Nabble - debian-gtk-gnome

Nautilus scripts

2009-11-29T02:14:05Z

Hello,

being a fan of Nautilus scripts, I wrote my program gallery-uploader
([0]) so that it can also be used as such (and I personally do use it as
such).

But then, I noticed that the only way to enable a nautilus script is, as
far as I know, to link it from ~/.gnome/nautilus-scripts . This kind of
defeated my purpose of creating something which could be useful even to
people not knowing how to use a terminal/fiddle with hidden files.

Notice that there is a utility packaged only in Ubuntu and apparently
dead upstream, nautilus-script-manager ([1]), which is an extremely
simple bash script... so still a command-line utility.

That's why I created my nautilus-scripts-manager ([2], notice the "s" in
"scripts") and I packaged it.

Now: both nautilus-script-manager and a handful of nautilus scripts also
packaged in Ubuntu follow the rule that the system-wide installed
scripts lie (or are linked) in /usr/share/nautilus-scripts . So I
followed this rule too in installing gallery-uploader, and assumed it is
followed while writing nautilus-scripts-manager - in the end, I thought
it was better to follow an arbitrary one that to arbitrarily create a
new one.

However, my (potential) sponsor for nautilus-scripts-manager expressed
some doubts about the assumption, so I'm here asking: what do you
suggest I should do?

I figured out 2 possibilities:
1) keep on using /usr/share/nautilus-scripts
2) use $PREFIX/share/nautilus-scripts , and look for
$PREFIX/share/nautilus-scripts and $PREFIX/local/share/nautilus-scripts
in nautilus-scripts-manager.

Notice that for what concerns Debian, there is almost no practical
difference between 1) and 2) (I'm not aware of any non-packaged nautilus
script configured to be installed system-wise)... but still, I'd like to
know which is the best... and to get any other enlightenment from you.

Also notice that all this applies independently from the fact that in
next release of my utility I'd like it to support also user-provided
(not only system-wise installed) scripts.

I'd also like to bring to Debian a couple of very useful scripts that
are installed in Ubuntu, such as audio-convert.

Thanks (please CC me in replies, as I'm not subscribed)

Pietro

[0]: http://packages.debian.org/gallery-uploader
[1]: http://packages.ubuntu.com/nautilus-script-manager
[2]: http://www.pietrobattiston.it/nautilus-scripts-manager/

signature.asc (204 bytes) Download Attachment

[Future Icon Records] You've been added to our mailing list.

2009-11-28T19:58:02Z

Hi I represent KONVICT MUSIC recording artist COLBY O'DONIS (Just Dance Ft Colby O'Donis. Beautiful Ft Colby O'Donis) and we want to share with you His first Original Christmas song I made a radio edit of so happy here it is if you like it Radio Edit Of - So Happy https://rcpt.yousendit.com/782608652/9a8972b464bfc006aa5139a89722060d Instrumental Radio Edit - So Happy https://rcpt.yousendit.com/782608822/4c2efde9129f9900fe9782387ef48410 

--------
Get your free download from Future Icon Records here: http://fburls.com/30-eRKr74xA
--------

You have been added to the Future Icon Records fan list!

If you would like to verify your info or add more to your fan profile, you can do so by clicking on the following link:

http://www.FanBridge.com/signup/fansignup.php?userid=129853&email=debian-gtk-gnome@...&confCode=b7bahK34btk992e6r22U3dFUhc

--
This list is powered by FanBridge, the world's leading provider of fan relationship management services for artists.

With FanBridge your information is always secure.

For more information about FanBridge please visit http://www.FanBridge.com/learn/
--

***Important: Please be sure to add the email address (futureiconrecords@...) to your safe senders list.***

Here's how:

Gmail
1. Click Contacts along the left side of any Gmail page.
2. Click Add Contact.
3. In the primary email address box, type futureiconrecords@....
4. Click Save.

AOL (version 9.0 or higher)
1. Click the Mail menu and select Address Book.
2. In the pop up box, click the Add button.
3. In the "Other E-Mail" field, type futureiconrecords@....
4. Make our From address the "Primary E-Mail" address by checking the associated check box.
5. Click the Save button.

AOL 8.0
1. Open this confirmation email.
2. Click Add Address.
3. Verify the sender's contact information (futureiconrecords@...).
4. Click Save.

Yahoo!
1. Click the "addresses" button
2. Select "Add Contact"
3. Save the futureiconrecords@... to your contacts list.

Hotmail
1. Click Options.
2. On the left side of the page, click Mail, and then click Junk E-Mail Protection.
3. Click Safe List.
4. Type futureiconrecords@..., and then click Add.

Outlook
1. Right-click on a message from futureiconrecords@....
2. Point to Junk E-mail, and click Add Sender to Safe Senders List.

----------------------------------------
Future Icon Records sent this email to debian-gtk-gnome@...
Questions? Contact futureiconrecords@... or Future Icon Records, c/o FanBridge, Inc. - 14525 SW Millikan Way, #16910, Beaverton, Oregon 97005, United States

Update Your Information - http://fburls.com/48-S6wkPkb0
Forward to a friend - http://fburls.com/44-EObOIPN9
Unsubscribe - http://fburls.com/28-gXPsx29D
Privacy Policy - http://www.FanBridge.com/learn/privacy.php

This email message is powered by FanBridge:
http://www.FanBridge.com/b.php?id=129853
Powering Valuable Fan Relationships

--
To UNSUBSCRIBE, email to debian-gtk-gnome-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: How to break circular Build-Depends between gir-repository and gstreamer?

2009-11-28T04:08:01Z

Le vendredi 27 novembre 2009 à 11:24 -0800, Daniel Schepler a écrit :
> In fact, it doesn't have direct Build-Depends on gstreamer. The problem here
> is that it Build-Depends on webkit and (indirectly) tracker, which both Build-
> Depend on gstreamer.

I’ve asked the webkit maintainers to build the introspection data
directly in webkit, so that the build-dependency can be removed.

As for Tracker, you’d have to explain how this indirect dependency
happens.

Cheers,
--
.''`. Josselin Mouette
: :' :
`. `' “I recommend you to learn English in hope that you in
`- future understand things” -- Jörg Schilling

signature.asc (197 bytes) Download Attachment

Re: How to break circular Build-Depends between gir-repository and gstreamer?

2009-11-27T11:31:45Z

Am Freitag, den 27.11.2009, 11:24 -0800 schrieb Daniel Schepler:

> On Friday 27 November 2009 11:15:52 Sebastian Dröge wrote:
> > Am Freitag, den 27.11.2009, 10:50 -0800 schrieb Daniel Schepler:
> > > I'm seeing some circularity in the Build-Depends for gir-repository and
> > > gstreamer:
> > > [...]
> > > How would you recommend I break these cycles? Build bootstrap versions
> > > of gstreamer and gst-plugins-base without gir support? Or build
> > > bootstrap versions of webkit and tracker without gstreamer support?
> >
> > Simple answer: gir-repository should not build depend on gstreamer
> > anymore because the gobject-introspection stuff was moved from
> > gir-repository to gstreamer.
>
> In fact, it doesn't have direct Build-Depends on gstreamer. The problem here
> is that it Build-Depends on webkit and (indirectly) tracker, which both Build-
> Depend on gstreamer.

Right, well, that problem will fix itself in the future when everything
has moved from gir-repository to the correct packages. :)

signature.asc (205 bytes) Download Attachment

Re: How to break circular Build-Depends between gir-repository and gstreamer?

2009-11-27T11:24:18Z

On Friday 27 November 2009 11:15:52 Sebastian Dröge wrote:

> Am Freitag, den 27.11.2009, 10:50 -0800 schrieb Daniel Schepler:
> > I'm seeing some circularity in the Build-Depends for gir-repository and
> > gstreamer:
> > [...]
> > How would you recommend I break these cycles? Build bootstrap versions
> > of gstreamer and gst-plugins-base without gir support? Or build
> > bootstrap versions of webkit and tracker without gstreamer support?
>
> Simple answer: gir-repository should not build depend on gstreamer
> anymore because the gobject-introspection stuff was moved from
> gir-repository to gstreamer.

In fact, it doesn't have direct Build-Depends on gstreamer. The problem here
is that it Build-Depends on webkit and (indirectly) tracker, which both Build-
Depend on gstreamer.
--
Daniel Schepler

--
To UNSUBSCRIBE, email to debian-gtk-gnome-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: How to break circular Build-Depends between gir-repository and gstreamer?

2009-11-27T11:15:52Z

Am Freitag, den 27.11.2009, 10:50 -0800 schrieb Daniel Schepler:
> I'm seeing some circularity in the Build-Depends for gir-repository and
> gstreamer:
> [...]
> How would you recommend I break these cycles? Build bootstrap versions of
> gstreamer and gst-plugins-base without gir support? Or build bootstrap
> versions of webkit and tracker without gstreamer support?

Simple answer: gir-repository should not build depend on gstreamer
anymore because the gobject-introspection stuff was moved from
gir-repository to gstreamer.

signature.asc (205 bytes) Download Attachment

How to break circular Build-Depends between gir-repository and gstreamer?

2009-11-27T10:50:26Z

I'm seeing some circularity in the Build-Depends for gir-repository and
gstreamer:

daniel@frobozz:/var/cache/pbuildd$ cat build/g/gstreamer0.10/build-log-amd64
E: Could not find any package for gir-repository-dev
daniel@frobozz:/var/cache/pbuildd$ cat build/g/gir-repository/build-log-amd64
E: Could not find any package for libwebkit-dev
E: Could not find any package for libnautilus-extension-dev
daniel@frobozz:/var/cache/pbuildd$ cat build/w/webkit/build-log-amd64
E: Could not find any package for libgstreamer-plugins-base0.10-dev
daniel@frobozz:/var/cache/pbuildd$ cat build/n/nautilus/build-log-amd64
E: Could not find any package for libtrackerclient-dev (>= 0.6.6)
daniel@frobozz:/var/cache/pbuildd$ cat build/t/tracker/build-log-amd64
E: Could not find any package for libgstreamer0.10-dev (>= 0.10.12)
E: Could not find any package for libgstreamer-plugins-base0.10-dev (>=
0.10.12)
daniel@frobozz:/var/cache/pbuildd$ cat build/g/gst-plugins-base0.10/build-log-
amd64
E: Could not find any package for libgstreamer0.10-dev (>= 0.10.24.2)
E: Could not find any package for gstreamer-tools (>= 0.10.14)
E: Could not find any package for gstreamer0.10-doc
E: Could not find any package for gir-repository-dev
E: Could not find any package for gir1.0-gstreamer-0.10

How would you recommend I break these cycles? Build bootstrap versions of
gstreamer and gst-plugins-base without gir support? Or build bootstrap
versions of webkit and tracker without gstreamer support?

(For simplicity, I've already broken another cycle of pulseaudio -> bluez ->
gst-plugins-base -> libtheora -> libsdl1.2 -> pulseaudio by building a
bootstrap version of pulseaudio without bluetooth support.)
--
Daniel Schepler

--
To UNSUBSCRIBE, email to debian-gtk-gnome-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: One True DPI

2009-11-21T00:49:21Z

Le vendredi 20 novembre 2009 à 09:33 -0600, Peter Schultz a écrit :
> Gnome's font settings do not allow me to go any lower than 50. I know
> 44 DPI is very low for today's desktop monitors, but it makes for an
> excellent big screen TV. Shouldn't I be able to set this to 44 if
> that's what my monitor has?

The code at fault is this one:

http://git.gnome.org/cgit/gnome-settings-daemon/tree/plugins/xsettings/gsd-xsettings-manager.c

/* X servers sometimes lie about the screen's physical dimensions, so we
cannot
* compute an accurate DPI value. When this happens, the user gets fonts that
* are too huge or too tiny. So, we see what the server returns: if it reports
* something outside of the range [DPI_LOW_REASONABLE_VALUE,
* DPI_HIGH_REASONABLE_VALUE], then we assume that it is lying and we use
* DPI_FALLBACK instead.
*
* See get_dpi_from_gconf_or_server() below, and also
* https://bugzilla.novell.com/show_bug.cgi?id=217790
*/
#define DPI_FALLBACK 96
#define DPI_LOW_REASONABLE_VALUE 50
#define DPI_HIGH_REASONABLE_VALUE 500

Maybe you can request the minimum to be lowered if you have an example
of hardware with such a low resolution. Please file a bug upstream,
against the gnome-settings-daemon component.

Cheers,
--
.''`. Josselin Mouette
: :' :
`. `' “I recommend you to learn English in hope that you in
`- future understand things” -- Jörg Schilling

signature.asc (197 bytes) Download Attachment

One True DPI

2009-11-20T07:33:30Z

I'm trying to get to the bottom of DPI on the latest sid, I think
there may be a bug here. In XF86Config I have set:

Option "UseEdidDpi" "FALSE"
Option "DPI" "44 x 44"

but Gnome will not respect that. I changed the
/desktop/gnome/font_rendering/dpi gconf key to 44 and that's really
done wonders except it seems certain root processes are not aware of
the changes I've made in font settings. The gdm login dialogs, the
terminal output in Synaptic Package Manager and the Log File Viewer
all have (for this 50" 1080 HDTV display) extremely tiny fonts.

Gnome's font settings do not allow me to go any lower than 50. I know
44 DPI is very low for today's desktop monitors, but it makes for an
excellent big screen TV. Shouldn't I be able to set this to 44 if
that's what my monitor has?

I have confirmed the setting in the NVIDIA settings app and with the
command `xrdb -query | grep dpi'. Just for fun I created a new user,
at first everything looked great. I checked Xft.dpi and it was set to
96, so I merged in 44 and did not notice a difference. The query said
Xft.dpi was 44 so I logged in and out and found that Xft.dpi was now
set to 0. I think that means gconf is using the X server setting.

Thanks for you time,
Pete

--
To UNSUBSCRIBE, email to debian-gtk-gnome-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Please test experimental gvfs packages

2009-11-18T09:20:30Z

Josselin Mouette wrote:
> Hi,

Hi

> since Michael Biebl fixed IDE CD support in devicekit-disks, the
> GDU-enabled version of gvfs (currently in experimental) should be usable
> again.

The packages and the versions are
gvfs_1.4.1-5+gdu
gvfs-backends_1.4.1-5+gdu
gvfs-bin_1.4.1-5+gdu (optional)
gvfs-fuse_1.4.1-5+gdu (optional)

logout/login from your current GNOME session (or reboot your machine).

> Before uploading it to unstable, I’d appreciate if some adventurous
> people could test it and report any regressions.

I'm especially interested if automounting/media detctions of cd-roms is working
properly with ide-cd. You will easily know if you are using ide-cd, if your
cd-rom device is something like /dev/hd* (whereas libata used /dev/sr* resp.
/dev/scd*).

If you have any problems, please CC me or contact me directly.
Succesfull test report are of course also welcome.

Cheers,
Michael

signature.asc (270 bytes) Download Attachment

Please test experimental gvfs packages

2009-11-18T06:31:24Z

Hi,

since Michael Biebl fixed IDE CD support in devicekit-disks, the
GDU-enabled version of gvfs (currently in experimental) should be usable
again.

Before uploading it to unstable, I’d appreciate if some adventurous
people could test it and report any regressions.

Thanks,
--
.''`. Josselin Mouette
: :' :
`. `' “I recommend you to learn English in hope that you in
`- future understand things” -- Jörg Schilling

signature.asc (196 bytes) Download Attachment

RE: swfdec-gnome: Please update to 2.28.0

2009-11-07T15:58:05Z

Hi,

I've upload updated swfdec-gnome packaget at
http://mentors.debian.net/debian/pool/main/s/swfdec-gnome/swfdec-gnome_2.28.0-1.dsc

Its changelog is not collect (no mention NMU ;) but it can be used to update
purpose.

--
Regards,

Hideki Yamane henrich @ debian.or.jp/iijmio-mail.jp
http://wiki.debian.org/HidekiYamane

attachment0 (853 bytes) Download Attachment

Re: GObject introspection mini-policy, take 2

2009-09-28T03:45:05Z

Le dimanche 27 septembre 2009 à 10:59 +0800, Paul Wise a écrit :
> > gir1.0-foo-2.0 /usr/lib/girepository-1.0/Foo-2.0.typelib
>
> Would this proposal need to be adjusted for multiarch support?

I’m not sure. It will be mostly used by interpreters, which themselves
don’t need support for multiarch with the current state of the proposal.

Cheers,
--
.''`. Josselin Mouette
: :' :
`. `' “I recommend you to learn English in hope that you in
`- future understand things” -- Jörg Schilling

signature.asc (196 bytes) Download Attachment

Re: GObject introspection mini-policy, take 2

2009-09-27T06:12:02Z

Am Sonntag 27 September 2009 04:59:38 schrieb Paul Wise:

> 2009/9/26 Josselin Mouette <joss@...>:
> > 1. Directory layout
> >
> > GObject-introspection data is generally provided in two formats:
> > * XML format in /usr/share/gir-1.0/Foo-X.Y.gir
> > * binary format in /usr/lib/girepository-1.0/Foo-X.Y.typelib
>
> ...
>
> > 6. Example
> >
> > Suppose that libfoo-2.0 is an API built on libbar-3.0. The libfoo-2.0
> > source generates the following files, put in the following packages:
> > libfoo-2.0-3 /usr/lib/libfoo-2.0.so.3*
> > libfoo-2.0-dev /usr/lib/libfoo-2.0.so (and other usual stuff)
> > libfoo-2.0-dev /usr/share/gir-1.0/Foo-2.0.gir
> > gir1.0-foo-2.0 /usr/lib/girepository-1.0/Foo-2.0.typelib
>
> Would this proposal need to be adjusted for multiarch support?
>
> If so, perhaps just insert an arch triple?
>
> /usr/lib/<arch>/girepository-1.0/Foo-2.0.typelib

Isn't the lib directory for each arch already different?

I just question the need for a seperate package for _one_ typelib file.

HS

--
To UNSUBSCRIBE, email to debian-gtk-gnome-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

cruft: /tmp/pulse-$RAND and /tmp/virtual-$USER.$RAND/ ?

2009-09-27T00:41:37Z

Hi all,

Just logging into and out of GNOME from testing/squeeze leaves two
empty directories in /tmp/

/tmp/pulse-$RAND/
/tmp/virtual-$USER.$RAND/

Has anyone got any ideas about which package is responsible for these?
I don't have pulseaudio installed so I'm not sure about the first one
and I can't figure out what creates the second one.

--
bye,
pabs

http://wiki.debian.org/PaulWise

--
To UNSUBSCRIBE, email to debian-gtk-gnome-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: GObject introspection mini-policy, take 2

2009-09-26T19:59:38Z

2009/9/26 Josselin Mouette <joss@...>:

> 1. Directory layout
>
> GObject-introspection data is generally provided in two formats:
> * XML format in /usr/share/gir-1.0/Foo-X.Y.gir
> * binary format in /usr/lib/girepository-1.0/Foo-X.Y.typelib
...
> 6. Example
>
> Suppose that libfoo-2.0 is an API built on libbar-3.0. The libfoo-2.0
> source generates the following files, put in the following packages:
> libfoo-2.0-3 /usr/lib/libfoo-2.0.so.3*
> libfoo-2.0-dev /usr/lib/libfoo-2.0.so (and other usual stuff)
> libfoo-2.0-dev /usr/share/gir-1.0/Foo-2.0.gir
> gir1.0-foo-2.0 /usr/lib/girepository-1.0/Foo-2.0.typelib

Would this proposal need to be adjusted for multiarch support?

If so, perhaps just insert an arch triple?

/usr/lib/<arch>/girepository-1.0/Foo-2.0.typelib

--
bye,
pabs

http://wiki.debian.org/PaulWise

--
To UNSUBSCRIBE, email to debian-gtk-gnome-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

GObject introspection mini-policy, take 2

2009-09-26T05:26:47Z

After an insightful discussion with Sebastian, and taking into account
other suggestions from the list, here is a new proposal.

1. Directory layout

GObject-introspection data is generally provided in two formats:
* XML format in /usr/share/gir-1.0/Foo-X.Y.gir
* binary format in /usr/lib/girepository-1.0/Foo-X.Y.typelib

2. Binary introspection packages

The binary typelib file must be put in an architecture-dependent package
named after its namespace. The name should be gir1.0-NAMESPACE-VERSION.
For example, the package containing WebKit-1.0.typelib will be named
gir1.0-webkit-1.0.

Giant repositories of unrelated introspection data should be avoided.
(Under this rationale, gobject-introspection-repository will be split.)
However, related libraries that are known to evolve together can live in
the same package (example: Gst*-0.10).

Introspection packages belong in section libs for the moment. If there
are enough packages to justify it, a new section will be requested to
the FTP masters.

3. XML introspection data

The XML format introspection must be shipped in another
architecture-dependent* package of the same source.

* This is so that it is guaranteed to be accessible at
build time by the tool that will compute the
dependencies for the .typelib files.

If the source package also contains the library itself, this data should
be in the development binary package. If the introspection data is split
from the library source (e.g. for gobject-instrospection-repository), a
separate package containing this XML data can be created, in section
libdevel.

The package containing the XML data doesn’t need to depend on the
introspection package. It can contain XML data for several unrelated
libraries, since in the end it doesn’t depend on them.

4. Dependencies of introspection packages

Introspection packages must depend on the libraries they reference, with
a sufficient version for the symbols they reference.

For that effect, I propose to introduce a new helper, dh_girepository,
in the gobject-introspection package (which is already a
build-dependency for introspection packages). It would wrap
dpkg-shlibdeps so that the dependencies are the same as those of similar
ELF binaries.

Introspection packages must depend on other introspection packages that
are referenced through <include> statements. The helper should generate
such dependencies as well.

Packages containing the XML data don’t need any specific new
dependencies.

5. Dependencies on introspection packages

Currently, there are only Seed (JavaScript) scripts to use these
introspection packages. In the future, there might also be Python or
other interpreted languages.

Generating dependencies automatically for interpreted languages is not
reliable. Therefore, these packages must depend by hand on the
appropriate gir1.0-* packages. The interpreters themselves don’t need to
depend on packages they don’t use directly.

6. Example

Suppose that libfoo-2.0 is an API built on libbar-3.0. The libfoo-2.0
source generates the following files, put in the following packages:
libfoo-2.0-3 /usr/lib/libfoo-2.0.so.3*
libfoo-2.0-dev /usr/lib/libfoo-2.0.so (and other usual stuff)
libfoo-2.0-dev /usr/share/gir-1.0/Foo-2.0.gir
gir1.0-foo-2.0 /usr/lib/girepository-1.0/Foo-2.0.typelib

libfoo-2.0-dev Depends: libfoo-2.0-3, libbar-3.0-dev
gir1.0-foo-2.0 Depends: ${gir:Depends} which expands to:
libfoo-2.0-3, gir1.0-bar-3.0

If foobar is a package containing the following JS script:
#! /usr/bin/seed
Foo = imports.gi.Foo;
// Stuff that uses the Foo 2.0 API

Then foobar Depends: gir1.0-foo-2.0

I’ve started preliminary work on dh_girepository. The first version will
be a bit hackish and will rely on building an intermediate binary
referencing the appropriate symbols that will be fed to dpkg-shlibdeps.
Doing better will require extending dpkg-shlibdeps so that it accepts
another input format than ELF (it doesn’t have to be the GObject XML
format, it could be anything easy to generate).

--
.''`. Josselin Mouette
: :' :
`. `' “I recommend you to learn English in hope that you in
`- future understand things” -- Jörg Schilling

signature.asc (197 bytes) Download Attachment

Re: Fixing the Gobject Introspection mess

2009-09-26T04:23:38Z

Le samedi 26 septembre 2009 à 13:12 +0200, Sebastian Dröge a écrit :
> > There is no “build time” for interpreters. What do you mean exactly?
>
> Interpreters should use the typelib file and not the GIR file. The GIR
> file is meant for generating bindings (like the current Python/C++/C#
> bindings) while the typelib file is meant to be used at runtime to
> generated bindings on the fly.

OK, then I agree the .gir file should go in a separate development
package.

But that will make dependency computation more difficult, since it will
have to be done from the .typelib file. Time to dig deeper into the
libgirepository API…

> So you would always put the GIR and typelib files into a single separate
> package? Or only the typelib file? IMHO only the latter would make
> sense, the GIR file can/should be in the -dev package, and if only
> because of space savings.

Yes, agreed.

--
.''`. Josselin Mouette
: :' :
`. `' “I recommend you to learn English in hope that you in
`- future understand things” -- Jörg Schilling

signature.asc (197 bytes) Download Attachment

Re: Fixing the Gobject Introspection mess

2009-09-26T04:12:35Z

Am Samstag, den 26.09.2009, 11:54 +0200 schrieb Josselin Mouette:

> Le samedi 26 septembre 2009 à 07:56 +0200, Sebastian Dröge a écrit :
> > Am Freitag, den 25.09.2009, 13:32 +0200 schrieb Josselin Mouette:
> > > 1. Package layout
> > >
> > > GObject-introspection packages provide introspection data
> > > in /usr/share/gir-1.0/Foo-X.Y.gir, and the
> > > optional /usr/lib/girepository-1.0/Foo-X.Y.typelib.
> > >
> > > The packages should be architecture-dependent.
> >
> > Only the typelib file actually is meant to be architecture-dependent
> > (right, the GIR file could be arch-dep too if the headers and API parts
> > of the sources (GObject properties/signals) are different from arch to
> > arch. But who does that?!).
>
> This has already happened, and this will happen again. For the same
> reason we make headers architecture-dependent, I think we should make
> GIR files the same.

Ok, with my proposal to put them into the -dev packages that is no
problem then ;)

> > Also the GIR file is only meant for build time things so it could simply
> > be placed in the -dev packages (as I've done so far).
>
> There is no “build time” for interpreters. What do you mean exactly?

Interpreters should use the typelib file and not the GIR file. The GIR
file is meant for generating bindings (like the current Python/C++/C#
bindings) while the typelib file is meant to be used at runtime to
generated bindings on the fly.

> > Putting the typelib files in the shared library packages will create
> > conflicts for soname changes. Not good (I know I placed them there in
> > some packages). Creating a new package just for the typelib file is not
> > good either ;)
>
> Agreed. We should probably mandate to always split the introspection
> files in a separate package.

So you would always put the GIR and typelib files into a single separate
package? Or only the typelib file? IMHO only the latter would make
sense, the GIR file can/should be in the -dev package, and if only
because of space savings.

If you meant the former, shall we also create separate packages for Vala
bindings? They're very similar to the GIR files but are also only needed
at build time ;)

signature.asc (205 bytes) Download Attachment

Re: Fixing the Gobject Introspection mess

2009-09-26T02:54:38Z

Le samedi 26 septembre 2009 à 07:56 +0200, Sebastian Dröge a écrit :

> Am Freitag, den 25.09.2009, 13:32 +0200 schrieb Josselin Mouette:
> > 1. Package layout
> >
> > GObject-introspection packages provide introspection data
> > in /usr/share/gir-1.0/Foo-X.Y.gir, and the
> > optional /usr/lib/girepository-1.0/Foo-X.Y.typelib.
> >
> > The packages should be architecture-dependent.
>
> Only the typelib file actually is meant to be architecture-dependent
> (right, the GIR file could be arch-dep too if the headers and API parts
> of the sources (GObject properties/signals) are different from arch to
> arch. But who does that?!).

This has already happened, and this will happen again. For the same
reason we make headers architecture-dependent, I think we should make
GIR files the same.

> Also the GIR file is only meant for build time things so it could simply
> be placed in the -dev packages (as I've done so far).

There is no “build time” for interpreters. What do you mean exactly?

> Putting the typelib files in the shared library packages will create
> conflicts for soname changes. Not good (I know I placed them there in
> some packages). Creating a new package just for the typelib file is not
> good either ;)

Agreed. We should probably mandate to always split the introspection
files in a separate package.

Cheers,
--
.''`. Josselin Mouette
: :' :
`. `' “I recommend you to learn English in hope that you in
`- future understand things” -- Jörg Schilling

signature.asc (197 bytes) Download Attachment

Re: Fixing the Gobject Introspection mess

2009-09-26T00:24:40Z

On Sep 25, Julien Cristau <jcristau@...> wrote:

> Doesn't this break co-installability of libfoo2.0-X and libfoo2.0-Y, if
> both install Foo-2.0.gir?
And what about multiarch?

--
ciao,
Marco

signature.asc (205 bytes) Download Attachment

Re: Fixing the Gobject Introspection mess

2009-09-25T22:56:04Z

Am Freitag, den 25.09.2009, 13:32 +0200 schrieb Josselin Mouette:

>
> [...]
>
> 1. Package layout
>
> GObject-introspection packages provide introspection data
> in /usr/share/gir-1.0/Foo-X.Y.gir, and the
> optional /usr/lib/girepository-1.0/Foo-X.Y.typelib.
>
> The packages should be architecture-dependent.

Only the typelib file actually is meant to be architecture-dependent
(right, the GIR file could be arch-dep too if the headers and API parts
of the sources (GObject properties/signals) are different from arch to
arch. But who does that?!).

Also the GIR file is only meant for build time things so it could simply
be placed in the -dev packages (as I've done so far).

The typelib file is another issue though...

> 2. Naming scheme
>
> The package should be named gir1.0-foo-X.Y. For example, the package
> containing WebKit-1.0.gir will be named gir1.0-webkit-1.0.
>
> Giant repositories of dozens of unrelated introspection data should be
> avoided. (Under this rationale, gobject-introspection-repository will be
> split.) However, related libraries that are known to evolve together can
> live in the same package (example: Gst*-0.10).
>
> If, alternatively, the introspection data belongs in the same source
> package as the library it references, it can be put in the same binary
> package. In this case, it must feature a Provides: field corresponding
> to the name of the introspection data. For example, libfoo2.0-2
> containing libfoo-2.0.so.2 and Foo-2.0.gir must provide gir1.0-foo-2.0.

Putting the typelib files in the shared library packages will create
conflicts for soname changes. Not good (I know I placed them there in
some packages). Creating a new package just for the typelib file is not
good either ;)

> [...]

Everything else sounds good to me.

signature.asc (205 bytes) Download Attachment

Re: Fixing the Gobject Introspection mess

2009-09-25T04:46:05Z

Le vendredi 25 septembre 2009 à 13:44 +0200, Julien Cristau a écrit :

> On Fri, Sep 25, 2009 at 13:32:54 +0200, Josselin Mouette wrote:
>
> > If, alternatively, the introspection data belongs in the same source
> > package as the library it references, it can be put in the same binary
> > package. In this case, it must feature a Provides: field corresponding
> > to the name of the introspection data. For example, libfoo2.0-2
> > containing libfoo-2.0.so.2 and Foo-2.0.gir must provide gir1.0-foo-2.0.
> >
> Doesn't this break co-installability of libfoo2.0-X and libfoo2.0-Y, if
> both install Foo-2.0.gir?

Good point. Maybe we can recommend this solution only for libraries
where this is not expected to happen.

Or, given the (large) size of introspection stuff, to mandate having it
always split.

--
.''`. Josselin Mouette
: :' :
`. `' “I recommend you to learn English in hope that you in
`- future understand things” -- Jörg Schilling

signature.asc (196 bytes) Download Attachment

Re: Fixing the Gobject Introspection mess

2009-09-25T04:43:21Z

On Fri, Sep 25, 2009 at 13:32:54 +0200, Josselin Mouette wrote:

Doesn't this break co-installability of libfoo2.0-X and libfoo2.0-Y, if
both install Foo-2.0.gir?

Cheers,
Julien

--
To UNSUBSCRIBE, email to debian-gtk-gnome-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Fixing the Gobject Introspection mess

2009-09-25T04:32:54Z

Hi,

with an increasing number of packages providing introspection data for
Gobject, each one doing things its own way, it’s starting to be a big
mess. I’d like to fix this mess before we have a hundred different
packages, all behaving differently.

Which is why I’m proposing a Gobject-introspection mini-policy. And of
course, to implement it in existing packages.

1. Package layout

GObject-introspection packages provide introspection data
in /usr/share/gir-1.0/Foo-X.Y.gir, and the
optional /usr/lib/girepository-1.0/Foo-X.Y.typelib.

The packages should be architecture-dependent.

2. Naming scheme

The package should be named gir1.0-foo-X.Y. For example, the package
containing WebKit-1.0.gir will be named gir1.0-webkit-1.0.

Giant repositories of dozens of unrelated introspection data should be
avoided. (Under this rationale, gobject-introspection-repository will be
split.) However, related libraries that are known to evolve together can
live in the same package (example: Gst*-0.10).

If, alternatively, the introspection data belongs in the same source
package as the library it references, it can be put in the same binary
package. In this case, it must feature a Provides: field corresponding
to the name of the introspection data. For example, libfoo2.0-2
containing libfoo-2.0.so.2 and Foo-2.0.gir must provide gir1.0-foo-2.0.

Introspection packages belong in section libs for the moment. If there
are enough packages to justify it, a new section will be requested to
the FTP masters.

3. Dependencies of introspection packages

Introspection packages must depend on the libraries they reference, with
a sufficient version for the symbols they reference.

For that effect, I propose to introduce a new helper, dh_gir, in the
gobject-introspection package (which is already a build-dependency for
introspection packages). It would wrap dpkg-shlibdeps (possibly using
its internals until the needed interfaces are exported) so that the
dependencies are the same as those of similar ELF binaries.

Introspection packages must depend on other introspection packages that
are referenced through <include> statements. The helper should generate
such dependencies as well.

4. Dependencies on introspection packages

Currently, there are only Seed (JavaScript) scripts to use these
introspection packages. In the future, there might also be Python or
other interpreted languages.

Generating dependencies automatically for interpreted languages is not
reliable. Therefore, these packages must depend by hand on the
appropriate gir1.0-* packages. The interpreters themselves don’t need to
depend on packages they don’t use directly.

Thoughts anyone? I’ll start working on dh_gir as described if there is
consensus on the proposed policy. Once implemented in a few packages,
the policy would be put in a more formal way and added to
gobject-introspection.

Cheers,
--
.''`. Josselin Mouette
: :' :
`. `' “I recommend you to learn English in hope that you in
`- future understand things” -- Jörg Schilling

signature.asc (196 bytes) Download Attachment

Nautilus hiccup in unstable

2009-09-24T01:47:09Z

Hi,

in my haste to fix #545254, I have uploaded nautilus 2.28.0 a bit too
early. If you have not upgraded yet, please don’t install 2.28.0-1!

If you have already upgraded, you should install 2.28.0-2 as soon as it
is available, and then remove any ~/.nautilus/metafiles/migrated-to-gvfs
files. This way you will find back your metadata (icon positions on the
desktop, window sizes, emblems…) at the next login.

Sorry for the inconvenience.

Cheers,
--
.''`. Josselin Mouette
: :' :
`. `' “I recommend you to learn English in hope that you in
`- future understand things” -- Jörg Schilling

signature.asc (196 bytes) Download Attachment

Adivinha a palavra

2009-09-14T11:01:37Z

im43_6

Caso não visualize correctamente este e-mail, por favor clique AQUI.
Adivinha a palavra e recebe uma Scooter Sym MIO





Para deixar de receber estas ofertas no seu e-mail clicar aqui
NOTA INFORMATIVA: O presente email destina-se única e exclusivamente a informar potenciais utilizadores. Se pretender não receber mais estes emails clique AQUI.

Nosso primeiro uniforme de Futebol - Meninos da Doze

2009-09-02T12:58:15Z

Boa Tarde,

A Associação Esportiva Unidos da Doze é uma entidade sem fins lucrativos que promove na comunidade do Parque Dorotéia, Zona Sul de Sâo Paulo projetos sociais ligados ao Esporte, Lazer e Cultura.

Para saber mais sobre a entidade visite www.unidosdadoze.com.br

O Projeto Meninos da Doze está com uma campanha para conseguir verbas para a compra do seu primeiro uniforme.

Viemos até você para solicitar sua contribuição, acreditamos que com a colaboração de cada um teremos nosso objetivo conquistado.

Faça a sua contribuição com toda a segurança no site http://www.mootiva.com.br/meninosdadoze

Muito obrigado, nossa comunidade agradece

Paulo Toledo
Presidente

Não deseja mais receber nossas mensagens? Cancele o recebimento aqui.

¡Move on! ganate un MP3 de 8gb, tus amigos ya lo hicieron...

2009-08-25T07:42:41Z

Having trouble viewing this e-mail? please use this link.

Si no puede ver bien este email, véalo haciendo click aqui
Si no puede ver las imágenes, haga click derecho al mouse y elija la opción: “Descargar Imágenes”.

"/>

This email was sent to debian-gtk-gnome@..., by arturomacias03@....
You may unsubscribe from this list. If this message was received in error, please reportit@....

ePublicidad | LOPEZ MATEOS #1157 | GUADALAJARA | | 44630 | MX

Re: planning directfb 1.4 transition

2009-08-22T07:38:19Z

On Saturday 22 August 2009, Fathi Boudra wrote:
> This is an informative mail. I have uploaded DirectFB 1.4 to
> experimental. At some point, the transition could be started (after
> coordination with the related maintainers).
>
> I didn't tried myself to rebuild affected packages yet.

I've built cairo, gtk+2.0 and cdebconf (all from unstable) against it for
a D-I test. The builds were all OK, but I see serious regressions in D-I.

In this screenshot you can see that our banner is missing:
http://people.debian.org/~fjp/tmp/d-i/directfb_regression.png

And the same goes for icons, so basically any image.

Also, if I move the cursor using the arrow keys, it jumps one line. E.g.
if I go down, the current line moves from Moldova to Montenegro and skips
Monaco. I guess the same happens for selection between two radiobuttons,
but there it actually results in the selection not changing at all
(because there's nothing to skip).

I've verified that both issues are not present in a daily built image
using current libraries from unstable. I'll file a bug against the
experimental version of directfb later.

There's also a rather large size increase of a D-I image: a daily built
image is 18458624, while one with the new directfb is 18905088; that's
436kB.

Cheers,
FJP

signature.asc (204 bytes) Download Attachment

planning directfb 1.4 transition

2009-08-22T05:13:13Z

(cc'ing related teams)

Hi,

This is an informative mail. I have uploaded DirectFB 1.4 to experimental.
At some point, the transition could be started (after coordination
with the related maintainers).

I didn't tried myself to rebuild affected packages yet.

Thus, quoting upstream:
Most software will run out-of-the-box after a recompile.
The major changes are listed here:
* Functions to rotate windows and layers:
IDirectFBDisplayLayer::GetRotation, IDirectFBDisplayLayer::SetRotation
and IDirectFBWindow::SetRotation
* Functions to alter or initialise keymaps:
IDirectFBInputDevice::LoadKeymap and
IDirectFBInputDevice::SetKeymapEntry
* DWOP_FOLLOW_BOUNDS: make the bounds of a window follow the parent bounds.
Note that this requires the SaWMan window manager to function.
* DWCAPS_SUBWINDOW: create a subwindow instead of a top-level window.
* New pixel format: RGBA4444
* added DFBSurfaceHintFlags to surface creation to optimise e.g.
memory allocation.

Let me know if there's known blockers.

cheers,

Fathi

ps: please cc me, I'm not subscribed to debian-boot or debian-gtk-gnome lists.

--
To UNSUBSCRIBE, email to debian-gtk-gnome-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Packages still using libgnomeprint

2009-08-18T08:13:36Z

Josselin Mouette wrote:

> Hi all,
>
> libgnomeprint/libgnomeprintui is going to be soon deprecated upstream.
> The GtkPrint replacement (built in GTK+ itself) has been available for 3
> years.
>
> I’d like to remove it before the squeeze release. This can only be done
> by getting rid of as much as possible of the reverse dependencies. When
> this is done, we’ll see how it is feasible.
>
> Note that some of these packages already include GtkPrint support, but
> you have to select it at compile time. Otherwise, please consider
> porting to the much more modern Cairo/GtkPrint API.
>
> As for bindings, they don’t have any reverse dependencies except for the
> Python ones, so I think we’d be better off removing them ASAP.
>
> If you are fine with it, I’ll do a MBF.
>
> <snip>
>
>
> Cheers,
>

Joss,

I was getting ready to file all of these so a +1 from me.

Thanks,

Barry deFreese

--
To UNSUBSCRIBE, email to debian-gtk-gnome-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Packages still using libgnomeprint

2009-08-18T07:16:43Z

Hi all,

libgnomeprint/libgnomeprintui is going to be soon deprecated upstream.
The GtkPrint replacement (built in GTK+ itself) has been available for 3
years.

I’d like to remove it before the squeeze release. This can only be done
by getting rid of as much as possible of the reverse dependencies. When
this is done, we’ll see how it is feasible.

Note that some of these packages already include GtkPrint support, but
you have to select it at compile time. Otherwise, please consider
porting to the much more modern Cairo/GtkPrint API.

As for bindings, they don’t have any reverse dependencies except for the
Python ones, so I think we’d be better off removing them ASAP.

If you are fine with it, I’ll do a MBF.

Daniel Leidert (dale) <daniel.leidert@...>
xmlroff (U)

Masayuki Hatta (mhatta) <mhatta@...>
abiword

J.H.M. Dassen (Ray) <jdassen@...>
goffice0.4
Note: used by abiword and gnucash, has already a fixed replacement in the archive.

Sebastien Bacher <seb128@...>
ghex

Mirco Bauer <meebey@...>
gfax (U)
gnome-desktop-sharp2 (U)

W. Martin Borgert <debacle@...>
xmlroff (U)

Rob Bradford <robster@...>
screem

Joachim Breitner <nomeata@...>
gnometab

Thomas Bushnell, BSG <tb@...>
gnucash

Arnaud Cornet <acornet@...>
ruby-gnome2

Debian Accessibility Team <debian-accessibility@...>
dots

Debian CLI Applications Team <pkg-cli-apps-team@...>
gfax

Debian CLI Libraries Team <pkg-cli-libs-team@...>
gnome-desktop-sharp2

Debian Evolution Maintainers <pkg-evolution-maintainers@...>
gtkhtml3.8
http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=pkg-gnome-maintainers@...;tag=gtkhtml3.8

Debian GNOME Maintainers <pkg-gnome-maintainers@...>
ghex (U)
gnome-games (U)
Note: fixed upstream
gnome-python-desktop (U)
Note: python-gnomeprint will be removed as soon as the rdeps are gone
gtksourceview
http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=pkg-gnome-maintainers@...;tag=gtksourceview1.0
gyrus (U)
libgnomedb3 (U)
Note: will soon be replaced by libgnomedb4, only one rdep

Debian Perl Group <pkg-perl-maintainers@...>
libgnome2-print-perl

Debian Ruby Extras Maintainers <pkg-ruby-extras-maintainers@...>
ruby-gnome2 (U)

Debian XML/SGML Group <debian-xml-sgml-pkgs@...>
xmlroff

Debian-Med Packaging Team <debian-med-packaging@...>
treeviewx

Sebastian Dröge <slomo@...>
ghex (U)
gnome-desktop-sharp2 (U)
gnome-games (U)
gnome-python-desktop (U)

Patrik Fimml <patrik@...>
abiword (U)

Heikki Henriksen <heikkih@...>
gtkhtml3.8 (U)

Joshua Kwan <joshk@...>
abiword (U)

Richard Laager <rlaager@...>
gbonds

Rafael Laboissiere <rafael@...>
plplot (U)

Jordi Mallach <jordi@...>
libgnomedb3 (U)

tony mancill <tmancill@...>
gbonds (U)

Margarita Manterola <marga@...>
linsmith

Loic Minier <lool@...>
ghex (U)
gnome-python-desktop
gtkhtml3.8 (U)
gtksourceview (U)
libgnomedb3 (U)

Emilio Pozuelo Monfort <pochu@...>
scribes

Gustavo R. Montesino <grmontesino@...>
libgnomedb3

Josselin Mouette <joss@...>
gnome-games
gnome-python-desktop (U)
gtksourceview (U)

Ryan Niebur <ryanryan52@...>
libgnome2-print-perl (U)

Goedson Teixeira Paixao <goedson@...>
gpaint

David Paleino <d.paleino@...>
treeviewx (U)

Charles Plessy <charles-debian-nospam@...>
treeviewx (U)

Python Applications Packaging Team <python-apps-team@...>
scribes (U)

Andrew Ross <andrewross@...>
plplot

Michael Schlueter <schlue@...>
gnome-photo-printer

Michael Schutte <m.schutte.jr@...>
ruby-gnome2 (U)

Carlo Segre <segre@...>
xournal

Gustavo Noronha Silva <kov@...>
gnome-python-desktop (U)

Geert Stappers <stappers@...>
conglomerate

Ondřej Surý <ondrej@...>
gyrus

Sergio Talens-Oliag <sto@...>
gnome-u2ps

Antonio Terceiro <terceiro@...>
ruby-gnome2 (U)

Samuel Thibault <sthibault@...>
dots (U)

Paul van Tilburg <paulvt@...>
ruby-gnome2 (U)

Cheers,
--
.''`. Josselin Mouette
: :' :
`. `' “I recommend you to learn English in hope that you in
`- future understand things” -- Jörg Schilling

signature.asc (196 bytes) Download Attachment

Re: WANTED: Perl / GTK+ hacker

2009-08-18T02:32:50Z

Le samedi 15 août 2009 à 11:26 +0200, Josselin Mouette a écrit :
> Since the guy who originally wrote it (Eric Gillespie) is no longer part
> of the project, I’m looking for a developer who knows Perl enough to
> make a port to GTK+. The largest part of the problem is porting from
> GnomeDruid to GtkAssistant, which probably only requires a few hours for
> a knowledgeable person.

Apparently an Ubuntu developer decided to do it at the same moment. See
http://bugs.debian.org/542175

Cheers,
--
.''`. Josselin Mouette
: :' :
`. `' “I recommend you to learn English in hope that you in
`- future understand things” -- Jörg Schilling

signature.asc (196 bytes) Download Attachment

Re: WANTED: Perl / GTK+ hacker

2009-08-16T01:21:53Z

Le samedi 15 août 2009 à 17:21 +0300, Kalle Olavi Niemitalo a écrit :
> The back button of GtkAssistant seems troublesome.
> In GnomeDruidPage, the back and next buttons just emit signals,
> which Debconf::FrontEnd::Gnome then handles by exiting the main
> loop and returning '' or 1 from sub go. In GtkAssistant however,
> the back button backtraces a private visited_pages list, and it
> is automatically hidden when this list is empty.

> (b) Handle the clicked signal from the back button and make the
> button visible against the wishes of GtkAssistant. If the
> visited_pages list remains empty at all times, then the
> handler added by GtkAssistant does nothing, and there is no
> need to remove it.

This is probably the right behavior, and mimics what the current
GnomeDruid frontend does.

BTW, if debconf does not use the page sequencing ability of
GtkAssistant, what’s the point of using it at all? You can just define a
GtkDialog with 3 buttons (GTK_STOCK_GO_BACK, GTK_STOCK_CANCEL and
GTK_STOCK_GO_FORWARD), add whatever handlers you want to these buttons,
and use GtkDialog->run which removes the need from exiting manually from
the main loop.

How does it sound?
--
.''`. Josselin Mouette
: :' :
`. `' “I recommend you to learn English in hope that you in
`- future understand things” -- Jörg Schilling

signature.asc (196 bytes) Download Attachment