Re: Would a Debian patch to fix bug #776595 be an acceptable path to go?
Frans Spiesschaert frans.spiesscha...@yucom.be wrote: Given this context, I have the following question: would there be a chance that such a patch gets accepted and reaches Jessie 8.0 or 8.1 or is preparing a patch not worth the effort, given the fact that the severity of bug #776595 is only important. Please send a patch against nl.po to the bug. It looks worth fixing. Cheers, -- Joss -- To UNSUBSCRIBE, email to debian-gtk-gnome-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1422894285.28375.5.camel@dsp0698014
Re: Bug#776218: installation-reports: Reportbug needs python-vte, which is not installed in the default installation
Hi, Cyril Brulebois k...@debian.org wrote: (major) The missing packages should be installed from the beginning. These are python-vte and python-gtkspell (which reportbug also wants). Might be a good idea for some gnome packages to pull those packages? I’m not sure it’s the right way to do that. These packages are not maintained upstream and we want to get rid of them, not to add new dependencies. GNOME in jessie is fully built on GTK3, except for iceweasel and a couple of other default applications. And most Python dependencies have been switched to Python 3 as well (except for some Debian-specific scripts). -- Joss -- To UNSUBSCRIBE, email to debian-gtk-gnome-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1422268763.22902.26.camel@dsp0698014
Re: Problem with nvidia driver and Gnome Backgrounds
Hi, Le vendredi 05 décembre 2014 à 07:38 +0100, Johan Kröckel a écrit : I am a little bit annoyed of bug #768896 and I am starting to suspect, that it could be another package which causes the problem. It seems, that the backgrounds are stored in memory, which is not powered over suspend and not refreshed after wakeup. I really want to help with this bug, but I dont know how. Do you have any ideas? I have seen the exact same bug on VMware windows when resuming from suspend with wheezy+nvidia-glx 339. So this definitely looks like a nVidia bug which needs to be taken upstream. -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-gtk-gnome-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1417775156.17676.2.ca...@debian.org
Re: [Pkg-xfce-devel] Reverting to GNOME for jessie's default desktop
Le mardi 12 août 2014 à 03:03 +0100, Anthony F McInerney a écrit : I had stated previously XFCE had started showing memory usage similar to gnome. This has quite obviously changed. I was wrong, and i'm posting it as a correction to my statement. You’re comparing apples and oranges. These memory usage comparisons are only useful at feature parity - which doesn’t exist, since different environments have different paradigms and different feature sets. How much RAM does your browser use? Lots, which is why i prefer my DE not to eat it all. When the browser uses 1 GB while GNOME (including evolution and many other running applications) uses half of that, I don’t think you need to look for memory savings in the desktop. You need to buy more RAM and that’s all, because browsers won’t suddenly stop needing their gigabyte. If you can't run GNOME because you don't have the system specs to run a modern desktop then you can select XFCE/LXDE in the installation menu. But let's be fair, those people are a minority. And a default should fit the needs of the majority. Ahh good you have statistics for that. Please link them, or quote and cite sources. I just had a look at an online hardware store. Out of their 682 laptops and 332 desktops: * 1 model has 1 GiB * 48 models have 2 GiB * 470 models have 4 GiB * 495 have 6 GiB or more Which means 0,1% of the machines you can buy are not able to run a web browser anyway, 5% are more than enough for a full-fledged GNOME+web browser, and all the rest are very comfortable with anything you can run under Linux. Some people like the 'basic 3d acceleration' for other things, so not only do you want me to sacrifice my RAM to all powerful DE, but also my GPU? How kind of you ;) We happen at work to have users with very important needs of 3D resources, so one of my colleagues conducted some performance tests with and without a compositor (the compositor being GNOME 3). It turns out that with a recent adapter, 3D applications are running a small bit faster under GNOME, and that’s probably because it saves your graphics card the pain to switch from 2D to 3D contexts. -- .''`.Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-gtk-gnome-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1407838921.26277.435.camel@dsp0698014
Re: [Pkg-xfce-devel] Reverting to GNOME for jessie's default desktop
Le mardi 12 août 2014 à 13:12 +0100, Anthony F McInerney a écrit : Virtualbox Results (no guest drivers installed) Glxgears is not a relevant 3D benchmark. But the funniest thing is that you did this test without any 3D acceleration, which is not representative at all of most real-world computers. Thanks for making the point that with llvmpipe, GNOME is perfectly usable on a machine without 3D. -- .''`.Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-gtk-gnome-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1407846059.26277.455.camel@dsp0698014
Re: RFH: gi and overrides, how it should be packaged
Hi Osamu, Le lundi 21 juillet 2014 à 02:07 +0900, Osamu Aoki a écrit : Hi gnome folks, The input method packaging team is wondering what to do with the /usr/lib/python*/dist-packages/gi/overrides/Ibus.py files generated when python-gi-dev is in the build environment. Do we make python-ibus just for them? Or put it inside gir* packages. I have no idea which one is better. (gir* is easier for me...) Since they are overrides for modules which are loaded through GI, it looks much better to put them in the gir* package. Cheers, -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-gtk-gnome-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1406394599.2376.6.camel@tomoyo
Re: Error message installing Google-Web-Designer
Le vendredi 06 juin 2014 à 11:17 -0400, Stephen Allen a écrit : Greetings. Running Gnome-Shell 3.8.x on Debian Jessie, after installing Google-Web-Designer the following message is presented: Setting up google-webdesigner (1.0.1.0-1) ... Error in file /usr/share/gnome/applications/display.im6.desktop: NoDisplay=true is an invalid MIME type (NoDisplay=true does not contain a subtype) This message is proof that this package’s postinst script is doing completely unneeded or irrelevant stuff. (There is a real bug here which is #692141, fixed in svn, but it’s unrelated.) Which results in the application showing up without any toolbars or chrome just a blank shell. Tell Google to stop writing hundreds of useless lines in their postinst scripts. Any idea what's wrong/needed to fix this? Google's page says it's compatible with Debian/Ubuntu. Apparently, it is not. All of freedesktop stuff is automatically handled by triggers, in both Debian and Ubuntu. What this package does risks breaking your system. -- .''`.Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-gtk-gnome-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1402069883.21068.94.camel@dsp0698014
Re: GNOME 3.8 and awesome wm
Le vendredi 22 novembre 2013 à 11:18 +, Mike Timonin a écrit : This thread indicates that in 3.8 media keys, layout, etc, have been moved over to gnome-shell https://bbs.archlinux.org/viewtopic.php?pid=1262471 Yes, it is a known problem. We need to resurrect them as g-s-d plugins used from gnome-fallback. Cheers, -- .''`.Josselin Mouette : :' : `. `' `- -- 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/1385129301.24216.626.camel@dsp0698014
Re: Affected by gnome-shell lockups on wheezy?
Le vendredi 05 juillet 2013 à 23:30 +0200, David Weinehall a écrit : I'm using gnome-shell 3.8.3 from experimental I'm still seeing lockups every now and then. Not sure whether it's the same issue, but it's annoying, it's rather frequent, and now with the workspace grid and weather notification extensions rectifying the shortcomings of the default behaviour I'd be very disappointed to have to abandon gnome-shell. It could be the same issue (although triggered differently), because while gjs has changed a lot, the bug in mozjs is still around. If so, the version in unstable should have the workaround working. -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1373109084.13665.1.camel@tomoyo
Affected by gnome-shell lockups on wheezy?
Hi all, despite some workarounds added to the gnome-shell package, some users have still complained of more or less frequent deadlocks of the shell (usually 10 minutes after login), forcing them to fall back to GNOME Classic or other desktops. We know vaguely where this comes from, and it should be fixed in GNOME 3.8, but in the meantime we can improve the situation in wheezy. If you have been affected by such deadlocks, please test gnome-shell 3.4.2-11 in unstable. I can also provide wheezy packages if needed. If the deadlock happens, it should now soon after login, and the shell should restart after 10 seconds instead of remaining locked. It’s still far from perfect, of course, but it should be a big improvement over losing the session. If the tests are conclusive, we’ll upload this fix into wheezy in the next point release. Thanks, -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1372888711.26950.5.camel@tomoyo
Re: The difficulty of contributing / volunteering
Hi Boruch, Le jeudi 31 janvier 2013 à 16:22 -0500, Boruch Baum a écrit : Hello everyone, I'm getting a bit discouraged (see below). I thought it would be simple to offer to volunteer helping in debian, specifically packaging 'meld' and other packages with only older versions debianized. It really shouldn't be this difficult. Thanks a lot for your interest. Our primary means of synchronisation in the GNOME team is the IRC channel (#debian-gnome on the OFTC network). If you have specific changes you want to submit, you can send them to a bug report, but it’s easier to discuss directly. About meld specifically, since it is not really part of GNOME, I don’t think anyone would object if you wanted to adopt it and move the repository to collab-maint, for example. Cheers, -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1359668402.20400.3.camel@tomoyo
Re: Making GNOME 3 fallback mode not suck
Le vendredi 11 janvier 2013 à 21:16 +0100, Johannes Rohr a écrit : Well, I have played around with fallback mode a bit now, and I have to admit that it seems very unstable, with the panel crashing all the time, and there are just too many feature of GNOME 2, which don't work anymore as expected, so it is probably not such a good idea to encourage its use. If the panel crashes, please report a bug with the stack trace. The fallback session is supposed to work with all functionality for the wheezy cycle and we will treat bugs as such. I’ve been personally using this setup on 2 machines on a regular basis, with very few problems (much less than with squeeze). Am 11.01.2013 17:36, schrieb Jeremy Nickurak: It's worth keeping in mind that the fallback mode the Gnome developers had provided in 3.0-3.6 is being removed in 3.8, in favour of a strictly gnome-shell based desktop. Even on systems that lack hardware acceleration, software rendering of these elements is reportedly very quick. Software rendering only works on x86 systems. We are currently working with other distributions on ways to keep the fallback mode working in the long term. Upstream is not hostile to that approach. Cheers, -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1358204334.9342.10.camel@tomoyo
Re: Fwd: GDM3 with systemd support doesn't shut down/restart system
Le vendredi 21 décembre 2012 à 09:08 -0200, Laércio Benedito Sivali de Sousa a écrit : In order to use the multiseat support available in systemd-logind, I have recompiled gdm3 package with systemd support (options --with-systemd and --without-console-kit in debian/rules). Strangely, my GDM3 stops rebooting/shutting down my computer (when I click Shut down in greeter, nothing happens, and when I click Shut down inside a GNOME session, it only logs out). GDM is probably trying to use the systemd mechanism to shut down, instead of ConsoleKit. Even with systemd enabled, for wheezy it should always use CK for the shutdown interface (this will change after the release). You need to patch this in the source. I’m CCing darion Андрей who is also interested in multiseat support. If you are willing to fix any such regressions (including those with multiseat + user-switching that darion reported), and the patches are light enough, it might be not too late to fix this for wheezy (although it *is* late). Cheers, -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1356177567.25654.4.camel@tomoyo
Re: Nvidia proprietary driver and multiseat with gdm3+systemd
Le samedi 22 décembre 2012 à 16:39 +0300, darion Андрей a écrit : I ran into another problem. Nvidia proprietary driver does not work with gdm3+sistemd. I'm only interested in a full 3D support for multiseat. Decided by adding patches (include in attaches) Patch idea was found here https://bugzilla.redhat.com/show_bug.cgi?id=878605 If this patch is needed, you need to report a bug against the systemd package. Now all the seats are working fine and full accelerated, but after logout gdm3 greating respawn not working. May be I should rebuild with --without-console-kit too (now I rebuild with --with-systemd only) ? No, this is unrelated. You need to debug the spawning logic, which is different for multiseat. The patches for monoseat are: 17_switch_on_finish.patch 18_parametrize_create_display.patch 19_static_transient_display.patch 20_switch_kill_greeter.patch 21_static_display_purge.patch I have adapted them for the code changes for multi-seat but this was never tested, so there is probably some remaining work. Cheers, -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1356187232.25654.10.camel@tomoyo
Re: Only one WISH: don't leave Gnome2!
Le mercredi 04 juillet 2012 à 16:33 +0200, Stefano Salvi a écrit : Gnome Fallback is NOT Gnome2 - is far less usable! How is it less usable? Explain! http://malsain.org/~joss/explain.jpg -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1341433618.4613.2.camel@tomoyo
Re: gnome fallback, etc??
Le vendredi 29 juin 2012 à 01:21 +0200, Svante Signell a écrit : Thanks a lot, it seems to be located in gnome-session-fallback package. And it will be part of Wheezy too? Yes. Some time ago the fallback version was unavailable when a 2D solution was found. Huh? This had only been the case for a few weeks and only in experimental BTW: I wonder how to configure applets and extended features with the Gnome 3 session, provided by the gnome-applets and gnome-shell-extensions packages. I did not find out how to do that, still using it on the laptop. alt+right click does not work. And is there a way to disable the 3D functions, the laptop has only 1GB memory and a slow graphics card (I think it is an i915). You have to understand that the “GNOME” and “GNOME Classic” sessions are based on different software (resp. shell and panel). With the shell, you enable extensions using gnome-tweak-tool. With the panel, you can edit it like with GNOME 2. Cheers, -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1340955380.3646.292.camel@pi0307572
Re: gnome fallback, etc??
Le jeudi 28 juin 2012 à 12:45 +0200, Svante Signell a écrit : Unfortunately I have to upgrade my Debian systems without changing the desktop environment away from gnome3. Is there a way to have something similar to gnome2, like the fallback (gone already?), applets in the window list (like the netspeed applet), 2D instead of 3D, etc. I have not found any menus for setting, e.g. 2D under gnome3. (my laptop already has gdm3, I didn't find anything there). You can select “GNOME Classic” as a session from the display manager. It is extremely similar to GNOME 2, except that the panel is black and you have to use alt+right click to configure it. There is also still a netspeed package. Cheers, -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1340922196.4647.1.camel@tomoyo
Re: Improving the accessibility of our GNOME session
Le jeudi 21 juin 2012 à 18:13 +0200, Jordi Mallach a écrit : Second, we need a way to activate Orca using a keypress in the GDM greeter. Something like: gsettings set 'org.gnome.settings-daemon.plugins.media-keys' screenreader 'Primarys' (or whatever keybinding we think is good enough) for the Debian-gdm user should work, but I'm not sure how to do that in a sane way. Joss? Either add, like desktop-base, a new file in /usr/share/gdm/dconf/10-orca-settings with the setting you want. Or simply change debian/greeter.gsettings in the gdm3 package. -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1340531489.6380.3.camel@tomoyo
Re: Debian Installation Alpha 1 AMD64 netinst ISO installation report
Le mardi 15 mai 2012 à 00:46 +0200, Cyril Brulebois a écrit : Note that I installed Debian within a virtual machine. When I rebooted the VM, and tried to install some packages (gnome-desktop-environment) to try out Gnome Shell, aptitude offerred to remove alsa and alsa-base. Apparently it did, because at the next reboot, I was left with no speech. This is not related to the installer, which worked very well. I would call this an RC bug. Hae anyone of you experienced this problem? Also, I wanted to let you know that their were alsa-related errors related to the PCM device, but didn't really affect anything, because I was able to get to the login prompt just fine. Their were also errors related to consolekit and the keymap. I'm putting gnome people to the loop for the sound issues. A wild guess: when installing gstreamer0.10-pulseaudio some other backends were removed, and no dependency remained on alsa-base. Since alsa-base is essential to having working sound, I’d suggest moving it to priority important, and/or adding a dependency somewhere in the stack (pulseaudio/linux-any would be a good choice). -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1337250625.5346.4.camel@tomoyo
Re: evolution extensions
Hi, Le jeudi 16 février 2012 à 10:08 -0300, David Roguin a écrit : I want to make an evolution extension that adds a simple 'archive' button that mimics the gmail's one. I have a doubt about what evolution source should I change. I'm using wheezy right now, so most of my gnome packages are 3.2.* even though gnome's master is in 3.3. What I was thinking is getting evolution src from debian, make changes and build the package again. Instead of getting the latest evolution from upstream. What do you recommend? Evolution supports quite a number of extension points, so you probably don’t need to patch it for such a simple change. You can use evolution-dev to build an extension that can be installed separately and enabled at runtime. You can have a look at evolution-rss, which is, although already a bit complex, a good example of a standalone extension with a few UI changes. Cheers, -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1329501241.3297.872.camel@pi0307572
A Debian sprint for package management GUIs?
Hi, given the poor state of our desktop package management tools in squeeze, and the number of unknown variables when it comes to wheezy, I’d like to propose to gather around in a dedicated Debian sprint on this topic. We should be able to get funding from the project for such a task. Schedule could include: * Upstream and Debian state of synaptic, update-*, aptdaemon, software-center, PackageKit and related packages * What features we want to expose on our desktop environments (use cases, interaction scenarios) * Which tools to focus on to provide these features for wheezy * Trying to envision what features we want in wheezy+1 and how to make this happen * Initial common hacking session to get wheezy on the right tracks How many of you would be interested in such a meeting? Cheers, -- .''`. Josselin Mouette : :' : `. `' `- signature.asc Description: This is a digitally signed message part
Re: gtk2.0 support after gnome3 transition
Hi, Le samedi 12 novembre 2011 à 15:42 +0900, Osamu Aoki a écrit : Hi, I have questions for what to expect for the wheezy environment: * Is there any significant applications which will remain in gtk2 based? Applications of the core module set should be all ported to gtk 3 in time for wheezy. But for other applications we depend on, there are at least abiword, gnumeric, iceweasel, gimp, inkscape, shotwell, simple-scan, transmission, debconf (using libgtk2-perl), liferea (which is becoming so crappy we might replace it by something else) and libreoffice for which I am not sure. You should ask their respective maintainers whether they intend to port them or not. If most of them have been ported in time or have good replacements using gtk3, we might have a gtk2-free desktop for wheezy. * Is support of gtk3 only good enough? It depends on what you are trying to achieve. There will be anyway a large number of remaining, small GTK+ 2.x applications. It took us 8 years to get rid of GTK+ 1.2, I’m afraid it will take a similar amount of time for GTK+ 2. * Does gtk3 have GTK3_IM_MODULE just like QT4_IM_MODULE for qt4? No. This is one of the upstream choices I am really unhappy about; the environment variables and X settings are the same for GTK+ 2.x and 3.x, despite not having the same modules/themes/input modules available. Cheers, -- .''`. Josselin Mouette : :' : `. `' `- signature.asc Description: This is a digitally signed message part
Re: gtk2.0 support after gnome3 transition
Le samedi 12 novembre 2011 à 13:01 +, Harvey Kelly a écrit : Out of interest, what would you recommend? I use Liferea, which is *okay*, but would like to try something else. I’m using evolution-rss, which I find to be a bit better, but it is not a killer application either. -- .''`. Josselin Mouette : :' : `. `' `- signature.asc Description: This is a digitally signed message part
Re: Bug#637314: Nautilus transition started; please upload to unstable
Le mardi 18 octobre 2011 à 19:39 +0200, Andrea Veri a écrit : On Thu, 13 Oct 2011, Jordi Mallach wrote: Please upload a GTK+3 version of your package to unstable as soon as possible, or ask for help in debian-gtk-gnome@lists.debian.org if any problem arises. I mailed diff-ext's upstream author several times now and didn't get a response from him yet. He told me he was working on providing an updated package but then he disappeared. Anyone on the Debian's Gtk-GNOME team can suggest me a good way of providing a nautilus-3 compatible package? You mostly need to port it to GTK+ 3, so it is not the hardest part. All necessary explanations are in the libgtk-3-doc package. -- .''`. Josselin Mouette : :' : `. `' `- signature.asc Description: This is a digitally signed message part
Re: Bug#642906: RFH: balsa -- An e-mail client for GNOME
Le lundi 26 septembre 2011 à 10:22 +0200, Maxime Chatelle a écrit : Sorry for the late, I will take it over as we said earlier [1] if your are ok again. With the holidays, I missed the time. (and a little bit forgotten) Ah right, I forgot we already had someone interested /o\ Please take it over when you have the time. We will remove it from the pkg-gnome repository when it’s done. Thanks, -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1317025474..191.camel@pi0307572
Re: Ephiphany backport?
Le lundi 26 septembre 2011 à 15:27 +0200, Paul van der Vlis a écrit : Do you think it would be possible to make a backport from Epiphany 3.04 for Squeeze without big upgrades like GTK and Gnome? No. You’ll need at least glib, gdk-pixbuf, gtk+2.0, gtk+3.0, glib-networking, libsoup, webkitgtk, seed and I’m forgetting some. Furthermore proxy settings won’t work unless you make heavy changes in glib-networking. -- .''`. Josselin Mouette : :' : `. `' `- signature.asc Description: This is a digitally signed message part
Bug#642906: RFH: balsa -- An e-mail client for GNOME
Package: wnpp Severity: normal I request assistance with maintaining the balsa package. Nobody in the GNOME team is actually using it anymore, and only RC issues are fixed at the moment. It is vastly inferior to evolution, but it is also a decent lightweight alternative for those in need for it. The package description is: Balsa is a highly configurable and robust mail client for the GNOME desktop. It supports both POP3 and IMAP servers as well as the mbox, maildir and mh local mailbox formats. Balsa also supports SMTP and/or the use of a local MTA such as Sendmail. . Some of Balsa's other features include: * Allowing nested mailboxes * Printing * Spell Checking * Multi-threaded mail retrieval * MIME support (view images inline, save parts) * GPE Palmtop, LDAP, LDIF and vCard address book support * Multiple character sets for composing and reading messages * File attachments on outgoing messages * GPG/OpenPGP mail signing and encryption . Support for Kerberos and SSL has been enabled in this package. -- .''`. Josselin Mouette : :' : `. `' `- -- 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/20110925135427.ga14...@malsain.org
Re: Bug#604934: libproxy: Please upgrade to 0.46
Le jeudi 22 septembre 2011 à 17:59 +0100, Iain Lane a écrit : I've been working recently on upgrading libproxy to 0.47, the latest upstream. Seriously, don’t do that. The 0.3 series was already broken, and the 0.4 one is even worse. They reimplemented again a non-standards-compliant HTTP parser, instead of using an existing one. This library as a whole is a bucket of fail. We need to rip the interesting parts from it and put them in glib-networking, using libsoup for the HTTP parts and libjscore for JS parsing. Any approach that keeps libproxy in the archive is doomed to produce gazillions of bugs. -- .''`. Josselin Mouette : :' : `. `' `- signature.asc Description: This is a digitally signed message part
Re: Bug#637331: transition: nautilus
Le jeudi 18 août 2011 à 07:21 +0530, dE . a écrit : I hope you all notice the fact that the Gnome team has not deprecated Gnome 2.x, thus the classic panels, and metacity is not deprecated; they may be mixed with Gnome 3. The panel in GNOME 3 has a completely revamped API which calls for a large transition. http://deb.li/panel3 -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1313654967.3506.370.camel@pi0307572
Bug#638067: transition: evolution
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, we’d like to schedule a transition to evolution 3.0. As usual for evolution transitions, there is a small set of packages requiring sourceful uploads and more that require binNMUs. I haven’t tested whether they build correctly, but I don’t expect it to be harder than usual. The transition needs to be done together with libgdata, which only implies only one extra binNMU. In order to avoid forcing reverse dependencies to be updated to gtk+ 3 simultaneously, the evolution-data-server source package has been renamed to evolution-data-server3. Some binaries are simply replaced by the newer version, while libraries that changed soname are co-installable - this is especially true of libedataserverui. Once reverse dependencies have all been updated to gtk+ 3, the plan is to rename back the source package to evolution-data-server and decruft old binaries. The following packages need sourceful uploads, they are ready in experimental except for evolution-mapi which is not in testing either: * evolution * evolution-data-server3 * evolution-exchange * evolution-mapi (not in testing) * evolution-rss * libgdata The following packages need binary NMUs for libgdata: * totem The following packages can be rebuilt against a newer libcamel, but even if they are not this should not prevent the packages from migrating: * almanah * deskbar-applet * ekiga * empathy * eweouz * giggle * gnome-panel * gnome-phone-manager * gnome-python-desktop * gnome-shell * libopensync-plugin-evolution2 * librevolution-ruby * mail-notification * sflphone * syncevolution * tracker The following packages will need to be updated to gtk+ 3 and libedataserverui-3.0 later so that e-d-s 2.30 can be dropped: * gnome-panel (will have its own transition) * sflphone * tracker -- .''`. Josselin Mouette : :' : `. `' `- -- 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/20110816220710.ga8...@malsain.org
Re: Bug#637331: transition: nautilus
Le jeudi 11 août 2011 à 20:31 +0200, Michael Biebl a écrit : The alternative is to backport the necessary changes in g-s-d (which sounds insane) or to re-add the necessary support in nautilus (which is far from trivial). I'd rather just have automount support broken temporarily, tbh. I don’t think there is any point in testing if we break such basic functionality for a long period of time. But that’s for the RT to decide anyway. -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1313137327.24704.366.camel@pi0307572
Re: Bug#637331: transition: nautilus
Hi, Le mercredi 10 août 2011 à 15:11 +0200, Michael Biebl a écrit : as next step of getting GNOME 3 into unstable, we'd like to request a slot to start the nautilus 3 transition Sorry for chiming in after being not-so-active for a while, but I’m afraid this transition cannot be done, as things stand, independently from the core GNOME components. Nautilus 3.0 removes the code to automount filesystems, so it needs to migrate together with gnome-settings-daemon. In turn, g-s-d needs to be synchronized with (at least) glib2.0, gvfs, gnome-control-center, gdm3, gnome-media, gnome-power-manager, gnome-screensaver, and gnome-session. The alternative is to backport the necessary changes in g-s-d (which sounds insane) or to re-add the necessary support in nautilus (which is far from trivial). Also, if we’re able to, I wonder whether it’s possible to migrate gnome-panel first - otherwise it will have to go with the rest. -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1313067533.24704.338.camel@pi0307572
Re: Software center outdated.
Le jeudi 11 août 2011 à 20:48 +0530, dE . a écrit : Lately, I've been concerned about the software-center package which's stuck in version 2.0.x instead of the current 4.x. I tried reporting a bug but there was no response from the maintainer. Kindly have a look at it's state. If you’re interested in the maintenance of the software-center package, you’re welcome to help; this package obviously needs someone to take care of it. Cheers, -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1313078241.24704.363.camel@pi0307572
Re: Fwd: Ugly themes appearance
Le dimanche 24 juillet 2011 à 13:10 +0200, Cesare Leonardi a écrit : Since, as mentioned in the theme, Adwaita currently doesn't look as intended (for me is annoying that it doesn't make evident what is the active window), i prefered customize it using the Clearlooks windows border: to me this enable the future using the good old look. The reason why in the test laptop i use at work that happened automatically was that in these days i've switched from LXDE to Gnome, so i had took the new default. I wonder if this theme switch will be forced by gnome-themes package or will be something left to the user. The switch will be forced for GNOME users when upgrading to gnome-settings-daemon 3.0. I can’t tell for LXDE or Xfce. -- .''`. Josselin Mouette : :' : `. `' `- signature.asc Description: This is a digitally signed message part
Re: Can't smoothly type in gnome-terminal
Le mardi 05 juillet 2011 à 13:03 +0900, Miles Bader a écrit : Chris bbsh...@gmail.com writes: According to a reply to bug #631116, installing ibus-gtk3 solved the typing issue for me. But the bad style is still here. A reboot makes no difference. As for the theme, the only available theme for GTK3 at the moment is Adwaita, so you need to use this one. [Argh, even though I'm the original bug reporter for #631116, I didn't get any of the email followups, so I didn't seem those replies until you mentioned them! Some stupid spam filter crap no doubt... Spammers ... must die] No, this is because of #434257. The debbugs developers don’t want to fix their software. So what exactly is gnome-terminal screwing up here...? Why does disabling SCIM solve it? As mentioned in the bug log, SCIM doesn’t provide a GTK3 module. -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1309947676.13005.270.camel@pi0307572
Re: Bug#626723: RFP: rhythmbox-plugin-ror -- Remember last played song and play it as first song after rhythmbox restarts.
Le samedi 14 mai 2011 à 21:21 +0400, Roman V. Nikolaev a écrit : Package name: rhythmbox-plugin-ror Version: unknown Upstream Author: Michal Nánási m...@ksp.rhythmboxplugin.ksp.sk URL: http://people.ksp.sk/~mic/Projects/RhythmboxROR License: GPL3 Description: Remember last played song and play it as first song after rhythmbox restarts. These plugins are way too small to make it relevant to package each of them separately. I encourage anyone interested in rhythmbox plugins to start collecting third-party plugins and put them in a single package. -- .''`. Josselin Mouette : :' : `. `' `- signature.asc Description: This is a digitally signed message part
Re: Analysis of the gnome3 transitions
Mehdi Dogguy wrote: First of all I think we should upload gtk+3.0 to unstable in the next days. Together with it we can upload a lot of libraries that are parallel-installable with their GTK 2.x versions. This happened already. GTK3 is here, now we can start uploading libraries that depend on it. 1. libnotify This has been requested and is tracked as #622363. As mentioned in the bugreport, we will try to get Xfce before (asked earlier and seems to simplify the transition a bit). Yes, although libnotify 0.6 doesnt require anything and would help some reverse dependencies already. 3. devhelp and, anjuta-extras I guess. If everything needed is already ready in sid/wheezy, you can go ahead with this. The one thing Im wondering about starting to upload GTK3 applications is the lack of a good theme. The only theme available currently is Adwaita; we could upload it to unstable but this means changing the default theme. 4. gnome-keyring It is almost a self-contained transition (gnome-keyring + seahorse). However it needs to be done early because empathy (involved in other transitions) will need it. This semi-started :/ libgnome-keyring 3.0 has been uploaded and triggered some bad side effects (#622556). It might be a good idea to do this one, if we can avoid updating seahorse-plugins ; or revert the upload. Yeah, I think upstream f*cked up this one too. Ill see how this can be fixed. 5. gedit This probably means not before gnome-keyring and devhelp transitions are over, I guess. In any case, if we do one transition before the other, the gedit plugin will stop working for a while. I think its a necessary evil, otherwise were going to entangle all these transitions together. 6. gnome-bluetooth The only fix I can think of is to rename the source package to gnome-bluetooth3 and the -dev package to libgnome-bluetooth8-dev, making it conflict with libgnome-bluetooth-dev. Then it will take, later, another round of source uploads to change back the -dev package name. Sounds reasonable. OK, will do. 7. evolution Sounds reasonable. Does this transition need any other one mentioned already? or, is it self-contained? Just checking. Since the source package name is changed, it is almost self-contained. The reverse dependencies for e.g. libcamel will be rebuilt against the new version, though, so it might block other transitions if the new package doesnt migrate to testing soon enough. 8. gnome-media + gnome-media-profiles Due to the upstream split between the library and the binary, if we upload gnome-media 3.x, the gtk2 library will disappear. We can probably rename the source package to gnome-media3, so that only the gnome-media binary is taken over, keeping libgnome-media0 and -dev in the archive. Later we can rename again the source package to make them disappear. (Again, cruft to deal with at the end of the transitions.) So, affected packages here are: - gnome-python-desktop - gnomeradio - rhythmbox - sound-juicer (nothing build-depends on libgnome-media-profiles-dev yet). Bigger problem here, aiui, is gnome-python-desktop as it provides a library and has a significant number of reverse dependencies. It depends on what kind of changes are implemented there. Depending on the changes required to get reverse dependencies ready, maybe it's not necessary to rename packages and have to deal with cruft? Its not possible to port gnome-python-desktop; the python-mediaprofiles binary will be removed. I dont know for gnomeradio, but I dont like the idea to force several packages at once to migrate to GTK3 together. 9. gnome-panel Which applets are not ported yet? (libpanel-applet2-dev has quite some number of reverse dependencies). Very few applets have been ported so far. 10. nautilus For automounting, things are a lot worse. The functionality has been moved to gnome-settings-daemon and changing that would be a lot of work. Therefore, Iâd like to know whether the release team would accept to tie this (already big) nautilus transition with the big GNOME transition. Ideally, we prefer smaller transitions, when possible (for obvious reasons). So, are the changes to apply to nautilus significant? Will that take a lot of time to get them prepared and ready? This is a big amount of work; Im not sure it is possible to get back automount to work. Had it been useful, I would have volunteered to do it, but just to make it able to transition smoothly, it looks like a lot. If you want to have a look, these are most of the changes between 2.91.2 and 2.91.3. 11. The big GNOME transition Any opinion on webkit 1.3.x? Is it needed somewhere for the Gnome transition? Webkit, just like most GTK+ based libraries, will be parallel installable, so there is no transition
Re: Analysis of the gnome3 transitions
Emilio Pozuelo Monfort wrote: Bigon said 0.6 doesn't link against any gtk+ version though it still uses it. That's buggy (it should link against the version it was built against) and will cause various kind of bugs, so I think we should go for 0.7 directly. If the number of rdeps is too big we can rename the -dev package. OK, fine. The one thing Im wondering about starting to upload GTK3 applications is the lack of a good theme. The only theme available currently is Adwaita; we could upload it to unstable but this means changing the default theme. We'll change it sooner or later, so this shouldn't be a big issue. Or am I missing something? I havent checked whether g-s-d 2.x is able to set the theme for gtk 3.x. If its the case, thats clearly the way to go. -- Joss -- 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/538f8c72f7362f17142577bf84dbfb0d.squir...@malsain.org
Analysis of the gnome3 transitions
-media binary is taken over, keeping libgnome-media0 and -dev in the archive. Later we can rename again the source package to make them disappear. (Again, cruft to deal with at the end of the transitions.) 9. gnome-panel Theoretically, this one should be done with the big gnome3 transition (see below). However it sounds insane to couple it, since it breaks all existing panel applets. Updating it without updating the rest of GNOME implies making sure that it can be a drop-in replacement for gnome-panel 2. First of all the applet setup will be ditched upon upgrade, but I don’t see this as a real problem. However interaction with the old gnome-session (especially with saved sessions) could be. This implies a lot of testing if we want to keep this transition separate. It also requires dropping python-gnomeapplet from gnome-python-desktop. I can think of two approaches here. * I’d prefer to get entirely rid of libpanel-applet2-0 and all applets that depend on it. We migrate the new panel to testing, remove them all and re-add them if their upstreams port them to the new API. * We can keep the old API in a different source package that would remain around for some time. However it would mean users could install applets that don’t actually work with the panel, but only with e.g. Xfce. It’s less breakage but more confusion. I’d appreciate the input of the release team on this topic. 10. nautilus This version of nautilus will break all nautilus extensions, which need to be ported to gtk 3. So it will be tied to brasero, file-roller, evince, tracker, totem, gnome-disk-utility, gnome-user-share. For some of these modules it might make sense to drop nautilus support temporarily, but for things like gnome-disk-utility this is simply unrealistic. The desktop icons are no longer drawn by default in nautilus 3.0. The default could be temporarily reverted until the big GNOME transition but currently it is unusable and requires fixing. I also think compatibility with older gnome-session (and saved sessions) will need fixing. For automounting, things are a lot worse. The functionality has been moved to gnome-settings-daemon and changing that would be a lot of work. Therefore, I’d like to know whether the release team would accept to tie this (already big) nautilus transition with the big GNOME transition. 11. The big GNOME transition It implies at least the following packages that need to migrate together. gdm3 gnome-control-center gnome-media gnome-power-manager gnome-screensaver gnome-session gnome-settings-daemon gnome-shell I’m adding libgnomekbd, since all its rdeps are among the list anyway. If nautilus has to be added (and it has unless we spend a lot of time on nautilus changes that will have to be reverted later), this makes the transition much bigger. The same holds for gnome-panel but it should be more easily avoidable. If you know of other libraries that will be involved, please speak up now. If you have read the whole mail, congratulations. ** TL;DR: I’d like to know when we can schedule all of these, and ** ** whether the migration scenarios I have evoked are realistic. ** Thanks, -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
Re: Metapackage strategy for GNOME 3
Le mardi 05 avril 2011 à 02:12 -0500, Kenny Hitt a écrit : I'd like to see gnome-accessibility get moved into gnome-core. I depend on gnome-orca for access to my desktop. I'm thinking if gnome-accessibility was moved into gnome-core then it would be possible to use a gtk based installer with software speech. Currently, I need special hardware to install Debian. I know there is work to get software speech support with speakup into the next installer release, but having additional options would be good. The metapackage gives you what gets installed, but it isn’t used directly within d-i. Using orca from the graphical installer should definitely be possible but it would require making a udeb for it and adding support in the installer. Cheers, -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
Metapackage strategy for GNOME 3
Hi, in order to get GNOME 3 from experimental installable easily by users, I’m considering doing the metapackages soon - even if it means not waiting for everything to be ready. Upstream split their modules between (mostly) platform, core and featured applications, the featured applications list still being far from what we need on a default desktop. I am proposing to keep the gnome-core metapackage and to use it for the core upstream packages. The condition for that is for these to stick on a single CD. This will probably have to be checked afterwards with the CD team. As for the high-level metapackages, I can envision two strategies: * Drop gnome-desktop-environment entirely, only keeping gnome that would include upstream featured apps in addition to the ones we select. * Replace it by gnome-apps that would contain upstream blessed applications, and make gnome depend on gnome-apps. Given the lack of clear upstream rules for featured applications, I’m seeing the first approach work better for the long term. We should probably keep gnome-devel as is. I’d like to use the opportunity to rename gnome-core-devel to gnome-platform-devel, but you can also keep the name. I’m wondering whether gnome-accessibility still makes sense. It probably does no harm keeping it and making gnome-core recommend it, but pushing all of its contents to gnome-core and making accessibility a first-class citizen like upstream does would be nice. I don’t know what to do with gnome-office. We could probably merge its contents directly into gnome, I don’t see the point of a specific package. As for the “mini”-metapackage that is gnome-session, I’m not entirely sure. Given the number of interested people and the number of desktop environments Debian is shipping, I think it makes more sense to propose both GNOME and GNOME fallback as available sessions directly into GDM. This would imply: * gnome-session depending on gnome-shell, mutter, g-s-d, and a few others; * gnome-session-fallback (or -classic, or gnome2-session, or whatever cool name you come up with) depending on gnome-panel, metacity, g-s-d and the same others; * gnome-session recommending gnome-session-fallback; * gnome-core depending on both. The alternative is a single gnome-session depending on both gnome-shell and gnome-panel, and leaving only one way to switch to the fallback mode, in the control center. I think it might be feasible in the future, but I’m expecting too much backlash if we follow upstream on this right now. Thoughts anyone? -- .''`. : :' : “You would need to ask a lawyer if you don't know `. `' that a handshake of course makes a valid contract.” `--- J???rg Schilling -- 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/1301821826.23020.26.camel@pi0307572
Plans for GNOME 3 and GTK 3
Hi, the plans of the GNOME team for GNOME 3 are not entirely complete yet. However there are a number of transitions coming up that you should be aware of. Currently, there is a gobject-introspection transition going on, and the gtk+2.0 / gdk-pixbuf split. These are both prerequisites for gtk+3.0. gtk+3.0 in itself does not create any transition. New libraries that are based on it don’t either, for most of them, since they are co-installable with their gtk2 versions. The problem arises when these libraries cannot, for a reason or another, be in unstable at the same time as the old version. Because of that, it will not be possible to separate the upload of these libraries and transitions involving core GNOME components. One of the problematic libraries is libedataserverui, which will be part of the evolution transition. This one brings gnome-panel, which in turns breaks all existing applets in Debian - and that makes a lot of packages out of the GNOME team control. I will give you a thorough list, with all affected reverse-dependencies, when everything is in experimental. We can then think of strategies to break entanglements if possible. In any case there is no rush, since we don’t know yet whether GNOME 3.0 will be suitable for unstable - I have much better hopes now than a few weeks ago, though. It will probably need some time to be polished enough; if it takes too much time it might be better to wait for GNOME 3.2. So in short, there is no GNOME transition to schedule for now, but it would be nice if you could prepare a big slot for several hairy transitions when we are ready. Thanks, -- .''`. : :' : “You would need to ask a lawyer if you don't know `. `' that a handshake of course makes a valid contract.” `--- J???rg Schilling -- 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/1301501681.6014.58.camel@pi0307572
Re: gnome 3 minimize button (etc)
Le mardi 08 mars 2011 à 10:52 +0900, Miles Bader a écrit : What's convincing? I mean, maximize isn't too much of an issue -- double-clicking on the title bar seems reasonably convenient and intuitive -- but making minimize inconvenient _is_ an issue, especially since there doesn't seem to be a good reason for doing so. With GNOME Shell there’s nowhere to minimize the window too. It would just make it disappear, which would be nonsense. Don’t try to apply the GNOME 2 paradigm to GNOME 3, it’s just different. You can like it or not, but know what you’re talking about before calling people insane. -- .''`. : :' : “You would need to ask a lawyer if you don't know `. `' that a handshake of course makes a valid contract.” `--- J???rg Schilling -- 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/1299584089.13961.159.camel@meh
Re: GNOME 3 and panel applets
Le lundi 07 mars 2011 à 02:01 +0100, David Weinehall a écrit : The panel remains, but it will be a GTK3 / D-Bus panel. In its current state, it doesn’t support the good old GTK2 / bonobo applets, of which we have a lot in the archive. Upstream confirmed they don’t have time to support them for 3.0 unless someone steps up to do the job. This is only partially correct though. gnome-panel will remain, but in a heavily modified state -- the intention for the GNOME 3 version of gnome-panel is having it as a fallback in case gnome-shell isn't supported, and thus a lot of features will be gutted or altered to ensure that it behaves as similar as possible to gnome-shell. AIUI, this is mostly a different default configuration. Nothing prevents us from shipping another one. People who have been expressing concern about this have, reasonably enough, been told that gnome-panel 2.32 is probably what they really want. Are there any plans to provide this package? No. -- .''`. : :' : “You would need to ask a lawyer if you don't know `. `' that a handshake of course makes a valid contract.” `--- J???rg Schilling -- 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/1299485435.3041.125.camel@meh
GNOME 3 and panel applets
[Bcc: all maintainers of GNOME applets] Hi, as it was already mentioned for other reasons, GNOME 3 is just around the corner, and there are some big changes ahead. DO NOT PANIC: the current desktop with gnome-panel and metacity will remain as an alternative. Anyone wanting to troll about how gnome-shell sucks is invited to do so elsewhere, since the topic here is gnome-panel. The panel remains, but it will be a GTK3 / D-Bus panel. In its current state, it doesn’t support the good old GTK2 / bonobo applets, of which we have a lot in the archive. Upstream confirmed they don’t have time to support them for 3.0 unless someone steps up to do the job. If you develop, maintain or use one of those packages, and you don’t want it to disappear, your options are now: 1. Prepare to disable gnome-panel support (that’s for packages which already have other options, such as using the notification area). 2. If meaningful (it depends on the applet), switch to another technology such as libappindicator or the notification area. 3. Port your applet to GTK3 and the new D-Bus API. The bindings for Python and C# will probably not work either, so you might have to start with them. 4. Step up and do the work to add support for bonobo applets in the panel. Option 4 is the only way to keep all applets with low maintenance in Debian. It should be possible by developing a gateway D-Bus service that loads a bonobo applet in a process separate from the panel and proxies signals through it. If you are interested, please get in touch with upstream. If no one is interested, a large portion of the following list is going to leave the archive. David Villa Alises david.vi...@uclm.es ows Sebastien Bacher seb...@debian.org lock-keys-applet mboxcheck-applet netspeed Vincent Bernat ber...@debian.org xnee Michael Biebl bi...@debian.org tracker vinagre (U) Laurent Bigonville bi...@debian.org gnome-mag (U) Salvatore Bonaccorso salvatore.bonacco...@gmail.com giplet Joachim Breitner nome...@debian.org link-monitor-applet Tzafrir Cohen tzaf...@debian.org hdate-applet (U) LI Daobing lidaob...@debian.org lunar-applet 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) Debian Hebrew Packaging Team debian-hebrew-pack...@lists.alioth.debian.org hdate-applet hspell-gui Debian Xfce Maintainers pkg-xfce-de...@lists.alioth.debian.org xfce4-xfapplet-plugin Barry deFreese bddeb...@comcast.net xnee (U) Sebastian Dröge sl...@debian.org deskbar-applet (U) gnome-mag (U) gnome-netstatus (U) gnome-utils (U) hamster-applet (U) mousetweaks (U) ontv (U) seahorse-plugins (U) service-discovery-applet vinagre (U) Diego Fernández Durán di...@goedi.net quick-lounge-applet Baruch Even bar...@debian.org hdate-applet (U) hspell-gui (U) Luca Falavigna dktrkr...@debian.org remmina-gnome Anthony Fok f...@debian.org lunar-applet (U) Pedro Fragoso em...@ubuntu.com hamster-applet Filippo Giunchedi fili...@esaurito.net sensors-applet (U) Rudy Godoy r...@kernel-panik.org xfce4-xfapplet-plugin (U) Gustavo Iñiguez Goya g...@kutxa.homeunix.org gnome-inm-forecast Fabian Greffrath fab...@debian-unofficial.org glunarclock (U) Debian QA Group packa...@qa.debian.org ddccontrol gnome-pilot Jeremy Guitton debo...@free.fr ontv Guido Günther a...@sigxcpu.org window-picker-applet Jerry Haltom was...@larvalstage.net gnome-netstatus Clement 'nodens' Hermann clement.herm...@free.fr tsclient (U) Raphaël Hertzog hert...@debian.org indicator-applet (U) Simon Huggins hug...@earth.li xfce4-xfapplet-plugin (U) Lior Kaplan kap...@debian.org hdate-applet (U) hspell-gui (U) Philipp Kern pk...@debian.org timer-applet Julian Andres Klode j...@debian.org gnome-main-menu Kilian Krause kil...@debian.org tsclient (U) Mario Lang ml...@debian.org gnome-mag (U) John Lightsey light...@debian.org apt-watch Martin Loschwitz madk...@debian.org xfce4-xfapplet-plugin (U) Francois Marier franc...@debian.org verbiste workrave Fladischer Michael fladischermich...@fladi.at panflute Robert Millan rmh.deb...@aybabtu.com gnote Loic Minier l...@dooz.org computertemp (U) gnome-mag (U) gnome-netstatus (U) gnome-utils (U) netspeed (U) service-discovery-applet (U) tsclient (U) Emilio Pozuelo Monfort po...@debian.org deskbar-applet (U) gnome-main-menu (U) gnome-utils (U) hamster-applet (U) mousetweaks (U) ontv (U) seahorse-plugins vinagre Sam Morris s...@robots.org.uk sensors-applet Josselin Mouette j...@debian.org deskbar-applet (U) gnome-mag (U) gnome-netstatus
Re: GNOME 3 and panel applets
Le lundi 14 février 2011 à 23:06 +0530, Joachim Breitner a écrit : Hi, thanks for the heads-up. Am Montag, den 14.02.2011, 18:17 +0100 schrieb Josselin Mouette: 3. Port your applet to GTK3 and the new D-Bus API. The bindings for Python and C# will probably not work either, so you might have to start with them. do you have some pointers to migration guides or similar? There is one for GTK+: http://library.gnome.org/devel/gtk3/stable/gtk-migrating-2-to-3.html As for libpanel-applet itself, I don’t think there is any, so now may also be the time to write one :) AFAIK the only applets that have been ported are the ones from gnome-applets (apart from invest which is in Python), so you might want to have a look at what lies in their git repository. For example gweather: http://git.gnome.org/browse/gnome-applets/commit/?id=445b1ebba673fbc8d4943829c4607c41613cde5e Also, for link-monitor-applet, I need to find out whether gob2 needs to be updated. But it seems that GTK-3 still uses GLib-2, so this might work. Yes, Glib remains compatible. Cheers, -- .''`. : :' : “You would need to ask a lawyer if you don't know `. `' that a handshake of course makes a valid contract.” `--- J???rg Schilling -- 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/1297705956.8791.154.camel@meh
Re: regarding brasero and brasero-cdrkit
Le mercredi 10 novembre 2010 à 13:18 +0200, Tshepang Lekhonkhobe a écrit : What's the reason behind not making brasero Recommends brasero-cdrkit? Because we don’t want no schilyware in the default installation. -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
Re: [Fwd: Re: Debian Ciel -- A Theme Proposal for Squeeze]
Le mardi 19 octobre 2010 à 14:22 +0200, Michael Banck a écrit : http://wiki.debian.org/DebianArt/Themes/debian-ciel What I think needs discussion is changing the GNOME GTK+, window manager and icon themes, possibly . Not all themes are tested equally well tested, and personally, I think it is rather a feature than a bug that we ship with the default theme (Clearlooks, AFAIK). Metacity and icon themes should be open to discussion (with thorough testing for the icon theme) but for GTK+ I think it is ouf of question, given the too short timeframe we have to test the theme correctly. Even a change in the default colors can lead to some applications being rendered in an unreadable way. -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
Re: [Fwd: Re: Debian Ciel -- A Theme Proposal for Squeeze]
Le mercredi 20 octobre 2010 à 00:09 +0200, Michael Banck a écrit : Can you summarize what the difference between the currently used icon theme, the Tango! theme and gnome-brave is? Is gnome-brave a color-modified version of tango? I guess the Tango icons are very well established and should be less of a problem to use (though I was under the impression that the current icon theme was actually tango already) My personal experience with icon themes is that it takes a long while to ensure that all icons have a similar look, and that no icon inherited from another theme will look bad along with them. It doesn’t look interesting to me to switch an icon theme just to have blue folder icons that don’t look nice with other ones. Cheers, -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
Re: on tracker-gui
Le lundi 04 octobre 2010 à 11:02 +0200, Tshepang Lekhonkhobe a écrit : Josselin once mentioned that it's preferable to have a meta-gnome2 alternatives if the new entrant is a drop-in replacement. In the case of meta-gnome2 2.30+2, tracker-gui is set to be an alternative of gnome-search-tool, even though it's not even close to gnome-search-tool offers, and will be removed from Tracker in favor of some other supposedly superior UI. Any justification? The justification is to provide a tool for full-text search that can rely on tracker if it is installed. If tracker-gui is replaced later by a better tool, I cool with the idea, but currently it’s what we have. Do you have an alternative approach to propose? Cheers, -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
Re: Anjuta in squeeze
Le dimanche 03 octobre 2010 à 00:05 +0200, Mehdi Dogguy a écrit : On 10/02/2010 01:50 PM, Josselin Mouette wrote: What does this leave us for squeeze? * [...] * Shipping this patched 2.32 version which should be much more stable. Go ahead for this one. I’ve uploaded anjuta/2:2.32.0.0-3 and anjuta-extras/2.32.0.0-2 to unstable. I’ll request an unblock when they have matured for a while. Cheers, -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
Anjuta in squeeze
Hi all, I’m very worried about the situation of anjuta in squeeze. In version 2.26 anjuta moved all the function indexing code in a new “symbol-db” plugin, which is based on libgda (and in turn sqlite). Don’t be mislead by the “plugin” name, it’s mandatory. This caused all kinds of packaging problems, but nothing too dramatic. Until now. Now, after giving version 2.30 to some of our users with heavy codes in their hands, it appears that this version is still not ready, causing important stability problems. It’s hard to tell on what scale, but a crashing IDE is something that would annoy me a *lot*. Upstream is well aware of that, and their bugzilla is full of memory corruption bugs, which, along with huge performance issues, caused them to rewrite the whole symbol-db code in a cleaner fashion for 2.32, without providing any bugfixes for this code in the stable 2.30 branch. To make things worse, the new code requires a new libgda, along with a few other libraries not in unstable. I have prepared anjuta/anjuta-extras 2.32.0.0 packages in experimental, with a few small patches to remove the new libraries requirement, so that it has the possibility to migrate to squeeze eventually. However the code changes are fairly large, mostly because of this symbol-db rewrite. What does this leave us for squeeze? * Shipping 2.30.2 with its stability problems, with no upstream support and no hope to really fix them. * Shipping this patched 2.32 version which should be much more stable. * Going back to anjuta 2.24, which used to be stable too, or even the 2.4 version from lenny. * Dropping anjuta from the release, and recommending something else instead (probably monodevelop). I’m leaving the decision in the RT’s hands. Cheers, -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
Re: Anjuta in squeeze
Le samedi 02 octobre 2010 à 15:04 +0100, Luis Matos a écrit : I am an anjuta user and i like 2.30 a *LOT* more than 2.24, ainly because of symbol-db. I have been presented with some crashes, but few of them and recently none (i thought they had been fixed :) ). To be fair, some of the crashes have been fixed in 2.30.2, but the memory corruption and performance issues, that both show up mostly when dealing with large projects, have not gone away. I would prefer squeeze to ship 2.32. Me too, but it’s out of my hands now :) Cheers, -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
A first look at GNOME 2.32 - squeeze status
Hi, GNOME 2.32 is just around the corner. As it was expected, a large number of modules have only seen bug fixes and translations, which makes it possible to consider them for squeeze. We are not going to ship anything that includes dependencies on GDBus, GSettings, or GTK+ 2.22. Add to that anything that means a SONAME change. Still, there is a list of modules that we can consider. Note that this list was made quickly, based on what’s in today’s git. If e.g. some modules migrate to GSettings before the release, or if it turns out the changes are too large at this state of the freeze, let’s just skip them. The goal here is to pick things that are likely to fix bugs, not things that introduce new ones. * accerciser : OK * alacarte : OK * anjuta : NO (glib 2.26) * at-spi : OK (but see what is this relocate thing) * atk1.0 : OK (although beware of the shlibs bump) * brasero : NO (gsettings) * bug-buddy : OK * cheese : OK * control-center : NO (new g-s-d) * dasher : OK * deskbar-applet : OK * devhelp : NO (soname change) * ekiga : Looks OK but large changes * eog : NO (gdbus) * epiphany-browser : goes on as 2.30.x * evince : NON (gsettings, gtk 2.22) * evolution-* : in your dreams * file-roller : NO (gdbus) * gcalctool : NO (gsettings) * gconf : NO (gsettings) * gconf-editor : OK * gdl : there is no 2.32 branch (maybe a 2.30 release?) * gdm3 : this would be suicidal * gedit : there is no 2.32 branch (maybe a 2.30 release?) * glade-3 : there is no 2.32 branch (maybe a 2.30 release?) * glib : NO * gnome-applets : NO (new gnome-panel) * gnome-backgrounds : OK * gnome-bluetooth : NO (GSettings) * gnome-common : NO (don’t mess with build tools) * gnome-desktop : OK * gnome-devel-docs : OK * gnome-disk-utility : OK * gnome-doc-utils : NO (don’t mess with build tools) * gnome-games : looks OK but heavy changes * gnome-icon-theme : looks OK but lots of changes * gnome-keyring : NO (GSettings) * gnome-mag : OK if there is a release * gnome-media : OK * gnome-menus : OK - all development still done as 2.30 * gnome-netstatus : OK * gnome-nettool : OK * gnome-orca : OKish but lots of changes * gnome-panel : NO (soname bump, lots of changes) * gnome-power-manager : OK * gnome-python : OK if there is a release * gnome-python-desktop : NO (only useful for new evince) * gnome-screensaver : OK * gnome-session : OK except maybe one commit to revert (GTK+ 2.22 requirement) * gnome-settings-daemon : NO (GTK 2.22) * gnome-system-monitor : OK * gnome-system-tools : NO (GSettings) * gnome-terminal : NO (Glib 2.26) * gnome-themes : OK (but carefully) * gnome-user-docs : OK * gnome-user-share : OK * gnome-utils : OK * gnome-vfs : OK * gok : OK * gtk+ : NO * gtk-engines : OK (but beware of Xfce interactions) * gstreamer-* : probably not * gtkhtml3.14 : looks OK but not recommended without doing evo too * gtksourceview : no 2.32 branch (maybe a 2.30 release?) * gucharmap : OK * gvfs : OK * hamster : looks OK but large changes * libbonobo : only from the 2.30 branch * libbonoboui : OK * libgnome-keyring : OK * libgnome : OK (ditches libesd) * libgnomecanvas : OK * libgnomekbd : OK but shlibs bump * libgnomeprint : OK (although we should try to remove it instead) * libgnomeprintui : ditto * libgnomeui : OK * libgtop : OK * libgweather : only from the 2.30 branch * liboobs : NO (soname change) * librsvg : OK (but shlibs bump) * libsoup : OK * libwnck : OK (development is done as 2.30) * metacity : OK but requires reverting a gdk 2.22 commit (like gnome-session) * mousetweaks : NO (gdbus) * nautilus : OK (gdbus, gtk 2.22) * nautilus-sendto : only from 2.28 branch * pango1.0 : maybe (there might also be a 1.28 release) * pygtksourceview : NO (new gtksourceview) * seahorse : OK * seahorse-plugins : OK * sound-juicer : OK * totem : NO (new glib) * totem-pl-parser : OK (master is 2.30) * vinagre : NO (gtk 2.22) * vino : OK * vte : OK but maybe not useful without the new gnome-terminal * yelp : only in 2.30 branch (requires merging into webkit branch) * zenity : OK Black helicopters will be sent to anyone who uploads a module marked “NO” to unstable without a serious justification. For other modules I recommend a lot of care to not introduce broken stuff into a frozen distribution. GNOME 2.30 was one of the greatest GNOME releases ever, so let’s not break it. If you see anything related to GApplication, GtkApplication, GSettings, or GDBus, just flee. In case of doubt, ask the release team before uploading to unstable. -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
Re: gsettings-desktop-schemas
Hi, Le jeudi 02 septembre 2010 à 11:36 +0200, Tanguy Ortolo a écrit : I tried to use gsettings-desktop-schemas from source, but it needs compiling, with a tool called gschema-compile, that is not yet packaged too. Do you know if there are plans to package these? I think they will get more used on the future, and maybe become mandatory for GNOME. Unfortunately, I do not know these GNOME things very well. It is planned to package gsettings-desktop-schemas of course, but it is low priority since it will not be included in squeeze. Everything you need for GSettings is in libglib2.0-bin in experimental. Cheers, -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
GNOME 2.32 plans
Hi, as some of you might have heard, there is going to be a GNOME 2.32 release in September, GNOME 3.0 being delayed to next spring. For a large number of modules, 2.32 is going to be a pure bugfix release based on 2.30. Therefore I propose the following approach: * For bugfix releases, we upload them to unstable and try to put them in squeeze. * For modules requiring GSettings, we keep the 2.30 version, maybe with some backported bugfixes. GSettings is simply too fresh, we don’t have enough hindsight and we don’t want to have to direct users through 2 different configuration mechanisms. * For modules not requiring GSettings but requiring other new features in Glib or GTK+ 2.x, see later. I doubt we will have many such modules. Then there’s the case of Glib. Glib 2.26 will be backwards compatible, but the introduction of GSettings causes some packaging changes. I’m not too fond of risking to break reverse dependencies. Having this version in squeeze will depend on the calendar, but I’m not too fond of risking to break thousands of reverse dependencies. I guess we’ll have to see how the freeze is coming when it’s out. For GTK+ 2.22, things are in a similar state. Even larger packaging changes are being introduced because gdk-pixbuf was split in a separate module. However I’d prefer to see it in squeeze, otherwise backporting GTK+ 3.0 will be very hard. Of course I’m only proposing it since it doesn’t use GSettings. For GTK+ 3.0, the plan is to rely on backports since we don’t even have a release date. If we ever happen to see it available during early freeze time, we can try to squeeze it in. But in any case, direct or indirect dependencies of meta-gnome2 must not depend on it. It would be just so that GTK+ 3 applications can be built on squeeze without backports. Do you think this is realistic? -- .''`. : :' : “Fuck you sir, don’t be suprised when you die if `. `' you burn in Hell, because I am a solid Christian `-and I am praying for you.” -- Mike -- 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/1280910279.449.21.ca...@meh
Re: GNOME 2.32 plans
Le mercredi 04 août 2010 à 17:21 +0200, Emilio Pozuelo Monfort a écrit : I'd say it depends on when the RT plans to freeze the archive. If soon (e.g. this month) maybe we should just release with 2.30? But if they don't plan to release anytime soon, updating GLib and GTK+ doesn't bad to me, although I don't see much benefits in updating GLib. The benefit of updating Glib is to be able to upload GTK+ 2.22 - which in turn is necessary if we want GTK+ 3.0 backports to work. -- .''`. : :' : “You would need to ask a lawyer if you don't know `. `' that a handshake of course makes a valid contract.” `--- J???rg Schilling -- 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/1280938451.449.34.ca...@meh
Re: Debian desktop support for virtualisation
Le dimanche 27 juin 2010 à 01:40 +0100, Roger Leigh a écrit : On Fri, Jun 25, 2010 at 01:46:41PM +0200, Josselin Mouette wrote: You may also need (but I haven’t checked): * /var/run/cups for printing * /var/run/avahi-daemon and some others that I’m forgetting. Thanks! I think we now have most of these. We don't preserve the environment by default (you have to use the -p option), but we could make that automatic in a future release by adding a new configuration option. You should definitely pass the following environment variables without asking, since GNOME applications won’t work without them: DISPLAY XAUTHORITY ORBIT_SOCKETDIR DBUS_SESSION_BUS_ADDRESS The following shouldn’t hurt as well. Terminal: TERM COLORTERM XSMP support (probably doesn’t work in a chroot): SESSION_MANAGER gnome-keyring (only the SSH stuff works across the lenny→squeeze upgrade): SSH_AGENT_PID SSH_AUTH_SOCK GNOME_KEYRING_CONTROL GNOME_KEYRING_PID seahorse: GPG_AGENT_INFO Used by xdg-utils and debianutils scripts: XDG_SESSION_COOKIE DESKTOP_SESSION GNOME_DESKTOP_SESSION_ID GTK+ modules to load: GTK_MODULES GTK_IM_MODULE Language: LANG LC_* We definitely have /tmp and all of /var/run so most of the above should be catered for. Passing all of /var/run looks a bit dangerous to me since it could lead some scripts in the chroot believe that a daemon is started in the chroot. I’m not sure if that’s a real problem, but you should probably at least print a warning somewhere. If anyone on the lists is using schroot for desktop applications, I'm currently uploaded schroot version 1.4.5-1 which adds a desktop configuration profile. Just set script-config=desktop/config in your chroot definition. Great! -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
Re: Debian desktop support for virtualisation
Le jeudi 24 juin 2010 à 19:18 +0100, Roger Leigh a écrit : schroot is commonly used for this task, and I'm adding a desktop configuration profile, which I'd like to work out of the box to allow desktop applications to run inside a chroot. More detail is given below, and in the full bug report. Basically, I'd like to add whatever pieces are needed from the host system, be it bind mounting filesystems, making sure the needed services are accessible, copying over configuration etc. Anything that makes using a chroot more transparent and accessible to users is on the cards. If anyone has already added customisations to schroot to make this work, sharing your configuration details would also be useful. For GNOME, most things are done through X11 (with the root window), D-Bus and GConf. This means you need: * a bunch of environment variables * /tmp for the X11 sockets, the session bus, GConf, seahorse and gnome-keyring * /var/run/dbus for the system bus * starting with gdm3, /var/run/gdm3 for the xauth file You may also need (but I haven’t checked): * /var/run/cups for printing * /var/run/avahi-daemon and some others that I’m forgetting. Cheers, -- .''`. : :' : “Fuck you sir, don’t be suprised when you die if `. `' you burn in Hell, because I am a solid Christian `-and I am praying for you.” -- Mike -- 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/1277466401.10458.17.ca...@meh
Re: Decoupling GNOME 2.30 transitions
Le mardi 20 avril 2010 à 12:19 +0200, Luca Bruno a écrit : 2 - gnome-desktop (libgnome-desktop-2-11 → libgnome-desktop-2-17) Binary NMUs: avant-window-navigator awn-extras-applets Any news on this? Awn 4.0 was released recently, and I'm still waiting to upload the needed library... The gnome-desktop transition has just started, so I think you can do that as soon as it is finished (but maybe double-check with -release). Cheers, -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
Re: tracker 0.8 transition
Le lundi 12 avril 2010 à 18:35 +0200, Michael Biebl a écrit : nautilus (2.28 links against libtrackerclient, 2.30 uses dlopen) Be it only for that, I’d prefer to do it after the gnome-desktop transition (which implies uploading nautilus, control-center and gnome-settings-daemon 2.30). The question remains, whether to do it before or after evolution, since it would be entangled with it. Question: have you checked whether nautilus 2.30 tracker support has the bug GTK+ originally had? It used to assume that when the library is available, the daemon is too, and didn’t try to make a connection to it. Cheers, -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
Re: tracker 0.8 transition
Le lundi 12 avril 2010 à 22:35 +0200, David Weinehall a écrit : Isn't the evolution transition still blocked by http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=565809 Unlike what I originally thought, it is not a problem for the transition, since evolution-mapi is not in testing. Cheers, -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
Re: Sudo mode and policykit
Le vendredi 26 mars 2010 à 15:15 -0300, Margarita Manterola a écrit : On Fri, Mar 26, 2010 at 6:42 AM, Josselin Mouette j...@debian.org wrote: In squeeze, with consolekit installed, a lot of groups are made obsolete: audio, netdev, powerdev, plugdev, video (modulo a number of buggy packages remaining), probably bluetooth. In the end, floppy and cdrom could go away as well. We are actually improving in this direction. I'm very glad to hear this. However, I'm worried that I (and I think many others too) have no idea how to handle having users with the appropriate permissions without the groups. I looked up the information about consolekit, and couldn't find any reference for this either. It is done by /lib/udev/rules.d/70-acl.rules. I very recently installed squeeze with KDE, and the way to allow the second user to access to USB devices and similar stuff was to add that user to the same groups the first user had been added. This should not be necessary anymore. Cheers, -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
Sudo mode and policykit
Hi, currently, depending on the “sudo mode” which is set during installation, d-i configures gksu to use sudo mode by default (with a GConf key). However, an increasing number of packages use policykit instead of gksu to obtain root access, so we need some changes on this matter. Actually there are two very simple solutions, so it is really a matter of what design you prefer. 1. (Stolen from Ubuntu) Create a new “admin” group, modify policykit to accept self-authentication for all members of the admin group. Let d-i simply add the user to group admin if in sudo mode. Bonus points for using the admin group in sudo too instead of hardcoding the username. 2. Let d-i create a file somewhere in /etc/polkit-1 that will add the created user to the list of users authorized to self-authenticate. In both cases the modifications to d-i should be very straightforward, but I think this needs to be done for squeeze for the sake of consistency. Cheers, -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
Re: Inclusion in Uploaders:
Le jeudi 04 mars 2010 à 20:07 +0100, David Weinehall a écrit : I'm a member of the pkg-gnome team on alioth, but that apparently doesn't mean automatic inclusion in the gnome-pkg-tools list of uploaders; what exactly is needed for this? Should I add myself to that package first in the subversion repository, and make an upload up that package, or do I need someone to vouch for me? If you only intend to do this for a handful of packages, you can just add yourself to the Uploaders field in control.in. Otherwise, the full list is in the gnome-pkg-tools package, which is in the same subversion repository (in the tools/ toplevel). BTW, since you’re already on IRC, it would be better if you could come on #debian-gnome sometime; this is where we usually synchronize, more than on the list. Cheers, -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Debian/GNOME bug triage week-end: 20-21 february 2010
Given the enthusiasm, I propose the 20-21 february to hold this bug triage weekend. Come on #debian-gnome and join the party! -- .''`. Josselin Mouette : :' : `. `' “A handshake with whitnesses is the same `- as a signed contact.” -- Jörg Schilling -- To UNSUBSCRIBE, email to debian-gtk-gnome-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
CORRECTION: Debian/GNOME bug triage week-end: 27-28 february 2010
Sorry about the mess, but I’m the one who’s unavailable the 20-21 february. Therefore I propose the week-end of 27-28 february. I’ll make a broader announcement later. -- .''`. Josselin Mouette : :' : `. `' “A handshake with whitnesses is the same `- as a signed contact.” -- Jörg Schilling -- To UNSUBSCRIBE, email to debian-gtk-gnome-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug triage week-end
Hi, some time ago, someone (was it HE?) proposed to reserve a week-end during we would try to close, forward and fix as many as possible of the bugs reported on the team-maintained packages. It didn’t turn into reality until now, but I’d like to bring back the idea. It would be very welcome to reduce the number of bugs, and it would be a perfect time for newcomers to learn about GNOME packages. Would you people be available for an upcoming week-end during February? Cheers, -- .''`. Josselin Mouette : :' : `. `' “You did never write something helpful `- besides your trolling” -- Jörg Schilling -- To UNSUBSCRIBE, email to debian-gtk-gnome-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: How to break circular Build-Depends between gir-repository and gstreamer?
Le vendredi 27 novembre 2009 à 11:24 -0800, Daniel Schepler a écrit : In fact, it doesn't have direct Build-Depends on gstreamer. The problem here is that it Build-Depends on webkit and (indirectly) tracker, which both Build- Depend on gstreamer. I’ve asked the webkit maintainers to build the introspection data directly in webkit, so that the build-dependency can be removed. As for Tracker, you’d have to explain how this indirect dependency happens. Cheers, -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: One True DPI
Le vendredi 20 novembre 2009 à 09:33 -0600, Peter Schultz a écrit : Gnome's font settings do not allow me to go any lower than 50. I know 44 DPI is very low for today's desktop monitors, but it makes for an excellent big screen TV. Shouldn't I be able to set this to 44 if that's what my monitor has? The code at fault is this one: http://git.gnome.org/cgit/gnome-settings-daemon/tree/plugins/xsettings/gsd-xsettings-manager.c /* X servers sometimes lie about the screen's physical dimensions, so we cannot * compute an accurate DPI value. When this happens, the user gets fonts that * are too huge or too tiny. So, we see what the server returns: if it reports * something outside of the range [DPI_LOW_REASONABLE_VALUE, * DPI_HIGH_REASONABLE_VALUE], then we assume that it is lying and we use * DPI_FALLBACK instead. * * See get_dpi_from_gconf_or_server() below, and also * https://bugzilla.novell.com/show_bug.cgi?id=217790 */ #define DPI_FALLBACK 96 #define DPI_LOW_REASONABLE_VALUE 50 #define DPI_HIGH_REASONABLE_VALUE 500 Maybe you can request the minimum to be lowered if you have an example of hardware with such a low resolution. Please file a bug upstream, against the gnome-settings-daemon component. Cheers, -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Please test experimental gvfs packages
Hi, since Michael Biebl fixed IDE CD support in devicekit-disks, the GDU-enabled version of gvfs (currently in experimental) should be usable again. Before uploading it to unstable, I’d appreciate if some adventurous people could test it and report any regressions. Thanks, -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: GObject introspection mini-policy, take 2
Le dimanche 27 septembre 2009 à 10:59 +0800, Paul Wise a écrit : gir1.0-foo-2.0 /usr/lib/girepository-1.0/Foo-2.0.typelib Would this proposal need to be adjusted for multiarch support? I’m not sure. It will be mostly used by interpreters, which themselves don’t need support for multiarch with the current state of the proposal. Cheers, -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: Fixing the Gobject Introspection mess
Le samedi 26 septembre 2009 à 07:56 +0200, Sebastian Dröge a écrit : Am Freitag, den 25.09.2009, 13:32 +0200 schrieb Josselin Mouette: 1. Package layout GObject-introspection packages provide introspection data in /usr/share/gir-1.0/Foo-X.Y.gir, and the optional /usr/lib/girepository-1.0/Foo-X.Y.typelib. The packages should be architecture-dependent. Only the typelib file actually is meant to be architecture-dependent (right, the GIR file could be arch-dep too if the headers and API parts of the sources (GObject properties/signals) are different from arch to arch. But who does that?!). This has already happened, and this will happen again. For the same reason we make headers architecture-dependent, I think we should make GIR files the same. Also the GIR file is only meant for build time things so it could simply be placed in the -dev packages (as I've done so far). There is no “build time” for interpreters. What do you mean exactly? Putting the typelib files in the shared library packages will create conflicts for soname changes. Not good (I know I placed them there in some packages). Creating a new package just for the typelib file is not good either ;) Agreed. We should probably mandate to always split the introspection files in a separate package. Cheers, -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
GObject introspection mini-policy, take 2
After an insightful discussion with Sebastian, and taking into account
other suggestions from the list, here is a new proposal.
1. Directory layout
GObject-introspection data is generally provided in two formats:
* XML format in /usr/share/gir-1.0/Foo-X.Y.gir
* binary format in /usr/lib/girepository-1.0/Foo-X.Y.typelib
2. Binary introspection packages
The binary typelib file must be put in an architecture-dependent package
named after its namespace. The name should be gir1.0-NAMESPACE-VERSION.
For example, the package containing WebKit-1.0.typelib will be named
gir1.0-webkit-1.0.
Giant repositories of unrelated introspection data should be avoided.
(Under this rationale, gobject-introspection-repository will be split.)
However, related libraries that are known to evolve together can live in
the same package (example: Gst*-0.10).
Introspection packages belong in section libs for the moment. If there
are enough packages to justify it, a new section will be requested to
the FTP masters.
3. XML introspection data
The XML format introspection must be shipped in another
architecture-dependent* package of the same source.
* This is so that it is guaranteed to be accessible at
build time by the tool that will compute the
dependencies for the .typelib files.
If the source package also contains the library itself, this data should
be in the development binary package. If the introspection data is split
from the library source (e.g. for gobject-instrospection-repository), a
separate package containing this XML data can be created, in section
libdevel.
The package containing the XML data doesn’t need to depend on the
introspection package. It can contain XML data for several unrelated
libraries, since in the end it doesn’t depend on them.
4. Dependencies of introspection packages
Introspection packages must depend on the libraries they reference, with
a sufficient version for the symbols they reference.
For that effect, I propose to introduce a new helper, dh_girepository,
in the gobject-introspection package (which is already a
build-dependency for introspection packages). It would wrap
dpkg-shlibdeps so that the dependencies are the same as those of similar
ELF binaries.
Introspection packages must depend on other introspection packages that
are referenced through include statements. The helper should generate
such dependencies as well.
Packages containing the XML data don’t need any specific new
dependencies.
5. Dependencies on introspection packages
Currently, there are only Seed (JavaScript) scripts to use these
introspection packages. In the future, there might also be Python or
other interpreted languages.
Generating dependencies automatically for interpreted languages is not
reliable. Therefore, these packages must depend by hand on the
appropriate gir1.0-* packages. The interpreters themselves don’t need to
depend on packages they don’t use directly.
6. Example
Suppose that libfoo-2.0 is an API built on libbar-3.0. The libfoo-2.0
source generates the following files, put in the following packages:
libfoo-2.0-3 /usr/lib/libfoo-2.0.so.3*
libfoo-2.0-dev /usr/lib/libfoo-2.0.so (and other usual stuff)
libfoo-2.0-dev /usr/share/gir-1.0/Foo-2.0.gir
gir1.0-foo-2.0 /usr/lib/girepository-1.0/Foo-2.0.typelib
libfoo-2.0-dev Depends: libfoo-2.0-3, libbar-3.0-dev
gir1.0-foo-2.0 Depends: ${gir:Depends} which expands to:
libfoo-2.0-3, gir1.0-bar-3.0
If foobar is a package containing the following JS script:
#! /usr/bin/seed
Foo = imports.gi.Foo;
// Stuff that uses the Foo 2.0 API
Then foobar Depends: gir1.0-foo-2.0
I’ve started preliminary work on dh_girepository. The first version will
be a bit hackish and will rely on building an intermediate binary
referencing the appropriate symbols that will be fed to dpkg-shlibdeps.
Doing better will require extending dpkg-shlibdeps so that it accepts
another input format than ELF (it doesn’t have to be the GObject XML
format, it could be anything easy to generate).
--
.''`. Josselin Mouette
: :' :
`. `' “I recommend you to learn English in hope that you in
`- future understand things” -- Jörg Schilling
signature.asc
Description: Ceci est une partie de message numériquement signée
Re: Fixing the Gobject Introspection mess
Le samedi 26 septembre 2009 à 13:12 +0200, Sebastian Dröge a écrit : There is no “build time” for interpreters. What do you mean exactly? Interpreters should use the typelib file and not the GIR file. The GIR file is meant for generating bindings (like the current Python/C++/C# bindings) while the typelib file is meant to be used at runtime to generated bindings on the fly. OK, then I agree the .gir file should go in a separate development package. But that will make dependency computation more difficult, since it will have to be done from the .typelib file. Time to dig deeper into the libgirepository API… So you would always put the GIR and typelib files into a single separate package? Or only the typelib file? IMHO only the latter would make sense, the GIR file can/should be in the -dev package, and if only because of space savings. Yes, agreed. -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Fixing the Gobject Introspection mess
Hi, with an increasing number of packages providing introspection data for Gobject, each one doing things its own way, it’s starting to be a big mess. I’d like to fix this mess before we have a hundred different packages, all behaving differently. Which is why I’m proposing a Gobject-introspection mini-policy. And of course, to implement it in existing packages. 1. Package layout GObject-introspection packages provide introspection data in /usr/share/gir-1.0/Foo-X.Y.gir, and the optional /usr/lib/girepository-1.0/Foo-X.Y.typelib. The packages should be architecture-dependent. 2. Naming scheme The package should be named gir1.0-foo-X.Y. For example, the package containing WebKit-1.0.gir will be named gir1.0-webkit-1.0. Giant repositories of dozens of unrelated introspection data should be avoided. (Under this rationale, gobject-introspection-repository will be split.) However, related libraries that are known to evolve together can live in the same package (example: Gst*-0.10). If, alternatively, the introspection data belongs in the same source package as the library it references, it can be put in the same binary package. In this case, it must feature a Provides: field corresponding to the name of the introspection data. For example, libfoo2.0-2 containing libfoo-2.0.so.2 and Foo-2.0.gir must provide gir1.0-foo-2.0. Introspection packages belong in section libs for the moment. If there are enough packages to justify it, a new section will be requested to the FTP masters. 3. Dependencies of introspection packages Introspection packages must depend on the libraries they reference, with a sufficient version for the symbols they reference. For that effect, I propose to introduce a new helper, dh_gir, in the gobject-introspection package (which is already a build-dependency for introspection packages). It would wrap dpkg-shlibdeps (possibly using its internals until the needed interfaces are exported) so that the dependencies are the same as those of similar ELF binaries. Introspection packages must depend on other introspection packages that are referenced through include statements. The helper should generate such dependencies as well. 4. Dependencies on introspection packages Currently, there are only Seed (JavaScript) scripts to use these introspection packages. In the future, there might also be Python or other interpreted languages. Generating dependencies automatically for interpreted languages is not reliable. Therefore, these packages must depend by hand on the appropriate gir1.0-* packages. The interpreters themselves don’t need to depend on packages they don’t use directly. Thoughts anyone? I’ll start working on dh_gir as described if there is consensus on the proposed policy. Once implemented in a few packages, the policy would be put in a more formal way and added to gobject-introspection. Cheers, -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: Fixing the Gobject Introspection mess
Le vendredi 25 septembre 2009 à 13:44 +0200, Julien Cristau a écrit : On Fri, Sep 25, 2009 at 13:32:54 +0200, Josselin Mouette wrote: If, alternatively, the introspection data belongs in the same source package as the library it references, it can be put in the same binary package. In this case, it must feature a Provides: field corresponding to the name of the introspection data. For example, libfoo2.0-2 containing libfoo-2.0.so.2 and Foo-2.0.gir must provide gir1.0-foo-2.0. Doesn't this break co-installability of libfoo2.0-X and libfoo2.0-Y, if both install Foo-2.0.gir? Good point. Maybe we can recommend this solution only for libraries where this is not expected to happen. Or, given the (large) size of introspection stuff, to mandate having it always split. -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Nautilus hiccup in unstable
Hi, in my haste to fix #545254, I have uploaded nautilus 2.28.0 a bit too early. If you have not upgraded yet, please don’t install 2.28.0-1! If you have already upgraded, you should install 2.28.0-2 as soon as it is available, and then remove any ~/.nautilus/metafiles/migrated-to-gvfs files. This way you will find back your metadata (icon positions on the desktop, window sizes, emblems…) at the next login. Sorry for the inconvenience. Cheers, -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: WANTED: Perl / GTK+ hacker
Le samedi 15 août 2009 à 11:26 +0200, Josselin Mouette a écrit : Since the guy who originally wrote it (Eric Gillespie) is no longer part of the project, I’m looking for a developer who knows Perl enough to make a port to GTK+. The largest part of the problem is porting from GnomeDruid to GtkAssistant, which probably only requires a few hours for a knowledgeable person. Apparently an Ubuntu developer decided to do it at the same moment. See http://bugs.debian.org/542175 Cheers, -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: WANTED: Perl / GTK+ hacker
Le samedi 15 août 2009 à 17:21 +0300, Kalle Olavi Niemitalo a écrit : The back button of GtkAssistant seems troublesome. In GnomeDruidPage, the back and next buttons just emit signals, which Debconf::FrontEnd::Gnome then handles by exiting the main loop and returning '' or 1 from sub go. In GtkAssistant however, the back button backtraces a private visited_pages list, and it is automatically hidden when this list is empty. (b) Handle the clicked signal from the back button and make the button visible against the wishes of GtkAssistant. If the visited_pages list remains empty at all times, then the handler added by GtkAssistant does nothing, and there is no need to remove it. This is probably the right behavior, and mimics what the current GnomeDruid frontend does. BTW, if debconf does not use the page sequencing ability of GtkAssistant, what’s the point of using it at all? You can just define a GtkDialog with 3 buttons (GTK_STOCK_GO_BACK, GTK_STOCK_CANCEL and GTK_STOCK_GO_FORWARD), add whatever handlers you want to these buttons, and use GtkDialog-run which removes the need from exiting manually from the main loop. How does it sound? -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
WANTED: Perl / GTK+ hacker
Hi, the GNOME backend for Debconf is slightly outdated nowadays. It uses some APIs that are being deprecated, and there are now solutions to make the same things with less dependencies. Since the guy who originally wrote it (Eric Gillespie) is no longer part of the project, I’m looking for a developer who knows Perl enough to make a port to GTK+. The largest part of the problem is porting from GnomeDruid to GtkAssistant, which probably only requires a few hours for a knowledgeable person. Any volunteers? -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: Evince libraries evdocument and evview
Le jeudi 21 mai 2009 à 23:37 +0200, Luca Bruno a écrit : libevview and libevdocument haven't been packaged as development libraries. Conseguently, no bindings in any language have been built for them. I've realized they were missing since I needed them to render some documents in my application. I've worked a bit on packaging them together by creating libevince1 and libevince-dev (like libgnome-media0). Can I proceed? I didn’t think they were needed by other applications, so that’s why the development libraries are not packaged. In all cases, you need to check whether they can work with both evince and evince-gtk. If possible, it might also be interesting to split out the backends in a separate package so that both evince and evince-gtk can use the same. Cheers, -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: GNOME 2.26
Le jeudi 21 mai 2009 à 10:41 +0200, Michael Ott a écrit : Unless more than one person starts working on it, it is becoming clear to me that the plan is to wait for a very long time. What do you mean with that sentence? You are the only one in the Gnome team? How can I help when I am not a maintainer? Actually that’s a bit of an exaggeration, but apart from Luca Bruno and I, other maintainers don’t seem so eager to see GNOME 2.26 packaged. Let me also add that #517768 is a blocker for large parts of GNOME 2.26 and that we will be able to go forth only when it is fixed. Note that in the meantime, I have reassigned it so that it is not a blocker anymore. It is still a blocker for squeeze, of course, but it’s not blocking the transition anymore. If you want to help, start by reproducing this (MIME cache version 1.0 in your home, version 1.1 in the system, using nautilus 2.26) and try to understand why the 1.0 cache is not simply ignored by the xdgmime code in glib2.0. Sorry for the stupid question. How can I find out which mime version I use. I do not have this problem and I use nautilus 2.26. The home directory cache is only created when you add new MIME types at the user level. To create a 1.0 version cache, you need the pre-GNOME 2.24 tools: shared-mime-info 0.30, nautilus 2.22 + glib 2.17 or nautilus 2.20 + gnome-vfs 2.22. Cheers, -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: GNOME 2.26
Le mercredi 20 mai 2009 à 10:01 +0200, Johannes Rohr a écrit : sorry for nagging, but what is the plan for GNOME 2.26? Unless more than one person starts working on it, it is becoming clear to me that the plan is to wait for a very long time. -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: GNOME 2.26
Le mercredi 20 mai 2009 à 12:00 +0200, Josselin Mouette a écrit : Le mercredi 20 mai 2009 à 10:01 +0200, Johannes Rohr a écrit : sorry for nagging, but what is the plan for GNOME 2.26? Unless more than one person starts working on it, it is becoming clear to me that the plan is to wait for a very long time. Let me also add that #517768 is a blocker for large parts of GNOME 2.26 and that we will be able to go forth only when it is fixed. If you want to help, start by reproducing this (MIME cache version 1.0 in your home, version 1.1 in the system, using nautilus 2.26) and try to understand why the 1.0 cache is not simply ignored by the xdgmime code in glib2.0. Cheers, -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Let’s remove scrollkeeper
Hi, is anyone aware of some leftovers that scrollkeeper can handle and rarian-compat cannot? If there are still some, we can handle them just like this was done for the DTDs since I’d like to ask for the removal of scrollkeeper. Once this is done, I propose to add a trigger to rarian-compat and to deprecate dh_scrollkeeper entirely. I don’t know what we should do to remove scrollkeeper from the users’ desktops. Currently gnome-core forces the dependency on rarian-compat, maybe we should do the same with some other packages. Cheers, -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Subversion cleanup
Hi, I just disabled SVN access on pkg-gnome for most of those who didn’t commit in the last year to the repository. Please don’t hesitate to ask if you feel I have removed you by mistake, of course. Cheers, -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Preparing for GTK 3.0 and GNOME 3
Hi, although for various reasons (mostly ongoing transitions) we are quite late in packaging GNOME 2.26 in Debian, we should also look at the future. GTK+ 3.0 is planned around march 2010, and GNOME 3.0 a little while later. With them comes the final deprecation of many GNOME 2.X interfaces. It took a very long time (8 years!) to get rid of GTK+ 1.2 and the process is in its final stage now. I’d like to avoid this horrible mess for GTK+ 2.X and for the GNOME libraries that will stop being maintained upstream after the 3.0 release. Fortunately, GTK+ 3.0 is an evolutionary change, not a revolutionary one. Which means for some applications there will be zero porting work, and for most of them there will only be minor changes required. For GNOME libraries, the changes will be more radical. This concerns less applications, but several libraries will simply disappear. What you can do right now is start to work on packages using the GNOME library stack. For affected packages, you can start working on patches right now, or at least pester your upstream so that they do. Now for the various pieces. GLIB The changes in GLib will mostly concern in removing deprecated APIs. If your packages build with -DG_DISABLE_DEPRECATED -DG_DISABLE_SINGLE_INCLUDES, they are most likely to build with GLib 3.0 with only compilation changes. Removed functions have replacements described in the API documentation. GDK / GTK+ Same as GLib. If you can build your package with GTK+ 2.16 using -DGDK_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED -DGDK_DISABLE_SINGLE_INCLUDES -DGTK_DISABLE_SINGLE_INCLUDES, it is very likely that your package can build with GTK+ 3.0. ESOUND Applications still using EsounD should be ported to using libcanberra (for sound events) or GStreamer (for the rest). GCONF There are plans to replace GConf by dconf, but it is quite certain that there will be at least a GConf compatiliby layer, so there is nothing to be done here. GNOME-VFS GnomeVFS has been deprecated for a while in favor of GIO, but porting is not something trivial. The GIO API documentation has some notes on how to port from GnomeVFS. LIBART It is now preferred to draw custom objects directly using Cairo, using the gdk_cairo_* API. LIBBONOBO / LIBBONOBOUI This part is completely going away, and it’s not easy. Replacing it generally means revamping parts of the application to use D-Bus for communication instead. LIBIDL / ORBIT ORBit will stay as a general-purpose CORBA implementation, but it is not meant to be used in GNOME applications anymore – currently its primary users are GConf and Bonobo. LIBGLADE Libglade is going away in favor of GtkBuilder. LIBGNOME This collection of random APIs with various uses is completely going away. The replacements are scattered among various libraries now: * GnomeProgram = GLib, libunique * gnome_execute_* = GLib (g_spawn) * gnome_gconf = GConf * gnome_help, gnome_url = GIO (g_app_info) * gnome_sound = libcanberra * Various stuff in GLib * More information: http://live.gnome.org/LibgnomeMustDie LIBGNOMEUI Same issue as with libgnome, the replacements depend on what the API is originally about. * gnome_init = GLib (GOption) * GnomeClient = Session management will be added to GTK+, it’s still missing AFAIK * The various widgets have replacements in GTK+ now. LIBGNOMECANVAS Deprecated in favor of libcairo. LIBEEL It has never been a widely used library, and it will be gone after 2.24. Replacements can be found in GTK+ for some widgets, for some others you will have to look at how it is now done in Nautilus. GTKSOURCEVIEW GtkSourceView 1.X is already deprecated, you should upgrade to GtkSourceView 2.X now. LIBGNOMEPRINT / LIBGNOMEPRINTUI Both deprecated in favor of gtk-unix-print (in GTK+) which is based on Cairo. LIBNAUTILUS-BURN It is going to be replaced with libbrasero-burn which has a very similar API. Now let’s get to work. FWIW, the end of the evolution transition should be tonight, so you’re going to see things move in the GNOME area really soon. Cheers, -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: New libthai and pango
Le mercredi 01 avril 2009 à 09:27 +0700, Theppitak Karoonboonyanan a écrit : I have got a dirty hack: by adding symbol versioning to libdatrie0. This solves the upgrading crash without breaking the current apps in unstable. But I'm not sure if it's a good practice in terms of package maintenance. Do you think doing so is considered ABI breakage? It is not ABI breakage, but it is useless, since this won’t fix libdatrie in lenny. -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: New libthai and pango
Le lundi 30 mars 2009 à 18:26 +0200, Loïc Minier a écrit : 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). Unfortunately this won’t work for upgrades from lenny, so I’d prefer to see the Conflicts anyway. -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: New libthai and pango
Le lundi 30 mars 2009 à 20:22 +0700, Theppitak Karoonboonyanan a écrit : 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. And you wonder why we insist on symbols needing to be versioned in libraries. Now there is no way to enforce the package will work using usual dependencies. Given the small number of reverse dependencies, it might be good to add a conflict against libdatrie0 in the new version of libthai, to completely avoid this issue. My question is, what should be the proper time for me to upload the new libthai into unstable, to minimize down time for the pango module? If I do that too soon, the pango module in unstable would not work properly, or might even crash. Please synchronize with the release team to get it at the right moment, since it implies a library transition. I’d appreciate if it could come after the big gnome-desktop/nautilus transition that still has to be done. Cheers, -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: New libthai and pango
Le lundi 30 mars 2009 à 21:34 +0700, Theppitak Karoonboonyanan a écrit : 2009/3/30 Josselin Mouette j...@debian.org: And you wonder why we insist on symbols needing to be versioned in libraries. Now there is no way to enforce the package will work using usual dependencies. Yes, with upstream's hat on, I realize that now, although a bit late.. Then please consider adding them now, so that it can be smoother next time :) Could it be done along with the next pango update? That is, next pango experimental build can link against it, and be tested before migrating to unstable together. How is that possible? FYI, I've tested it for a while in my jhbuild before releasing. There is no real need to synchronize with pango, since the release team can use binNMUs to rebuild all reverse-dependencies when needed. Cheers, -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Fwd: [Gnome] deskbar-applet broken, how to find out what's wrong?
Le lundi 30 mars 2009 à 15:27 +0100, Magnus Therning a écrit : After a recent upgrade my deskbar-applet isn't starting any longer. The problem is that the only feed-back I have is a dialogue stating that deskbar has quitted unexpectedly and I have a choice between reloading or not. Not so helpful. The obvious places don't seem to get anything written to them, ~/.xsession-errors and /var/log/**. Where can I find a trace of what's happening when I try to add the applet? You can launch it from a terminal. Run /usr/lib/deskbar-applet/deskbar-applet from it right when the dialog shows up, and immediately click on reload after the launch. You should be able to debug it like a regular Python application when doing this way. Cheers, -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: CD's not automounted in GNOME desktop
Le lundi 23 mars 2009 à 23:17 -0400, José Alburquerque a écrit : Would anyone happen to know why a few days now my cd's are not automounted in my gnome destkop? I'm running unstable and I've been upgrading regularly so I think it's happened with a recent update. Sorry if it's a simple question. I’ve already seen a similar issue reported on IRC. For that user, it looked like gnome-volume-manager was not running, probably because it died somehow after login. It would be nice if you could help debugging this issue by finding what mechanism is killing gnome-volume-manager. -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: CD's not automounted in GNOME desktop
Le mardi 24 mars 2009 à 13:07 +0100, Johannes Rohr a écrit : Wouldn't it be better in terms of identifying and eradicating bugs, if GNOME 2.24 (and eventually 2.26) was completely uploaded to unstable? At the moment, several components are still kept in experimental and gnome-session is still at 2.22. GNOME 2.24 will probably go into unstable as soon as the evolution transition is over. Which takes time as the buildds are heavily loaded and there are countless bugs introduced in related packages. As for gnome-session, it will certainly not be upgraded until 2.26.1, which should bring back basic session management functionality. Is the relatively slow update of GNOME after the lenny release due to transitions which have to complete first or is it because most of the GNOME team have actually deserted Debian and gone to the Ubuntu camp? It would sure help if people could actually give a helping hand. There have been a few proposals for help already, but we could use much more fresh blood. -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Splitting of the gnome-python* source packages - MBF
Le lundi 16 mars 2009 à 14:08 +0100, Josselin Mouette a écrit : 3. GNOME-PYTHON-EXTRAS What is happening in unstable: * egg.trayicon, gtkhtml2 and gtkmozembed each have their own binary package (python-eggtrayicon, python-gtkhtml2, python-gtkmozembed) * gksu 1.X is going away (nothing uses it anyway) * gda is going away, at least for a while * gtkspell will have its own binary package (currently in NEW) What will change upstream: * It’s very hard to tell, these modules don’t seem to change much. * Most of them have better replacements, so other packages should really get of these dependencies anyway. What changes to apply to Debian packages: * To simplify the dependency tree, the dependencies of python-gnome2-extras on python-eggtrayicon, python-gtkhtml2 and python-gtkmozembed are going away, probably right after the squeeze release. * Therefore, packages using these modules *must* be updated to use the new binary package as dependency instead. Apparently, developers have a strong tendency to not fix these bugs the correct way and instead, to make packages depend on e.g. python-gtkmozembed | python-gnome2-extras Therefore, I’m probably going to make gnome-python-extras follow the gnome-python-desktop path: * the gksu2 and gdl modules will go in python-gksu2 and python-gdl * when gda comes back (Gustavo is working on packaging libgda4), it will be in python-gda * let’s take that opportunity to ditch egg.recent away Are people OK with this approach? -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Splitting of the gnome-python* source packages - MBF
...@debian.org gtimelog (U) Romain Francoise rfranco...@debian.org deskbar-applet (U) François Févotte francois.fevo...@ensta.org exaile Jeremy Guitton debo...@free.fr ontv Dafydd Harries d...@debian.org gtimelog (U) Uwe Hermann u...@debian.org miro Varun Hiremath va...@debian.org pychess Philipp Kaluza pk+d...@yomu.de pida Philipp Kern pk...@debian.org timer-applet Julian Andres Klode j...@jak-linux.org gimmie martin f. krafft madd...@debian.org jppy (U) Mario Lang ml...@debian.org accerciser Julien Lavergne julien.laver...@gmail.com avant-window-navigator awn-extras-applets screenlets Yann Leboulanger aste...@lagaule.org gajim Clement Lorteau northern_lig...@users.sourceforge.net gtkvncviewer Jan Luebbe jlue...@debian.org pida (U) Maintainers of GStreamer packages pkg-gstreamer-maintain...@lists.alioth.debian.org elisa-plugins-good Simon McVittie s...@debian.org gtimelog Loic Minier l...@dooz.org elisa-plugins-good (U) gedit-plugins meld (U) nautilus-python (U) pitivi service-discovery-applet (U) update-manager (U) Emilio Pozuelo Monfort po...@ubuntu.com decibel-audio-player emesene nautilus-python (U) scribes update-manager (U) Sam Morris s...@robots.org.uk serpentine Josselin Mouette j...@debian.org epiphany-extensions gedit-plugins (U) gnome-games hamster-applet (U) hotwire update-manager (U) Philippe Normand phili...@fluendo.com elisa-plugins-good (U) Piotr Ożarowski pi...@debian.org griffith Thibaut Paumard paum...@users.sourceforge.net update-manager (U) Adriaan Peeters apeet...@lashout.net music-applet Frederic Peters fpet...@debian.org gnome-blog Nicholas C Piper nick-deb...@nickpiper.co.uk jppy (U) Norbert Preining prein...@debian.org jppy (U) Andy Price a...@andrewprice.me.uk pybackpack Python Applications Packaging Team python-apps-t...@lists.alioth.debian.org decibel-audio-player (U) emesene (U) pybackpack (U) screenlets (U) scribes (U) Arnaud Quette aque...@debian.org elisa-plugins-good (U) Florian Ragwitz r...@debian.org istanbul (U) jokosher Gustavo Noronha Silva k...@debian.org update-manager (U) Jonas Smedegaard d...@jones.dk sugar (U) sugar-toolkit (U) sugar-web-activity (U) Joseph Smidt jsm...@byu.edu gmail-notify Jose Carlos Garcia Sogo js...@debian.org conduit John Sullivan j...@wjsullivan.net xword jppy development team jppy-de...@zanu.org.uk jppy Magnus Therning mag...@therning.org keysafe James A. Treacy tre...@debian.org gramps Andrea Veri bluek...@ubuntu.com cgmail Jelmer Vernooij jel...@debian.org bzr-gtk (U) Hanna Wallach hm...@cam.ac.uk straw Torsten Werner twer...@debian.org pychess (U) -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: rebuild totem-pl-parser
Le vendredi 13 mars 2009 à 11:41 +0100, Adeodato Simó a écrit : * Gustavo Noronha [Thu, 12 Mar 2009 20:16:00 -0300]: We're holding uploads of totem-pl-parser because of ongoing transitions, but it is currently uninstallable in unstable, which is causing some builds to fail on the build daemons. A rebuild should be enough to remedy the situation: If you have an upload pending, a sourceful upload is appropriate at this stage. If you still prefer the Bin-NMUs, please reply to this mail and I will schedule them. I think you’ll prefer that we don’t upload the totem-pl-parser package we have ready, since it’s another transition… -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: ENV for gconftool-2
Le mercredi 11 mars 2009 à 13:24 -0400, Rick Pasotto a écrit : For a long time (1+ years) I have had a cron job run a script every 15 minutes to change my desktop background. Recently it stopped working. The script still runs but the background image is not changed. If I run the script from the command line it behaves as ususal. Evidently there is some ENV variable that gconftool-2 needs to change the background. What might it be? The script line that changes the background: /usr/bin/gconftool-2 -t str --set /desktop/gnome/background/picture_filename $FileName The installed version of gconftool-2 (included in gconf2): gconf2: Installed: 2.24.0-7 This is because GConf now uses D-Bus to locate the server. The actual contents of the GConf key is changed, but the applications are not notified since your script doesn’t use the same GConf server. Theoretically, this might just work if you pass DISPLAY=:0 (if your session is running on :0) to the gconftool command; D-Bus should be able to locate everything it needs using X settings. Cheers, -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Proposing gdm update for stable
Hi, I’d like to propose a GDM update for the 5.0.1 point release, in order to fix #495797 (XDMCP being broken on many setups). There is currently a new bugfix release in unstable (2.20.9), but the upstream requirements are a bit less conservative than for gtk+2.0, so I’d prefer to upload a targeted fix for #495797 instead. If there are other bug fixes that some people would like to see in the point release, please speak up now. Cheers, -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
