Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
On Mon, 14 Jul 2014, Kurt Roeckx wrote: > On Mon, Jul 14, 2014 at 02:09:55PM -0300, Henrique de Moraes Holschuh wrote: > > On Mon, 14 Jul 2014, Kurt Roeckx wrote: > > > I plan to try and get them to use symbol versioning, at least on > > > those platforms that support it. This will probably be just like > > > > Thank you. > > > > > the patch currently in Debian. I don't plan to add multiple > > > versions of a symbol to try and keep the same soname since that > > > probably won't work on all platforms. > > > > We want _all_ visible libressl symbols versioned, but that's for protective > > namespacing, and not for backwards binary compatibility. That's why it > > should be a libressl-specific symbol version, since full guaranteed > > *internal* ABI compatibility with openssl is not really happening. > > If it wasn't clear, I was talking about openssl not libressl. I see. > But libressl really should use symbol versions too. The patch in > Debian's openssl should be a good starting point, but you need to > rename the symbol version to something else. If you change the > soname you also want to change the symbol versions, so keep that > in mind when picking the version you're going to use. i.e. get the soname into the symbol version string. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140714173608.gb24...@khazad-dum.debian.net
Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
On Mon, 14 Jul 2014, Kurt Roeckx wrote: > I plan to try and get them to use symbol versioning, at least on > those platforms that support it. This will probably be just like Thank you. > the patch currently in Debian. I don't plan to add multiple > versions of a symbol to try and keep the same soname since that > probably won't work on all platforms. We want _all_ visible libressl symbols versioned, but that's for protective namespacing, and not for backwards binary compatibility. That's why it should be a libressl-specific symbol version, since full guaranteed *internal* ABI compatibility with openssl is not really happening. We've been through this hell with libpng, libsasl, and openssl itself... I still think we should forbid any libraries with unversioned symbols in Debian, unless they're guaranteed to never be linked by other libraries (including nss modules and the like). Solaris got this idea right nearly two decades ago. Use of symbol versioning for providing several versions of the same symbol for backwards binary compatibility (like it is done by glibc) has its own problems and limitations. Those were rehearsed ad nauseam some years ago, and that's _not_ what we're talking about here, anyway. > We also plan to reduce the risk of breaking the ABI. Now a lot of > structs are public and we would like to make them private and > provide functions for those things that people want to access. Seems sensible. > This will all probably take some time. As long as you don't mean to wait to deploy symbol versioning. It becomes *really* painful after a while. Changes to symbol versioning requires everyone to recompile everything that uses the library. It is bad enough when you go from unversioned to versioned symbols (the binary will still run but you get a warning about it every time), but it is hell when you switch[1] symbol versioning decoupled from a major soname bump, because everything that is not recompiled with the new symbols will fail to runtime link, requiring coordinated transitions/flag-days to avoid this. [1] as in change the namespace, and _not_ as in provide a new version of symbols while also providing the older versions of the symbol around. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140714170955.ga24...@khazad-dum.debian.net
Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
On Sun, 13 Jul 2014, Juliusz Chroboczek wrote: > > Meanwhile, we could try to get ever distro with a clue together, map the > > versioned symbol diffs that already exist, and see if we can come up with a > > plan to at least do downstream versioning in a compatible way. > > Please, please, please speak to upstream first. It's hard work, but some > upstreams can be convinced to do the right thing. Yes. Getting upstream in the loop has to be part of any plan re. versioning symbols. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140713210621.ga3...@khazad-dum.debian.net
Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
On Sun, 13 Jul 2014, Matthias Urlichs wrote: > I am, frankly, not at all concerned with binaries not compiled on Debian > at this point. Data point: Fedora uses a different symbol versioning > scheme for openssl, so openssl-linked binaries from there won't run on > Debian anyway. > > It's far more imperative to educate upstream (in general, not just openssl > – but them in particular) about the fact that adding versioning to their > libraries is a Very Good Idea which will save them (and, more to the point, > anybody using their code) a whole lot of hassle – as well as potential > security holes – if/when their ABI changes. Meanwhile, we could try to get ever distro with a clue together, map the versioned symbol diffs that already exist, and see if we can come up with a plan to at least do downstream versioning in a compatible way. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140713200739.ga1...@khazad-dum.debian.net
Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
On Sun, 13 Jul 2014, Matthias Urlichs wrote: > for that (i.e. make sure that _everything_ in libressl is only exported > with properly versioned symbols), again IMHO the time and effort required PLEASE PLEASE PLEASE PLEASE PLEASE take this to the portable libressl upstream *and make it true* for the Linux targets. Now. Before people start shipping for real non-versioned-symbols versions of libressl everywhere and third party closed-source applications pick on that. And please use a libressl-specific symbol version (LIBRESSLxy, for example). > that now; and while IANARTM (Release Team Member) transitioning the whole > of Debian to libressl closer to the release would not be a good idea even > if we decide it's (going to be) the better alternative. Indeed. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140713171629.gb23...@khazad-dum.debian.net
Re: possible MBF: automatically detecting unused build dependencies
On Mon, 07 Jul 2014, Johannes Schauer wrote: > MBF template email: > > --%<--- > Subject: Please consider removing the build dependencies on $foo, $bar and > $baz > Severity: wishlist > Usertag: unusedbd > User: bootst...@lists.debian.org > > Dear Maintainer, > > the build dependencies $foo, $bar and $baz of this source package do not seem > to be needed. Neither are any of their files accessed during the build nor are > their dependencies on other binary packages required. Please consider dropping > those build dependencies to make bootstrapping Debian easier. > > You can find more detail about the procedures that were used to find this > problem in the MBF announcement on debian-devel: $email > -->%--- Please don't assume that the unused build dependency is always where the defect is. Rather, the MBF text should account for the possibility that the unused build-dependency should have been used in the first place, but something is broken in the build and it is being left unused. For example: something that is uselessly build-depending on autotools-dev might either: 1. Have an useless build-dependency or 2. Have a bug that is causing autoreconf to either not be called in the first place, or to fail to refresh the auto-tooling. While (1) is more likely, ignoring the possibility of (2) is not wise. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140707120726.ga7...@khazad-dum.debian.net
Re: Unicode 7.0 released - some packages contain outdated embedded data copies
On Wed, 18 Jun 2014, Thorsten Glaser wrote: > Furthermore, with upstream *and* Debian maintainer hat on, I refuse to > use a Debian-specific “special way” here. I will only fix this upstream > (and there, there is no unicode-data package). Make it generic, instead. You could just automatize the table update through a script, and allow it to either fetch the data over the network using curl/wget/whatever (default), or to get the data from a local file. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140618132234.ge22...@khazad-dum.debian.net
Re: use of RDRAND in $random_library
On Fri, 13 Jun 2014, Joey Hess wrote:
> Henrique de Moraes Holschuh wrote:
> > Now, the kernel can soft-blacklist RDRAND (and RDSEED) usage[2]. In that
> > case, the kernel won't use it and it disappears from /proc/cpuinfo, and we
> > could do that also to avoid processor errata, not just due to user request.
> > However, AFAIK kernel blacklisting would not cause the instructions to trap
> > or fail on bare-metal, so userspace could still just use them anyway.
>
> Not sure what you mean by bare metal here.
Not under a hypervisor.
> > Joey, what does that Haskell lib uses to detect availability of RDRAND?
>
> int cpu_has_rdrand()
> {
> uint32_t ax,bx,cx,dx,func=1;
> __asm__ volatile ("cpuid":\
> "=a" (ax), "=b" (bx), "=c" (cx), "=d" (dx) : "a" (func));
> return (cx & 0x4000);
> }
Oh dear. Can you try running that on a kernel that was booted with the
"nordrand" command line parameter? I don't have a box with RDRAND support
to test it myself ATM.
Please try it on bare metal (not on a VM).
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140614220026.gb18...@khazad-dum.debian.net
Re: use of RDRAND in $random_library
On Wed, 11 Jun 2014, Joey Hess wrote: > I don't have a stong opinion on the security of RDRAND, which is a > contentious topic in a domain I am not expert in. However, I would much > rather rely on linux developers to make the right decision on that, > rather than libraries deciding on an ad-hoc basis. Especially because I second that. Previous experience with the "xstore-rng" instruction for the VIA PadLock on-die HRNG[1] taught me just how dangerous it is dangerous to call model-specific instructions directly. Although it is Intel we're talking about here, so you could at least expect a microcode update to disable RDRAND/RDSEED where broken (it is a known fact that they can enable or disable it through a microcode update, refer to errata BV54 for the 3rd gen Intel Core processor, where the microcode update does the opposite and enables RDRAND). It would take like 6 months for such a microcode update to show up anywhere, and the low adoption rates would ensure a lot of boxes would never get the fix. So it would be up to the kernel to avoid disaster. Now, the kernel can soft-blacklist RDRAND (and RDSEED) usage[2]. In that case, the kernel won't use it and it disappears from /proc/cpuinfo, and we could do that also to avoid processor errata, not just due to user request. However, AFAIK kernel blacklisting would not cause the instructions to trap or fail on bare-metal, so userspace could still just use them anyway. Joey, what does that Haskell lib uses to detect availability of RDRAND? [1] Due to processor errata, instead of writing the requested number of bytes, the xstore-rng instruction will write 16 bytes, trashing nearby data. Known to happen at least to the Via Nano processor. [2] Add "nordrand" to the kernel command line to soft-blacklist RDRAND. You cannot blacklist RDSEED on most kernels at this time, the fix was not sent to -stable (yet). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140613134310.gc30...@khazad-dum.debian.net
Re: Why not 03 ?
On Mon, 02 Jun 2014, Xavier Roche wrote: > On Mon, Jun 02, 2014 at 10:36:01AM -0300, Henrique de Moraes Holschuh wrote: > > As long as you have a way to regression-test. And I don't mean performance > > regressions, either. Although issues with -O3 are rare, they're not unheard > > of. > > Looking at the `man gcc' page, I fail to see, outside compiler bugs, what > could cause issues at 03 vs. O2. It is a moving target. For GCC 4.9: -O3 turns on all optimizations specified by -O2 and also turns on the: -finline-functions, -funswitch-loops, -fpredictive-commoning, -fgcse-after-reload, -ftree-loop-vectorize, -ftree-slp-vectorize, -fvect-cost-model, -ftree-partial-pre and -fipa-cp-clone options. For GCC 4.7: -O3 turns on all optimizations specified by -O2 and also turns on the: -finline-functions, -funswitch-loops, -fpredictive-commoning, -fgcse-after-reload, -ftree-vectorize and -fipa-cp-clone options. And compiler bugs _are_ an issue. Which is why testing done on an optimization level is not strictly valid for other optimization levels. You can ignore this, but it may eventually bite you (especially on less common arches and optimization modes). > I have the feeling that most "dangerous" (ie. breaking dirty code, or code > using non-specified C behavior) features are already on O2: > * -fstrict-aliasing (code aliasing the same pointer wirh a different type) > * -fstrict-overflow (signed arithmetic overflow being undefined) Optimizations related to memory reuse are _always_ a bit dangerous to enable blindly on anything that has complex signal handlers, needs to be able to "secure clobber" memory, implements multithreading syncronization directly, etc. > Outside architecture issues, such as "will produce bytecode unsupported by > old processors", what typical optimizations can harm us at O3 ? All of the optimizations in -O3 are known to be harmful[1] in certain situations, otherwise they'd be in the -O2 set in the first place. Fortunately, only compiler bugs and code with undefined behaviour will cause incorrect program behaviour [unrelated to performance] when you change among -Os,-Og,-O0,-O1,-O2,-O3. [1] supposedly they are only possibly harmful to performance. When it causes miscompiling, it is a bug. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140602174106.ga2...@khazad-dum.debian.net
Re: Why not 03 ?
On Mon, 02 Jun 2014, Thomas Goirand wrote: > On 06/02/2014 05:07 AM, Julien Cristau wrote: > > For a lot of scientific packages, the upstream authors don't know what > > they're doing. So I'm not sure that's much of an argument. > > [citation needed] > > Also, it's easy to just play with the -O option and see what's faster. As long as you have a way to regression-test. And I don't mean performance regressions, either. Although issues with -O3 are rare, they're not unheard of. And all bets are off when the C code has undefined behavior. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140602133601.ga25...@khazad-dum.debian.net
Re: Why not 03 ?
On Sun, 01 Jun 2014, Tollef Fog Heen wrote: > > FWIW, the recent port of Ubuntu to ppc64el uses -O3 as the default, because > > IBM has broad experience in resolving performance issues for their own > > hardware and have found that -O3 gives an overall better experience for > > their customers. It will be difficult for Debian to gather the same kind of > > information across all its architectures, but we shouldn't conclude, just > > because it's difficult to know the right answer, that -O2 is definitely the > > right answer. > > It sounds like we want to stop recommending any particular level in > Policy and just let the architecture toolchain default to the > recommended value for that architecture, and only override when there's > a need. No. People mess with this rather cluelessly. As long as it is not "MUST use -Ofoo", we really should say something in policy. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140531230024.ga8...@khazad-dum.debian.net
Re: Bug#749099: ITP: conv -- Simple ASCII,binary,decimal,hex converter
On Sat, 24 May 2014, Jakub Wilk wrote: > * Marcio de Souza Olivera , 2014-05-23, 23:53: > >* Package name: conv > > That's an awfully generic name... Agreed. And for something rather limited. > > Description : Simple ASCII,binary,decimal,hex converter > > How is it different/better than iprint? Or printf in bash, or the correct use of "ibase" and "obase" in bc... We really have way too many ways to convert between bases already. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140524155543.ga12...@khazad-dum.debian.net
Re: noexec goal for hardening Debian (was Re: Bug#746496: general: Package upgrade scripts partly fail when /tmp is noexec)
On Fri, 02 May 2014, Thorsten Glaser wrote: > Henrique de Moraes Holschuh dixit: > >On Wed, 30 Apr 2014, Pierre wrote: > >> When /tmp is configured as noexec (for example /tmp in RAM), some > >> scripts fail on package update. > > […] > >It may look like it is working, but we don't properly support it, > > Sounds like a release goal for jessie+1 or jessie+2. No, it is useless, wasted effort. NOEXEC $TMPDIR (and NOEXEC /tmp) will always break the world. There is no shortage of troublesome release goals that are worth the effort. NOEXEC /tmp is not one of them. E.g. it would be a lot better to, instead, adopt per-user (that can also mean per-daemon/per-service) exclusive $TMPDIR enhanced by per-user mount namespaces that also take care of /tmp, or something to that effect. But those won't be NOEXEC. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140502151920.gb19...@khazad-dum.debian.net
Bug#746496: general: Package upgrade scripts partly fail when /tmp is noexec
On Wed, 30 Apr 2014, Pierre wrote: > When /tmp is configured as noexec (for example /tmp in RAM), some scripts > fail on package update. Don't Do It. It will break the system in surprising ways. It may look like it is working, but we don't properly support it, as it is almost never tested. Neither by us, nor by anybody else (so third-party software is very likely to also choke on noexec /tmp and/or noexec $TMPDIR). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140501025654.ge11...@khazad-dum.debian.net
Re: Advice for how to make new things policy (was: ':any' syntax in package names in jessie/sid Packages)
On Mon, 21 Apr 2014, Charles Plessy wrote: > things are too slow or not happening is the lack of manpower. See for example > the documentation of the Dpkg triggers: we miss only one single Debian > Developer to review the discussion and the patch in #582109 (I even offered to > go piece by piece, see message #209 in the thread). Yet, it has been more > than > a year that out of our hundreds of active developers, nobody had time or > interest to do this. Nobody *who really knows how triggers work*, you mean. Otherwise some of the random DDss that hang around debian-policy, like yours thruly, would already have seconded it. This is the important point to keep in mind: we rarely [should be never] second what we don't understand. We won't second something that we cannot judge to be correct or not, especially when the details *matter*. > accelerate the incorporation in the Policy by taking the lead: submit a patch, > restart the discussion when it loses momentum, and ask DDs to review the patch > if nobody spontaneously volunteer. The only thing you can not do is to decide Indeed. It helps a *GREAT* *DEAL* if the people who actually designed and/or implemented the feature shows up to write the documentation, or to second it. So far, it looks like that won't be a problem for multiarch, so it should have a much easier time getting into policy... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140421020600.gb11...@khazad-dum.debian.net
Re: Having fun with the following C code (UB)
On Thu, 10 Apr 2014, Shachar Shemesh wrote: > I never did understand what people expect. gcc uses the undefined Warn the hell out of any line of code with per-spec undefined behaviour, if not by default, at least under -Wall. THAT would be a good start. Too bad not even gcc knows every time it hits undefined behaviour... > Are you really sure you want to have slower code just so that your > corner cases are easier for you? How is that a reasonable trade-off to make? Yes in just about everything that did not ask for -On where n > 2. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140412203827.ga25...@khazad-dum.debian.net
Re: Having fun with the following C code (UB)
On Thu, 27 Mar 2014, Jakub Wilk wrote: > * Mathieu Malaterre , 2014-03-27, 13:06: > >I preferred not to mass bug everyone out there and instead: > > > >http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742780 > > But many packages don't regenerate autofoo at build-time. :-( > > >LFS is still a release goal, not a requirement. > > Then "severity: grave" is probably overkill. :-P No, it is not. I can cause data loss or corruption when operating with large files, and it is aggravated by the fact that the application used to work in LFS mode just fine on Wheezy, but it is now broken. LFS has been a release goal for a LONG time, which means we have fixed a LOT of packages to have LFS for at least two stable releases already and therefore regressions on LFS support *are* an issue. Also, autotooling at build time (i.e. regenerating the autofoo) is our recommended best practice, exactly so that we can actually have a shot at fixing this kind of crap... IMO, this is very much a "grave" bug. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140408143923.gd1...@khazad-dum.debian.net
Re: RSA vs ECDSA (Was: Bits from keyring-maint: Pushing keyring updates. Let us bury your old 1024D key!)
On Wed, 05 Mar 2014, peter green wrote: > Also ECDSA shares with DSA the serious disadvantage over RSA that > making signatures on a system with a broken RNG can reveal the key. I believe that we should avoid ECDSA gnupg keys and subkeys like the plague for the time being. You'd most likely get ECDSA keys using the NIST p-curves out of gnupg, and these p-curves are suspected to be backdoored. AFAIK, better curves are available only on the latest development versions of gnupg 2.1, and the difficulties do not end there: the keyservers are also going to be a problem for such keys and subkeys for a while yet. IMHO, we should stick with 4096-bit RSA for the main key for the time being, and use short expire dates for the *subkeys* (2 years or less). Refer to http://safecurves.cr.yp.to/ for more details on elliptic curves for crypto. PS: NIST p-curves are also a potential problem on OpenSSH and DNSSEC. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140323025114.ga14...@khazad-dum.debian.net
Re: default init on non-Linux platforms
On Tue, 18 Feb 2014, Russ Allbery wrote: > Henrique de Moraes Holschuh writes: > > They *HAVE* to be provided by the active init system. They are an > > impedance matching layer (aka stable API) used by maintainer scripts to > > interface with the active init system. > > If you look at the existing implementation, you'll find that the version > provided by sysv-rc already supports systemd, upstart, and sysv-rc itself. > So this isn't precisely true. If we stick with the current model, then > some (probably essential) package just needs to provide those Hmm, we can provide one, yes. Probably in sysvinit-utils, which already has some important tools that are not strictly related to sysvinit itself. > There are some advantages to providing only one version with knowledge of > all of the init systems given that we're supporting init system switching, > and therefore may need to set up state for init systems that aren't > currently running so that switching can work properly. A good example is > registering an init script with insserv so that the correct S and K links > are created even if the system is currently booted with a different init > system. I agree. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140219000552.ga17...@khazad-dum.debian.net
Re: default init on non-Linux platforms
On Tue, 18 Feb 2014, Tollef Fog Heen wrote: > > Once I consider OpenRC ready for it, would it be ok to just replace > > sysv-rc by OpenRC, and transform sysv-rc into a transitional package? > > No, update-rc.d and invoke-rc.d still need to be provided by something. They *HAVE* to be provided by the active init system. They are an impedance matching layer (aka stable API) used by maintainer scripts to interface with the active init system. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140218234420.ga17...@khazad-dum.debian.net
Re: Ubuntu will switch to systemd
On Sat, 15 Feb 2014, Tollef Fog Heen wrote: > ]] Henrique de Moraes Holschuh > > Well, it is difficult to second-guess Shuttelworth, but the "tight coupling" > > is likely to be part of it. This was a non-issue with sysvinit (for Debian) > > and upstart (for Ubuntu), but with systemd we will have to get involved > > upstream. > > > > Debian and Ubuntu together have enough weight to affect systemd development > > somewhat, and more imporantly, enough resources to permanently maintain a > > fork should that ever become necessary (I have no reasons to belive it will > > happen, and I don't count minor distro-specific changes as a fork). > > You make it sound like we are not involved upstream and that we don't > already have weight to affect systemd development. Neither of those are > true. I didn't mean to imply Debian had no involvement or influence with systemd upstream, so thanks for clearing that up. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140215180235.ga9...@khazad-dum.debian.net
Re: Ubuntu will switch to systemd
On Fri, 14 Feb 2014, Noah Meyerhans wrote: > I'm not sure I understand why. Debian and Ubuntu have been using > different init systems for some time now, with Ubuntu on upstart and > Debian on sysvinit. Why should our change of defaults really matter to > them, when they weren't using our default anyway? > > Or might they be resigned to the "tight coupling" that Ian Jackson is so > worried about? As Debian becomes more tightly bound to systemd, using > something else may prove increasingly difficult. Well, it is difficult to second-guess Shuttelworth, but the "tight coupling" is likely to be part of it. This was a non-issue with sysvinit (for Debian) and upstart (for Ubuntu), but with systemd we will have to get involved upstream. Debian and Ubuntu together have enough weight to affect systemd development somewhat, and more imporantly, enough resources to permanently maintain a fork should that ever become necessary (I have no reasons to belive it will happen, and I don't count minor distro-specific changes as a fork). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140215150926.gc5...@khazad-dum.debian.net
Re: when will we finally throw away binary uploads (Re: Please upgrade your build environment when you are affected by transition
On Sat, 15 Feb 2014, Philipp Kern wrote: > That's why I was careful to publish the address nowhere. We do some Unfortunately, that cat is out of the bag, now. Whether it will get spammed or attacked, I don't know. However, it is not like we ever could trust the logs anyway for any security purposes, as they are not signed by the same key that signed the respective changes file for the upload. Currently, they're useful for debug purposes, and that's it (which is fine). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140215143421.gb5...@khazad-dum.debian.net
Re: [RFC] Cyrus SASL 2.1.26 experimental->unstable
On Thu, 30 Jan 2014, Roberto C. Sánchez wrote: > That said, I am curious if there would be any opposition to an upload of > cyrus-sasl2 2.1.26 into unstable. Aside from opposition, are there any > other comments that anyone would like to offer in regard to this? Well, it has to go to unstable eventually, doesn't it? Might as well do it now unless it would cause trouble with some ongoing transition. That said, it is probably a good idea to check upstream's git repo for fixes to 2.1.26. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140131123115.ga15...@khazad-dum.debian.net
Re: Valve games for Debian Developers
On Thu, 23 Jan 2014, Zlatan Todoric wrote: > Can now be a reason for becoming a DD - I want to get free Valve games? :) Well, a lot of time ago we had to make sure people wanted to be a DD for a reason other than the @debian.org email address... I don't see how dealing with people who just want Valve games would be any different :-) -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140123110822.ga10...@khazad-dum.debian.net
Re: CUPS is now linked against OpenSSL
On Tue, 14 Jan 2014, Jakub Wilk wrote: > * Daniel Kahn Gillmor , 2014-01-13, 23:03: > >if the only axis we're measuring along is cryptographic security, > >then protecting against passive attackers (eavesdroppers) is > >clearly better than not doing so. > > > >but if people think that CUPS' TLS protects them against active > >attackers, and they use that to do things like send confidential > >information over the link, they have been lulled into a false > >sense of security. > > Hear, hear. > > So, how would people feel about the following policy: > > TLS clients must either: > - validate server certificates; > - or prominently document that they don't do that? As in log "unsafe TLS connection to "? Because anything less than that would not be effective at all. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140114114323.gb31...@khazad-dum.debian.net
Re: [RFH] !!SOS!! totally hosed init system
On Fri, 03 Jan 2014, Roger Leigh wrote: > If file-rc and/or the maintainer scripts somehow restored the links > incorrectly, then insserv will ignore the header and preserve your > customisations (not the link ordering, but the runlevels to start > and stop in). This would certainly be the cause of all the ... > > Anyway, is there a way to tell update-rc.d or insserv or whatever > > to just ignore the existing /etc/rc*.d/ structure completely and ... > "insserv -d" should revert to the defaults. And there's not usually > any reason to deviate from them. > > If not, you could remove the structure entirely and then try re- > running "insserv -d" again. We really should have an easy way to address "my system is screwed up, please remove the entire sysv-rc admin-configured state and recreate it from the LSB headers and override files, for all initscripts". While something rarely needed, it would help a great deal when it is in fact required... "insserv -d" helps, but apparently it doesn't do the full sysv-rc reset. You'd need to call it for every initscript, at the very least. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140103154608.ga20...@khazad-dum.debian.net
Re: [debhelper-devel] Bug#733045: Bug#733045: debhelper: Can debhelper make autotools-dev updating default behaviour?
On Tue, 24 Dec 2013, Joey Hess wrote: > Henrique de Moraes Holschuh wrote: > > Hmm? That's interesting, given that bug report I was cc'd (and which I later > > cc'd you asking about the -/_ thing) complaining that dh-autotools-dev-foo > > was not working because of that -/_ mismatch. > > Which I answered the same way. Crap, indeed you did but I was not CC'd, and your answer hit the bts *after* I had read the bug report (I didn't send my question to you right away, it was in my "postponed" folder for a while... and I didn't reread the bug report before sending). So, I "never got the memo" :-( No matter. I apologise for not being as dilligent as usual at being sure I was not being left out of the loop, and I am happy that in the end it all means there is no problem anywhere in dh or autotools-dev's contributed dh module. > > Is the -/_ fixup a long time feature of dh, already supported by stable's > > debhelper? > > The line of code in dh that does this is unchanged since the first > commit adding --with to dh. Very good. Thank you. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131224200506.gd12...@khazad-dum.debian.net
Re: Bug#733045: debhelper: Can debhelper make autotools-dev updating default behaviour?
On Tue, 24 Dec 2013, Julien Cristau wrote: > On Tue, Dec 24, 2013 at 15:15:13 -0200, Henrique de Moraes Holschuh wrote: > > On Tue, 24 Dec 2013, Wookey wrote: > > > 2) for dh packages: > > > adding --with autotools-dev to the dh invocation > > > > This is broken. debhelper modules are not allowed to use "-" in the name, > > the correct module name is "autotools_dev" as stated in the documentation. > > > Says who? As a random example, doko did, bug report #731248. Someone had already closed the bug through -done stating "not a bug", but I was obviously left out of the loop by that. I requested more details from doko, but Joey is in a better position to tell us whether it is a valid concern or not for old versions of dh/debhelper. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131224194810.gc12...@khazad-dum.debian.net
Re: [debhelper-devel] Bug#733045: debhelper: Can debhelper make autotools-dev updating default behaviour?
On Tue, 24 Dec 2013, Joey Hess wrote: > Henrique de Moraes Holschuh wrote: > > On Tue, 24 Dec 2013, Wookey wrote: > > > 2) for dh packages: > > > adding --with autotools-dev to the dh invocation > > > > This is broken. debhelper modules are not allowed to use "-" in the name, > > the correct module name is "autotools_dev" as stated in the documentation. > > > > Yeah, this is annoying, and a large pitfall. > > > > OTOH, anyone who suddenly notices his package had this bug, please take a > > moment to think about how it happened to pass that you never noticed your > > package build was not doing what you wanted it to... > > dh automatically fixes up dh-foo to dh_foo. Hmm? That's interesting, given that bug report I was cc'd (and which I later cc'd you asking about the -/_ thing) complaining that dh-autotools-dev-foo was not working because of that -/_ mismatch. Is the -/_ fixup a long time feature of dh, already supported by stable's debhelper? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131224193442.ga12...@khazad-dum.debian.net
Re: Bug#733045: debhelper: Can debhelper make autotools-dev updating default behaviour?
On Tue, 24 Dec 2013, Wookey wrote: > 2) for dh packages: > adding --with autotools-dev to the dh invocation This is broken. debhelper modules are not allowed to use "-" in the name, the correct module name is "autotools_dev" as stated in the documentation. Yeah, this is annoying, and a large pitfall. OTOH, anyone who suddenly notices his package had this bug, please take a moment to think about how it happened to pass that you never noticed your package build was not doing what you wanted it to... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131224171513.ga8...@khazad-dum.debian.net
Re: Need some guide with LSB core
On Wed, 18 Dec 2013, Ian Jackson wrote:
> Bas Wijnen writes ("Re: Need some guide with LSB core"):
> > On Sat, Dec 14, 2013 at 08:27:45PM +0530, V.Krishn wrote:
> > > Conforming scripts shall not specify the "exit on error" option (i.e.
> > > set -e) when sourcing this file, or calling any of the commands thus
> > > made available.
> >
> > From the bugs you cite, the consensus in Debian seems to be that this is
> > an unreasonable requirement which leads to buggy code. However, since
> > it is a requirement, we follow it and try to be very careful to avoid
> > bugs.
...
> LSB is, after all, a specification for third-party packages. init
> scripts written for Debian are first-party and can be Debian specific.
Yes. And we do know better than provide system-wide shell script functions
for initscript usage that croak under "set -e", so there is no such
requirement for Debian.
If anything in the *Debian-provided* initscript helpers (which does include
some of the LSB compatibility layer) croaks under "set -e", please file a
bug so that it can be fixed.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131218162521.ga8...@khazad-dum.debian.net
Re: Is GCC really wrongly optimizing code leading to several bugs and vulnerabilities?
On Sun, 24 Nov 2013, Thomas Goirand wrote: > I haven't checked for these facts myself due to lack of time, which is > why I just post here. I think this paper is interesting anyway, and > worth sharing. I read that paper sometime ago, and as far as I recall, it mostly deals with C code that has undefined behavior by the spec, so it is not about gcc doing things wrong. It is about C being an extremely hard language to get right, because it has a ton of "undefined" situations way too many C coders are not aware of, nor paying sufficient attention to. Obviously, the results of a C statement depending on undefined behavior can change when the compiler, compiler version, or optimization level changes. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131124134648.gb3...@khazad-dum.debian.net
Re: Any news from the debian-ctte?
On Fri, 22 Nov 2013, Russ Allbery wrote: > positions complete. The only ones we haven't heard from are the sysvinit > and OpenRC position statement maintainers. Hmm, sysvinit as in "init" or as in "sysv-rc + insserv" ? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131124005417.gb19...@khazad-dum.debian.net
Re: Bug#729660: ITP: xemacs21 -- highly customizable text editor
On Tue, 19 Nov 2013, Russ Allbery wrote: > Henrique de Moraes Holschuh writes: > > On Sun, 17 Nov 2013, Russ Allbery wrote: > > >> Yeah, I know, which is part of why I used it for an example. I looked > >> at it yesterday and will probably adopt it at some point when I have > >> enough free time to do a proper job on the initial upload. > > > File an ITA bug on nvi with that paragraph, please. > > An ITA bug on nvi will block someone else who wants to adopt it, and > therefore I don't plan on doing that until I'm actually ready to commit to > adopting it myself. In the meantime, the orphaned status is correct. It shouldn't, as long as you title it appropriately and explain that, should someone else want it, they're welcome. something like: "ITA: nvi (if someone else wants to adopt it, please do)" > I read debian-release and debian-qa, so hopefully I'll notice if someone > starts looking seriously at removing it from the archive. I'll also copy > this message to the O bug. Yeah, that should help. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131119232721.ga7...@khazad-dum.debian.net
Re: Bug#729660: ITP: xemacs21 -- highly customizable text editor
On Sun, 17 Nov 2013, Russ Allbery wrote: > Sune Vuorela writes: > > On 2013-11-16, Russ Allbery wrote: > >> If someone proposed to remove nvi from the archive because vim is > >> better, I would be quite annoyed. If it ever did get removed from the > >> archive, I would probably adopt it and reintroduce it, because nvi is > >> the editor that I'm used to for small files and for root editing tasks, > >> I want to keep using it, and none of the things that are wrong with it > >> are fatal for that usage. > > > Note that nvi is orphaned, no removal could happen given that many > > people thinks vim is better. > > Yeah, I know, which is part of why I used it for an example. I looked at > it yesterday and will probably adopt it at some point when I have enough > free time to do a proper job on the initial upload. File an ITA bug on nvi with that paragraph, please. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131119171150.ge20...@khazad-dum.debian.net
Re: Two new DNS virtual packages (authoritative-name-server & recursive-name-server)
On Tue, 22 Oct 2013, Russ Allbery wrote: > > I would suggest: caching-name-server > > That's basically what a recursive-name-server is. I don't think the > application should care whether it caches locally or not; that's up to the > local administrator. Almost every recursive resolver does caching, to the point that anything that needs a remote caching namerserver can expect it to just exist. Usually, the worst you can expect is two levels: local-system -> crap SOHO device DNS proxy -> DNS recursive server with caching. When something actually bothers to specify that it wants a caching name-server, it means a close-by (latency-wise) caching name-server, or an exclusive caching nameserver. Heck, mail clusters often need an hierarchy of a local high-performance caching resolver per node AND a cluster-wide pair of full-blown high-performance caching recursive resolvers and private authoritative resolvers (for the RBL feeds). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131022172329.gb...@khazad-dum.debian.net
Re: Moving conf file from one package to another
On Tue, 22 Oct 2013, Ondřej Surý wrote: > Also thanks for the *.maintscript, I have missed that the dh_installdeb > can use it. Yeah, it is pretty cool! What I can't find is the information of the required versioned build-dependency on debhelper itself (or debhelper compatibility level) to ensure the package builds correctly :( This is usually listed in the debhelper manpages, but in this case either that detail was forgotten, or I am failing to look at the right place for the information (other than hunting it down in the debhelper change logs, I suppose). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131022170310.ga...@khazad-dum.debian.net
Re: skipping bioinformatics on some architectures ?
On Sat, 19 Oct 2013, peter green wrote: > If a release architecture is getting behind on building on a long > term basis then IMO either more buildd hardware should be obtained > or the port should lose it's release status. > > But that isn't what we are talking about here, we are talking about > an architecture that was kicked out of testing and kicked out of the > official archive years ago, degraded to an almost unusuable state > and is now attempting to become usable again. For them it's > probablly far more important to build as many "important but not yet > built" pckages as possible than it is to make sure every package > they have built is up to date. Agreed. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131019150601.gf18...@khazad-dum.debian.net
Re: skipping bioinformatics on some architectures ?
On Fri, 18 Oct 2013, Thorsten Glaser wrote: > One thing I think we *can* do is to have debports wanna-build lower the > build priorities of some sections below what we currently have as “all > others”, which would mean that e.g. bioinformatics would still be built > but only after the rest (both out-of-date and uncompiled) was. Aurélien, > is this possible? Right now, we have the problem that an upload of a > previously compiled source package that’s “totally unimportant” will be > sorted before all source packages in state “uncompiled”. Only if we also get a waiver that allows testing to go out-of-sync for these arches. Otherwise, no thanks. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131019141005.ge18...@khazad-dum.debian.net
Bug#726393: general: Possible malware infections in source packages
On Fri, 18 Oct 2013, Thorsten Glaser wrote: > On Tue, 15 Oct 2013, Thijs Kinkhorst wrote: > > I'm still not sure why the virus contained in the source could not be > > replaced by the EICAR test signature. > > Because it’s not testing a virus scanner, but because the > specific RFC822 message in question exhibited multiple problems > in the code, due to the way it’s written/structured. Then we could just defang it for good, replacing most of the virus code with crap while preserving the "malformedness". -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131019140539.gc18...@khazad-dum.debian.net
Re: Propose Release Goals (delayed ;) - xz compression
On Fri, 18 Oct 2013, Guillem Jover wrote: > For example on one of my 64-bit systems, with 220481 paths installed, I > go from 62.8 MiB to 46.1 MiB max resident memory, a saving of 16.7 MiB. > That should compensate a bit for the slight increase in memory usage > from xz. This is great, thank you! -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131019140757.gd18...@khazad-dum.debian.net
Re: First autoremovals happen in about 8 days
On Tue, 08 Oct 2013, Geoffrey Thomas wrote: > Would this be addressed by building some mechanism (making tombstone > packages comes to mind, but there are many options) for apt to > prompt to remove packages that were removed in the archive? It is already addressed by the user-oriented package management frontends. E.g. aptitude lists them separately. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131008234424.gb...@khazad-dum.debian.net
Re: think twice before enabling -D_FORTIFY_SOURCE=2 for C projects without thorough build-time testing
On Wed, 25 Sep 2013, Adam Borowski wrote: > On Wed, Sep 25, 2013 at 09:38:18AM -0700, Russ Allbery wrote: > > Thorsten Glaser writes: > > > Russ Allbery debian.org> writes: > > Programs that don't check the return status of functions that they think > > won't ever fail are a bit of a pet peeve of mine, in part because it would > > make a lot of sense for localtime() to be able to fail when the question > > it was asked is undefined. But no one ever checks the return status of > > localtime() for much the same reason that you spell out for not checking > > the return status of crypt(), which means that localtime() is required by > > all this legacy code to return arbitrary nonsense instead of an error. > > __attribute__((warn_unused_result)) Too bad it won't work in this specific case, but one could use Coccinelle or another static checker tool to track down crypt() calls without a subsequent test for NULL. That would still require a sweep on the source of the entire archive, though, as well as periodic testing to make sure the braidamage doesn't find its way back as new packages or new upstream versions. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130925193856.ga23...@khazad-dum.debian.net
Re: think twice before enabling -D_FORTIFY_SOURCE=2 for C projects without thorough build-time testing
On Fri, 20 Sep 2013, Daniel Pocock wrote: > On 20/09/13 22:09, Bastian Blank wrote: > > I would call code that hits such clear definitions too buggy to be > > supported. > > and what if many more existing packages are found to have similar issues? IMHO: fix everything gcc, llvm and the static testers complain about (which can be quite troublesome, as you must be *sure* you're actually fixing the issue instead of making it worse by silencing the warning without fixing a real bug). And never mind the amount of false positives, which you also need to make sure are actually false :( If you cannot do it, bug upstream until they fix it. I'd also manually check every instance of (at the very least) memcopy, *printf, and friends, and run a batch of tests (i.e. use the program) under valgrind and other such dynamic behaviour checking tools. And if you find out it is too buggy to live, well, do the right thing and kill it from Debian (or punt it to experimental) until it gets better. > One of my packages has some nice colours: > > http://debile.debian.net/source/fred/resiprocate/1.8.12-4/1 I'd recommend checking manually either all or a decent group of the issues related by those tools (some are really prone to false positives), and if the issues are not false positives, I'd say take it upstream ASAP. IMHO, in that case you should also nuke it from Debian jessie until the code gets a really through check against incompetent[1] coding. A SIP stack is very security sensitive... if upstream doesn't know enough C to refuse code that depends on undefined behaviour, that cannot end well. [1] no derision intended: the amount of pitfalls in the C standards makes it *really hard* to be competent at coding in C. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130921010136.ga6...@khazad-dum.debian.net
Re: packaging data that can't be distributed as part of a Debian package
On Fri, 20 Sep 2013, Faheem Mitha wrote: > So, I suppose anyone using the software needs to download it. I'll > provide a script to download the data, but if I want to build a > Debian package containing that data, how should I do it? Maybe studying other download-and-package packages, like "java-package", can help. In your case, apparently you can automate the "get the data file" part, which java-package is forbidden to do. > Let's say I have the software source directory with a script in it > which downloads the data files to a specific directory. When should > this download happen? Should the user do it manually? Manually is good. > I still don't have a license for those data files, but is that Ok if > the package does not distribute it? Probably yes, but it is safer for everybody if the source of the datafile publishes a license with its terms of use/distribution. > The response I got when asking for license information was > > IMGT ® data are publicly available on the IMGT® web site for academics > for their own research, but they are not redistributed by users. Check the website for a proper "terms of use" page and use it as the license... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130919231007.ga19...@khazad-dum.debian.net
Re: Custom Reload command/signal in upstart
On Fri, 23 Aug 2013, John Paul Adrian Glaubitz wrote: > No, it's not. It's the only reasonable thing to do. Nothing is safer > than a daemon which is *not* running. The fewer services are running, A daemon which is not running but which can be made to run by an unpriviledged connect() is as good as running for most purposes. Maybe it will not be subject to random memory corruption and cold memory attacks, but whether that (and less usage of system resources) are a good enough reason to increase service latency and create a trivial way to exploit races and resource contention at daemon startup is likely the subject of a careful case-by-case analysis. Now, a *disabled* daemon which requires explicit *local* priviledged action to start, that will, indeed, reduce the window of opportunity for an attacker a great deal. > That's non-sense. The time a process is started doesn't have any > influence on the security of the service. If it does, this should Systems are really not nearly as compartimentalized as you seem to think they are. There are several attacks that leverage a service start at exactly the wrong time to widen or open security holes in that service enough to have better chance of exploiting them (typically either because of race conditions, or bugs in error paths dealing with resource allocation). > If you don't need something, turn it off. THAT is correct, as long as by "turn it off" you mean "disable it". Otherwise, it depends. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130824172039.ga32...@khazad-dum.debian.net
Re: new hashes (SHA512, SHA3) in apt metadata and .changes files?
On Sat, 03 Aug 2013, Ondřej Surý wrote: > [IANACryptoguy] As far as I understand the MD5 attacks the length doesn't > matter. You just need to pick the package big enough to hold your evil > content and the "filling" which you use to compute the same MD5 (e.g. > collision vulnerability). I think that the lengths of the files do not add > enough bits. For length to make a sucessfull collision attack considerably harder, your signature must include the length, i.e. it should be something like "hash, length", not just the hash. I.e. you need to know the length of the original message/data somehow, not just its hash. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130803173235.gc10...@khazad-dum.debian.net
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On Sun, 14 Jul 2013, Russ Allbery wrote: > I've been administering UNIX systems professionally for 20 years, from > SunOS and ULTRIX through AIX, HP-UX, IRIX, Solaris, and Linux. In my > professional, *experienced* opinion, proper deployment of a modern init > system will make Debian considerably more robust, simpler to develop, and > simpler to administer. How much of that improvement would be realised if we added a dependable, declarative (i.e. config-based instead of shell-script-based) service configuration support to sysvinit ? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130715195018.ga7...@khazad-dum.debian.net
Re: boot ordering and resolvconf
On Wed, 12 Jun 2013, Wouter Verhelst wrote: > On 10-06-13 18:36, Ian Jackson wrote: > > B. resolv.conf is not static and may change due to network > >environment changes. > > Implications: > > 1. All existing DNS applications must be modified to notice > >changes to resolv.conf. > > 2. Corollary: all existing DNS resolver libraries must be > >so modified. > > 3. This will be impractical unless a common mechanism with > >a convenient interface (and low impact on the rest of a > >program) is provided. Hopefully resolvconf fits this bill. > > > > I don't know exactly how impractical B2 is. The libc's resolver is > > probably a hard case because of the libc's low level in the protocol > > stack. Can we make it aware of resolvconf ? > > You can replace it (through nsswitch.conf) by lwresd, which can easily > be restarted when resolv.conf is updated. I've been using lwresd for a long time (2+ years), and it isn't very reliable. I don't think it is widely used at all, we'd need to talk to upstream about it and probably hit lwresd hard to flush out the worst bugs. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130615220446.ga10...@khazad-dum.debian.net
Re: Survey answers part 1: systemd has too many dependencies, …
On Mon, 10 Jun 2013, Thomas Goirand wrote: > On 06/10/2013 03:21 AM, Michael Stapelberg wrote: > > Thomas Goirand writes: > >> In this blog post, you tell that it's possible not to use all the > >> components of systemd. Then, the immediate question that pops to my > >> mind: what are *your* intentions then, in Debian (or, said in another > >> way, what would you like to do if you where the only one to decide)? > >> Would you like to remove some components, or keep them all by default? > > I don’t understand the intention behind that question. Could you clarify > > so that I can give a proper answer please? > > Let's say you decide. Let's say you set systemd by default in Debian. > > Then which component would you install, and activate by default? Which > component will you make only installable if the user decides to do it > actively (for example using apt-get install)? That is an uninteresting option. There is no way we can afford to have two different sets of features for PID 1 under the same name in Debian without it causing support trouble we don't need. So, please assume that every "optional" PID 1 feature of systemd will be compiled in, and that only stuff that can be disabled at runtime might be disabled. It would be best to enhance http://people.debian.org/~stapelberg/docs/systemd-dependencies.html with information about what runs on PID 1, and what runs after fork() and how critical it is. Also, it is extremely important to track down the full library dependency chain for the systemd executable that runs as PID 1, and include any library initialization code found in the entire chain in the analysis, otherwise the analysis will be too incomplete to base any decisions on. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130610182334.gb28...@khazad-dum.debian.net
Re: GNU config (config.sub/guess) is now GPLv3 with additional permission
On Sat, 01 Jun 2013, Jakub Wilk wrote: > * Henrique de Moraes Holschuh , 2013-05-31, 18:44: > >As a special exception to the GNU General Public License, if you > >distribute this file as part of a program that contains a > >configuration script generated by Autoconf, you may include it > >under the same distribution terms that you use for the rest of > >that program. > > So I can distribute this file under the terms of GPLv2, but only if > $something. What about §6 of said license? (“You may not impose any > further restrictions on the recipients' exercise of the rights > granted herein.”) Well, the $something is "you don't change the build system to stop using autoconf while still retaining config.sub or config.guess". I am not sure it matters at all (clearly upstream seems to think that it should/might), but I'd be very hard pressed to think that $something is enough to be a problem for GPLv2. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130531224607.gb15...@khazad-dum.debian.net
Re: GNU config (config.sub/guess) is now GPLv3 with additional permission
On Fri, 31 May 2013, Josh Triplett wrote:
> On Fri, May 31, 2013 at 06:44:00PM -0300, Henrique de Moraes Holschuh wrote:
> > Upstream has changed the license to GPLv3. It has an additional
> > permission to negate any "viral effects", but it only applies to
> > packages that include a configuration script generated by GNU
> > autoconf.
> [...]
> > Here is the new license text for config.sub and config.guess:
> [...]
> >As a special exception to the GNU General Public License, if you
> >distribute this file as part of a program that contains a
> >configuration script generated by Autoconf, you may include it under
> >the same distribution terms that you use for the rest of that
> >program. This Exception is an additional permission under section 7
> >of the GNU General Public License, version 3 ("GPLv3").
>
> Interesting choice of wording. Read literally ("generated by
Indeed.
> Autoconf"), this would mean that the exception only applies when you
> distribute config.guess or config.sub as part of a source distribution
> that includes the generated configure, not just the input configure.ac.
> Which should be the case for most source distributions, but it still
> seems interesting.
>
> And on the flip side, you could also trivially satisfy this by including
> a generated configure script that doesn't actually get used.
Yes. It is not exactly an watertight wording.
I expect this license might be further updated to correct these points,
it is not like we don't have to update config.sub/guess at least once an
year...
So I advise people to stick to the obvious intention behind the license
change, which is that GNU config is to be used by GPLv3 packages and
also by packages that use GNU autoconf/automake regardless of their
license.
> In any case, this seems like something we could easily scan for with
> lintian or with any of the automatic whole-archive source scanning
> tools: just look for a source package that contains config.sub or
> config.guess but does *not* contain a configure script (or whose
> configure script does not contain "Generated by GNU Autoconf" in its
> first few lines).
I will file a bug report with upstream to the effect that the license
should allow distribution under a different license in any case where
GNU autoconf or GNU automake is used, even if the configuration scripts
have not been generated yet.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2013053137.ga15...@khazad-dum.debian.net
Re: DPA instead of PPA
On Thu, 09 May 2013, Steve McIntyre wrote: > In article <518b7cf6.3080...@debian.org> you write: > >On 09/05/13 07:38, Raphael Hertzog wrote: > >> bikeshed \o/ > > > >You probably meant this to be a comment on the discussion rather than a > >suggested name, but "until it gets uploaded to unstable, you can get > >GNOME 3.8 from the GNOME Team bikeshed" actually sounds like a > >reasonable sentence to write. :-) > > +1 for the "bikeshed" name. I think it's a *perfect* fit! :-) At least for "PPAEXT", it really fits... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130510022018.ga18...@khazad-dum.debian.net
Re: RFC: initramfs-tools support for early firmware loading
On Tue, 23 Apr 2013, Julien Cristau wrote: > On Mon, Apr 22, 2013 at 19:23:50 -0300, Henrique de Moraes Holschuh wrote: > > As of Linux kernel 3.9, support for supplying early firmware data to the > > kernel has been added. Currently, it is used for early microcode updates > > for Intel processors, and ACPI table overrides. > > > > This is a very important feature, that we should support as soon as > > practical. ACPI table overrides can massage less-than-stellar firmware into > > something usable, and early CPU microcode update are the only way (other > > than a BIOS upgrade) to avoid certain CPU defects. > > > > To supply early firmware data to the kernel, we have to *prepend* an > > uncompressed cpio archive to the initramfs image. The initramfs image > > itself can be compressed as usual. > > > > Currently, initramfs-tools has undocumented support for appending data to > > the initramfs image. This is now useless. We need to enhance > > initramfs-tools to support adding arbritary files to a cpio archive that > > needs to be prepended to the initramfs image. > > > Seems a bit odd that you're sending a mail about initramfs-tools to two > mailing lists, none of which are the initramfs-tools maintainer? (Hint: > that would be initramfs-to...@packages.debian.org, aka > debian-ker...@lists.debian.org) Meh, my bad. I will repost there, and drop debian-boot. Thanks! -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130423232637.ga13...@khazad-dum.debian.net
RFC: initramfs-tools support for early firmware loading
As of Linux kernel 3.9, support for supplying early firmware data to the
kernel has been added. Currently, it is used for early microcode updates
for Intel processors, and ACPI table overrides.
This is a very important feature, that we should support as soon as
practical. ACPI table overrides can massage less-than-stellar firmware into
something usable, and early CPU microcode update are the only way (other
than a BIOS upgrade) to avoid certain CPU defects.
To supply early firmware data to the kernel, we have to *prepend* an
uncompressed cpio archive to the initramfs image. The initramfs image
itself can be compressed as usual.
Currently, initramfs-tools has undocumented support for appending data to
the initramfs image. This is now useless. We need to enhance
initramfs-tools to support adding arbritary files to a cpio archive that
needs to be prepended to the initramfs image.
The kernel cpio parser is very dumb: it will happly grok unterminated
cpio archives[1], which allows us to prepend any number of such
quasi-cpio archives to the initramfs. This would be very easy to implement,
in a similar way to the undocumented "catenate_cpiogz" functionality.
However, producing unterminated cpio archives require special tools.
I *think* the kernel will also happly skip any EOF cpio records
("TRAILER!!!" records), which would allow for prepending any number of
regular cpio archives created with a suitably small block size. But this is
not set in stone, if we want it to be that way, I'd have to request it. And
I would have to request it *really* *soon*.
Alternatively, we'd have to reserve a filesystem tree somewhere (probably
/boot or /etc) and generate the early firmware cpio archive if it contains
any files. This is easy enough to do, however it is also a lot less
flexible than allowing dynamic generation of quasi-cpio archives by the hook
scripts.
I am volunteering to write any required tools and patches (including kernel
ones), but I want a second opinion on which way should we take: dynamic
generation, or cpio of an static tree somewhere in /boot or /etc ?
[1] the kernel wants a cpio archive in the 0x070701 format ("newc"), and
doesn't care for the "TRAILER!!!" EOF marker.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2013042350.ga4...@khazad-dum.debian.net
Re: upgraded systems won't boot from UUID volumes
On Sun, 07 Apr 2013, Ben Hutchings wrote: > So it seems that this is only going to be an issue if users take the > unusual step of changing /etc/fstab to refer to LVs by UUID. But maybe > there are management tools that do that as a matter of course? One should never use UUIDs in fstab to refer to non-unique filesystems (which is pretty much a normal thing with LVM, as the use of snapshotting is common). Any management tools that screw this up need a reality check (and post-haste bug fix). Doing otherwise is courting a data loss scenario. We've seen it happen a large number of times over the years because of the md 0.90 layout, until userspace tools started to add defensive layers to make it less likely to happen. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130408004345.ga14...@khazad-dum.debian.net
Re: git dangerous operations on alioth
On Thu, 28 Feb 2013, Holger Levsen wrote: > signed commits, so you can identify unwanted bits and clean up in the very > care case that's actually needed? Indeed. Secure git workflows are possible, although it is a relatively new development. Signed commits and pull requests are a very big part of such workflows... http://mikegerwitz.com/docs/git-horror-story.html -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130301004920.ga7...@khazad-dum.debian.net
Re: Backports upgrade policy (ButAutomaticUpdates:yes)
On Fri, 25 Jan 2013, Wookey wrote: > +++ martin f krafft [2013-01-25 16:06 +1300]: > > also sprach David Kalnischkies [2013.01.25.0020 > > +1300]: > > > You can find much of the same discussion in the bugreport requesting > > > implementation of this feature in APT: #596097 > > > > Thanks for the pointer! I missed this discussion un^Wfortunately. > > Anyway, it seems that most people are in favour of this change, and > > your message pretty much sums up the reasons. > > You message was not usless as I never knew about the 100 < P < 500 > feature, and the need to pin/not pin according to what effect you > wanted vs AutomaticUpdates setting. Making this info more widely known > would be a useful service so that people get the behaviour they want. > > (maybe it already is and I'm the only one no-one told, but I doubt it > :-) Sorta. It is in manpage apt_preferences(5), but... Now, complete documentation of the Release files, where the tags you can use in repositories to get such nice functionality like ButAutomaticUpdates... Does anyone know where such a thing might dwell? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130125131900.ga29...@khazad-dum.debian.net
Bug#697270: PC 32-bit programs fails to work on amd64
On Thu, 03 Jan 2013, Alexey Eromenko wrote: > On Thu, Jan 3, 2013 at 8:05 PM, Didier 'OdyX' Raboud wrote: > > > > release and lsb-base being Architecture: foreign). Patches are welcome to > > make > > Wheezy+1 more suitable to your needs. > > How about changing it from a kernel bug to tasksel feature ? > > I recommend: "tasksel" to install 32-bit libraries by default, if user > chooses stock "Desktop" (KDE/GNOME/XFCE/...). This should solve the > problem for most users. This is actually a very good idea. Automatically generate the library subset of a task, teach tasksel to add the required arch tags, and make it as easy as a checkbox or a command line option to add most of the libraries you might ever need for a secondary arch. This could go a long way to make it less painful (if a _lot_ more wasteful of inodes and disk space) to deal with 32-bit non-debian applications. That said, for now, it is best to learn how to use the "ldd" utility to root out missing libraries for any binary. It *really* helps. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130103194624.ga2...@khazad-dum.debian.net
Re: "Do not CC me"
On Mon, 26 Nov 2012, Jakub Wilk wrote: > * Dmitrijs Ledkovs , 2012-11-26, 00:19: > >If your e-mail processing machinery cannot handle duplicate > >messages (due to cross-postings and CC's), maybe you should get an > >a better email processing machinery. Receiving duplicate emails is > >inevitable, and trivial to deal with. > > Oh really? I've always wondered how is this supposed to work. Well, the software to do it is around for more than 15 years. Google for "procmail duplicate suppression". Basically you keep a database of the message-ids seen in the last "n" days, and don't deliver them again. You do it per-folder or system-wide or in whatever way you want, by using separate databases. Nowadays there is an added aggravation: if anyone worth of notice uses Outlook, you need to key on envelope sender+recipient+message-id to work around some atrocious bugs in Outlook's message-id handling. I just store everything in Cyrus IMAPd 2.4, and tell it using a folder annotation whether it should drop or store duplicates that end up sorted to that folder. > Let's imagine I received a mail, read it, decided it's not > important, and deleted it. 5 minutes later another mail with > different contents and headers but the same message-id is received. > How do you deal with such situation "trivially"? Do you have some > kind of AI to decide whether this is the "same" message or not? A duplicate suppresion database does not even require a state machine, let alone an AI... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121126011227.ga21...@khazad-dum.debian.net
Re: Canonical pushes upstart into user session - systemd developer complains
On Sun, 25 Nov 2012, John Paul Adrian Glaubitz wrote: > On Sun, Nov 25, 2012 at 10:48:27PM +1300, Chris Bannister wrote: > > https://lists.linuxaudio.org/mailarchive/lau/2012/11/21/194431 > > > > There is a rather bad smell regarding all this. > > None of the systemd advocates ever mentioned for example the real > reason why it uses such an ugly configuration syntax and Windoze > format files.^^^ The: [crap] foo = bar format for config files is widely despised. And this is not a systemd issue, even git uses that crap instead of something better like xml, or simpler, like the hierarchical format used by apt that resembles C++ classes. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121125150623.ga8...@khazad-dum.debian.net
Re: the right bug severity in case of data corruption
On Sat, 24 Nov 2012, Christoph Anton Mitterer wrote: > This however leads to irrecoverable data corruption, as the partial > quoting of so called From_ lines cannot be undone anymore. > An easy solution for that dilemma is known for years, namely the other > mbox formats (either mboxrd, mboxcl or mboxcl2), of which mboxrd is > typically the one which fits best the needs for staying backwards > compatible. ... > No first I've had reported these corruptions at the different upstreams > (and apart from KMail and mutt...all the major players I've tested, e.g. > Thunderbird, Evolution, getmail, postfix, were affected). ... > Apart from the getmail upstream all reacted rather stubborn and without > much insight,... bringing up obscure "arguments" like "this corruption > has always been the case historically, therefore it's ok". At least for postfix, I'd expect them to accept a patch for local(8) to not quote From lines as a config option, with the default being to keep the current behaviour (i.e. quote them). > Well we, as Debian, can't of course force upstreams to fix their crap, > but IMHO neither should we let our users at risk for silent data > corruption. > > So I've opened bugs at the BTS, too, with severities critical Look, if it were severity critical, given how long this situation stands, we'd not have this thread and nobody would be doing this. It is severity important or normal, I'd say. In postfix' case, it is documented like all heck, for example (see local(8) manpage), and it can trivially be configured to use something else to deliver mail to mbox files (such as procmail, etc). > So,... bringing this up here at d-d, as I think it would be good for > Debian to have a well thought position in how to handle this family of > corruption bugs... We [Debian] could deprecate anything that uses mboxo (mbox old) format as the native/preferred storage format, and configure our stuff where possible to never use mboxo by default. That's about it. But first, you need to get support for better mbox formats on the important stuff. We [users/developers] can write patches to teach important software to use something less retarded than mboxo by default, and pester upstream to take them. Just complaining about it obviously won't help, since people don't see it as a problem at all. You need to do _all_ the leg work, write the new functionality, and test the heck out of it before you can really expect upstream to accept the change. > If not, than the majority opinion might perhaps even convince the > maintainers to handle this with some higher severity :) That's not how it works. Someone needs to come up with *well tested* patches for everything worth fixing. THEN you can ask for some sort of Debian-wide pressure to get rid of mboxo outside of extra/old-libs... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121125002747.ga17...@khazad-dum.debian.net
Re: Source-only uploads (was: procenv_0.9-1_source.changes REJECTED)
On Tue, 20 Nov 2012, Dmitrijs Ledkovs wrote: > I am sorry, if I was not clear. I am aware of the "last iteration", > but I am not enquiring about the default policy within debian as to > how we should upload by default. > I am asking why, when I had a reason to do so, was not able to do a > source-only upload. > Is this a feature of dak, or a policy enforcement? Both. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121120122309.gb22...@khazad-dum.debian.net
Re: Question: Packages.xz and Contents-.xz
On Thu, 15 Nov 2012, Peter Samuelson wrote: > [Hideki Yamane] > > > henrich@hp:/tmp$ du -k Packages.* > > > 6052 Packages.bz2 > > > 5812 Packages.xz > > > henrich@hp:/tmp$ time bzip2 -d Packages.bz2 > > > > > > real 0m0.999s > > > user 0m0.956s > > > sys 0m0.020s > > > > > > henrich@hp:/tmp$ rm Packages > > > henrich@hp:/tmp$ time xz -d Packages.xz > > > > > > real 0m0.565s > > > user 0m0.532s > > > sys 0m0.032s > > > > > henrich@hp:/tmp$ time gzip -d Packages.gz > > > gzip: Packages already exists; do you wish to overwrite (y or n)? y > > > > > > real 0m1.932s > > > user 0m0.272s > > > sys 0m0.012s > > While your post has good points, we need to notice that because of the > interactive prompt, the 'real' time value for gzip -d is misleading. > > > decompression speed is > > best : xz > > second: bz2 > > third : gz > > If you ignore the time gzip spent waiting for you to type 'y', it is > the fastest, not the slowest. Yes, gzip is the fastest decompressor (measured by input ratio or user time). However, when there is a major difference in compression ratio or the input ratio is low because of external factors (e.g. low bandwidth), a stream with much higher compresison rate and a slower decompressor can still be much faster when you measure the output ratio. I.e. it will use more cpu time/energy, but it will finish the job sooner. gzip is really fast and widely supported, and it also has much lower worst-case memory requirements (xz isn't a memory pig when decompressing, but how much memory it needs depends on the input stream and the worst case is 6 times the best case, at ~63MiB). However, xz compresses so much better, it is not funny. We should keep both. bzip2 should be deprecated (i.e. we should transition to xz). We keep bzip2 as standard because there is way too much .bz2 around, but we start generating .xz instead of .bz2 when we can. I've found that data which depends on large windows *and* sub-window reordering to compress at its best does _really_ well in xz, and hideously in gzip and bzip2. Play with the "intel-microcode" Debian source package and several compressors, and you will see what I mean. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121116141346.ga27...@khazad-dum.debian.net
Re: Question: Packages.xz and Contents-.xz
On Thu, 15 Nov 2012, Guillem Jover wrote: > On Thu, 2012-11-15 at 17:11:02 +0100, David Kalnischkies wrote: > > 0.8.10.3+squeeze1 does as its changelog tells us. > > Note through that it needs the 'xz' binary for that (as it did for bzip2, > > that changed just yet with the usage of libbz2 now for wheezy and as > > usual people complain about it …). xz is priority required though so > > this is most likely not that much of an issue as it was for bzip2. > > Although xz-utils is currently priority required, it should really go > back to optional, as dpkg stopped Pre-Depending on it some time ago. More like it should be in standard nowadays, along with bzip2. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121115205609.gc18...@khazad-dum.debian.net
Re: Where could I upload x32 port bootstrap?
On Sun, 11 Nov 2012, Adam Borowski wrote: > On Sat, Nov 10, 2012 at 08:30:06PM +, Wookey wrote: > > +++ Steve McIntyre [2012-11-10 18:28 +]: > > > *If* we want to include x32, it's worth describing it and > > > understanding the potential benefits properly and getting some > > > benchmarks. There's been some work in Ubuntu on the benchmarking front > > > (as I saw mentioned in a session at UDS last week[1]), which should be > > > worth looking at. Hmmm, can't find any direct links to them, > > > though. :-( Maybe somebody else can fill in here? > > > > These were discussed at UDS: > > http://kernel.ubuntu.com/~cking/x32/Quantal-x32-power-memory-comparisons.ods > > > > comparing 64/64 64/32 32/32 kernel/userspace for various tasks, memory > > usage, power consumption, and duration where approporiate. > > How did this guy manage to run x32 on a "32 bit kernel"? It is comparing x32 (64/32) with full amd64 (64/64) and full ia32 (32/32). I am far more interested in x32 versus 64/32 using ia32, though. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2012005531.gb12...@khazad-dum.debian.net
Re: Where could I upload x32 port bootstrap?
On Sun, 11 Nov 2012, Ben Hutchings wrote: > On Sat, 2012-11-10 at 20:14 -0200, Henrique de Moraes Holschuh wrote: > > On Sat, 10 Nov 2012, Bastian Blank wrote: > > > On Sat, Nov 10, 2012 at 02:15:14PM -0200, Henrique de Moraes Holschuh > > > wrote: > > > > Yes, I know :) Our amavisd-box at work has 16GiB RAM and 16 cores, > > > > we need at least that much to be able to run 64 instances with the > > > > scratch directories on tmpfs... > > > > x32 would be most likely a _MAJOR_ win for that box. > > > > > > Is it _likely_ or is it? 16GiB can be used with the 32bit i386 also. > > > > I assume you mean a amd64-kernel with i386 userspace combination. > > > > Compared to x32, i*86 userspace on a 64-bit kernel has the added aggravation > > of the full kernel syscall compat layer, which has been a source of problems > > in the past, and all the wasted performance of our i486-optimized userland. > [...] > > The compat layer for x32 is almost entirely the same as for i386 on > x86_64; indeed it is almost entirely the same as Linux uses for *every* > 64-bit architecture that supports a 32-bit userland. I think the only > interesting difference is that x32 has 64-bit time_t. It has changed, then... I thought it used the 64-bit syscalls plus ~84 that were x32-specific, while ia32 had to go through compat for all syscalls... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2012005312.ga12...@khazad-dum.debian.net
Re: Where could I upload x32 port bootstrap?
On Sat, 10 Nov 2012, Bastian Blank wrote: > On Sat, Nov 10, 2012 at 02:15:14PM -0200, Henrique de Moraes Holschuh wrote: > > Yes, I know :) Our amavisd-box at work has 16GiB RAM and 16 cores, > > we need at least that much to be able to run 64 instances with the > > scratch directories on tmpfs... > > x32 would be most likely a _MAJOR_ win for that box. > > Is it _likely_ or is it? 16GiB can be used with the 32bit i386 also. I assume you mean a amd64-kernel with i386 userspace combination. Compared to x32, i*86 userspace on a 64-bit kernel has the added aggravation of the full kernel syscall compat layer, which has been a source of problems in the past, and all the wasted performance of our i486-optimized userland. Still, the performance should be close enough between the two for many workloads. We'd have to test it to know. Note that I am fine with x32 as a partial arch, but it better have all the pointer-heavy crap in it, such as perl, as well as anything that benefits greatly from the reduced register pressure, from SSE2 or from reduced pointer size due to cache footprint. If it is easier to have x32 as a full unofficial arch at first, and later decide whether it should be partial or not and what should be included, then let's go for the full unofficial arch... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121110221432.ga5...@khazad-dum.debian.net
Re: Where could I upload x32 port bootstrap?
On Sat, 10 Nov 2012, Peter Samuelson wrote: > > On Sat, Nov 10, 2012 at 10:47:43AM +0100, Adam Borowski wrote: > > > On the other hand, widespread dumb-ass assumptions about i386/amd64 may > > > cause quite a bit of issues: basically any Makefile that talks about "x86" > > > is somewhat suspicious. This is the main reason one may want to oppose > > > the inclusion of x32 in Debian, IMHO. > > [Andrey Rahmatullin] > > Can you elaborate? > > [Henrique de Moraes Holschuh] > > This is no worse than any other new arch. > > The new wrinkle is that, because x32 uses the x86-64 instruction set, > it defines preprocessor symbols associated with x86-64, and which a lot > of source code uses to differentiate between i386 and amd64. Thus, Which means a relevant, but not that large fraction of the packages will have to be fixed. Like I said, no worse than any other new arch. I hope less than 10% of the packages will cause trouble. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121110162616.gc17...@khazad-dum.debian.net
Re: Where could I upload x32 port bootstrap?
On Sat, 10 Nov 2012, Thomas Goirand wrote: > On 11/10/2012 08:15 PM, Henrique de Moraes Holschuh wrote: > > 3) Memory usage of some common server workload. E.g. email with > > amavisd-new+spamassassin (perl is a memory pig in amd64), or a LAMP stack > > with some common web application > Hi, > > I cannot tell for the other use cases, but for what's above, I can, > I have a long experience of running that. That's basically what I > sell (well, rent...) as a hosting platform to hundreds of customers > running on virtual machines. Yes, I know :) Our amavisd-box at work has 16GiB RAM and 16 cores, we need at least that much to be able to run 64 instances with the scratch directories on tmpfs... x32 would be most likely a _MAJOR_ win for that box. > This makes me think that it's been years that we should have switched > to using DSPAM and clam-smtp instead of amavis and spamassassin! :) IME, performance would tank, besides amavisd-new does so much more than what DSPAM+clam-smtp can do, it is not even funny. So, we take the memory hit. The next box for that job at work will have 24GiB of RAM and 32 cores, so that we can run 128 instances of amavisd-new. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121110161514.gb17...@khazad-dum.debian.net
Re: Where could I upload x32 port bootstrap?
On Sat, 10 Nov 2012, Adam Borowski wrote: > On Fri, Nov 09, 2012 at 11:27:20PM +0100, Marco d'Itri wrote: > > On Nov 09, Daniel Schepler wrote: > > > I've asked a couple people in private mail about this, and haven't > > > gotten any answer, so I thought I'd ask here for ideas. Where would > > > be a good place to upload what I have so far from bootstrapping an x32 > > > port of Debian? > > Nowhere, until we decide if and how we want to use x32. > > IIRC there was some agreement that if we decide to support x32 it should > > be as a partial architecture. > > That'd make it mostly worthless. If you need to co-install amd64 packages > on the same system (but not physical machine!), memory gains are gone. Can someone give us numbers? Using VMs or even the bare metal, it should be possible to gather some statistics about memory usage for x32 versus amd64 for: 1) Desktop running gnome or kde (or both, whatever) with iceweasel open on the www.debian.org page. 2) Maximum memory usage for a kernel, x.org or libreoffice build run. 3) Memory usage of some common server workload. E.g. email with amavisd-new+spamassassin (perl is a memory pig in amd64), or a LAMP stack with some common web application. This should give us a pretty clear idea, and could go a long way to prove the case for x32 as a full arch as far as memory goes. If someone knows of patological workloads (one that really doesn't benefit from x32, and one that benefits enormously from x32), those would be interesting data points as well. > Speed gains are far better than armel->armhf, at least for i386. Gains > compared to amd64 are limited to pointer-heavy code, said to be up to 30%. > If Daniel could upload his work somewhere, we'd be able to test this > ourselves instead of relying on some random benchmarks. Yes. > On the other hand, widespread dumb-ass assumptions about i386/amd64 may > cause quite a bit of issues: basically any Makefile that talks about "x86" > is somewhat suspicious. This is the main reason one may want to oppose > the inclusion of x32 in Debian, IMHO. This is no worse than any other new arch. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121110121528.ga17...@khazad-dum.debian.net
Re: What is the use case for Policy §7.6.2 ?
Hi Josselin! On Fri, 09 Nov 2012, Henrique de Moraes Holschuh wrote: > On Fri, 09 Nov 2012, Josselin Mouette wrote: > > It looks to me that we should strictly favor the transitional package > > approach instead. Shouldn’t we entirely forbid the > > Provides/Conflicts/Replaces combination way of handling upgrades, except > > for virtual packages? > > And instantly break even further the upgrade path of lots of > already-published packages? This is the sort of thing that might need a > deployment plan over two stable releases, it is probably better to find a > way to fix apt. Meh, never mind, it was a major thinko on my part, and I apologise. We could certainly keep the current support in the tools, but forbid the usage of the fields in that way for the future. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121109125322.gb8...@khazad-dum.debian.net
Re: What is the use case for Policy §7.6.2 ?
On Fri, 09 Nov 2012, Josselin Mouette wrote: > It looks to me that we should strictly favor the transitional package > approach instead. Shouldn’t we entirely forbid the > Provides/Conflicts/Replaces combination way of handling upgrades, except > for virtual packages? And instantly break even further the upgrade path of lots of already-published packages? This is the sort of thing that might need a deployment plan over two stable releases, it is probably better to find a way to fix apt. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121109124628.ga8...@khazad-dum.debian.net
Re: ANNOUNCEMENT: Intel/AMD x86 CPU microcode update system in non-free
On Thu, 08 Nov 2012, Christoph Egger wrote: > Peter Samuelson writes: > > ...But it does bring up the question of why intel-microcode and > > amd64-microcode are not built on kFreeBSD or the Hurd. Maybe those > > kernels lack a CPU microcode interface? > > http://www.freebsd.org/doc/faq/compatibility-processors.html > > Though I rather doubt the linux microcode framework and the FreeBSD one > are *that* easily compatible The datafiles should be identical, I think. So, if someone actually uses Debian/FreeBSD, has an AMD and Intel processor boxes that can take a microcode update (i.e. outdated BIOS/EFI), and wants to help, it should be possible to support it. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121108210120.ga16...@khazad-dum.debian.net
Re: ANNOUNCEMENT: Intel/AMD x86 CPU microcode update system in non-free
On Thu, 08 Nov 2012, Carlos Alberto Lopez Perez wrote: > On 06/11/12 17:05, Henrique de Moraes Holschuh wrote: > > Still, it did lead me to a possible cause: I am not trying to modprobe > > "microcode" in the intel-microcode postinst. This can indeed cause the > > failure to update microcode at package install time. > > > > I forget why I didn't do it that way in the first place, but that's easily > > fixed. Please file a bug, severity minor. I will check for any possible > > problems it might cause, and if I can't find any, I will fix it in unstable. > > Same here. > > Just installed intel-microcode and iucode-tool and it didn't worked > until I manually modprobed the microcode module. > > Just wondering... > > Perhaps you should add a file in /etc/modules.d/ to automatically load > the microcode module at start-up? It is indeed loaded on boot by the initramfs support, and it is also auto-loaded by the kernel in some situations. So, it will be fine after a reboot. Non-initramfs setups are supported in a limited fashion, and will require manual setup. This is properly documented in the package's README files in /usr/share/doc/intel-microcode/ or /usr/share/doc/amd64-microcode/. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121108161933.ga9...@khazad-dum.debian.net
Re: ANNOUNCEMENT: Intel/AMD x86 CPU microcode update system in non-free
On Wed, 07 Nov 2012, Adrian Fita wrote: > Fair enough, but how about having the linux-image packages recommend the > *microcode packages for installation so users won't get confused by the > message caused by the module trying to load the file with the microcode > update and not finding it? I don't think we can do that, because the -microcode packages are in non-free. And an annoying technical detail makes it suboptimal to add the microcode packages as a recommendation of the firmware-linux-nonfree package. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121107183300.ga6...@khazad-dum.debian.net
Re: ANNOUNCEMENT: Intel/AMD x86 CPU microcode update system in non-free
On Wed, 07 Nov 2012, Nikolaus Rath wrote: > Henrique de Moraes Holschuh writes: > >> > # iucode_tool --scan-system -vv > >> > iucode_tool: cpuid kernel driver unavailable, cannot scan system > >> > processor signatures > > > > Hmm, that should happen only if iucode-tool is installed/configured after > > intel-microcode. > > I've seen this message too, during the update-initramfs call. The initramfs hook does try to load the cpuid module before it runs iucode_tool. If it didn't load, the problem lies elsewhere. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121107145749.ga...@khazad-dum.debian.net
Re: ANNOUNCEMENT: Intel/AMD x86 CPU microcode update system in non-free
On Wed, 07 Nov 2012, Adrian Fita wrote: > My CPU is an AMD Turion(tm)X2 Dual Core Mobile RM-76, cpu family: 17, so > it doesn't need the amd64-microcode package which contains microcode > updates only for cpu families: 10h - 14h & 15h. But the microcode kernel Family 17 (decimal) is family 11h (hexadecimal). > module gets loaded regardless of the fact that my CPU doesn't need it. Linux loads drivers for the devices it supports. Your processor supports microcode updates, and the kernel does know how to apply them, so the microcode driver will load. Also, the modular microcode driver won't complain of missing firmware files if amd64-microcode is properly installed and working (the firmware files with the microcode will be there), so something is wrong. Are you using a custom kernel? was the initramfs for the running kernel properly updated by "update-initramfs -u" ? Are you using systemd? > So, shouldn't the microcode module be loaded only for the CPUs that need > it? I know I can blacklist the module from loading, but I think this > should be handled more elegantly - read automatically - by Debian so > users wouldn't have to manually fiddle with blacklisting modules. I It is not a very good idea to overcomplicate stuff that will break the boot process should it be buggy. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121107005052.gb5...@khazad-dum.debian.net
Re: ANNOUNCEMENT: Intel/AMD x86 CPU microcode update system in non-free
On Tue, 06 Nov 2012, Stephan Seitz wrote: > On Mon, Nov 05, 2012 at 06:12:53PM -0200, Henrique de Moraes Holschuh wrote: > >I would like to bring to your attention the improved support for system > >processor (CPU) microcode updates, for x86/i686/x86-64/amd64 systems > >that was recently added to [non-free] Wheezy. > > Alas, this will not work for XEN users because I can’t update the > microcode in Dom0 with xen-hypervisor 4.1. There exist kernel > patches (over a year old), but according to the xen-devel ML they > are not good enough to be included in the kernel. > > With XEN 4.2 the hypervisor can load the CPU microcode. Would this > be a reason to include XEN 4.2 in Wheezy? I wouldn't know, please ask the xen maintainers and the release manager about it. Maybe a backport of the relevant functionality is also a possible solution. What I do know is that lack of microcode update support is a severe issue IMO. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121106160840.gb25...@khazad-dum.debian.net
Re: ANNOUNCEMENT: Intel/AMD x86 CPU microcode update system in non-free
On Tue, 06 Nov 2012, Jon Dowland wrote: > On Mon, Nov 05, 2012 at 06:12:53PM -0200, Henrique de Moraes Holschuh wrote: > > Microcode updates will be applied immediately when the microcode > > packages are installed or updated: you don't have to reboot. You will > > have to keep the packages installed, though: as explained above, the > > microcode updates have to be reapplied at every boot. > > > > You can check which version of the microcode your processors are running > > by looking for "microcode" lines on /proc/cpuinfo. This information is > > only available on recent kernels (such as the Wheezy kernel). > > This did not appear to work for me automatically. I did not upgrade my kernel > in the same aptitude session. That can also happen if you upgrade it in a previous aptitude session, but didn't reboot yet. > Before: > > microcode : 0x1b > > After installing intel-microcode and iucode-tool 0.8.3-1: > > microcode : 0x1b > > > # iucode_tool --scan-system -vv > > iucode_tool: cpuid kernel driver unavailable, cannot scan system processor > > signatures Hmm, that should happen only if iucode-tool is installed/configured after intel-microcode. Still, it did lead me to a possible cause: I am not trying to modprobe "microcode" in the intel-microcode postinst. This can indeed cause the failure to update microcode at package install time. I forget why I didn't do it that way in the first place, but that's easily fixed. Please file a bug, severity minor. I will check for any possible problems it might cause, and if I can't find any, I will fix it in unstable. Still, those reports are very valuable. I will probably try to get some information about the microcode updates on the Wheezy release notes, and this thread will go a long way to make sure no pitfals are left behind. > > $ grep microcode /proc/cpuinfo > > microcode : 0x28 And that's why these packages exist... although you might want to check if your motherboard vendor has a BIOS/UEFI update available, as it is _always_ better to have microcode updated as early as possible, and that means the BIOS/UEFI. > Shall I file a bug? Please do. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121106160553.ga25...@khazad-dum.debian.net
ANNOUNCEMENT: Intel/AMD x86 CPU microcode update system in non-free
Hello all, I would like to bring to your attention the improved support for system processor (CPU) microcode updates, for x86/i686/x86-64/amd64 systems that was recently added to [non-free] Wheezy. System Processors from Intel and AMD may need updates to their microcode (sort of a control sequence for the processor) to operate correctly. These updates fix bugs/errata that can cause anything from incorrect processing, to code and data corruption, and system lockups. It is very difficult to know for sure whether you need a microcode update or not, but it is not safe at all to just ignore them. You might not notice their effect and have precious data silently corrupted, or an important program silently misbehave. Or you could experience one of those unexplainable and infrequent software issues (such as kernel oops, application segfaults) or hardware issues (including sudden reboots and hangs). Releases of new microcode updates are more frequent on young processors, but the release of new microcode updates for older processors do happen. The BIOS (or EFI) updates the CPU microcode during boot, however most of the time either the motherboard vendor won't issue frequent BIOS/EFI updates, or the user won't install such updates. For these reasons, the system processor is likely to be running with outdated microcode on a vast number of systems. The operating system has to pick up the slack. Unfortunately, the license of the microcode update data from AMD and Intel are not compatible with the Debian Free Software Guidelines. Therefore, microcode update data will be available through the non-free distribution. The new processor microcode update system is available for both non-free Wheezy and non-free Squeeze (through the backports repository). HOW TO INSTALL MICROCODE UPDATES: Processor microcode updates are ephemeral, and last only until the next processor reset or power off. They have to be reapplied at every boot, and also when the system wakes up from suspend or hibernation. Please install the "amd64-microcode" package (for systems with AMD processors), or the "intel-microcode" and "iucode-tool" packages (for systems with Intel processors). "iucode-tool" is available in "contrib", the other two packages are available in "non-free", so you will have to enable both contrib and non-free in /etc/apt/sources.list. Debian Squeeze users can find up-to-date versions of these packages in the official backports repository (in the contrib and non-free sections). Microcode updates will be applied immediately when the microcode packages are installed or updated: you don't have to reboot. You will have to keep the packages installed, though: as explained above, the microcode updates have to be reapplied at every boot. You can check which version of the microcode your processors are running by looking for "microcode" lines on /proc/cpuinfo. This information is only available on recent kernels (such as the Wheezy kernel). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121105201253.ga18...@khazad-dum.debian.net
Re: Discarding uploaded binary packages
On Thu, 18 Oct 2012, Arno Töll wrote: > On 18.10.2012 04:29, Paul Wise wrote: > > On Thu, Oct 18, 2012 at 10:20 AM, Russell Coker wrote: > >> We could have a lintian warning for any occurance of the string "/home" in > >> a > >> packaged file and have error conditions for "/build" and the current value > >> of > >> $HOME for the account running lintian. > > > > Based on a quick grep of /usr/bin on my laptop, this is going to have > > a fair number of false positives; commented out paths, paths in POD > > documentation, URLs, paths outside of /home that include /home in > > their name somewhere. > > Moreover, I bet there is a fair number of DDs building their stuff in > /srv, /some/random/non-fhs/directory and whatever else one could > imagine, possibly including /tmp. Scanning for a particular directory > or, list of directories, does not really help. It does on buildds. If it is broken on the buildd, it is broken everywhere... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121018102402.ga20...@khazad-dum.debian.net
Re: Processor microcode update packages
On Sat, 29 Sep 2012, Eric Valette wrote: > On 29/09/2012 12:32, Henrique de Moraes Holschuh wrote: > >If you want to use non-modular, built-in microcode, the documentation of > >iucode-tool does explain how to trigger the microcode reload after boot. You > >will have to add it to your system yourself. > > Fair enough. Already done. However, during the stable->wheezy > migration, all users building their own kernel may be affected as > microcode.ctl package did had an initscript... And it was properly documented on NEWS.Debian. I expect that, out of the 1400 or so users of Squeeze intel-microcode/microcode.ctl, no more than 1% have custom, no-initramfs kernels with microcode built-in instead of as a module. If you want an initscript, you're welcome to write one and submit it as a patch. I will add it as an example to the package, so that others can easily use it if they want. For this class of user, it will be irrelevant soon enough when a proper way to load microcode updates during initial processor setup lands on v3.7, and we switch to initramfs-piggyback-cpio- assisted microcode updates. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120929195631.ga8...@khazad-dum.debian.net
Re: Processor microcode update packages
On Sat, 29 Sep 2012, Eric Valette wrote: > On 29/09/2012 03:46, Henrique de Moraes Holschuh wrote: > >1. No html, please. > > > >non-initrd is supported. Read the package documentation for the details. > > I did. I do not want to compile microcode tool as a module because Currently using microcode as a module is indeed the best choice, as it covers all reasonably common user cases and works right for all supported Linux kernel versions. If you want to use non-modular, built-in microcode, the documentation of iucode-tool does explain how to trigger the microcode reload after boot. You will have to add it to your system yourself. Feel free to write a new initscript and propose it as a wishlist bug to be added to /usr/share/doc/.../examples. If you do, I will add it at the next upload. > So it does not work for people compiling their own kernel and not > using modules (when you tailor your kernel for a given machine, > modules are just slowing the boot process and do not bring > anything). It does not work out-of-the-box. Which is fine as far as I am concerned, you did not get a custom kernel without initramfs support out-of-the-box either. And that happens to be the _only_ setup which is not supported out-of-the-box. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120929103227.ga14...@khazad-dum.debian.net
Re: Processor microcode update packages (was: Towards d-i wheezybeta 3)
On Fri, 28 Sep 2012, Eric Valette wrote: > > > > > > > Reading the thread about microcode, I wonder why > there is no more any /etc/init.d/microcode.ctl equivalent for > people like building their own kernel without initrd. > > -- eric > > > > 1. No html, please. non-initrd is supported. Read the package documentation for the details. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120929014648.gb31...@khazad-dum.debian.net
Re: Microcode and the installer (Re: Towards d-i wheezy beta 3)
On Thu, 13 Sep 2012, Henrique de Moraes Holschuh wrote: > On Mon, 10 Sep 2012, Jonathan Nieder wrote: > > (replying to -devel and -boot only) > (I am not subscribed to -boot. Please keep -devel on replies, or CC me > directly). > > > Henrique de Moraes Holschuh wrote: > > > On Mon, 10 Sep 2012, Philipp Kern wrote: > > >> If we do that the same should also happen for firmware-linux-nonfree. > > >> Loading > > >> the radeon KMS module without firmware available results in an unusable > > >> (text) console. (Yes, it might be considered a bug that radeon is > > >> loadable > > >> without.) > > > > > > Sounds good to me. > > > > > > What should I clone and hack to try to implement this? > > > > , I think. > > It is actually the hw-detect module, and adding support for the two system > processor microcodes is somewhat trivial... as long as I ignore VMs. I just > need to add a hook to pre-pkgsel.d. > > If I want to skip installing the processor microcode on VM images, I need to > install and "in-target" run virt-what before the hook can decide whether > installing the microcode packages is warranted or not. > > Should I attempt to install virt-what (which brings dmidecode as a > dependency) to avoid wasting space on VM images ? PING? I need some feedback from debian-boot or from VM users! -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120917150633.ga32...@khazad-dum.debian.net
Re: Microcode and the installer (Re: Towards d-i wheezy beta 3)
On Mon, 10 Sep 2012, Jonathan Nieder wrote: > (replying to -devel and -boot only) (I am not subscribed to -boot. Please keep -devel on replies, or CC me directly). > Henrique de Moraes Holschuh wrote: > > On Mon, 10 Sep 2012, Philipp Kern wrote: > >> If we do that the same should also happen for firmware-linux-nonfree. > >> Loading > >> the radeon KMS module without firmware available results in an unusable > >> (text) console. (Yes, it might be considered a bug that radeon is loadable > >> without.) > > > > Sounds good to me. > > > > What should I clone and hack to try to implement this? > > , I think. It is actually the hw-detect module, and adding support for the two system processor microcodes is somewhat trivial... as long as I ignore VMs. I just need to add a hook to pre-pkgsel.d. If I want to skip installing the processor microcode on VM images, I need to install and "in-target" run virt-what before the hook can decide whether installing the microcode packages is warranted or not. Should I attempt to install virt-what (which brings dmidecode as a dependency) to avoid wasting space on VM images ? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2012091316.gd29...@khazad-dum.debian.net
Re: Processor microcode update packages (was: Towards d-i wheezy beta 3)
On Thu, 13 Sep 2012, Andrei POPESCU wrote: > On Jo, 13 sep 12, 11:29:39, Nikolaus Rath wrote: > > I think this should be mentioned somewhere *much* more prominent. I > > consider myself pretty tech-savy, but only stumbled upon this just now > > on the this list. Can a non-free package be made essential or > > required? It seems there is really absolutely no-reason other than > > non-freeness for not installing this by default. > > Could the various microcode packages be Suggested or even Recommended by > firmware-linux-nonfree? Probably not, because our support for arch-lists outside of build-dependencies is just a hack (it is resolved at package build time, and the dependencies are ommited based on the build arch). The microcode packages are arch-specific, and firmware-linux-nonfree is arch all. Arch all cannot have any arch-specific binary package dependencies. This means a recommends or suggests for the two microcode packages, if added to firmware-linux-nonfree, would be visible, and not satisfiable, on every arch but i386 and amd64. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120913164947.gc29...@khazad-dum.debian.net
Re: Processor microcode update packages (was: Towards d-i wheezy beta 3)
On Thu, 13 Sep 2012, Nikolaus Rath wrote: > Henrique de Moraes Holschuh writes: > > On Thu, 13 Sep 2012, Wolodja Wentland wrote: > >> On Mon, Sep 10, 2012 at 11:44 +0200, Marco d'Itri wrote: > >> > Also, we should mention somewhere (the install documentation?) that > >> > non-free should be enabled to install microcode fixes which may be > >> > critical to maintain the system stability. > >> > >> Could you elaborate on this please? I have been running systems just fine > >> even though microcode.ctl (and corresponding microcode) was not installed > >> and > >> a look at microcode.ctl's popcon [0] confirms that a majority of users do > >> the > >> same. > > > [...] > > > > System stability depends critically on the presence of microcode that is as > > up-to-date as required to cover all serious bugs on all features of the > > processor that your workload uses. > > I think this should be mentioned somewhere *much* more prominent. I > consider myself pretty tech-savy, but only stumbled upon this just now > on the this list. Can a non-free package be made essential or > required? It seems there is really absolutely no-reason other than > non-freeness for not installing this by default. For non-free, the priority doesn't make any difference. It cannot be made essential or required, because that doesn't make sense for non-free. Basically, everything in non-free is effectively priority "extra". That said, both packages have their priority set to "standard" in the control file, but ftp-masters decided to lower it. It is also worth notice that enabling non-free is not just optional, it is officially discouraged: non-free is not even mentioned by the Debian Wheezy installer unless you're in expert mode. And yes, the only reason to not have it installed by default on every x86 Debian system with an Intel or AMD processor is the non-freeness. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120913164559.gb29...@khazad-dum.debian.net
Re: Towards d-i wheezy beta 3
On Thu, 13 Sep 2012, Wolodja Wentland wrote: > On Mon, Sep 10, 2012 at 11:44 +0200, Marco d'Itri wrote: > > Also, we should mention somewhere (the install documentation?) that > > non-free should be enabled to install microcode fixes which may be > > critical to maintain the system stability. > > Could you elaborate on this please? I have been running systems just fine > even though microcode.ctl (and corresponding microcode) was not installed and > a look at microcode.ctl's popcon [0] confirms that a majority of users do the > same. Either your system doesn't happen to have a processor with any of the worst bugs, possibly because your BIOS/EFI has up-to-date microcode, or you're just lucky. The kernel could be working with reduced functionality to avoid triggering the bug (it usually logs something when it notices it has to do that), and it is also possible that you just didn't notice any issues because they can be hard to detect. It is a fact that most users consider application or system crashes, lock-ups, and slight malfunctions caused by data corruption to be facts of life, and will blame software bugs first and foremost. As long as they are not too frequent, they will rarely even consider the possibility of hardware problems. > If system stability does, in fact, depend *critically* on the presence of > microcode does this also mean that everybody should install it? What are the > implications of not installing it? The BIOS/EFI will almost always already have a microcode patch level to apply to your processor. You know something had to update the processor microcode if the "microcode" line in /proc/cpuinfo is anything different from zero (requires a recent kernel. 3.2 shows it). So yes, it is very often quite critical. The question then becomes: does your EFI/BIOS have the latest microcode updates? Have you updated your BIOS/EFI recently? Most users _never_ update the system firmware. And some vendors just plain don't release BIOS/EFI updates. System stability depends critically on the presence of microcode that is as up-to-date as required to cover all serious bugs on all features of the processor that your workload uses. So, chances are you don't need it. Or that you need it, but you won't know because it will cause data corruption or some sort of malfunction only once a blue moon and you'd never notice the problem, or you end up blaming it on something else. Maybe you'd benefit from a microcode update, but since it fixes errata that just causes, e.g. slight incorrect performance monitoring, or some waste of power, or some slowdown because the kernel can't do all it should be able to on your processor, you just didn't notice. If you need to know for sure, you have to get the processor errata documentation from Intel or AMD, check the errata list and the list of errata fixed by microcode. Also, these documents are not static, they do get updated when new errata are disclosed. AMD is much better at telling you what they're fixing with a microcode update, the list of errata fixed is already in the README's of the amd64-microcode package so you only need the processor documentation to know what the errata numbers mean. With Intel, you might or might not get a list of errata fixed by a microcode version in the "processor specification update" documents (and usually you don't get anything). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120913121749.ga29...@khazad-dum.debian.net
(fwd) make tar*-pkg considered dangerous
I am forwarding this as a remider that, should we ever get to the point of
moving around /lib or /usr/lib, /sbin or /usr/sbin, and /bin or /usr/sbin,
as well as any other such trunks, we really ought to consider whether we
should be using symlinks or bind mounts [where possible] for such moves.
Also, just in case, Debian users are gently reminded that there are less
unsavory methods of packing custom kernel builds for later use in Debian
boxes, including the Linux upstream "deb-pkg" make target (dpkg is a lot
smarter than "tar"), and the make-kpkg command provided by the
kernel-package Debian package (which IMHO tends to produce better kernel
.deb packages than the upstream "deb-pkg" make target.
- Forwarded message from Andi Kleen -
Date: Wed, 12 Sep 2012 05:16:46 +0200
From: Andi Kleen
To: linux-ker...@vger.kernel.org, linux-kbu...@vger.kernel.org
Subject: make tar*-pkg considered dangerous
Hi,
We've had some incidents with people destroying Fedore 17 installs
(to the point of reinstall) by installing a kernel tarball generated with
make tar*-pkg
The problem is that the tarball includes /lib/{modules,firmware},
but on FC17 /lib is a symlink. tar when it unpacks the tarball
replaces the symlink with the directory. So they end up
with a /lib which only contains the new kernel files, but nothing else,
And then the system doesn't boot anymore.
I'm not sure there is a good fix for this. I don't know of a way to
convince tar to not do that. And putting everything into /usr
would be very incompatible.
Disable these make targets or add warnings? If disabling people should
use rpms or dpkgs instead?
-Andi
--
a...@linux.intel.com -- Speaking for myself only.
- End forwarded message -
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120912161154.gb3...@khazad-dum.debian.net
Re: greater popularity of Debian on AMD64?
On Tue, 11 Sep 2012, Thomas Goirand wrote: > On 09/10/2012 09:44 PM, Osamu Aoki wrote: > >Why make things more complicated. What is the rationale to pick > >i686 over others now. Why change to x86-64 which is AMD origin. If > >slashed to listing are list of vender released names, it should be > >(AMD64/Intel 64). We picked one archive identifier at one point of > >history. Osamu > Strictly speaking, and because nobody wrote about it, Intel calls it EM64T. Not anymore, and yes, I checked. That's why I wrote Intel 64. The marketroids strike again. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120910212638.gb2...@khazad-dum.debian.net
Re: Towards d-i wheezy beta 3
On Mon, 10 Sep 2012, Philipp Kern wrote: > On Sun, Sep 09, 2012 at 08:38:38PM -0300, Henrique de Moraes Holschuh wrote: > > I'd like to see it recommend the instalation of (or just install by default) > > system processor microcode update packages when non-free is enabled on a x86 > > arch (i386 or amd64) and the running processor is either Intel or AMD > > (easily identified by a grep in /proc/cpuinfo). > > If we do that the same should also happen for firmware-linux-nonfree. Loading > the radeon KMS module without firmware available results in an unusable > (text) console. (Yes, it might be considered a bug that radeon is loadable > without.) Sounds good to me. What should I clone and hack to try to implement this? Is there any preference over install-by-default or ask-if-the-user-wants-it ? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120910203124.ga2...@khazad-dum.debian.net
Re: Towards d-i wheezy beta 3
On Mon, 10 Sep 2012, Cyril Brulebois wrote: > Features expected to be merged: > - UEFI support (Steve). Before anyone asks, and as far as I can tell: >it's not about supporting secure boot. > - IPv6 support in d-i (Philipp). > - Possibly more xz-related unblocks (Ansgar). > > If anybody wants to see something land into this release, it would be > nice to mention it now instead of after the end of the merge window. I'd like to see it recommend the instalation of (or just install by default) system processor microcode update packages when non-free is enabled on a x86 arch (i386 or amd64) and the running processor is either Intel or AMD (easily identified by a grep in /proc/cpuinfo). I'm willing to help write and test this, but I need a few pointers. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120909233838.ga...@khazad-dum.debian.net
Re: greater popularity of Debian on AMD64?
On Sun, 09 Sep 2012, Ben Hutchings wrote: > On Sat, 2012-09-08 at 22:46 -0300, Henrique de Moraes Holschuh wrote: > > On Sun, 09 Sep 2012, Russell Coker wrote: > > > On Sat, 8 Sep 2012, Henrique de Moraes Holschuh wrote: > > > > If "64-bit PC" is too vague, the alternative designator for the amd64 > > > > arch > > > > is the vendor neutral "x86-64". The vendor-neutral designator for all > > > > of > > > > i386, i486, i586, i686, amd64 and x32 is "x86" (i.e. it is for both > > > > 32-bit > > > > and 64-bit). i286, i186 and 8086 are too old to bother with :-) > > > > > > Why should we be vendor-neutral? AMD invented the AMD64 instruction set. > > > > > > Intel invented the 386 instruction set and we call it i386. > > > > > > Why be vendor-neutral for things that AMD invents when we aren't vendor- > > > neutral for things that Intel invents? > > > > I don't know, and I don't care either way. I am fine with amd64. > > > > But I object to "32-bit PC" and "64-bit PC". i686, amd64, x86-32, x86-64... > > at least those are correct. > > But none of them are widely understood. > > > 32-bit PC and 64-bit PC mean nothing, > > I think a lot more people know which of those they have. Yeah, and it can be fixed by "32-bit PC (i386/i686)" and 64-bit PC (amd64/x86-64)". > > and it will make the mess worse when we start shipping x32. > > If, not when, x32 is in the archive, it can only be a partial > architecture, and will be of no interest to the regular Debian user. So > I don't expect any mess there. I hope you're right. And yes, x32 as a partial arch would be fine. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120909152547.ga23...@khazad-dum.debian.net
Re: greater popularity of Debian on AMD64?
On Sun, 09 Sep 2012, Russell Coker wrote: > On Sat, 8 Sep 2012, Henrique de Moraes Holschuh wrote: > > If "64-bit PC" is too vague, the alternative designator for the amd64 arch > > is the vendor neutral "x86-64". The vendor-neutral designator for all of > > i386, i486, i586, i686, amd64 and x32 is "x86" (i.e. it is for both 32-bit > > and 64-bit). i286, i186 and 8086 are too old to bother with :-) > > Why should we be vendor-neutral? AMD invented the AMD64 instruction set. > > Intel invented the 386 instruction set and we call it i386. > > Why be vendor-neutral for things that AMD invents when we aren't vendor- > neutral for things that Intel invents? I don't know, and I don't care either way. I am fine with amd64. But I object to "32-bit PC" and "64-bit PC". i686, amd64, x86-32, x86-64... at least those are correct. 32-bit PC and 64-bit PC mean nothing, and it will make the mess worse when we start shipping x32. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120909014645.ga1...@khazad-dum.debian.net
Re: Help me DTRT with upstream naming
On Fri, 07 Sep 2012, Lisandro Damián Nicanor Pérez Meyer wrote: > On Fri 07 Sep 2012 21:45:54 Russ Allbery escribió: > > Lisandro Damián Nicanor Pérez Meyer writes: > > > If you go for changing the name, kerberos-wallet or krb-wallet seems > > > quite right. > > > > It's a reasonable idea for the current implementation, but I'd rather not > > use that either because the protocol was designed to not require Kerberos. > > It currently is only implemented using a remctl protocol, but you could > > easily use REST or SOAP to communicate with the backend and 90% of the > > software would work without modification. (In fact, in the long run, I > > hope to do that sort of implementation, or one that uses ssh public keys > > for authentication.) > > auth-wallet then ;) ticket-master? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120908012131.gb27...@khazad-dum.debian.net
Re: greater popularity of Debian on AMD64?
On Fri, 07 Sep 2012, Francesca Ciceri wrote: > On Wed, Sep 05, 2012 at 07:17:52PM +0100, Ben Hutchings wrote: > > I've previously requested that various user-facing references to > > 'i386' and 'amd64' should be changed to the hopefully more > > understandable '32-bit PC' and '64-bit PC', with some success. Please > > could the publicity team try to follow this convention in future > > press/publicity material? > > Sure! I've just fixed the web version of DPN accordingly: changes will be > visible in few hours. If "64-bit PC" is too vague, the alternative designator for the amd64 arch is the vendor neutral "x86-64". The vendor-neutral designator for all of i386, i486, i586, i686, amd64 and x32 is "x86" (i.e. it is for both 32-bit and 64-bit). i286, i186 and 8086 are too old to bother with :-) AFAIK, "x86-32" is seldom used. "x64", which is the same as "x86-64", is very rarely used (in fact, I've never seen anyone use it in Linux-centric communities and workplaces). AFAIK, the full x86 arch list, with vendor-neutral names is: (non-vendor-neutral/explanation): vendor neutral IA32,ix86,i386..i686: x86-32 amd64/EM64T, 64-bit ABI x86-64 32-bit ABI for amd64/EM64T: x32 any of those: x86 Notes: 1. x32 is very different from x86-32. x32 requires the x86-64 instruction set and register set, and a x86-64 64-bit kernel with x32 support. There is no non-vendor-neutral name for x32, fortunately :-) 2. A x86-64 processor can run code for any x86 arch/ABI. 3. A recent x86-64 linux kernel, properly configured, is supposed to support all three arches/ABIs (x32, x86-32 and x86-64) concurrently. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120907184610.gd5...@khazad-dum.debian.net
