Re: libcdio transition
Nicolas Boullis wrote: Hi, On Fri, Jul 03, 2009 at 01:08:22AM +0200, Luk Claes wrote: Nicolas Boullis wrote: Cheers, On Wed, Jul 01, 2009 at 08:03:20AM +0200, Luk Claes wrote: If you are sure that there are no API changes, then please upload to unstable and tell us when you did so we can schedule binNMUs (as it does not seem to interfere with existing transitions). I just played with diff over the header files and... unfortunately, there are some API changes. A few functions were removed (I guess nobody used them anyway), added (that should be no problem) or even changed (only one function, that had its return changed from int to an enum, which should be safe). Is it alright anyway? Or would you prefer to check if everything's alright with bin-NMUs to experimental? Just manually checking the builds of all reverse build dependencies with the new version on one arch would also be fine. I checked all the packages that build-depend against libcdio-dev, libiso9660-dev, libudf-dev, libcdio-cdda-dev or libcdio-paranoia-dev, and all could be built without changing anything. Hence, I just uploaded libcdio 0.81-4 to unstable (I uploaded packages for i386, powerpc and sparc). Now, I think you can schedule binNMUs. Scheduled. Cheers Luk -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please hint krb5 1.7 into testing and retain libkrb53 in testing
Sam Hartman wrote: Hi. Hi This is an update on my message about the krb5 transition. Currently, if krb5 1.7 from unstable were to migrate into testing and if the libkrb53 binary package were maintained in testing (it disappears from the krb5 source package between testing and unstable), I believe we have high confidence that: 1) nothing would break I'm not so sure this is the case as I tried it last night and britney refused to transition it because of making packages uninstallable in testing. I guess that's because some packages that try to migrate together depend on krb5 already and are not installable... 2) we would unjam a significant number of migrations blocked by krb5 That's true. The libkrb53 package includes libraries to support Kerberos 4 that were dropped between version 1.6 and 1.7. The version of krb5 already in testing effectively has stub support for these libraries; the functionality is for all practical purposes not available in testing. (For more detail read the previous notes on this here and on debian-devel) An application that uses libraries from the libkrb53 package currently in testing and the other library packages currently in unstable will not segfault. It will simply get some function calls that return a not-implemented error. For the most part these functions already return not-implemented in testing. I uploaded fixes for both heirloom-mailx and mailutils today and will hopefully be able to hint krb5, bluez and imagemagick in at when they are built and uploaded. Cheers Luk -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Coordinating efforts to get a new kernel in testing?
Christian Perrier wrote: During the last meeting of the D-I 'team' (ahem) which logs can be read from http://wiki.debian.org/DebianInstaller/Meetings, the situation of the kernel packages wrt testing transition was raised. Apparently, having a new kernel in testing (whether this is 2.6.30 or whatever other funky new version appears soon is not really relevant) is quite hairy. It needs quite some work to get reverse dependencies handled and getting it built on all architectures. Both of which are the main responsability of the kernel team... Could this be prioritized by the involved teams (mostly kernel and release, I'd guess) or are there already some plans for this to happen? There are no plans to force anything in like some propose in such situations as there is no clear plan of the kernel team to get the remaining issues solved soon after it would be forced in. Cheers Luk -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RM: gnote/testing -- ROM; uninstallable (Re: please unblock gnote_0.4.0-3~squeeze1 (Re: gnote broken in testing due to libxml++2.6 migration))
Robert Millan wrote: On Sat, Jun 27, 2009 at 04:57:54PM +0200, Luk Claes wrote: Robert Millan wrote: On Tue, Jun 16, 2009 at 10:30:46PM +0200, Robert Millan wrote: On Tue, Jun 16, 2009 at 08:05:29PM +0200, Luk Claes wrote: In the meantime, it's uninstallable (see #533216). Any ideas on how can this be fixed? Maybe a gnote upload to tpu? That would indeed be an option. Okay, gnote_0.4.0-3~squeeze1 uploaded to tpu. Please consider unblocking. Ping. Unfortunately it's not ready to be approved as it's not installed on all architectures yet. Hi, There's something odd with s390 and hppa. 0.4.0-3~squeeze1 was built 3 weeks ago on both, but those binaries didn't reach the archive. I suspect their queues aren't processed very often... In the meantime, please could you remove 0.3.1-7 from testing? Untill 0.4.0-3~squeeze1 builds are finished, 0.3.1-7 is uninstallable and just causing confusion. Removal hint added. Cheers Luk -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please binNMU pidgin against libsilc-dev (= 1.1.9-1)
Jérémy Bobbio wrote: Hi mighty members of the release team, Could you please schedule a binNMU of pidgin against libsilc-dev (= 1.1.9-1) in order to update its binary deps? Can you please give a bit more context as it doesn't seem obvious why this would be needed? Cheers Luk -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please binNMU mlt against libsox-dev (= 14.3.0)
Patrick Matthäi wrote: Hello, could you please binnmu mlt on all architectures against libsox-dev (= 14.3.0)? scheduled, btw it would be good to mention what old binary package is replaced by which new one. Cheers Luk -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: stable update for znc (0.058-2+lenny2)
On Fri, 2009-07-10 at 15:05 +0200, Patrick Matthäi wrote: I want to fix #536489 [i|+| ] [znc] znc: Possible crash if a user is connecting to a server and will be deleted at the same time debdiff attached: debian/patches/03-crash-deleted-user.dpatch | 21 + znc-0.058/debian/changelog | 13 + znc-0.058/debian/control|2 +- znc-0.058/debian/patches/00list |1 + Please upload. Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Fix for #524957 in lenny
Luigi Gangitano wrote: Hi releasers, I would like to ask if a fix for #524957 would be accepted in proposed-updates. This bug, while being trivial, makes smb authentication unusable in the current version of squid in lenny. The fix is in sid ATM and has been repeatedly tested. Looks good, please upload. Cheers Luk -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#531556: upgrade problem with the proposed libarchive-tar-perl Etch update
Niko Tyni wrote: On Thu, Jun 04, 2009 at 10:19:38AM +0300, Niko Tyni wrote: Oldstable release managers: will you accept a libarchive-tar-perl 1.38-3~etch2 upload with the diversions added, or can you suggest another fix? What's the schedule for the Etch r9 release? Introducing diversions in a point release is a no go IMHO. As the Conflicts entry did not leave room for any update, that's the bug that should be fixed IMHO. Ping? I see 1.38-3~etch1 is still ACCEPTED in oldstable-proposed-updates, but it would be very unfortunate to have an Etch point release with that. I understand the release may not be very soon, but I'm worried this gets forgotten. Maybe adding a note to the TODO list on top of http://release.debian.org/proposed-updates/oldstable.html would suffice to make sure this gets resolved before the release? It's mentioned in the TODO. Cheers Luk -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: stable update for znc (0.058-2+lenny2)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Adam D. Barratt schrieb: On Fri, 2009-07-10 at 15:05 +0200, Patrick Matthäi wrote: I want to fix #536489 [i|+| ] [znc] znc: Possible crash if a user is connecting to a server and will be deleted at the same time debdiff attached: debian/patches/03-crash-deleted-user.dpatch | 21 + znc-0.058/debian/changelog | 13 + znc-0.058/debian/control|2 +- znc-0.058/debian/patches/00list |1 + Please upload. Thanks = done. - -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkpYdw0ACgkQ2XA5inpabMewJgCfS7ZVvuxvxEzYMW0S2v+0vOMJ eXMAoKt6uTQxVdkiKPMKqqa1Q0Vkmm4D =OZYz -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please hint krb5 1.7 into testing and retain libkrb53 in testing
Luk == Luk Claes l...@debian.org writes: Luk Sam Hartman wrote: Hi. Luk Hi This is an update on my message about the krb5 transition. Currently, if krb5 1.7 from unstable were to migrate into testing and if the libkrb53 binary package were maintained in testing (it disappears from the krb5 source package between testing and unstable), I believe we have high confidence that: 1) nothing would break Luk I'm not so sure this is the case as I tried it last night and Luk britney refused to transition it because of making packages Luk uninstallable in testing. I guess that's because some Luk packages that try to migrate together depend on krb5 already Luk and are not installable... *sigh* You need to maintain libdes425-3 in testing. I thought libkrb53 included both libkrb4.so.2 and libdes425.so.3, but it depends on libdes425-3 for the second. )(Sorry, there were multiple different breakdowns of this around) If that's not it then then please read on; otherwise sorry for wasting your time. even if you manage to fix this with uploads to unstable, I'd like to understand a bit more about what went wrong here. I don't like it when I give people advice that might break things and thought I had very high confidence in my statement:-) You tried to hint krb5 into testing while retaining the libkrb53 binarypackage alrready in testing and something became uninstallable? What? As I understand it: krb5 in unstable has no dependencies not in testing. I.E. krb5 can migrate alone unless the migration would break something in testing. Nothing conflicts with the krb5 in unstable. I haven't actually checked this, but it would be really strange for me not to know about. krb5 in unstable satisfies all dependencies in testing except: libkrb53, libdes425-3 and libkadm55 disappear. libkrb53and libdes425-3 in testing can be installed with the krb5 in unstable; unstable krb5 meets the libkrb53 dependencies in testing if libdes425-3 is retained. Nothing at all in testing depends on libkadm55. So, unless it was libdes425-3, I'm really really confused. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please binNMU pidgin against libsilc-dev (= 1.1.9-1)
Luk Claes l...@debian.org (11/07/2009): Jérémy Bobbio wrote: Hi mighty members of the release team, Could you please schedule a binNMU of pidgin against libsilc-dev (= 1.1.9-1) in order to update its binary deps? Can you please give a bit more context as it doesn't seem obvious why this would be needed? From silc-toolkit_1.1.9-1/changelog: |* libsilc and libsilcclient are now shipped in two different binary packages | in order to respect their SONAMEs. The -dev package depends on both and | has been renamed to libsilc-dev. libpurple0 (from src:pidgin) depends on one of them. I guess a rebuild would update that dependency; given that silc_client_* symbols come from the libsilcclient-1.1.3 binary, a dependency against that one is going to be added. FWIW, silc-toolkit is uploaded, but not installed, on amd64. Cc'ing amd64 buildd admins for that matter. Mraw, KiBi. signature.asc Description: Digital signature
Re: Removal of remaining packages using GTK 1.2
Moritz Muehlenhoff wrote: On 2009-06-27, Luk Claes l...@debian.org wrote: Moritz Muehlenhoff wrote: On 2009-06-01, Moritz Muehlenhoff j...@inutil.org wrote: On 2009-05-28, Neil McGovern ne...@debian.org wrote: On Sun, May 17, 2009 at 10:12:04PM +0200, Moritz Muehlenhoff wrote: xemacs21 All removed Thanks. All have been removed now with the exception of xemacs21. I suppose that's because toolbar-fancy (which is xemacs21-specific) needs to be removed along. Seems this one is a tough nut to crack, GTK 1.2 is still in testing. Is there a web site or other form of log, which details what package is blocking the removal? Executing the following on merkel should give you the list: dak rm -Rn -s testing gtk+1.2 Thanks. I've done NMUs to fix gpsim-l[ogic|ed], but it appears a few buildds need to be retriggered: amoeba 1.1-19.1 on mipsel FTBFS, bug is already filed. gpsim 0.22.0-5.1 on powerpc - Building since 7th of May... If you look closer, you would see that it FTBFS already 4 times, though given back. gpsim-led 0.22.0~rc3-2.2 on powerpc - likewise since 27th of June given back. guile-gnome-platform 2.16.1-2 on hppa - Needs-Build since 20th of June? given-back Cheers Luk -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Coordinating efforts to get a new kernel in testing?
Quoting Luk Claes (l...@debian.org): Could this be prioritized by the involved teams (mostly kernel and release, I'd guess) or are there already some plans for this to happen? There are no plans to force anything in like some propose in such situations as there is no clear plan of the kernel team to get the remaining issues solved soon after it would be forced in. So, could we get some input from the kernel team on this topic, then? Are you guys prioritizing work to get a new kernel in testing or work to get yet another upstream release in unstable? (from the above sentence and the discussion we had during the D-I team meeting, you probably understand where is my own preference going) signature.asc Description: Digital signature
Re: upload of gcc-4.4 4.4.0-10 for mips
Matthias Klose wrote: please upload gcc-4.4 4.4.0-10 for mips, or start a new build if the build is lost (built on June 29). the eglibc migration depends on the recent gcc-4.4 package. Scheduled for upload. Cheers Luk -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please hint krb5 1.7 into testing and retain libkrb53 in testing
Sam Hartman wrote: Luk == Luk Claes l...@debian.org writes: Luk Sam Hartman wrote: Hi. Luk Hi This is an update on my message about the krb5 transition. Currently, if krb5 1.7 from unstable were to migrate into testing and if the libkrb53 binary package were maintained in testing (it disappears from the krb5 source package between testing and unstable), I believe we have high confidence that: 1) nothing would break Luk I'm not so sure this is the case as I tried it last night and Luk britney refused to transition it because of making packages Luk uninstallable in testing. I guess that's because some Luk packages that try to migrate together depend on krb5 already Luk and are not installable... *sigh* You need to maintain libdes425-3 in testing. I thought libkrb53 included both libkrb4.so.2 and libdes425.so.3, but it depends on libdes425-3 for the second. )(Sorry, there were multiple different breakdowns of this around) If that's not it then then please read on; otherwise sorry for wasting your time. even if you manage to fix this with uploads to unstable, I'd like to understand a bit more about what went wrong here. I don't like it when I give people advice that might break things and thought I had very high confidence in my statement:-) You tried to hint krb5 into testing while retaining the libkrb53 binarypackage alrready in testing and something became uninstallable? Ah, that's the reason. I thought there were different source packages involved (for libkrb53), but apparently you ask to do a gross hack to keep the libkrb53 binary package in while migrating krb5 and its remaining binary packages. This is possible, though I'd rather not do that. If we would do something like that we would probably retain all the binary packages from the previous source package btw. Sorry for misunderstanding, though krb5 is almost ready to migrate without having to leave libkrb53 in testing, so I'd prefer to do that. Cheers Luk -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please binNMU pidgin against libsilc-dev (= 1.1.9-1)
Cyril Brulebois wrote: Luk Claes l...@debian.org (11/07/2009): Jérémy Bobbio wrote: Hi mighty members of the release team, Could you please schedule a binNMU of pidgin against libsilc-dev (= 1.1.9-1) in order to update its binary deps? Can you please give a bit more context as it doesn't seem obvious why this would be needed? From silc-toolkit_1.1.9-1/changelog: |* libsilc and libsilcclient are now shipped in two different binary packages | in order to respect their SONAMEs. The -dev package depends on both and | has been renamed to libsilc-dev. libpurple0 (from src:pidgin) depends on one of them. I guess a rebuild would update that dependency; given that silc_client_* symbols come from the libsilcclient-1.1.3 binary, a dependency against that one is going to be added. The strange thing is that the soname of libsilc did not change, though as there are only a small number of reverse dependencies, I've scheduled binNMUs for them. Cheers Luk -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please hint krb5 1.7 into testing and retain libkrb53 in testing
Ah, that's the reason. I thought there were different source packages involved (for libkrb53), but apparently you ask to do a gross hack to keep the libkrb53 binary package in while migrating krb5 and its remaining binary packages. This is possible, though I'd rather not do that. If we would do something like that we would probably retain all the binary packages from the previous source package btw. Your call obviously. In a general policy discussion (not this thread, not this mailing list probably) I'd love to try and convince the release team that this is not a hack and is a good thing to do when: * Breakage is null or low * Things are in such a state that if you really had to drop enough packages to make a release, you could. However I'd like to learn more from your side before trying to do that. If we find ourselves sharing a drink at debconf, perhaps we could discuss. --Sam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please binNMU pidgin against libsilc-dev (= 1.1.9-1)
On Sat, Jul 11, 2009 at 01:46:24PM +0200, Cyril Brulebois wrote: Luk Claes l...@debian.org (11/07/2009): Jérémy Bobbio wrote: Hi mighty members of the release team, Could you please schedule a binNMU of pidgin against libsilc-dev (= 1.1.9-1) in order to update its binary deps? Can you please give a bit more context as it doesn't seem obvious why this would be needed? From silc-toolkit_1.1.9-1/changelog: |* libsilc and libsilcclient are now shipped in two different binary packages | in order to respect their SONAMEs. The -dev package depends on both and | has been renamed to libsilc-dev. libpurple0 (from src:pidgin) depends on one of them. I guess a rebuild would update that dependency; given that silc_client_* symbols come from the libsilcclient-1.1.3 binary, a dependency against that one is going to be added. FWIW, silc-toolkit is uploaded, but not installed, on amd64. Cc'ing amd64 buildd admins for that matter. I gave back silc-toolkit. Kurt -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Coordinating efforts to get a new kernel in testing?
On Sat, Jul 11, 2009 at 01:08:05PM +0200, Luk Claes wrote: It needs quite some work to get reverse dependencies handled and getting it built on all architectures. Both of which are the main responsability of the kernel team... it is mostly done, beside the strange cpio missing build dep, that funnily surfaced now on i686. fixed in latest repo and scheduled for upload latest on this upcoming week. Could this be prioritized by the involved teams (mostly kernel and release, I'd guess) or are there already some plans for this to happen? There are no plans to force anything in like some propose in such situations as there is no clear plan of the kernel team to get the remaining issues solved soon after it would be forced in. without force hints linux-2.6 goes nowhere. what are the remaining issues that you are concerned about? -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please binNMU pidgin against libsilc-dev (= 1.1.9-1)
Luk Claes l...@debian.org (11/07/2009): Cyril Brulebois wrote: From silc-toolkit_1.1.9-1/changelog: |* libsilc and libsilcclient are now shipped in two different binary packages | in order to respect their SONAMEs. The -dev package depends on both and | has been renamed to libsilc-dev. libpurple0 (from src:pidgin) depends on one of them. I guess a rebuild would update that dependency; given that silc_client_* symbols come from the libsilcclient-1.1.3 binary, a dependency against that one is going to be added. The strange thing is that the soname of libsilc did not change, though as there are only a small number of reverse dependencies, I've scheduled binNMUs for them. Since I was porting it to GNU/kFreeBSD, I didn't notice the following problem until now: - pidgin B-D on libsilc-1.1-2-dev | libsilc-dev. - silc-toolkit dropped the former for the latter. - sbuild picks the former (which still exists in the archive since it wasn't trashed). [and didn't exist on the system I was working on, that's why I didn't notice at once.] - sbuild can't install it since it depends on an old version of the library. I see two ways here: - decruft the old -dev; - tweak the B-D on pidgin's side (Ari Cc'd for that matter)… but there are other packages in this case. silc-toolkit folks may want to contact their reverse dependencies to sort this mess out, I guess. Mraw, KiBi. signature.asc Description: Digital signature
Re: Coordinating efforts to get a new kernel in testing?
maximilian attems wrote: On Sat, Jul 11, 2009 at 01:08:05PM +0200, Luk Claes wrote: It needs quite some work to get reverse dependencies handled and getting it built on all architectures. Both of which are the main responsability of the kernel team... it is mostly done, beside the strange cpio missing build dep, that funnily surfaced now on i686. fixed in latest repo and scheduled for upload latest on this upcoming week. Could this be prioritized by the involved teams (mostly kernel and release, I'd guess) or are there already some plans for this to happen? There are no plans to force anything in like some propose in such situations as there is no clear plan of the kernel team to get the remaining issues solved soon after it would be forced in. without force hints linux-2.6 goes nowhere. If you mean this in general then you are misinformed. If you mean atm, then you know the answer to your following question. what are the remaining issues that you are concerned about? The ones that prevent linux-2.6 from migrating once it would be unblocked. Cheers Luk -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
SPU for xfce4-weather-plugin
Hi, xfce4-weather-plugin in stable recently stopped to work, because it uses weather.com XOAP without really respecting the API, and especially it doesn't use a key. The version in testing correctly handles that, but the patch is too heavy for a stable upload. An intermediate version would be to only use the API key (which would fix the problem without correctly respecting weather.com api). I've prepared a package for stable, debdiff is attached. Would it be possible to include it in spu and in the next stable release? Cheers and thanks, -- Yves-Alexis diff -u xfce4-weather-plugin-0.6.2/debian/changelog xfce4-weather-plugin-0.6.2/debian/changelog --- xfce4-weather-plugin-0.6.2/debian/changelog +++ xfce4-weather-plugin-0.6.2/debian/changelog @@ -1,3 +1,11 @@ +xfce4-weather-plugin (0.6.2-1+lenny1) stable; urgency=low + + * debian/patches: +- 01_add-weather.com-api-key added: use the xfce4-weather-plugin API + key so weather.com gives us the weather. closes: #536289 + + -- Yves-Alexis Perez cor...@debian.org Sat, 11 Jul 2009 15:23:01 +0200 + xfce4-weather-plugin (0.6.2-1) unstable; urgency=low [ Simon Huggins ] only in patch2: unchanged: --- xfce4-weather-plugin-0.6.2.orig/debian/patches/01_add-weather.com-api-key.patch +++ xfce4-weather-plugin-0.6.2/debian/patches/01_add-weather.com-api-key.patch @@ -0,0 +1,29 @@ +diff --git a/panel-plugin/weather.c b/panel-plugin/weather.c +index 75c3d3c..0eb9487 100644 +--- a/panel-plugin/weather.c b/panel-plugin/weather.c +@@ -338,9 +338,10 @@ update_weatherdata (xfceweather_data *data) + } + + /* build url */ +- url = g_strdup_printf (/weather/local/%s?cc=*dayf=%dunit=%c, ++ url = g_strdup_printf (/weather/local/%s?cc=*dayf=%dunit=%clink=xoapprod=xoappar=%skey=%s, + data-location_code, XML_WEATHER_DAYF_N, +- data-unit == METRIC ? 'm' : 'i'); ++ data-unit == METRIC ? 'm' : 'i', ++PARTNER_ID, LICENSE_KEY); + + /* start receive thread */ + weather_http_receive_data (xoap.weather.com, url, data-proxy_host, +diff --git a/panel-plugin/weather.h b/panel-plugin/weather.h +index ef85749..f0adb47 100644 +--- a/panel-plugin/weather.h b/panel-plugin/weather.h +@@ -22,6 +22,8 @@ + + #include libxfce4panel/xfce-panel-plugin.h + #include libxfce4util/libxfce4util.h ++#define PARTNER_ID 1121946239 ++#define LICENSE_KEY 3c4cd39ee5dec84f + + G_BEGIN_DECLS signature.asc Description: This is a digitally signed message part
Re: SPU for xfce4-weather-plugin
Yves-Alexis Perez wrote: Hi, xfce4-weather-plugin in stable recently stopped to work, because it uses weather.com XOAP without really respecting the API, and especially it doesn't use a key. The version in testing correctly handles that, but the patch is too heavy for a stable upload. An intermediate version would be to only use the API key (which would fix the problem without correctly respecting weather.com api). I've prepared a package for stable, debdiff is attached. Would it be possible to include it in spu and in the next stable release? Yes, please upload. Cheers Luk -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: SPU for xfce4-weather-plugin
On sam, 2009-07-11 at 19:48 +0200, Luk Claes wrote: Would it be possible to include it in spu and in the next stable release? Yes, please upload. Done, thanks! -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: Coordinating efforts to get a new kernel in testing?
On Saturday 11 July 2009, Luk Claes wrote: what are the remaining issues that you are concerned about? The ones that prevent linux-2.6 from migrating once it would be unblocked. Like FTBFS of linux-modules-extra-2.6 on 3 architectures I guess? That seemed to me like a valid reason not to want to migrate .29 to testing. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Coordinating efforts to get a new kernel in testing?
On Sun, Jul 12, 2009 at 5:29 AM, Frans Pop elen...@planet.nl wrote: Like FTBFS of linux-modules-extra-2.6 on 3 architectures I guess? That seemed to me like a valid reason not to want to migrate .29 to testing. Also the armel linux-2.6 FTBFS: https://buildd.debian.org/fetch.cgi?pkg=linux-2.6;ver=2.6.30-2;arch=armel;stamp=1247068753 -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
