Please binNMU geany-plugins against new geany (0.18)
Hello, There was recently a new release of Geany (= 0.18) in which the plugin ABI was broken, hence requiring that all plugins be rebuilt in order to be loaded by Geany. nmu geany-plugins_0.17.1-1 . ALL . -m 'Rebuild against new geany (Closes: #542716)' -- Kind regards, Chow Loong Jin signature.asc Description: OpenPGP digital signature
Re: Mozilla plans for the squeeze cycle
On Sun, Aug 16, 2009 at 02:41:21PM +0200, Marc Brockschmidt wrote: Heya, As announced on dda [RT1], we want to get an impression when releasing Squeeze is feasible. We have proposed a (quite ambitious) freeze in December 2009, and some developers have noted that their planned changes wouldn't be possible in this time frame. So, to find out when releasing would work for most people, it would be great if you could answer the following questions: * Which major upstream releases of Mozilla/Xulrunner-based software are expected in the next two years? Which of those are material for Debian stable, which might be a bit flaky? firefox 3.6 is currently scheduled for december 2009; i think it would be worthwhile to get that in before freeze even if its not yet final at that point; this would help to get a bit longer upstream security support and would make debian more modern. Also it will probably get to final during freeze. Mozilla does not have any 2 years plans that one could rely on. Last I know is the general goal to target a ~9 month cycle, but with usual approach to release when ready (so 3.5 took 12 month). * How much time do you usually need from a new upstream release to a stable Debian package in unstable? This is hard to guess as you dont know up-front how much porting will be required. Also I cannot speak for debian xulrunner/firefox maintainers here. * How many big transitions will the upcoming changes cause? When should those happen? Can we do something to make them easier? Same here ... we dont really know in advance. p.s. CC me ... not subscribed iirc. - Alexander -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: open issues with the hppa port
On Sun, Aug 16, 2009 at 7:24 AM, Andreas Bartha...@not.so.argh.org wrote: As an current exmaple, take the libcdio-transition. This transition needs to have updated packages xmms2, xmp and vlc. However, the packages are out-of-date on hppa, and for this reason cannot enter testing (and they depend on an old library that will go away with the transition). vlc 1.0.1-1 builds on hppa: https://buildd.debian.org/fetch.cgi?pkg=vlcarch=hppaver=1.0.1-1stamp=1250706425file=logas=raw xmp 2.7.1-1 builds on hppa: https://buildd.debian.org/fetch.cgi?pkg=xmparch=hppaver=2.7.1-1stamp=1250460366file=logas=raw xmms2 is the only package that doesn't build. Analysis of the xmms2 build shows that this is a python crash. Thankfully the python crash reproduces (in a different location each time). I'll look into this. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
version screwup: any recourse besides epoch?
I screwed up and released tiff 3.9.0beta+deb1 to experimental earlier this week instead of 3.9.0~beta+deb1. Now I'd like to upload 3.9.0 to unstable. I really don't want to introduce an epoch. Is it possible to make 3.9.0beta+deb1 just disappear? It's never been anywhere but experimental, and it's only been there for two days. Otherwise, I'll have to think about whether to introduce an epoch or to just contort the version for this one release, like 3.9.0+final. I hate to use an epoch to fix a typo instead of to handle a genuine change to the version numbering scheme. Advice welcome. I'll delay my 3.9.0 upload a bit until I get an answer. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: version screwup: any recourse besides epoch?
Jay Berkenbilt q...@debian.org wrote: I screwed up and released tiff 3.9.0beta+deb1 to experimental earlier this week instead of 3.9.0~beta+deb1. Now I'd like to upload 3.9.0 to unstable. I really don't want to introduce an epoch. Is it possible to make 3.9.0beta+deb1 just disappear? It's never been anywhere but experimental, and it's only been there for two days. Otherwise, I'll have to think about whether to introduce an epoch or to just contort the version for this one release, like 3.9.0+final. I hate to use an epoch to fix a typo instead of to handle a genuine change to the version numbering scheme. Advice welcome. I'll delay my 3.9.0 upload a bit until I get an answer. Please disregard. I figured it out. I'm going to upload 3.9.0 to unstable, which will work fine because it's newer than 3.8.2. I'll upload 4.0.0beta3 to experimental which will clear out 3.9.0beta+deb1. Sorry for the noise. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: open issues with the hppa port
* Carlos O'Donell (car...@systemhalted.org) [090821 16:49]: On Sun, Aug 16, 2009 at 7:24 AM, Andreas Bartha...@not.so.argh.org wrote: As an current exmaple, take the libcdio-transition. This transition needs to have updated packages xmms2, xmp and vlc. However, the packages are out-of-date on hppa, and for this reason cannot enter testing (and they depend on an old library that will go away with the transition). vlc 1.0.1-1 builds on hppa: https://buildd.debian.org/fetch.cgi?pkg=vlcarch=hppaver=1.0.1-1stamp=1250706425file=logas=raw xmp 2.7.1-1 builds on hppa: https://buildd.debian.org/fetch.cgi?pkg=xmparch=hppaver=2.7.1-1stamp=1250460366file=logas=raw Thanks for both packages. They should arrive at about the same time as vlc on mipsel, so that we can hopefully finish this transition soon. xmms2 is the only package that doesn't build. Analysis of the xmms2 build shows that this is a python crash. Thankfully the python crash reproduces (in a different location each time). I'll look into this. Good. I might still break this package because libcdio is blocking lots of binNMUs, and we need to try to keep transitions as small as possible, but of course as soon as this package is fixed it's welcome to get in sync (and if you need help for that from the release team please don't hesitate to contact us). Cheers, Andi -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: version screwup: any recourse besides epoch?
On 2009-08-21 Jay Berkenbilt q...@debian.org wrote: Jay Berkenbilt q...@debian.org wVrote: I screwed up and released tiff 3.9.0beta+deb1 to experimental earlier this week instead of 3.9.0~beta+deb1. Now I'd like to upload 3.9.0 to [...] I'll upload 4.0.0beta3 to experimental which will clear out 3.9.0beta+deb1. 4.0.0~beta3 I guess ;-) cu andreas -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: version screwup: any recourse besides epoch?
Jay Berkenbilt a écrit : Please disregard. I figured it out. I'm going to upload 3.9.0 to unstable, which will work fine because it's newer than 3.8.2. I'll upload 4.0.0beta3 to experimental which will clear out 3.9.0beta+deb1. You can also just ask ftpmaster to remove (via a bugreport against ftp.debian.org) the experimental version, I guess. Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: version screwup: any recourse besides epoch?
Andreas Metzler ametz...@downhill.at.eu.org wrote: On 2009-08-21 Jay Berkenbilt q...@debian.org wrote: Jay Berkenbilt q...@debian.org wVrote: I screwed up and released tiff 3.9.0beta+deb1 to experimental earlier this week instead of 3.9.0~beta+deb1. Now I'd like to upload 3.9.0 to [...] I'll upload 4.0.0beta3 to experimental which will clear out 3.9.0beta+deb1. 4.0.0~beta3 I guess ;-) cu andreas Yes. Of course. ;-) -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: OpenOffice.org plans for the squeeze cycle
On Thu, 20 Aug 09 19:26, Matthias Klose wrote: On 16.08.2009 15:15, Rene Engelhard wrote: .0s should be avoided for Debian stable, the are almost always full of bad bugs/regressions, as we see e.g. in 3.1.0, too. So this would mean, that squeeze will release with 3.1.x (3.1.0 release in Apr 2009), which will be several months old when squeeze releases. Would it be possible to package 3.2.0 for unstable, and I thought the squeeze freeze/release date is not fixed yet and these mails should be the base for the final date... /Armin -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Mozilla plans for the squeeze cycle
On Fri, Aug 21, 2009 at 03:39:55PM +0200, Alexander Sack wrote: On Sun, Aug 16, 2009 at 02:41:21PM +0200, Marc Brockschmidt wrote: Heya, As announced on dda [RT1], we want to get an impression when releasing Squeeze is feasible. We have proposed a (quite ambitious) freeze in December 2009, and some developers have noted that their planned changes wouldn't be possible in this time frame. So, to find out when releasing would work for most people, it would be great if you could answer the following questions: * Which major upstream releases of Mozilla/Xulrunner-based software are expected in the next two years? Which of those are material for Debian stable, which might be a bit flaky? firefox 3.6 is currently scheduled for december 2009; i think it would be worthwhile to get that in before freeze even if its not yet final at that point; this would help to get a bit longer upstream security support and would make debian more modern. Also it will probably get to final during freeze. Mozilla does not have any 2 years plans that one could rely on. Last I know is the general goal to target a ~9 month cycle, but with usual approach to release when ready (so 3.5 took 12 month). And security support is dropped 6 months after that for the previous release. I.e. Firefox 3.0 security support will be dropped in 4 months. Firefox is also not the only mozilla product we have, and only considering Firefox may be biaised. Thunderbird 3.0 might be expected somewhen soonish in the next few months, as well as Seamonkey 2.0. They will both be based on Gecko 1.9.1, which is the version of Gecko that Firefox 3.5 uses. Getting all these in sync means we share the same codebase in all Mozilla products, which, despite upstream support being dropped earlier may substantially help the security team. Firefox 3.6, on the other hand, relies on Gecko 1.9.2. I, for one, don't want to maintain 2 gecko codebases in the same distribution much longer. But people are free to join the mozilla team and help out. * How much time do you usually need from a new upstream release to a stable Debian package in unstable? * How many big transitions will the upcoming changes cause? When should those happen? Can we do something to make them easier? Every new gecko, which we mainly have in xulrunner nowadays, needs some work, though I do hope 3.6 will require less work than 3.5 has and will. ATM, 3.5 is definitely not release-ready, and a lot of work remains to be done: - Build and test rdeps against newer version (applications such as epiphany[1], and plugins) - Patch liboggplay, liboggz, libvorbis, libtheora, etc. with the necessary patches, and make sure it doesn't break other packages. - Build xulrunner against these patched libraries instead of the bundled oned as currently is the case. Once we're done with this, the same will have to done again for 3.6. As the whole depends on more than myself alone, it's hard to give an evaluation on how long these transition will take. I'm not even able to say how long it will take me to get 3.5 itself in shape. Cheers, Mike 1. Note that epiphany may be totally dropping gecko support in the near future (and I hear yelp and devhelp should, too), but that still leaves us with at least galeon and kazehakase. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: open issues with the hppa port
Andreas Barth wrote: * Carlos O'Donell (car...@systemhalted.org) [090821 16:49]: xmms2 is the only package that doesn't build. Analysis of the xmms2 build shows that this is a python crash. Thankfully the python crash reproduces (in a different location each time). I'll look into this. Good. I might still break this package because libcdio is blocking lots of binNMUs, and we need to try to keep transitions as small as possible, but of course as soon as this package is fixed it's welcome to get in sync (and if you need help for that from the release team please don't hesitate to contact us). I was able to build xmms2 for hppa using a non-SMP kernel and have done a porter upload for it in order to facilitate the transition to testing. I have done that only because the underlying problem is actively being investigated, and of course the search for the cause of the failure should not be stopped because of my upload. Cheers, FJP -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
