Re: [WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading
On Sun, Jun 25, 2017 at 09:19:36AM -0300, Henrique de Moraes Holschuh wrote: [...] > Apparently, Intel had indeed found the issue, *documented it* (see > below) and *fixed it*. There was no direct feedback to the OCaml > people, so they only found about it later. [...] > We do not have enough information at this time to know how much software > out there will trigger this specific defect. > > One important point is that the code pattern that triggered the issue in > OCaml was present on gcc-generated code. There were extra constraints > being placed on gcc by OCaml, which would explain why gcc apparently > rarely generates this pattern. > > The reported effects of the processor defect were: compiler and > application crashes, incorrect program behavior, including incorrect > program output. > > > What we know about the microcode updates issued by Intel related to > these specific errata: > > Fixes for processors with signatures[1] 0x406E3 and 0x506E3 are > available in the Intel public Linux microcode release 20170511. This > will fix only Skylake processors with model 78 stepping 3, and model 94 > stepping 3. The fixed microcode for these two processor models reports > revision 0xb9/0xba, or higher. > > Apparently, these errata were fixed by microcode updates issued in early > April/2017. Based on this date range, microcode revision 0x5d/0x5e (and > higher) for Kaby Lake processors with signatures 0x806e9 and 0x906e9 > *might* fix the issue. We do not have confirmation about which > microcode revision fixes Kaby Lake at this time. so in conclusion: don't buy intel. At least in future. I must say I'm utterly disappointed by this crap. "hey there is a hug bug, we dont tell you what it is exactly, or how we fixed it, but YOU MUST INSTALL THIS BINARY BLOB TO FIX IT. (and btw, this is for skylake, for kaby lake, ahem, maybe, we have no idea, but do install that crap^wblob too.") Are there any other public bug reports which got fixed by this, or is the ocaml issue the only known issue which gets fixed by installing this microcode update? (and I hope this were obvious, but I guess it's not, so: I'm saying Intel sold and still is selling us crap here, not Henrique, who tiredlessly tries to help dealing with that crap. Thank you, Henrique, for this, that's really nice of you.) -- cheers, Holger, hardware *is* software… signature.asc Description: Digital signature
Re: [WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading
On Mon, Jun 26, 2017 at 08:34:57AM +, Holger Levsen wrote: > but YOU MUST INSTALL THIS BINARY BLOB How is it worse than the blobs already in your hardware? -- WBR, wRAR signature.asc Description: PGP signature
Re: [WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading
On Mon, Jun 26, 2017 at 01:51:25PM +0500, Andrey Rahmatullin wrote: > > but YOU MUST INSTALL THIS BINARY BLOB > How is it worse than the blobs already in your hardware? it opens the door for targeted attacks. -- cheers, Holger signature.asc Description: Digital signature
Bug#865989: ITP: ruby-native-package-installer -- Ruby library to help install native packages on "gem install"
Package: wnpp Severity: wishlist Owner: "HIGUCHI Daisuke (VDR dai)" -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: ruby-native-package-installer Version : 1.0.4 Upstream Author : Kouhei Sutou * URL : https://github.com/ruby-gnome2/native-package-installer * License : LGPL-3+ Programming Lang: Ruby Description : Ruby library to help install native packages on "gem install" Users need to install native packages to install an extension library that depends on native packages. It bores users because users need to install native packages and an extension library separately. native-package-installer helps to install native packages on "gem install". Users can install both native packages and an extension library by one action, "gem install". - - This is needed for new upstream release of Ruby-GNOME2: https://tracker.debian.org/pkg/ruby-gnome2 - - This is maintaind by me and Debian Ruby Extras Maintainers. - -- Regards, dai GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E -BEGIN PGP SIGNATURE- iQJDBAEBCAAtFiEECynYjkLmt2W42OpQeDlhndQ5Zo4FAllQ4zwPHGRhaUBkZWJp YW4ub3JnAAoJEHg5YZ3UOWaON/MP/jxApr1LfY73QH7AbwC+XlEdKctiS33WqvB8 VziNrWNejAgEDPRGg4+IeAkBXejLxZ1z2WRjlVlwXfYtpMrM5HAxyRQZckHH1wac 6GnPnavJC7Rs5Ym7Ie0V5PWXlarRwo1FLpFzlrSUz2LzO1tsUmWpPrpFMEiJM38Z P4GMm6sUTr88ddJM1i0+LB8bL6rBqdXXeoPScjeDVe9dePjOhFrsvZET5OFXlbND O20/+jQbRY1F1kJOuzbP5UmR25N2JZmhMxlQ8r2XFft/2QHQEilF1bmKA77iwICA M5CQ2q5ag13BHFV7MNxRGvh3PoHRYU6AYUkdvJnXE2ICRsZTKZc04wDPSO6j06Pp NBkXcamhohfkHWsauwHHbDZHe8JWL60waspfrgBb9XyjQG5lDDVYJtzzXu/j5649 5RXwLiQOY30pqLPrsyQcFJK6ar9LQyOtuU/Q8ZWQMbyIG4Hbb8z4NInCgCF3XaWk bqgMqZblTW7SYyidVfuaicFGyKcxEnPzmJ7R08BCuEsHR6xOQcwFs2iuqcvsgfBu XMAbbpywHsEVj6YpuvBHEwCgbe9nY8Zm8m4ThnRFxTKSkHuEDK5M8lGTB5ueREj8 k3zEphlhCow3+eaGi9igzNqS9qqGM1ZQFF0hm3sluuTJLAiNM9zaqLA6iIpSt4+1 r9DRivZv =/oVn -END PGP SIGNATURE-
Re: Bug#865642: ITP: libgtk3-webkit-perl -- WebKit bindings for Perl
Control: reopen -1 Control: retitle -1 ITP: libgtk3-webkit2-perl -- WebKit2 bindings for Perl Hi all, On Fri, Jun 23, 2017 at 01:32:37PM +, Mike Gabriel wrote: > Control: tags -1 wontfix > Control: close -1 > > Hi, > > On Fr 23 Jun 2017 14:28:49 CEST, Mike Gabriel wrote: > > > Package: wnpp > > Severity: wishlist > > Owner: Mike Gabriel > > > > * Package name: libgtk3-webkit-perl > > Version : 0.06 > > Upstream Author : Emmanuel Rodriguez > > * URL : https://metacpan.org/release/Gtk3-WebKit > > * License : LGPL-2.1 > > Programming Lang: Perl > > Description : WebKit bindings for Perl > > > > Gtk3::WebKit provides the Perl bindings for the Gtk3 port of WebKit. > > > > This package will soon be required by the Arctica Web Browser, a remote > > session > > aware web browser with client side rendering overlay. > > > > The package will be maintained under the umbrella of the pkg-perl group and > > the co-maintained by Debian Remote Maintainers team. > > as just discussed with pochu on IRC, packaging the above is not such a good > idea, as libwebkit-3.0-dev and co. are gonna be removed in the buster > release cycle. > > Thus, closing this ITP... > > Mike I played with perl-Gtk3-WebKit(2) a bit and the patch for binding against WebKit2 is really trivial. So reopening and renaming this ITP. Greets, Mike -- mike gabriel aka sunweaver (Debian Developer) fon: +49 (1520) 1976 148 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: sunwea...@debian.org, http://sunweavers.net signature.asc Description: PGP signature
Re: [WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading
On Mon, 26 Jun 2017, Holger Levsen wrote: > Are there any other public bug reports which got fixed by this, or is the > ocaml issue the only known issue which gets fixed by installing this microcode > update? As far as I know, so far OCaml is the only one that was verified to be caused by the SKL150 erratum. I got some comments about the advisory after it was published. According to a couple of those, the code pattern that triggers SKL150 is one that is usually avoided [by compilers and hand-optimized assembly] due to performance reasons. Apparently, it is explicitly documented as being slow by Intel optimization manuals. That may well mean the pattern is rare enough that nothing else in Debian is affected. -- Henrique Holschuh
Re: [WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading
On Mon, Jun 26, 2017 at 08:39:10AM -0300, Henrique de Moraes Holschuh wrote: > As far as I know, so far OCaml is the only one that was verified to be > caused by the SKL150 erratum. [...] thanks for providing these details. -- cheers, Holger signature.asc Description: Digital signature
Re: [WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading
Am Montag, den 26.06.2017, 08:34 + schrieb Holger Levsen: > On Sun, Jun 25, 2017 at 09:19:36AM -0300, Henrique de Moraes Holschuh > wrote: > [...] > > Apparently, Intel had indeed found the issue, *documented it* (see > > below) and *fixed it*. There was no direct feedback to the OCaml > > people, so they only found about it later. > > [...] > > We do not have enough information at this time to know how much > > software > > out there will trigger this specific defect. > > > > One important point is that the code pattern that triggered the > > issue in > > OCaml was present on gcc-generated code. There were extra > > constraints > > being placed on gcc by OCaml, which would explain why gcc > > apparently > > rarely generates this pattern. > > > > The reported effects of the processor defect were: compiler and > > application crashes, incorrect program behavior, including > > incorrect > > program output. > > > > > > What we know about the microcode updates issued by Intel related to > > these specific errata: > > > > Fixes for processors with signatures[1] 0x406E3 and 0x506E3 are > > available in the Intel public Linux microcode release > > 20170511. This > > will fix only Skylake processors with model 78 stepping 3, and > > model 94 > > stepping 3. The fixed microcode for these two processor models > > reports > > revision 0xb9/0xba, or higher. > > > > Apparently, these errata were fixed by microcode updates issued in > > early > > April/2017. Based on this date range, microcode revision 0x5d/0x5e > > (and > > higher) for Kaby Lake processors with signatures 0x806e9 and > > 0x906e9 > > *might* fix the issue. We do not have confirmation about which > > microcode revision fixes Kaby Lake at this time. > > so in conclusion: don't buy intel. At least in future. In conclusion: don't buy AMD or Intel CPUs. AMD processors have bugs too. Just look at the recent changes to the amd64-microcode package. If you are unlucky, there might not even be a workaround and it can take months to reproduce, find the root cause and fix it. Comparing the patch IDs can give you a hint how many iterations were needed. I don't see much difference between AMD and Intel when comparing Henrique's announcement with my first-hand experience with one of the vendors. > I must say I'm utterly disappointed by this crap. "hey there is a hug > bug, we > dont tell you what it is exactly, or how we fixed it, but YOU MUST > INSTALL THIS > BINARY BLOB TO FIX IT. (and btw, this is for skylake, for kaby lake, > ahem, maybe, > we have no idea, but do install that crap^wblob too.") The same complaint can be said about the AMD microcode updates. -- Benjamin Drung System Developer Debian & Ubuntu Developer ProfitBricks GmbH Greifswalder Str. 207 D - 10405 Berlin Email: benjamin.dr...@profitbricks.com Web: https://www.profitbricks.com Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg, HRB 125506B. Geschäftsführer: Achim Weiss. signature.asc Description: This is a digitally signed message part
Re: [WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading
On Mon, Jun 26, 2017 at 02:30:24PM +0200, Benjamin Drung wrote: > The same complaint can be said about the AMD microcode updates. quite probably, yes. but that doesn't make any crap any better. -- cheers, Holger signature.asc Description: Digital signature
Re: [WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading
On Mon, Jun 26, 2017 at 01:01:51PM +, Holger Levsen wrote: > > The same complaint can be said about the AMD microcode updates. > quite probably, yes. but that doesn't make any crap any better. Yet "don't buy anything" is not a good advice. -- WBR, wRAR signature.asc Description: PGP signature
Re: [WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading
On Mon, Jun 26, 2017 at 06:04:43PM +0500, Andrey Rahmatullin wrote: Yet "don't buy anything" is not a good advice. Have we ruled out all ARM vendors yet? :) -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Bug#866001: ITP: node-debuglog -- used for debugging
Package: wnpp Severity: wishlist Owner: saravanan30erd X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-debuglog Version : 1.0.1 Upstream Author : Sam Roberts * URL : https://github.com/sam-github/node-debuglog * License : Expat Programming Lang: JavaScript Description : used for debugging used for debug logging. . This library is a dependency of npm, Node.js package manager. . Node.js is an event-based server-side JavaScript engine.
Re: [WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading
On Mon, Jun 26, 2017 at 02:08:20PM +0100, Jonathan Dowland wrote: > > Yet "don't buy anything" is not a good advice. > Have we ruled out all ARM vendors yet? :) Are we still talknig about general-purpose computers? -- WBR, wRAR signature.asc Description: PGP signature
IMPORTANT: Do live Debian images have a future?
[ Note the cross-posting... ] Hey folks, Background: we released live images for Stretch using new tooling, namely live-wrapper. It is better than what we had before (live-build) in a number of ways, particularly in terms of build reliability and some important new features (e.g. UEFI support). But it's also less mature and has seen less testing. There have been bugs because of that. I have fixes for most of the ones I know about [1], and I'm still working on more bugfixes yet. While the bugs are annoying, what worries me more is that they were only spotted in release builds. There had been testing versions of live images available for multiple weeks beforehand, presumably with the same bugs included. (Almost) none of them reported. This shows that we don't have enough people using these live images and/or caring about filing bugs. We have a similar lack of involvement in terms of the content of the live images. As I said above, I'm happy that we now have a reliable tool for building our live images - that makes my life much easier. But I honestly have no idea if the multiple desktop-specific live images are actually reasonable representations of each of the desktops. For example, I *seriously* hope that normal KDE installations are not effected by #865382 like our live KDE images. Validation by the various desktop teams would be useful here. The current situation is *not* good enough. I ended up getting involved in live image production because the images needed making, and I was already the main person organising production of Debian's official images. To be frank, I had (and still have) no direct use for the live images myself and I don't *particularly* care about them all that much. Despite that, I've ended up spending a lot of time working on them. A few other people have also spent a lot of time working in this area - thanks are due to those people too. But it's still not enough. If our live images are going to be good enough to meet the standards that Debian users deserve and expect, we need *consistent*, *sustained* involvement from a lot more people. Please tell me if you're going to help. If we don't see a radical improvement soon, I'll simply disable building live images altogether to remove the false promises they're making. [1] https://get.debian.org/images/release/current-live/amd64/iso-hybrid/#issues -- Steve McIntyre, Cambridge, UK.st...@einval.com "...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver." -- Daniel Pead signature.asc Description: PGP signature
Re: [WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading
On Mon, Jun 26, 2017 at 06:14:36PM +0500, Andrey Rahmatullin wrote: On Mon, Jun 26, 2017 at 02:08:20PM +0100, Jonathan Dowland wrote: > Yet "don't buy anything" is not a good advice. Have we ruled out all ARM vendors yet? :) Are we still talknig about general-purpose computers? In 2017? Sure we are! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Bug#866009: ITP: python-aiosmtpd -- Python3 asyncio based SMTP server
Package: wnpp Severity: wishlist Owner: =?utf-8?q?Pierre-Elliott_B=C3=A9cue?= * Package name: python-aiosmtpd Version : 1.0 Upstream Author : Barry Warsaw , Eric V. Smith, Andrew Kuchling, Jason Coombs * URL : https://github.com/aio-libs/aiosmtpd * License : Apache 2 Programming Lang: Python Description : Python3 asyncio based SMTP server This is a server for SMTP and related protocols, similar in utility to the standard library’s smtpd.py module, but rewritten to be based on asyncio for Python 3. This package is a new dependency for mailman3-core package that I first intended to package in sept. 2015[1]. Since then, we decided to wait until Mailman 3.1 to finalize packaging as python3.5 became the main version of python in debian and mailman3.0.x was not fully 3.5 operative. Now that 3.1 is out, it's time to finish this work, and this package seems to be the only missing dependency. This package would be maintained by me and the DPMT. Barry Warsaw offered to sponsor me on this one. Cheers. [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799281
Bug#866010: ITP: ruby-public-suffix -- Domain name parser based on the Public Suffix List
Package: wnpp Severity: wishlist Owner: Sruthi Chandran X-Debbugs-CC: debian-devel@lists.debian.org * Package name: ruby-public-suffix Version : 2.0.5 Upstream Author : Simone Carletti * URL : https://rubygems.org/gems/public_suffix * License : MIT Programming Lang: Ruby Description: Domain name parser based on the Public Suffix List Public Suffix can parse and decompose a domain name into top level domain, domain and subdomains. signature.asc Description: OpenPGP digital signature
Re: [WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading
On Mon, 2017-06-26 at 08:34 +, Holger Levsen wrote: > On Sun, Jun 25, 2017 at 09:19:36AM -0300, Henrique de Moraes Holschuh wrote: > [...] > > Apparently, Intel had indeed found the issue, *documented it* (see > > below) and *fixed it*. There was no direct feedback to the OCaml > > people, so they only found about it later. [...] > so in conclusion: don't buy intel. At least in future. [...] Other procesors aren't bug-free, they just don't get as many bug fixes. Ben. -- Ben Hutchings Never put off till tomorrow what you can avoid all together. signature.asc Description: This is a digitally signed message part
Re: IMPORTANT: Do live Debian images have a future?
I'm not a dev but I am a user and I do test so I'll add my bit here. Let's be frank Live Wrapper only exists because of animosity within Debian towards the originator of Live Build (and to be honest his own lack of concern for what Debian required of Live Build). Live Wrapper was rushed and was never going to be ready for Stretch and in hindsight it was a little foolish to think it would be ready to build the types of images Debian required. Live Build wasn't up to scratch but the UEFI support issue has been fixed so what other issues are there with Live Build that makes it unreasonable to use? On 27 June 2017 at 00:08, Steve McIntyre wrote: > [ Note the cross-posting... ] > > Hey folks, > > Background: we released live images for Stretch using new tooling, > namely live-wrapper. It is better than what we had before (live-build) > in a number of ways, particularly in terms of build reliability and > some important new features (e.g. UEFI support). But it's also less > mature and has seen less testing. There have been bugs because of > that. I have fixes for most of the ones I know about [1], and I'm > still working on more bugfixes yet. > > While the bugs are annoying, what worries me more is that they were > only spotted in release builds. There had been testing versions of > live images available for multiple weeks beforehand, presumably with > the same bugs included. (Almost) none of them reported. This shows > that we don't have enough people using these live images and/or caring > about filing bugs. > > We have a similar lack of involvement in terms of the content of the > live images. As I said above, I'm happy that we now have a reliable > tool for building our live images - that makes my life much > easier. But I honestly have no idea if the multiple desktop-specific > live images are actually reasonable representations of each of the > desktops. For example, I *seriously* hope that normal KDE > installations are not effected by #865382 like our live KDE > images. Validation by the various desktop teams would be useful here. > > The current situation is *not* good enough. I ended up getting > involved in live image production because the images needed making, > and I was already the main person organising production of Debian's > official images. To be frank, I had (and still have) no direct use for > the live images myself and I don't *particularly* care about them all > that much. Despite that, I've ended up spending a lot of time working > on them. A few other people have also spent a lot of time working in > this area - thanks are due to those people too. But it's still not > enough. > > If our live images are going to be good enough to meet the standards > that Debian users deserve and expect, we need *consistent*, > *sustained* involvement from a lot more people. Please tell me if > you're going to help. If we don't see a radical improvement soon, I'll > simply disable building live images altogether to remove the false > promises they're making. > > [1] https://get.debian.org/images/release/current-live/amd64/ > iso-hybrid/#issues > > -- > Steve McIntyre, Cambridge, UK. > st...@einval.com > "...In the UNIX world, people tend to interpret `non-technical user' > as meaning someone who's only ever written one device driver." -- Daniel > Pead >
Processed: reassign 859877 to general
Processing commands for cont...@bugs.debian.org: > reassign 859877 general Bug #859877 [debian-maintainers] debian-maintainers: problem mit instalation HP DeskJet 2130 all-in-one Bug reassigned from package 'debian-maintainers' to 'general'. Ignoring request to alter found versions of bug #859877 to the same values previously set Ignoring request to alter fixed versions of bug #859877 to the same values previously set > thanks Stopping processing here. Please contact me if you need assistance. -- 859877: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859877 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Intended MBF: maintainer scripts not using strict mode
Hi, we currently have in sid 84 maintainer scripts not using strict mode. That is, they neither start on "#!/bin/[ba]sh -e", nor do a "set -e". The list is attached. This list includes the 12 remaining scripts not starting on #! (bugs are already filed for these). Policy says in Section 10.4: Shell scripts (sh and bash) other than init.d scripts should almost certainly start with set -e so that errors are detected. [..] Every script should use set -e or check the exit status of every command. I had a cursory look over the listed maintainer scripts, and did not find any that does a careful checking of exit statuses. Though some of them are quite trivial, or even sometimes empty. It looks to me as not using strict mode in these cases is an oversight, and I would like to file bugs for these. What is your opinion? Policy says "should", not "must". If you agree with the MBF, what do you think would be the appropriate severity? -Ralf. asterisk-prompt-de_2.0-1.1/preinst authbind_2.1.2/postinst authbind_2.1.2/prerm bcache-tools_1.0.8-2+b1/preinst bible-kjv_4.29+b1/postinst bible-kjv_4.29+b1/postrm bible-kjv_4.29+b1/prerm bible-kjv-text_4.29/postinst bible-kjv-text_4.29/prerm bind9_1:9.10.3.dfsg.P4-12.3/postrm binfmtc_0.17-2+b1/postinst binfmtc_0.17-2+b1/postrm bwbar_1.2.3-2.1+b2/prerm ca-certificates-mono_4.6.2.7+dfsg-1/postinst checksecurity_2.0.16+nmu1/preinst clips_6.24-3.2/postinst cxref_1.6e-2+b1/postrm debbugs_2.4.1.1/postrm debfoster_2.7-2.1+b1/postrm discover_2.1.2-7.1/postrm discover_2.1.2-7.1/preinst dsh_0.25.10-1.3/postinst dsh_0.25.10-1.3/postrm dsh_0.25.10-1.3/preinst dvifb_1:01.03-14.2/postinst dvifb_1:01.03-14.2/postrm ekiga-dbg_4.0.1-6+b5/postinst ekiga-dbg_4.0.1-6+b5/postrm ekiga-dbg_4.0.1-6+b5/preinst geki3_1.0.3-8.1/postinst geki3_1.0.3-8.1/postrm gjiten_2.6-3/postinst gnukhata-core-engine_2.6.1-3/postrm golang-godebiancontrol-dev_0.0~git20140119-1/preinst guidedog_1.2.0-3+b1/postrm hyperspec_1.30+nmu2/postinst kterm_6.2.0-46.2/postinst kterm_6.2.0-46.2/prerm ldp-docbook-xsl_0.0.20040321-3/preinst ldp-docbook-xsl_0.0.20040321-3/prerm libclips_6.24-3.2/postinst libclips_6.24-3.2/prerm linpac_0.24-1+b1/postrm logtool_1.2.8-10/postrm logtool_1.2.8-10/preinst lpr_1:2008.05.17.2+b1/postinst lpr_1:2008.05.17.2+b1/postrm manpages-posix-dev_2013a-2/postinst manpages-posix-dev_2013a-2/postrm manpages-posix-dev_2013a-2/preinst mgetty-docs_1.1.36-3/preinst mgetty-fax_1.1.36-3+b1/preinst mgetty-voice_1.1.36-3+b1/postrm mime-support_3.60/prerm pmw-doc_1:4.29-1/postinst pmw-doc_1:4.29-1/preinst python-imaging-doc-html_1.1.2-1.2/postinst python-imaging-doc-pdf_1.1.2-1.2/postinst python-kde4_4:4.14.3-2/postinst remembrance-agent_2.12-7+b2/prerm samba_2:4.6.5+dfsg-2/prerm samba-common-bin_2:4.6.5+dfsg-2/prerm samhain_4.1.4-2/preinst sauce_0.9.0+nmu3/postrm scalable-cyrfonts-tex_4.17/postinst scalable-cyrfonts-tex_4.17/postrm scanlogd_2.2.5-3.3/postinst scanlogd_2.2.5-3.3/postrm scanlogd_2.2.5-3.3/prerm sendfile_2.1b.20080616-5.3+b3/preinst simba_0.8.4-4.3/postrm spacearyarya_1.0.2-7.1/postinst spacearyarya_1.0.2-7.1/postrm suricata_4.0.0-beta1-1~exp1/preinst swapspace_1.10-4+b2/postinst t1-cyrillic_4.17/postrm t1-oldslavic_4.17/postinst t1-oldslavic_4.17/postrm t1-teams_4.17/postinst t1-teams_4.17/postrm websimba_0.8.4-4.3/postinst websimba_0.8.4-4.3/postrm whizzytex_1.3.2-1.3/prerm wodim_9:1.1.11-3+b2/preinst
Re: IMPORTANT: Do live Debian images have a future?
I'm a user and a tester, not a dev, and I know nothing (and don't want to know anything) about the personal politics between Debian developers. So that's all I'll say on that subject. To Steve's original point: First, a big THANK YOU! to Steve for taking this job on. I, for one, an grateful. I use Debian a lot, but I'm only an occasional user of the Debian Live images. But when I need them, I need them. And when I need them, I want them to just work. If having them there and working when I need them means I have to add them to my list of things to test and report on, I'm willing to make that investment. Please add me to your "testers" list. Thank you, Rick PS: On a related topic: What I think would be really cool, would be Debian Live images for some of the ARM architectures. Something I could dd to a USB stick and boot right away when I get a new box in for testing. Even cooler would be the ability to use that self-same live image to install Debian after the testing phase was over. > On 27 June 2017 at 00:08, Steve McIntyre wrote: > >> [ Note the cross-posting... ] >> >> >> If our live images are going to be good enough to meet the standards >> that Debian users deserve and expect, we need *consistent*, >> *sustained* involvement from a lot more people. Please tell me if >> you're going to help. If we don't see a radical improvement soon, I'll >> simply disable building live images altogether to remove the false >> promises they're making. >> >> [1] https://get.debian.org/images/release/current-live/amd64/iso >> -hybrid/#issues >> >> -- >> Steve McIntyre, Cambridge, UK. >> st...@einval.com >> "...In the UNIX world, people tend to interpret `non-technical user' >> as meaning someone who's only ever written one device driver." -- Daniel >> Pead >> > >
Re: Intended MBF: maintainer scripts not using strict mode
On Mon, Jun 26, 2017 at 10:23:56PM +0200, Ralf Treinen wrote: > we currently have in sid 84 maintainer scripts not using strict mode. > That is, they neither start on "#!/bin/[ba]sh -e", nor do a "set -e". > The list is attached. This list includes the 12 remaining scripts not > starting on #! (bugs are already filed for these). sigh. And using `#!/bin(ba)?sh -e` is not good either (there is a lintian tag about it, iirc). > I had a cursory look over the listed maintainer scripts, and did not > find any that does a careful checking of exit statuses. Though some > of them are quite trivial, or even sometimes empty. It looks to me > as not using strict mode in these cases is an oversight, and I would > like to file bugs for these. Yes, they are bugs, I agree. > What is your opinion? Policy says "should", not "must". If you agree > with the MBF, what do you think would be the appropriate severity? I do agree and support the MBF. I think they should be at most severity important, possibly checkig some of those packages (I'm thinking about samba, samhain, ..) to see whether an eventual failure would be very bed and in those case even be RC. Please, as usual, file those bugs using some usertag. BTW, you forgot to attach a dd-list and a proposed text for review. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Intended MBF: maintainer scripts not using strict mode
On Mon, Jun 26, 2017 at 10:23:56PM +0200, Ralf Treinen wrote: > What is your opinion? Policy says "should", not "must". If you agree > with the MBF, what do you think would be the appropriate severity? "normal" if there are no issues and "important" if you've encountered possible problems. and thanks for doing this work! I'd appreciate if we could change policy to "must" one day. -- cheers, Holger signature.asc Description: Digital signature
Re: Intended MBF: maintainer scripts not using strict mode
On 26/06/17 22:23, Ralf Treinen wrote: > Hi, > > we currently have in sid 84 maintainer scripts not using strict mode. > That is, they neither start on "#!/bin/[ba]sh -e", nor do a "set -e". > The list is attached. This list includes the 12 remaining scripts not > starting on #! (bugs are already filed for these). > > Policy says in Section 10.4: > > Shell scripts (sh and bash) other than init.d scripts should almost > certainly start with set -e so that errors are detected. > [..] > Every script should use set -e or check the exit status of every > command. > > I had a cursory look over the listed maintainer scripts, and did not > find any that does a careful checking of exit statuses. Though some > of them are quite trivial, or even sometimes empty. It looks to me > as not using strict mode in these cases is an oversight, and I would > like to file bugs for these. > > What is your opinion? Policy says "should", not "must". If you agree > with the MBF, what do you think would be the appropriate severity? Important. Btw I just fixed these: ekiga-dbg_4.0.1-6+b5/postinst ekiga-dbg_4.0.1-6+b5/postrm ekiga-dbg_4.0.1-6+b5/preinst Cheers, Emilio
Re: IMPORTANT: Do live Debian images have a future?
On Mon, Jun 26, 2017 at 02:09:00PM -0700, Rick Thomas wrote: > PS: On a related topic: What I think would be really cool, would be > Debian Live images for some of the ARM architectures. Something I could > dd to a USB stick and boot right away when I get a new box in for testing. > Even cooler would be the ability to use that self-same live image to > install Debian after the testing phase was over. Alas, all ARMs I personally saw require a device-specific u-boot setup, and don't allow booting from USB mass storage -- you need a supported kind of boot device load u-boot, and only that may then chainload from USB. This is different in those legendary ARMs that have UEFI support, but they must be a myth. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can. ⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener. ⠈⠳⣄ A master species delegates.
Re: Intended MBF: maintainer scripts not using strict mode
Ralf Treinen wrote... > What is your opinion? Certainly the right thing to do. These scripts run as root, that's reaon enough to enforce extra precautions. I'd consider even stricter modes like set -u, unless ... Let's be honest: Shell scripts, while easy to write, carry too many risks of unsafe programming. So while your proposed fixing is a step in the right direction, this is all just band-aid. We (as in Debian) should look forward and try to replace these maintainer scripts with something more error-prone. Niels has mentioned declarative approaches which seem like a good idea. No idea about the status, though, and I'm interested in details if there already are some. Christoph signature.asc Description: Digital signature
Bug#866047: ITP: factorio-server -- headless server for the game Factorio
Package: wnpp Severity: wishlist Owner: Justin Gerhardt * Package name: factorio-server Version : 0.15.23 Upstream Author : Wube Software * URL : https://www.factorio.com/ * License : Proprietary Programming Lang: C++ Description : headless server for the game Factorio Factorio is a massively popular factory management and automation game. This packages is the headless server used to host dedicated multiplayer games. Community efforts have so far created distributions for Docker, Ansible and a number of cloud offerings. I beleive adding a package for Debian and its derivatives would benefit many users though easier updates and init system intergration. This is my first time creating a package. I intent to the best of my abilities maintain it myself. It should be simple enough not to require a comaintainer. I will need a sponsor for the ultimate inclusion in the non-free repo games section.
Bug#866053: ITP: emacs-ivy-doc -- documentation for emacs' Incremental Vertical completYon
Package: wnpp Severity: wishlist Owner: Nicholas D Steeves * Package name: emacs-ivy-doc Version : 0.9.1-1 Upstream Author : Oleh Krehel * URL : https://github.com/abo-abo/swiper * License : GFDL Programming Lang: Markdown and TeX Description : documentation for emacs' Incremental Vertical completYon This package contains documentation for emacs-ivy that cannot be part of the main Debian archive due to the presence of cover page and invariant GDFL texts. . That is to say, it is not DFSG-free. >From the related Bug #864912 On Sat, Jun 24, 2017 at 09:46:18PM +0100, Sean Whitton wrote: > > On Fri, Jun 23, 2017 at 02:35:20PM -0400, Nicholas D Steeves wrote: > > Emacs-ivy-doc is also pretty much ready to upload to non-free/docs; I > > just need to find out what I should build from the .texi--man page, > > and info page? Man page, info page and html doc? Something else? > > Without looking at the source, Info and HTML sounds sensible. So, thus far the plan is to build Info and HTML docs from the .org and/or .texi source. If I remember correctly the .texi is built from the .org upstream.
Re: [WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading
(updates, hopefully the last ones...) On Sun, 25 Jun 2017, Henrique de Moraes Holschuh wrote: > Fast-forward a few months, and Mark Shinwell noticed the mention of a > possible fix for a microcode defect with unknown hit-ratio in the > intel-microcode package changelog. He matched it to the issues the > OCaml community were observing, verified that the microcode fix indeed > solved the OCaml issue, and contacted the Debian maintainer about it. There are a few factual incorrections in the advisory text, which were entirely my fault, and for which I apologise. The corrections are below: 1. It was one of the OCaml bug reporters (by the handle of ygrek) who first noticed that the 20170511 microcode update could be relevant, and not Mark Shinwell. 2. Various other bug reporters and OCaml developers, some under request from Mark and some by their own volition, helped out and devoted substantial time to investigating the issue. I apologise to those involved: to "ygrek" for misreading the bug report and attributing to Mark Shinwell the correlation between the SKL150 erratum description and the OCaml compiler issue report; and to all members of the OCaml community that worked on the issue both in the bug report and behind the scenes, for not explicitly crediting their effort. The original OCaml bug report is listed in the references section at the end of the advisory (and also in this update). > Related processor signatures and microcode revisions: > Skylake : 0x406e3, 0x506e3 (fixed in revision 0xb9/0xba and later, > public fix in linux microcode 20170511) > Skylake : 0x50654 (no information, erratum listed) > Kaby Lake : 0x806e9, 0x906e9 (defect still exists in revision 0x48, > fix available as a BIOS/UEFI update) The recently launched "Kaby Lake-X" processors (signature 0x906e9, socket LGA2066) are documented by Intel as *NOT* being affected by the KBL095 defect. This information comes from table 16 of the latest revision of the "7th gen. Core Family specification update" (which is listed in the references section). Please note that the "7th gen. Core i7 X-series processors" (Kaby Lake-X) both support hyper-threading and share the processor signature (family, model number and stepping) with "Kaby Lake-H/S" processors. The tests in the advisory (and also the perl script) will *incorrectly* report Kaby Lake-X processors as affected. References: https://caml.inria.fr/mantis/view.php?id=7452 http://metadata.ftp-master.debian.org/changelogs/non-free/i/intel-microcode/unstable_changelog https://www.intel.com/content/www/us/en/processors/core/desktop-6th-gen-core-family-spec-update.html https://www.intel.com/content/www/us/en/processors/core/7th-gen-core-family-spec-update.html https://www.intel.com/content/www/us/en/processors/xeon/xeon-e3-1200v6-spec-update.html https://www.intel.com/content/www/us/en/processors/xeon/xeon-e3-1200v5-spec-update.html https://www.intel.com/content/www/us/en/products/processors/core/6th-gen-x-series-spec-update.html -- Henrique Holschuh
Re: Intended MBF: maintainer scripts not using strict mode
Hi, Quoting Christoph Biedl (2017-06-27 00:37:33) > Let's be honest: Shell scripts, while easy to write, carry too many risks of > unsafe programming. So while your proposed fixing is a step in the right > direction, this is all just band-aid. We (as in Debian) should look forward > and try to replace these maintainer scripts with something more error-prone. > Niels has mentioned declarative approaches which seem like a good idea. No > idea about the status, though, and I'm interested in details if there already > are some. this might've exactly been the angle that made Ralf find these issues with maintainer scripts in the first place: https://debconf16.debconf.org/talks/63/ https://www.irif.fr/~treinen/colis/ Thanks! cheers, josch signature.asc Description: signature
Re: Intended MBF: maintainer scripts not using strict mode
On Tue, Jun 27, 2017 at 6:37 AM, Christoph Biedl wrote: > Let's be honest: Shell scripts, while easy to write, carry too many > risks of unsafe programming. So while your proposed fixing is a step in > the right direction, this is all just band-aid. We (as in Debian) should > look forward and try to replace these maintainer scripts with something > more error-prone. Niels has mentioned declarative approaches which seem > like a good idea. No idea about the status, though, and I'm interested > in details if there already are some. I assume you meant *less* error-prone :) For maintainer scripts that can't be converted to the declarative approaches, I hope that folks are checking their scripts using the various tools available to do that, especially shellcheck: https://anonscm.debian.org/cgit/collab-maint/check-all-the-things.git/tree/data/sh.ini -- bye, pabs https://wiki.debian.org/PaulWise
Re: Intended MBF: maintainer scripts not using strict mode
On Mon, Jun 26, 2017 at 11:47:53PM +0200, Emilio Pozuelo Monfort wrote: > Btw I just fixed these: > ekiga-dbg_4.0.1-6+b5/postinst > ekiga-dbg_4.0.1-6+b5/postrm > ekiga-dbg_4.0.1-6+b5/preinst While you are at it, please convert these to automatic debug symbol packages. This can be done by just removing all traces of ekiga-dbg and let debhelper do it's magic. Bastian -- Extreme feminine beauty is always disturbing. -- Spock, "The Cloud Minders", stardate 5818.4
Re: Intended MBF: maintainer scripts not using strict mode
On Tue, Jun 27, 2017 at 4:23 AM, Ralf Treinen wrote: > we currently have in sid 84 maintainer scripts not using strict mode. > That is, they neither start on "#!/bin/[ba]sh -e", nor do a "set -e". > The list is attached. This list includes the 12 remaining scripts not > starting on #! (bugs are already filed for these). Looks like you were talking about these bugs: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=colis-shparser;users=trei...@debian.org > What is your opinion? Policy says "should", not "must". If you agree > with the MBF, what do you think would be the appropriate severity? I note that naively adding "set -e" can make shell scripts more brittle, especially when using diff or other commands that can return failure in unforeseen circumstances. When doing the MBF, please remind people to read their scripts, note the range of exit codes for each command and add "|| true" for commands that return failure exit codes that do not indicate failures or indicate conditions that should not terminate the maintainer script. PS: will you be packaging the software produced by the CoLiS project? PPS: the lintshell link on the CoLiS website requires a login. -- bye, pabs https://wiki.debian.org/PaulWise
Re: IMPORTANT: Do live Debian images have a future?
Hello Steve, thanks for your work on this task. I myself use it from time to time to show how Debian can looks like without installing at the target machine. So I have USB Sticks with me (with the inofficial non-free image). Kind regards Mechtilde Am 26.06.2017 um 16:08 schrieb Steve McIntyre: > [ Note the cross-posting... ] > > Hey folks, > > Background: we released live images for Stretch using new tooling, > namely live-wrapper. It is better than what we had before (live-build) > in a number of ways, particularly in terms of build reliability and > some important new features (e.g. UEFI support). But it's also less > mature and has seen less testing. There have been bugs because of > that. I have fixes for most of the ones I know about [1], and I'm > still working on more bugfixes yet. > > While the bugs are annoying, what worries me more is that they were > only spotted in release builds. There had been testing versions of > live images available for multiple weeks beforehand, presumably with > the same bugs included. (Almost) none of them reported. This shows > that we don't have enough people using these live images and/or caring > about filing bugs. > > We have a similar lack of involvement in terms of the content of the > live images. As I said above, I'm happy that we now have a reliable > tool for building our live images - that makes my life much > easier. But I honestly have no idea if the multiple desktop-specific > live images are actually reasonable representations of each of the > desktops. For example, I *seriously* hope that normal KDE > installations are not effected by #865382 like our live KDE > images. Validation by the various desktop teams would be useful here. > > The current situation is *not* good enough. I ended up getting > involved in live image production because the images needed making, > and I was already the main person organising production of Debian's > official images. To be frank, I had (and still have) no direct use for > the live images myself and I don't *particularly* care about them all > that much. Despite that, I've ended up spending a lot of time working > on them. A few other people have also spent a lot of time working in > this area - thanks are due to those people too. But it's still not > enough. > > If our live images are going to be good enough to meet the standards > that Debian users deserve and expect, we need *consistent*, > *sustained* involvement from a lot more people. Please tell me if > you're going to help. If we don't see a radical improvement soon, I'll > simply disable building live images altogether to remove the false > promises they're making. > > [1] > https://get.debian.org/images/release/current-live/amd64/iso-hybrid/#issues > -- Mechtilde Stehmann ## Apache OpenOffice.org ## Freie Office Suite für Linux, MacOSX, Windows ## Debian Developer ## Loook, calender-exchange-provider, libreoffice-canzeley-client ## PGP encryption welcome ## Key-ID 0x141AAD7F signature.asc Description: OpenPGP digital signature
Re: Intended MBF: maintainer scripts not using strict mode
On 27/06/17 07:04, Bastian Blank wrote: > On Mon, Jun 26, 2017 at 11:47:53PM +0200, Emilio Pozuelo Monfort wrote: >> Btw I just fixed these: >> ekiga-dbg_4.0.1-6+b5/postinst >> ekiga-dbg_4.0.1-6+b5/postrm >> ekiga-dbg_4.0.1-6+b5/preinst > > While you are at it, please convert these to automatic debug symbol > packages. This can be done by just removing all traces of ekiga-dbg and > let debhelper do it's magic. Well, that's exactly what I did. Emilio
