Re: GNOME 3 and panel applets
Thanks for starting this effort! Some comments below: On Mon, Feb 14, 2011, Josselin Mouette wrote: Debian GNOME Maintainers pkg-gnome-maintain...@lists.alioth.debian.org deskbar-applet gnome-mag (U) gnome-main-menu (U) gnome-netstatus (U) gnome-utils hamster-applet (U) mousetweaks (U) netspeed (U) ontv (U) seahorse-plugins (U) tsclient vinagre (U) * tsclient got RMed * deskbar-applet and gnome-main-menu are larger bodies of code, but I don't think they are relevant upstream anymore; probably hard to keep alive; RM? * I believe hamster-applet is still in wide use, albeit I don't use it myself; I would hope it gets adapted * vinagre is probably wide use as well. * Most of the others are probably half-relevant; not sure what's widely used in gnome-utils; maybe gnome-mag is helpful for a11y for some people? hard to tell Loic Minier l...@dooz.org computertemp (U) gnome-mag (U) gnome-netstatus (U) gnome-utils (U) netspeed (U) service-discovery-applet (U) tsclient (U) The ones not listed above are not very important in my eyes and are candidates for RM as well Thanks, -- Loïc Minier -- To UNSUBSCRIBE, email to debian-gtk-gnome-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110214184102.gf3...@bee.dooz.org
Re: New libthai and pango
On Mon, Mar 30, 2009, Theppitak Karoonboonyanan wrote: As the shlib dependency is transitive, the pango-thai-lang.so module is currently linked against libdatrie0. So, upgrading libthai would cause both libdatrie versions to be loaded simultaneously, one from pango-thai-lang.so itself, and the other from the new libthai. Unfortunately, due to ABI incompatibility, some libdatrie functions would not work correctly in that case. Why do you expose -ldatrie in pkg-config --libs libthai? It seems to me pango doesn't use any of libdatrie's symbols and would work with either the new or the old libthai (that is would work with whatever version of libdatrie is used by libthai). So, pango would need to be rebuilt against the new libthai-dev to fix the problem. Could you change Requires: datrie to Requires.private: datrie in libthai.pc in unstable first? We could then rebuild pango against this libthai.pc and drop the libdatrie dep hence avoiding the problem and the transition entirely (the binaries could migrate to testing separately). -- Loïc Minier -- To UNSUBSCRIBE, email to debian-gtk-gnome-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: gconftool-2: custom desktop settings
I'll reply to the customize a system to do this parts; to customize the contents of the live CD to apply these changes, you should ask on their mailing-list rather than this one. On Sun, Jan 18, 2009, schoappied wrote: I want to change some settings of the live-cd desktop and I'm wondering how to do it. I've heard you better do it with gconftool. This is what I want: 1) change desktop theme GConf setting; you should use a GConf defaults file to override this; see man update-gconf-defaults. 2) remove icons from the menu You want to remove the programs from the live CD or just hide them? I guess you could hide them either by changing the /etc/ or the ~/ menu files; the former manually, the latter with a menu editor e.g. alacarte. 3) add icons to entries in the menu which don't have an icon ? All entries should have icon, or it's a bug, no? 4) remove the top panel That's a GConf key. 5) add the 'OpenSuse-gnome-menu' to the low panel and some other things like networkmanager, fast user switch etc. You want to add packages. 6) add bookmarks to bookmark menu in iceweasel and also to the bookmark toolbar. 7) add a new search engine to iceweasel Don't know how to do this properly; you could change the shipped bookmarks or install some in ~/. 8) edit the applications preferences (icedove for email for instance) GConf as well. -- Loïc Minier -- To UNSUBSCRIBE, email to debian-gtk-gnome-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian GNOME Policy?
On Wed, Aug 20, 2008, Guido Loupias wrote: I'm currently packaging a panel applet for Debian. I've come across what appears to be a policy for GNOME packages in Debian (through Google), however I can not find this page anywhere on the official Debian site. Am I not searching hard enough? The page is here: http://burtonini.com/computing/gnome-policy-20050123.html Should I follow this policy? It was last updated in 2005. It's really too old to be very useful. I don't think we have been following a very strict policy, but the Debian GNOME group uses a set of tools and relatively homogen packaging habits across the pkg-gnome packages. We're happy to help in specific issues you face, or to start from other packages as templates for yours; we hang on #gnome-debian on GIMPNet, but you can also ask your questions on [EMAIL PROTECTED] If anyone is interested in maintaining a GNOME subpolicy document, I guess he could try collecting information with us. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#451459: New maintainer for update-manager needs help
On Mon, Jun 09, 2008, Thibaut Paumard wrote: I would be grateful if I could be added to the pkg-gnome alioth team, in order to be able to commit directly my work there. done -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: complaints against the GNOME team
On Sat, May 17, 2008, Tshepang Lekhonkhobe wrote: In too many places has it been declared buggy and dead upstream, that rarian should replace it. Do you have more specifics? We don't really have a formal process to propose new features to Debian or Debian GNOME; we only have release goals and DEPs AFAIK, but this is moving. What we currently do is that we rely on individuals to discuss high level features / goals, then implement them by requesting / doing the technical changes. If I were asked now to switch to rarian, I would point at the risk of changing to a new codebase and would ask for some proven benefits. Perhaps you can start building a wiki page documenting: - known new features (could be performance, code quality etc.) - known regressions - known bugs in scrollkeeper which are fixed in rarian This would help convincing people like me; if nothing comes in the way, you could immediately start proposing patches to prefer rarian over scrollkeeper. Bye -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please remove me from uploaders of debiant-gtk-gnome group
On Thu, May 15, 2008, Ondřej Surý wrote: as you may have noticed I didn't do any work in at least last two years in pkg-gnome. Could you please remove me from Uploaders list in cdbs macro and you are free to adopt any of my pkg-gnome packages (in case of core libraries it would be more then welcomed). The current code will only list you as Uploader if you did a recent upload and you're part of the team; I've explicitely removed you from the team in gnome-pkg-tools now, and you'll disappear from the Uploaders progressively with each new upload. For Maintainer: fields, one would have to fix these manually. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: complaints against the GNOME team
On Mon, May 12, 2008, Tshepang Lekhonkhobe wrote: * Sebastien was once declared heroic for frantically packaging and uploading GNOME 2.24 stuff after its release for which I'm also grateful, but then he refrained from uploading Nautilus 2.24 to Sid, choosing instead Experimental. I would really have preferred that she mentioned this on the mailing list and not just the Debian changelog. So what's still holding back Nautilus into entering Sid? I think you mean Sebastian (Dröge) here; we also have a Sébastien (Bacher); in both cases, they are hes, not shes. :) My understanding is that Nautilus isn't included because it's not as feature complete as the previous series; I lack the details, I'll let others provide them. * I'd like to know the team's position regarding PulseAudio, especially given that it's the hottest thing these days regarding FLOSS audio stuff, and that it's been given publicity in other distros. So, what's holding back PulseAudio from being the default? PulseAudio is very cool; I know of many GNOME-ish people in Debian who run it; it's working fine most of the time, but it's not fit for 100% of the users; still, it should probably be the default. I'm not sure where we stand with pulseaudio, what's missing etc., but I saw Sjoerd work on ALSA integration with a new plugin which allows autodetection of pulseaudio. What this means is that any ALSA app will use the ALSA pulseaudio plugin IF pulseaudio is running and regular ALSA otherwise; this allows enabling pulseaudio system-wide and unconditionally for everybody. * I'd like to know why scrollkeeper is still in Debian, if there's still functionality it provides that rarian-compat does not provide. I don't know why you want to replace scrollkeeper; rarian is a rewrite, but its early revisions were not enough to fully replace scrollkeeper. AFAIK, scrollkeeper did its job quite well, albeit very slowly, and rarian being a rewrite had to go through bugs, and was missing documentation for a while. So apart from speed, which is also mostly addressed by triggers which should be added for both rarian and scrollkeeper, I don't know of much motivation to switch to rarian, or to drop scrollkeeper. However nothing should be preventing the use of rarian instead of scrollkeeper anymore. I'm afraid the team isn't good at communication, we do exchange some bits over IRC mainly. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Looking for sponsor for bakery2.4 and libnotifymm
On Tue, Apr 08, 2008, Deng Xiyue wrote: Note I'm a DM, so those packages have been DMUAed. Hope that won't be a problem. (I'm personally ok with that addition to any pkg-gnome-ish package manphiz works on. I'm usually sponsoring manphiz as well as some other people, but we didn't find the time, so if you have time pick it up.) -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug triage weekend?
On Sun, Mar 02, 2008, Marc 'HE' Brockschmidt wrote: It looks like the gnome packages are once again drowning in bugs (examples are control-center, gdm or even gtk+). I thought we should perhaps set a date (like the last weekend in march, or earlier) on which we sit together and sift through these heaps of bugs. Non-maintainers can and should help, while experienced people should stand by to help deciding more complex cases. What do you think? Stating the obvious: GO FOR IT! -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Could libglib1.2ldbl provide libglib1.2 ?
On Thu, Dec 20, 2007, Alessandro Chemini wrote: Hello, I'm not sure this is the right ML for libglib, moreover I may have missed a previous discussion on the topic... The question is: is there any serious reason for libglib1.2ldbl not to transitionally PROVIDE libglib1.2 in lenny? The problem is related to external repositories dependancies (namely debian-multimedia). I think this would be a problem for two reasons: - might prevent moving from one package to the other (if you only have packages depending on libglib1.2 installed, you might not move from libglib1.2 to libglib1.2ldbl on upgrades) - versions in dependencies wouldn't be honored anymore (as versionned provides aren't supported) It would be best for debian-multimedia to do the same transition and update debs for etch / lenny / sid when these dists are updated. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
pre-commit hook checks added
Hi, The pkg-gnome SVN repos will now check that the commit includes a real log messages (it requires at least a letter or digit) and will reject commits touching debian/changelog if the version ends with ubuntuNNN (any number of digits). People in pkg-gnome can fix the pre-commit hook if needs be; it's in /svn/pkg-gnome/hooks/pre-commit on alioth. If you have interesting checks for this pre-commit hook, you're welcome to suggest them; one thing which we could think about is access control: most people only hack on a couple of modules. Cheers, -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Rarian and versionned deps on scrollkeeper
On Wed, Nov 14, 2007, Jerome Warnier wrote: Gnome-terminal has not yet been uploaded without versioned scrollkeeper dependency. Should I submit a bugreport against this? It is the last package which prevents us to install rarian-compat on a system. It was fixed in SVN; I would have liked to prepare an upload right now, but it wont build on i386 (gtk+2.0 missing) nor amd64 (fontconfig missing). -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Failed to close thumbnail pixbuf loader
On Sun, Nov 11, 2007, Gene Z. Ragan wrote: The error is generated by nautilus-thumbnails.c located in libnautilus-private. This is in response to an error from gdk_pixbuf_loader_close(). I don't know why gdk_pixbuf is returning an error though. http://library.gnome.org/devel/gdk-pixbuf/unstable/GdkPixbufLoader.html#gdk-pixbuf-loader-close Reading the GNOME bug report mentionned by the OP, I think this is likely a limitation / bug on what the Gdk pixbuf loader for JPEG wants to do in degradated cases. Perhaps there's a security/safety limit in what the loader will accept, but it would be best to look at the nautilus code to see whether it checks the previous gdk_pixbuf_* calls for errors (such as gdk_pixbuf_loader_write() for example). -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Printer management plans?
On Thu, Sep 27, 2007, Sven Arvidsson wrote: At the moment gnome-cups-manager is used, but it is in need of some serious love. As an example, printing test pages have been broken for quite a while (bug 379510). gnome-cups-manager also haven't had any upstream releases for a long time. Yes, gnome-cups-manager never was stable code and is completely dead upstream. Ubuntu seems to have gone with system-config-printer[0] for Gutsy[1] (it is also already available in Debian). I don't know how the Ubuntu choice was made, but I recall searching how RedHat was doing its printer management and found about their system-config-printer tool; later I recommended Otavio to have a look at it as a replacement for gnome-cups-manager. One of the drawbacks with system-config-printer is that the UI could use some polish, and it exposes some of the more arcane aspects of CUPS, such as classes. On the other hand, it appears to be very actively developed upstream and has been used in Fedora for some time. Yes, it's the default in Fedora and RedHat distros (and derivatives), so it has a large user base. So, is there any interest in using system-config-printer by default for Lenny? Perhaps the Ubuntu folks would have more information on the topic, but I'm really happy that we have a replacement available to us which is more stable and actively maintained. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GTK 2.12 and Pango
On Thu, Sep 27, 2007, Ian Bull wrote: gnome-appearance-properties: symbol lookup error: /usr/lib/libgtk- x11-2.0.so.0: undefined symbol: pango_extents_to_pixels Check or send the output of ldd /usr/lib/libgtk-x11-2.0.so.0; it's likely a local lib on your host. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gnome-panel pixmap usage
On Thu, Sep 20, 2007, Miles Bader wrote: So does anybody have a clue why gnome-panel would be using so much pixmap memory? Does it have known pixmap leaks? Perhaps one of your applet leaks pixmaps; if you graph it over time, or simply compare the values after restarting gnome-panel, you might tell for sure whether it's a leak. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#442403: RFP: vinagre -- VNC Client for the GNOME Desktop
On Sat, Sep 15, 2007, Sven Arvidsson wrote: I made packages of vinagre and it's dependency gtk-vnc for personal use, they are online if you want to try it out. Keep in mind that vinagre requires GTK+ 2.11 from experimental. http://www.whiz.se/temp/vinagre/ http://www.whiz.se/temp/gtk-vnc/ If you like to maintain them in Debian, feel free to push them to pkg-gnome of course! :) -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ubuntu logout dialog patch in Debian [Discuss]
On Wed, Jun 27, 2007, Sebastian Heinlein wrote: I think that it is quite hard to find good metaphors for suspend, hibernate and restart at all. The terms are really very technical. That's true; I've seen attempts at such icons, and these were not easy to use, but it was still more easy to remember that the Zzz icon is for suspend than to read the text each time. Ubuntu simply uses different colors for the power button. Still an improvement IMO. The GNOME dialogs only requires you to scan the buttons horizontally. THe Ubuntu dialog is harder to scan since it also uses the vertical orientation and has got a separated cancel button. (I don't find the Ubuntu dialog harder to use, but YMMV.) Oh, take a look at pm-utils - it makes use of uswsusp and provides good scripts that can be easily extended. They work really great here on my ThinkPad in combination with hal. Thanks; I'm happy for now really, but pm-utils is said to be the long term replacement for acpi-support, so I suppose I will switch to it at some point. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ubuntu logout dialog patch in Debian [Discuss]
On Tue, Jun 26, 2007, Sebastian Heinlein wrote: For the verbosity as Loic mentioned, can adding icons to the buttons help? Icons would make the dialog even wider. Furthermore there are no GNOME or Tango suspend or hibernate icons. The ones from g-p-m won't be very helpful at this size (a small disk and a small memory stick with a could). I think icons would help. Sure, it will take more space -- perhaps not only width -- but at least I wont be forced to read the text of all buttons to decide what I want, plus it will make clicking on the buttons easier. You have a point that a prerequisite for such a change is to have decent icons, but it should only delay the implementation, not influence the long term goal. (FWIW, I don't intend to use the poweroff dialog in the short term anyway since the backlight isn't properly turned on with the underlying suspend call; I'll continue calling my own little s2ram wrapper manually...) -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ubuntu logout dialog patch in Debian [Discuss]
On Mon, Jun 25, 2007, Sebastian Heinlein wrote: The GNOME dialog also queries the power manager: if (panel_power_manager_can_suspend(logout_dialog-priv-power_manager)) gtk_dialog_add_button (GTK_DIALOG (logout_dialog), _(S_uspend), PANEL_LOGOUT_RESPONSE_STR); I certainly don't see a Suspend button in my Close session dialog. My opinion on the patch is that the dialog offers more options than in the stock dialog, and these are useful. I find it more convenient to keybind to this dialog to decide what I want to do than to keybind the invidiual actions. I also find it easier to click on the launcher I have for Close session and then hit huge icons than to go through the tiny menu of gnome-power-manager (plus GPM isn't always displayed). In short, I don't have any strong opinion on the non-HIG-ness of this dialog, but I certainly wish the functionality would be available. Of course, this is an upstream issue and has nothing Debian or Ubuntu specific. Did anyone check how it stands with 2.19.x? -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ubuntu logout dialog patch in Debian [Discuss]
On Mon, Jun 25, 2007, Sebastian Heinlein wrote: I often realize myself searching for the wished option in the Ubuntu dialog. So it pop ups fast but it takes some time for me to locate the right action. The current gnome-panel logout dialog is even worse: I find myself *read* the text each time I have to click in it. At least the Ubuntu dialog is very big and has colors with a shorter text for each button. Ideally the suspend action should be tiggered by the lid close event, so you would not need such an option in most cases. But who can trust his or her laptop that it always suspends correctly :) Haha, *exactly*; I don't trust suspend to work reliably, and it's unlikely to change soon. Also, I sometimes close the lid for lunch where I don't want to suspend (it's also a quick way to leave my place which locks the screen too). -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ubuntu logout dialog patch in Debian [Discuss]
On Mon, Jun 25, 2007, Sven Arvidsson wrote: You need to enable the can suspend and can hibernate options in g-p-m for these options to appear in the logout dialog. I have these set in GConf, and I don't get the buttons in the logout dialog. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ubuntu logout dialog patch in Debian [Discuss]
On Mon, Jun 25, 2007, Sven Arvidsson wrote: Sorry, I meant the shut down dialog. Wow, I'm discovering it; cool. To update my critics: 5 choices, small buttons, no color / icons but text = not very friendly to use I also find it confusing to have: 1) lock screen directly, no dialog 2) close session with 2 choices and cancel 3) shutdown with 4 choices and cancel = sounds not properly balanced and I very much prefer the one stop dialog where I can access all possible actions (except lock screen) -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ubuntu logout dialog patch in Debian [Discuss]
On Wed, Jun 20, 2007, Alan Baghumian wrote: So, If it's possible, send your comments to see if there is a room to put this patch in. One issue is and always will be translations: we have no Debian infrastructure to fixup the *.po files of upstream apps in a more or less industrialized process. We can grab the translations from Ubuntu each time the patch changes though. Do you by chance have the upstream bug where this dialog has been proposed? I wonder what upstream thinks of this patch. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Starting DBus from gnome-session instead of Xsession
On Sun, May 06, 2007, Josselin Mouette wrote: - from the PoV of gdm, there are a couple of GNOME sessions, and the Default session, which will launch x-session-manager which might or might not gnome-session See the gnomerc snippet which already does this detection: BASESTARTUP=`basename $STARTUP | cut -d\ -f1` if [ $BASESTARTUP = gnome-session -o \ \( $BASESTARTUP = x-session-manager -a \ `readlink /etc/alternatives/x-session-manager` = \ /usr/bin/gnome-session \) ]; then blabla fi Yes, I know, this is exactly what the patch I pointed at does ... and it's very fragile. It would also be quite ugly to encode GNOME awareness in dbus stuff. I think there might be better ways to be more robust, cleaner, while still offering more control to the end-user/end-administrator. For example: 1) we could force all GDM sessions to be based on a .desktop file, pass this .desktop file to the whole session via an env var or another convention (~/.gdm-session-$DISPLAY.desktop could be a symlink to this desktop file); options would be encoded in X- fields of this file 2) we could pass various information directly via environment, such as X_SESSION_OPTIONS=nodbus and X_SESSION_TYPE=gnome and use this as a base to decide to parse .gnomerc and to disable dbus (a Xsession.d script would add nodbus to X_SESSION_OPTIONS if X_SESSION_TYPE is gnome) I think both of the above options could be more robust than the current check for the value of STARTUP, while still giving end-user control over what the session should or should not do. - sessions can be started via startx and/or various other ways AFAIK startx also uses Xsession. Yes, startx does, but by various other ways I meant: - .xsession or .Xsession (Xsession.d/* are still read, but STARTUP wont match this) - overrides files of various dms, or session .desktop files - custom manual calls to /etc/X11/Xsession -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Starting DBus from gnome-session instead of Xsession
On Sun, May 06, 2007, Tim Dijkstra wrote: For me it doesn't make sense. DBus aims to be more generic than just for gnome. You didn't make really clear why it should be started from gnome-session instead of during the X start-up. If you try to sneak in extra information into DBus' environment, that could be annoying for people who use an occasional gnome program, but do not use gnome-session. gnome-session is the canonical way to properly start a GNOME session, with a working GNOME stack. If a normal GNOME session needs dbus, then I find it quite normal that gnome-session spawns it instead of relying on the distributor to integrate dbus in the startup before gnome-session. In fact, you can go even farther and say that each individual application needing the session dbus should arrange for it being present, which is the case with recent DBus: but this is already solved by newer DBus which will spawn a session dbus if any app needs to access it. Yes, starting dbus from gnome-session is a broken design, but it will work in more cases than the current way of starting it, and it will more consistent across distributions; I think we would benefit from switching to this startup style. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: shipping a default gtkrc
On Thu, May 03, 2007, Matt Good wrote: Typically when I see someone using an alternate DE they just use the ugly default GTK look. It wont get them Clearlooks installed. In the example of the icon themes, we have dependencies in place already, only the environment needs fixing. :-/ -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: FWD: [Debconf-devel] Bug#422130: cant login into gnome-2.18 in Debian Sid+experimental error in debconf :/etc/bash_completion.d/debconf: line 10: `_debconf-show': not a valid identifier
On Thu, May 03, 2007, Joey Hess wrote: Does someone know why gdm has started doing this with the new gnome? Could be the mistake I made in 2.18.1-1 fixed in -2; please open a bug otherwise. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: shipping a default gtkrc
On Thu, May 03, 2007, Josselin Mouette wrote: As it was recently suggested (sorry, I can't remember by whom), it is possible to ship a default configuration for GTK+ applications in /etc/gtk-2.0/gtkrc, that could look like this: gtk-theme-name = Clearlooks gtk-icon-theme-name = gnome When gtk2-engines and gnome-icon-theme are not installed, these settings will be silently ignored. Otherwise, they will be used by applications run outside a GNOME/XFCE session. They will also be overriden by *-settings-daemon, so this really looks harmless. What makes it useful is: * that GTK+ applications should benefit of a better default look, even when run outside GNOME; * that some GNOME applications, like epiphany and evolution, make assumptions of what icons are available in the default icon theme, enforced by a dependency on gnome-icon-theme, but when they are run outside GNOME, the default icon theme is hicolor and they won't benefit of it. Yes, we received at least a couple of bug reports on the topic, such as #421353. I discussed this with Sébastien which reminded me that this is probably since we dropped a patch which was setting the fallback icon theme in gtk/gtkicontheme.c. However, there's now clean support for fallback-icon-theme as a GtkSetting, except it's empty by default (and the default gtk-icon-theme-name is hicolor); see GNOME #325546. Does anyone oppose to such a change? It's a good workaround to the bugs we receive, but instead of distributing a gtkrc, I preferred patching the default gtk-fallback-icon-theme which a bit better; this avoids touching the gtk-icon-theme-name setting, and shipping a gtkrc. I don't think we need Clearlooks as gtk-theme-name though. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Default Gnome theme
On Mon, Apr 30, 2007, Indraveni wrote: And when I manually tried to execute the update-gconf-defaults command from the shell prompt, it dint show any affect in my themes i.e it dint execute the 20_bossblue file under the /usr/share/gconf/defaults/. I think there is something that I am missing. Files in /usr/share/gconf/defaults/ are compiled into /var/lib/gconf/debian.defaults by update-gconf-defaults; you can double check whether this update happened. /var/lib/gconf/debian.defaults is referenced in the gconf path, see /etc/gconf/2/path. Check whether the GConf settings are in effect with gconf-editor or gconftool from your GNOME session. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting Ideas: About Debian menu item
On Wed, Apr 18, 2007, Alan Baghumian wrote: I wanted to know about adding an About Debian menu item under the system menu. What's your idea? It can launch default web browser to http://www.debian.org/... or open a local page. Sounds like a good idea; you can add these to our gnome-panel, I suppose Ubuntu has a patch to do something similar for About Ubuntu which could be a base. Perhaps debian-l10n-english@ can review the editorial content? -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: shipping a default gtkrc
On Thu, May 03, 2007, Josselin Mouette wrote: It's not needed per se, but it would make things better for users of GTK applications outside GNOME/XFCE. I fear we'll receive bugs on missing dependency on clearlooks and I don't feel it's worth adding the conffile. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Default Gnome theme
On Fri, May 04, 2007, Indraveni wrote: Thankyou for this mail. I double checked the paths which you mentioned about (var/lib/gconf/debian/defaults/%gconf...xml file and in everything I am able to see my modifications getting affected when I installed my newly created debian package. This suggests that the default value would work, probably for new users. But the theme is not getting replaced with my new theme. Even I restarted my system and checked. still the theme remains the same old one which was there before I install my package. Probably this user has a setting taking precedence in his GConf path, such as having already set the value. Check whether it affects a fresh new user, check each element of the GConf path to see where the incorrect value comes from. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ITP: gnome-orca -- Scriptable screen reader
On Mon, Apr 30, 2007, Mario Lang wrote: I also had to retrieve the orig tarball, but now that I've got the hang of this, it feels pretty simple. If you feel like it, you can add gnopernicus and gnome-speech to pkg-gnome (since these are gnome.org modules), so that the team can act as primary fallback if you're VAC. I don't use these modules though, so I don't expect to work on them a lot, but I suppose I would transition them along of the rest of pkg-gnome would anything need to be changed globally. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ITP: gnome-orca -- Scriptable screen reader
(Cc:ing debian-gtk-gnome) On Fri, Apr 27, 2007, Mario Lang wrote: Loïc Minier [EMAIL PROTECTED] writes: I've imported and tagged the unstable version instead; you can commit whatever changes you had on mentors on top of that. @Mario: do you want to continue sponsoring, I need to add you to pkg-gnome as well so that you can tag uploads; do you want to? First of all, sorry for ignoring this issue for so long, but now, time permits me to do more work on GNOME accessibility stuff again, and now that I've looked and seen I already have an alioth account (mlang) that still works, I'd be interested in co-maintaining gnome-orca. Since I will be using orca on a daily basis, I think it would only make sense to have the ability to address problems directly, rather then having to go via the BTS. Could you add me to the alioth users group that is required for orca and give me a very quick primer on how to checkout and behave in the svn managed team appropriately? I am pretty new to the GNOME team per se. I've added you to pkg-gnome so that you can work on gnome-orca; welcome! We should have more documentation on simple rules we follow in pkg-gnome, but the working process is based on quite standard svn-buildpackage usage, in mergeWithUpstream mode. Basically, svn co to retrieve a working copy of the package dir at: svn+ssh://svn.debian.org/svn/pkg-gnome/desktop/unstable/gnome-orca svn-buildpackage to build it, svn-buildpackage --svn-tag-only to tag the committed revision when you've done the final build. Subscribe to the pkg-gnome-maintainers@ list on alioth if you want to get all PTS for all packages, and to -commits for the commits. There are a lot of people on #gnome-debian on GIMPNet (irc.gimp.org) to help with uncommon tasks or to answer questions (me included). If you want to prepare gnome-orca 2.19, you do not need to wait for the API freeze as it doesn't export an API (AFAIK), so you can start by svn cping desktop/unstable/gnome-orca right now to desktop/experimental, but make sure you don't forget to commit fixes to both branches. When the time comes, you will svn mv the experimental branch to unstable. You can use the check-dist makefile to avoid erroneous uploads to unstable of the experimental branch. Good luck, -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New package addidtion policy
On Fri, Apr 20, 2007, Alan Baghumian wrote: Is there a little document/how to for beginners here? We should have one, but for now I think only discussions on this list are available as references. I want to add a new package (ubuntulooks) to the SVN, but I'm totally confused where it should be added? Desktop/ ? Package? or even unstable or experimental folders? You should add it to unstable because you're going to upload it towards unstable; desktop/ is for the official platform + desktop + bindings + admin, anything not part of the official GNOME goes in packages/, even if it's gnome.org. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Graphical bug statistics.
On Thu, Apr 19, 2007, David Martínez Moreno wrote: http://ftp.es.debian.org/~ender/GNOME_bugs/graphs/total.png Thanks, it's great; of course it will become more interesting over time. :) -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Addition of Alan Baghumian to pkg-gnome (alanbach-guest)
[ Cc:ing debian-gtk-gnome to introduce you. ] Hi, Welcome on pkg-gnome, Alan! On Mon, Apr 16, 2007, Alan Baghumian wrote: 1) I like to maintain some packages (You can offer me or I'll suggest), You can either help randomly on pkg-gnome packages by triaging/forwarding/diagnosing bugs, testing patches (perhaps from upstream), committing fixes/patches/changes in the SVN. If unsure about anything, please ask. Or you can adopt some particular packages and act as principal maintainer. The packages up for adoption are basically those with pkg-gnome in the Maintainer field or where the maintainer did not do any of the uploads in the last 6 months. and also package some gnome related packages those are not in Debian yet (Joey Shultz suggested some Ubuntu artwork related packages some months ago). Hmm ok. It's hard to tell which packages should or should not go in pkg-gnome, but I tend to encourage gnome.org stuff or build-dependencies thereof to be added to pkg-gnome, and I tend to discourage other packages from being added, but it varies on a case by case basis. There are already a lot of modules in there, but it's really a nice thing to have similar packages under the same umbrella. 2) I already maintain pkg-parsix project at Alioth, http://svn.debian.org/wsvn/pkg-parsix, You can see a ~full copy of GNOME customized for Parsix GNU/Linux there. I get packages from Debian and apply our specific patches on it and maintain on http://parsix.org/packages/pool/ I'm a bit surprized to discover such a pool of GNOME packages in another alioth project; out of curiosity, what changes do you need to do in these packages and how do you keep in sync? 3) I work with devscripts and build packages over SVN, I think that you are doing the same. Yep. 4) I'm fully familiar with generating patches against packages and related Debian tools (dpatch, cdbs's simple patch system) Fine; there's some quilt too. 5) I've registered to become an official Debian developer: https://nm.debian.org/nmlist.php (Waiting for Application manager) Perfect. 6) I'm a C/C++/PHP programmer too. My favorite library is wxGTK. A C++ and wxGTK = you're disqualified! Hmm, just kidding. The SVN permissions will need a little time to propagate. You can hang on #gnome-debian on GIMPNet for coordination. Bye, -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fixing watch files on SF.Net
On Wed, Apr 18, 2007, Alan Baghumian wrote: As you know, SF.Net has a complicated download mirroring system that simple watch files can not work with it. There is a PHP script that can do the task: http://qa.debian.org/watch/sf.php?project=proj pkgname-([\d.]*).tar.gz It should be used automatically if you use http://sf.net/; as base URL, see the uscan manpage. (It's hardcoded in uscan that sf.net - qa.debian.org/watch/sf.php.) -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's (hopefully not) break unstable
On Wed, Apr 11, 2007, Josselin Mouette wrote: I don't know whether this was discussed somewhere, but unless someone comes up with a good reason not to do so, I intend to start uploading 2.18 stuff to unstable soon. Unstable users have already waited way too long. I started preparing the uploads of platform stuff, mainly pango, gtk, and glib. -- Loïc Minier For subalterns, saying something intelligent is as risky as saying something stupid. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Merging between unstable and experimental; changelog handling
On Mon, Apr 09, 2007, Loïc Minier wrote: The only way I could reconcile everything above is the proposal below: - merge branches, never svn mv them - create a new entry in each dist with all the new merged changes after each merge This did not fly with HE or sjoerd, they both think this is unnatural, so I bow before them and will svn mv stuff around, like we did in the past. -- Loïc Minier For subalterns, saying something intelligent is as risky as saying something stupid. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Merging between unstable and experimental; changelog handling
On Mon, Apr 09, 2007, Marc 'HE' Brockschmidt wrote: Loïc Minier [EMAIL PROTECTED] writes: I don't want changelog entries to be lost as they represent actual uploads; hence, in the past, I've merged changelog entries between experimental and unstable so that all experimental and unstable uploads appear in the changelog of the latest version; this is sometimes weird as it can shows two versions doing the same set of changes when we did them separately. Which I think is a problem. I believe that changelog entries should only be merged when the related chages were merged. There is seldom more development on a stable (ie, uploaded to unstable) branch of a package than on the experimental version, so I think a useful way to handle this problem is to merge all changes made to the unstable version into the experimental version (and include the fitting changelog entries). If a package is moved from experimental to unstable, it should be done with svn mv [1]. So you want to keep experimental uploads in the unstable changelog? Or do we edit the changelog after the svn mv to create a new unstable version? I firmly believe that the changelog should only reflect development done on the branch that is actually uploaded, and not contain what was done to other branches. Remember, we do non-linear development, but changelogs only provide a linear way to represent changes, so we should document the actual line of development in the changelog of the package that we are uploading. Sure, how does the proposal I made contradict the above? -- Loïc Minier For subalterns, saying something intelligent is as risky as saying something stupid. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Merging between unstable and experimental; changelog handling
On Tue, Apr 10, 2007, Marc 'HE' Brockschmidt wrote: Merging unstable changelog entries that were relevant to a version that is not the base of the current version contradicts that. I think you refer here to the second paragraph of my mail, which says in the past; I don't think I suggest doing so in the proposal starting below the proposal below. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Merging between unstable and experimental; changelog handling
Hi, I had plenty of different discussions on the handling of merges and changelog entries on IRC with various people, so I want to discuss and/or propose the way which seems the most logical to me. Ultimately, this should end up documented on the pkg-gnome web pages when someone finds enough motivation to. :-P I don't want changelog entries to be lost as they represent actual uploads; hence, in the past, I've merged changelog entries between experimental and unstable so that all experimental and unstable uploads appear in the changelog of the latest version; this is sometimes weird as it can shows two versions doing the same set of changes when we did them separately. So merging full changelog entries between dists seems bad. But wouldn't we merge changelogs, and declare an experimental branch as to be uploaded for unstable (svn rm unstable/source svn mv experimental/source unstable), we would erase any history in the changelog which wouldn't have been merged before this. Some people also told me that the experimental changelog entries are just technical details which shouldn't be displayed to the consumers of changelogs in unstable. The only way I could reconcile everything above is the proposal below: - merge branches, never svn mv them - create a new entry in each dist with all the new merged changes after each merge Here's an example: unstable/: foo (2.14-2) dist=unstable * change 2 -- foo (2.14-1) dist=unstable * change 1 -- experimental/: foo (2.18-1) dist=experimental * new upstream -- foo (2.16-2) dist=experimental * change 2 -- foo (2.16-1) dist=experimental * new upstream -- foo (2.14-1) dist=unstable * change 1 -- = we decide to upload 2.18: 1) svn merge the experimental branch into unstable from the date of the branching (after 2.14-1) up to the latest version, this includes superfluous changes 2) resolve conflicts and resolve changelog conflicts by creating a new entry: unstable/: foo (2.18-2) dist=unstable * new upstream * new upstream -- foo (2.14-2) dist=unstable * change 2 -- foo (2.14-1) dist=unstable * change 1 -- = we update 2.18 unstable/ foo (2.18.2-1) dist=unstable * new stable upstream -- foo (2.18-2) dist=unstable * new upstream * new upstream -- foo (2.14-2) dist=unstable * change 2 -- foo (2.14-1) dist=unstable * change 1 -- = we decide to prepare 2.19 1) svn merge the unstable branch from the date of the merge up to the latest version 2) resolve conflicts and resolve changelog conflicts by creating a new entry: experimental/: foo (2.19-1) dist=experimental * new stable upstream * new development upstream -- foo (2.18-1) dist=experimental * new upstream -- foo (2.18-1) dist=experimental * new upstream -- foo (2.16-2) dist=experimental * change 2 -- foo (2.16-1) dist=experimental * new upstream -- foo (2.14-1) dist=unstable * change 1 -- I expect this to be painful, but I satisfies the two constraints to not lose changelog entries nor have superfluous changelog entries. What do you think? Bye, -- Loïc Minier For subalterns, saying something intelligent is as risky as saying something stupid. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
GNOME Documentation for Debian
Hi, Vincent Untz (at gnome.org) asked me whether some Debian folks are currently working on end-user documentation for Debian's GNOME. He would like everybody to join forces upstream for the benefit of all. Could people already working on this topic or interested in doing so contact me and/or Vincent? Thanks! -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Shorten your Uploaders field today; keep it slim tomorrow
Hey, Marc 'HE' Brockschmidt poked the issue of the very long Uploaders field once again and came back with a nice new Uploaders field generator: instead of listing all members of the GNOME team in Uploaders, the last 10 uploads of the package are filtered to only keep members from the team and remove the maintainer. This should slim the field considerably and give it some stability, so don't be surprized if you get a readable Uploaders field in your diff! As an added bonus, packages having custom rules to generate control out of control.in may now set DISABLE_UPDATE_UPLOADERS before including uploaders.mk, and this should disable its clean:: target. This requires build-depending on gnome-pkg-tools 0.11. Bye, -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
pkg-gnome-commits list setup
Hi, I noticed that a pkg-gnome-commits list mailing-list was setup on alioth since forever, but with nothing going to it; so I've setup svnmailer to send all commits mails to this list as well starting today. Bye, -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts for the GStreamer profiles transition
On Wed, Mar 21, 2007, Loïc Minier wrote: - Rhythmbox 0.9.7 and Totem 2.17.5 should start suggesting/recommending gnome-control-center instead of gnome-media and should conflict with gnome-control-center 2.15.90 (Done.) -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Call for testers for sarge - etch upgrades of GNOME
Hi, Javier Fernández-Sanguino Peña agreed that it would nice to get some feedback from testers on sarge - etch GNOME upgrades. The more testers, the more different use cases we will have covered! If you find a particular bug and/or workaround, either mail the solution to Javier Fernández-Sanguino Peña [EMAIL PROTECTED] and this list, or simply file a bug mentionning this is an upgrade issue from sarge. The goal is to cover as many different configuration as possible and document frequent issues in our release notes. Perhaps there's even a little time to fix some. Especially problems with changed default settings might be worth looking into, such as the default GStreamer audio and video sinks which changed between sarge and etch. Thanks! -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Conflicts for the GStreamer profiles transition
Hi, Recent GStreamer packages have introduced the concept of profiles; a profile is an index set on pipelines to chose the appropriate configuration from various configs. [1] Applications have started only recently to use the new feature; Rhythmbox 0.9.7 added such a support, Totem 2.17.5 as well. This is problematic because of the associated user interface to change these settings. Previously, configuration of the default audiosink was achieved with gstreamer-properties, in the gnome-media package, which shows in the GNOME preferences. However this program was not updated to support the new profiles, instead gnome-sound-properties permits setting them since control-center 2.15.90 (I think). Additionally, in gnome-media 2.18.0 gstreamer-properties is hidden from the preferences. So, I propose adding protections against mixing of older control-center with profile-aware applications and another one to ensure people always have one way to configure GStreamer in their menus. Since multimedia applications do not use Depends on the capplet, but only Recommends or Suggests, I propose we add Conflicts as follows: - Rhythmbox 0.9.7 and Totem 2.17.5 should start suggesting/recommending gnome-control-center instead of gnome-media and should conflict with gnome-control-center 2.15.90 - gnome-media 2.18 could conflict with control-center 2.15.90 to ensure there's at least a GStreamer user interface Of course, other applications as only Rhythmbox and Totem are affected, but I don't know them all. I think we could start with the gnome-media rdeps which use GStreamer; from this list: bee% apt-cache rdepends gnome-media | grep '^ ' | sort -u education-desktop-gnome gnome-applets gnome-desktop-environment gnome-media-common gnome-volume-manager goobox libgnome-media0 libgnome-media-dev libgstreamer-gconf0.8-0 magicdev bee% apt-cache rdepends libgnome-media0 | grep '^ ' | sort -u gnome-media libgnome-media-dev python-gnome2-desktop rhythmbox sound-juicer I'd say goobox, magicdev, and python-gnome2-desktop are worth a look. Perhaps some programs started to recommend gnome-control-center already? I'm not sure about the gnome-media - gnome-cc conflict; it's not very likely to mix 2.14 and 2.18 stuff. Thoughts? Anyone wanting to do some of these (cool!) checks? Bye, [1] This was added to the gconfaudiosink element in gst-plugins-good 0.10.2, you can check GNOME #329107 for the implementation details. http://bugzilla.gnome.org/show_bug.cgi?id=329107 -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: OT: GNOME development on Debian?
On Tue, Mar 20, 2007, Jean-Christophe Dubacq wrote: It means that gnome 2.16 was installable only for a few days. Hopefully, I got it ! There's an etch backport of 2.16 which will remain installable, and some 2.16 packages have been tagged as such in our SVN (but not all I'm afraid); beside everything 2.16 except epi + epi 2.18 is still installable. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: pkg-gnome SVN layout
On Wed, Mar 14, 2007, Josselin Mouette wrote: I see two reasons to have a trunk: - we currently have no defined merge process, so we commit some changes in unstable and other changes in experimental; we then have to guess how to merge the branches together: merge from unstable to experimental, or the other way around, or both ways... This is suboptimal and risky. We'll still have to merge things from the trunk to the other branches. What exactly would it bring? Not only would it be clear in which way you have to do the merge -- and hence more scriptable -- but also the responsability of the merge would IMO be clearer. Of course, as Sjoerd reminded us, we should document the process better, but currently we all commit stuff in whatever branch we're doing an upload, but we do not always merge to the other branches. In the case of a trunk, it would be clear that each packaging change which is not specific to a dist should be made or merged in trunk, and dist specific changes would only be done in the dist branch, not in trunk. It makes it clearer which changes are specific to a dist or not, and it encourages making this distinction at the time the change is made ... instead of scratching one's head at the time of the merge. - we have no place to prepare the latest upstream development releases, experimental only allows for one more GNOME series which is currently GNOME 2.16 This, I disagree with. We have experimental for that purpose. We should not make the current situation (experimental as a staging area for already stable upstream packages) the norm. Unfortunately, with our current release strategy, there will always be a problem between a 6 months upstream version freeze in Debian and a 6 months release cycle upstream. Also, we have no place to prepare packages of development versions which we do not want to publish to everybody. I think we need a place to prepare the latest available tarballs -- and perhaps upload these to a private archive, such as on alioth -- to be ready to do massive uploads of a new GNOME release. This can also serve to confirm a bug has been fixed upstream or to test development releases of GNOME before uploading them to an official archive (even if it's experimental). I agree it would be nice to have, but without some automation it won't be as helpful. We already often forget to commit what we upload or to upload what we commit. If there is one more step, we're likely to forget it even more often, or, like it happened when branching for the last stable, to tag the wrong version. svn-buildpackage supposedly has such support; I'm not too happy with it (#414564), but once fixed it should be good enough. Layout (3) is more elegant, but I agree that for everyday use layout (1) is the simplest. What do you think of layout 2 which is somewhat between 1 and 3 in terms of hashing? It's sjoerd's and my preferred one, and close to the current one (the name are a bit more explicit in my example than in the current repository, with official = admin + bindings + desktop + devtools + platform). Especially the concept of extra is used in a lot of teams. -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: pkg-gnome SVN layout
On Thu, Mar 15, 2007, Josselin Mouette wrote: I've always considered the latest version this way, and was hoping other people were doing the same. If you believe changing the name to trunk can help that, then let it be, but it's a bit annoying to see a name change - which will mess up the whole history of the repository - for such a frivolous reason. Admittedly, it will help us in the future to always keep the correct history in the trunk. Well, I sometimes worked on unstable/ for urgent fixes, and had to merge later. This also means the commits are compressed into a single one. :-/ You should also consider that, without a clear separation between experimental and unstable, we lose the view of which packages have been uploaded to which archive. Of course, there are some web summaries, but they don't give such a clear view when actually working on the packages. I'm not sure what you mean here; we would still have unstable/ and experimental/. This, I disagree with. We have experimental for that purpose. We should not make the current situation (experimental as a staging area for already stable upstream packages) the norm. Unfortunately, with our current release strategy, there will always be a problem between a 6 months upstream version freeze in Debian and a 6 months release cycle upstream. More and more voices are asking for a more aggressive release strategy. I'd like to know how the lenny release will be handled before making such decisions. Yes, but since we're Debian, this is not going to happen overnight; let's stop limiting ourselves. :-) Furthermore, there's little point in building packages if no one uses them. I'm sure you see/saw the pressure for 2.16, and the 2.18 pressure is already there (well, it's on the IRC chan and someone filed a bug against evolution to get 2.10). People want the latest crap! :) -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GNOME 2.16 backport for etch
On Thu, Mar 15, 2007, Norbert Tretkowski wrote: I've read about plans on a 'semi-official' GNOME 2.16 backport for etch. What's the status here? I have some spare time during the next two weeks and thought about creating a GNOME 2.16 backport for etch during that time. You're welcome to use our an etch-backport in our SVN if that helps you; I've started tagging the 2.16 modules (except a11y stuff) that I've switched to 2.18 to keep a ref to the 2.16 version. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GNOME 2.16 in Experimental
On Wed, Mar 14, 2007, Xavier Bestel wrote: Yess !! You made it, today is the first day of gnome 2.16 on debian :) aptitude -t experimental install gnome worked perfectly. I confirm, I just did a full sid - experimental upgrade of the GNOME packages (well, anything pulled by gnome-desktop-environment 2.16), and it went nicely. -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GNOME 2.16 in Experimental
On Tue, Mar 13, 2007, Xavier Bestel wrote: Apparently libeel's situation is a mess. Nautilus is depending on libeel2-2 (not libeel2-2.16), which depends on the very same libeel2- data than the others, but of course = 2.16. Yeah; that was to be expected by the package name change; I don't feel like requesting bin NMUs for experimental as the release managers are overworked, and I don't feel like doing a binary rebuild of nautilus and others. This should fix itself with the next nautilus upload. -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GNOME 2.16 in Experimental
On Tue, Mar 13, 2007, Xavier Bestel wrote: Ok. Back to hibernation mode then, patiently waiting for an installable gnome 2.16. Haha, never mind, I've uploaded nautilus 2.16.3-5 for i386 and made it autobuildable! (I thought it already was and the buildd was slacking.) And you thought you could take some rest. -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GNOME 2.16 in Experimental
On Mon, Mar 12, 2007, Xavier Bestel wrote: - Some experimental packages depend on libeel2-2.14 which downgrades libeel2-data to 2.14, which downgrades some other packages to 2.14. libeel2-2.16 is missing in experimental for i386, the rdeps might need rebuild against libeel2-2.16. This is painful, so I'm not making this top priority, but I've uploaded a relaxed libeel2-2.16 which will install with libeel2-data 2.14. Made the package autobuildable as well. - gnome-desktop-environment depends on sound-juicer (= 2.16.2) (latest version avalable is 2.16.1). Missing on i386; I've uploaded 2.16.3 for i386 instead. Made the package autobuildable as well. - gnome-panel 2.16 isn't there (but gnome-panel-data is). Missing on i386; I've uploaded 2.16.3 for i386 instead. Made the package autobuildable as well. (You can find the packages in incoming.d.o.) Thanks for reporting these, you're welcome to report more problems. -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Discussion on tags/, backpors, G2.16 branch (Was: pkg-gnome SVN layout)
/ should be top-level or per package-type dir? (especially given that some packages get promoted to official status or get deprecated) 11:48 @lool (thanks for commenting!) 11:48 sjoerd np :) 11:49 sjoerd I wouldn't be against tagging everything.. Although people tend to forget it, but that's true for hashing it 2.16 too ofcourse 11:50 sjoerd you mean tags/official tags/extras etc ? 11:50 sjoerd Dunno, that's a hard one 11:50 @lool sjoerd: Actually, I thought we could have a top-level tags/$source/$version 11:50 @lool It also makes it easier not to checkout it 11:50 sjoerd I'd guess that per package type makes sense, as at the time it was tagged it had a certain tatus 11:50 @lool s/not to checkout it/to not checkout it 11:50 sjoerd $source being ? the source package 11:51 @lool yes 11:51 sjoerd right, so the choice is between that and tags/$package_type/$source/$version right ? 11:52 @lool a) pkg-gnome/tags/$source/$version b) pkg-gnome/$type/tags/$source c) pkg-gnome/tags/$package_type/$source/$version 11:53 @lool (All versions proposed so far) 11:53 @lool I prefer a), and I prefer anything top-level; it's less complex 11:54 sjoerd i'd say either a or b, don't have strong opinion any way 11:55 @lool Ok, I really prefer a), I think it will be simpler 11:55 sjoerd k 11:55 @lool sjoerd: May I send the above log to dgg? 11:55 sjoerd sure -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GNOME 2.16 in Experimental
On Mon, Mar 12, 2007, Xavier Bestel wrote: I don't know if it's on topic, because it's not pulled by gnome (well, it's part of the fifth toe), but gthumb needs libcairo2 (= 1.3.12) which is still at 1.2.6. This is a mistake of the maintainer, especially since it doesn't build-depend on libcairo at all; as gthumb is not maintained by the GNOME team, I suppose it would be best if you could file a bug report against this version of gthumb. -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
pkg-gnome SVN layout
Hi, I would like to switch the SVN repository to a new layout. The most important change I I would like to do is to introduce a trunk/ branch. Its role would be to centralize all packaging fixes and track the newest packaged upstream release. While we're at it, it's a good occasion to revisit some other things: - usage of tags/, and perhaps even a real branches/ dir - package splitting criteria Currently the structure is as follows: pkg-gnome |-- desktop | |-- experimental | |-- sarge | `-- unstable |-- packages | |-- experimental | |-- sarge | `-- unstable |-- tools | |-- debian-comparator | |-- gnome-pkg-tools | `-- pbuilder `-- www (I think www, not being a package, doesn't need any change.) I see two reasons to have a trunk: - we currently have no defined merge process, so we commit some changes in unstable and other changes in experimental; we then have to guess how to merge the branches together: merge from unstable to experimental, or the other way around, or both ways... This is suboptimal and risky. - we have no place to prepare the latest upstream development releases, experimental only allows for one more GNOME series which is currently GNOME 2.16 Hence, I propose we switch to a layout with a trunk/ along the branches, it could look like: . |-- experimental |-- sarge |-- trunk `-- unstable Using tags/ could be a nice addition as we currently don't have an easy way to retrieve the debian/ of a package. I understand it adds a burden; I'm fine with or without, please voice your preference. It's also classical to have a branches/ dir, so we could switch to a more traditional structure like: . |-- branches | |-- experimental | |-- sarge | `-- unstable |-- tags `-- trunk My personal preference goes to not having a branches/ dir. Finally, there is the question of the package types that we host under pkg-gnome. I think there are mainly three types: - GNOME official packages - random GNOME-ish officious packages (either from gnome.org or from other sources) - Debian packaging specific packages I personally find the difference important, but I don't need to have them split in various dirs. So, we could either: - use a flat structure, let's call it layout 1: . |-- devhelp |-- gksu |-- glib2.0 |-- gnome-pkg-tools |-- nautilus |-- pessulus |-- pygtk `-- rhythmbox - use the current official/unofficial/debian split, layout 2: . |-- extra | |-- gksu | `-- rhythmbox |-- official | |-- devhelp | |-- glib2.0 | |-- nautilus | |-- pessulus | `-- pygtk `-- debian-specific `-- gnome-pkg-tools - split even more by GNOME sections, layout 3: . |-- admin | `-- pessulus |-- bindings | `-- python | `-- pygtk |-- debian-specific | `-- gnome-pkg-tools |-- desktop | `-- nautilus |-- devtools | `-- devhelp |-- extra | |-- gksu | `-- rhythmbox `-- platform `-- glib2.0 My personal preference goes to a layout similar to the current one (2), or a flat layout (1) as I think modules move between sections, or gain / lose official status, and also to make merge URLs a bit simpler to type. So, I would like to hear: - what other people think of the addition of the trunk - whether we should use tags and perhaps even branches - which package splitting criteria we should use (There might some details to discuss afterwards, such as whether to have branches at the top-level, or per-package, or per-package type.) Bye, -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Handling of libvte / vte-common and package name change
On Thu, Mar 08, 2007, Marc 'HE' Brockschmidt wrote: Something is weird with i386, I still need to work out why auto-building of gnome-terminal failed. I did an i386 upload after my message, but I don't know whether this is connected to your build failure. The source changes I did were to bump the libgnomeui-dev requirement to get a version compatible with gtk 2.10, and I moved the gtk-dev build-dep before libgnomeui-dev. -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Handling of libvte / vte-common and package name change
On Mon, Mar 05, 2007, Xavier Bestel wrote: Now there are still packages that are stuck to 2.14 (e.g. gnome-terminal because it mismatches with gnome-terminal-data), so gnome is still 2.14 only. The rest is due to problems with autobuilding the GNOME stuff or lack of autobuilder, the state of gnome-terminal is: bee% rmadison gnome-terminal gnome-terminal | 2.16.1-1 | experimental | i386 gnome-terminal | 2.16.1-3 | experimental | source, amd64 For gnome-terminal, I've uploaded a package with relaxed deps so that you can combine any new 2.16.x gnome-terminal with any 2.16.x gnome-terminal-data and I've kludged it to be autobuildable. (2.16.1-4) -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Handling of libvte / vte-common and package name change
On Mon, Mar 05, 2007, Xavier Bestel wrote: On Thu, 2007-03-01 at 11:34 +0100, Loïc Minier wrote: I will upload a package dropping the versionning of the libvte-common dependency altogether Any ETA ? Uploaded the first of March, as planned: http://packages.qa.debian.org/v/vte/news/20070301T113202Z.html -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GNOME 2.16 in Experimental
On Thu, Mar 01, 2007, Evandro Fernandes Giovanini wrote: That could be fixed by shipping a /etc/gtk-2.0/gtkrc in the GTK+ package, with the following line: gtk-theme-name = Clearlooks This is a bad idea; the Gtk package is not used only in GNOME, and I don't want the Gtk package to start pulling gtk2-engines to work properly, even if it's nicer than the default theme. -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GNOME 2.16 in Experimental
On Fri, Mar 02, 2007, Josselin Mouette wrote: We could ship this file in the gtk2-engines package. I don't like gtk2-engines carrying configuration for gtk2 either. :-/ -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: gnome-dbg
On Thu, Mar 01, 2007, Josselin Mouette wrote: I don't see anything futuristic here. See bug#407701 for a generic way to achieve this. My idea was then to write a nautilus extension to look up for a package able to read a given MIME type, and to spawn synaptic to install it. What I meant with generic / futuristic was something like a library wrapping requests for feature to packages and perhaps offering UI to spawn the package manager as well. What you did in #407701 could be /repeated/ for other problems of course. On a related note, your solution does not work for packages hosted in disabled / not listed APT repositories; I think the Ubuntu spec goes further than that and ship the actual mappings to offer access to codecs in non-default repositories (multiverse) and commercial repositories; well, from what I understood of it at least. Isn't the Ubuntu thing sending the dumps to their own servers, so that they can be matched to debugging information? If so, I think this is unacceptable wrt. user privacy. Hmm, I don't think so either; I understood that it's just like sending an attached core dump in your bug report. -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GNOME 2.16 in Experimental
On Thu, Jan 25, 2007, Xavier Bestel wrote: Would it be possible for people having compiled them themselves to NMU the packages ? It's ok (and welcome!) to bin NMU the packages if you're pulling the real minimal from experimental as needed for the package. Please do not upload bin NMUs if you're unsure about this as it caused issues with some packages. If it builds with the pbuilder-satisfydepends-experimental, it should be ok, but not all packages build in this way unfortunately. -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GNOME 2.16 in Experimental
On Thu, Mar 01, 2007, Xavier Bestel wrote: There's still an issue with libvte, which makes several packages uninstallable. Yes, ISTR you raised the point BTW: thanks! The discussion on the exact resolution is a separate thread, but FYI I plan to upload the ugly but working solution of not versionning the dep at all (so any libvte-common would be ok). -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Handling of libvte / vte-common and package name change
I'm afraid I didn't receive much feedback on this, and while I know the most complete solution involves patching both the textdomain name and the path to the termcap files, I prefer keeping my hands out of this. I will upload a package dropping the versionning of the libvte-common dependency altogether; this decision is based on two technical facts which I didn't have when I started the discussion: 1) only the translations not matching the templates will break, this won't cause any buffer overflow or format string problems as gettext won't replace the text if the templates don't match; so no risk of breakage due to translations, but some translations will be out of date and new or old text might be displayed in english 2) the termcap files did not change since 2002; these are deeply frozen, beside I couldn't figure a scenario where termcap files would be changed incompatibly; termcap files are supposedly copied in a lot of ways and may even live outside of the vte package, so IMO vte has to keep compatibility with previously published termcap files I know this isn't perfect, but it will save us patch work, and I'm quite sure we would forget to patch new bindgettextdomain() calls between new upstream releases, or references to the termcap files as we don't have a per-source new upstream release procedure to follow. This will permit installing unstable's libvte + libvte-common aside of experimental's libvte. -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: gnome-dbg
Hi, On Thu, Mar 01, 2007, Josselin Mouette wrote: 1. Making bug-buddy downloading them automatically when needed; this needs to integrate a lot of intelligence in bug-buddy itself, as it would have to know which packages to download to generate a useful backtrace. The user would also need to wait for the download to complete. I don't know how complex it is to achieve this, I suppose there are some examples in other apps such as time-admin in ways to spwan the package manager to install stuff and how to test for installed stuff? For me, this opens a more general question about what we want bug-buddy to be for us: do we want to interface it to the Debian BTS or to send the report upstream? Do we need a gateway where we could filter bug-buddy reports from the Debian bug-buddy? Another thing I have in mind is that we need some more formal package installation service; I'm not sure of the progress of the Ubuntu folks on the codec issue: they are working on a way to pull/suggest *.debs which are useful to decode certain formats. The bug-buddy problem sounds a similar type of problem: when faced to a situation where some additional packages would be useful, locate the appropriate packages and suggest/install them. I don't think their current solution is generic in this regard though. (I know this is kind of futuristic, but I thought I would share it nevertheless.) 2. Making the gnome-desktop-environment metapackage recommend gnome-dbg, and gnome depend on it, but only in the development cycle, not in stable releases. Sounds good. I'm not sure whether your position changed on *.ddeb debug packages; that would also be helpful IMO. I didn't try the SIGSEGV kernel handler that I think is nowadays in use in Ubuntu, but from what I've heard it gives good results in matching the installed packages with debug packages and producing useful backtraces. This is certainly harder a project to achieve in Debian than in Ubuntu, but I don't see what we would have to lose with such a feature; I certainly see we would get debug symbols for programs, and not only for libraries like we mostly have now. Cheers, -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411508: ITP: liboobs -- GObject based interface to system-tools-backends
Package: wnpp Severity: wishlist Owner: Loic Minier [EMAIL PROTECTED] * Package name: liboobs Version : 2.17.91 Upstream Author : Carlos Garnacho Parro [EMAIL PROTECTED] * URL : No homepage; tarballs available from http://ftp.gnome.org/pub/GNOME/sources/liboobs/ * License : GPL Programming Lang: C Description : GObject based interface to system-tools-backends Liboobs is a lightweight library that provides a GObject based interface to system-tools-backends. It's completely abstracted of the communication and authentication details, making it easy for applications to integrate with the system details. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.20-1-686 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- Loïc Minier [EMAIL PROTECTED]
Handling of libvte / vte-common and package name change
Hi, libvte9 and libvte4 are not parallel installable due to the versionning of the vte-common dependency. vte-common carries: - locale data - a termcap file I've discussed options on debian-devel@ for handling locale data, but not the problem of the termcap file. When I first considered libvte-common, I thought we should simply drop the package, and either: 1) rename the /usr/share/locale/*/vte.mo into /usr/share/locale/*/libvte$soname.mo and ship these in libvte$soname.mo 2) or keep the */vte.mo files, but add replaces (2) permits co-installability, but there might be missing translations) While a patch for 1) would not be too hard (basically patch bindtextdomain() and perhaps dgettext() calls to use a name passed via CFLAGS instead of PACKAGE), patching the path to the termcap file might be more complex / intrusive. Also, while there is no risk in using Replace for the translations, there might be some risk in doing the same for the termcap file. So, what do people think of the best way to handle the termcap path? Is it used in other sources than vte? My position is currently that it would be safer to patch the termcap *DATADIR* than the termcap file itself, for example using /usr/share/libvte$soname/termcap/xterm (and not using /usr/share/vte/termcap/xterm-$soname), but I wonder whether we should provide some backward-compatibility symlinks (perhaps via alternatives?) for the old pathname. Bye, -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411029: ITP: libgnomekbd -- GNOME library to manage keyboard configuration
Package: wnpp Severity: wishlist Owner: Loic Minier [EMAIL PROTECTED] * Package name: libgnomekbd Version : 2.17.2 Upstream Author : Sergey V. Udaltsov [EMAIL PROTECTED] * URL : No homepage, tarballs available from: http://ftp.gnome.org/pub/gnome/sources/libgnomekbd/ * License : Looks mostly LGPL Programming Lang: C Description : GNOME library to manage keyboard configuration libgnomekbd offers an API to manage the keyboard in GNOME applications. libgnomekbdui offers an API to display a graphical user interface for libgnomekbd operations. gkbd-capplet offers an applet embeddable in GNOME Panel for libgnomekbd operations. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.20-1-686 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- Loïc Minier [EMAIL PROTECTED]
Bug#410881: ITP: jhbuild -- flexible build script for package collections
Package: wnpp Severity: wishlist Owner: Loic Minier [EMAIL PROTECTED] * Package name: jhbuild Version : SVN r1372 Upstream Author : James Henstridge and others * URL : http://www.jamesh.id.au/software/jhbuild/ * License : Mostly GPL, some bits under MIT and BSD-style licenses Programming Lang: Python Description : flexible build script for package collections Jhbuild is a program that can be used to pull a number of modules from CVS, Subversion, Bazaar and other types of repositories or from tarballs and build them in the correct order. Unlike some build scripts, jhbuild lets you specify what modules you want built and it will then go and build those modules plus dependencies. . Although jhbuild was originally developed to build GNOME, it is now able to build a number of the modules in freedesktop.org's CVS. Extending it to handle new modules is usually trivial assuming the build infrastructure matches the other modules it handles. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.20-1-686 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- Loïc Minier [EMAIL PROTECTED]
Bug#408604: ITP: gnome-vfs-obexftp -- GnomeVFS module for OBEX FTP
Package: wnpp Severity: wishlist Owner: Loic Minier [EMAIL PROTECTED] * Package name: gnome-vfs-obexftp Version : 0.2 Upstream Author : Name [EMAIL PROTECTED] * URL : N/A * License : LGPL Programming Lang: C Description : GNOME VFS module for OBEX FTP GNOME VFS is the GNOME Virtual File System. GNOME VFS abstracts various operations on files and directories over a collection of backends. . OBEX is the OBject EXchange protocol. OBEX enables transfer of binary files over Bluetooth or IrDA (infrared) links. . This package contains a GNOME VFS backend to access remote files over OBEX FTP, for example mobile phones or personal digital assistants. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-686 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- Loïc Minier [EMAIL PROTECTED]
Re: Erroneous upload of gnome-vfs2 2.16 to unstable
On Tue, Jan 23, 2007, Jerome Warnier wrote: Now, GNOME-VFS from experimental (2.16) is particularly difficult to get. Just wanted to point this out, doesn't need a quick fix for me. I've just uploaded 1:2.16.3-4 to experimental. HTH, -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Erroneous upload of gnome-vfs2 2.16 to unstable
On Sun, Jan 21, 2007, Loïc Minier wrote: I suppose I should work on introducing simple debian/rules checks in our experimental branch to fail when the target dist is unstable. I've added a Makefile implementing such checks in gnome-pkg-tools 0.10 and added the relevant build-deps and checks in experimental modules. (The build-dep bump was not strictly needed as the include could have been made optional (-include ...), but I felt safer bumping it in case of pbuilder builds with an out of date gnome-pkg-tools and with svn-dont-clean (or without sbp).) -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bugs in default GNOME etch?
On Thu, Jan 18, 2007, Manoj Srivastava wrote: Because as a Debian maintainer of gnome programs that work even when you are not using gnome, you are not just supporting people who use gnome, you are supporting _all_ Debian users. Yes, but if 90% of the users of these packages do not use the Debian menu it gets lower priority than the other tasks. Beside, my remark is taken out of context: it was not meant to imply we should drop the Debian menu altogether as you imply, but as a criticism of the current technical problems of the Debian menu which makes it a maintenance burden. -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bugs in default GNOME etch?
Hi, On Tue, Jan 16, 2007, Luca Capello wrote: first of all, I posted to d-d because I think the problem is not restricted to GNOME, but if I'm wrong, please continue this discussion to debian-gtk-gnome (which I cc:ed) and cc: me please (not needed for d-d, I read it). Indeed, not only GNOME is concerned, but bug reports are often reassigned when needs be, so next time you discover some issues you may want to fill them directly as you discover them in the BTS. However, there's some room for discussion for the class of bugs you are reporting here. 1) some entries in the Debian menu lack the icon 2) the Debian menu requires xpm icons [2] and in fact only 4 packages have icons in the png format (ekiga, evince, gimp, gnomemeeting), but for some packages the xpm icon is really bad 3) there are different icons for the same entry in the GNOME Applications list and the Debian menu These issues are connected; what you describe is a general problem I have with the Debian menu: its XPM requirement and its duplication of the menu entries makes it a maintenance burden. I can imagine technical solutions to these problems, such as a) making XPM optional and automatically generating it when it's not available (yes, this might result in an ugly icon in some cases, but at least we will have an ugly icon vaguely ressembling the icon, and it might also result in nicer icons for PNG capable menu displays), b) using the .desktop files upstream provides to automatically register entries in the Debian menu (Note that the inverse process exists in menu-xdg :). Without this, Debian menu support in Debian packages will always lag behind as upstream updates its .desktop files, icons etc. or adds/remove programs. Another personal problem I have with the Debian menu is that it's slightly cluttered with entries useless to me, and it's also of no use along of the GNOME menu under GNOME. This doesn't motivate me (and I expect other people) to fix it. So, basically, I think Debian menu support for GNOME apps is very low priority, and would have deeper problems to solve first. 4) evince doesn't appear by default on the GNOME Applications list (it happened on three different installations). Maybe it's not the only one, but I cannot find any others. This is on purpose, the .desktop file has NoDisplay=true because it is expected that you never need to launch evince, but you simply open documents from nautilus or your browser and this spawns evince. This is to not clutter the GNOME menu. (So, not a bug, a feature.) 5) some programs aren't present in the Debian menu: alacarte, gnome-btdownload No idea about these. You're welcome to file bugs if it makes sense to have them in the menu. 6) gnome-panel gives an .xsession-errors because Unable to open desktop file epiphany.desktop for panel launcher. This is normal as epiphany isn't installed by default, but I'd suggest to install the firefox.desktop instead. I did not see the discussion which lead to the choice of iceweasel as the default browser, and I think it would have been a worthwhile discussion to make publicly. This appears to be Ubuntu's choice as well, but I think the arguments brought up back then in the Ubuntu discussion don't apply anymore or don't apply to Debian (Epiphany is now as usable as IceWeasel is, and the name Firefox is not an argument anymore for Debian). I suppose what you're seeing is the result of a discrepancy between the default panel layout offered in the gnome-panel package and the installed packages. Perhaps this matter should be discussed on the debian-desktop@ list, at least I wish we would have a strong Debian Desktop decision-taking body so we could share ideas and goals and march in the same direction. Feel free to file a bug against either tasksel or gnome-panel depending on whether you would like to see iceweasel or epiphany on the default desktop. 7) why still Gnomemeeting by default instead of Ekiga (which AFAIK is the default VoIP client since GNOME 2.14)? This is fixed in the gnome-desktop-environment package, but did not migrate to testing yet, will happen in a couple of days. 8) the gnomebaker window doesn't start big enough to include all the buttons (this is clearly a bug, which strangely hasn't been reported yet). Completely unrelated, please see with the gnomebaker package's BTS / maintainer. Bye, -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bugs in default GNOME etch?
On Tue, Jan 16, 2007, Luca Capello wrote: 2) the Debian menu requires xpm icons [2] and in fact only 4 packages have icons in the png format (ekiga, evince, gimp, gnomemeeting), To be fair, the .png icon referenced by the evince menu file doesn't exist... I know and in fact I wrote at point 1: some entries in the Debian menu lack the icon: evince, yelp, sound-juicer, gnome-cups-manager (both entries), ^^ gnome-utils (gnome-screenshot), gucharmap, foomatic-gui, gnome-system-monitor, grdesktop, gsynaptics, ekiga Thus, evince Debian menu entry has two bugs: not an xpm icon and the actual png icon is missing (the latter more important IMHO). Fixed in 0.4.0-5. -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bugs in default GNOME etch?
On Tue, Jan 16, 2007, Bernhard R. Link wrote: * Lo?c Minier [EMAIL PROTECTED] [070116 10:50]: I can imagine technical solutions to these problems, such as a) making XPM optional and automatically generating it when it's not available (yes, this might result in an ugly icon in some cases, but at least we will have an ugly icon vaguely ressembling the icon, and it might also result in nicer icons for PNG capable menu displays), You can just translate the icons yourself. I want to spare me the time to do the update manually, but you suggest I augment the amount of manual work. Would the Debian menu system do this for me, I wouldn't have to. I usually prefer it when machines do the repetitive instead of me. If you consider them ugly, just add a new field for nice icons and start persuade people to tell their menu methods to use those settings first. Why reinvent the wheel in the Debian menu system? Why would I want to convert nicely looking upstream icons to an old format which can only look uglier? All desktop environments support pngs, and even svgs. And I do not benefit of the Debian menu system personally, I only see it as cluttering my GNOME menu, so I prefer spending my time in things which improve Debian as well, but which I enjoy doing and don't consider useless. b) using the .desktop files upstream provides to automatically register entries in the Debian menu (Note that the inverse process exists in menu-xdg :). Without this, Debian menu support in Debian packages will always lag behind as upstream updates its .desktop files, icons etc. or adds/remove programs. Well, to be perhaps a bit too frank: a maintainer that cannot cope with menu files should consider orphaning a package. I actually don't think orphaning packages make them any better. You're welcome to join pkg-gnome and fix the Debian menu entries. In fact, any help is welcome, not just on fixing menu entries. Hop in #gnome-debian on GIMPNet, and I'll be happy to guide you in participating to tasks of the team. If you do not even know which programs appear and vanish, you simply have lost. Sorry, but people make mistakes. This is why we avoid duplicating data in databases, and we avoid duplicating code in programs. I don't see why the Debian menu would be so special that it would require me to maintain menu entries in parallel to the .desktop files. You've taken the time to criticize my personal position with respect to the menu system, I suggest you also take the time to read the technical proposals I made to improve the menu system. The Debian menu system will not magically become useful to me, but at least it will automatically cover packages of maintainers which do not make it a priority to support the menu system fully in all their packages. -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gtkentry_password char
Hi, On Fri, Jan 05, 2007, Виталий Ищенко wrote: So I created patches for gnome-system-tools, libgksuui1.0, libgksu (2.0.3), libgksu , seahorse (should be looked at more carefully. Seahorse creates it's own widget, and I don't know better way to discover default GtkEntry invisible char, than creating GtkEntry with gtk_entry_new() and unreferencing it later) That's great! I've respectively: - filed an upstream bug for gnome-system-tools: http://bugzilla.gnome.org/show_bug.cgi?id=393173 if upstream merges the patch against the latest SVN, I will merge yours in the unstable tree, - forwarded your message to the maintainer and upstream developer of libgksu* for libgksuui1.0 and libgksu, - pinged an uploader of seahorse which was around on IRC. If somebody knows another apps which override default invisible char, send it here :) Heh! :) FYI, the default has been switched in experimental in version 2.10.6-5 of gtk+2.0. Bye, -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFC: gnome-vfs - bonobo symbol migration and indirect Depends/Build-Depends
Hi, Symbol have moved from gnome-vfs towards bonobo. The appropriate conflict has been added to ensure that you can't end up without the symbols if you need them. But this conflict causes a lot of complexity to compute the necessary build-deps. Of course, it will just work if the only versions available to the buildd satisfy the build-deps, and their deps and conflicts, but this is really problematic for: - experimental - backports - and perhaps if we don't notice that the default version is incompatible, but archive rebuilds before releases shoudl guard against this (But in the end, we will end up with more restrictive build-deps than what the sources truly permit.) I would like to complete the transition on the side of build-deps and deps as well, that is bump up build-deps and/or deps appropriately so that any version which satisfies the build-deps of a package is not discovered later on to conflict with another build-dep or a dep of a build-dep. An example of the problem is gedit, which build-depends on gnome-vfs2 = 2.16, and libgnomeui = 2.16. libgnomeui depends on libbonoboui = 2.13, which depends on libbonobo = 2.13. But gnome-vfs2 2.16 conflicts with libbonobo 2.15. I currently see two ways to transition to a simpler situation, but other ways would be valuable of course: 1) transition each inter-dependency: bump up the rdeps on libgnomevfs2-dev and libbonobo2-dev to transitionned version; for example libbonoboui2-dev $someversion would depend on libbonobo2-dev = 2.16, and libgnomeui-dev would depend on libbonoboui2-dev = $someversion 2) add dependencies or build-dependencies on lower level libs in high level libs: gedit would build-depend on libbonobo2-dev = 2.16 I don't like the second solution as it leaks low level libs deps to higher level stuff, and I don't like the former solution because it will bump a lot of inter-dependencies which are in the middle of the stack and will cause a lot of work. Bye, -- Loïc Minier [EMAIL PROTECTED] Forget your stupid theme park! I'm gonna make my own! With hookers! And blackjack! In fact, forget the theme park! -- Bender -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Arabic aspell patch for gedit in etch ?
On Tue, Dec 19, 2006, Josselin Mouette wrote: Please submit bug reports for such issues, so that we can keep track of them. He filed #403710. If other GNOME maintainers agree, I'm OK for uploading a patched gedit. I uploaded. -- Loïc Minier [EMAIL PROTECTED] Forget your stupid theme park! I'm gonna make my own! With hookers! And blackjack! In fact, forget the theme park! -- Bender -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: pango 1.14.9 and pango-libthai
An update for d-g-g readers: On Fri, Dec 08, 2006, Loïc Minier wrote: I would rather backport fixes to pango-libthai if needs be. I've uploaded the fixes prepared by Theppitak this morning... - a new source package (libdatrie), at least 10 days propagation to testing if everything goes fine ...and I'm picking this up now. -- Loïc Minier [EMAIL PROTECTED] I have no strong feelings one way or the other. -- Neutral President -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: pango 1.14.9 and pango-libthai
On Fri, Dec 08, 2006, Theppitak Karoonboonyanan wrote: What we need in the new pango deb is - Build-Depends: libthai-dev = 0.1.7-1 - Conflicts: pango-libthai However, libthai in sid/etch is currently 0.1.6-1. Libthai 0.1.7 would require a new package, libdatrie, for which I have filed ITP bug #392315, and prepared the package in mentors.debian.net [2], waiting for sponsorship for over a month. We are currently in upstream version freeze; I think this is the last freeze before full freeze. Following your plan requires: - a new source package (libdatrie), at least 10 days propagation to testing if everything goes fine - a new upstream version of libthai (breaks new upstream version freeze), with shlibs bumps (breaks another freeze which started longer ago, but there are not so many rdeps to libthai0), certainly 10 days at least, after libdatrie - a new upstream version of pango (breaks new upstream version freeze, has an udeb == is used in debian-installer), given the importance of pango, 10 days as well, probably after libthai This is a bit too much I'm afraid, and you didn't state any benefit at all: does it fix bugs? is it faster? Alternatively, if that takes too much, esp. if the new pango is still aimed for etch, we can ship it without Thai language module, and provide pango-libthai until libthai 0.1.7 makes it into Debian. But in the long run, pango-libthai is doomed (as well as its friend, gtk-im-libthai, once the new GTK+ is released upstream). A pango update might be feasible, it has no API change, so wouldn't need any shlib bump, but I messed with the previous update a little, and it's getting really late. I would rather backport fixes to pango-libthai if needs be. -- Loïc Minier [EMAIL PROTECTED] I have no strong feelings one way or the other. -- Neutral President -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
CDBS DEB_CONFIGURE_SCRIPT_ENV with/versus LDFLAGS/CFLAGS
Hi, (This is not a question, just a two cents trick for people using CDBS in gnomish packages.) Today, I had to add CFLAGS and LDFLAGS to a package's build process. The package had the --as-needed clob in its debian/rules: DEB_CONFIGURE_SCRIPT_ENV += LDFLAGS=-Wl,-O1 -Wl,--as-needed I could have added the LDFLAGS I needed at the end of the above line, even with CFLAGS, but it wouldn't have been very maintainable or simply readable. Digging up the DEB_CONFIGURE_SCRIPT_ENV usage, I think it makes more sense to simply set LDFLAGS: # drop unneeded ELF deps LDFLAGS += -Wl,-O1 -Wl,--as-needed (DEB_CONFIGURE_SCRIPT_ENV contains LDFLAGS=$(LDFLAGS) by default) Adding or removing options is then as simple as adding or removing/commenting CFLAGS / LDFLAGS lines: # build with TCP wrappers LDFLAGS += -lwrap CFLAGS += -DUSE_LIBWRAP Make sure you always use +=. As a side effect, any LDFLAGS set by CDBS isn't overwritten anymore. There's a high number of DEB_CONFIGURE_SCRIPT_ENV occurrences in pkg-gnome so I thought this is a common pattern. In the interest of readability, I suggest that people start updating their packages to augment LDFLAGS or CFLAGS directly. Thanks for your attention! Cheers, -- Loïc Minier [EMAIL PROTECTED] I have no strong feelings one way or the other. -- Neutral President -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using gconftool-2 for another user...
On Mon, Dec 04, 2006, David BERCOT wrote: I'd like to set values in gconf tree, from the root account to another account... Either set --config-source to the home dir (/home/$user/.gconf, see /etc/gconf/2/path) and run gconftool as root, then chown+chmod the files; or simply su - $user and run gconftool. If you wish to set settings for all users, you should write them as root into /etc/gconf instead, see /etc/gconf/2/path. -- Loïc Minier [EMAIL PROTECTED] You see, killbots have a preset kill limit. Knowing their weakness, I sent wave after wave of my own men at them until they reached their limit and shutdown.-- Zapp Brannigan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: planner transition will be held by pango.
On Mon, Dec 04, 2006, Gustavo Franco wrote: Latest planner upload is just 5 days old, but it depends on a libpango that is newer that the one in testing and pango is in freeze (due to the udeb). (I've requested migration of pango already, and it will quite certainly make it.) Since the latest planner upload in sid is a new upstream release, if we need it for Etch. EPARSE. :) -- Loïc Minier [EMAIL PROTECTED] You see, killbots have a preset kill limit. Knowing their weakness, I sent wave after wave of my own men at them until they reached their limit and shutdown.-- Zapp Brannigan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GNOME 2.16 in Experimental
On Tue, Nov 28, 2006, Jerome Warnier wrote: The following packages have unmet dependencies: gnome-power-manager: Depends: libdbus-1-2 (= 0.62) but it is not installable gnome-terminal: Depends: libvte9 (= 1:0.13.3) but it is not going to be installed metacity: Depends: metacity-common (= 1:2.16.2-1) but 1:2.14.5-2 is to be installed E: Broken packages I don't really expect anything, but felt important to let you know. Hope it helps. Probably ultimately missing packages on your architecture, especially if it's i386. Feel free to bin NMU the missing architectures. -- Loïc Minier [EMAIL PROTECTED] You see, killbots have a preset kill limit. Knowing their weakness, I sent wave after wave of my own men at them until they reached their limit and shutdown.-- Zapp Brannigan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GNOME 2.16 in Experimental
On Tue, Nov 28, 2006, Jerome Warnier wrote: Also, gnome-media is built with libnautilus-burn3, not the up-to-date libnautilus-burn4. This is on purpose. We build with as much from unstable as the build-dependencies permit. -- Loïc Minier [EMAIL PROTECTED] You see, killbots have a preset kill limit. Knowing their weakness, I sent wave after wave of my own men at them until they reached their limit and shutdown.-- Zapp Brannigan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GNOME 2.16 in Experimental
On Tue, Nov 28, 2006, Xavier Bestel wrote: The problem is that it conflicts with libvte4, used by synaptic and anjuta. Indeed. Some package inter-dependencies similar to libvte$soname - libvte-common have been relaxed, but for the same major version (e.g. gconf2 2.16.0- depends on gconf2-common (= 2.16), gconf2-common ( 2.17)). -- Loïc Minier [EMAIL PROTECTED] You see, killbots have a preset kill limit. Knowing their weakness, I sent wave after wave of my own men at them until they reached their limit and shutdown.-- Zapp Brannigan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Please test gnonlin 0.10.5.2 in experimental
Hi, Anyone using gnonlin (I suppose rare people with jokosher or pitivi installed), please test gnonlin 0.10.5.2 in experimental and report *regressions* over 0.10.5 as important bugs with the experimental tag. Thanks! -- Loïc Minier [EMAIL PROTECTED] 10 SIN 20 GO TO ROBOT HELL -- Temple of Robotology -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Has the GTK+ file-chooser problem been fixed?
Hi, On Thu, Nov 23, 2006, Tshepang Lekhonkhobe wrote: Has the file-selector problem shown here: http://oskuro.net/blog/freesoftware/gnome-2.16-etch-2006-10-06-21-45 been fixed yet? If not, how did Edgy deal with it? Yes and no. The problem is not as simple as a code-level error; the issue was that the semantics of the usage of the new async API did not reach a consensus. One of the point was whether the callback should be called when an early error happens, or not. This is very important because many applications will use the API, and will rely on these semantics, for example to free memory in all cases. The released 2.10 reflected a set of semantics which caused crashes, for which I think patches have been produced in other distros. There is a CVS branch where the alternate set of semantics is being developed. As I understand it, none of these two sets has been fully stabilized. At all rates, since Gtk 2.10 comes with a new module ABI, all of this is post-etch material. Bye, -- Loïc Minier [EMAIL PROTECTED] 10 SIN 20 GO TO ROBOT HELL -- Temple of Robotology -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [G-I] testresults using new gtk2-engines udeb
On Fri, Oct 13, 2006, Frans Pop wrote: We added /usr/lib/gtk-2.0/2.4.0/engines/libpixmap.so in libgtk-directfb-2.0-0-udeb to support the bladr theme. If we actually drop bladr and go with clearlooks for the default theme, and the libpixmap lib is not needed for that, it'd be nice if we could drop it again from the udeb. No real rush though. I've uploaded gtk+2.0 2.8.20-3 which drops this engines again, and adds the strdup() fix which seems required here as well. -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how to install packages from experimental
On Fri, Oct 13, 2006, Xavier Bestel wrote: The problem is that to build this package, I must install libgtk2.0-dev from experimental (= 2.10.1-1) so havoc will ensue (gnome uninstallation). Build it on another machine, in a pbuilder, or in a chroot. I can hand you possibly out of date binaries if you like: http://people.dooz.org/~lool/debian/libwmf/0.2.8.4-2.1/experimental-pbuilder/ (Please don't Cc: me, I'm subscribed to [EMAIL PROTECTED]) -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [G-I] testresults using new gtk2-engines udeb
On Fri, Oct 13, 2006, Frans Pop wrote: There is one minor issue. VT1 gets flooded with two messages: * Repeated a lot: (debconf: ): Gdk-DirectFB-WARNING **: gdk_directfb_gc_set_dashes not implemented * Repeated a lot while progress bar is running: Gdk_DirectFB-Message: filled polygons with n 3 are not yet supported, drawing outlines Seems like the engine uses some advanced features that are not supported by gdk-directfb, though it does seem to cleanly fall back to alternatives. I'd like to prevent the flooding of VT1 though; would it be possible to suppress these warnings? gdk_directfb_gc_set_dashes() and filled polygons with n 3 aren't implemented in Gtk 2.10.6 either, so a backport wouldn't help. I'm afraid that use of these functions would have to be changed in the Clearlooks engine and we would have to change the build to apply different patches to the directfb build; this would be relatively hard. I'm afraid that warnings are always printed by default, I couldn't find a way to turn them off without adding a special log handler. :-/ (The relevant code is in glib/gmessages.c in glib2.0, and the doc is at http://developer.gnome.org/doc/API/2.0/glib/glib-running.html.) I have one question: how will implementing this clearlooks engine affect implementing the bladr and dark theme? I'd like to avoid implementing several different themes/engines for Etch and instead stick to only: - one default theme - the dark theme (or rather one theme for visually impaired people) You definitely want a theme for visually impaired people, I've added libhcengine.so the gtk2-engines udeb, which enhances the look ot the High Constrast theme. It seems to reference /usr/share/themes/HighContrastLargePrint/pixmaps, but /usr/share/themes/HighContrast/gtk-2.0/gtkrc is probaly the bulk of the theme, and it would be a good start to try using this gtkrc. (Please let me know ahead of time if you need a gnome-themes udeb as well, but it would be easier to grab a copy from the relevant files and ship them in rootskel for now.) I didn't look into the Bladr theme. I'm not sure how you'll switch theme when someone wants the accessibility mode of the installer, do you have a solution for this already? Will you generate a gtkrc in /etc? -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [G-I] testresults using new gtk2-engines udeb
On Fri, Oct 13, 2006, Frans Pop wrote: OK. If there is no acceptable way to turn them off, I guess we'll have to live with them. It's mostly that I'd like to avoid unnecessary BRs from users who see the errors and also give really meaningful errors a chance of actually being seen... Understood. The clean way would to turn them off conditionally, for example only for g-i. Sample possible ways: - gtk/dfb: . build gtk one more time for g-i (curently, the directfb build is used both for regular *.debs and for the udeb) . add a buildtime condition in a patch for gtk which only affects the g-i build - gtk/dfb + g-i: . add a runtime condition in a patch for gtk which turns off warnings when a certain condition is met (environment var, file...) . meet that condition in g-i - gtk2-engines: . add a buildtime condition in a patch for gtk2-engines which only affects the g-i build . add a log handler to filter out these events in the patch But let us explore the backport of gtk2-engines 2.8 first. :-P BTW, are these messages also written to a logfile somewhere? No. -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
