Re: mips64el in testing
* Niels Thykier (ni...@thykier.net) [160605 22:45]: > In other words, there is a DSA buildd? > > I notice we have the following list of mipsel/mips64el buildds: > > * mips64el: eberlin, mipsel-aql-01, mipsel-aql-02, mipsel-manda-01, >mipsel-manda-02 >- I presume none of them are DSA given mips64el currently has a note > of not having a DSA buildd. All of them are the normal DSAed machines, also used for mipsel. The note is probably quite old. > * mipsel: mayer, eysler, rem, phrixos (non-DSA), helle (non-DSA) > > Are these lists up to date? Not at all. There is a common set of DSAed-buildds for both, and that is the list as of above for mips64el plus mipsel-aql-03 (for both arches). For mips64el, there are additional to that list thor, clash and lm6100 active. Andi
Re: Release Team Sprint Results
* Steve Langasek (vor...@debian.org) [141110 23:06]: On Mon, Nov 10, 2014 at 09:33:07PM +, Adam D. Barratt wrote: [re-adding -devel@] On Mon, 2014-11-10 at 21:20 +, Adam D. Barratt wrote: On Mon, 2014-11-10 at 13:08 -0800, Steve Langasek wrote: Hi Jonathan, On Sun, Nov 09, 2014 at 11:52:31AM +, Jonathan Wiltshire wrote: [...] - i486 support dropped I'm rather certain that i486 hasn't been supported in Debian for at least the past 4 years (and probably much longer, my memory is fuzzy; but as a data point, https://lists.debian.org/debian-devel/2011/11/msg00687.html). Why is this on the release team's radar as something that needs to be documented in the release notes for jessie? I believe this was intended as a reference to this change in the latest Linux kernel upload: * [i386] Rename 486 flavour to 586, as it has not worked on 486 processors since we enabled CC_STACKPROTECTOR (Closes: #766105) Ok, well, given that Debian didn't work on 486 for years before that, I think this is a non-event that doesn't need to be release-noted. Well, I think the reference was mostly what we might need to document. If nobody noticed that, then well, you are right, and perhaps we don't need to document that. (Technically it was still input to the release notes, which however was then ignored.) Andi -- 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/20141110221935.gd...@mails.so.argh.org
Re: Plan B for kfreebsd
* Steven Chamberlain (ste...@pyro.eu.org) [141110 23:10]: Petr Salinger wrote: Jonathan Wiltshire wrote: [...] though we do hope that the porters will be able to make a simultaneous unofficial release. It is unclear, what we have to duplicate. Do we stay in testing ? I'd like to know this as soon as possible as it affects our planning. Thanks. If we don't stay in testing, we'd at least want to archive off the last-built kfreebsd packages before they are deleted... That sounds sensible. As you want to do an unofficial release, I think we should coordinate so that this doesn't create unnecessary additional efforts. I don't know how the others feel about, when should kbsd be removed from testing? That would give some impression how fast this should be done. But certainly for unofficial releases, a supplemental repository would be great for us. We can bypass usual freeze policy to fix bugs we think are important, which may not have got an unblock. I'd replace that with that allows to have an freeze policy centered around kbsd. Andi -- 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/20141110222309.ge...@mails.so.argh.org
Bug#767743: [jcris...@debian.org: Re: Bug#767743: unblock: blitz++/0.10-3]
* Andreas Tille (andr...@fam-tille.de) [141102 21:20]: could you please follow what was suggested here https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767291#15 to ensure building blitz++ at mips? Blacklisted it on corelli/lucatelli. Andi -- 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/20141102202609.ga21...@mails.so.argh.org
Re: Bug#763148: Prevent migration to jessie
* Andreas Cadhalpun (andreas.cadhal...@googlemail.com) [141005 22:36]: That's because the last message from a release team member in this bug said [1]: 'However (and please note that I'm not a member of the security team and just speak for myself here as always when not otherwise marked) if As I said, I was just speaking for myself. That I might be at other times speaking as a member of the release team doesn't make it an opinion of the release team. For the release team opinion on this topic seen Cyrils mails. Also, the re-evaluation happened. It however didn't had the outcome you wanted (basically because the web browser needs so many security updates which only could be done by backporting all of it that the embedded copy doesn't make any difference - this is an exceptional thing which does happen but not very often. I can understand it, and of course it's the call of the security team how to ensure that Debian has security updates. I hadn't know that at the time I though about the possibility, otherwise I would have already achived at that moment at the conclusion). Conclusion: Though I'm usually an optimistic person how to get things achived, I don't see any way left how at this late time it's possible to ship with ffmpeg in jessie. I'm sorry but we have to face the facts. Independend if we like them or not (and I can fully understand that you don't like them, but it's no good pretending facts are different than they are). Sorry. Andi -- 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/20141005205445.gh3...@mails.so.argh.org
Bug#754988: Bug#763360: libjpeg-turbo is hijacking binaries from other source packages
Hi, looking a bit from the outside it looks to me as different questions discussed in parallel. The one question is how we came here. * Bill Allombert (ballo...@debian.org) [141003 12:15]: On Fri, Oct 03, 2014 at 01:41:02AM +0200, Emilio Pozuelo Monfort wrote: On 30/09/14 11:32, Bill Allombert wrote: On Mon, Sep 29, 2014 at 08:55:16PM +0200, Ondřej Surý wrote: Bill, I am very sorry that I have not Cced everything related to the libjpeg-transition to you. I have honestly believed that you and everyone else involved was following the transition plan as mentioned in #717076#225. As for the takover of the libjpeg62* packages it was discussed in the transition plan bug #754988. Bad faith ? No I do not think so. [...] ... and neither of you bothered to ask me. Ondřej already said he thought while uploading that you were involved, and notices now that you weren't and is sorry that he didn't CC you to all mails. I can understand that you are angry about the uploaded packages. I'm not going to argue about what the tech ctte resolution was, and what could or should be interpreted into it or not, because that is not helpful. Uploading the package as happend and without proper discussion before was a mistake, and Ondřej already accepted his responsibility for it. So while an mistake is never good, mistakes can happen, and I personally always consider it a good thing if people stand to their actions and apologize if appropriate. I hope we could leave it as that for the upload - nobody has a time machine to undo the upload, but we could try to make it better now and discuss where we should go. The other question is: Where from here? What should be the appropriate state of packages within Debian for the release? It's a pity that we lost time, but we still could adjust things so they are best for Debian, based on the (spirit of the) initial decision of the tech ctte (and in case the relevant people cannot agree, of course another decision of the tech ctte would be possible, but I really hope we could avoid that and conclude on something acceptable for all). (And of course, any question not already decided by the tech ctte could be discussed and hopefully also answered here - which source package will build libjpeg62* is part of that.) Andi -- 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/20141003130309.go20...@mails.so.argh.org
Re: Bug#763148: Prevent migration to jessie
* Andreas Cadhalpun (andreas.cadhal...@googlemail.com) [140928 11:27]: On 28.09.2014 10:24, Moritz Muehlenhoff wrote: Package: ffmpeg Severity: serious As written before we can have only libav or ffmpeg in jessie. I'm filing this blocker bug to prevent testing migration until this is sorted out. As I have explained [1], I see no security problem with having FFmpeg and Libav in Jessie, in particular because this is already the case for Wheezy, as chromium embeds a copy of FFmpeg. First of all, I think it is very good news that we now have FFmpeg available in Debian. Thank you for your work on it, it's appreciated. However, the open question is (especially with the upcoming release), do we want to have it in jessie? (That we probably want FFmpeg in testing in the long run is something else, but the current discussion is especially about jessie.) I also think it's good that you actively raised this discussion, even if it is perhaps not working as you would have like it. Please continue this good style. Another remark, we are already quite late in the cycle. At this point it is too late to have greater changes to jessie. So even if jessie is not officially frozen, larger changes are not possible anymore (without disturbing the time plan). So would you please explain why you see a problem? I hope we end this discussion on an agreement about the jessie plans. However, to avoid misunderstandings at a later moment, I need to point out that the final decision of what is part of jessie is taken by the release team (or ultimatly the release managers). All of RC-bugs, testing migration scripts etc are very valuable helpers because it wouldn't be possible to manage it otherwise, but in the end they are helpers. The release policy does say Packages must be security-supportable. I would be surprised if a statement from the security team (assuming that Moritz raised that bug report with his security team-hat on and not privately) that they would like to have only one of libav and ffmpeg in jessie would be overruled by the release team. Now seeing the statements from the libav maintainers (which of course, as this is an overlaping jurisdiction, could be escalated to the tech ctte), that we already have transition freeze and the time planings for jessie, makes it quite unlikely (or rather: impossible) to switch from libav to FFmpeg in time for jessie. (Of course, for jessie+1 there is enough time for the transition. And for jessie+1 we will have enough experience with FFmpeg in Debian to perhaps see things in a different light.) So from my experience I assume the final answer would look similar to It's too late for jessie, sorry. Which might be a pity but, well, that's how it is. Andi -- 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/20140928104705.gn20...@mails.so.argh.org
Re: Bug#763148: Prevent migration to jessie
* Andreas Cadhalpun (andreas.cadhal...@googlemail.com) [140928 14:36]: On 28.09.2014 12:47, Andreas Barth wrote: The release policy does say Packages must be security-supportable. I would be surprised if a statement from the security team (assuming that Moritz raised that bug report with his security team-hat on and not privately) that they would like to have only one of libav and ffmpeg in jessie would be overruled by the release team. Nonetheless both are in wheezy and will be in jessie, unless chromium gets removed from testing. There is a distinction between an old and a new package. However (and please note that I'm not a member of the security team and just speak for myself here as always when not otherwise marked) if it would be possible to replace the internal code copy in chromium by a reference to ffmpeg (but it's not possible with libav), that will probably lead to a re-evalutation. (That doesn't necessarily mean sucess guranteed, but it looks to me as it will not make things worse.) Perhaps you always intended that, but at least I didn't understand it that way yet. I absolutely cannot understand why the security team would prefer to have an embedded code copy instead of a properly packaged library. I don't think they do that. However, I can understand why one embedded code copy is better than one embedded code copy plus a library in addition to it. Andi -- 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/20140928124440.gt3...@mails.so.argh.org
Bug#763058: nmu: doxygen_1.8.7-3
* Sylvestre Ledru (sylves...@debian.org) [140928 14:15]: On 27/09/2014 18:54, Andreas Barth wrote: See e.g. [3]https://www.debian.org/doc/debian-policy/ch-sharedlibs.html | Every time the shared library ABI changes in a way that may break | binaries linked against older versions of the shared library, the | SONAME of the library and the corresponding name for the binary | package containing the runtime shared library should change. Can you please do that so that we could schedule the binNMUs after this is done? The package name is libclang1-3.5 and the soname is libclang-3.5.so.1 Initially, I uploaded with libclang-3.5.so as soname since the ABI remains the same over a version of libclang but dpkg-shlibdeps complained about the missing .1 even if it seems valid in the policy [4]https://www.debian.org/doc/debian-policy/ch-sharedlibs.html The soname may instead be of the form name-major-version.so, such as libdb-5.1.so, in which case the name would be libdb and the version would be 5.1. What would you want in term of package naming ? I don't know what would work best here libclang-3.5.1 is kind of a bad name. Basically there is no really nice solution there because the packagename libclang1-3.5 was already used for the soname libclang.so.1. The two major options are: 1. Change back the soname (which is of course wrong otherwise) 2. Change the package name to something like libclang1-3.5a. I also have an idea for an ugly hack but I need to think a bit more about it. From package POV it might be the niciest, but I'm not sure if it works (which is a precondition for everything). I'll update this mail tonight. Andi -- 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/20140928123259.gs3...@mails.so.argh.org
Bug#763058: nmu: doxygen_1.8.7-3
* Andreas Barth (a...@ayous.org) [140928 14:32]: I also have an idea for an ugly hack but I need to think a bit more about it. From package POV it might be the niciest, but I'm not sure if it works (which is a precondition for everything). I'll update this mail tonight. What works in practice, and seems to be ok-ish from a theoretical POV is to create a symlink from libclang-3.5.so.1 to /usr/lib/`dpkg-architecture -qDEB_BUILD_MULTIARCH`/libclang.so.1 during build time (as part of the deb file). This allows doxygen to work again. (Also, all previous packages were broken according to policy because that symlink was created only at configure time by ldconfig. However the symlink needs to be part of the package so that the lib is available before configure. Just a notice, there doesn't seem to be a fallout from that, but should be kept in mind for future packages.) Andi -- 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/20140928192507.ga...@mails.so.argh.org
Bug#763058: nmu: doxygen_1.8.7-3
* Sylvestre Ledru (sylves...@debian.org) [140927 16:51]: nmu doxygen_1.8.7-3 . ALL . -m binMNU because of the libclang change of soname I updated the soname as part of the coordination to switch to llvm 3.5. https://release.debian.org/transitions/html/llvm-defaults-3.html Did you also switch the binary package name? For any soname change you need to have the package name to follow. See e.g. https://www.debian.org/doc/debian-policy/ch-sharedlibs.html | Every time the shared library ABI changes in a way that may break | binaries linked against older versions of the shared library, the | SONAME of the library and the corresponding name for the binary | package containing the runtime shared library should change. Can you please do that so that we could schedule the binNMUs after this is done? Andi -- 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/20140927165428.ga24...@mails.so.argh.org
Re: FFmpeg in Jessie
* Andreas Cadhalpun (andreas.cadhal...@googlemail.com) [140926 23:24]: On 26.09.2014 22:55, Moritz Muehlenhoff wrote: On Fri, Sep 26, 2014 at 10:56:08PM +0200, Cyril Brulebois wrote: [ Not speaking for any team. ] Andreas Cadhalpun andreas.cadhal...@googlemail.com (2014-09-26): FFmpeg was recently accepted into the Debian archive by the FTP team. We plan to upload it to unstable soon, so that it can be part of Jessie. If you have any concerns about this, now would be a good time to start discussing them in order to find a solution for Jessie. I think those concerns have been raised already, with the bottom line roughly being: it's either libav or ffmpeg, not both? Indeed. And why? In my opinion upstreams' security support for FFmpeg is better than that of most other packages in Debian. Security updates are a simple matter of packaging a new point release from upstream. The work for the security team would be limited to reviewing the upstream changes and sending out a DSA. Additionally the security of FFmpeg has improved quite a bit so that nowadays there a far fewer CVEs for it than e.g. for MySQL. That sounds like we should drop libav and release with ffmpeg. Is this also the opinion of the libav maintainers? Or is there a strong reason why this is not possible? Andi -- 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/20140926212825.gm20...@mails.so.argh.org
Bug#742329: use softer colours for architecture qualification page
* Thijs Kinkhorst (th...@debian.org) [140322 16:51]: On Sat, March 22, 2014 16:28, Julien Cristau wrote: looks like that if col==red is now broken? Indeed, see fixed patch attached. print 'td style=background-color:%s%s/td' % (col,contents) I'm asking myself if we shouldn't just rather translate colors here, i.e. (with an appropriate colormap) print 'td style=background-color:%s%s/td' % (colormap.get(col,col),contents) Andi -- 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/20140322155321.gc16...@mails.so.argh.org
Re: Bits from the Release Team: Architecture health check
* Robert Millan (r...@debian.org) [140214 00:11]: On 12/02/2014 20:06, Niels Thykier wrote: As I see it, there are two concrete problems with the (number of) supported packages. First, the number of packages actually built on kFreeBSD is just shy of 90%, whereas most other release architectures are at 96%[1]. Here kFreeBSD has increased in the past quarter from ~89.5% to almost, but not quite 90%. The release architecture criteria [1] says the target is 98% but hardware-specific packages are excluded. Does this apply to kernel ports by simply replacing hardware-specific with kernel-specific? [1] https://release.debian.org/jessie/arch_policy.html At the time where we wrote that criteria there wasn't a difference - basically packages which don't make a sense don't need to be ported was the main thought. Andi -- 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/20140214204245.gh16...@mails.so.argh.org
Bug#733411: migrate only packages built on at least two architectures
Package: release.debian.org User: debian-release@lists.debian.org Usertags: britney Hi, as just discussed on IRC, it would be nice if britney would only migrate packages to testing which are available on at least two architectures (so that we know it had been autobuilt at least once). (For the few exceptions which are only relevant for a single architecture, there would need to be a hint like singlearch package, and also an initial cleanup before activating it sounds a good idea.) Reasoning behind is that as of now britney doesn't get aware if brand new packages FTBFS everywhere e.g. because of broken build dependencies, but would happly migrate such a package to testing (which then couldn't been built in a clean chroot), because the package is current on all architectures it was ever built on. Forcing human work to file RC bugs fast enough doesn't seem reliable, especially if we could automatically detect it. Thanks, Andi -- 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/20131228193231.gw12...@mails.so.argh.org
Bug#733411: migrate only packages built on at least two architectures
* Cyril Brulebois (k...@debian.org) [131228 21:38]: Andreas Barth a...@ayous.org (2013-12-28): as just discussed on IRC, it would be nice if britney would only migrate packages to testing which are available on at least two architectures (so that we know it had been autobuilt at least once). No, we wouldn't know that. _multi.changes, etc. Well, we at least would have way better changes. Im not speaking about cheating maintainers, but about maintainers making simple errors. This isn't the 100%-approach, but the 95% we can get easily. Anyways, not my decision. Andi -- 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/20131228213000.gx12...@mails.so.argh.org
Re: Bits from the release team (freeze time line)
* Steve McIntyre (st...@einval.com) [131227 03:17]: On Thu, Dec 26, 2013 at 06:08:03PM +0100, Niels Thykier wrote: On a related note, DSA have concerns with the current arm* and mips* hardware. While there have been promises of new hardware to replace some of the current buggy machines, the offers are currently not leading to concrete results. Porters of these architectures should contact DSA and figure out a solution to avoid a situation where an architecture is in jeopardy due to insufficient buildd or porter machines. Ummm, WTH? We've been looking into possible *upgrades* to replace some of the armel and armhf buildds with faster and (ideally) more easily managed machines, but I *seriously* disagree with any suggestion that the current machines are buggy. I can see that with the some of the known-buggy mips* machines, but I don't accept that the arm* machines could/should be classified this way. Sorry, but I *seriously* disagree with this statement. If we apply common standards (and I think we should), then either arm* and mips* have hardware issues or none of them. On all those architectures we speak about build power and the options to refresh hardware, and looking at buildd.d.o it doesn't look like mips* does worse by far than arm, but rather the other way. However, using words like known-buggy mips* machines is just FUD against the mips*-ports, and plainly inacceptable, so please stop doing that. (For reference, there is no mipsel machine which has hardware bugs affecting daily operations. There are two mips machines which are pre-series and are not as stable as I wish, but as builddadm I was more occupied recently with arm* machines not stable then with mips machines not stable. This all doesn't mean I think nothing should be changed, but please do not FUD against mips* (or any other architecture).) Andi -- 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/20131227131907.gg16...@mails.so.argh.org
Re: Roll call for porters of architectures in sid and testing
Hi, I'm an active porter for mipsen (both mips and mipsel) and plan to continue that during the full next cycle (or rather: spend more time on it compared to the recent months). As that, I'm involved in debugging packages, triaging, fixing and forwarding arch-specific issues, keeping contact to linux-mips-community and upstream (and being contacted by them as well), involved about getting new hardware supported and for our autobuilders, maintaining buildds, running and using such hardware for my own purposes etc. Andi -- 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/20130928103321.gw28...@mails.so.argh.org
Re: Proposed addition to RC policy (release upgrades)
* Adam D. Barratt (a...@adam-barratt.org.uk) [130917 20:45]: As I've seen it come up a few times recently, I'm proposing adding some explicit RC requirements relating to upgrades between releases. I don't think there's anything particularly controversial about this, as it's basically documenting long-standing practice. yes, this is the current policy. | +Packages must upgrade cleanly from the version in the previous stable | +release (if any). In order to support partial upgrades, versioned | +dependencies must be used if the version in the previous release is | +not sufficient for the new package version to be functional. Upgrades | +skipping a stable release are not required to be supported. | + | If two packages cannot be installed together, one must list the other | in its Conflicts: field. \== should we also put a statement in about (versioned) conflicts, or does that follow automatically from the normal text below? Andi -- 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/20130917203445.gv28...@mails.so.argh.org
Re: DSA concerns for jessie architectures
* Andreas Barth (a...@ayous.org) [130622 20:06]: Different answers - select the one you like most: 1. We could buy a some loongson 2f machines (or newer), see e.g. http://www.tekmote.nl/epages/61504599.sf/nl_NL/?ObjectPath=/Shops/61504599/Products/CFL-006 plus some memory. These machines have kernels in the archive, and not the hardware bug with choking on too many nop-instructions in a row. 2. We get the kernel team to accept the additional kernel config for 2e (I'm too lazy now to search for the bug report from ages ago, but the only difference needed to build kernels for our 2e-machines is an additional kernel config, no code changes necessary) 3. We have currently two new machines with loongson 3a processors to test. It will take a bit of time to finally get a working kernel on these, but that would also decrease build-times quite much. Currently mipsel is still marked as with DSA-concerns. Is the third option enough for DSA that the concerns are reasonably addressed for the moment (and the comment could be removed), or do we need to push on one of the other options as above? Andi -- 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/20130816141958.ga3...@mails.so.argh.org
Re: DSA concerns for jessie architectures
* Martin Zobel-Helas (zo...@debian.org) [130622 19:27]: [please consider replacing debian-ports@ldo with the appropriate port specific list when replying.] According to lists.d.o the status of debian-ports is: dead list. It at least isn't the list for all porters to read. * mips: existing machines are either not reliable or too slow to keep up; we suspect that they may not be easily replaceable. We're about to get newer machines which are both stable and fast (the two instable machines are pre-alpha versions, and should be replaced; but this is not an architecture-topic but rather an machine-topic). Also, if we buy more mipsel machines we could convert the mipsel swarms to mips ones (and so replace broken machines, see below) - mostly depends on how urgent you think this is. * mipsel: the porter machine and some of the buildd machines have an implementation error for one opcode; missing kernel in the archive Different answers - select the one you like most: 1. We could buy a some loongson 2f machines (or newer), see e.g. http://www.tekmote.nl/epages/61504599.sf/nl_NL/?ObjectPath=/Shops/61504599/Products/CFL-006 plus some memory. These machines have kernels in the archive, and not the hardware bug with choking on too many nop-instructions in a row. 2. We get the kernel team to accept the additional kernel config for 2e (I'm too lazy now to search for the bug report from ages ago, but the only difference needed to build kernels for our 2e-machines is an additional kernel config, no code changes necessary) 3. We have currently two new machines with loongson 3a processors to test. It will take a bit of time to finally get a working kernel on these, but that would also decrease build-times quite much. Andi -- 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/20130622180631.gy28...@mails.so.argh.org
Re: RC-ness of incomplete copyright files
* Christian PERRIER (bubu...@debian.org) [121014 12:44]: Quoting Michael Gilbert (mgilb...@debian.org): Hi, Jakub Wilk has been filing a lot of RC bugs on packages with incomplete copyright files. Some examples: http://bugs.debian.org/690394 http://bugs.debian.org/690371 http://bugs.debian.org/690370 Now, these are mostly easy fixes and of course in the end completeness is useful, but with so many packages embedding so much code from various sources, I think in the end we're going to find most of the archive affected. So, I'm wondering if the release team's opinion concurs with serious severity, or if these can be downgraded to important to avoid further delaying wheezy? Not wearing a release team hat, but it is my feeling that such deep nitpicking is certainly wished in the long termbut also helps very well in delaying the release of wheezy. No offense intended to Jakub's work, far from that. We certainly need people doing such archive-wide reviews of things that are often neglected. Basically setting an bug to RC grade means: It is better to delay the release of Debian (or remove this package) then to ship as it is. If the bug is already present in stable, an minor error in the copyright file shouldn't mean that as we're not making anything worse. If the bug is new, and it is an real issue (like the copyright file saying this code is public domain, but in reality it is GPL3), then it sounds RC grade to me. If it is rather an minor glitch, then indeed it still should be fixed, but it's not serious enough to stop the release, i.e. the severity should be important. (I had always translated serious with we cannot do that, and important with we should be really ashamed. That worked very well.) Andi -- 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/20121014124827.gi26...@mails.so.argh.org
Bug#687369: Updates to wine-1.4.1-2 -- acceptable for wheezy?
* Hilko Bengen (ben...@debian.org) [120927 18:32]: Since some of these fixes are not exactly one-line patches, I'd like to know whether the following attached patches would be acceptable from the release team's point of view before we push them along with a fix for #687062 (RC: missing copyright file). [..] All of the patches seem to be ok for me. Andi -- 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/20120927183417.ga31...@mails.so.argh.org
Re: Please do not unblock gnome-meta just yet
* Julien Cristau (jcris...@debian.org) [120925 18:52]: On Tue, Sep 25, 2012 at 15:51:17 +0100, Ian Jackson wrote: As you may be aware, the TC recently overruled the maintainers of the gnome-core metapackage, deciding that the dependency from gnome-core to network-manager should be weakened from Depends to Recommends. (The full TC decision is reproduced below.) In response to this the maintainers have uploaded a new version of meta-gnome in which the gnome-core package Recommends network-manager-gnome, as required. However, additionally, they have reintroduced a dependency from gnome to network-manager-gnome, as Depends. See the changes info, also below. The Release Team should be aware that our request to unblock the update to meta-gnome implementing the TC decision does not extend to this latter change to meta-gnome. The TC decision didn't say anything about the gnome metapackage AFAICT. The resolution said: | [...] users who have | gnome or gnome-core installed but have removed or never installed | network-manager will have network-manager installed during an upgrade | from squeeze. | The Technical Committee believes that this will cause undesireable | behavior for upgrades from squeeze So I think while not explicitly spelling out that there should be no depends from gnome to n-m, adding one is against the spirit of the resolution. Andi -- 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/20120925171718.ga26...@mails.so.argh.org
Re: problems with mips builds on ball (potential mass give-back)
* Simon McVittie (s...@debian.org) [120715 01:06]: ball.debian.org seems to be rather unhappy. I already stopped the buildd some time ago, and scheduled a hardware maintenance. Thanks for the list of packages, I'll reschedule a build. Andi -- 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/20120715062730.gm2...@mails.so.argh.org
Re: Are FTBS on mipsel release critical? (goobox #679554)
* Helge Kreutzmann (deb...@helgefjell.de) [120701 10:42]: after a broken NMU I uploaded (before the freeze) essential the previous version with just some additional translations. For some strange reasons (the code in question has been built fine several times on all archs, including mipsel) the build now fails on mipsel (cf. #679554 and #679552). Yes, FTBFS on mipsel alone are RC. Andi -- 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/20120701084427.gd2...@mails.so.argh.org
Re: systemd and dovecot
* Nicholas Bamber (nicho...@periapt.co.uk) [120617 08:59]: We really need to get dovecot compiled on the non-linux platforms to progress with the mysql migration. The systemd dependency puzzles me somewhat as systemd is not available on non-linux platforms and dovecot has previously compiled on those platforms. Why is systemd used at all during build time? I don't think it's usually appropriate to depend on daemons installed during package building. If you need something to link again, then it should be part of a -dev-package (which still might or might not be available on !linux, but that's something else). Andi -- 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/20120617083807.gc2...@mails.so.argh.org
Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability
* Ian Jackson (ijack...@chiark.greenend.org.uk) [120611 13:21]: Guillem Jover writes (Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability): As I mentioned in the long ref-counting thread, I strongly disagree this is a correct solution, it just seems like a hack to me. Instead I think we should consider changelog (and copyright as long as it's in machine parseable format) as dpkg metadata (something dpkg misses compared to rpm or other package managers for example) and as such they should go into the .deb control member, which would end up in the dpkg database w/o any kind of file conflict, and very minor packaging effort as for most that would be handled by helpers. I think this is the wrong design. The changelog is primarily used by humans, not software, and burying it in the dpkg database is not helpful. I think the solution with the binNMU changelogs is straightforward and should be implemented. Hm. Though I see the reasoning in general, would you think it hurts to have the binary epoch (and the corresponding binNMU reason) be stored in the metadata instead of the changelog as today? Andi -- 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/20120612185205.gn13...@mails.so.argh.org
Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability
* Guillem Jover (guil...@debian.org) [120612 09:00]: I disagree placing it in the dpkg database is not helpful, for a user or other programs wanting to access that structured package metadata it's obviously easier and better to do something like «dpkg --show-changelog foo» or «dpkg-query --control-path foo changelog», than having to go hunt where in the filesystem the changelog might be I don't see why dpkg --show-changelog foo can't work even if the changelog is stored in the filesystem. Andi -- 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/20120612185352.go13...@mails.so.argh.org
Re: Handling of changelogs and bin-nmus
* Raphael Hertzog (hert...@debian.org) [120612 13:10]: 1/ we modify dpkg to ignore differences on /usr/share/doc/*/changelog.*gz for multi-arch: same packages Doesn't sound too bad to me, at least for short-term (where I'd tend to take the changelog-version of the main architecture on installation time, but that's just a tiny side note). Andi -- 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/20120612185613.gp13...@mails.so.argh.org
Re: Migration path for 'Multi-Arch:allowed' packages
* David Kalnischkies (kalnischk...@gmail.com) [120612 18:03]: You need to upgrade to support MultiArch, but you need MultiArch to upgrade… (beside, how would the detection for such a message look like?) We had discussed to export foreign-arch packages to the arches packages files at debconf. That would mean in this case that the amd64-packages file contains the i386-package wine-bin. That would allow to detect we need multi-arch packages easily (and avoid that people have to add all i386-packages to an amd64-system just to install wine-bin). In order to get that going, we would need to document in the release notes that certain packages either need to be put on hold prior to the upgrade in case they're installed or to upgrade apt, aptitude and dpkg first. Both had been done before. Andi -- 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/20120612203928.gb2...@mails.so.argh.org
Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability
* Guillem Jover (guil...@debian.org) [120610 10:08]: As I mentioned in the long ref-counting thread, I strongly disagree this is a correct solution, it just seems like a hack to me. Instead I think we should consider changelog (and copyright as long as it's in machine parseable format) as dpkg metadata (something dpkg misses compared to rpm or other package managers for example) and as such they should go into the .deb control member, which would end up in the dpkg database w/o any kind of file conflict, and very minor packaging effort as for most that would be handled by helpers. I'm fully happy to see that solved in whatever way. However, getting it sorted out for binNMUs seems like some kind of priority to me. Perhaps we could add the binNMU entry for the moment and fix the rest later? Or whatever would make you more happy. Just I'd like to be able to schedule binNMUs again on ma-packages. Andi -- 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/20120610115223.gy2...@mails.so.argh.org
Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability
* Philipp Kern (pk...@debian.org) [120610 14:06]: On Sun, Jun 10, 2012 at 01:52:24PM +0200, Andreas Barth wrote: Perhaps we could add the binNMU entry for the moment and fix the rest later? Or whatever would make you more happy. Just I'd like to be able to schedule binNMUs again on ma-packages. There is no such block in place. No, just the package won't be co-installable afterwards. Which doesn't make me really happy. Andi -- 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/20120610213624.gz2...@mails.so.argh.org
Re: Handling of changelogs and bin-nmus
* Raphael Hertzog (hert...@debian.org) [120610 20:44]:
On Sun, 10 Jun 2012, Jonathan Nieder wrote:
Raphael Hertzog wrote:
As such, I suggest that we handle binary rebuild differently:
- debian/changelog is left unmodified since it's the source changelog
= it defines the ${source:Version} substvar
- debian/changelog.binary-rebuild (or any other better name) is created
when we want to do a bin-nmu
= it defines the ${binary:Version} and it's not included in
the generated source package
Sounds good to me. Where would the binary changelog entry and binary
version be stored in the resulting binary package?
In the short term, the binary changelog would not be stored in the
package so that /usr/share/doc/pkg/changelog.Debian.gz is the
same across all bin-nmued package.
Later, it would be stored in the metadata as Guillem suggested (within
control.tar.gz and then installed by dpkg somewhere under /var/lib/dpkg/).
For the binary version, nothing would be changed (it's in the Version field
of the control file).
Asking to be sure: For sbuild, that means instead of changing the file
debian/changelog before starting the build, a new file
debian/changelog.binary-rebuild (or however it is named) is created
and from there on all works by itself?
Do we have other tools than dpkg that parse the changelog to find out
the package version? How far are we away from getting that
implemented once we decide we want that?
Andi
--
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/20120610214037.ga2...@mails.so.argh.org
Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability
* Henrique de Moraes Holschuh (h...@debian.org) [120609 02:31]: We'd just have to teach the tool to binNMU all arches when the target package would need it due to multiarch. Release team requests a binNMU of a package for some arch, the tool notices it has to do them all because of multi-arch constraints, and replicates the request for all other arches. Just that this won't do it, because the changelogs for the different arches will be binary different, so no win. However, we discussed that during the multi-arch bof last Debconf, and came to the conclusion that it would be better to not modify the changelog as we do now, but instead create a new file changelog.$arch.$version with the binNMU. This is a bit more complicated because it can't be done as of now just within the source package. Anyone implementing this is warmly welcome. Andi -- 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/20120609132606.gx2...@mails.so.argh.org
Re: bts.turmzimmer.net not updating
* Touko Korpela (touko.korp...@iki.fi) [120602 12:46]: It seems that http://bts.turmzimmer.net service Unofficial RC-Bugs Count isn't updated since last year. It has some features that official pages lack. But it should be fixed or links to it removed. it's basically dead. I added an appropriate error page now. Andi -- 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/20120602141704.gm13...@mails.so.argh.org
Re: Bug#655673: RM: mafft [ia64] -- ICE
* Cyril Brulebois (k...@debian.org) [120529 11:23]: As far as britney hints are concerned, I think arch-specific removals can't reallly be done without manual hacking, so maybe remove As far as I remember britneys construction it could. However, if the arch binary package had been removed in unstable already, it will automatically be scheduled for removal from testing (also again AFAICR). So, ampliconnoise/ia64 should be removed (or fixed) in unstable first, and rest should happen automatically. Andi -- 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/20120529154222.gs2...@mails.so.argh.org
Re: Architecture qualification
* Adam D. Barratt (a...@adam-barratt.org.uk) [120528 14:22]: mips Currently no porter box; being worked on. Some concern over stability of some buildds. eh. The porter box is online again after that was brought to our attention. Still the box has an hardware issue (hard disk might fail in the near future), but a replacement is being worked on. However, the log shows that the porter box is not only online, but also is being used again. Not optimal, but no porterbox is wrong as well. Also, if most porting cases, the mipsel box can be used equally (as mips and mipsel tend to fail on the same issues). The stability concern is exactly about one buildd (or rather: there is only one buildd with flaky hardware), and we are working on getting that one replaced as well. mipsel -- Currently suffering from the loss of a buildd. Machine replacement is in progress, so hopefully won't be an issue for much longer. Replacement is currently on its way to the data center. If we need even one more machine, please say so - we have hardware for it (except a larger ram module needs to be bought, but that's 50 Euro, so no issue as well). Andi -- 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/20120528175749.gl2...@mails.so.argh.org
Re: Architecture qualification
* Philipp Kern (pk...@debian.org) [120528 20:24]: On Mon, May 28, 2012 at 01:21:38PM +0100, Adam D. Barratt wrote: ia64 No real follow-up from porters. #638068 in initramfs-tools may be an issue. Still feels very much on the fringe. We could look how good it works out with some people waking up on the list. (OTOH I can test it is not that helpful.) #638068 sounds to me like an RC bug (adjusted severity now). Also, for ia64 we *could* consider (as long as there is no serious hickup - #638068 is serious) that we release with ia64 but given to the lack of real porters left we already decide now to drop ia64 directly after the release of wheezy. Actually that is what I would expect unless someone is clearly willing (and ready) to work on it from here on. Andi -- 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/20120528184419.gm2...@mails.so.argh.org
Re: Architecture qualification
* Adam D. Barratt (a...@adam-barratt.org.uk) [120528 14:22]:
hurd-i386
-
Is there time to add it to testing and get it out of
{break,fucked}_arches? Would it make sense to release if it was still
in break_ and/or fucked_arches?
Depending on the number of issues that pop up, it might still be
technical possible. However, as a non-linux arch, I have my doubts.
Also, as soon as we consider it a full release architecture, any bugs
relevant to only hurd-i386 are considered RC.
I don't think there is any (technical) harm in adding it to testing as
long as it's in both break and fuck archs - however, from the feedback
I got from different people, it might be felt different, so if we add
it, we need to deliver a very clear message.
We can't release if it still is in any of break/fucked arches (at
least that would be my recommendation, due to technical and legal
issues, e.g. we might need to preserve multiple source code versions
if we have different binary versions within a stable release).
All in all, my recommendation for hurd-i386 would be that (as long as
this is agreed by all involved, and communicated clearly to the
developers at large before doing it) we add hurd-i386 to testing with
break/fucked, but we don't expect it to make the release. I.e. bugs
for hurd-i386 are not RC. We don't do unblocks for hurd-i386. Etc. But
also I think keeping at as part of proper Debian would be good for the
open source community at large, so we keep it even after the next
stable release in testing and unstable.
Andi
--
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/20120528185718.gn2...@mails.so.argh.org
Re: Architecture qualification
* Adam D. Barratt (a...@adam-barratt.org.uk) [120528 22:05]:
On Mon, 2012-05-28 at 20:24 +0200, Philipp Kern wrote:
On Mon, May 28, 2012 at 01:21:38PM +0100, Adam D. Barratt wrote:
hurd-i386
-
Is there time to add it to testing and get it out of
{break,fucked}_arches?
I think it's not. If anything that would be for the beginning of the next
cycle, but not for this one. As KiBi said it would massively increase our
load with unblock requests while it's unlikely that everything's fixed up
in time.
[...]
Would it make sense to release if it was still in break_ and/or
fucked_arches?
No, not at all. It wouldn't be released at all at that point. (I.e. not
copied
into stable.) I'm very uncomfortable having such a thing alongside our
regular architectures (even kfreebsd, which generally works for server
stuff).
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.
Useful for whom?
For preparation of the next stable release: between nil and not really
much, as it isn't part of it.
For preparation of the second next stable release: maybe, if the port
might be part of it.
For stabilization of the port: potentially, depending on the status of
the port and open topic. It's always way more easy to use testing as
target than unstable, e.g. for installation media (remember the issues
DSA had when armel wasn't in testing yet).
For the open source community at large: pick your favourite answer
above.
Andi
--
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/20120528202541.go2...@mails.so.argh.org
Re: mips and mipsel qualification for Wheezy
* Adam D. Barratt (a...@adam-barratt.org.uk) [120523 20:36]: On Fri, 2012-05-18 at 22:31 +0200, Andreas Barth wrote: mipsel buildds: In the last month, we had two buildds eating their hard disk, so all the time only three buildds are active. The three can just keep up but are obviously not how it should be. The currently broken buildd is the non-DSAed, and I don't intend to bring that one back again (at least not for unstable), but instead setup another DSAed 2e buildd. If wanted, I could also setup yet another one - hardware is available for that. IIUC, the plan is for the new buildd to be hosted at man-da? That would give us four mipsel buildds, two at man-da, one of OSUOSL and one at Silver Server. Right. (and then we cross our fingers that nothing bad happens to man-da.) The lemotes however are buyable new for 215 Euros. So nothing too bad for mipsel even if something happens to man-da (however, there is more debian stuff there, so this doesn't hold from a project perspective - so we should still cross our fingers). Andi -- 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/20120523184233.gf13...@mails.so.argh.org
Re: powerpc qualification for Wheezy
* Lennart Sorensen (lsore...@csclub.uwaterloo.ca) [120523 21:21]: On Wed, May 23, 2012 at 07:42:32PM +0100, Roger Leigh wrote: I am still a regular powerpc user, and I should have sufficient time to assist with porting issues for the foreseeable future, which I haven't done for the last couple of releases but will now be able to. So feel free to put me down as a powerpc porter, I'll continue to follow powerpc issues on debian-powerpc and be happy to undertake specific porting and debugging as and when required. I try to help too, but I am not a DD and hence don't matter. :) For being a porter it's not directly required to be a DD (though easier). It's more relevant that to you fix architecture-specific bugs, care about mail to the porter list, report bugs and solve bugs etc. Just making sure the arch is in good shape. And yes, GPG signatures by two different real people (one of them DD) would be helpful too. Andi -- 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/20120523194311.gk2...@mails.so.argh.org
Re: mips and mipsel qualification for Wheezy
* Andreas Barth (a...@ayous.org) [120518 23:47]: Independend of that, we should replace the porterbox with the more stable version of the same hardware soon, even if only for stability. As said, that specific replacement box is currently being tested if it really runs stable. If it does, we'll arrange with DSA for hosting soon. After some discussions with DSA, we would tend to not resurrect the current porter box but instead take the time it takes to get the new box finally tested, shipped, installed (I assume a few weeks if we don't urgent all people involved - shipping hardware and installing in racks just takes it time). Please say if this is considered as problematic from a release point of view (provided that we still have the mipsel box during that time), as then we (or rather: DSA) would have the additional effort of re-installing the current box on a new hard disc for this short time span. Andi -- 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/20120520125337.gg2...@mails.so.argh.org
Re: Architecture qualification
* Cyril Brulebois (k...@debian.org) [120516 11:31]: Andreas Barth a...@ayous.org (16/05/2012): Anyways, if the most concering issue is that there is currently only one swarm-type mips buildd, we could just use the spare machine we have and add another one. (Normally packages can build on any hardware, but sometimes it's more favourable to distribute packages accordingly between different hardware types - nothing too bad, but sometimes e.g. RAM is more important than many processors). Whatever is done, we need packages to build, reliably and not as slowly as these days (week, months…). The current situation is really painful. Looking at mips and its backlog of less than 10 packages, I don't know why you write months. There is no package currently waiting for being built for more than a day on mips (or at least: hadn't been tried since less than a day - things like the mysql-hickup may make a difference here, but that's not mips specific). Of course, accidents happen as on any architecture, e.g. recently a buggy package decided to block a buildd exclusivly for two weeks until I manually kill the build (activly circumventing the buildds safety mechanismn), but that could happen on any hardware and architecture. Andi -- 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/20120520130123.gb13...@mails.so.argh.org
Re: armel qualification for Wheezy
* Peter Palfrader (wea...@debian.org) [120519 11:18]: On Sat, 19 May 2012, Luk Claes wrote: As everyone keeps claiming there is no armel buildd location redundancy, I don't have much motivation to keep ancina running. It's ignored anyway. It's been down for a week or longer now. I sent you email, you didn't answer. We have no out of band management, no serial console, no remote power. And even if it worked, it alone would not be able to keep up. Looking at stats now, it seems that armel doesn't behave better than mipsel currently. If however both arches have a buildd down, that would fit. Andi -- 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/20120519092828.gd2...@mails.so.argh.org
Re: hurd-i386 qualification for Wheezy
* Adam D. Barratt (a...@adam-barratt.org.uk) [120519 20:06]: On Sat, 2012-05-19 at 17:29 +0200, Samuel Thibault wrote: - About buildd-dsa, we are fine with a DSA'd buildd, if DSA is happy to maintain it, they will however probably have to learn a few Hurd things? We don't know to what extend DSA have to tinker with the machine, but we would be happy to help. I think the prevailing view recently has been that having DSAed buildds and porter boxes is generally preferable; this might be something to cover under the above discussion with DSA. For security updates (i.e. after release), we need two DSAed buildds. Having DSAed buildds allows also to do autosigning, which shortens the time span for getting builds into the archive. This isn't strictly required, but not doing so will sometimes lead to annoying delays for testing transitions (when the architecture is in testing, and the mark this arch is too slow removed). (Please also note that as Adam pointed out any new arch will start to live with arch is too slow and packages might break in testing, because otherwise next to all testing transitions will be broken (until more or less all packages are moved to testing).) Andi -- 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/20120519182013.ge2...@mails.so.argh.org
Re: Removing armhf / s390x from broken and/or fucked
* Adam D. Barratt (a...@adam-barratt.org.uk) [120519 22:19]:
One question which has come up quite a bit recently is whether we should
remove armhf and s390x from one or both of {broken,fucked}arches. Doing
so doesn't necessarily imply making them release architectures,
particularly while we're not treating arch-specific bugs on them as RC.
For clarity, broken means the source may migrate even if
installability gets worse on $arch, whereas fucked means the source
may migrate even if builds for $arch aren't ready.
I think we should definitly remove both from broken. armhf looks
better than armel from an overall perspective, and s390x looks
equivalent to s390. Of course, both arches will continue to stay a bit
worse until the flag is finally removed.
As for fucked, I don't think it actually will make any difference, so
removing them there would be recommended but isn't as important as
removing them from broken.
Andi
--
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/20120519222716.gf2...@mails.so.argh.org
Re: mips and mipsel qualification for Wheezy
Hi, regarding both mips and mipsel, a few remarks from the porters. Let's start with our current buildd hardware: 1. swarm: can work as mips and mipsel. We have five such boxes, where one is used as mips buildd (ball), two as mipsel (rem and mayer), one is currently with Aurel, and one has a dead disk and hosting issues (mayr) and should be brought back online again. Machines have dual-core CPUs. 2. Loongson 2e/f: Only mipsel. We have five 2e machines, and one 2f. One 2e is used as porter box, and one as buildd. A second one is just about being setup as buildd. Machines have single-core CPUs, and therefor sometimes different fast then the swarms. 3. Cavium Octeon: Only mips. We have three such machines, which are installed equal. Two of them run buildds, one a porterbox (gabrielli). Two of the machines have stability issues (not totally unstable and in general works well enough, but not as it should be; means machines sometime just reboot by themself), whereas one doesn't. Machines have 16-core-CPUs but no FPU (that's why ressource-hungry packages and/or FPU-intensive ones build *very* slow here). We currently run two buildds per machine, each using up to six cores. We have been offered a replacement for the porterbox, which is currently being stability-tested, and after succeeding could be installed. Regarding the lines on http://release.debian.org/wheezy/arch_qualify.html : mips porterbox: We currently have gabrielli, but as noted above it sometimes isn't as stable as it should. Also, usually issues are same between mips and mipsel, so the mipsel porterbox could also often be used. In sum I think red is not the appropriate colour; I'm not sure green is appropriate for the current status but then yellow might be. mipsel buildds: In the last month, we had two buildds eating their hard disk, so all the time only three buildds are active. The three can just keep up but are obviously not how it should be. The currently broken buildd is the non-DSAed, and I don't intend to bring that one back again (at least not for unstable), but instead setup another DSAed 2e buildd. If wanted, I could also setup yet another one - hardware is available for that. So, the topic buildd-dsa is already yes now as phrixos is down (and please either decrement the number of buildds by one, or set the rendundancy to yes - probably decrementing is more appropriate until the new DSAed buildd is installed). Of course, just as arm* both architectures might be not too fast in certain cases like linking large C++-files - same issues and reasons apply for mips* as well, so I don't want to repeat what's discussed already for arm* here. Andi -- 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/20120518203137.gb2...@mails.so.argh.org
Re: mips and mipsel qualification for Wheezy
* Mehdi Dogguy (me...@dogguy.org) [120518 23:31]: On 18/05/12 22:31, Andreas Barth wrote: mips porterbox: We currently have gabrielli, but as noted above it sometimes isn't as stable as it should. fwiw, weasel mentioned that gabrielli has currently disk issues too. Sounds like a recent issue to me - of course, hard disk issues can happen with any arch, and should be possible to fix the same way as always. Independend of that, we should replace the porterbox with the more stable version of the same hardware soon, even if only for stability. As said, that specific replacement box is currently being tested if it really runs stable. If it does, we'll arrange with DSA for hosting soon. Andi -- 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/20120518214637.gc2...@mails.so.argh.org
Re: Architecture qualification
* Adam D. Barratt (a...@adam-barratt.org.uk) [120515 22:26]: On Tue, 2012-05-15 at 21:45 +0200, Julien Cristau wrote: On Tue, May 15, 2012 at 20:42:14 +0100, Adam D. Barratt wrote: On Tue, 2012-05-15 at 20:42 +0200, Julien Cristau wrote: I'd add a concern about the mips buildds to the arch qual page (not sure how to phrase it). Assuming it's the stability issue, then maybe re-using weasel's unstable under load which we used for the porter box? There's that, and there's some packages that can only be built on ball because lucatelli/corelli fail every time. azeem has a bunch of those. Hmmm, ball's lower spec than the octerons iirc? Different spec. swarm and octeons have different advantages (octeons have many but a slower processors, and less memory per used processor than swarms (because we run two buildds in parallel per hardware, each using up to 6 cpus)). Anyways, if the most concering issue is that there is currently only one swarm-type mips buildd, we could just use the spare machine we have and add another one. (Normally packages can build on any hardware, but sometimes it's more favourable to distribute packages accordingly between different hardware types - nothing too bad, but sometimes e.g. RAM is more important than many processors). Andi -- 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/20120515223403.gy2...@mails.so.argh.org
Re: Architecture qualification meeting for Wheezy
* Adam D. Barratt (a...@adam-barratt.org.uk) [120430 20:30]: On Wed, 2012-04-25 at 23:09 +0100, Adam D. Barratt wrote: On Wed, 2012-04-25 at 13:46 +0100, Adam D. Barratt wrote: fwiw, the next sensible weekends (i.e. ignoring the one in a couple of days time) are May 5/6th - which is a three-day holiday weekend in the UK - and 12/13th, which is the York BSP. I could do the latter but would prefer the former. As mentioned on IRC, a Doodle for the former - http://www.doodle.com/qxr4u5xa29yk3tid So far there have only been two responses, one of which was from me. :-/ If this is due to people not liking the included dates, please suggest others. We really should decide this stuff soon though... As that weekend doesn't work for all, I created a new doodle a week later. As Saturday is already busy with the .-release, I only used Sunday as options http://www.doodle.com/dgi23b5fgxs7vqnk I think it would be useful to have all involved parties present (and give all interessted porters the chance to join us) so that we could get an result we could work on. Andi -- 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/20120502210924.gq2...@mails.so.argh.org
Re: Architecture qualification meeting for Wheezy
* Adam D. Barratt (a...@adam-barratt.org.uk) [120425 14:47]: fwiw, the next sensible weekends (i.e. ignoring the one in a couple of days time) are May 5/6th - which is a three-day holiday weekend in the UK - and 12/13th, which is the York BSP. I could do the latter but would prefer the former. Morning of the 12th (i.e. end prior to 11h UTC) and evening of the 13th (i.e. after 14h UTC) would work here. Andi -- 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/20120426063530.gd13...@mails.so.argh.org
Re: Architecture qualification meeting for Wheezy (Was: Re: Release Team meeting?)
* Niels Thykier (ni...@thykier.net) [120330 08:31]: On 2012-03-30 00:16, Martin Zobel-Helas wrote: Hi, On Thu Mar 29, 2012 at 23:52:02 +0200, Niels Thykier wrote: [...] With my DSA hat on: It would make sense to have someone from the DSA team present during that IRC meeting, as architecture qualification has a direct impact on our hardware and resource planning. Could you set up a doodle for that, and keep us posted? Cheers, Martin Thanks. So one more time :). I propose we do an architecture qualification meeting over the Easter holidays. I have setup a doddle for it at [1]. Sorry, but Easter weekend is a bit bad here because that are 4 days where one could be away. Could we move it a weekend earlier or later? That would be great, at least for me. Andi -- 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/20120330070524.gx13...@mails.so.argh.org
Re: RFC: britney's hint classes
* Adam D. Barratt (a...@adam-barratt.org.uk) [120126 18:48]: Somewhat inherited from b1, b2 has: HINTS_HELPERS = (easy, hint, remove, block, block-udeb, unblock, unblock-udeb, approve) HINTS_STANDARD = (urgent, age-days) + HINTS_HELPERS 1) Does anyone remember the logic behind the current split? Because you need the first set pretty soon for squashing RC bugs or allowing packages to migrated shortly before release. (Not claiming this is the best or a useful or whatever split.) Andi -- 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/20120126231348.gb2...@mails.so.argh.org
Re: armhf / s390x
* Adam D. Barratt (a...@adam-barratt.org.uk) [120105 18:07]: The nett result is that with a few small hammers (a force-hint for a dozen or so binary packages, a couple of urgents and a couple of forces to handle missing mipsel builds) we add ~4500 packages for each of armhf and s390x to testing, the vast majority of which are installable. [...] Those are somewhat annoying, but I think we can live with them in the short term given that they're not armhf or s390x issues as such. I'd say then: add both arches to testing, and we can always look at the minor details later on (as long as these arches don't block testing migration of course). Andi -- 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/20120105181024.ga2...@mails.so.argh.org
Re: binNMUs?
* Steve Langasek (vor...@debian.org) [110912 20:44]: On Thu, Aug 25, 2011 at 08:19:09PM +0200, Julien Cristau wrote: On Mon, Aug 1, 2011 at 15:31:56 +0200, Andreas Barth wrote: Also, I think we still have a reason for +b(something) as sometimes we just need to rebuild on a single architecture (because something strange has happend there), and I don't want to get rid of that ability. The more I think about it, the more I think we should move the binNMU changelog out of /usr/share/doc and allow co-installation of different binNMU versions of multi-arch: same packages. (IOW: agreed) Any reason not to ship it as /usr/share/doc/$pkg/changelog.$arch? (I.e., I think /usr/share/doc is still the right place for it, even if it can't be changelog.Debian.gz anymore.) I would rather do /usr/share/doc/$pkg/changelog.$arch.$binNMU - but well, YMMV. Anyways, I think that dpkg-deb should inject this files e.g. from an entry in the control file. Otherwise, it might be too difficult to get this done. Andi -- 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/20110912191929.gg4...@mails.so.argh.org
Re: debian armel recertification status
* Riku Voipio (riku.voi...@iki.fi) [110815 11:42]: buildds: 5 - arcadelt and argento are no longer in use buildd redundancy: partial - 1 in different location but would struggle to keep up alone buildd-dsa: yes - All armel buildd are under DSA control fixed. Andi -- 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/20110815105648.gw15...@mails.so.argh.org
Re: LFS and IPv6 goals
* Thijs Kinkhorst (th...@debian.org) [110808 10:35]: Hi, On Mon, August 1, 2011 23:07, Neil McGovern wrote: Carried forward from last release: - IPv6 support - Large File Support I'm wondering why these two are still goals for the current cycle. I think it's safe to say that their intent has already been achieved (make Debian generally work well with IPv6/LFS). What's left now is some specific bugs tagged ipv6 or lfs, but these lists will probably never be completely empty. Making a sprint on these subjects with etch and lenny was useful, but now we've now reached the stage where bugs in these systems are valid and should be fixed, but aren't fundamendamentally different from any other set of bugs. They aren't formulated in a SMART way, and it's not clear (to me at least) what in the wheezy cycle specifically is expected to happen that needs release goal status. My conclusion would be to just drop the goals: they've already been successful. This means to me mostly bugs regarding these topics continue to stay (at least) important, and can be NMUed as RC bugs. Perhaps such clean-up tasks should be moved somewhere else, but until that is done, I think release goals is still the appropriate headings for it. Andi -- 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/20110808224324.gr15...@mails.so.argh.org
Re: Release goal proposal: remove yada
* Tim Retout (dioc...@debian.org) [110805 12:20]: Would you feel differently if yada were orphaned? My understanding is that this could happen quite soon - so far I have been unable to elicit a response from the maintainer on bug #334164. If this does not happen within the next week, and in the absence of any response from the maintainer, I'll consider the tech-ctte route. If a maintainer isn't responding any more, the proper route to orphan is via QA, not via tech ctte. Tech ctte is in case a maintainer doesn't want to give away his package. Andi -- 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/20110805161638.gm15...@mails.so.argh.org
binNMUs?
Hi, this comes from a private conversation which actually shouldn't be private (redistributing with permission from Phil). So following up in public now. * Philipp Kern (pk...@debian.org) [110801 13:25]: On Fri, Jul 29, 2011 at 06:29:20PM +0200, Andreas Barth wrote: * Andreas Barth (a...@not.so.argh.org) [110729 13:27]: Otherwise, I think having binNMUs for only one arch is quite often sensible - but we might want to switch +buildX-source-uploads for scheduling the whole archive. What is the technically reason for we cannot do binNMUs anymore? We might just loose the changelog information - or put the additional reasons in files like /usr/share/doc/$pkg/binary-upload-$arch-$number. Of course, for just re-uploading all architectures the +buildN would be good. But for special cases binNMUs are still useful for me. +buildN makes only sense if we agree by policy that we're allowed to make such uploads, though. Sure, but I think we should (question is just how to do that - mostly needs support on the dak side). Also, I think we still have a reason for +b(something) as sometimes we just need to rebuild on a single architecture (because something strange has happend there), and I don't want to get rid of that ability. The technical reason is that it's not guaranteed that a package yields the same files in the non-multiarch directories. But I guess those are actually RC bugs that need to be filed against all packages converted to multiarch and not adhering to this. Yes - this means we should have an automated checker for that. (This includes files like those created by dh-buildinfo, which only needs to be present in a chroot to be picked up by cdbs; it might include other files, like compressing stuff on your own with gzip, not passing -n.) One way would of course be to get rid of changing the changelog (and instead add an extra file to /usr/share/doc/$package/binNMU-$arch-$num-$reason or so). Via that, we wouldn't have conflicting files. Does that sound very insane? Andi -- 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/20110801133156.gh2...@mails.so.argh.org
Re: binNMUs?
* Andreas Barth (a...@not.so.argh.org) [110801 15:32]: this comes from a private conversation which actually shouldn't be private (redistributing with permission from Phil). So following up in public now. And for context (thanks, Niels, for the hint): This is about what happens with multiarch, multiarch: same-packages and binNMUs, see e.g. https://wiki.ubuntu.com/MultiarchSpec#Binary_NMUs for ubuntus way to handle it. Andi -- 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/20110801133743.gj15...@mails.so.argh.org
Re: di/cd/release meetup at DebConf
* Neil McGovern (ne...@debian.org) [110728 12:32]: On Thu, Jul 28, 2011 at 11:16:59AM +0200, Neil McGovern wrote: I'd like to have a sit down with relevant people to work out how we can improve d-i and debian-cd handling for the next release. Please indicate your availability at: http://www.doodle.com/x2kit5h9zurfk6ss To confirm, this is at 2pm BiH time. Meet at the bottom of the stairs to the upper hacklab :) eh, actually the doodle says 3pm BiH time which is equivalent to Berlin time zone I choose. So, what of both is correct? Andi -- 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/20110728110851.gc15...@mails.so.argh.org
Bug#630251: patch for proposed updates / rdesktop sometimes fails to transfer files from win2k8
Package: release.debian.org Hi, some programms make rdesktop to fail to keep up the directory forwarding to an win 2k8-server. Please see http://sourceforge.net/tracker/?func=detailaid=2812158group_id=24366atid=381349 for the bug, the fix is as follows: --- rdesktop-1.6.0.orig/disk.c 2009-06-19 09:06:27.0 -0400 +++ rdesktop-1.6.0/disk.c 2009-06-25 09:40:44.0 -0400 @@ -1096,10 +1101,24 @@ rdp_out_unistr(out, fsinfo-type, 2 * strlen(fsinfo-type) - 2); break; + /* JMD 20090623: Needed for Windows 2008 support + http://msdn.microsoft.com/en-us/library/cc232104(PROT.13).aspx + IRP Query Volume Information class: 0x07 */ + case FileFsFullSizeInformation: + printf(Called FileFsFullSizeInformation\n); + out_uint32_le(out, stat_fs.f_blocks); /* TotalAllocationUnits */ + out_uint32_le(out, 0); + out_uint32_le(out, stat_fs.f_bavail); /* CallerAvailableAllocationUnits */ + out_uint32_le(out, 0); + out_uint32_le(out, stat_fs.f_bfree);/* ActualAvailableAllocationUnits */ + out_uint32_le(out, 0); + out_uint32_le(out, stat_fs.f_bsize / 0x200);/* SectorsPerAllocationUnit */ + out_uint32_le(out, 0x200); /* Bytes per sector */ + break; + case FileFsLabelInformation: case FileFsDeviceInformation: case FileFsControlInformation: - case FileFsFullSizeInformation: case FileFsObjectIdInformation: case FileFsMaximumInformation: Is this correct? If so, I'd prepare and upload an appropriate new version to stable (oldstable has the same bug, and I'm happy to fix it there too, but actually the current stable version just has bug fixes compared to oldstable, so that the new stable version should be backported to olstable in that case). Andi -- 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/20110612180902.gi2...@mails.so.argh.org
Re: move to britney2?
* Adam D. Barratt (a...@adam-barratt.org.uk) [110430 23:49]: On Sat, 2011-04-30 at 23:35 +0200, Andreas Barth wrote: * Steve Langasek (vor...@debian.org) [110430 23:24]: On Fri, Apr 29, 2011 at 11:28:43PM +0200, Andreas Barth wrote: - be less strict and keep old binaries (and thus 2 versions of the same source package) in testing. This applies in particular for libraries going through SONAME changes and which can happily coexist during a transition. That was already discussed and approved for testing I think in Helsinki. However, it needs someone implementing code, and isn't as easy as it looks like. Feel free to submit patches though. I guess that the continued need to run both britney1 and britney2 in parallel is somewhat of a barrier for submitting patches. Any ETA for switching to britney2? Last I remember was after the large transitions are done, which would be ... now. And yes, that should happen. Yes, it should. I've been trying to make sure that the bugs we know about in b2 are documented in the BTS and fix them; the first part should at least be done now. I should also dig out my RFC mail on the switch which I think is sitting in my drafts somewhere. I really think we should do the switch soon, then let both run for a couple of months in parallel, and then start using the newer b2-features. We will see some breakages, but we will do that anyways, and at the current time in the release cycle seems it won't hurt us too bad. Andi -- 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/20110501182708.gt2...@mails.so.argh.org
move to britney2?
* Steve Langasek (vor...@debian.org) [110430 23:24]: On Fri, Apr 29, 2011 at 11:28:43PM +0200, Andreas Barth wrote: - be less strict and keep old binaries (and thus 2 versions of the same source package) in testing. This applies in particular for libraries going through SONAME changes and which can happily coexist during a transition. That was already discussed and approved for testing I think in Helsinki. However, it needs someone implementing code, and isn't as easy as it looks like. Feel free to submit patches though. I guess that the continued need to run both britney1 and britney2 in parallel is somewhat of a barrier for submitting patches. Any ETA for switching to britney2? Last I remember was after the large transitions are done, which would be ... now. And yes, that should happen. But re the keeping old libs, that was already an issue before b2 existed. Also, I seem to remember we discussed that already in Vancouver, but you should know that better. ;) Andi -- 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/20110430213522.gk2...@mails.so.argh.org
Re: move to britney2?
* Steve Langasek (vor...@debian.org) [110501 01:08]: We certainly did. It's not a new idea, and I certainly don't suggest that switching to b2 will suddenly cause patches to appear. But OTOH, the current muddled state of britney maintenance does make it harder for anyone to submit patches should they wish to do so. No doubt about that. We should fix that - and the state of dpkg.c in britney also doesn't help new patches to emerge faster. Andi -- 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/20110430232613.gl2...@mails.so.argh.org
Bug#622279: transition: python-defaults
* Scott Kitterman (sc...@kitterman.com) [110411 18:12]: This transition is the first major step of meeting the Python release goal for Wheezy. The plan in this step is to drop python2.5 and add python2.7 in supported versions. The default python will remain python2.6. The affected packages have been identified: http://release.debian.org/transitions/python2.7.html Because the default python version isn't changing, these do not have to be done all at once. They can be done in smaller batches so as not to impact other transitions or overload the buildds. It would be best to do packages that are used by other packages as build-depends. Someone would need to create appropriate batches and feed them to wanna-build. Last time that was done by Jakub. Also, this means (AFAIUI) that using python2.7 isn't really supported unless that is finished. Also, while doing so, one needs to make sure to not block an ongoing transition, i.e. only schedule packages which are the same in testing and unstable. Some of the packages are arch-all and need (at least as of now) real NMUs to get updated. There are a few packages that directly depend on python2.5 that will have to be ported to a newer python version or removed, but the list is small and we can deal with them in the context of the upcoming python2.5 removal bug and not this transition. They are: freevo gozerbot libtuxcap nagios-statd python-multiprocessing Looking only at these packages, the can be removed from testing (plus gozerbot-plugins), so that doesn't sound too bad. Of those, python-multiprocessing will definitely be removed since it's a backport of a module included in python2.6 and later. As we want to get rid of python2.5, that sounds like an candidate for an removal bug even as of now. python2.7 is already in testing. python-support, python-central, distribute, and python-stdlib-extensions will need updates. I've discussed this with maintainers/uploaders for those packages. They have either been in experimental or are trivial to prepare and will be uploaded in coordination with python-defaults. Ok. In sum, sounds good to me as soon as someone volunteers to create appropriate batches for the rebuilds. Andi -- 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/20110411182653.ga31...@mails.so.argh.org
Re: Python2.6 as default
* Scott Kitterman (deb...@kitterman.com) [110409 19:07]: Obviously that was a Squeeze goal. The equivalent goal for Wheezy should be python2.7 as default and python2.5 and python2.6 removed. Sure. Please feel free to fix that. Andi -- 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/20110409172612.gd15...@mails.so.argh.org
Bug#617272: transition: python3-defaults
* Scott Kitterman (sc...@kitterman.com) [110403 17:43]: Source uploads needed: distribute python3-pkg-resources distribute python3-setuptools python-distutils-extra python3-distutils-extra python3-lxml python3-lxml BinNMU: gearman-interface python3-gearman.libgearman jinja2 python3-jinja2 lxml python3-lxml py-postgresql python3-postgresql python-apt python3-apt python-bsddb3 python3-bsddb3 python-drizzle python3-drizzle pyyaml python3-yaml sip4 python3-sip Looks good to me right now, except the bug 619528 of the package python-apt (but that shouldn't be too hard to NMU either). So, if noone else disagrees with me, and python-apt plus the above source upload needing packages are ready to go, please go ahead. Andi -- 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/20110403174630.ga1...@mails.so.argh.org
Re: RFC: use of shlib bump for libc dependency on new multiarch directories?
* Steve Langasek (vor...@debian.org) [110223 22:53]: We can handle this one of two ways. We can either bump the minimal dependency of *all* packages against libc, by adjusting shlibs/symbols in the eglibc package; or we can make adding the dependency a part of the standard library multiarchification recipe. Or third, we could add the new path to eglibc in a stable point update and into unstable, and either a) have a virtual package provided, and for the core utilities pre-depend on that virtual package (so that user systems are never broken by the upgrade), or b) don't multiarch the core utilities for the next stable release. Andi -- 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/20110223230318.gy15...@mails.so.argh.org
Re: RFC: use of shlib bump for libc dependency on new multiarch directories?
* Steve Langasek (vor...@debian.org) [110223 23:29]: Ah, I don't know the details; I take this as gospel from the GCC maintainers that There Are Differences. Perhaps the differences are only optimization rather than compatibility; but regardless, given that most distros use i586-linux-gnu or i686-linux-gnu as their toolchain triplet, i486-linux-gnu is an odd bird to propose to standardize on. AFAIUI, we need the atomic locking the i386 and some early i486 don't have, we need an co-processor that not all i486 have (but that's an kernel issue - the math emulation code is instant root exploitable, and therefor not part of the kernel code), and that's it. However, we optimize for i586 IIRC. [1] As you said pre-depends are messy but the safe bet. It would be best if we could somehow ensure that libc6 is upgraded first and that everything needed for the unpack is still there at that point (i.e. some liberal use of pre-depends somewhere in just the base set instead of everywhere). Ok. I think that's certainly going to be more manageable than trying to add pre-depends to everything, anyway. Any concerns about bumping the dependency for all libraries via dpkg-shlibdeps? Yes, I don't like libary bumps, because that's annoying if we need backports of all packages just to make dpkg happy (and the other package would still work, but just dpkg would complain). But well, maybe still the best. Andi -- 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/20110223230957.gz15...@mails.so.argh.org
Re: Pre-approval request for dpkg sync() changes for squeeze
* Phillip Susi (ps...@cfl.rr.com) [101025 17:00]: On 10/24/2010 1:20 PM, Andreas Barth wrote: I quite often run dpkg installs / upgrades in pbuilder ramdisks. If the sync could be reduced to only that ramdisk, everything would be fine. That's exactly the environment where you would disable syncing entirely since you don't care if the pbuilder chroot becomes corrupted if the system crashes; you will just rebuild it from the tarball anyhow. So, what is the appropriate configuration setting for dpkg, and where are the bug reports for our usual tools to auto-set it correct? If there is none, this argument is moot. Andi -- 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/20101026061013.gr15...@mails.so.argh.org
Re: Pre-approval request for dpkg sync() changes for squeeze
* Phillip Susi (ps...@cfl.rr.com) [101024 19:15]: True, but that seems a bit of a contrived corner case. Most of the time when people are upgrading, I'd wager that they don't have many gb of dirty cache buffers already sitting in the cache. Though that does make me wonder why there isn't a sync() variant that applies only to a specific mount point. That would at least keep other unrelated mounts out of the picture. I quite often run dpkg installs / upgrades in pbuilder ramdisks. If the sync could be reduced to only that ramdisk, everything would be fine. Andi -- 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/20101024172016.gq15...@mails.so.argh.org
Re: Mono 2.6 Transition Plan for Debian/Squeeze
* Mirco Bauer (mee...@debian.org) [100920 23:47]: Time has come, Mono 2.6 is ready for testing migration \o/ unblocked. Andi -- 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/20100921070632.ge2...@mails.so.argh.org
Re: Python3 experimental packages with destination squeeze
* Matthias Klose (d...@debian.org) [100915 01:53]: In experimental you'll find a set of packages for Python3 python3.1 3.1.2+20100909-1 python3.2 3.2~a2-4 python3-defaults 3.1.2-10 python-defaults 2.6.6-2 distribute 0.6.14-3 For reference, since I was asked on IRC: As nobody has disagreed with it yet, and a sane number of people has reviewed the changes (at least that's what I assume from reading three names below it, and it mostly only affects python3) I think it's save to upload these files to unstable now. Andi -- 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/20100920201617.gp15...@mails.so.argh.org
Re: [britney] RFC: Behaviour change for approve hints
* Julien Cristau (jcris...@debian.org) [100919 01:39]: On Sun, Sep 19, 2010 at 01:04:59 +0200, Andreas Barth wrote: * Adam D. Barratt (a...@adam-barratt.org.uk) [100919 00:33]: [ Short version for the impatient - I'd like to make britney require all architectures to be built in t-p-u before paying any attention to an approve hint ] cool. can we please as well get an force-approve? ;=) Couldn't that just be separate force and approve? if that works, why not? Andi -- 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/20100919061423.gb2...@mails.so.argh.org
Re: [britney] RFC: Behaviour change for approve hints
* Adam D. Barratt (a...@adam-barratt.org.uk) [100919 00:33]: [ Short version for the impatient - I'd like to make britney require all architectures to be built in t-p-u before paying any attention to an approve hint ] cool. can we please as well get an force-approve? ;=) Andi -- 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/20100918230459.go15...@mails.so.argh.org
Re: Possibility of getting an up-to-date version of Wine into Squeeze
* Stephen Kitt (li...@sk2.org) [100906 23:24]: Thus the plan would be: 1. adopt mingw-w64 (I'll update #594371) 2. prepare binutils-mingw-w64 and gcc-4.5-mingw-w64 packages 3. update the mingw-w64 runtime (version 1.0 has been released) 4. update the wine-gecko 1.0.0 package 5. package wine-gecko 1.1.0 (this is required for wine-unstable 1.3.2) 6. update wine and wine-unstable [...] All in all it seems rather unrealistic to try hard now to get wine 1.2 into squeeze... Agreed. However, it still would make sense to fix the issues in experimental - we need that anyways. Of course, only with an appropriate priority. Thanks for your effort. Andi -- 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/20100906213050.gp2...@mails.so.argh.org
Re: Docky 2.0.6 upload to Sid/Squeeze request
* Mirco Bauer (mee...@debian.org) [100904 14:48]: On Sat, 04 Sep 2010 14:06:19 +0200 Rico Tzschichholz ric...@t-online.de wrote: this is a bug-fix-only upstream release which only includes cherry-picked patches and translation updates! I added an updated and a more filtered debdiff for better reading. debdiff docky_2.0.5-1.dsc docky_2.0.6-1.dsc | filterdiff -x *.po* -x *configure* -x *.m4 docky-206-debian-trimmed.debdiff After reviewing the denoised diff of docky 2.0.6, I think this should be included in squeeze as it only deals with bugfixes and also unbundles the gio-sharp library which always has been the last remaining cog in the wheel as each application is source bundling it's own version of it :/ This of course means if docky 2.0.6 gets approved, gio-sharp needs to be too, which would surely be a good thing from a security/release PoV though! Sounds fair to me. Please remind me after it's uploaded. Andi -- 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/20100905105808.gk15...@mails.so.argh.org
Re: Possibility of getting an up-to-date version of Wine into Squeeze
* Andreas Barth (a...@not.so.argh.org) [100829 15:55]: * Andreas Barth (a...@not.so.argh.org) [100822 23:18]: * Stephen Kitt (li...@sk2.org) [100820 00:02]: The version of Wine Squeeze is going to ship with (1.0.1) is nearly two years old and for many users its use is greatly limited. The recently released stable version, 1.2, has vastly improved support for a large number of applications and games. I have prepared packages in the same style as the current maintainer's, and a few people have tested them. I haven't had much reaction from Ove but I do know he is aware of their existence; I haven't consulted him regarding this particular request. Can we please see this version of wine in experimental first Any news on uploading wine to experimental? ping? Andi -- 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/20100905130635.gm15...@mails.so.argh.org
Re: Possibility of getting an up-to-date version of Wine into Squeeze
* Andreas Barth (a...@not.so.argh.org) [100822 23:18]: * Stephen Kitt (li...@sk2.org) [100820 00:02]: The version of Wine Squeeze is going to ship with (1.0.1) is nearly two years old and for many users its use is greatly limited. The recently released stable version, 1.2, has vastly improved support for a large number of applications and games. I have prepared packages in the same style as the current maintainer's, and a few people have tested them. I haven't had much reaction from Ove but I do know he is aware of their existence; I haven't consulted him regarding this particular request. Can we please see this version of wine in experimental first Any news on uploading wine to experimental? Andi -- 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/20100829135451.gj15...@mails.so.argh.org
Re: Mono 2.6 Transition Plan for Debian/Squeeze
* Mirco Bauer (mee...@debian.org) [100824 22:56]: Mono 2.6 consists out of the following source packages that need to be uploaded to unstable (after this plan was approved by the release team) and also freeze exceptions granted once they are in unstable: ok. Please ping me if the packages are ready for testing migration. Andi -- 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/20100825164455.gi15...@mails.so.argh.org
Re: Please unblock clamav-data
* Philipp Kern (pk...@debian.org) [100819 12:16]: On 08/16/2010 10:56 AM, Marc Haber wrote: Please unblock clamav-data as this will bring more virus signatures into lenny. The package is built and tested automatically inside the debian-volatile infrastructure. well, it's neither built nor tested inside the debian-volatile infrastructure, but outside of it. Apart from that, please see [0]. Well, eunomia was set up specifically for building clamav-data while I was operating debian-volatile (and even while it was on my infrastructure, so it had the same root users). I'm not sure that this automatically makes it part of the volatile infrastructure, but it's also not unrelated. Andi -- 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/20100822091458.gf15...@mails.so.argh.org
Re: Possibility of getting an up-to-date version of Wine into Squeeze
* Stephen Kitt (li...@sk2.org) [100820 00:02]: The version of Wine Squeeze is going to ship with (1.0.1) is nearly two years old and for many users its use is greatly limited. The recently released stable version, 1.2, has vastly improved support for a large number of applications and games. I have prepared packages in the same style as the current maintainer's, and a few people have tested them. I haven't had much reaction from Ove but I do know he is aware of their existence; I haven't consulted him regarding this particular request. Can we please see this version of wine in experimental first (instead the current 1.1.24-1), e.g. also with a version number as 1.2~exp0.1 or so? That would also allow us to judge the open issues (I have some symphathy for this request, but obviously it's quite late or even too late for squeeze.) Andi -- 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/20100822211744.gg15...@mails.so.argh.org
Re: Possibility of getting an up-to-date version of Wine into Squeeze
* Ove Kaaven (o...@arcticnet.no) [100821 04:03]: 1. Get wine-gecko built on Debian. Apparently gcc-mingw32 4.4.4 did not solve all the problems with it, gcc-mingw32 would apparently have to be upgraded all the way to 4.5.0 to build a fully working package. Not sure if the release team will accept that, and even if they did, packaging Wine 1.2 for squeeze will, by now, be a rush job that may result in a package with serious problems. Same here - can we please first see gcc-mingw32 in experimental before discussing about unstable? 2. Allow wine to download upstream's wine-gecko binaries over the Internet, as it does by default. Not an option. Even not for experimental. 3. Disable the wine-gecko download. This results in a crippled Wine, and both upstream and users will hate us. Still better than 2. 4. Leave things as they are. If users want Wine 1.2, let them use backports.org or similar, or even download upstream's own Debian packages if they prefer. Even in that case, we need to fix the issues (perhaps not in the same hurry, but we need to). Andi -- 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/20100822211936.gh15...@mails.so.argh.org
Re: Python 3 support in Squeeze
* Piotr Ożarowski (pi...@debian.org) [100821 00:45]: Please note that in most (all?) cases 2to3 tool (which converts python2.X code to python3.X one) will have to be used (again, no new upstream versions) so patching the code in Squeeze (security bugs, etc.) will not have to be done twice (at least in most cases). In that case, one of the pre-conditions would be to add an appropriate README that tells NMUers (security team et al) what to do to avoid double patching. Otherwise, please wait for a couple more days for a full answer. Andi -- 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/20100821093952.gc15...@mails.so.argh.org
Re: Releasability of the kFreeBSD ports
* Aurelien Jarno (aurel...@aurel32.net) [100804 19:15]: From the server point of view, I think we reached something close to other debian-ports, with even some added features like ZFS. On the other hand I have to agree that on the desktop point of view, there are still problems, which may break the expectations users have from a stable release. The desktop is usable though. This sounds like something that needs to be documented in the release notes (or other accompying documentation). If it's not entirely up to our standards, would a separate suite, like it has been done in the past for sarge-amd64 and etch-m68k, help having some sort of release that can be updated independently from the main stable release? Such a suite could also be useful to land larger changes than normally allowed for stable. Or do you think we should skip this release? (But keep it in testing, of course.) Doing a release, a technology preview or something that offer a consistent port with security updates to the users will definitely help the port by attracting more users and possible developers. I am open to any form of release. Doing something else than a technical normal release has to pay some price. So, I think we should stick with that, unless there is an advantage we get from another form. Of course, it makes sense to put the label technology preview (or similar) on the kbsd-ports of the squeeze release. But that's a non-technical difference (and yes, I don't think the ksbd ports will in all aspects be far enough at the time of the release), not a technical. Andi -- 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/20100805215015.gb15...@mails.so.argh.org
Re: Future requirements for specifying supported Python versionsand transition support
* Scott Kitterman (deb...@kitterman.com) [100626 23:51]: There is a bit of difference over how to specify which versions to build for, but if we don't need to expose it externally (and I don't see a case for this), then it's an internal matter for package build systems as long as they support a requirement that arch: any packages be binNMUable for new Python versions. There are pre-ideas that we might be able to binNMU arch=all-packages as well - nothing that will come too early, but it might be useful to not depend on the fact that we only binNMU arch=any. We've discussed this pretty broadly on debian-pyt...@l.d.o and in #debian- python, so I think we have enough buy-in. In spite of some discussion I have seen, I haven't followed that enough to have an own opinion. Anyways, I trust you that you do it right - I was just stating what are the requirements of the release team (and why), and I think they're sensible (and if not, please feel free to say so). Andi -- 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/20100627092844.gj13...@mails.so.argh.org
Re: Future requirements for specifying supported Python versions and transition support
[ speaking only for myself ]
one thing that isn't clear for me, what is (or is there any) opinion
from doko / POX on this?
* Scott Kitterman (deb...@kitterman.com) [100625 22:37]:
Among the group discussing the question of how to represent Python 3
versions,
there is some reasonable consensus around the idea of a separate field in
debian/control, but there is concern about further bloating Packages.{gz,bz2}
and adding more to the binary control file.
I don't think the bloat is so bad.
The first question is: Does the release team still consider it a requirement
for supported Python{3} versions to be externally exposed in some way other
than through package dependencies? In our review of the recent transitions,
we don't see a case for it.
I think whatever way it works is fine - the main requirement is
something along the lines transitions should be as less painful as
possible. Of course, as long as the python people take mostly care
of the required packages for rebuilding, this is less painful for
the release team ;)
XS-Python-Version: = 2.4, = 3.0
I think that's ugly.
2. Create a new set of fields, XS/B-Python3-Version. This would obtain a
clearer separation and conditions like XS-Python-Version: 2.5, 2.5, 3.1 can
be
treated as an error so that maintainers are aware of a problem. It does add
to the information exposed in Packages.{gz,bz2} for no clear gain.
Sounds fine for me (from the technical point).
3. Create a new field, X-Python-Version: for Python3 versions. This avoids
concerns about control file bloat, but may be a bit confusing in combination
with the existing XS/B-P-V. Please note the lack of XB-Python-Version, i.e.
X-Python-Version will be used to feed build tools only.
I think this will cause confusion. If, then as X-Python3-Version.
Andi
--
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/20100626191134.gh13...@mails.so.argh.org
Re: tbb has not been built on ia64; why?
* Roberto C. Sánchez (robe...@connexer.com) [100608 00:56]: I was looking at the status of tbb, and apparently it has not propogated to testing because of not being build on ia64. One buildd status page says Build-Attempted, but doesn't provide a link to a build log. Does anyone know what is going on with it? Given back, we'll let have it another try. Andi -- 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/20100608065222.gs13...@mails.so.argh.org
Re: Eucalyptus Cloud infrastructure and kernels/initrds
* Stefano Zacchiroli (z...@debian.org) [100529 09:29]: I believe this is the most relevant part for -release. AFAIK the pkg-eucalyptus team already has all the software to create on the fly the needed images and kernel/initrds. The point is then which work-flow do you want to synchronize with pkg-eucalyptus so that when a release is updated, their images get updated too (assuming that the extra coordination is not too much of an extra burden for -release). Similar concerns exist for kernel alone and Steffen is getting in touch with the kernel team about that. Is there any reason why the pkg-eucalyptus team just can't build their images once a (point-)release is ready? How long does it take to build those images? Andi -- 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/20100529095455.gi13...@mails.so.argh.org
Re: Eucalyptus Cloud infrastructure and kernels/initrds
* Steffen Möller (steffen_moel...@gmx.de) [100529 16:52]: On 05/29/2010 02:18 PM, Bastian Blank wrote: On Sat, May 29, 2010 at 01:13:45AM +0200, Steffen Möller wrote: I'll postpone an email to debian-devel for a week or two until the workload at Eucalyptus allows upstream to join the thread on that more public list. Even after reading this mail I'm not sure what exactly you are trying to do. For building some sort of images, you don't need the cooperation of anyone; just fetch it and publish it, the authenticity can be checked with the release key. Agreed. Some fetch and publish is indeed what I was thinking about. The motivation for the email was for instance about the release team triggering the fetch and publish when they want to. Or to just learn about some sorts of caveats that may have escaped us. Of course, I would recommend to do development builds of such images often (basically like d-i, i.e. daily). If that happens, then we can have you in the loop to provide images basically more or less at the time of release - in case it doesn't take too long. (Of course, this would be an additional feature, and in case things go wrong, we could always decide to delay image creation a bit). Andi -- 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/20100529151337.gj13...@mails.so.argh.org
Re: Some of luk's hints need to be reactivated
* Raphael Geissert (geiss...@debian.org) [100430 05:51]: block youtube-dl block kcheckgmail Why are there no RC bugs if the packages are not meant to be released? Andi -- 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/20100430103351.gc3...@mails.so.argh.org
Re: permission to upload ICU 4.4 to unstable
* Jay Berkenbilt (q...@debian.org) [100418 16:00]: Jay Berkenbilt q...@debian.org wrote: ICU 4.4 was released a few weeks ago. There are very few changes from 4.4.rc1. I'm going to do one upload of 4.4 to experimental to make sure it builds properly on all platforms. If all goes well, I'd like to go ahead and upload to unstable. Please let me know when I can proceed with the upgrade. As before, there are no API changes for people who stick to published interfaces, so binary NMUs for reverse dependencies should be adequate, as it has been for the last few ICU transitions. Hello again. I'm still waiting for a response to this. Of course, I understand that the release team is busy and understaffed, and that you have to serialize things sometimes, so I'm not complaining... we confirm that we have seen your request There is not yet a decision where this is in the queue. Sorry for that. Andi -- 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/20100418145758.gb3...@mails.so.argh.org
Re: Ladyhawke bug in britney
* Santiago Vila (sanv...@unex.es) [100416 19:25]: This is really strange. The package stellarium_0.10.2-1_kfreebsd-i386.deb seems to be part of squeeze depending on the position of the sun in the sky (for some yet-to-be-determined timezone). Seems rather to be a bug in dak: stellarium | stellarium | 0.10.2-1 | testing | source, amd64, armel, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc stellarium | stellarium | 0.10.2-1 | testing-proposed-updates | kfreebsd-amd64, kfreebsd-i386 stellarium | stellarium | 0.10.2-1 | unstable | source, alpha, amd64, armel, hppa, hurd-i386, i386, ia64, mips, mipsel, powerpc, s390, sparc This should not happen. I'll check with the ftp-team. Andi -- 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/20100416173832.ga3...@mails.so.argh.org
Re: squeeze release-notes (was: Invite to join the Release Team)
* Simon Paillard (spaill...@debian.org) [100404 20:38]: 1/ In case someone noticed lacks in NEWS file, would the RT allow migration to testing after freeze only for NEWS file update ? Depends on how long the freeze will probably take, but as long as we allow to migrate for l10n-upgrades, NEWS-files sounds sane to me. 2/ Is it acceptable to change NEWS log entry a posteriori ? why not (it might get difficult after the first mass-upgrades happens, but that's nothing that will happen as of tomorrow). Andi -- 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/20100404193503.gm19...@mails.so.argh.org
Re: Binary rebuild of lbdb (#536481)
* martin f krafft (madd...@madduck.net) [100403 10:06]: also sprach Andreas Barth a...@not.so.argh.org [2010.04.03.0957 +0200]: Can we please have the full information in order to schedule the necessary binNMUs? Thanks. After further investigation, it seems that the problem was specific to the NMU package, which was never uploaded. I don't remember where the NMU came from, nor do I still have the package. Sorry. Consider the issue closed. It would have helped if you would just had written that without an further ping, so that I could've dropped the issue from my todo list. Andi -- 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/20100403082711.gj19...@mails.so.argh.org
Re: Migrating netcdf3 - netcdf4
* Francesco P. Lovergine (fran...@debian.org) [100403 15:35]: As always, if RMs or others had something to say about/against this mini-transition, please speak now :-) Please give us a few days time to see where the loss of ries for more than a week leaves us. You'll get another answer later, but please take it as a not now till then. Andi -- 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/20100403134902.gl19...@mails.so.argh.org
Re: Binary rebuild of lbdb (#536481)
Hi, * martin f krafft (madd...@debian.org) [100331 11:09]: Can you please trigger a rebuild of lbdb, due to #536481? why does the binnmu fix the problem? was something changed in a dependency? The bugreport unfortunatly doesn't say anything. Andi -- 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/20100331093409.gz19...@mails.so.argh.org
