Re: BTS lost most of its version tracking data!
On Sat, 31 Dec 2016 16:44:21 +0100 Mattia Rizzolo wrote: > On Sat, Dec 31, 2016 at 04:29:47PM +0100, Francesco Poli wrote: [...] > > They now risk being auto-removed from testing. If they are indeed > > auto-removed, they won't re-enter stretch and they won't be part of > > stretch (as released stable) at all. Not even as version x... > > As you can see from the 2 links I provided in the last email, the > majority of packages that migrated during that broken run were packages > that weren't previously in testing. This is true, no doubt. [...] > I usually account and optimize for the most common case. I acknowledge > what you're saying, but it's not the common case. What you say is more than reasonable. I noticed the issue by looking at the fbpanel case, and I thought that many other packages could be in the same situation. Instead, it seems that there are very few similar cases, while the majority of the wrongly migrated packages fall in other categories. So it seems that I must be only worried about fbpanel and a few other packages... > > > And they do not seem to have one month to get their RC bugs fixed. > > I see that the auto-removals are scheduled for January, the 14th. > > Depends on the bug. Somehow I thought most of them would have until the > 29th, but apparently that's less than half of them. > 396 packages are scheduled for removal the 29th > 548 packages are scheduled for removal the 14th Ah, I see. Thanks for the explanations! Bye. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgp7sYfPl9AAi.pgp Description: PGP signature
Re: BTS lost most of its version tracking data!
On Sat, 31 Dec 2016 15:46:48 +0100 Mattia Rizzolo wrote: > On Sat, Dec 31, 2016 at 03:37:47PM +0100, Francesco Poli wrote: [...] > > It seems a bit unfair that some packages won't be part of stretch, due > > to a BTS glitch which happened during the last days before the soft > > freeze. > > It's kinda the reverse: now *a lot* of packages have another month of > time to be fixed, when before they would have been out of testing > already without any chance of re-entering it. Wait, there's something in your line of reasoning that is not clear to me. Some packages were in the following situation: testing: version x with no RC bugs unstable: version y affected by one or more RC bugs They didn't risk any auto-removal from testing. Maybe they risked being part of stretch (as released stable) as version x, rather than version y > x. But nothing worse. Now those packages are in the following situation: testing _and_ unstable: version y affected by one or more RC bugs They now risk being auto-removed from testing. If they are indeed auto-removed, they won't re-enter stretch and they won't be part of stretch (as released stable) at all. Not even as version x... And they do not seem to have one month to get their RC bugs fixed. I see that the auto-removals are scheduled for January, the 14th. One example is the already cited fbpanel [1]. [1] https://tracker.debian.org/pkg/fbpanel > > > What can be done about this unfortunate situation? > > go fix RC bugs. Needless to say, this would be the ideal solution! :-) But we both know that some package maintainers are not so quick to deal with bugs, not even when the severity is above the RC threshold and the deadlines are near... :-( Hence my concern. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgprirNUjTLYR.pgp Description: PGP signature
Re: BTS lost most of its version tracking data!
On Fri, 30 Dec 2016 18:57:06 +0100 Mattia Rizzolo wrote: > On Fri, Dec 30, 2016 at 04:47:30PM +0100, Francesco Poli wrote: > > In the meanwhile, I see that something changed on the BTS side. > > But something still appears to be wrong. The RC bug count page [1] > > claims > > > > Number concerning the current stable release: 597 > > Number concerning the next release: 1190 > > > > which does not look right to me (there were about 500 RC bugs > > concerning the next release a few days ago, or am I recalling > > incorrectly?!?). > > that's because "concerning the next stable release" means testing. > Before yesterday all those RC-buggy packages were kept out of testing, > so the RC bug count for it was a lot lower. So many RC bugs introduced into testing, due this BTS version tracking issue?!? Could this harm the release process? I mean: a lot of RC-buggy package versions migrated into testing, when they should have not. Many packages are now risking being auto-removed from testing, if the RC bugs are not fixed quickly. And auto-removed packages won't re-enter stretch, since the soft freeze will begin shortly [2]. [2] on January, the 5th, unless I am misinterpreting the announce https://lists.debian.org/debian-devel-announce/2016/12/msg0.html It seems a bit unfair that some packages won't be part of stretch, due to a BTS glitch which happened during the last days before the soft freeze. What can be done about this unfortunate situation? -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgp0dEdCMJq6k.pgp Description: PGP signature
Re: BTS lost most of its version tracking data!
On Thu, 29 Dec 2016 16:40:39 +0100 Emilio Pozuelo Monfort wrote: > On 29/12/16 16:34, Francesco Poli wrote: [...] > > As of now, the RC bug count page [1] claims > > > > Number concerning the current stable release: 24 > > Number concerning the next release: 25 > > > > which is obviously wrong. [...] > > [1] https://bugs.debian.org/release-critical/ [...] > > I think the problem is grave, as it seems to allow packages to migrate > > to testing with new RC bugs. [...] > > Yes, we noticed that earlier today and decronned britney. Unfortunately that > was > too late for last night's (UTC) britney run. I see, thanks a lot for your super-prompt reply! > > We need to implement a check in britney to abort the run if the data from the > BTS is bad. That is not ideal if the BTS gives us a partially broken file... > It'd be better if it gave us nothing at all if something went wrong. I agree that some sort for guard against incorrect data from the BTS would be useful. And I also agree that the BTS should attempt to check the correctness of the data, before sending everything out. Or fail as clearly as possible, when the dataset is not good. In the meanwhile, I see that something changed on the BTS side. But something still appears to be wrong. The RC bug count page [1] claims Number concerning the current stable release: 597 Number concerning the next release: 1190 which does not look right to me (there were about 500 RC bugs concerning the next release a few days ago, or am I recalling incorrectly?!?). Please let me know. Thanks for your time! -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgp7wmCXE6Mdo.pgp Description: PGP signature
BTS lost most of its version tracking data!
Hello! It seems to me that the BTS version tracking is no longer working correctly. Yesterday the RC bug count page [1] suddenly reported more than 2000 RC bugs closed or downgraded. The actual listed RC bugs were not really closed or downgraded, they just seemed to lack knowledge about which package versions are currently in the various Debian suites (testing, unstable, stable, ...). [1] https://bugs.debian.org/release-critical/ As of now, the RC bug count page [1] claims Number concerning the current stable release: 24 Number concerning the next release: 25 which is obviously wrong. I think the problem is grave, as it seems to allow packages to migrate to testing with new RC bugs. For instance, fbpanel/7.0-2 [2] has just migrated to testing, and this migration introduced one unfixed RC bug [3] into testing. [2] https://tracker.debian.org/pkg/fbpanel [3] https://bugs.debian.org/846626 I hope this BTS issue may be fixed real soon now, since it is apparently causing harm to the stretch release process (this is why I am Cc-ing the Release team). Thanks for your time! Bye. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpPipBvWHooS.pgp Description: PGP signature
Re: bugscan doesn't obey Extra-Source-Only: yes (and debbugs probably doesn't either)
On Mon, 1 Aug 2016 13:25:22 -0500 Don Armstrong wrote: [...] > On Sat, 30 Jul 2016, Francesco Poli wrote: [...] > > Would you like to have an actual bug report filed against debbugs, in > > order to track the issue more easily? > > Sure, done with this email. Good, thank you! -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpsN9k2Mg8lI.pgp Description: PGP signature
Re: Bug#830267: dpkg: Segmentation fault when purging package in APT test case
On Mon, 25 Jul 2016 22:03:36 +0200 Francesco Poli wrote: > On Mon, 25 Jul 2016 10:41:08 -0500 Don Armstrong wrote: [...] > > OK, this is going to take a bit of work; I think the short-term answer > > is for the BTS to completely ignore source entries which are > > Extra-Source-Only: yes > > > > I'll try to get to that shortly so we don't have more bad migrations > > like this in the future. > [...] > And thanks to you, Don, for your willingness to fix the issue soon. Hello Don, any progress on this issue? Would you like to have an actual bug report filed against debbugs, in order to track the issue more easily? Please keep us informed. Thanks for your time! -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpE0NWnYmibW.pgp Description: PGP signature
Re: Bug#830267: dpkg: Segmentation fault when purging package in APT test case
On Mon, 25 Jul 2016 10:41:08 -0500 Don Armstrong wrote: > On Mon, 25 Jul 2016, Adam D. Barratt wrote: > > > [dropped #830267 from CC; it's not directly relevant to this branch of the > > discussion] So be it. [...] > > Does the BTS take account of entries in Sources marked > > "Extra-Source-Only: yes" when determining bugginess? > > No, we totally ignore that field. > > > If so, a possible explanation is that debsig-verify 0.15 migrated to > > testing overnight on the 18th/19th. The binary packages have > > "Built-Using: dpkg (= 1.18.9)", which would have led dak to add the > > corresponding source package to testing with an E-S-O marker. > > Ah. Yep, that definitely explains it. > > OK, this is going to take a bit of work; I think the short-term answer > is for the BTS to completely ignore source entries which are > Extra-Source-Only: yes > > I'll try to get to that shortly so we don't have more bad migrations > like this in the future. Thanks a lot, Adam, for figuring out what could be the cause of the bad migration. And thanks to you, Don, for your willingness to fix the issue soon. Bye. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgp6i0U9WzmtV.pgp Description: PGP signature
Re: Bug#830267: dpkg: Segmentation fault when purging package in APT test case
On Sun, 24 Jul 2016 11:43:19 -0500 Don Armstrong wrote: [...] > I'll try to check out snapshots > later this week to see if I can figure out when the transition actually > happened, or if there was something else going on in the archive to > explain it. Thanks for your help! Please keep us informed, as the investigations go on. Bye. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgphhxYGTKWnB.pgp Description: PGP signature
Re: Bug#830267: dpkg: Segmentation fault when purging package in APT test case
On Sun, 24 Jul 2016 16:24:19 +0100 Jonathan Wiltshire wrote: > On 2016-07-24 16:00, Francesco Poli wrote: [...] > > Should <owner@bugs.d.o> be contacted, perhaps? > > Sure, if you'd like to. Dear BTS owner, could you please investigate on what happened to bug #830267 on 2016-07-19T10:00 ? Please take a look at https://bugs.debian.org/830267#20 https://bugs.debian.org/830267#25 for more context. Thanks for your time. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpKh9__sDa55.pgp Description: PGP signature
Re: Bug#830267: dpkg: Segmentation fault when purging package in APT test case
On Sun, 24 Jul 2016 13:51:45 +0100 Jonathan Wiltshire wrote: > On 2016-07-24 11:20, Francesco Poli wrote: [...] > > Dear Release Team, could you please explain what I failed to understand > > about the testing migration rules [2]? > > Your understanding is correct - an RC bug affecting sid and not testing > is considered a regression and blocks migration, whereas one which > affects both suites does not. Good, thanks for confirming! > > Britney is fed that information from the BTS. The migration happened > because on 2016-07-18T22:00 #830267 was a regression, but on > 2016-07-19T10:00 it was marked as also affecting testing, so the package > was migrated. I don't know what happened in the BTS to cause that > change, certainly nothing on the bug log that I can see. I hope it's possible to investigate further, in order to find out what really happened: needless to say, I think that the correctness of the migration process is of great importance to the quality of Debian testing (and, consequently, of future stable releases!). Should <owner@bugs.d.o> be contacted, perhaps? -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpILBgo0ZFSQ.pgp Description: PGP signature
Re: Bug#830267: dpkg: Segmentation fault when purging package in APT test case
On Thu, 7 Jul 2016 21:14:10 +0200 Guillem Jover wrote: [...] > On Thu, 2016-07-07 at 20:37:39 +0200, Julian Andres Klode wrote: > > Package: dpkg > > Version: 1.18.9 > > Severity: serious > > > > dpkg fails to purge a package [...] > > Hmm, thanks for the report, I know where this is coming from, I'm > fixing it and preparing an upload right away for later today. [...] Hello Guillem, I see that this serious bug has been pending since July the 7th. I thought dpkg/1.18.10 was going to be uploaded to unstable very soon after having found the fix for this regression, but apparently something went wrong. In the meanwhile, dpkg/1.18.9 managed to migrate to testing [1], despite introducing this RC bug: I wonder how that was even possible... do the testing migration checks skip pending RC bugs?!? a pending bug is not a fixed bug!!! I am Cc-ing the Release Team about this. Dear Guillem, could you please clarify the status of this bug? Dear Release Team, could you please explain what I failed to understand about the testing migration rules [2]? Please let me know, thanks for your time. [1] https://tracker.debian.org/news/785311 [2] https://www.debian.org/devel/testing -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgp7HXipql5_4.pgp Description: PGP signature
Re: License incompatibility below RC threshold
On Sun, 24 Apr 2016 08:42:51 + Niels Thykier wrote: ^^^ > Francesco Poli: [...] > > Could someone prod the FTP masters to analyze the issue and provide an > > authoritative statement? > > > > Thanks for your time. > > > > > > It seems to me that you just did? Maybe, but, as you can see (please note the above highlighted date), it does not seem to work!:-( I have repeatedly asked the FTP masters to analyze the issue and express their opinion, but I have seen no reply yet. Once again, I urged them to address this issue, but nothing seems to have happened. That's why I asked someone else to prod them: I was hoping to find someone more likely to be listened to... -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgp1WSA4ygkof.pgp Description: PGP signature
Re: License incompatibility below RC threshold
On Sat, 23 Apr 2016 15:34:44 + Niels Thykier wrote: > Francesco Poli: > > On Sat, 2 May 2015 18:34:31 +0200 Francesco Poli wrote: > > > >> [...] > > > > > > Dear Release Team, dear FTP masters, > > once again this issue has been left unaddressed for quite some time, > > unfortunately. [...] > > Hi, Hello Niels, thanks for your prompt reply. > > AFAICT, the FTP masters are the authoritative source on dealing with > license issues and they have not yet made a ruling. Yes, and that's the problem: they seem to never answer, no matter who and when tries to ask for a reply. Am I writing to the right e-mail address? I originally wrote to <ftpmas...@debian.org> (which is listed in <https://www.debian.org/intro/organization>), but I see that you wrote to <ftpmas...@ftp-master.debian.org>. Which one should I use? > > * I see no reason for the Release Team to be involving at this point as >we cannot answer this inquiry. > > However, should the FTP masters rule it to be a license incompatibility, > please do not hesitate to bump the severity to RC. Could someone prod the FTP masters to analyze the issue and provide an authoritative statement? Thanks for your time. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpbLgZgAs3Zp.pgp Description: PGP signature
Re: License incompatibility below RC threshold
On Sat, 2 May 2015 18:34:31 +0200 Francesco Poli wrote: > On Thu, 15 Jan 2015 18:49:55 +0100 Niels Thykier wrote: > > > Hi FTP masters, > > > > We have been prodded about the severity of #741196 > [ the prod is https://bugs.debian.org/741196#101 ] > > However, being a license interpretation issue, we would like to > > defer the judgement to you on this one (suggested in comment #39). > > You may find the mail from Russ Allbery at [1] relevant for narrowing > > down the possible issue (which is AFAICT a "choice of venue" clause). > > > > If you believe this is (or might be) a grave issue, please upgrade the > > severity at your earliest convenience and notify us. > > > > Thank you, > > ~Niels > > > > [1] https://lists.debian.org/debian-release/2015/01/msg00264.html > > Dear Release Team, dear FTP masters, > just as I feared, jessie was released with this license incompatibility > unaddressed. > > > I believe I presented all the relevant facts to explain why there > indeed is an incompatibility between the CeCILL-C and the GNU GPL > licenses. > Russ Allbery agreed that this may actually be a problem. > > Yet, the package maintainers do not believe that there is an issue and > they keep the bug severity below the RC threshold, while waiting for > some official pronouncement from the FTP masters. > This official statement from the FTP masters has been requested > multiple times, but seems to never arrive. > > Could you please take the time to address this issue during the stretch > development cycle? > > Looking forward to hearing back from you. > Thanks for your time. Dear Release Team, dear FTP masters, once again this issue has been left unaddressed for quite some time, unfortunately. I think it should be taken care of as soon as possible, lest it slip through another stable release. Please re-read (at least): https://bugs.debian.org/741196#5 https://bugs.debian.org/741196#53 https://bugs.debian.org/741196#96 https://bugs.debian.org/741196#111 What do you think should be done? Once again, looking forward to hearing back from you. Thanks for any help you may provide in solving this issue once and for all. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpdZq3UhdqzB.pgp Description: PGP signature
Bug#816708: release.debian.org: migration waits 5 days despite urgency=high
On Fri, 04 Mar 2016 18:50:56 + Adam D. Barratt wrote: > That package version is not in the list of uploads and urgencies fed to > britney by dak (most likely due to dinstall having had some issues > recently), so the default urgency is being used. Ah, I see: I hope these issues may be fixed soon... > > I've added a hint so the package should be eligible to migrate in the > next run. Thanks! Bye. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpJjBU9_fQxk.pgp Description: PGP signature
Bug#816708: release.debian.org: migration waits 5 days despite urgency=high
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: britney Hello Release Team! I noticed something awkward about the unstable→testing migration and it seems to me that it's not even the first time I see it... It appears that the migration waits 5 days, even in cases where the upload has set urgency=high. For instance, openssl/1.0.2g-1 hasn't yet migrated to testing: $ rmadison openssl | grep 'unstable \|testing ' | cut -c 1-60 openssl| 1.0.2d-1 | unstable openssl| 1.0.2f-2 | testing openssl| 1.0.2g-1 | unstable but it got uploaded more than 2 days ago [1]. The excuses [2] seem to confirm that britney is waiting 5 days. Since this upload fixes several vulnerabilities, I think the urgency is well justified: why does britney seem to ignore it? Please investigate and fix the issue. Or else, please clarify where my reasoning is wrong. Thanks for your time. Bye! [1] https://tracker.debian.org/news/751911 [2] https://qa.debian.org/excuses.php?package=openssl
Re: License incompatibility below RC threshold
On Thu, 15 Jan 2015 18:49:55 +0100 Niels Thykier wrote: Hi FTP masters, We have been prodded about the severity of #741196 [ the prod is https://bugs.debian.org/741196#101 ] However, being a license interpretation issue, we would like to defer the judgement to you on this one (suggested in comment #39). You may find the mail from Russ Allbery at [1] relevant for narrowing down the possible issue (which is AFAICT a choice of venue clause). If you believe this is (or might be) a grave issue, please upgrade the severity at your earliest convenience and notify us. Thank you, ~Niels [1] https://lists.debian.org/debian-release/2015/01/msg00264.html Dear Release Team, dear FTP masters, just as I feared, jessie was released with this license incompatibility unaddressed. I believe I presented all the relevant facts to explain why there indeed is an incompatibility between the CeCILL-C and the GNU GPL licenses. Russ Allbery agreed that this may actually be a problem. Yet, the package maintainers do not believe that there is an issue and they keep the bug severity below the RC threshold, while waiting for some official pronouncement from the FTP masters. This official statement from the FTP masters has been requested multiple times, but seems to never arrive. Could you please take the time to address this issue during the stretch development cycle? Looking forward to hearing back from you. Thanks for your time. Bye. -- http://www.inventati.org/frx/ fsck is a four letter word... . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgp9CjCYU969O.pgp Description: PGP signature
License incompatibility below RC threshold
Dear Release Team, I am concerned that a license incompatibility (bug #741196 and the other similar bug reports against other packages) might slip through into the jessie release without being noticed or addressed adequately. Please read #741196 bug log, or, at least: https://bugs.debian.org/741196#5 https://bugs.debian.org/741196#53 https://bugs.debian.org/741196#96 What do you think should be done? I am very disappointed by the lack of replies from the FTP Masters and by the status of this bug: it seems that nobody is addressing it in any way and the severity is being kept below the RC threshold (during the wait for an official statement that seems to never arrive). Looking forward to hear back from you. Thanks for your time. -- http://www.inventati.org/frx/ fsck is a four letter word... . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgplwXQ_IpvW_.pgp Description: PGP signature
Bug#729747: pu: package apt-listbugs/0.1.8
On Fri, 06 Dec 2013 14:18:55 + Jonathan Wiltshire wrote: [...] On 2013-12-04 21:24, Francesco Poli wrote: On Wed, 04 Dec 2013 14:04:41 + Jonathan Wiltshire wrote: [...] On 2013-11-16 16:43, Francesco Poli (wintermute) wrote: [...] If you agree, I can ask my usual sponsor to upload the prepared package to stable, so that it will end up in the next point release. Yes, please. OK, thanks for your reply. I've just asked my usual sponsor to perform the upload. FTR, uploaded Thanks. Where is the built package? I expected to find it in http://ftp.debian.org/debian/pool/main/a/apt-listbugs/ but it has not shown up yet. and flagged for acceptance. Thanks. Unfortunately (due to a misunderstanding) the package was built by my sponsor without including the l10n .po file update, hence I am afraid that it will be almost without working localized strings. If you think that this warrants a stop the press!, could you please un-flag it for acceptance, until I can check the package and (possibly) manage to fix the issue? I hope we are still in time... -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpLCIRVL3KTV.pgp Description: PGP signature
Bug#729747: pu: package apt-listbugs/0.1.8
On Fri, 6 Dec 2013 18:56:05 +0100 Francesco Poli wrote: On Fri, 06 Dec 2013 14:18:55 + Jonathan Wiltshire wrote: [...] On 2013-12-04 21:24, Francesco Poli wrote: On Wed, 04 Dec 2013 14:04:41 + Jonathan Wiltshire wrote: [...] FTR, uploaded Thanks. Where is the built package? I expected to find it in http://ftp.debian.org/debian/pool/main/a/apt-listbugs/ but it has not shown up yet. Never mind, it has now appeared there... and flagged for acceptance. Thanks. Unfortunately (due to a misunderstanding) the package was built by my sponsor without including the l10n .po file update, hence I am afraid that it will be almost without working localized strings. If you think that this warrants a stop the press!, could you please un-flag it for acceptance, until I can check the package and (possibly) manage to fix the issue? I hope we are still in time... I've just tested the package inside a wheezy chroot environment. It seems to work correctly, even when non-English locales are used. Sorry for raising a non-issue. I think we may go ahead and accept the package for the upcoming stable update. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpaky6JHowJd.pgp Description: PGP signature
Bug#729747: pu: package apt-listbugs/0.1.8
On Wed, 04 Dec 2013 14:04:41 + Jonathan Wiltshire wrote: [...] On 2013-11-16 16:43, Francesco Poli (wintermute) wrote: [...] If you agree, I can ask my usual sponsor to upload the prepared package to stable, so that it will end up in the next point release. Yes, please. OK, thanks for your reply. I've just asked my usual sponsor to perform the upload. Be aware that the window closes on Saturday. That's a close deadline... What happens if the upload does not make it before Saturday? Would it be just postponed to the successive stable update? P.S.: after this, I may perhaps find the time to do the same for oldstable (squeeze), unless you say I shouldn't bother... Please do. I'll see what I can do: when will the current window for oldstable (squeeze) close? Is there an already decided deadline? -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgphIW_PUlVU7.pgp Description: PGP signature
Bug#729747: pu: package apt-listbugs/0.1.8
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: pu Hello, I am the current maintainer of the apt-listbugs package. While preparing version 0.1.10, I fixed an insecure temporary file creation. The apt-listbugs program creates a temporary file in /tmp, when the user asks to view the bug lists in HTML with a browser. This temporary file is created, written (with HTML content), and then displayed by a web browser (invoked by apt-listbugs itself). Before version 0.1.10, this temporary file used to be created by an ad-hoc class, which computed the file name by just concatenating a fixed string, the PID, and a progressive integer starting at 0 (incremented, in case of name conflict with an already existing file). Since I thought that this mechanism was fairly predictable and insecure, I dropped this ad-hoc class and started using Tempfile from Ruby standard library, which seems to be more secure. This fix is part of apt-listbugs version 0.1.10 or later. Version 0.1.11 migrated into testing about one month ago. I got in touch with the security team, asking whether I should prepare updated versions of apt-listbugs for wheezy and maybe squeeze, back-porting the fix to versions 0.1.8 and maybe 0.1.3, and explicitly pointing out that apt-listbugs is a package which is useful above all to testing and unstable users, and definitely less so to stable and oldstable users. The security team kindly obtained a CVE number for this security issue (CVE-2013-6049) and replied that the issue doesn't warrant a DSA, but it would be good to fix it for an upcoming point update. Hence, I prepared apt-listbugs/0.1.8+deb7u1 for wheezy: please find the source diff attached (the only other changes are the result of running make update-po in order to update the .pot and .po l10n files). If you agree, I can ask my usual sponsor to upload the prepared package to stable, so that it will end up in the next point release. Please let me know. Thanks for your time! P.S.: after this, I may perhaps find the time to do the same for oldstable (squeeze), unless you say I shouldn't bother... apt-listbugs_stable-update_0.1.8+deb7u1.diff.gz Description: application/gzip
Re: Bug#710140: gpgme1.0 dropped libgpgme-pth
On Sat, 5 Oct 2013 11:41:55 +0200 Francesco Poli wrote: [...] I waited some time before speaking again, as I was hoping to see some comments from other people, possibly members of the release team. Anyway, do I understand correctly that this issue has currently a practical impact only on boxes where non-packaged (== not included in Debian) programs or libraries which use libgpgme-pth.so or libgpgme+ +-pth.so are installed? Could you please confirm this? Please do not misunderstand me: I am not trying to argue about the severity of the bug (whether it is a Policy violation or not, and so forth...). I am just trying to clarify which users should avoid upgrading libgpgme11 because of this issue and which users may safely upgrade without worrying to break their systems. Please let me know. Thanks for your time. Does anyone have anything to say about this? Please clarify. Thanks for any insight you may share. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpWZQfXYMYRS.pgp Description: PGP signature
Re: Bug#710140: gpgme1.0 dropped libgpgme-pth
On Tue, 03 Sep 2013 15:06:14 +0200 Daniel Leidert wrote: [...] Am Sonntag, den 25.08.2013, 12:19 +0200 schrieb Francesco Poli: [...] Could you please clarify the status of the bug? Thanks for your time! CCing release.d.o. [...] I'm hereby asking the release team how to proceed? The issue itself seems to have been fixed inside Debian by fixing libgpgme++2, which has already been done [3]. There might be third-party software out there using libgpgme-pth.so or libgpgme++-pth.so. [...] [3] http://packages.qa.debian.org/k/kdepimlibs/news/20130614T070347Z.html Dear Daniel, first of all thanks for your kind reply. I waited some time before speaking again, as I was hoping to see some comments from other people, possibly members of the release team. Anyway, do I understand correctly that this issue has currently a practical impact only on boxes where non-packaged (== not included in Debian) programs or libraries which use libgpgme-pth.so or libgpgme+ +-pth.so are installed? Could you please confirm this? Please do not misunderstand me: I am not trying to argue about the severity of the bug (whether it is a Policy violation or not, and so forth...). I am just trying to clarify which users should avoid upgrading libgpgme11 because of this issue and which users may safely upgrade without worrying to break their systems. Please let me know. Thanks for your time. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpN0tvPhJko9.pgp Description: PGP signature
Bug#692928: unblock: apt-listbugs/0.1.9
Control: tags -1 - moreinfo On Sun, 11 Nov 2012 00:34:02 +0100 Francesco Poli wrote: [...] To be frank, the proposed update was actually supposed to meet the previous guidelines for freeze exceptions: translation updates and documentation fixes. [...] the upload of version 0.1.9 [...] was due about one week ago, but was delayed because of personal issues. Sorry about that. [...] Now I am sorry, if I managed all this situation the wrong way, but I felt it would have been a shame to postpone the accumulated changes until after the wheezy release... :-( Thanks for your patience. I think I provided the requested additional information. Please ask again, in case you need more. I hope the freeze exception may be granted, even if the upload happened with a couple days of delay with respect to the freeze policy change... Please let me know, thanks for your time and understanding. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpgz2vTTcJch.pgp Description: PGP signature
Bug#692928: unblock: apt-listbugs/0.1.9
On Mon, 12 Nov 2012 17:51:20 + Neil McGovern wrote: On Mon, Nov 12, 2012 at 06:31:00PM +0100, Francesco Poli wrote: I hope the freeze exception may be granted, even if the upload happened with a couple days of delay with respect to the freeze policy change... Hi, I'm afraid we have our policy in place now so that we don't have to manually review these little changes, so this isn't getting an unblock. For a *couple* days of delay, caused by *personal* issues beyond my own control? Taking into account that I did *not* know in advance when the freeze policy was going to be changed? Bah, this is really frustrating and discouraging... :-( -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpOMZbxpmcA3.pgp Description: PGP signature
Bug#692928: unblock: apt-listbugs/0.1.9
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package apt-listbugs As can be seen with the following command on the public git repository: $ git diff apt-listbugs/0.1.8..apt-listbugs/0.1.9 | filterdiff \ --exclude='*.po' --exclude='*.pot' the only non-l10n changes from version 0.1.8 are: * minor improvements for the Makefile * drop of Thomas Müller from the Uploaders field at his request * drop of a superfluos dependency on a virtual package I am attaching the output of the above mentioned command. If you like to review the changes organized in commits, please feel free to take a look at the git repository: http://anonscm.debian.org/gitweb/?p=apt-listbugs/apt-listbugs.git;a=shortlog Thanks for your time! unblock apt-listbugs/0.1.9 -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (800, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash apt-listbugs_018_019.diff.gz Description: GNU Zip compressed data
Bug#692928: unblock: apt-listbugs/0.1.9
On Sun, 11 Nov 2012 00:09:52 +0100 intrigeri wrote: [...] Hi, Hi! Thanks for your very fast reply. Francesco Poli (wintermute) wrote (10 Nov 2012 22:37:17 GMT) : unblock apt-listbugs/0.1.9 The request does not help me understand how the proposed update is supposed to meet the current guidelines for freeze exceptions [1]. Please clarify. [1] http://release.debian.org/wheezy/freeze_policy.html To be frank, the proposed update was actually supposed to meet the previous guidelines for freeze exceptions: translation updates and documentation fixes. The drop of the dependency on a virtual package makes the package comply with the new Debian Ruby Policy. The remaining changes are really minor ones. I had requested another unblock (with more changes) on last September, the 30th, and it was granted (see #689204). Since then, I have prepared the upload of version 0.1.9, which was due about one week ago, but was delayed because of personal issues. Sorry about that. At that point, I received the debian-devel-announce message [2], which announced the updated freeze policy, and I thought I hope I am still on time to get a freeze exception!. [2] https://lists.debian.org/debian-devel-announce/2012/11/msg3.html Now I am sorry, if I managed all this situation the wrong way, but I felt it would have been a shame to postpone the accumulated changes until after the wheezy release... :-( Thanks for your patience. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpRpGO399yKO.pgp Description: PGP signature
Bug#690461: RM: freecad/0.12.5284-dfsg-7
On Sun, 14 Oct 2012 16:31:21 +0100 Ben Hutchings wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm Hello Ben! freecad contains GPLv2 code and links with a GPL-licensed library (Coin3D) and links to OCTPL (non-GPL-compatible) libraries (bug #617613)/ True. This is supposed to be fixed soon as there is a new version of libopencascade under a BSD licence http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=617613#153. No, wait: this does not look correct, unfortunately! There is no re-licensing under the BSD for OpenCASCADE Technology going on (I wish there were!!!). Please re-read the message you cited: it's Coin3D that was re-licensed under the BSD. Once FreeCAD links with this BSD-licensed Coin3D version and stops incorporating any GPL-licensed code, *at that point* FreeCAD will be able to legally link with the still GPL-incompatible OpenCASCADE Technology framework, without any distribution issue. Not an ideal solution, but still a solution... Since the relicensed libopencascade s/libopencascade/libcoin/ is not available in Debian and probably will not get into wheezy, I think freecad should be removed from stable and testing. This is what I wanted to avoid: I have struggled since April 2009 in order to persuade OpenCASCADE S.A.S. to re-license the OpenCASCADE Technology framework under GPL-compatible terms... Unfortunately no result has been obtained yet.:-( In the meanwhile, the (suboptimal) solution described above (FreeCAD that links with no GPL-licensed code and incorporates no GPL-licensed code, in order to be able to link with GPL-incompatible code) has been devised and is being implemented. I don't know whether this is enough to grant a wheezy-ignore tag to bug #617613... Bye. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpWgHIimT5Es.pgp Description: PGP signature
Bug#689204: unblock: apt-listbugs/0.1.8
On Mon, 01 Oct 2012 10:36:01 +0200 Niels Thykier wrote: [...] Unblocked, thanks. Thanks to you for processing my request so promptly! Rest assured that this is very appreciated. Bye. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpfuktqOvFTT.pgp Description: PGP signature
Bug#689204: unblock: apt-listbugs/0.1.8
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package apt-listbugs As can be seen with the following command on the git repository: $ git diff apt-listbugs/0.1.7..apt-listbugs/0.1.8 | filterdiff \ --exclude='*.po' --exclude='*.pot' the only non-l10n changes from version 0.1.7 are: * i18n fixes and enhancements * English improvements and clarifications in translatable strings and in the documentation (discussed on the debian-l10n-english mailing list) * a dependency adjustment, done to drop a transitional package (libgettext-ruby1.8 replaced by ruby-gettext) I am attaching the output of the above command. Please also take a look at the git repository, in case you want to review the changes organized in commits: http://anonscm.debian.org/gitweb/?p=apt-listbugs/apt-listbugs.git;a=shortlog Thanks for your time! unblock apt-listbugs/0.1.8 -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (800, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash apt-listbugs_017_018.diff.gz Description: GNU Zip compressed data
Re: Kernel Firmware issue: are GPLed sourceless firmwares legal to distribute ?
On Wed, 18 Oct 2006 13:06:19 +0100 Stephen Gran wrote: This one time, at band camp, Don Armstrong said: [...] baring competent legal advice to the contrary,[1] distributing sourceless GPLed works is not clear of legal liability. Doing otherwise may put ourselves and our mirror operators in peril. I think the argument here revolves around whether the GPL is a contract to our users, or a license from the copyright holders. If it is a license from the copyright holders, than the only ones who can sue Debian for distribution of sourceless GPL'ed works are, er, the people who originally gave out those works in that form. I understand there is some contention around whether this claim is accurate (and I claim no deep understanding of international copyright and contract law to make a claim for either side), but I think that is the fairly simple counter argument. How so? Let's assume that *only* copyright holders can sue the Debian Project and mirror operators (whether this is true or false is irrelevant for this discussion). What makes you think that every and each copyright holder acted in good faith when started to distribute firmware under the terms of the GNU GPL v2, while keeping the source code secret? Some copyright holder could be deliberately preparing a trap, in order to be able to sue at whim, whenever he decides he wants to. Moreover, maybe the undistributability could be intended: some copyright holder could have intentionally chosen the GNU GPL v2, while retaining source code, in order to be the *only one* legally allowed to distribute that firmware (you know, forcing users to visit his website and stuff like that...). Or even worse, who says that the copyright holder is actually aware that the firmware is distributed inside a GPL'd driver? In some cases, the firmware blob could be included in the driver without retaining proper copyright and permission notices. The blob could *appear* to be GPL'd, while it's not. Hope that helps. -- But it is also tradition that times *must* and always do change, my friend. -- from _Coming to America_ . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpsSEcTTVMRF.pgp Description: PGP signature
Re: Problems with ntp
On Wed, 14 Sep 2005 00:03:36 -0700 Steve Langasek wrote: What are you going to replace it with? AFAIK, ntp is the only package we have in Debian which supports useful clock synchronization, which is essential for a number of other services (e.g., Kerberos). Isn't chrony a possible replacement? It conflicts with ntp, among other things... -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpZ6Tyl2wzDx.pgp Description: PGP signature
