Bug#844196: ITP: ufo-filters -- Set of plugins for ufo-core
Package: wnpp Owner: picca Severity: wishlist * Package name: ufo-filters Version : 0.11.0 Upstream Author : matthias.vogelges...@kit.edu * URL or Web page : http://ufo.kit.edu/ * License : LGPL-3+ Description : Set of plugins for ufo-core The UFO data processing framework is a C library suited to build general purpose streams data processing on heterogeneous architectures such as CPUs, GPUs or clusters. It is extensively used at the Karlsruhe Institute of Technology for Ultra-fast X-ray Imaging (radiography, tomography and laminography). . This package contains `average', `backproject', `bin', `blur', `buffer', `calculate', `camera', `clip', `contrast', `crop', `denoise', `duplicate', `fftmult', `fft', `filter', `flatten', `flip', `forwardproject', `gemm', `ifft', `interpolate', `loop', `measure', `merge', `metaballs', `monitor', `null', `opencl', `ordfilt', `pad', `read', `reduce', `refeed', `replicate', `rescale', `ringwriter', `sleep', `slice', `stack', `stdin', `stdout', `subtract', `transpose', `write' and `zeropad' plugins.
Bug#844197: ITP: r-cran-rgeos -- GNU R interface to geometry engine
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-cran-rgeos Version : 0.3-21 Upstream Author : Roger Bivand * URL : https://cran.r-project.org/package=rgeos * License : GPL Programming Lang: GNU R Description : GNU R interface to geometry engine This GNU R package provides an Interface to the Geometry Engine - Open Source (GEOS) using the C API for topology operations on geometries. Remark: This package is needed to run the unit tests for r-cran-sp. It willl be maintained by the Debian Med team at svn://anonscm.debian.org/debian-med/trunk/packages/R/r-cran-rgeos/trunk/
Re: More 5 november in the release schedule [and 1 more messages]
On Thu, 10 Nov 2016 08:26:46 +0100, Christoph Biedl wrote: >Finally, there's a thing called "trust": I trust the Release Team does >this solely in order to keep the freeze time as short as possible, >everybody hates that time anyway. This trust was created by the very >people behind it, and the way they acted in the past months. This is exactly the problem I have with the current policy: I fail to see why this measure will shorten the freeze. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: More 5 november in the release schedule [and 1 more messages]
On Thu, 10 Nov 2016 10:17:57 +0100, Emilio Pozuelo Monfort wrote: >And yes, we will give exceptions on a case by case basis, as we have always >done. This will create a third class of packages: The ones that are not important enough to get an exception, which will in turn demotivate package maintainers even more. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Archive changes - indices compression and checksums
On Sat, Nov 12, 2016 at 01:52:20PM +0100, Joerg Jaspert wrote: >Hi > >as started in March[1] we have just adjusted unstable to no longer >generate gzip compressed Packages/Sources files. We plan to wait about a >week before adjusting testing too. > >Additionally we turned off SHA1 checksums for the (In)Release files for >all testing suites. I understand the desire to add functionality, but can you explain why you're removing the older formats? It's breaking other tools, and I'm not convinced there's much benefit... -- Steve McIntyre, Cambridge, UK.st...@einval.com Can't keep my eyes from the circling sky, Tongue-tied & twisted, Just an earth-bound misfit, I...
Re: More 5 november in the release schedule [and 1 more messages]
Marc Haber wrote... > This is exactly the problem I have with the current policy: I fail to > see why this measure will shorten the freeze. I don't. But I'd say we'll just watch what's going to happen and resume this discussion once stretch is released. Chri- "somewhen December 2017" stoph signature.asc Description: Digital signature
Re: More 5 november in the release schedule
On Tue, 8 Nov 2016 11:05:59 +0100, Christian Seiler wrote: >Yes, especially since autoremovals are not instantaneous, but for >packages with rdeps (and the rdeps themselves) will happen at >least 30 days in the future - and you will get an email in time. >(For packages without rdeps it's 15 days. Plus IIRC a week delay >after a bug was initially marked RC before autoremoval is even >triggered, but I might be wrong about that last part.) > >30 days within the deep freeze should be plenty enough I would feel a lot less uncomfortable if the teams who are using automated tools to auto-file RC bugs for third-rate policy violations which will auto-remove a (99,99% of the cases) perfectly working package from testing in a time where a maintainer would probably not dare to touch his maintainer scripts for fear of creating a really RC bug which will in turn get the package auto-removed from testing would refrain from doing their auto-foo during the freeze. I do appreciate automated tests, and while I think it can be discussed whether the policy violations found by those automatic tests need to be RC, I firmly believe that these tools should not be used as a weapon against packages. >- and as I >said: if the problem is more complicated, just talk to the release >team _while the package is still in testing_. So you want people to beg if they want their packages in testing. What is that going to help, aside from demotivating and humiliating people? >The goal of autoremovals is to provide an incentive for people >to deal with problems in their packages _early_. Managerspeak. Even at work I hate people who talk about giving "incentives" while they actually threaten. >And as I said previously: if a maintainer of a dependency of yours >doesn't care: NMUs for RC bugs have a far lower threshold - even >0-day NMUs are possible if the maintainer is really completely >asleep. (DevRef 5.11.1) So this is a method to force people to take additional responsibilities for dependencies as well in addition to the responsibilities they have taken voluntarily? Well, _this_ will clearly motivate people. Greetings Ma "not." rc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: More 5 november in the release schedule
On Thu, 10 Nov 2016 08:36:21 +0100, Ole Streicher wrote: >Wouter Verhelst writes: >> On Tue, Nov 08, 2016 at 11:05:59AM +0100, Christian Seiler wrote: >>> 30 days within the deep freeze should be plenty enough - and as I >>> said: if the problem is more complicated, just talk to the release >>> team _while the package is still in testing_. >> >> Let's say I'm on holiday (or I get hit by a bus and end up in hospital, >> or I get a major project at work which eats up all my time, or whatnot) >> and I don't notice for a while that a package that I maintain gets an RC >> bug. The automated machinery throws the package out before I have time >> to work on the package again. Now what? > >This is a good argument for team maintenance. :-) Why is Libreoffice not team maintained, for example? Where is the KDE team doing bug triaging? There are less important packages where the maintainer has been searching for help to work in a team for years without success. And instead of relieving those people, they now get responsible for their dependencies as well if their maintainers are overworked as well if they want their packages to be in stretch. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: More 5 november in the release schedule
On Thu, 10 Nov 2016 07:37:00 +, Niels Thykier wrote: > * As James noted; sending an update to the bug will reset the timer. Did I miss the documentation about this? It does not seem to be in the freeze policy. > * Also, if you do not have time for a given bug, please consider > tagging it "help", so your fellow contributors know that you need > help. That tag shows up on all RC bugs views I know of. How many bugs tagged help actually go get help? > * For more extreme cases (death, mowed by bus, sudden long term > illness, etc), the replacement maintainer can ask for an exception. > (per [freeze policy]) That'll hold for less than a percent of the removals. >""" >The release managers may make exceptions to these guidelines as they see >fit. *Such exceptions are not precedents and you should not assume that >your package has a similar exception*. Please talk to us if you need >guidance. >""" >(Emphasis from original - 3rd paragraph from the top) This is a quite nice opportunity to say something like "you haven't been nice enough to us in the past or you have dared to speak up when you didn't like what we did, so you're free to take a hike with your package, have a nice day". I find that unnecessarily humiliating and will probably not do this and rather live without my package in stable for this release. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: More 5 november in the release schedule
On Wed, 9 Nov 2016 14:01:13 +, Ian Jackson wrote: >If it turns out to be a more common problem and there are many >packages affected, then this would mean delays to the stretch release, >indeed. One of my issues is that this new policy means a switch from "we'll release when it's ready" to "we'll sacrifice package list completeness of our release for a timely release", which is a rather radical change. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: More 5 november in the release schedule
On Wed, 9 Nov 2016 19:45:02 +0100, gregor herrmann wrote: >I don't quite understand where all this fuzz about auto-removals >suddenly comes from. The auto-removals exist since Septemer 2013 [0] >and they were also in place for the jessie freeze [1], with the small >difference that now the point-of-no-return is a month before the hard >freeze, and in jessie it started with the hard freeze. If the jessie release actually had a point-of-no-return, then it was this seldomly and/or silently enforced that I totally missed it. I don't have anything against autoremovals, I am strongly opposed against the "once you're out, you'll stay out" since I fail to see the advantages of this approach aside from "giving incentives". For me, this "incentive" will most likely have the opposite result. Greetings Marc, who is about to stop caring just a bit more -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: More 5 november in the release schedule
Marc Haber, on Sun 13 Nov 2016 11:30:18 +0100, wrote: > On Wed, 9 Nov 2016 14:01:13 +, Ian Jackson > wrote: > >If it turns out to be a more common problem and there are many > >packages affected, then this would mean delays to the stretch release, > >indeed. > > One of my issues is that this new policy means a switch from "we'll > release when it's ready" to "we'll sacrifice package list completeness > of our release for a timely release", which is a rather radical > change. We have always had to sacrifice packages to get something released. You can't release 10,000 packages at the same time if you don't make sacrifices. It just has moved from "arbitrary" to "not maintain closely enough". Samuel
Re: More 5 november in the release schedule
On Sun, 6 Nov 2016 13:06:33 +0200, Lars Wirzenius wrote: >I'm even willing to justify my opinion: Keeping testing in a state >that can be released seems to be the only way in which we can make a >release in a reasonable time frame. We've tried several other >approaches, which haven't worked. The approach of "let's freeze and >then try to fix things" didn't work. Let's not try it again. I do not think that it is a service to our users to release an incomplete distribution just for the sake of keeping a date. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: More 5 november in the release schedule
On Sun, 06 Nov 2016 11:51:36 +, Steve McIntyre wrote: >Releasing Debian is work for all of us, not just the Release Team... So you are actually suggesting that people who are neither on the release team nor maintaining a key package are not working? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Bug#844204: ITP: node-grunt-contrib-clean -- Used to clean files and folders in Grunt
Package: wnpp Severity: wishlist Owner: Sruthi Chandran X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-grunt-contrib-clean Version : 1.0.0 Upstream Author : Grunt Team (http://gruntjs.com/) * URL : https://github.com/gruntjs/grunt-contrib-clean * License : Expat Programming Lang: JavaScript Description : Used to clean files and folders in Grunt
Re: missing -dbgsym packages on uploads by maintainer(s)
On Sat, Nov 12, 2016 at 08:51:26AM +0100, Christian Seiler wrote: > Actually, there could be another option: > - by default, throw away all binary debs on uploads /me likes. > - there is a special field in the .changes file (automatically >set by buildds) to tell dak to keep the debs >e.g. Keep-Binaries: yes if the only valid usecase of binary uploads is bootstraping an arch (which I'm not sure is the only valid use case, but I cannot come up with another right now…), I think we shouldnt allow individual maintainers to overwrite this and upload binaries. Rather I'd propose to allow this for all packages of an architecture, which is being bootstrapped right now. And once it's bootstrapped, we disallow it again. -- cheers, Holger signature.asc Description: Digital signature
Re: More 5 november in the release schedule
Marc Haber, on Sun 13 Nov 2016 11:37:13 +0100, wrote: > On Sun, 6 Nov 2016 13:06:33 +0200, Lars Wirzenius wrote: > >I'm even willing to justify my opinion: Keeping testing in a state > >that can be released seems to be the only way in which we can make a > >release in a reasonable time frame. We've tried several other > >approaches, which haven't worked. The approach of "let's freeze and > >then try to fix things" didn't work. Let's not try it again. > > I do not think that it is a service to our users to release an > incomplete distribution just for the sake of keeping a date. As said above, it's *not* a matter of "keeping a date", but "getting something out at all within reasonable time". Samuel
Re: More 5 november in the release schedule
On Sun, 2016-11-13 at 11:28 +0100, Marc Haber wrote: > On Thu, 10 Nov 2016 07:37:00 +, Niels Thykier > >""" > >The release managers may make exceptions to these guidelines as they see > >fit. *Such exceptions are not precedents and you should not assume that > >your package has a similar exception*. Please talk to us if you need > >guidance.unnecessarily > >""" > >(Emphasis from original - 3rd paragraph from the top) > > This is a quite nice opportunity to say something like "you haven't > been nice enough to us in the past or you have dared to speak up when > you didn't like what we did, so you're free to take a hike with your > package, have a nice day". Only if you start from an assumption of bad faith. > I find that unnecessarily humiliating and will probably not do this > and rather live without my package in stable for this release. I find your characterisation of a team and process I've invested several years in trying to make the best that we can demotivating, frankly. And no, I'm not just saying that as tit-for-tat. Regards, Adam
Re: More 5 november in the release schedule
Marc Haber, on Sun 13 Nov 2016 11:37:54 +0100, wrote: > On Sun, 06 Nov 2016 11:51:36 +, Steve McIntyre > wrote: > >Releasing Debian is work for all of us, not just the Release Team... > > So you are actually suggesting that people who are neither on the > release team nor maintaining a key package are not working? He is very obviously not suggesting that. He is just saying what he said: the Release Team shouldn't be doing all the work to get the thing out. Samuel
Re: missing -dbgsym packages on uploads by maintainer(s)
On Sun, Nov 13, 2016 at 10:44:34AM +, Holger Levsen wrote: > On Sat, Nov 12, 2016 at 08:51:26AM +0100, Christian Seiler wrote: > > - there is a special field in the .changes file (automatically > >set by buildds) to tell dak to keep the debs > >e.g. Keep-Binaries: yes > > if the only valid usecase of binary uploads is bootstraping an arch > (which I'm not sure is the only valid use case, but I cannot come up > with another right now…), I think we shouldnt allow individual > maintainers to overwrite this and upload binaries. Rather I'd propose to > allow this for all packages of an architecture, which is being > bootstrapped right now. > > And once it's bootstrapped, we disallow it again. Architectures are not the only things that gets bootstrapped. compilers are another common thing, as is breaking build-dependency chains. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: More 5 november in the release schedule
On Sun, 6 Nov 2016 12:53:42 +0100, Christian Seiler wrote: >And if the problem is complicated, they have other >options: request for help on debian-devel@ and debian-mentors@, >request an exception from the release team to mark a bug as >stretch-ignore in specific cases, request an extension by the >release team to delay autoremoval so they have more time to >fix the issue, etc. This means that one needs personal sympathy, a thing that many people don't have. Especially those who have spoken their mind in the past or have voiced a minority opinion are likely to experience that. I have always liked in Debian that you don't need to brown-nose the people in power to have your work appreciated. Sadly, those times seem to be over. >If a stable release is going to happen, there needs to be some >kind of process so that one may converge on a stable result. I have been around since Debian slink. I have seen train-wreck releases like sarge. As being around for so long, I have to say that the last three-or-so releases have been rather smooth and painless, thanks to the good work the release team and the rest of the Debian community have done. Even the systemd migration, which I have predicted as being doomed and quite painful, went without a hitch. I must say that I have been really astonished about this and I am proud of being a (tiny and mostly irrelevant) part of the community that has done so superb work in the last years. systemd has made us lose valuable people, but we got even this release out of the door nearly in time and in a nearly-perfect stage. Well done. Actually, I am kind of afraid that after we have driven off the people who complained about us releasing too seldomly with the pre-lenny releases, we are now driving off the people who complain about us releasing too often. This effect will be enhanced by the fact that we're going to release an incomplete stretch this time, with no mechanism in place that will even tell pre-existing users of a package that was in jessie but not in stretch that we felt like removing this package. That being said, I simply don't see the neccisity of tightening the thumbscrews on contributors with the new policy. We have done sufficiently well in the past, and this new policy is not going to improve this, but au contraire. >What happens if you only have a single deadline to freeze >fully? Immediately before that deadline people panic because >they noticed they didn't take care of their packages enough >and upload tons of stuff on very short notice - which leads to >more bugs due to weird interactions that will then have to be >sorted out during the actual freeze. With the soft deadlines >added now, this will be relaxed quite a bit, because >everything doesn't hit at once, but it's spaced out and the >overall quality will improve. Agreed. >I really don't see where you are coming from: why do you think >this makes things worse? We will release an incomplete distribution if we don't allow packages back in. And it will damage our contributor's egos when they get the information that their package is not important enough to get an exception, while more important or key packages will _OF_ _COURSE_ be excempt from this policy. We already have a two-class citizenship in Debian, this policy is going to introduce a third class. >The only people affected negatively >by this are going to be people asleep at the wheel for the >entire Stretch cycle that only wake up right before the hard >freeze. And I think that curbing that kind of maintenance >"style" is a very, very good thing. I'd rather have a badly maintained package than none. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: More 5 november in the release schedule
On Thu, 10 Nov 2016 00:24:20 +0100, Wouter Verhelst wrote: >What if I did notice, but fixing the bug takes longer than the 15 days >(and I agree that we shouldn't release with that bug, so I agree that >the severity is correct)? > >15 days is a pretty short time for irreversible changes in Debian, IMO. > >If the policy for the upcoming release really is (and will remain) "once >you're out, you stay out, no exceptions", then have fun releasing Debian >without me. Fully agreed. >If the release team is willing to consider exceptions when >the automated machinery was jumping the gun a little, however, then >okay, I think it might be a good idea to try this out. If you only get an exception if your package is so important that the press will mention us like "Debian stretch is missing the important foo package", then I wouldn't want to even try this. If getting an exception is the normal case, then, fine, try it. But why would be bother to write this in policy if we intend to do this as the normal case? I probably will not bother with asking for an exception if I would need one. If the release team feels like releasing without one of my packages, I'm fine with that. You're not obliged to take advantage of my work. Mein Server läuft auch ohne User. >Being rigid about such policies is never a good thing, though. Yes. And I am afraid that this policy is being as rigid as a two inch steel wall. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: More 5 november in the release schedule [and 1 more messages]
On Sun, 13 Nov 2016 11:07:18 +0100, Christoph Biedl wrote: >Marc Haber wrote... > >> This is exactly the problem I have with the current policy: I fail to >> see why this measure will shorten the freeze. > >I don't. But I'd say we'll just watch what's going to happen and resume >this discussion once stretch is released. Agreed. Maybe I will be proven wrong the same way as I was proven wrong when I claimed that jessie is going to be our most painful release since the glibc migration. I surely hope that I'm wrong. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: More 5 november in the release schedule
Marc Haber: > On Wed, 9 Nov 2016 19:45:02 +0100, gregor herrmann > wrote: >> I don't quite understand where all this fuzz about auto-removals >> suddenly comes from. The auto-removals exist since Septemer 2013 [0] >> and they were also in place for the jessie freeze [1], with the small >> difference that now the point-of-no-return is a month before the hard >> freeze, and in jessie it started with the hard freeze. > > If the jessie release actually had a point-of-no-return, then it was > this seldomly and/or silently enforced that I totally missed it. > > I don't have anything against autoremovals, I am strongly opposed > against the "once you're out, you'll stay out" since I fail to see the > advantages of this approach aside from "giving incentives". > > For me, this "incentive" will most likely have the opposite result. > > Greetings > Marc, who is about to stop caring just a bit more > It was listed in at least two d-d-a mails: * https://lists.debian.org/debian-devel-announce/2015/02/msg0.html * https://lists.debian.org/debian-devel-announce/2014/09/msg2.html Plus the jessie freeze policy; * https://release.debian.org/jessie/freeze_policy.html If you feel we could be more vocal with our announcements, please do not hesitate to let us know. These days we /also/ have a [release calendar] now that you can import, so you can see the deadlines in your favourite calendar. I admit, we did not have that for Jessie - but hopefully it will help people for stretch. Thanks, ~Niels [release calendar] http://release.debian.org/release-calendar.ics
Re: More 5 november in the release schedule
On Sun, 13 Nov 2016 11:45:23 +0100, Samuel Thibault wrote: >Marc Haber, on Sun 13 Nov 2016 11:37:13 +0100, wrote: >> On Sun, 6 Nov 2016 13:06:33 +0200, Lars Wirzenius wrote: >> >I'm even willing to justify my opinion: Keeping testing in a state >> >that can be released seems to be the only way in which we can make a >> >release in a reasonable time frame. We've tried several other >> >approaches, which haven't worked. The approach of "let's freeze and >> >then try to fix things" didn't work. Let's not try it again. >> >> I do not think that it is a service to our users to release an >> incomplete distribution just for the sake of keeping a date. > >As said above, it's *not* a matter of "keeping a date", but "getting >something out at all within reasonable time". This means that we didn't to this with squeeze, wheezy and jessie. In fact, we were in a so reasonable time frame for those three releases that I have seen installations moving away from Debian because we keep releasing too often. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: More 5 november in the release schedule
On Sun, 13 Nov 2016 11:46:36 +0100, Samuel Thibault wrote: >Marc Haber, on Sun 13 Nov 2016 11:37:54 +0100, wrote: >> On Sun, 06 Nov 2016 11:51:36 +, Steve McIntyre >> wrote: >> >Releasing Debian is work for all of us, not just the Release Team... >> >> So you are actually suggesting that people who are neither on the >> release team nor maintaining a key package are not working? > >He is very obviously not suggesting that. He is just saying what he >said: the Release Team shouldn't be doing all the work to get the thing >out. And to relieve the release team they have decided to make re-entering testing a manual process. I only see one way that wouldn't falsify that assumption, and that way is bad. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: More 5 november in the release schedule
On Sun, 13 Nov 2016 10:46:07 +, "Adam D. Barratt" wrote: >On Sun, 2016-11-13 at 11:28 +0100, Marc Haber wrote: >> This is a quite nice opportunity to say something like "you haven't >> been nice enough to us in the past or you have dared to speak up when >> you didn't like what we did, so you're free to take a hike with your >> package, have a nice day". > >Only if you start from an assumption of bad faith. Or from an assumption of being human. I have seen this way of people behaving too often in the past (including in myself). Feel free to prove me wrong. I would really appreciate that. >> I find that unnecessarily humiliating and will probably not do this >> and rather live without my package in stable for this release. > >I find your characterisation of a team and process I've invested several >years in trying to make the best that we can demotivating, frankly. I apologize for speaking my mind. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: More 5 november in the release schedule
Marc Haber, on Sun 13 Nov 2016 11:55:13 +0100, wrote: > On Sun, 13 Nov 2016 11:45:23 +0100, Samuel Thibault > wrote: > >Marc Haber, on Sun 13 Nov 2016 11:37:13 +0100, wrote: > >> On Sun, 6 Nov 2016 13:06:33 +0200, Lars Wirzenius wrote: > >> >I'm even willing to justify my opinion: Keeping testing in a state > >> >that can be released seems to be the only way in which we can make a > >> >release in a reasonable time frame. We've tried several other > >> >approaches, which haven't worked. The approach of "let's freeze and > >> >then try to fix things" didn't work. Let's not try it again. > >> > >> I do not think that it is a service to our users to release an > >> incomplete distribution just for the sake of keeping a date. > > > >As said above, it's *not* a matter of "keeping a date", but "getting > >something out at all within reasonable time". > > This means that we didn't to this with squeeze, wheezy and jessie. That was an awful lot of work for the release team, as well as decisions to abitrary drop some packages, to get something out, which they shouldn't have to bear. > I have seen installations moving away from Debian because we keep > releasing too often. You'll always deceive somebody when doing anything in any kind of way. Samuel
Re: More 5 november in the release schedule
Marc Haber, on Sun 13 Nov 2016 11:56:09 +0100, wrote: > On Sun, 13 Nov 2016 11:46:36 +0100, Samuel Thibault > wrote: > >Marc Haber, on Sun 13 Nov 2016 11:37:54 +0100, wrote: > >> On Sun, 06 Nov 2016 11:51:36 +, Steve McIntyre > >> wrote: > >> >Releasing Debian is work for all of us, not just the Release Team... > >> > >> So you are actually suggesting that people who are neither on the > >> release team nor maintaining a key package are not working? > > > >He is very obviously not suggesting that. He is just saying what he > >said: the Release Team shouldn't be doing all the work to get the thing > >out. > > And to relieve the release team they have decided to make re-entering > testing a manual process. I only see one way that wouldn't falsify > that assumption, and that way is bad. The way I see to falsify is that the release team will only have to make a *decision* about fixes done by the maintainer, instead of having to fix themselves at the last minute some packages they don't even know about. That's way less work. Samuel
Re: Debian Installer Stretch Alpha 8 release
On Nov 13, Helmut Grohne wrote: > Thus I think that debootstrap should revert to unmerged /usr until > dpkg-shlibdeps has been fixed. Fixing is non-trivial and likely requires > an archive rebuild on several architectures. Not really: dpkg-shlibdeps just needs to be fixed to search for libraries in $directory and /usr/$directory, and then everything will work again as usual. And yes, hacks like this one are a side effect of maintaining support for non-merged systems. -- ciao, Marco signature.asc Description: PGP signature
Re: More 5 november in the release schedule
On Sun, Nov 13, 2016 at 11:55:13AM +0100, Marc Haber wrote: > This means that we didn't to this with squeeze, wheezy and jessie. we did this for jessie. the fact that you were not paying attention doesnt change reality. -- cheers, Holger signature.asc Description: Digital signature
Re: Debian Installer Stretch Alpha 8 release
Marco d'Itri, on Sun 13 Nov 2016 12:04:07 +0100, wrote: > On Nov 13, Helmut Grohne wrote: > > Thus I think that debootstrap should revert to unmerged /usr until > > dpkg-shlibdeps has been fixed. Fixing is non-trivial and likely requires > > an archive rebuild on several architectures. > Not really: dpkg-shlibdeps just needs to be fixed to search for > libraries in $directory and /usr/$directory, and then everything will > work again as usual. Then that should be fixed before enabling "merged-usr by default". > And yes, hacks like this one are a side effect of maintaining support > for non-merged systems. Rather, a side effect of taking into account the whole lot of existing packages, whose file list show libraries either in /lib or /usr/lib. Samuel
Re: More 5 november in the release schedule
Marc Haber, on Sun 13 Nov 2016 11:48:06 +0100, wrote: > I'd rather have a badly maintained package than none. That's probably the real point where people differ. To me, releasing in Debian means some given level of quality. Samuel
Re: More 5 november in the release schedule
On Sun, 13 Nov 2016 12:11:06 +0100, Samuel Thibault wrote: >Marc Haber, on Sun 13 Nov 2016 11:48:06 +0100, wrote: >> I'd rather have a badly maintained package than none. > >That's probably the real point where people differ. > >To me, releasing in Debian means some given level of quality. Yes. But we currently treat "does not build at all" or "eats my entire ~ on installation" the same way like "leaves an idle directory in /var/lib after an install-purge-reinstall-old-version-update-remove-reinstall-purge cycle". Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: More 5 november in the release schedule
Marc Haber whined: >On Thu, 10 Nov 2016 07:37:00 +, Niels Thykier > >>""" >>The release managers may make exceptions to these guidelines as they see >>fit. *Such exceptions are not precedents and you should not assume that >>your package has a similar exception*. Please talk to us if you need >>guidance. >>""" >>(Emphasis from original - 3rd paragraph from the top) > >This is a quite nice opportunity to say something like "you haven't >been nice enough to us in the past or you have dared to speak up when >you didn't like what we did, so you're free to take a hike with your >package, have a nice day". The release team are volunteers, working hard and trying to do the best thing for Debian as a whole. Insinuations of unfairness and personal attacks are hardly likely to motivate them to continue to donate their free time, are they? >I find that unnecessarily humiliating and will probably not do this >and rather live without my package in stable for this release. Or, you know, you could just ensure that your packages are working well and this doesn't come up? FTAOD: I thank the release team for their tireless work on making each Debian release better than the last. We keep on adding more and more software and making things harder and harder to stabilise and release, and I 100% support their efforts to improve the process of releasing Debian. I hope that the vast majority of Debian contributors think the same. -- Steve McIntyre, Cambridge, UK.st...@einval.com Armed with "Valor": "Centurion" represents quality of Discipline, Honor, Integrity and Loyalty. Now you don't have to be a Caesar to concord the digital world while feeling safe and proud.
Re: More 5 november in the release schedule
Marc Haber, on Sun 13 Nov 2016 12:16:46 +0100, wrote: > But we currently treat "does not build at all" or "eats my entire > ~ on installation" the same way like "leaves an idle directory in > /var/lib after an > install-purge-reinstall-old-version-update-remove-reinstall-purge > cycle". Don't confuse the bar with the levels catched by the bar, which can be very different indeed. And I guess "leaves an idle directory" is a very good candidate for stretch-ignore, as was done in the past. Samuel
Re: More 5 november in the release schedule
]] Marc Haber > On Thu, 10 Nov 2016 00:24:20 +0100, Wouter Verhelst > wrote: > > >If the release team is willing to consider exceptions when > >the automated machinery was jumping the gun a little, however, then > >okay, I think it might be a good idea to try this out. > > If you only get an exception if your package is so important that the > press will mention us like "Debian stretch is missing the important > foo package", then I wouldn't want to even try this. If getting an > exception is the normal case, then, fine, try it. But why would be > bother to write this in policy if we intend to do this as the normal > case? I don't understand why you think the criteria for allowing a package back in is «is important». It might just as well be «is the maintainer doing an honest effort here, or is it just a drive-by upload?» or something else. I'm not going to pretend to be able to read the release team's collective mind. > >Being rigid about such policies is never a good thing, though. > > Yes. And I am afraid that this policy is being as rigid as a two inch > steel wall. It sounds like you have had very different interactions with the release team than I have. In my experience, they're doing a difficult job, and doing it well, trying to accomodate everybody while still making progress towards releasing. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: More 5 november in the release schedule
On Sun, Nov 13, 2016 at 12:16:46PM +0100, Marc Haber wrote: > Yes. But we currently treat "does not build at all" or "eats my entire > ~ on installation" the same way like "leaves an idle directory in > /var/lib after an > install-purge-reinstall-old-version-update-remove-reinstall-purge > cycle". no, we don't. -- cheers, Holger signature.asc Description: Digital signature
Re: More 5 november in the release schedule
Samuel Thibault, on Sun 13 Nov 2016 12:25:33 +0100, wrote: > Marc Haber, on Sun 13 Nov 2016 12:16:46 +0100, wrote: > > But we currently treat "does not build at all" or "eats my entire > > ~ on installation" the same way like "leaves an idle directory in > > /var/lib after an > > install-purge-reinstall-old-version-update-remove-reinstall-purge > > cycle". > > And I guess "leaves an idle directory" is a very good candidate for > stretch-ignore, as was done in the past. By that, I mean: - either it's easily fixable, and thus there is no reason the maintainer can't fix it in time, and if he doesn't, one can be doubtful about the quality of the rest of the package, for which no RC bug report has been reported _yet_. - or it's difficult to fix, and thus considering the little consequence, the release team will probably accept a stretch-ignore. Samuel
Re: Browserified files and DFSG
On 14490 March 1977, Pirate Praveen wrote: >> I have referred this to CTTE >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830978 > grunt is now available in main, a big part of this issue is resolved, Thanks for that work to all who did it. -- bye, Joerg
Re: Archive changes - indices compression and checksums
On 14490 March 1977, Steve McIntyre wrote: >>as started in March[1] we have just adjusted unstable to no longer >>generate gzip compressed Packages/Sources files. We plan to wait about a >>week before adjusting testing too. >>Additionally we turned off SHA1 checksums for the (In)Release files for >>all testing suites. > I understand the desire to add functionality, but can you explain why > you're removing the older formats? It's breaking other tools, and I'm > not convinced there's much benefit... The SHA1 removal shouldn't break stuff. (We keep MD5 and SHA256, with MD5 for Jigdo). The .gz removal still breaks more than anticipated, so they will stay and get turned off after stretch got stable. Removing them is simply for space, bandwidth and amount of files reason. -- bye, Joerg
Re: More 5 november in the release schedule
Marc Haber writes: > I would feel a lot less uncomfortable if the teams who are using > automated tools to auto-file RC bugs for third-rate policy violations > which will auto-remove a (99,99% of the cases) perfectly working > package from testing in a time where a maintainer would probably not > dare to touch his maintainer scripts for fear of creating a really RC > bug which will in turn get the package auto-removed from testing would > refrain from doing their auto-foo during the freeze. I would rather prefer to get the results of these tools *before* the freeze. In the Jessie release process I had the impression that many tests were done only after the freeze, putting some unneeded pressure to the maintainers. It would rather be nice to run them *now*, or even a few months earlier. > I do appreciate automated tests, and while I think it can be discussed > whether the policy violations found by those automatic tests need to > be RC, I firmly believe that these tools should not be used as a > weapon against packages. They should rather be part of the CI process, also allowing to discuss them during the normal evolution, not in the pressing time of a release. But this is based on my subjective, unproven feeling. >>The goal of autoremovals is to provide an incentive for people >>to deal with problems in their packages _early_. > > Managerspeak. Even at work I hate people who talk about giving > "incentives" while they actually threaten. The problem I see here is: why doesn't the RC bug appear _early_, but maybe only during freeze? >>And as I said previously: if a maintainer of a dependency of yours >>doesn't care: NMUs for RC bugs have a far lower threshold - even >>0-day NMUs are possible if the maintainer is really completely >>asleep. (DevRef 5.11.1) > > So this is a method to force people to take additional > responsibilities for dependencies as well in addition to the > responsibilities they have taken voluntarily? Well, _this_ will > clearly motivate people. I must say that I see no other way: if a dependency of your package has n RC bug, nobody fixes it and you want your package to be kept in, you have to deal with it yourself. I would only propose (and hope) that from the release team it is also accepted to re-upload my own package rebuilt without the buggy dependency -- very often dependencies are optional, and it may help to cut the dependency on a broken, poorly maintained package. For example, many of my packages have lots of dependencies just to run extensive build time tests. Removing them would not make the package worse. Or it may be better to have the package with reduced functionality that to get the package removed completely. Best regards Ole
Bug#844215: ITP: libpod-weaver-section-support-perl -- Add a SUPPORT section to your POD
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libpod-weaver-section-support-perl Version : 1.007 Upstream Author : Apocalypse * URL : https://metacpan.org/release/Pod-Weaver-Section-Support * License : Artistic or GPL-1+ Programming Lang: Perl Description : Add a SUPPORT section to your POD Pod::Weaver::Section::Support is a Dist::Zilla plugin to that will produce a hunk of pod that lists the various ways to get support for your module. If you have Dist::Zilla::Plugin::Repository enabled in your dist.ini, be sure to check the repository_link attribute! The generated support section is added ONLY to the main module's POD, because it would be a waste of space to add it to all modules in your dist. The package will be maintained under the umbrella of the Debian Perl Group. -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Re: More 5 november in the release schedule [and 1 more messages]
On Sun, 13 Nov 2016 10:29:13 +0100, Marc Haber wrote: > On Thu, 10 Nov 2016 08:26:46 +0100, Christoph Biedl > wrote: > >Finally, there's a thing called "trust": I trust the Release Team does > >this solely in order to keep the freeze time as short as possible, > >everybody hates that time anyway. This trust was created by the very > >people behind it, and the way they acted in the past months. > This is exactly the problem I have with the current policy: I fail to > see why this measure will shorten the freeze. It already has shortened the freeze for jessie which had more or less the same policy in place: https://wiki.debian.org/DebianReleases#Release_statistics Cheers, gregor -- .''`. https://info.comodo.priv.at/ - Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- NP: Beatles: Happiness Is A Warm Gun signature.asc Description: Digital Signature
Bug#844219: ITP: libpod-elemental-transformer-list-perl -- module to transform :list regions into =over/=back
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libpod-elemental-transformer-list-perl Version : 0.102000 Upstream Author : Ricardo SIGNES * URL : https://metacpan.org/release/Pod-Elemental-Transformer-List * License : Artistic or GPL-1+ Programming Lang: Perl Description : module to transform :list regions into =over/=back Pod::Elemental::Transformer::List module provides a way to write lists in Pod in an easier way than usual =over/=item/back section. In your Pod document, you must add a =for declaration and then the list items prefixed with '*' The package will be maintained under the umbrella of the Debian Perl Group. -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Re: Debian Installer Stretch Alpha 8 release
Control: clone 843073 -1 Control: reassign -1 debootstrap 1.0.85 Control: retitle -1 debootstrap: Please revert merged-/usr by default as it breaks builds Control: severity -1 serious Control: affects -1 dpkg-dev Control: severity 843073 wishlist Control: block 810499 by 843073 Control: severity 810499 serious Control: affects 810499 dpkg-dev Hi! On Sun, 2016-11-13 at 08:38:53 +0100, Helmut Grohne wrote: > On Sat, Nov 12, 2016 at 08:55:43PM +0100, Michael Biebl wrote: > > Is this really so for all buildds? > > See #843433, the sparc64 buildds apparently do use a merged-usr chroot. > > The issue depends on the loader path of the architecture. Although I do > not understand why, it seems that /lib64 is less prone to exposing it > than /lib is. We have people saying: > * not reproducible on amd64 /lib64 (Marco) > * not reproducible on sparc64 /lib64 (Michael) > * reproducible on i386 /lib (#810499) > * reproducible on armhf /lib (Uwe) > > So the expectation I have is that it'll break: > * armel > * armhf > * i386 > * mips > * mipsel > * s390x > > Plus a number of non-release architectures. Thanks for taking a look! > > Hm, I would still consider it release critical, i.e. something which > > needs to be fixed before we can release stretch. Otherwise this will > > bite us later. > > I agree. Ok fine, this looks pretty worse than it looked before. So I'm rearranging the bugs to where they belong. > The /usr merge violates core assumptions in dpkg-shlibdeps. The reason > that amd64 isn't broken is sheer luck. > /etc/ld.so.conf.d/x86_64-linux-gnu.conf lists /lib before /usr/lib, so > dpkg-shlibdeps considers that first. Swapping them or simply removing > /lib (as seems reasonable on a merged /usr), breaks almost any build on > amd64 (e.g. dash). The breakage on amd64 is simply hidden. Right. I'm happy to assist people who want to fix this to try to find a proper solution in dpkg-dev, but I'm not planning on spending time on this on my own. On Sun, 2016-11-13 at 12:04:07 +0100, Marco d'Itri wrote: > On Nov 13, Helmut Grohne wrote: > > Thus I think that debootstrap should revert to unmerged /usr until > > dpkg-shlibdeps has been fixed. Fixing is non-trivial and likely requires > > an archive rebuild on several architectures. > Not really: dpkg-shlibdeps just needs to be fixed to search for > libraries in $directory and /usr/$directory, and then everything will > work again as usual. > And yes, hacks like this one are a side effect of maintaining support > for non-merged systems. Err, well exactly because usemerge is a major hack, and I'm actually surprised we are deploying systems by default with that. As an interesting thing to install and try out on ones system that's perfectly fine though. But IMO if the merge needs to be done it should be done by installing things into their final desired destination on each package. Of course that makes split installations not possible, but oh well. Thanks, Guillem
Bug#844222: ITP: slic3r-prusa -- G-code generator for 3D printers
Package: wnpp Severity: wishlist Owner: Chow Loong Jin * Package name: slic3r-prusa Version : 1.31.4 Upstream Author : Vojtech Bubnik * URL : https://github.com/prusa3d/slic3r * License : GPL Programming Lang: Perl, C++ Description : G-code generator for 3D printers Slic3r converts digital 3D models into printing instructions (G-code) for your 3D printer. It cuts the model into horizontal slices (layers), generates toolpaths to fill them and calculates the amount of material to be extruded. . Slic3r supports input in the STL, AMF and OBJ formats, and can output G-code for several series of 3D printers, including RepRap, Ultimaker, Makerbot, as well as SVG files for DLP printers. . It can be used with a graphical interface, or in batch mode via the command-line. . This package contains the Prusa3D fork of Slic3r. -- Kind regards, Loong Jin signature.asc Description: PGP signature
Bug#844223: ITP: libwww-shorten-github-perl -- shorten GitHub URLs using GitHub's URL shortener
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libwww-shorten-github-perl Version : 0.1.7 Upstream Author : James Aitken * URL : https://metacpan.org/release/WWW-Shorten-GitHub * License : Artistic or GPL-1+ Programming Lang: Perl Description : shorten GitHub URLs using GitHub's URL shortener This module provides a perl interface to GitHub's URL shortening service, git.io. It allows you to shorten any GitHub URL, and also retrieve the original URL from a pre-shortened URL The package will be maintained under the umbrella of the Debian Perl Group. -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Bug#844229: ITP: node-chroma-js -- JavaScript library for color conversions
Package: wnpp Severity: wishlist Owner: Ross Gammon * Package name: node-chroma-js Version : 1.2.1 Upstream Author : Gregor Aisch * URL : https://github.com/gka/chroma.js * License : BSD-3 Programming Lang: JavaScript Description : JavaScript library for color conversions Chroma.js is a tiny JavaScript library (12kB) for all kinds of color conversions and color scales. . Node.js is an event-based server-side JavaScript engine. Chroma-js is a new dependency of node-carto which is maintained within the Debian Javascript Team, where this one will also be maintained.
Bug#844230: ITP: node-husl -- Human-friendly HSL
Package: wnpp Severity: wishlist Owner: Ross Gammon * Package name: node-husl Version : 6.0.1 Upstream Author : Alexei Boronine * URL : http://www.husl-colors.org * License : Expat Programming Lang: JavaScript Description : Human-friendly HSL HUSL is implemented as a set of functions to convert colors between RGB, HUSL and HUSLp. . Node.js is an event-based server-side JavaScript engine. Husl is a new dependency of node-carto which is maintained within the Debian Javascript Team, where this one will also be maintained.
Re: libc recently more aggressive about pthread locks in stable ?
On 12/11/16 at 18:51 -0200, Henrique de Moraes Holschuh wrote: > Lucas, > > Thanks for trying a build run with TSX enabled. > > On Sat, 12 Nov 2016, Lucas Nussbaum wrote: > > I did an archive rebuild on Amazon EC2 using m4.16xlarge instances, that > > use a CPU with TSX enabled. > > What microcode revision is that Xeon E5-2686 running? microcode: CPU0 sig=0x406f1, pf=0x1, revision=0xb14 (That's just on one node. I'm assuming that all nodes had the same microcode revision, which is probably a reasonable bet) Lucas
Re: More 5 november in the release schedule
On Sun, Nov 13, 2016 at 11:23:24AM +, Steve McIntyre wrote: > FTAOD: I thank the release team for their tireless work on making each > Debian release better than the last. We keep on adding more and more > software and making things harder and harder to stabilise and release, > and I 100% support their efforts to improve the process of releasing > Debian. > > I hope that the vast majority of Debian contributors think the same. +1. I agree with Steve. -- I want to build worthwhile things that might last. --joeyh signature.asc Description: PGP signature
Bug#844251: ITP: elpa-ido-ubiquitous -- use ido (nearly) everywhere
Package: wnpp Severity: wishlist Owner: Lev Lamberov * Package name: elpa-ido-ubiquitous Version : 3.14 Upstream Author : Ryan C. Thompson * URL : https://github.com/DarwinAwardWinner/ido-ubiquitous * License : GPL-3+ Programming Lang: Emacs Lisp Description : use ido (nearly) everywhere If you use the excellent `ido-mode' for efficient completion of file names and buffers, you might wonder if you can get ido-style completion everywhere else too. This package replaces stock emacs completion with ido completion wherever it is possible to do so without breaking things. elpa-completing-read+: This package implements the `ido-completing-read+' function, which is a wrapper for `ido-completing-read'. Importantly, it detects edge cases that ordinary ido cannot handle and either adjusts them so ido *can* handle them, or else simply falls back to Emacs' standard completion instead.
Re: More 5 november in the release schedule [and 1 more messages]
On Sun, 13 Nov 2016 15:43:26 +0100, gregor herrmann wrote: >On Sun, 13 Nov 2016 10:29:13 +0100, Marc Haber wrote: > >> On Thu, 10 Nov 2016 08:26:46 +0100, Christoph Biedl >> wrote: >> >Finally, there's a thing called "trust": I trust the Release Team does >> >this solely in order to keep the freeze time as short as possible, >> >everybody hates that time anyway. This trust was created by the very >> >people behind it, and the way they acted in the past months. >> This is exactly the problem I have with the current policy: I fail to >> see why this measure will shorten the freeze. > >It already has shortened the freeze for jessie which had more or less >the same policy in place: > >https://wiki.debian.org/DebianReleases#Release_statistics By 13 days. I don't think that's worth it. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Does debconf-set-selections automatically deletes values from debconf database once they are used?
Hi, Not sure if it's okay to ask about it here. But I asked on #debian-user, and never get the reply. One of these days, I made, say, unattended install of different version of mysql. And the main concern is about putting passwords in debconf database (if they are left there or not). But also I'm curious what's exactly happening there. Consider the following typescript: # export DEBIAN_FRONTEND="noninteractive" # sudo debconf-set-selections <<< "mysql-community-server mysql-community-server/remove-data-dir boolean true" # echo GET mysql-community-server/remove-data-dir | debconf-communicate 0 true # apt purge mysql-* ... # echo GET mysql-community-server/remove-data-dir | debconf-communicate 10 mysql-community-server/remove-data-dir doesn't exist # sudo debconf-set-selections <<< "mysql-server mysql-server/root_password password 123456" # sudo debconf-set-selections <<< "mysql-server mysql-server/root_password_again password 123456" # echo GET mysql-server/root_password | debconf-communicate 0 123456 # apt install mysql-server-5.6 ... # echo GET mysql-server/root_password | debconf-communicate 0 So, do the values get deleted after use? Who does this? Why I can set a value when the package is not installed yet, but getting it after removing the package triggers an error? And more importantly, is the password still in debconf database after installing the package? Regards, Yuri
Bug#844259: ITP: r-cran-rentrez -- GNU R interface to the NCBI's EUtils API
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-cran-rentrez Version : 1.0.4 Upstream Author : David Winter * URL : https://cran.r-project.org/package=rentrez * License : MIT Programming Lang: GNU R Description : GNU R interface to the NCBI's EUtils API Provides an R interface to the NCBI's EUtils API allowing users to search databases like GenBank and PubMed, process the results of those searches and pull data into their R sessions. Remark: This package is needed to upgrade r-cran-taxize which needs r-cran-rotl which in turn needs this package r-cran-rentrez. It will be maintained by the Debian Med team at svn://anonscm.debian.org/debian-med/trunk/packages/R/r-cran-rentrez/trunk/
Re: OpenSSL 1.1.0
Hi, so whats your suggestions to solve issues like I have with open-vm-tools: Most build-dependencies switch to 1.1.0 - but one (libxml-security-c-dev) sticks with 1.0, as far as I've seen in the bts because shibboleth won't be able to use 1.1.0. Not shipping open-vm-tools is not an option, as it will break support for Debian on basically all installations under a vmware hypervisor. Which are a lot. Whats your suggestion? Best regards, Bernd P.S. imho the time for the openssl transition was the worst one possible at all, it *will* result in security bugs and/or a delayed release. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F signature.asc Description: OpenPGP digital signature
debian/compat and debian/control debhelper dependency
Aren't the two redundant ? Jérémy
Re: debian/compat and debian/control debhelper dependency
Dear Jérémy, On Sun, Nov 13, 2016 at 11:53:36PM +0100, Jérémy Lal wrote: > Aren't the two redundant ? Not always, no. debhelper compat 10 was available before debhelper version 10 was released. -- Sean Whitton signature.asc Description: PGP signature
Re: Does debconf-set-selections automatically deletes values from debconf database once they are used?
On Sun, Nov 13, 2016 at 10:56:32PM +0200, Yuri Kanivetsky wrote: > # sudo debconf-set-selections <<< "mysql-community-server > mysql-community-server/remove-data-dir boolean true" > > # echo GET mysql-community-server/remove-data-dir | debconf-communicate > 0 true > > # apt purge mysql-* > ... > > # echo GET mysql-community-server/remove-data-dir | debconf-communicate > 10 mysql-community-server/remove-data-dir doesn't exist This happens because packages generally purge questions owned by them from the debconf database when they themselves are purged. This is up to each package, but debhelper's standard debconf integration code gets it right and packages generally don't deviate from that unless they have some particularly good reason. > # sudo debconf-set-selections <<< "mysql-server > mysql-server/root_password password 123456" > > # sudo debconf-set-selections <<< "mysql-server > mysql-server/root_password_again password 123456" > > # echo GET mysql-server/root_password | debconf-communicate > 0 123456 > > # apt install mysql-server-5.6 > ... > > # echo GET mysql-server/root_password | debconf-communicate > 0 This happens because mysql-server-5.6's postinst script explicitly clears the password from the debconf database in order to avoid it staying around on disk. > Why I can set a value when the package is not installed yet, but > getting it after removing the package triggers an error? These are consistent. You can always set a question's value using debconf-set-selections (it registers the question if it doesn't exist yet, because debconf-set-selections is intended to be used for preseeding). Your first GET above succeeded because you'd preseeded the value yourself; the second failed because when you purged the package it removed the preseeded question. > And more importantly, is the password still in debconf database after > installing the package? You were right to check, since it's possible for packages to get this wrong, but no, it's not. Also, by default, questions of "password" type go into a separate debconf database which is only readable by root. This isn't great protection and packages should still ensure that passwords aren't left there long-term, but it's better than nothing. -- Colin Watson [cjwat...@debian.org]
Re: debian/compat and debian/control debhelper dependency
On Sun, Nov 13, 2016 at 03:59:07PM -0700, Sean Whitton wrote: > On Sun, Nov 13, 2016 at 11:53:36PM +0100, Jérémy Lal wrote: > > Aren't the two redundant ? > > Not always, no. > > debhelper compat 10 was available before debhelper version 10 was > released. And even aside from that, one sometimes needs to build-depend on a newer debhelper because it fixes a bug or adds a particular feature, yet without necessarily immediately opting into all the compatibility-breaking changes that come with the higher compat level. -- Colin Watson [cjwat...@debian.org]
Re: missing -dbgsym packages on uploads by maintainer(s)
Hi, Quoting Mattia Rizzolo (2016-11-13 11:48:02) > On Sun, Nov 13, 2016 at 10:44:34AM +, Holger Levsen wrote: > > if the only valid usecase of binary uploads is bootstraping an arch (which > > I'm not sure is the only valid use case, but I cannot come up with another > > right now…), I think we shouldnt allow individual maintainers to overwrite > > this and upload binaries. Rather I'd propose to allow this for all packages > > of an architecture, which is being bootstrapped right now. > > > > And once it's bootstrapped, we disallow it again. > Architectures are not the only things that gets bootstrapped. compilers are > another common thing, as is breaking build-dependency chains. the proper long-term fix for that would be for wanna-build to support build profiles. Then maintainers: a) will have an incentive to add build profiles to their source packages containing cyclic build dependencies b) can do source-only uploads because building the source packages in the right order with the right build profiles activated will break build dependency cycles without manual injection of pre-compiled binaries Thanks! cheers, josch signature.asc Description: signature
