Re: Streamlining d-i releases
On 16829 March 1977, Cyril Brulebois wrote: I put SSH trigger into the room, instead of sudo. You supply the version on the ssh cmdline, and if that exists in unstable, a copy-installer is run with that version. That looks very good to me, thanks! Could even be extended to have source and target suite selectable too. I think we only released the installer via tpu once, at least that I could confirm by checking my sent box: I prepared a little script. Now need a SSH key to allow. Usage is simple, you MUST supply a version, you CAN supply a source and a dest suite. Space seperated. It checks amd64s installer in that suite, and if the version directory exists, it calls dak copy-installer on it. -- bye, Joerg
Re: Streamlining d-i releases
On 16824 March 1977, Cyril Brulebois wrote: I realize that getting a sudo line on fasolo would mean increasing the security risks quite a bunch for a limited gain. Since we already have a mechanism to trigger changes in the archive via release team access, that is /srv/release.debian.org/www/proposed-updates/*_comments (which we can edit from coccia); maybe something similar could be done to trigger dak copy-installer? I put SSH trigger into the room, instead of sudo. You supply the version on the ssh cmdline, and if that exists in unstable, a copy-installer is run with that version. Could even be extended to have source and target suite selectable too. -- bye, Joerg
Re: Please dak copy-installer 20210731
On 16211 March 1977, Cyril Brulebois wrote: FTP Masters, please sync the installer from sid to testing, as it seems to be Installed for all release architectures (9 total): dak copy-installer 20210731 $ dak copy-installer 20210731 Will copy installer version 20210731 from suite unstable to testing. Architectures to copy: i386, amd64, mipsel, ppc64el, s390x, armel, armhf, arm64, mips64el Architectures to skip: Installer has been copied successfully. -- bye, Joerg
Re: Finding a tentative bullseye release date
On 16197 March 1977, Paul Gevers wrote: Albeit there is some progress, we think it better for the people involved to now say that we will *not* release on July 31. Unfortunately, that means that we have to start looking for a new date again. Assuming what we'll learn in the upcoming week or two is good, I propose to already start the list below with two weeks after the previous date. Upcoming time is around DebConf, I can imagine it could even be an advantage, especially as that's on-line, let's see. I am away from 7th to 21st August (including both), at a place with very bad internet, so those are out for me. 14 August (day before DebCamp) 21 August (last day of DebCamp) RT: elbrus Not me. 28 August (DebConf) RT: elbrus 4 September RT: elbrus 11 September: RT: elbrus Can do all three. -- bye, Joerg signature.asc Description: PGP signature
Re: 10.7 planning
On 15937 March 1977, Adam D. Barratt wrote: In an attempt to be slightly more efficient than usual at planning a point release... it's about a month since 10.6, so let's start looking at dates for 10.7. - November 21st - November 28th - December 5th Right now they all look good for me. -- bye, Joerg
Re: Scheduling 10.2
On 15562 March 1977, Adam D. Barratt wrote: - November 9th - November 16th - November 23rd All work for me. -- bye, Joerg
Re: Please dak copy-installer 20190410
On 15369 March 1977, Cyril Brulebois wrote: FTPmasters, please sync the installer from sid to testing: dak copy-installer 20190410 [ master ] dak@fasolo:/srv/ftp.debian.org/web$ dak copy-installer 20190410 Will copy installer version 20190410 from suite unstable to testing. Architectures to copy: i386, amd64, mipsel, ppc64el, mips, s390x, armel, armhf, arm64, mips64el, hurd-i386 Architectures to skip: Installer has been copied successfully. -- bye, Joerg
Re: Scheduling 9.9
On 15351 March 1977, Jonathan Wiltshire wrote: - April 27 Wfm. -- bye, Joerg
Re: Please dak copy-installer 20190118
On 15287 March 1977, Cyril Brulebois wrote: FTPmasters, please sync the installer from sid to testing: dak copy-installer 20190118 [ ] dak@fasolo:~$ dak copy-installer 20190118 Will copy installer version 20190118 from suite unstable to testing. Architectures to copy: i386, amd64, mipsel, ppc64el, mips, armel, armhf, arm64, mips64el, hurd-i386 Architectures to skip: Installer has been copied successfully. -- bye, Joerg
Re: Scheduling 9.7
On 15286 March 1977, Jonathan Wiltshire wrote: - Feb 9 - Feb 16 Can deal with both. -- bye, Joerg
Re: Scheduling 9.5
On 15077 March 1977, Adam D. Barratt wrote: >> - July 7th >> - July 14th >> Are people available for either or both of those dates? > The 7th is looking like the favourite so far (although would mean > freezing next weekend), but we still need an ftp-master (N)ACK on > either / both date. No way for me for both, sorry. -- bye, Joerg
Re: Scheduling final Jessie point release, 8.11
On 15037 March 1977, Jonathan Wiltshire wrote: > - 23rd Jun Ok. > - 7th July No. -- bye, Joerg
Re: Scheduling 9.5
On 15037 March 1977, Jonathan Wiltshire wrote: > - May 26th (meaning freeze this coming weekend, which might be a big > ask) No. > - Jun 2nd (which may require an unusual SRM) Possible. > - Jun 9th (getting quite a way out of cadence, but maybe that can't be >helped) Possible. -- bye, Joerg
Re: Scheduling 9.4
On 14944 March 1977, Julien Cristau wrote: > we shipped 9.3 a couple of months ago, so we're overdue for 9.4. > Can you please let us know your availability on the following: > - March 3 > - March 10 Can do. > - March 17 Not very good > - March 24 > - March 31 No way. -- bye, Joerg
Re: Scheduling 9.1, maybe 8.9
On 14714 March 1977, Jonathan Wiltshire wrote: > A month or so from 9.0 bring us to about 15th July. How would any of these > suit? Is 8.9 at the same time feasible? > 8/9 July (probably a bit soon) > 15/16 July Both of them don't work for me. > 22/23 July That I could do. -- bye, Joerg
Re: Please dak copy-installer 20170407
On 14636 March 1977, Cyril Brulebois wrote: [ ] dak@fasolo:~$ dak copy-installer 20170407 Will copy installer version 20170407 from suite unstable to testing. Architectures to copy: i386, amd64, mipsel, ppc64el, mips, s390x, armel, armhf, powerpc, arm64, mips64el, hurd-i386 Architectures to skip: Installer has been copied successfully. -- bye, Joerg
Re: 8.8 planning
On 14611 March 1977, Julien Cristau wrote: > * April 8-9 No > * April 15-16 Possible > * April 22-23 Ok > * April 29-30 Ok > * May 6-7 No. -- bye, Joerg
Bug#850801: unblock: win32-loader/0.8.1
On 14548 March 1977, Didier Raboud wrote: > ftpmaster: please copy debian/tools/win32-loader/unstable into …/testing Done -- bye, Joerg
Re: Please dak copy-installer 20170112
On 14550 March 1977, Cyril Brulebois wrote: > FTPmasters, please sync the installer from sid to testing: > dak copy-installer 20170112 dak copy-installer 20170112 Will copy installer version 20170112 from suite unstable to testing. Architectures to copy: i386, amd64, mipsel, ppc64el, mips, s390x, armel, armhf, arm64, mips64el Architectures to skip: Installer has been copied successfully. -- bye, Joerg
Re: 8.7 planning
On 14526 March 1977, Julien Cristau wrote: > Jan 7th/8th > Jan 14th/15th Should work. > Jan 21st/22nd > Jan 28th/29th - Cambridge BSP, probably not ideal > Feb 4th/5th - FOSDEM, probably not great either > Feb 11th/12th None of them for me. -- bye, Joerg
Re: Release impact of introducing a new archive section?
On 14518 March 1977, Josh Triplett wrote: >> (my first thought was a canonical online location, but these tools may >> not want that at runtime and can't rely on it at build time, but maybe >> that should be the source used for the package) > Packaging this data (section names, short descriptions, and long > descriptions) seems like a great idea. Ideally, packages would have a > Depends on this and use the data at runtime, rather than using a > Build-Depends and compiling it in. With some care, such a package could > also serve as the basis for the descriptions on packages.debian.org. Does it need a package? Or just a file in the archive somewhere? -- bye, Joerg
Re: Release impact of introducing a new archive section?
On 14516 March 1977, Josh Triplett wrote: > I've now written and submitted all of these patches. Thanks! Lets give it some time for them to get into packages and then we add sections. Please ping again, so it doesnt get forgotten. -- bye, Joerg
Re: 8.5 and 7.11 planning
On 14307 March 1977, Julien Cristau wrote: > with wheezy EOL, we should get a final point release out. In order to > avoid version skew, it'd be good to have a jessie point release around > the same time, so if that works for everyone let's do them both on the > same Saturday again. > June 4th/5th > June 11th/12th > June 18th/19th > June 25th/26th All work for me. -- bye, Joerg Five exclamation marks, the sure sign of an insane mind. -- Terry Pratchett, Reaper Man
Re: Please dak copy-installer 20160106
On 14179 March 1977, Cyril Brulebois wrote: > FTPmasters, please sync the installer from sid to testing: > dak copy-installer 20160106 Done -- bye, Joerg [...] While Debian is certainly about beer, and in some cases may even be about free beer, Debian is mainly about free speech.
Re: 8.2 and 7.9 planning
On 14037 March 1977, Adam D. Barratt wrote: We're somewhat overdue for both 8.2 and 7.9 now (in that order). Some potential September dates: 5/6th - okay for me 12/13th - the 12th doesn't work for me until at least mid-afternoon 19th/20th - looks okay 26th/27th - looks okay All dates do seem to work for me currently, assuming the ftpmaster foo is done on Saturday (one right after the other?!), otherwise the 13th won't work out. On the 5th I would be available only about 2 hours later than usual starting times. -- bye, Joerg Oh, so they have internet on computers now!
Re: 8.1 (and maybe 7.9) planning
On 13951 March 1977, Adam D. Barratt wrote: Based on received responses and the current date, I'm proposing June 6th for 8.1 (and then looking at other dates for 7.9). Does that still work for people? Sounds ok to me. Start at 10 UTC or earlier/later? I was assuming either 8ish UTC (skipping dinstall) or 10ish UTC (after dinstall). Either would work for me, I'll just need more coffee for the former. :-) I've put 12 to 14 (so 10 to 12 UTC) in my calendar. -- bye, Joerg I think Smithers picked me because of my motivational skills. Everyone says they have to work a lot harder when I'm around. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87egm4n7zl@gkar.ganneff.de
Re: 8.1 (and maybe 7.9) planning
On 13927 March 1977, Adam D. Barratt wrote: We're also a little overdue for 7.9 as Jessie work took precedence; 7.9 really wants to take place after 8.1, as we have some packages for which pu opu stable. May 23/24 Works May 30/31 Works June 6/7 Works. June 13/14 Nope. June 20/21 Should work. -- bye, Joerg (23:02) liw I should take a photograph of my stapler, the maker of which is RAPESCO -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87sibgarz6@gkar.ganneff.de
Re: Bug#763148: Prevent migration to jessie
On 13926 March 1977, Bálint Réczey wrote: 2015-04-29 15:38 GMT+02:00 Emilio Pozuelo Monfort po...@debian.org: On 29/04/15 14:29, Bálint Réczey wrote: The last word from the Security Team was Moritz's email which gave ffmpeg green light after Jessie's release. No. He said that a decision between libav and ffmpeg would still have to be made. IOW, we won't ship Stretch with both libav and ffmpeg. He gave a green light to migration, it is very clear. Please answer my question, I'm not sure who I am talking to: Please clarify if the opinion you shared here is your own private opinion (as a DD) or the Release Team's official position. Note that as a DD you can engage in discussions about ffmpeg but can't keep the block alive. Reading this thread and how release team members get hit to allow one package into testing makes me want to use my ftpmaster hat to remove it entirely from Debian. Have you read their delegation? It's the release teams right to keep a package out of testing, even if you don't like them using that right. And that goes for every single member, so sod the your own private opinion or teams position, as soon as someone tells you no, then its a no. As usual with people using their delegated rights you have ways to go get to change that. Tons of repeating on a list thread/bug is not one of them. Especially not as you got told how it can get unblocked. -- bye, Joerg -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/871tj2ykvi@delenn.ganneff.de
Re: Scheduling for 7.3
According to the normal schedule, the point release for 7.3 is due somewhere around 12th December. How does everybody look for the weekends of: 14th/5th 21st/22nd 28th/29th December? Based on the responses so far, if we want to be sure to have an ftpmaster, SRM and CD-master available then it looks like the 14th might be the best bet. I put it in my calendar for the 14th now, so should be available then. -- bye, Joerg From a NM after doing the license stuff: I am glad that I am not a lawyer! What a miserable way to earn a living. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878uw33pz6@gkar.ganneff.de
Re: Scheduling for 7.3
On 13397 March 1977, Jonathan Wiltshire wrote: According to the normal schedule, the point release for 7.3 is due somewhere around 12th December. How does everybody look for the weekends of: 14th/5th Works 21st/22nd Should work. 28th/29th December? Does not work. -- bye, Joerg Some NM: main contains software that compiles with DFSG. [hehehe, nice typo] Of course, eye mean complies, knot compiles. Sum typos cant bee caught bye spelling checkers. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ob5ilw41@gkar.ganneff.de
Re: Next (old)stable point releases
Am 19.08.2013 15:55, schrieb Julien Cristau: we should start thinking about dates for the 7.2 and 6.0.8 point releases. Which week-ends in the coming months would work for ftpmaster, press and cd? (We'd need one date for stable and another later for oldstable.) We COULD do both at once, at least ftpmaster. Cant say for cd/press, though cds may be hard. - Sep 7-8 - Sep 14-15 - Sep 21-22 - Sep 28-29 - Oct 5-6 - Oct 12-13 - Oct 19-20 - Oct 26-27 Right now it looks like I can do all of them. -- bye Joerg -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2a269f20147181e06bfa6d6d3c7c8...@mail.ganneff.de
Re: Wheezy point release planning
On 13209 March 1977, Adam D. Barratt wrote: Based on some informal queries a little while ago, the weekend of 15/16 June looks like a good date for the first wheezy point release. Would that work for everyone? I'll be away then, with a TZ=UTC+8 and not very good net connection. So I'm basically out of it, hope Ansgar/Mark can jump in and do it. -- bye, Joerg I'm having the best day of my life, and I owe it all to not going to Church! -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87li7j8kmw@gkar.ganneff.de
Re: Hurd and the archive
with all the others (probably as a technology preview)... So, release people: How likely is it that Hurd gets added to jessie? If added as a 'technology preview', what does that mean exactly? Note that the tech preview was a softening of a requirement to get added to wheezy. Which didnt happen... Would Hurd-specific RC-severity bugs stall a package's transition to testing? And would it be necessary to fix all Hurd-specific RC bugs to be able to release? Unless it is added as a (whats the term in the code? fucked_arch?) well, second class arch thats usually ignored, then yes, adding it will come with all the usual requirements of a release arch. Adding it and then keeping it out of the usual migration rules is asking for failure from the beginning, accumulating cruft. Not a way to go, IMO. From the view of maintainers I think that would be the deciding factor, because it could imply extra work. Not everyone sees the benefits of porting efforts (whereas I see it as excellent QA and promotes better software design, hence I'm in favour of inclusion). I would be in favour of including it if it actually would look like it could be as up to the task as all the rest of the architectures are. But it doesn't appear to me that it is that. -- bye, Joerg rvb Dafür hat Ubuntu nen kleinen. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ppx37vt9@gkar.ganneff.de
Hurd and the archive
Hi From our FTPMaster meeting 2011 minutes[1]: --8schnipp-8--- - In a discussion with the Debian Hurd porters it was decided that the Hurd port stays on FTPMaster until Wheezy is released. Should they have managed to get the port into a state that it is released together with all the others (probably as a technology preview), it is kept in the archive. Should they not manage this the port will be removed from the main archive and move fully to debian-ports.org. It may then reenter the main archive whenever it is ready to get released with the next release. (Obviously when we say move to debian-ports this does not mean we expect the debian-ports people to just eat it. They are running their archive and may have their own needs and pre-conditions prior to accepting a port, like getting help with the work that needs to be done or with the hardware for it, so any port who has to look for new place should ensure to coordinate with the involved people.) In case it does not work out with debian-ports.org, the removal from main will still be done, but we are confident that the teams can work out something acceptable. --8schnapp-8--- Well. I don't see it in Wheezy. Though I remember something along the lines of if it enters testing (aka jessie) right after wheezy is out, it's fine too. I don't know if it will, and it is not my call. Thats why -release is CCed. So, release people: How likely is it that Hurd gets added to jessie? Within the next one or two months I mean, not maybe in a years time. :) [1] https://lists.debian.org/debian-devel-announce/2011/03/msg00015.html -- bye, Joerg You tried your best and failed miserably. The lesson is: never try. pgpwmBlPcphku.pgp Description: PGP signature
Re: 6.0.7 planning
On 13118 March 1977, Adam D. Barratt wrote: We're somewhat overdue with the next Squeeze point release (6.0.7) and it'd be good to get it done before the wheezy release, so that we can pull in some upgrade fixes. As an opening gambit, some proposed dates, all of which appear to currently work for me: February 23rd March 2nd March 9th All should work for me. -- bye, Joerg liw I'm kinky and perverse, but my illness is laziness -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zjzasa3o@gkar.ganneff.de
Re: Squeeze point release (6.0.6)
On 12962 March 1977, Philipp Kern wrote: I'd like to arrange a point release to be done as soon as feasible. So I'd like to propose a bunch of weekends here: * Sep 22/23: I'm personally busy on the 23th Right after the ftpmaster meeting. Might work. * Sep 29/30: ok from RT side Works for me. * Oct 6/7: Adam's busy for the weekend, hence we'd like to avoid that if possible * Oct 13/14: BSP attended by adsb/Sledge, not ideal to schedule it there Not in October. -- bye, Joerg Thats all. Just a few questions about your package and then we got it and you will be in DAMINATION :). I have no idea what DAMINATION is but it sounds cool. Let's get going. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sjaojnho@gkar.ganneff.de
Re: Architecture qualification
On 12861 March 1977, Steve McIntyre wrote: There's a related question, which I just realised wasn't actually explicit - does it make sense to add an architecture to testing at this stage of the process which we don't think is releasable? My memory of previous discussions is that the general answer was no, although this possibly depends on how one views the purpose of the testing suite. Definitely not, IMHO. How hard are the RT / ftpteam going to stick to the ship with Wheezy or you're out agreement as written in http://wiki.debian.org/Debian_GNU/Hurd ? Is Hurd at the point where we could *reasonably* ship it as (at least) a technology preview? I am pretty set on that. There isn't much point in coming to an agreement just to kick that out the door only because the time has come to actually do something about it. (And why didn't inclusion of hurd got a topic like, half a year or more ago?) There is only one thing I would agree on: If the RT decides to not include them in wheezy but add them to wheezy+1 right after wheezy is released (so we would be doing it during the process) and keep them there for the next release, then fine. Thats not exactly what we agreed on, but would be a workable compromise. I'm unconvinced that it is, being brutally honest. Ack. I also think it is way to late before the freeze to add something like a whole architecture (and hurd is more than just a plain architecture) *now*, where we already kick maintainers for uncoordinated package transitions, prepare to kick people putting (uncoordinated) SONAME changes into NEW and generally want to have a freeze RSN. Also, what is really changed when we do this? - hurd is no longer on the main mirrors. But only on those carrying debian-ports. * So what? Yay, we suddenly stop mirroring something to thousands of places which is used by less than anything else. Don't tell me there are so many users of hurd that it really warrants the wide spread mirroring. Especially with it being very limited on desktops and probably serious servers[fn:1] too? (Reading from http://wiki.debian.org/Debian_GNU/Hurd and links) - hurd can come back into the main archive following the usual archive qualification every other new addition has to follow. Clean, simple, straight forward. - We are rid of a special case of an unstable/experimental only architecture that often keeps pretty outdated packages in the archive. Less general maintenance work. Of course the above is my personal opinion and ftpmaster is a team. It might happen the rest disagrees with me and tells me to sod off, but I think thats highly unlikely, from what I know. Footnotes: [fn:1] That is, not just yeah, here, look, there is a server, but there is a server that actually has a production used application on it. Is HA and whatnot, and $company does $lotsathingswithit, relies on it -- bye, Joerg Ich will ein anderes Telefon, das hier klingelt immer! -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8762bfcvw7@gkar.ganneff.de
Re: installer location on mirrors
On 12854 March 1977, Daniel Baumann wrote: Thats not a new thing - and still we dont have any such image in Debian. non-free is not part of the official debian, yet we have non-free archive areas, so that's not an argument. some derivatives are building d-i images with firmware udebs from non-free included. debian should provide this on the archive level too (read: non-free udeb Packages/Sources indicies), regardless if the official debian images are using it yet or ever. On 12854 March 1977, Holger Levsen wrote: On Montag, 21. Mai 2012, Joerg Jaspert wrote: Thats not a new thing - and still we dont have any such image in Debian. /me likes http://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/even though I know it's not Debian ;-) And both of you just miss the point. We are NOT talking about udebs. We are NOT talking about whatever debian-cd creates. We are talking about the installer images. Those that fall out of the debian-installer source. And create the files you can find on any mirror in $suite/main/installer-* and which we never had in contrib or non-free. But the link to debian-cd created images answers the question in a different way: It won't have installer images in contrib/non-free. The only non-free stuff we would be likely to add - is added by debian-cd in an extra set of cd images. -- bye, Joerg Trying is the first step towards failure. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87likkfpxb@gkar.ganneff.de
Re: installer location on mirrors
On 12853 March 1977, Joey Hess wrote: Joerg Jaspert wrote: I understand it right that doing it this way (ie. current symlink stays around), it won't break anything, so we can just do it for all suites?! It appears that debmirror will be broken, if it helps. :/ Urgs. I can't find anything that will break in debian-cd. How big/intrusive would the change to debmirror be to adjust it to deal with the changed layout too, do you think it can be done now and included in wheezy? And even more, squeeze, a point release update there? Or is it so much that we only make wheezy able to deal with it and move it after we archive out squeeze? -- bye, Joerg It seems to me that the account creation step could be fully automated: checking the box approved by DAM could trigger an insert into the LDAP database thereby creating the account. 1375.143.121.153.52.1122977888.squir...@wm.kinkhorst.nl -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87hav93l7n@gkar.ganneff.de
Re: installer location on mirrors
I also take it we don't need/want the main/contrib/non-free in installer/, as our d-i will always be main/ only. What about firmware stuff? Thats not a new thing - and still we dont have any such image in Debian. Does firmware stuff itself need a whole image? Is anyone working on it (to be included in Debian), and is it realistic to be there anywhere in the next one or two releases? -- bye, Joerg [Es geht um MySQL] (14:35) Lam_al_Adie grummel. als ob ein subselect so kompliziert waere. (14:35) maxx als ob mysql eine db wäre... (14:35) plaisthos relationales textfile auf drogen? :0 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mx51i60e@gkar.ganneff.de
installer location on mirrors
Hi
a recent thread on the -dak list pointed me back to a topic that I want
to have fixed for some time now, which is the location of the installer
stuff... (Actually quite some more, but the important part for the
boot/release list is this).
I don't think the installer images should be in dists/ as they are now,
but get their own location, installer/. For various reasons, including
the - wth was it added there in the first place, - currently an
installer update move from one suite to another means real
copies/moves. Why, pool/ got rid of that for our packages, why do we
have it for the installer? Also, its really big and doesn't belong into
dists/, which is more like a set of Package indices.
So the proposed structure I have in mind ends up to look like this[fn:1]:
--8schnipp-8---
installer/
amd64/
20110106+squeeze4+b1/
20120327+b2/
20120507/
20120508/
sid - 20120508
squeeze - 20110106+squeeze4+b1
wheezy - 20120508
i386
[...]
[...]
--8schnapp-8---
There is one drawback I see outright - we no longer have a current
link. I might miss something here, but is the current link really
required, if we build it up like the above?
Currently the installer images have their MD5/SHA256SUMS included in the
Release file, so they can be checked and validated against the same key
all the rest of the archive is. We should keep the validation part, but
I am not sure we want to continue listing them in the Release file per
suite.
Instead I think we should have an InRelease[fn:2] file appear in
installer/, which lists all installers checksums files:
--8schnipp-8---
Origin:
Label:
Date:
Valid-Until: (Date+2weeks)
Architectures:
Description: Debian installer images
CHECKSUM1:
12345deadbeef amd64/20120507/images/MD5SUMS
deadbeef54321 amd64/20120507/images/SHA256SUMS
[...]
CHECKSUM2:
12345deadbeef42424242 amd64/20120507/images/MD5SUMS
deadbeef5432142424242 amd64/20120507/images/SHA256SUMS
[...]
--8schnapp-8---
This file would be inline clear signed, just as InRelease files are now.
Timeframe: I would like to change to this new layout pretty soon. Two
weeks? A month? Something there.
For all releases, including the stable stuff, though that needs the RMs
ok, obviously.
To not break whatever trillions of links we have and whatever expects
things in dists/ right now, I propose to move it all over, and set
symlinks from dists/ over to the right installer/ place. That is, dists/
keeps the installer-*/ dirs in main, and the 20XXwhatever/ and current
links are updated to point to the installer/$arch/$foo, where current/
will link to one of sid/squeeze/wheezy.
That way we can benefit from moving gigabytes of stuff out of dists/ but
still have stuff all working. Those links we should then get rid of for
anything wheezy. Until then the installer checksums would appear in
the suites release files, as of now.
Obviously I might have missed any number of points here, so now is the time
to beat this down. And/or change the layout to something else, if there
is anything better for it. I mainly move it out of the way of dists/
with this.
Footnotes:
[fn:1] Now, this depends a little if we will ever have installer outside
the main component. We currently do not have that, and I think the
likelyhood of it is very small. Thats why I propose it without a
component in the path entry, but if d-i people say it is more than
possible to actually end up with images for something else than main,
then insert a {main,contrib,non-free} right above the architectures.
[fn:2] I realize InRelease would be a stupid name at that position. And
the fields I propose are more than are strictly needed. I'm all happy
to get talked to drop that and end up with just a file that shows two
checksums for each of the installer checksum files, and be done.
The reason I went with the InRelease one is that tools know them, so
why break out?
--
bye, Joerg
Son, when you participate in sporting events, it's not whether you win
or lose: it's how drunk you get.
pgpXam6tjpbjS.pgp
Description: PGP signature
Re: installer location on mirrors
On 12851 March 1977, Joey Hess wrote: I don't think the installer images should be in dists/ as they are now, but get their own location, installer/. For various reasons, including the - wth was it added there in the first place, - currently an installer update move from one suite to another means real copies/moves. Why, pool/ got rid of that for our packages, why do we have it for the installer? Also, its really big and doesn't belong into dists/, which is more like a set of Package indices. It seems like pool/main/d/debian-installer/$ARCH/$version would be a good place to put it. Unless having non-debs in pool would break something's assumptions. Yeah, at least one dak tool does. check_archive, comparing pool/ with what is in the database. I have no idea if anything external does so too. Also it would introduce things into pool/ that aren't in any index, AKA packages/sources. Don't know what tools like debmirror/reprepro would say about that. Though, debmirror probably just ignores it. If it's in pool, then dists could just link to the right one, ie: dists/sid/main/installer-i386/current - ../../../../pool/main/d/debian-installer/i386/20120508 I think this preserves backwards compatability in a clean way that won't need further work later, while meeting your goals. We can do the same thing putting it in installer/, i think. wheezy - 20120508 There is one drawback I see outright - we no longer have a current link. I might miss something here, but is the current link really required, if we build it up like the above? What if a user is installing stable and cannot remember the release code name? (Not hypothetical; I couldn't tell you the current release codename offhand.) The advantage of keeping the symlink in dists is that it's right there with the other files for whatever dist the user navigates to. Also it avoids special cases. I wonder which special cases, but I won't object to keep the current symlink. Compared to what we have now, thats small. :) So to rephrase my proposal: - dists/*/main/installer-$arch content moves to installer/$arch/ - dists/*/main/installer-$arch/current will be a symlink into installer/$arch/, pointing to the latest for that suite - Updating the installer from one version to another (like, point release time) is a simple change of the current symlink. - additionally we have the $release - $version links as described in my first mail, for people that go directly into installer/ (and can remember the codenames :) ). I also take it we don't need/want the main/contrib/non-free in installer/, as our d-i will always be main/ only. I understand it right that doing it this way (ie. current symlink stays around), it won't break anything, so we can just do it for all suites?! -- bye, Joerg Getting out of jury duty is easy. The trick is to say you're prejudiced against all races. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k407nclq@gkar.ganneff.de
Re: Architecture qualification meeting for Wheezy
On 12824 March 1977, Niels Thykier wrote: [3] http://raphaelhertzog.com/2012/04/19/people-behind-debian-samuel-thibault-working-on-accessibility-and-the-hurd/ The Debian GNU/Hurd port can almost completely be installed from the official mirrors, using the standard Debian Installer. Not sure if that means we have imported packages (which are not showing up on my radar) or if it is just an installer issue (which would be covered by the table). They do: https://lists.debian.org/debian-hurd/2012/04/msg00110.html and ff. You need to check the build logs what they use for building packages. There is stuff in there thats only from d-p.o. Also, see https://lists.debian.org/debian-hurd/2012/04/msg00110.html -- bye, Joerg I'm normally not a praying man, but if you're up there, please save me Superman. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y5pjdoof@gkar.ganneff.de
Re: Description-less packages file
On 12750 March 1977, Andreas Tille wrote: On Tue, Feb 07, 2012 at 10:29:50PM +, Adam D. Barratt wrote: On Tue, 2012-02-07 at 23:26 +0100, Julien Cristau wrote: On Tue, Feb 7, 2012 at 22:59:25 +0100, Andreas Tille wrote: Regarding squeeze: Could somebody give some reasons for refusing an additional field in the Packages files? It is hard to cope with it is unlikely. A yes or no would be more helpful to find a reasonable decision for the UDD importer. It's not just a simple oneline more thing. It ends up being long desc goes away, d-md5 field gets in. Plenty disruptive. -- bye, Joerg maxx Aqua mach mal man brain Aquariophile maxx: schon probiert das gibts ned -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87haz1cddt@gkar.ganneff.de
Re: Description-less packages file
On 12749 March 1977, Andreas Tille wrote: Could somebody from the release team please give a statement whether there is any chance to inject description_md5 fields into the packages files from Squeeze (and Wheezy). Learn to read: In the last mails, cited many times, my sql query, the result. Wheezy has it. -- bye, Joerg Homer no function beer well without. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8739ame02v@gkar.ganneff.de
Re: Planning for next squeeze point release (6.0.4)
As an opening gambit, I'd propose we look at one of the following Saturdays in January: 14th, 21st, 28th. 21st and 28th (with the respective day after the actual release day, to do the live images) are fine for me. The 28th would be preferable for me. Would that still work for everyone else? Right, sounds ok for me. -- bye, Joerg All right pie, I'm just going to do this (munch munch). And if you get eaten, it's your own fault. (munch munch, bang) Ow! Oww!! My... Oh, the hell with it! -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8739brzmjw@gkar.ganneff.de
Re: Planning for final lenny point release (5.0.10)
On 12693 March 1977, Adam D. Barratt wrote: From the experience of etch's EOL point release, we'll need a little time to sort out any remaining build issues for security packages after the end of support. The earliest we'd therefore be looking at would be the weekend of 11/12th February. Does sound fine to me, but do you really want only one week between the end of security and the final point release? Its not much time, should security really push out something that ends up plenty broken... How high THAT possibility is i dont know, but meh. -- bye, Joerg cryogen gender is something i'll never really get either cryogen (hmm, that looks bad out of context) -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sjkoqk9b@gkar.ganneff.de
Re: Planning for final lenny point release (5.0.10)
On 12693 March 1977, Adam D. Barratt wrote: Does sound fine to me, but do you really want only one week between the end of security and the final point release? Its not much time, should security really push out something that ends up plenty broken... How high THAT possibility is i dont know, but meh. It was an absolute earliest date but, yes, we should probably leave a little longer just in case[tm]. To be on the safe side, maybe we should consider weekends between mid February and mid-to-late March? For *me*, set the end point at around mid March, after that I wont guarantee availability right now. -- bye, Joerg Die Dicke zum Spiegel: Spieglein, Spieglein an der Wand, wer ist die Schönste im ganzen Land? Der Spiegel: Geh doch mal weg, ich kann ja gar nichts sehen! -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vcpkp2av@gkar.ganneff.de
Description-less packages file
Hello world, I don't know if I really got everyone who should have a copy of this mail in my CC list, so please forward it to wherever you think I am missing. Thanks. I just merged a patch from Ansgar to generate the Packages files without the English description embedded inside them. Instead they are now written into a new file, the English Translation file in main/i18n/Translation-en.bz2. They thus appear alongside all other translated descriptions as just another language. apt co will (or should) just download those Translation files to show the description, as they do already for all other languages. This lets us save quite a bit of space on our mirrors by not repeating them as many times as we have architectures - and also enables non-English-speaking users (and eventually multi-arch enabled APT) to save on download size, as they no longer need to download a language that is of no use to them or is already there. As this is is a larger changeset we did not switch the official dists/ tree directly. Instead we are providing files generated in this way over at [1] for you to test with and report bugs you find in this implementation or in the handling of it in whatever tool breaks down. That location is updated right during dinstall so should always contain current information. Provided there are no showstoppers turning up we intend to switch the official dists/ tree one month from now. [1] http://ftp-master.debian.org/newdists/ -- bye, Joerg It’s not easy to juggle a pregnant wife and a troubled child, but somehow I managed to fit in eight hours of TV a day. pgpcPGKyreXve.pgp Description: PGP signature
Re: Point release schedule
On 12594 March 1977, Philipp Kern wrote: so apparently September is a very bad month to get CDs done. I'm hereby proposing the following with the hope that we can do it that way: * Lenny: October 1st * Squeeze: October 8th Can we do that, pretty please? :) Any objections? I screwed up the initial mail because there were three recipients like on the checklist, but actually I do need four. Can you comment on the above dates? We already got an OK from Sledge. I could do both. -- bye, Joerg http://meta.wikimedia.org/wiki/How_to_win_an_argument -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874o0qi4n8@gkar.ganneff.de
d-i decruft in sid
Heyho we just noticed that the dists/sid dir is getting unreasonably large, its at 11gigabyte right now. Most of that due to a huge number of d-i versions we have. Can we decruft some of them? The more the better. Below is a list of the current ones, please tell me which of them I should leave and which I can decruft. Also note that we still pursue the idea of getting the installers moved out of dists/. We just came up with a better way to do it during this meeting, but didn't find the time to implement it yet. So we will leave them at the current place for now, but the move will happen. installer-alpha/: 20090123 current installer-amd64/: 20100122 20100211 20100211+b1 20100719 20100722 20100911 20100912 20101020 20101121 20101127 20110106 20110106+b1 current installer-armel/: 20100122 20100211 20100722 20100912 20101020 20101121 20101127 20110106 20110106+b1 current installer-hppa/: 20100122 20100211 20100211+b1 20100719 20100722 20100911 20100912 20101020 20101121 20101127 20110106 20110106+b1 current installer-i386/: 20100122 20100211 20100211+b1 20100719 20100722 20100911 20100912 20101020 20101121 20101127 20110106 20110106+b1 current installer-ia64/: 20100122 20100211 20100211+b1 20100719 20100722 20100911 20100912 20101020 20101121 20101127 20110106 20110106+b1 current installer-kfreebsd-amd64/: 20100912 20101020 20101121 20101127 20110106 20110106+b1 current installer-kfreebsd-i386/: 20100912 20101020 20101121 20101127 20110106 20110106+b1 current installer-mips/: 20100122 20100211 20100211+b1 20100719 20100722 20100911 20100912 20101020 20101121 20101127 20110106 20110106+b1 current installer-mipsel/: 20100122 20100211 20100211+b1 20100722 20100912 20101020 20101121 20101127 20110106 20110106+b1 current installer-powerpc/: 20100122 20100211 20100719 20100722 20100911 20100912 20101020 2010112120101127 20110106 20110106+b1 current installer-s390/: 20100122 20100211 20100211+b1 20100722 20100911 20100912 20101020 20101121 20101127 20110106 20110106+b1 current installer-sparc/: 20100122 20100211 20100211+b1 20100719 20100722 20100911 20100912 20101020 20101121 20101127 20110106 20110106+b1 current -- bye, Joerg Some NM: Debian is mostly about free keysigning^Wspeech. pgpb10wTIsXFY.pgp Description: PGP signature
Bug#611117: unblock: apt/0.8.10.3
Given that the feature was implemented on request for ftpmaster [0] I at least hope they (still) use apt-ftparchive (at least for this)… (and a quick grep over dak shows a few 'a-f generate' calls, but yeah, thats guessing, as the feature implementation was guesswork, but thats a different story… no answer is an answer…) yes, we are still using apt-ftparchive to generate the Packages, Sources and Contents files. Contents is still a major pita. Packages and Sources are okay since we have 16 CPU cores to run the code in parallel. Which, as far as i understand the issue at hand, is the important part here: We do parallel runs of a-f, so each a-f call is only for one arch inside one suite. Ie. one amd64/unstable, one i386/testing, etc. This is true for all dinstall calls, only difference for stable point releases, but there it doesnt matter as we can only use the change with the bug for wheezy and later, so time enough to fix it up. -- bye, Joerg Lisa, Vampires are make-believe, like elves, gremlins, and eskimos. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wrlmy765@gkar.ganneff.de
Re: Bug#607293: 75 unreported RC bugs, (mostly?) fixable by rebuilding / could lintian please prevent such packages from being uploaded in future?
On 12331 March 1977, Adam D. Barratt wrote:
Package: lintian
Severity: wishlist
[...]
To get a list of affected binary packages:
w3m
http://lintian.debian.org/tags/install-info-used-in-maintainer-script.html |
awk '/[(]binary[)]$/ {print $1}'
[...]
Could lintian maintainers please add this lintian tag to
data/output/ftp-master-nonfatal, although this shouldn't occur much in
future since debconf doesn't create this snippet anymore?
Well, we could, but it would be somewhat redundant. The list of reject
tags in lintian is generated from the list on ftp-master, not
vice-versa; if you want the list of tags used by ftp-master to
auto-reject packages, you need to convince them, not us.
Im not against adding more tags.
Im against doing it right now, right after squeeze is a better time. We
dont want to break any possibly needed upload by those packages here.
But lintian could sure go already and make this E, its Severity:
normal, Certainty: possible a Warning now.And Certainty only possible,
does that mean we get false-positives?
--
bye, Joerg
It seems to me that the account creation step could be fully automated:
checking the box approved by DAM could trigger an insert into the LDAP
database thereby creating the account.
1375.143.121.153.52.1122977888.squir...@wm.kinkhorst.nl
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87lj3oghfc@gkar.ganneff.de
Bug#575733: security-master's dak needs to support source format 3.0
Why not use a RC severity then? (not intending to push people, just to make it clear when checking the bugs list). IIRC, the d-d-a mail asked to use normal severity. But maybe in this case it is better to use RC severity now. The release team can still adjust it as necessary. Is there any progress on this? N9on visible, but slowly. It has about the same stand than bpo, and im right now fighting with that. (Database is fun) -- bye, Joerg My first contact with Linux was with SuSE 6.3. A friend of mine installed it on my pc, and just take me a couple of hours to reinstall Windows on it. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d3tw5dsi@delenn.ganneff.de
Re: Constantly Usable Testing BoF @ DebConf10
I'd like to invite any Release and FTP team members who are attending DebConf to the Constantly Usable Testing BoF, Tuesday at 10:30 am. Im not sure I can attend this using the stream, maybe, we will see. But twerner is around in NYC, he might attend it. The purpose of the BoF is to finally explore whether it would make sense to implement the Constantly Usable Testing idea[1], ways to do it, and get feedback and advice from teams that could be affected by it. So it would be great to have some dak and britney wranglers to give advice on topics like: * Snapshotting testing. * How to support upgrades from old testing snapshots to current testing? * Installability/usability of testing. Issues like important packages being temporarily removed due to RC bugs. * Does testing get enough testing? Would having users use CUT improve that and help the quality of stable releases, or the opposite? For dak side - it is not too hard to add another suite, exported to the public or not. What bothers most is the size of a dists/ dir: 32M experimental 1.9Glenny 4.0Mlenny-proposed-updates 3.3Gsid 401Msqueeze 2.0Msqueeze-proposed-updates If we copy testing as is, then thats another 400mb hit there on index files that regularly change. Can we go without contents files? Thats already 200mb. (The pure size isn't a problem, in a tree that has hundreds of gigs, but dists/ is what changes a lot, compared to files in pool/ and that gets a good part of traffic on the mirrors. And our snapshot archive also has to store all the indexes... Having less == good). (And if we can also start this suite not having any bz2 index files, that would be doubly good. They are a pure waste of space, gzip is so much better for our mirrors (--rsyncable does gain a lot)). Also, technically, ftpmaster doesnt want to have to do much with the suite: We run the service, someone else does the work :) That is, we would want a team that has the say about it and that supplies us with an input file that defines how the suite has to look. Once, twice or four times a day. (That will be Heidi Format then) What will be the rules for the versions in CUT? It will definitely be = stable. Also, I think = unstable. No specific relation with testing? Though I think it should be somewhere = testing and every update should go via testing first, it could be wanted to directly get a new version from unstable to CUT, while britney not yet let that migrate to testing. Especially if it ends up being 2 processes that define how testing/cut look. How about the testing-proposed-update suite and the relations there? Does this suite also need a p-u one? (I dont think so) -- bye, Joerg That's just f***ing great, now the bar for being a cool guy in free software just got raised. It used to be you just had to write a million lines of useful code. Now you've got to get a subpoena from SCO to be cool. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877hk98vbb@delenn.ganneff.de
Re: Making auto decruft easier for us and the release team
So, I'm open for ideas how to improve the workflow and making it easier for the release team and us (especially for me ;) We could add an option --verbose to cruft-report that actually runs the suggested commands with the --no-action option added (but only if the command is actually doing an rdep check). And if one made sure no-action actually follows its name. :) Everyone could see the details at http://ftp-master.debian.org/cruft-report-daily.txt as soon as we enable --verbose for the dinstall run. The release team may schedule binNMUs as needed. We could maybe also mail d...@l.d.o with such testing affecting things, when we detect them. Like we do with the p-u-NEW changes. (But keep track of what we already mailed) -- bye, Joerg Mr. Scorpio says productivity is up 2%, and it's all because of my motivational techniques -- like donuts and the possibility of more donuts to come. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vdbiwk7g@gkar.ganneff.de
Re: Please help a apt ABI break by providing bin-NMUs
One feature I asked for in my mail about the long descriptions was having apt-ftparchive split the existing long descriptions out into a seperate file. Is that implemented? apt-ftparchive doesn't split out currently, since apt 0.7.25 [1] however it is possible to set APT::FTPArchive::LongDescription=0 to remove them from the Packages file. In the thread it sounds like there is already some magic tool which creates the Translation files and could easily do -en, too. apt-ftparchive on the other hand doesn't know anything about translation files and I have more or less paused thinking further about implementing it after my unanswered email [2] and just added the remove option and do it my way. (download en and a whole lot of other Translation files depending on LC, recently also LANGUAGE and of course the Acquire::Translation config-list; keeping md5sum as second preimage attacks are a bit too much for a LongDescription; keeping the whitelist as is as long as the acquire system in apt is as idiotic as it is currently with the todo to give it a renewal) Comments are obviously still welcomed. So right now I (as ftpmaster) have to create the packages files as normal, then split out the descriptions with a seperate tool, so others can use them as the english translation. I can not tell apt-ftparchive dont bother, as the stuff a-f is writing *is* the current master of english. (Ie. those taken from the package, and for squeeze this is not intended to change). Those magic tools are reading them and based on that the whole rest is processed. If you could add a mode that does not write them into a packages file but into a seperate one, in the layout I described back then, that would rock and save us a lot of time during each dinstall run! -- bye, Joerg Yeah, patching debian/rules sounds like changing shoes while running the 100 meters track. -- Michael Koch -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y6hncfae@gkar.ganneff.de
Re: Please help a apt ABI break by providing bin-NMUs
On 12059 March 1977, Michael Vogt wrote: the apt team plans to upload a new version of apt around 1. April that unfortunately breaks the ABI. To make this as painless as possible we would like to coordinate this with you so that we can schedule bin-NMUs. The ABI break is required for following new features: - allow Packages file without long descriptions [0] Where can one see the changes that are in that release? The bzr repository is either lying to me or its in another branch elsewhere or ive completly forgot how bzr works or whatever. :) One feature I asked for in my mail about the long descriptions was having apt-ftparchive split the existing long descriptions out into a seperate file. Is that implemented? -- bye, Joerg A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zl24f1fq@gkar.ganneff.de
Re: Mirror team plans for the squeeze cycle
On 11844 March 1977, Marc Brockschmidt wrote: Do you have any big changes planned? How much time would they take, and what consequences are there for the rest of the project? Thanks for asking, but luckily the mirror team plans do not affect the release or freeze time. We do have a lot of work and nice plans, but none of that should affect the release. -- bye, Joerg _DeadBull_ ohne speicher, tastatur, mouse, pladde, monitor, also nur die Hardware... -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ttf-bitstream-vera should not have been removed
On 11791 March 1977, Josselin Mouette wrote: Is it possible to put back ttf-bitstream-vera in unstable, using the version in testing (which was the last uploaded one anyway)? Otherwise, I guess we just have to wait for a new upload. Well, technically yes it is possible. I would much prefer if a new upload is made, so it is properly shown with a maintainer that cares - and not one that wants it gone. A simple rebuild for it shouldnt be much of a problem, its arch:all, not likely to break much. -- bye, Joerg exa And mind you, I have always been respectful to every debian developer EXCEPT Branden. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#515132: debian-installer: source for version of dhcp3-client-udeb used in D-I not in archive
I tried rmadison, but that is/was broken: $ rmadison dhcp3 Traceback (most recent call last): File /usr/local/bin/dak, line 248, in ? main() File /usr/local/bin/dak, line 243, in main module.main() File /srv/ftp.debian.org/dak/dak/ls.py, line 90, in main projectB = pg.connect(Cnf[DB::Name], Cnf[DB::Host], int(Cnf[DB::Port])) pg.InternalError: FATAL: database projectb does not exist Uhm, do you get that consistently? It works just fine here. Maybe you tried exactly when projectb in merkel gets reconstructed from the dumps, which *maybe* makes the database not exist for a small period of time. s/maybe//. It gets dropped and re-created. Unfortunately postgres currently can't do any real (and working) replication, so the merkel copy is handled in a rather ugly way... -- bye, Joerg Could you please add me to the mirr...@debian.org alias. I'm not receiving enough spam. -- Andrew Pollock -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Drafting dedication-5.0.txt
Here's a rough timeline: 1. Fix content -- due: 2009-02-06 2. Call for signatures and translations (d-d-a) 3. Finish collecting signatures -- due: 2009-02-11 4. Hand over files to ftp-masters Do we want to have translations as well? Obviously it will not work out to have them all together signed the same way as the english original, but it can't hurt to have them too. Also, while at it we should look at the placement of them on our mirror. While its ok to put them in doc/, it might get a little crowded in there, and it might not do much good if we add X new files. We could go and create project/dedication/ for it and place them there. -- bye, Joerg Some NM: FTBFS = first time build from source, [...] pgp1fOjHTfCB8.pgp Description: PGP signature
Re: Reboot times for ries
On 11638 March 1977, Adeodato Simó wrote: Once britney moves to 4 runs/day, it'll start at 4/10/16/22 (it's 10/20 at the moment). Britney, unfortunately, and until we get a better version running, has a very variable runtime. I don't know if what DSA asked for was set-in-stone time slots, but there are going to be days when Britney ends minutes before the next dinstall. (¹) No. The timeslots are meant to be flexible and mostly time ranges in which DSA does not need to hunt down an ftpmaster and a release team member just to get an OK for a reboot. But instead can just take look if something unusual is running (like a python process from britney eating all memory for a long time), and if not can just reboot without asking us. OTOH, regarding when people are working on the machine, I think that if reboots are wall'ed with some padding, that's reasonable instead of always having to ask on IRC. IRC can still be used if a quicker reboot is needed, or as a nicety. Yeah, but timeslots also tell you when no normal large dont disturb this please cronjob is meant to be running. -- bye, Joerg dloer Joey was bist du eigentlich offiziell im debian projekt genau? pgpcTvqdygP3b.pgp Description: PGP signature
Dinstall and mirror push frequency
Hi as announced a bit earlier[1], I just changed the frequency of our dinstall run, and as such the frequency of the mirror pushes too. We are now having 4 runs/pushes a day. The runs start at [01|07|13|19]:52 (every 6 hours, starting at 1:52), the mirror push follows approximately an hour later, as usual. All times in UTC. [1] http://lists.debian.org/debian-project/2008/12/msg00014.html -- bye, Joerg Some NM/AM: 24. What does the urgency field in changelog affect? The order in which updates are displayed in tools like dselect, synaptic, aptitude, etc. nice try. :) pgpZzGU0JnrQR.pgp Description: PGP signature
More frequent dinstall runs and mirror pushes
Hi as the subject says, we are planning to increase the frequency of dinstall[1] runs. Our current plan is to have 4 runs a day, switching From the current [07|19]:52 schedule to the new [01|07|13|19]:52 schedule. All times are in UTC. For the mirror network, this means two more pushes a day, but from current experience this is manageable. If we ever go to more than four runs our mirror network needs a different setup, as current rsync deficiencies[2] do not easily allow more frequent pushes. I plan to switch to the new schedule in 2 weeks. [1] dinstall is the programm that moves packages from incoming.debian.org into the Debian archive. [2] rsync needs a very long time to do the initial filesystem check, to find out what it actually needs to do. There is currently (afaik) no way to improve that, as rsync simply offers no way to preseed the needed information. I mailed the rsync list in November, but unfortunately noone picked it up, so for now i don't see a way to make mirror pushes less load on our mirrors. http://lists.samba.org/archive/rsync/2008-November/022140.html If you feel brave and want to help - there is some nice code to write! :) -- bye, Joerg vorlon hmm, I should fill in the buildds box for sparc and make it flash red and green pgpbDN5cOBpxG.pgp Description: PGP signature
sysklogd/rsyslog switch
Heya World, I just did the requested switch, sysklogd/klogd are now priority extra, rsyslog (not its -mysql -pgsql packages) are now priority important. If something else, like Tasks or so, needs to be changed too: Whoever needs to do that please do it. Thanks. -- bye, Joerg [ New Maintainer Prozess ] panthera ein jahr ist ein bisschen zu optimistisch, _rene_ panthera: kommt auf den NM/AM an. /* _rene_ ist pantheras AM und lässt sich mit pantheras package check schon ein wenig Zeit ;) */ pgp8zRUhoTFrH.pgp Description: PGP signature
Re: Bug#490440: Change default syslog daemon to rsyslog in time for lenny
On 11445 March 1977, Marc Haber wrote: On Sun, Jul 13, 2008 at 12:56:11AM +0200, Jonas Meurer wrote: On 12/07/2008 Joerg Jaspert wrote: Those two links clearly say Its better to not have force involved and let the maintainers agree on it. Why do you ignore that and try to force it now, not giving the maintainers any time to act on this? Joey Schulze never contributed to the discussion at any time Judging from the degree how good sysklogd is maintained, if sysklogd's Owner (I don't dare to say maintainer here for a reason) needs to consent, we'll have sysklogd as default syslogd until hell freezes over. The discussion just raised again on -release. Joey got CCed in one or two mails now. Pushing with the bug on the same day is too fast. Instead I like the proposal to wait until Tuesday and then take action. And no, I don't need Joeys OK to do such changes, I just dislike the speed that was used here. Depending on what I see (or not) on the lists/in this bug, I do the change on Tuesday. (I am in favor of it, even if i would have much preferred syslog-ng, but basically anything is better than sysklogd nowadays). -- bye, Joerg maxx Aqua mach mal man brain Aquariophile maxx: schon probiert das gibts ned -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#490440: Change default syslog daemon to rsyslog in time for lenny
On 11444 March 1977, Jonas Meurer wrote: At least one lenny release manager mentioned that he doesn't object against the change and that it's not to late for lenny either yet [7],[8]. Those two links clearly say Its better to not have force involved and let the maintainers agree on it. Why do you ignore that and try to force it now, not giving the maintainers any time to act on this? -- bye, Joerg elmo if klecker.d.o died, I swear to god, I'm going to migrate to gentoo. pgpchOfQSsNC5.pgp Description: PGP signature
Re: Bug#489298: Old testing_probs pages missing
reassign 489298 release.debian.org thanks On 11436 March 1977, Frank Lichtenheld wrote: Hi, the following links (as given on http://www.debian.org/devel/testing) are dead: http://ftp-master.debian.org/testing/testing_probs.htmlhttp://ftp-master.debian.org/testing/unstable_probs.html http://ftp-master.debian.org/testing/stable_probs.htmlhttp://ftp-master.debian.org/testing/unstable_outdate.txt Should we remove these links or will they be available again in the future? Not from us, ftp-master no longer runs testing, thats all release team now. From: Kalle Söderman [EMAIL PROTECTED] Subject: Broken links on the Testing page To: [EMAIL PROTECTED] I noticed that the list of links under Additional Information on the http://www.debian.org/devel/testing page are broken. The server returns Not Found and the files related to problems with the three distributions are not on http://ftp-master.debian.org/testing/ as the links suggest. regards Kalle -- -- bye, Joerg I. What would you do if a package has no sane default configuration? (There is *no* default configuration that works on most systems!) The best thing to do would be to add such a default configuration. [... ARGS ...] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#484009: ftp.debian.org: Core gnome metapackages removed from Lenny breaks gnome desktop
reassign 484009 release.debian.org thanks On 11403 March 1977, Daniel R. wrote: Package: ftp.debian.org Wrong location, we have nothing to do with (what is in) testing. Reassigning. This weekend (1-June-2008) several important gnome metapackages have been removed from Debian Lenny repositories: gnome-core gnome-desktop-environment gnome-cups-manager update-manager update-notifier libgnomecupsui1.0-1c2a Now, gnome desktop does not appear in Aptitude's tasks. I guess this will break new Lenny installation tried from the above date (at least for users who want to install gnome). I think special effort should be applied to solve this situation as soon as possible. -- bye, Joerg liw I'm kinky and perverse, but my illness is laziness pgp9L06EFt4cC.pgp Description: PGP signature
Bug#484129: release.debian.org: packages in tasks should be fixed in priority and removed in last resort after discussion
On 11404 March 1977, Mike Bird wrote: Artificially lowering the RC count in Testing is not always preferential to keeping Testing in a state amenable to testing. You say yourself that it's not artificially as RC bugs in new packages don't get that easily in testing anymore... Removing long-standing packages and stigmatizing them as new in order to keep the RC count down is artificial because such packages are not new. It should only be done very late in the release process if the packages are too late to be fixed for the next release. You may regard the process as some kind of perverse incentive to DDs but the direct consequences of Testing missing long-standing packages is to make Testing unfriendly to newbies, annoying for experienced users, hence less valuable for testing Debian, hence less valuable for improving Debian. Feel free to work on an alternative algorithm to manage testing in a different way, fixing what you currently dont like. I am sure that, if you get the work done, the release team will take a look at it. Of course that involves actually doing the work, Im sorry for suggesting that. -- bye, Joerg 2.5 million B.C.: OOG the Open Source Caveman develops the axe and releases it under the GPL. The axe quickly gains popularity as a means of crushing moderators heads. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Release Transitions
Hi as discussed in [1] the transition feature is now available and usable. Basically it is centered around a Yaml file in which you define the transitions. First: This whole thing is *NOT* meant to set policy on any upload other than needed for a release transition! No matter how much a possible upload of a package might be hated. Misuse it and we might accidently forget how this works in our code. :) Now, the actual feature. There is a new command, dak transitions. This has multiple ways to get run: Called without a parameter you will see an overview of the currently defined transitions, similar to: --8schnipp-8--- Currently defined transitions: Looking at transition: apt_update Source: apt New Version: 0.7.12 Responsible: Andreas Barth Description: Apt needs to transition to testing to get foo and bar done Blocked Packages (total: 7): apt, synaptic, cron-apt, debtags, feta, apticron, aptitude Transition source apt not in testing, transition still ongoing. - --8schnapp-8--- It shows what source and version needs to transition and what packages will get rejected[2] together with the description and also who is responsible for it. In case the transition is over it will also say that, but it *won't* modify the file. That leads to the first option, -c|--check. It will do the same output as above, but additionally also remove old transitions. Use that to semi-automagically cleanup the file, as every defined transition will get checked for every upload and so you shouldn't have old stuff in there. If you would want to keep a record of old transitions - copy them elsewhere or something, dont keep them in this file please. Now, the most important commandline option for you: -e|--edit. This will spawn an editor with a temporary file showing the currently defined transitions. The example from above would look like[3]: --8schnipp-8--- apt_update: reason: Apt needs to transition to testing to get foo and bar done source: apt new: 0.7.12 packages: - apt - synaptic - cron-apt - debtags - feta - apticron - aptitude rm: Andreas Barth --8schnapp-8--- The order of the fields does not matter (and might actually get sorted randomly when the file gets updated) and the short names (apt_update here) *have* to be *unique*. One important thing: Use a *consistent* indentation style, best is to keep 2 spaces for the indent. Strings *should* be in , but normally work without them, with one notable exception: Version-numbers with an epoch REALLY DO WANT to be in . Trust me. They do. For reference, the layout is # short_tag:A short tag for the transition, like apt_update # reason: One-line reason what is intended with it # source: Source package that needs to transition # new:New version of the target package # rm: Name of the Release Team member responsible for this transition # packages: Array of package names that are affected by this transition # - package1 # - package2 # ... Yes, the packages array has to include the transition source again. It is not automagically included! This is done on purpose, so you can easily allow any of the packages to upload again by simply removing them From this array until the upload you want is there.[4] After you are done with the edit you will be presented with an overview of the defined transitions. Look if the programs interpretation of what you just wrote is what you want to have. Look again. If it is - let it save it, if not edit again or drop the changes. In case you made a mistake with the Yaml format, missed a key or added one too much you should get a nice error message about it, with the only option to Edit again or Drop the changes. Effect of such a defined transition: If someone does a *sourceful* upload it will get rejected with a message similar to --8schnipp-8--- feta: part of the apt_update transition Your package is part of a testing transition designed to get apt migrated (it is currently 0.6.9, we need version 0.7.12). This transition is managed by the Release Team, and Andreas Barth is the Release-Team member responsible for it. Please mail debian-release@lists.debian.org or contact Andreas Barth directly if you need further assistance. You might want to upload to experimental until this transition is done. --8schnapp-8--- Any questions? If not - have fun. One more part, for those who produce nice little scripts for devscripts, manage the pts or our other QA pages: If you want to display transitions (or give notice before an upload), the sourcefile used for this is always available at
Re: britney
On 11359 March 1977, Andreas Barth wrote: So, what I would propose would be to either allow the release user to run dak control-suite -s testing, and/or to allow some people (including the release user) to change bin_associations and src_associations as far as it concerns testing. With that, running britney could be migrated to the release user. I wouldn't want a non-ftpteam user to run such commands if there are other ways, and your description shows that there are. You said it produces a list in heidi/control-suite-format, so well. We can think about something similar to the transitions. Have a script that parses the file, checks $wholelotsofstuff, then commits it. Then have it trigger something on ftpmaster side (ssh trigger, regular cronjob looking for a defined file, whatever) that imports it (if its valid). (ssh trigger would also enable release.d.o to be on a different host than ftpmaster, if that would ever be needed). -- bye, Joerg Naturally; worms that don't know what they are doing end up as fish bait, instead of getting invited into weird math experiments. -- Lars Wirzenius pgpj6Fn8hJOOv.pgp Description: PGP signature
Re: Idea for dealing with transitions
On 11261 March 1977, Margarita Manterola wrote: Implement a new file, that works similarly to the hints file, but that causes uploads to unstable for selected packages to be rejected. Thus, if a maintainer uploads, it won't get through so that it won't get in the way of the transition. Ganneff volunteered to prepare the patch after the format of the file is decided. The implementation of this is pretty simple, especially when we dont take Neils idea of a delayed queue and just do the reject. :) Diverting it to experimental is also not very nice (IMO), as you a.) have to check if experimental doesnt already have a later version b.) need to cleanup experimental later c.) need to upload again anyway to go into unstable when the transition is done d.) get files into experimental where the changelog (and .changes) talks about Distribution: unstable, something that might surprise users, experimental autobuilders and possibly others A REJECT is simple, directly tells the maintainer whats going on, and also leaves the option for them to do a seperate upload to experimental, in case they want it. Now, for the file - the format would be YAML, as its easy to parse from about every language and still easy to edit with $EDITOR. I propose the following: --8schnipp-8--- apt_update: reason: Apt wants to go to testing source: apt vto: 0.7.9 vtn: 0.7.10 packages: - apt - synaptic - cron-apt - debtags - feta - apticron foo_broken: reason: Something else source: foo vto: 1.2-3 vtn: 1.3-1 packages: - foo - baz - bar --8schnapp-8--- This would mean we have two transitions, one for apt, one for foo. apt_update/foo_broken would be an informational tag for the reject message, together with the reason. All packages named here are source packages, of course. vto means version testing old, vtn version testing new. And packages is simply a list of all packages affected by this transitions that should get rejected, *including* the transition target itself. Listing them all leaves the release team with a simple way to allow uploads of packages involved in a transition, in case its needed, by simple not listing such exception. vtn is there so that the file can be cleaned up automagically - as soon as the version in testing is the same or later as vtn no reject is done anymore. We *could* make it more complicated by adding versions to the package entries in packages:, but I currently don't see that that is needed. If it will ever be we can adapt it in the future. And now, as Im not a release expert - please comment what I forgot to add to that example. :) -- bye Joerg ribnitz Ganneff: NM-queue ist das schnellste zu uploadrechten für ein paket, oder? youam ach aqua^Wribnitz pgpz5I9ikqoBp.pgp Description: PGP signature
Re: [EMAIL PROTECTED]: Re: flyspray FSA:2]
On 11255 March 1977, Pierre Habouzit wrote: On Sat, Jan 05, 2008 at 11:30:41AM +, Luk Claes wrote: Please open bugs against ftp.debian.org requesting its removal from stable and oldstable, TIA. #459296 With the current title you request removal from unstable, please fix. -- bye Joerg exa look i can't afford to to any more work without becoming a DD pgpCTQH2LH7KR.pgp Description: PGP signature
Re: apt transition - please bump urgency of libept
On 11236 March 1977, Steve Langasek wrote: On Mon, Dec 17, 2007 at 09:48:48AM +0100, Enrico Zini wrote: So, as maintainer of C++ packages that use apt and are involved in apt transitions every so often, I would like to have some sort of handy way to know you're free to upload to sid or hang on a sec, or upload to experimental. A way that possibly doesn't require following both deity@ and debian-release@ regularly. - run the commands grep-excuses libept; grep-excuses libept/i386 - look for any Depends: lines - look at the testing transition page for those dependencies on bjorn.haxx.se: http://bjorn.haxx.se/debian/testing.pl?package=apt- if it looks hairy, ask That's going to catch 99% of the problematic cases, and is far more scalable than to have the release team try to notify all affected maintainers whenever there's an ongoing transition. (Perhaps not more scalable than having dput warn, but the above is something any maintainer can do for themselves today.) I guess there is no scriptable way to do that? Ie. if it would be scriptable without too much guesses here and there I would love to add something into process-new that shows me if there is anything related to transitions with the package I just look at. Which would show such things as the cwidgets upload, or other uploads where the library package name changes due to soname, but where it would be better to wait a day or two more before it gets accepted to let the old version transition first, together with whatever depends on it... -- bye Joerg pasc man pasc the AMD64 camp is not helped by the list of people supporting it pasc when nerode is on your side, you know you're doing something wrong -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ttf-junicode
On 10880 March 1977, Gürkan Sengün wrote: Do you REALLY think this is a valid candidate to be unblock? I don't think so. Yes I REALLY REALLY think so. WOULD I ELSE ASK FOR IT? oh well do whatever you want. So what RC bugs does it fix? None? Why are you asking? You know, its freeze time. -- bye Joerg elmo I'm James Troup, long term source of all evil in Debian. you may know me from such debian-devel-announce gems as Serious Problems With pgp4zdB8Zxc6O.pgp Description: PGP signature
Re: Who declares optional packages extra?
On 10794 March 1977, Richard B. Kreckel wrote: libginac1.3c2a-dbg_1.3.5-1_i386.deb: package says priority is optional, override says extra. Last time I uploaded that package (then libginac1.3c2a-dbg_1.3.4-1_i386.deb) it was optional. (I've just checked the old upload file.) Did it really spontaneously become extra? If so, why? Also, I'm slightly worried about the 6 non-depending packages made uninstallable on arm, according to http://bjorn.haxx.se/debian/testing.pl?package=ginac. Is this just bogus or what? Its the -dbg thats extra. A debug package cant be optional, its extra, as a normal user sure doesnt want it, its for some special use. -- bye Joerg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: petsc_2.3.0-1_i386.changes REJECTED
On 10473 March 1977, Adam C. Powell, IV wrote: * On Sunday 11/6, Joerg Jaspert marked my upload rejected for now, citing number of packages and naming convention as a reason. * I gave the reason for my naming convention and number of packages. * He hasn't replied in a week. Oh wow. A week. How bad of me. What gives? Is this sufficient justification for rejecting a lintian-clean package? Yes. Has my clarification been heard, Yes. libpetsc2.3.0 - Shared libraries for version 2.3.0 of PETSc libpetsc2.3.0-dbg - Static debugging libraries for PETSc libpetsc2.3.0-dev - Static libraries, shared links, header files for PETSc petsc-dbg - Empty package depending on latest PETSc debugging package petsc-dev - Empty package depending on latest PETSc development package petsc2.3.0-doc - Documentation and examples for PETSc The empty packages are useless here. They dont bring you or the users anything except confusion. Why not simply drop the petsc-[dbg|dev] dummy packages and rename the libpetsc2.3.0-[dbg|dev] to libpetsc-[dbg|dev]? That should get you exactly the same effect as you have right now, but kills the ugly dummy packages. I would also drop the version number from the -doc package, as you dont keep the old one around, so no version needed. If you have good reasons to keep it this way, and I just dont see them - please reply to this mail stating them. Thats why i suggest to remove them and to drop the version number out of the [dbg|dev] package. The actual lib can keep the version, I personally would prefer to drop the minor part of it, except upstream is that braindead that even minor versions are incompatible. As you may be able to tell, upstream breaks compatibility with every point release of PETSc. Wäh, looks like they are. Because a number of developers work with specific packages which use PETSc, from Illuminator (debianized) to Dolfin and libmesh (not yet), each of which builds against a specific version of PETSc (and they upgrade somewhat asynchronously), it's important to be able to install multiple versions of the development packages side by side. That's why I use the alternatives system to switch between them. I just skip the alternatives system and -dev package in one sentence (It's a sick and ugly idea), but except that your solution doesnt work as I understand what you wrote. Right now your petsc builds: libpetsc2.2.0, libpetsc2.2.0-dbg, libpetsc2.2.0-dev, petsc-dbg, petsc-dev, petsc2.2.0-doc. Now you upload with the packages listed at the top of this mail. That makes the ones from 2.2.0 right away to be Not built from source and one of us ftpmasters removes them within a few days. Which makes them disappear from unstable, and a short time later also from testing, whenever britney feels its good to do. So you can't count on multiple versions to be available until you upload multiple of them in different source packages (DON'T). IOW: No reason for the layout as it's right now. --8schnipp-8--- As an example take linux-ntfs, which was uploaded yesterday changing its lib-package: * linux-ntfs_1.12.1-1 builds: ntfsprogs, libntfs-gnomevfs, libntfs-dev, ntfstools-udeb, ntfstools, libntfs8 but no longer builds: o 1.11.2-3: libntfs7 --8schnapp-8--- This is what you see in http://ftp-master.debian.org/removals.txt marked as [rene]. On 10473 March 1977, Luk Claes wrote: I don't see anything there pertaining to my package. Perhaps I am overlooking something, can you please be more specific? Look at package split... You split the package too much... Hmm, there are numerous such meta packages in Debian, are they now against policy or otherwise discouraged? How is a user to automatically update to the latest version? There are only a very few of this *empty* meta packages... though there are a lot of unversioned development packages... Apparantly you didn't understand Joerg's proposal? He proposed to remove the empty packages and to drop the version in the *name* of the development, debug (and documentation) package. This will make sure that a user automatically updates to the latest version... And thats what I asked for, yes. Drop the version from -dev|-dbg|-doc, use the shlib system for the rest (which makes packages built against it depending on the right version) and have fun. -- bye Joerg liw er, *not* what I meant, is what I meant pgpab3RMJ1QIs.pgp Description: PGP signature
Re: Why discover1-data is so old in Debian Sarge, while in unstable is up to date ?
On 10311 March 1977, Petter Reinholdtsen wrote: Cc to debian-release, to pledge that the release managers include version 1.2005.04.23 of discover1-data in Sarge. Sarge is closed, so you are out of luck. -- Joshua Kwan [EMAIL PROTECTED] Sat, 23 Apr 2005 20:36:07 -0700 That old, and now asking? Tss. -- bye Joerg A.D. 1492: Christopher Columbus arrives in what he believes to be India, but which RMS informs him is actually GNU/India. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Release Notes - non-us being phased out - please comment
On 10297 March 1977, Frans Pop wrote: If it is certain that non-US is empty on release date, lets make the text a bit stronger: sect1 id=non-usheadingnon-US obsoleted/heading pFor the releasename; release, all packages that were formerly in the non-US part of the archive have been moved into the regular archive. If you have any lines referring to non-us in your file/etc/apt/sources.list/file, you should remove them as there is a chance that non-us.debian.org will be shut down in the future./p /sect1 Hrm. s/there is a chance// *IMO*. It is 100% sure it will be shut down, either for r0 directly, or with empty package files for a time (until r1 or etch). -- bye Joerg vorlon I realize the risk of portability problems is lower than with certain other desktop environments beginning with K that will go unnamed pgpBJHdFXVsNI.pgp Description: PGP signature
Package dak
Hi Ive just uploaded 1.0-8 of package dak. It fixes a bunch of bugs, including 3 translations. It also changes uma a bit to use gpg --with-colon, to not break with newer gnupg thats on its way to sarge. The last change is a modification to jennifer, to remove a today unused function (which will come in future, but no need to ship it right now). That one would actually break for people using dpkg-sig or similar things. :) Changelog entries attached, please consider it for sarge, debdiff is, except added sudo and newer libc, empty for me, so shouldnt do any harm. Thanks. Note: This version works on dak.ganneff.de (i386) and amd64.debian.net, so it should work, at least the second archive has enough package flow for a test. :) dak (1.0-8) unstable; urgency=low * Bug fix: dak: uma does not work with gnupg 1.4.0 that is in unstable (Closes: #299937). * Bug fix: dak: A small typo, thanks to Frederic LEHOBEY (Closes: #299626). * Bug fix: dak: add a recommendation for sudo, thanks to Frederic LEHOBEY (Closes: #299938). * Bug fix: dak: [INTL:ja] Initial Japanese debconf translation, thanks to Kenshi Muto (Closes: #302482). * dak: French debconf templates translation * Bug fix: [l10n] Czech translation for dak, thanks to Martin ¦ín (Closes: #308041). * Step back to a jennifer which actually runs on Debian hosts too, thus removing removing a small function to check debs a bit more. -- Joerg Jaspert [EMAIL PROTECTED] Sat, 21 May 2005 16:44:40 +0200 -- bye Joerg Joey Joey, provide a patch then. pgpC1gpdkKNOX.pgp Description: PGP signature
muddleftpd for sarge
Hi Can you hint muddleftpd, 1.3.13.1-4 in sarge? (Well, after its ready, Im waiting for the m68k build, all others worked). It is running in this version on my own box(i386) and on amd64.debian.net(amd64), to test it under some load. Changelog: muddleftpd (1.3.13.1-4) unstable; urgency=low * Change libmysqlclient-dev to libmysqlclient12-dev * muddleftpd: implicitly declared function returns a pointer that is used (Closes: #226529) -- Joerg Jaspert [EMAIL PROTECTED] Mon, 9 May 2005 21:54:24 +0200 muddleftpd (1.3.13.1-3) unstable; urgency=low * Bug fix: muddleftpd: FTBFS on amd64: -fPIC missing, thanks to Andreas Jochens (Closes: #253618). -- Joerg Jaspert [EMAIL PROTECTED] Tue, 3 May 2005 22:17:49 +0200 -- bye Joerg Gna, schon wieder Seti [...] Dabei ist es schon schwierig genug, auf *diesem* Planeten intelligentes Leben zu finden. [Charly Kuehnast in dasr] pgpxSPXt5erhT.pgp Description: PGP signature
Re: More hinting (simple removal) suggestions.
Nathanael Nerode [EMAIL PROTECTED] writes: == remove kernel-image-3.4.18-i386bf Boot-floppies image, useless in sarge 3.4-2.4? :) -- bye Joerg elmo [..] trying to avoid extra dependencies on gnumeric is like trying to plug one hole in the titantic with a bit of tissue paper pgpkmY4cLZ3hF.pgp Description: PGP signature
