Re: Bug#823465: dpkg: Won't run at all on i586 Pentium MMX due to illegal instruction
On Sun, 8 May 2016 00:51:57 +0200 Pierre Ynard wrote: > > My recommendation would be going to jessie[1], it has whole four > > years of support left. Anything you need from unstable can be > > backported. > > Hopefully the downgrade path would be workable. Backports can help with that - those are built in stable, so will have the same compiler options as stable. Start by commenting out all sources pointing at unstable, add sources for jessie and jessie-backports and investigate which packages are installed at a higher version without backports. If some are missing and you think you need those versions, you can always do a local backport by rebuilding in jessie and ask on the backports list to see if someone else needs the same backport. (Leave one source pointing at deb-src: for testing, source only for backport builds.) > > What kind of solution would you propose? We can't exactly add > > preinst guards to every single package. The only package that's > > depended on by (almost) all compiled code is libc6, but because of > > symbols handling the dependency is usually libc6 (>= 2.15) or such > > rather than (>= 2.22-7). > > I was thinking more along the lines of adding some central check in > dpkg maybe, that detects the lack of i686 support and errors out on > new, incompatible packages. Discriminating packages could be as > simple as a by-passable check on the build/release date. But then > this is a bit late to implement in advance. It's not about simply blocking installs - the package to be installed is being upgraded for a reason, so blocking the install just blocks the bug fix or blocks upgrades of other dependent packages, until the binary is rebuilt in stable. That's why the advice is to move this box to stable - ask for backports of any packages which need updates from testing. You have four years to decide whether to replace this hardware or continue running jessie without support. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgp3rfDRI8DYQ.pgp Description: OpenPGP digital signature
Re: Debian i386 architecture now requires a 686-class processor
On Sun, May 08, 2016 at 10:44:29AM +0800, Paul Wise wrote: > d-d-a is mostly for developers, you might like to reach our users via > the Debian publicity team: running unstable is not for users who don't know how to deal with breakage. dealing with breakage involves reading d-d-a. -- cheers, Holger signature.asc Description: Digital signature
Re: Debian i386 architecture now requires a 686-class processor
On Sun, May 8, 2016 at 6:21 PM, Holger Levsen wrote: > running unstable is not for users who don't know how to deal with > breakage. dealing with breakage involves reading d-d-a. I was thinking to give users running affected hardware more warning than reading the release notes in the next stable release. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Bug#823465: dpkg: Won't run at all on i586 Pentium MMX due to illegal instruction
On 2016-05-08 at 03:45, Neil Williams wrote: > On Sun, 8 May 2016 00:51:57 +0200 Pierre Ynard > wrote: >> I was thinking more along the lines of adding some central check >> in dpkg maybe, that detects the lack of i686 support and errors out >> on new, incompatible packages. Discriminating packages could be as >> simple as a by-passable check on the build/release date. But then >> this is a bit late to implement in advance. > > It's not about simply blocking installs - the package to be installed > is being upgraded for a reason, so blocking the install just blocks > the bug fix or blocks upgrades of other dependent packages, until > the binary is rebuilt in stable. That's why the advice is to move > this box to stable - ask for backports of any packages which need > updates from testing. > > You have four years to decide whether to replace this hardware or > continue running jessie without support. I read this suggestion as being less about this particular box, and more about preventing (other) people from having this breakage happen unexpectedly. In this particular case, it's already too late, after all. Even if running unstable, I would certainly expect that something which is known to break certain types of systems this badly would be announced at package install time, giving me a chance to cancel the install... and the more so considering that people keep talking about tracking sid as being a reasonable thing to do, although I myself decided years ago from experience that it was a bad idea. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Debian i386 architecture now requires a 686-class processor
Holger Levsen wrote: > On Sun, May 08, 2016 at 10:44:29AM +0800, Paul Wise wrote: >> d-d-a is mostly for developers, you might like to reach our users via >> the Debian publicity team: > running unstable is not for users who don't know how to deal with > breakage. dealing with breakage involves reading d-d-a. This is not a sid-exclusive issue, it also applies (or will soon apply) to testing. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Re: Bug#823465: dpkg: Won't run at all on i586 Pentium MMX due to illegal instruction
On Sun, 08 May 2016 07:18:40 -0400, The Wanderer wrote: >Even if running unstable, I would certainly expect that something which >is known to break certain types of systems this badly would be announced >at package install time, giving me a chance to cancel the install... and >the more so considering that people keep talking about tracking sid as >being a reasonable thing to do, although I myself decided years ago from >experience that it was a bad idea. Tracking sid is a good idea if you can debug and fix breakages. If you want to be warned for disruptions, use something that we actually released. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Fingerprint-GUI?
On Sun, 08 May 2016 11:28:50 +0800, Paul Wise wrote: > > Is there an effort to package fingerprint-GUI? > Generally you can answer this by looking at wnpp bugs: > https://www.debian.org/devel/wnpp/ > There is a search interface here: > http://wnpp.debian.net/ Or from the command line: % wnpp-check fingerprint (RFP - #666990) http://bugs.debian.org/666990 fingerprint-gui (wnpp-check is in the devscripts package.) Cheers, gregor -- .''`. Homepage https://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - https://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- NP: Carole King: Home Again signature.asc Description: Digital Signature
Re: Bug#823465: dpkg: Won't run at all on i586 Pentium MMX due to illegal instruction
On 2016-05-08 at 08:20, Marc Haber wrote: > On Sun, 08 May 2016 07:18:40 -0400, The Wanderer > wrote: > >> Even if running unstable, I would certainly expect that something >> which is known to break certain types of systems this badly would >> be announced at package install time, giving me a chance to cancel >> the install... and the more so considering that people keep talking >> about tracking sid as being a reasonable thing to do, although I >> myself decided years ago from experience that it was a bad idea. > > Tracking sid is a good idea if you can debug and fix breakages. If > you want to be warned for disruptions, use something that we > actually released. I agree, but I have seen people on debian-user advocating tracking sid by preference over testing as a recommended practice, even to the point of arguing against people who recommend otherwise. (Of whom I have seen fewer than I would have expected.) If the people who have been given this advice have been following it, there are people out there who certainly do not appear to be technically competent but who are nonetheless tracking sid. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Bug#823465: dpkg: Won't run at all on i586 Pentium MMX due to illegal instruction
On Sun, 08 May 2016 07:18:40 -0400 The Wanderer wrote: > On 2016-05-08 at 03:45, Neil Williams wrote: > > > On Sun, 8 May 2016 00:51:57 +0200 Pierre Ynard > > wrote: > > Even if running unstable, I would certainly expect that something > which is known to break certain types of systems this badly would be > announced at package install time, giving me a chance to cancel the > install... It's unstable - I've been running unstable on my main development laptop for ten years, most of the time that something has broken my system, I've had to be the one to report it! Some of those bugs have caused this level of breakage. It's also an issue of workload and whether there is a realistic likelihood of that breakage. The expectation is that users of unstable are not running production systems and that changes like this can be introduced in unstable with notices on d-d-a and - if those changes are to get into the release, the release notes. Some of the problems can be anticipated (package migrations etc.) and even some of those go wrong. The rest of the problems in unstable only become apparent to the maintainer after a bug has been filed. Some of these problems could disable packages completely but what happens is a bug report for the version in unstable and a fix in unstable. That's how unstable works. When unstable does break like this, users of unstable need to be ready to downgrade packages themselves, debug the failure themselves, write sensible bug reports and contribute to stopping that breakage getting into testing. Unstable does, sometimes, generate a high level interrupt, I don't see that this is something that can be avoided. That's why unstable is not suitable for production systems. I haven't had that many interruptions whilst using unstable, overall, but enough that I strongly advise any production system to use stable with backports or possibly testing. > and the more so considering that people keep talking about > tracking sid as being a reasonable thing to do, although I myself > decided years ago from experience that it was a bad idea. The purpose of sid cannot be fulfilled if nobody uses it but those who do use it have to accept being the front line for the problems that need to be fixed before causing problems in testing (and thereby backports & the next stable). With current migration priorities, those using unstable only have 5 days to upgrade and test the upgraded packages. Upgrading unstable once a month doesn't work, once a week is sub-optimal too. I still enjoy having unstable, I use it to preempt problems in stable and backports (where my production systems do rely on things working). Unstable is not suitable for production systems itself and it makes no sense to try and turn it into some kind of second testing. (Personally, I wouldn't use testing on production systems either - unless the number and scale of the backports to stable make that unmanageable.) -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpSsToncjCaj.pgp Description: OpenPGP digital signature
Re: Bug#823465: dpkg: Won't run at all on i586 Pentium MMX due to illegal instruction
On 2016-05-08 at 09:09, Neil Williams wrote: > On Sun, 08 May 2016 07:18:40 -0400 The Wanderer > wrote: > >> On 2016-05-08 at 03:45, Neil Williams wrote: >> >>> On Sun, 8 May 2016 00:51:57 +0200 Pierre Ynard >>> wrote: >> >> Even if running unstable, I would certainly expect that something >> which is known to break certain types of systems this badly would >> be announced at package install time, giving me a chance to cancel >> the install... > > It's unstable - I've been running unstable on my main development > laptop for ten years, most of the time that something has broken my > system, I've had to be the one to report it! Some of those bugs have > caused this level of breakage. Yes, that's part of the 'bargain' of running unstable. The difference is that, presumably, the fact that the change which led to that breakage would in fact so break things was not known in advance. I certainly do not expect such notification for every breakage which occurs in unstable. I was speaking only about cases where the fact that the breakage would occur was known in advance (which is the case here, because the breakage is an intentional feature removal), and where the breakage itself would be "bad enough" (in this case, essentially total). Off the top of my head, I can't actually think of another case where the breakage was both known in advance and expected to be total. If this case really is that unique, that would seem to be a point in favor of its being exceptional enough to warrant special notification measures. > It's also an issue of workload and whether there is a realistic > likelihood of that breakage. The expectation is that users of > unstable are not running production systems That expectation is perhaps not being properly communicated to the user base, then; as mentioned elsewhere, I have seen people who apparently know what they're doing advocating to people who apparently do not that tracking unstable is preferable to tracking testing. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Bug#823465: dpkg: Won't run at all on i586 Pentium MMX due to illegal instruction
On Sun, May 08, 2016 at 02:20:45PM +0200, Marc Haber wrote: > Tracking sid is a good idea if you can debug and fix breakages. If you > want to be warned for disruptions, use something that we actually > released. Another way is to use btrfs (or zfs or perhaps LVM snapshots): whenever something goes south in a way that's not trivial to recover, you can restore with a couple commands and reboot. And if unbootable because, for example, someone removed support for your CPU, you boot with subvol=backups/sys-2016-05-07. -- How to exploit the Bible for weight loss: Pr28:25: he that putteth his trust in the ʟᴏʀᴅ shall be made fat.
Re: Bug#823465: dpkg: Won't run at all on i586 Pentium MMX due to illegal instruction
On Sun, May 08, 2016 at 09:00:12AM -0400, The Wanderer wrote: > I agree, but I have seen people on debian-user advocating tracking sid > by preference over testing as a recommended practice, even to the point > of arguing against people who recommend otherwise. (Of whom I have seen > fewer than I would have expected.) >From what I've seen, debian-user has a negative signal-to-noise ratio, so such an advice is not unexpected. -- How to exploit the Bible for weight loss: Pr28:25: he that putteth his trust in the ʟᴏʀᴅ shall be made fat.
Re: Bug#823465: dpkg: Won't run at all on i586 Pentium MMX due to illegal instruction
On Sun, 2016-05-08 at 09:36 -0400, The Wanderer wrote: > On 2016-05-08 at 09:09, Neil Williams wrote: > > > > > On Sun, 08 May 2016 07:18:40 -0400 The Wanderer > > wrote: > > > > > > > > On 2016-05-08 at 03:45, Neil Williams wrote: > > > > > > > > > > > On Sun, 8 May 2016 00:51:57 +0200 Pierre Ynard > > > > wrote: > > > Even if running unstable, I would certainly expect that something > > > which is known to break certain types of systems this badly would > > > be announced at package install time, giving me a chance to cancel > > > the install... > > It's unstable - I've been running unstable on my main development > > laptop for ten years, most of the time that something has broken my > > system, I've had to be the one to report it! Some of those bugs have > > caused this level of breakage. > Yes, that's part of the 'bargain' of running unstable. > > The difference is that, presumably, the fact that the change which led > to that breakage would in fact so break things was not known in advance. > > I certainly do not expect such notification for every breakage which > occurs in unstable. I was speaking only about cases where the fact that > the breakage would occur was known in advance (which is the case here, > because the breakage is an intentional feature removal), and where the > breakage itself would be "bad enough" (in this case, essentially total). [...] You should probably blame me for not announcing the decision earlier, as I proposed and drove this change. However, the removal of the '586' kernel flavour should have provided some early warning of the change - linux-image-586 was changed to depend (indirectly) on linux-image-4.3.0-1-686, which would fail to boot. At that time the old kernel image would remain installed as a fallback, so this was recoverable. Ben. -- Ben Hutchings I haven't lost my mind; it's backed up on tape somewhere. signature.asc Description: This is a digitally signed message part
Re: Fingerprint-GUI?
* Andrew Shadura [160507 17:27]: > Fingerprint readers are insecure, and that's something that can't be > fixed. I'd prefer to see fewer fingerprint-related software packages > in Debian rather than more. I cringe when I see blanket statements like this from security advocates. Instead of saying "get rid of fingerprint readers", your efforts would be more beneficial if they were directed towards education of both the downsides of a particular technology and how to determine if the security problems associated with it outweigh the benefits. Your statement is analogous to saying that deadbolts are not going to stop an experienced burglar who has cased your house, so all hardware stores should stop selling deadbolts and only sell bank-vault-style door locks. I know of at least one fast food chain that uses fingerprint readers to allow their employees to clock in and out. Can an employee take advantage of the insecurity of fingerprint readers to get a coworker to clock him in early? Probably. If he does it regularly, will he get caught? Probably. Do the risks to the fast food chain outweigh the convenience of the technology? I seriously doubt it. I would like to see security advocates espousing use-case-based security, rather than just saying "it isn't secure, so don't use it." ...Marvin
Re: Bug#823465: dpkg: Won't run at all on i586 Pentium MMX due to illegal instruction
On Sun, 8 May 2016 16:40:22 +0200, Adam Borowski wrote: >On Sun, May 08, 2016 at 02:20:45PM +0200, Marc Haber wrote: >> Tracking sid is a good idea if you can debug and fix breakages. If you >> want to be warned for disruptions, use something that we actually >> released. > >Another way is to use btrfs (or zfs or perhaps LVM snapshots): whenever >something goes south in a way that's not trivial to recover, you can >restore with a couple commands and reboot. And if unbootable because, >for example, someone removed support for your CPU, you boot with >subvol=backups/sys-2016-05-07. btrfs has suffered severe regressions since kernel 4.4, with the btrfs upstream community only offering advice like "don't use so many snapshots" or "say goodbye to existing snapshots, backup, format with latest btrfs-tools, restore". This is, unfortunately, not a filesystem that I'd trust to keep my data, despite not having _lost_ actual data other than snapshots, but those bugs and the suggested remedies do not fit my expectations. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Bug#823779: ITP: geronimo-servlet-3.0-spec -- Geronimo API implementation of the Servlet 3.0 spec
Package: wnpp Severity: wishlist Owner: Christopher Hoskin * Package name: geronimo-servlet-3.0-spec Version : 1.0 Upstream Author : The Apache Software Foundation * URL : http://svn.apache.org/viewvc/geronimo/specs/tags/geronimo-servlet_3.0_spec-1.0/ * License : Apache-2.0 Programming Lang: Java Description : Geronimo API implementation of the Servlet 3.0 spec Apache Geronimo is an open source server runtime that integrates the best open source projects to create Java/OSGi server runtimes that meet the needs of enterprise developers and system administrators. Its most popular distribution is a fully certified Java EE 6 application server runtime. Geronimo API implementation of the Servlet 3.0 spec (javax.servlet classes) I intend to maintain this package within the Java Packaging Team. I will require a sponsor.
Bug#823789: ITP: python-pytest-pep8 -- py.test plugin for efficiently checking PEP8 compliance
Package: wnpp Severity: wishlist Owner: Daniel Kahn Gillmor * Package name: python-pytest-pep8 Version : 1.0.6 Upstream Author : Holger Krekel * URL : http://bitbucket.org/hpk42/pytest-pep8/ * License : MIT Programming Lang: Python Description : py.test plugin for efficiently checking PEP8 compliance This is a plugin to the pytest framework that checks PEP8 compliance. -- I plan to upload this as part of the DPMT. It is part of the test toolchain for some python modules, so it may be most useful as a build-dep.
Re: How to change config script for multiarch?
On Wed, Feb 10, 2016 at 11:03:04AM +0100, Bastien ROUCARIES wrote: > On Wed, Feb 10, 2016 at 10:59 AM, Alastair McKinstry > > In particular, for any non-standard variables, you can read them, by eg: > > > > f90_compiler=$(pkg-config mypkg --variable=f90_compiler) > > > > Its probably a good idea to document the config script as deprecated > > in output, the man page, etc. > > (2) wrapper are not cross build safe... This seems less than constructive, so let me briefly follow up on how to make it work properly. The first misconception I see in this thread is that somehow pkg-config is good and foo-config is bad. It's not as simple as that. Have a look at libpython3-dev. It ships e.g. x86_64-linux-gnu-python3-config. By prefixing the script with the triplet, we can treat it very much like libraries that are being placed in multiarch locations. In order for pkg-config to be "better" than your foo-config script, you need to tell it about the current host architecture by prefixing it with the triplet. Instead of calling pkg-config, you should be calling $DEB_HOST_GNU_TYPE-pkg-config. The tricky question is: Where to obtain that value. The answer is: By parsing $0. So when converting your foo-config scripts to use pkg-config, you can go ahead and parse $0. Use that triplet instead of encoding it into your script. Then each libfoo-dev instance can place the same (shared) foo-config script in a shared location and place individual symbolic links with the prefix at it. Alternatively, you can do like python and ship plain files in triplet-prefixed locations. No pkg-config. Still M-A:same safe. It is worth noting that pkg-config has a head-start here. It implements the parsing of $0 for you. It also improves the client side. For this change to work properly, consumers must call your foo-config with the triplet prefix. When you use autotools, it'll automatically prefer the prefixed pkg-config over the plain one (unless your pkg-config code is home-grown). It's not like pkg-config is the silver bullet here. It just helps you solve some of the integration problems. Finally, turning Multi-Arch off for libfoo-dev packages may sound bad, but in many cases it is actually harmless to practical cross building. libgpg-error-dev has it turned off and still works well in practise. There is a trade-off between backwards compatibility, multiarch support and time investment to be made in these cases. I do not believe that pkg-config is the one-size-fits-all answer. Helmut
Re: How to change config script for multiarch?
On Mon, 09 May 2016 at 06:47:38 +0200, Helmut Grohne wrote: > In order for pkg-config to be "better" than your foo-config script, you > need to tell it about the current host architecture by prefixing it with > the triplet. Instead of calling pkg-config, you should be calling > $DEB_HOST_GNU_TYPE-pkg-config. The tricky question is: Where to obtain > that value. The answer is: By parsing $0. The reason this works is that third-party configure scripts (for users of foo) normally call the PKG_PROG_PKG_CONFIG Autoconf macro, either directly or via PKG_CHECK_MODULES or PKG_CHECK_EXISTS, and PKG_PROG_PKG_CONFIG correctly uses AC_PATH_TOOL to look for the tuple-prefixed version before the unprefixed version. If users of foo normally call foo-config directly, no amount of adding prefixes is going to make them cross-build without modification. S
