Re: Bug#682719: Your gcl 2.6.7-107 upload
On Mon, 2012-10-08 at 19:22 +0200, Philipp Kern wrote: Camm, am Mon, Oct 08, 2012 at 12:02:52PM -0400 hast du folgendes geschrieben: Greetings! This was in line of addressing #682719. I was under the impression that the emacsen would cover the absence of emacs24. emacs24's forced in from unstable if no emacsen is installed yet. The bug you cited does talk about *build dependencies* and about putting it as a less-preferred build alternative (which is entirely bogus by itself, i.e. the bug report's resolution suggesting is *wrong*, because the buildd infrastructure will not consider such alternatives). In gcl you changed the binary package's *dependency* specification. Regarding the emacs23 | emacs24 dependency I thought emacs24 would enter testing. Obviously it did not make it in time. And the patch I submitted was for acl2, not gcl. Nevertheless, why build-depend on a non-existing package emacsen with emacs23 | emacsen? Additionally, it looks like emacs24 is not the default for unstable, why not? It should be for testing yes, but unstable? -- 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/1349726581.4330.23.camel@x60
Re: Bug#682719: Your gcl 2.6.7-107 upload
On Mon, 2012-10-08 at 21:10 +0100, Adam D. Barratt wrote: [recipient list trimmed, although it should probably be even smaller] On Mon, 2012-10-08 at 22:03 +0200, Svante Signell wrote: Nevertheless, why build-depend on a non-existing package emacsen with emacs23 | emacsen? It does exist, in exactly the same way that e.g. mail-transport-agent apt-cache show emacsen N: Can't select versions from package 'emacsen' as it is purely virtual N: No packages found apt-cache showsrc emacsen W: Unable to locate package emacsen N: No packages found Same with mail-transport-agent, I am probably missing something. Where is it? -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1349729976.4330.25.camel@x60
Re: Bug#682719: Your gcl 2.6.7-107 upload
On Mon, 2012-10-08 at 22:00 +0100, Adam D. Barratt wrote: On Mon, 2012-10-08 at 22:59 +0200, Svante Signell wrote: On Mon, 2012-10-08 at 21:10 +0100, Adam D. Barratt wrote: On Mon, 2012-10-08 at 22:03 +0200, Svante Signell wrote: Nevertheless, why build-depend on a non-existing package emacsen with emacs23 | emacsen? It does exist, in exactly the same way that e.g. mail-transport-agent apt-cache show emacsen N: Can't select versions from package 'emacsen' as it is purely virtual [...] Same with mail-transport-agent, I am probably missing something. Yes, you are. The wording of the error message should give you a clue OK, I confess I'm stupid. can't select versions from package does mean nothing to me, unfortunately. Looks like I'm not debianised enough yet :( Even after using debian for some 10+ years! -- 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/1349731588.4330.36.camel@x60
cdimage.debian.org down?
Hi, Title says it all. Where to find weekly built netinst isos (or unstable)? -- 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/1345061939.25812.1.ca...@hp.my.own.domain
Re: Possibility of getting an up-to-date version of Wine into Squeeze
Please take this request seriously. Even if Squeeze is frozen, distributing the same version (1.0.x) of Wine as Lenny does not look good! People are trying to help out! -- 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/1282352478.3623.41.ca...@hp.my.own.domain
[Fwd: Re: hurd-i386 qualification for Wheezy]
Looks like group reply in my mailer means reply only to the mailing list I have defined a filter for? Anyway, forwarding to debian-release too. Forwarded Message From: Svante Signell svante.sign...@telia.com Reply-to: Svante Signell svante.sign...@telia.com To: debian-h...@lists.debian.org Subject: Re: hurd-i386 qualification for Wheezy Date: Thu, 24 May 2012 19:30:47 +0200 On Thu, 2012-05-24 at 18:08 +0100, Adam D. Barratt wrote: On 19.05.2012 19:04, Adam D. Barratt wrote: Very quickly following up on a possible nomenclature issue and a couple of other things. On Sat, 2012-05-19 at 17:29 +0200, Samuel Thibault wrote: - We of course aim at tech preview for wheezy only, not a full release. Our goal is to establish a testing distribution for wheezy which does not block others ports (i.e. so-called fuckedarch), and get a full testing for wheezy+1. That's not what the phrase tech preview was used to mean for kfreebsd-* at least. [...] I'm not sure we've ever released with an architecture which was in either broken or fucked, but hopefully someone will correct me if I'm mistaken on that. Anyone? :-) Opinions as to whether it makes sense to release an architecture in either of those states would also be welcome. Is there a definition of what broken and fucked means, so this could be related to. Also, is tech preview defined somewhere. Were there any descriptions made/discussions when kFreeBSD was introduced for Squeeze? -- 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/1337880927.8802.200.ca...@s1499.it.kth.se
Re: Accepted gcc-defaults 1.118 (source all amd64)
On Sat, 2012-05-26 at 19:39 +0200, Julien Cristau wrote: On Sun, May 13, 2012 at 19:56:15 +0200, Matthias Klose wrote: sorry, thinko. I did mean End of May. So we're at the end of May. Can we have that revert now, or do I need to NMU? Stop nagging about the default gcc compiler for wheezy. Right now it is gcc-4.7, and problems will be resolved in due time for the release. -- 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/1338065890.3547.2.camel@x60
Re: Accepted gcc-defaults 1.118 (source all amd64)
On Sat, 2012-05-26 at 23:51 +0200, Philipp Kern wrote: Svante, am Sat, May 26, 2012 at 10:58:10PM +0200 hast du folgendes geschrieben: On Sat, 2012-05-26 at 19:39 +0200, Julien Cristau wrote: On Sun, May 13, 2012 at 19:56:15 +0200, Matthias Klose wrote: sorry, thinko. I did mean End of May. So we're at the end of May. Can we have that revert now, or do I need to NMU? Stop nagging about the default gcc compiler for wheezy. Right now it is gcc-4.7, and problems will be resolved in due time for the release. sorry to annoy you but nagging about problems of the upcoming release is actually our job description. So no, we won't stop just because you're telling us to, just with solid reasons instead of handwaving about it all going away because you say so. It's a hell lot of work it's causing. Nobody's saying anything against having gcc-4.7 as an option. Philipp, With all due respect, So far I have not seen any bug report causing the gcc-4.7 as default compiler being serious enough to make it reverted. Name the problematic bugs then, please. And, where is the big problem, please explain? -- 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/1338072725.3547.10.camel@x60
Re: Accepted gcc-defaults 1.118 (source all amd64)
On Sun, 2012-05-27 at 08:34 +0200, Yves-Alexis Perez wrote: On dim., 2012-05-27 at 00:52 +0200, Svante Signell wrote: On Sat, 2012-05-26 at 23:51 +0200, Philipp Kern wrote: ... With all due respect, So far I have not seen any bug report causing the gcc-4.7 as default compiler being serious enough to make it reverted. Name the problematic bugs then, please. And, where is the big problem, please explain? You mean something like http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-gcc-4.7;users=debian-...@lists.debian.org ? Looks like the list of bugs for gcc-4.7 is quickly diminishing. Most remaining have patches or are pending upload. Looks like most problems was missing inclusion of unistd.h or some symbols no longer visible. -- 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/1338283918.8802.266.ca...@s1499.it.kth.se
Re: hurd-i386 qualification for Wheezy
On Wed, 2012-05-30 at 09:53 +0100, Neil McGovern wrote: On Thu, May 24, 2012 at 06:08:16PM +0100, Adam D. Barratt wrote: On 19.05.2012 19:04, Adam D. Barratt wrote: I'm not sure we've ever released with an architecture which was in either broken or fucked, but hopefully someone will correct me if I'm mistaken on that. Anyone? :-) Opinions as to whether it makes sense to release an architecture in either of those states would also be welcome. I do not think it is sensible to release an architecture that is in broken/fucked. That's what something like debian ports is for. In order to release hurd, even as a tech preview, we need hurd in testing and users actually testing it. This is a problem at this stage because: An almost up-to-date web page about GNU/Hurd is available at: http://wiki.debian.org/Debian_GNU/Hurd * there isn't a functional D-I port yet It work perfectly well as far as I know. There are still bugs to be handled by the DMs, for example grub2: #670069, #634799, #670186, #670189 * it doesn't support debian style networking (ifupdown etc) ifupdown is supported, see wnpp bug #672212 * it doesn't support any meaningful available new hardware (USB, SATA) SATA support is in the works. * its archive coverage is far lower than required What is required, currently the percentage is 77%. How large was it when kFreeBSD was released as a tech preview in Squeeze. Take a look at the bug page, to find out how the percentage could increase: http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-h...@lists.debian.org;tag=hurd; 39 important bugs with patches 14 normal bug with patches 7 forwarded important and normal bugs 4 bugs pending uploads etc The introduction of GNU/Hurd in testing is not only in the hands of the porters. -- 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/1338369264.8802.329.ca...@s1499.it.kth.se
Re: hurd-i386 qualification for Wheezy
On Wed, 2012-05-30 at 11:23 +0200, Samuel Thibault wrote: Svante Signell, le Wed 30 May 2012 11:14:24 +0200, a écrit : * its archive coverage is far lower than required What is required, currently the percentage is 77%. No, it is rather 76%. It would be interesting to know how large the percentage would be if all the pending bugs were attended (and including mono, that one is in the works). Is it possible to derive an estimate? -- 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/1338370284.8802.334.ca...@s1499.it.kth.se
Re: hurd-i386 qualification for Wheezy
On Wed, 2012-05-30 at 11:34 +0200, Samuel Thibault wrote: Svante Signell, le Wed 30 May 2012 11:31:24 +0200, a écrit : On Wed, 2012-05-30 at 11:23 +0200, Samuel Thibault wrote: Svante Signell, le Wed 30 May 2012 11:14:24 +0200, a écrit : * its archive coverage is far lower than required What is required, currently the percentage is 77%. No, it is rather 76%. It would be interesting to know how large the percentage would be if all the pending bugs were attended (and including mono, that one is in the works). Is it possible to derive an estimate? Since there are about 1 source packages, it's almost exactly 0.01% per fixed package (plus reverse dependencies). The tricky part are the reverse dependencies, e.g. how many more packages will build when the psmisc bug, #673485, is closed? Can this be derived with the aid of http://people.debian.org/~sthibault/graph-top.txt or http://people.debian.org/~sthibault/graph-total-top.txt -- 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/1338370977.8802.339.ca...@s1499.it.kth.se
Re: Re: Architecture qualification
On 28/05/12 01:52, Steven Chamberlain wrote: On 29/05/12 19:57, Andreas Barth wrote: [...] 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. Maybe that's all that's needed? The recent enthusiasm sounds to me like an opportunity. An official testing suite in the archive, from which usable installer images can be built, could be what encourages hurd-i386 to progress into something really releasable. If this doesn't happen now while there's some momentum, it might never happen again and that would be a shame. From the one of the porters side, this would be a _very_ good solution indeed! If GNU/Hurd enters som kind of testing status, the number of users and contributors will increase (hopefully). Can it be part of testing and then when the release happens, be treated specially? And most packages will be located in the main repo, only the packages having patches, not yet handled by the DMs, being there. Is that possible? BTW: Are builds reported to buildd.debian.org already, it is visible ate least in the table on https://buildd.debian.org/, or maybe Samuel meant something else. -- 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/1338473910.8802.453.ca...@s1499.it.kth.se
Re: Re: Architecture qualification
On Thu, 2012-05-31 at 16:18 +0200, Svante Signell wrote: On 28/05/12 01:52, Steven Chamberlain wrote: On 29/05/12 19:57, Andreas Barth wrote: [...] 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. Maybe that's all that's needed? The recent enthusiasm sounds to me like an opportunity. An official testing suite in the archive, from which usable installer images can be built, could be what encourages hurd-i386 to progress into something really releasable. If this doesn't happen now while there's some momentum, it might never happen again and that would be a shame. From the one of the porters side, this would be a _very_ good solution indeed! If GNU/Hurd enters som kind of testing status, the number of users and contributors will increase (hopefully). Can it be part of testing and then when the release happens, be treated specially? And most packages will be located in the main repo, only the packages having patches, not yet handled by the DMs, being there. Is that possible? BTW: Are builds reported to buildd.debian.org already, it is visible ate least in the table on https://buildd.debian.org/, or maybe Samuel meant something else In my world it is considered polite to answer questions asked. Even if you don't have the time to reply properly, just say so. I'm still waiting for some kind of feedback, especially the questions. I assume this is not a regular mail correspondence, is it? -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1338589334.5450.165.ca...@hp.my.own.domain
Re: Re: Architecture qualification
On Mon, 2012-06-04 at 10:56 +0100, Neil McGovern wrote: I assume this is not a regular mail correspondence, is it? I generally consider it polite to give people an opportunity to respond before assuming that you're being ignored, especially if it's part of a longer thread. Maybe three days is a little short for a mailing list correspondence. As per my previous mail, I will not be adding hurd to testing for this release. It would affect the release as a whole, and I'm not happy doing that. Ok, understood. So getting into testing after the release of Wheezy is a more resonable target. Just a small remark, two (three) of the four reasons for not adding Hurd to testing was shown false. D-I OK, ifupdown OK, SATA support in the works, the major obstacle seems to be the still too low package count. One issue is how to encourage more people trying Hurd out, when it is not in testing. It is very easy to install, e.g. in a VM, and there are a number of public Hurd boxen for DMs, DDs, upstream and everybody interested as well, http://www.gnu.org/software/hurd/public_hurd_boxen.html -- 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/1338805550.5450.192.ca...@hp.my.own.domain
Re: Architecture qualification
On Mon, 2012-06-04 at 13:23 +0200, Holger Levsen wrote: Hi, On Montag, 4. Juni 2012, Svante Signell wrote: One issue is how to encourage more people trying Hurd out, when it is not in testing. I honestly don't think that's the main blocker trying out hurd. Lack of SATA, and USB support are the blocker, I think. Might be so, yes. And probably also missing meaningful graphics output puts many people off. Do you mean gnome3 and KDE4/5 here, or maybe DRM? Having SATA (or whatever feature) in the works is also meaningless, as hurd is in the works for years. No, this time the work is based on the DDE framework, recently successfully implemented for network drivers. Ask Samuel Thibault for more details if interested, he is the person in charge. BTW: USB support might also be possible within the DDE framework. -- 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/1338816345.8802.500.ca...@s1499.it.kth.se
Re: Hurd and the archive
On Mon, 2013-05-06 at 21:47 +0100, Steven Chamberlain wrote: Hi Samuel, On 06/05/13 21:35, Samuel Thibault wrote: Steven Chamberlain, le Mon 06 May 2013 21:20:57 +0100, a écrit : In that case would there be 150-200 RC-severity bugs introduced right away by its inclusion? I would rather say simply dropping them, as already requested in Bug#704477. And as I said a fair amount of these are actually already submitted as general FTBFS bugs or upgrade libtool bugs. If it's possible, yes outdated versions could be removed... and then look again at those figures. But it would need to happen pretty soon. Add to these numbers the large amount of bug reports _with_ patches not being handled during the long freeze time for Wheezy, see (note this list is not exhaustive, e.g. some patched packages are in experimental) bugs.debian.org/cgi-bin/pkgreport.cgi?tag=hurd;users=debian-h...@lists.debian.org 1 serious 49 important 4 normal (1 wontfix) 2 wishlist 10 forwarded important 3 pending upload important etc. Let's do the calculation of the coverage percentage when these bugs have been attended to (and the outdated ones removed as above). Why do you expect anything to be different now compared when the freeze happened, _several months ago_, in zero time? -- 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/1368109546.4595.14.camel@PackardBell-PC
Re: Hurd and the archive
On Thu, 2013-05-09 at 16:39 +0200, Samuel Thibault wrote: Svante Signell, le Thu 09 May 2013 16:25:46 +0200, a écrit : Why do you expect anything to be different now compared when the freeze happened, _several months ago_, in zero time? Please avoid this level of language, it can't bring anything good to the discussion. Maybe the wording was a little strong, sorry for that. The meaning of the mail was to give a link to facts, and give room for things to happen before making a decision. What's the reason for such a hurry? Wheezy has just been released, thanks everybody :) Maybe the maintainers should be given some slack as pointed out by earlier posts (not including the GNU/Hurd ones) -- 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/1368118446.4595.33.camel@PackardBell-PC
[Fwd: Debian GNU/Hurd 2013 released!]
FYI! ---BeginMessage--- This is now published on http://www.debian.org/ports/hurd/hurd-news.en.html http://www.gnu.org/software/hurd/news/2013-05-debian_gnu_hurd_2013.html Please spread the news :) Samuel -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130521232449.gz6...@type.youpi.perso.aquilenet.fr ---End Message---
Re: Roll call for porters of architectures in sid and testing
On Sun, 2013-09-01 at 09:33 +0200, Niels Thykier wrote: Hi, I am an active porter for the following architectures and I intend to continue this for the lifetime of the jessie release: For hurd-i386, I - test most packages on this architecture - fix toolchain issues - triage arch-specific bugs - fix arch-related bugs I am a not (yet) a DM/DD Svante Signell -- 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/1379596145.5825.104.ca...@s1499.it.kth.se
Re: Roll call for porters of architectures in sid and testing
On Thu, 2014-03-06 at 04:20 +0100, Guillem Jover wrote: Hi! On Tue, 2013-10-01 at 00:49:17 +0200, Guillem Jover wrote: I am an active porter for the following architectures and I intend to continue this for the lifetime of the jessie release: (about kfreebsd and hurd) I am a DD. Please, consider the above commitments rescinded. Thanks a lot for your work and professional feedback. Sorry to see you leave Debian and look forward to see you as upstream provider. Verbatim from a mail to debian-hurd: I've been progressively scaling down my involvement in Debian (due to continued dissatisfaction with the project), and given that I've not been very active maintaining GNU/Hurd packages since the switch of the packaging to git (as I find maintaining packaging with full upstream sources in the same repo slightly annoying), but mostly because Samuel has been doing excellent work anyway so I didn't need to do anything :), I thought it would be proper to make the records match reality, so I'm leaving the team. I just removed myself from Uploaders from the gnumach and mig packages, from the web site [O] and from the debian-hurd and pkg-hurd alioth projects, for which I was still admin. [O] http://www.debian.org/intro/organization I probably will still be lurking around, and might show up in the upstream lists or here from time to time, though. Amazing that no-one from Debian side have noticed you are phasing yourself out. Well, maybe other distros can be potential new Debian replacements. Currently I'm staying, but if something better pops up, I'll switch faster than light (including kfreebsd and hurd of course) -- 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/1394219026.25425.52.ca...@g3620.my.own.domain
Re: Re-evaluating architecture inclusion in unstable/experimental
On Sun, 2018-09-02 at 19:46 +0200, Samuel Thibault wrote: > Svante Signell, le dim. 02 sept. 2018 19:45:19 +0200, a ecrit: > > On Sun, 2018-09-02 at 15:21 +0200, Samuel Thibault wrote: > > > > > > > > > The statistics and graphs available on the debian-ports page[1] may > > > > provide some objective statistics or reflection on the actual > > > > suitability of your architecture's continued inclusion. > > > > [1]: https://buildd.debian.org/stats/ > > > > > > Such statistics are really difficult to get any real conclusion from. > > > Sometimes 10% packages are missing just for one tricky nonLinux-specific > > > issue in one package. > > > > Correct: One example is cmake for both hurd-i386 and kfreebsd-any. > > It does not even have to be tricky. > > If it's not tricky, a NMU should be able to fix it easily. I'm sorry Samuel, I asked both you and James Clarke, Cc:ed, for help on this issue and you both said it was not possible to NMU cmake, even if you are both DD's. See bugs https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905140 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900240 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905138 I think that the power of a package maintainer is far too big, making it possible to reject/ignore important and other bugs, especially with patches, for non-released architectures (and effectively block NMUs). I think the next step would be to bring the responsibilities and commitments of a Package Maintainer to the TC, in addition to the full control of everything related to that package. Maybe the recent salvaging of packages could be helpful in the future regarding this problem.
Re: Re-evaluating architecture inclusion in unstable/experimental
On Mon, 2018-09-03 at 01:07 +0200, Samuel Thibault wrote: > > > So has the debian patch been submitted in #900240 upstream by you or Petter > > Reinholdtsen yet? I don't believe so! > > I don't think so either, it'd be marked forwarded. That doesn't mean you > can't help with it. Regardless who is submitting patches upstream, two problem remains: 1) The delay until upstream makes a new release. 2) The delay until the Debian Maintainer creates an updated package from that release (if ever). Example: emacs26 And how many maintainers do cherry-pick patches accepted upstream, very few :(
Re: Re-evaluating architecture inclusion in unstable/experimental
On Sun, 2018-09-02 at 15:21 +0200, Samuel Thibault wrote:
>
> > The statistics and graphs available on the debian-ports page[1] may
> > provide some objective statistics or reflection on the actual
> > suitability of your architecture's continued inclusion.
> > [1]: https://buildd.debian.org/stats/
>
> Such statistics are really difficult to get any real conclusion from.
> Sometimes 10% packages are missing just for one tricky nonLinux-specific
> issue in one package.
Correct: One example is cmake for both hurd-i386 and kfreebsd-any.
It does not even have to be tricky. For kfreebsd the patch(es) is attached
below!
Index: cmake-3.11.2/bootstrap
===
--- cmake-3.11.2.orig/bootstrap
+++ cmake-3.11.2/bootstrap
@@ -1352,7 +1352,7 @@ else
libs="${libs} -ldl -lrt"
;;
*BSD*)
- libs="${libs} -lkvm"
+ libs="${libs} -lkvm -lfreebsd-glue"
;;
*SunOS*)
# Normally libuv uses '-D_XOPEN_SOURCE=500 -std=c90' on Solaris 5.10,
--- a/debian/control 2018-05-19 10:51:17.0 +0200
+++ b/debian_control 2018-07-29 17:38:11.272777000 +0200
@@ -15,6 +15,7 @@
librhash-dev,
libuv1-dev (>= 1.10),
procps [!hurd-any],
+ freebsd-glue [kfreebsd-any],
python3-sphinx,
qtbase5-dev ,
zlib1g-dev
Re: Re-evaluating architecture inclusion in unstable/experimental
On Mon, 2018-09-03 at 00:19 +0200, Samuel Thibault wrote: > > > I'm sorry Samuel, I asked both you and James Clarke, Cc:ed, for help on this > > issue and you both said it was not possible to NMU cmake, even if you are > > both > > DD's. > > For my part, I was not talking about that patch, but about the > hurd-related patches. > > For others, I can simply quote what was said: > > Felix Geyer wrote: > > I suggest that instead you respond to questions on bugs you opened. > > I'm not interested in maintaining patches for things that clearly > > belong upstream. Once upstream has reviewed the changes I'm happy to > > cherry-pick them. This is a comment on the Hurd bug, #900200, not the kfreebsd one, #905138. And I did not open that bug, you did! > And I agree with it (and also one of the reasons why I didn't just > NMU-ed cmake with the hurd patch). So has the debian patch been submitted in #900240 upstream by you or Petter Reinholdtsen yet? I don't believe so!
Bug#934132: Processed: #934132: Raise severity to important
On Fri, 2019-08-09 at 11:41 +0100, Adam D. Barratt wrote: > Control: severity -1 normal > > On 2019-08-09 11:33, Debian Bug Tracking System wrote: > > Processing commands for cont...@bugs.debian.org: > > > > > severity 934132 important > > Bug #934132 [release.debian.org] unblock: elogind/241.3-1+debian1 > > Severity set to 'important' from 'normal' > > No. release.d.o bugs are normal at most unless the team decide > otherwise. Please leave them like that. Might be so. But explain why this package is still blocked, buster was released several weeks ago!
Bug#934132: Processed: #934132: Raise severity to important
On Fri, 2019-08-09 at 12:06 +0100, Jonathan Wiltshire wrote: > On Fri, Aug 09, 2019 at 12:55:02PM +0200, Svante Signell wrote: > > On Fri, 2019-08-09 at 11:41 +0100, Adam D. Barratt wrote: > > > Control: severity -1 normal > > > > > > On 2019-08-09 11:33, Debian Bug Tracking System wrote: > > > > Processing commands for cont...@bugs.debian.org: > > > > > > > > > severity 934132 important > > > > Bug #934132 [release.debian.org] unblock: elogind/241.3- > > > > 1+debian1 > > > > Severity set to 'important' from 'normal' > > > > > > No. release.d.o bugs are normal at most unless the team decide > > > otherwise. Please leave them like that. > > > > Might be so. But explain why this package is still blocked, buster > > was > > released several weeks ago! > > Because it's nothing to do with buster. We're working on bullseye > now. So elogind has been excluded from the bullseye release? Maybe you can explain that decision.
