Re: Debian i386 architecture now requires a 686-class processor

[Adam Borowski]

On Wed, May 11, 2016 at 01:54:04PM -0700, Russ Allbery wrote:
> If someone has time and willingness, reviewing the contents of NEWS.Debian
> across all packages for the stable -> testing delta before the release
> sounds like a very useful thing to do.

>From what I've seen, this is very close to our problem with Recommends: --
those pointless NEWS.Debian _do_ make sense "locally" -- for a direct user
of the package in question.  If you're, say, coding something with a
library, you're interested when that library changed its API in an
incompatible way.  On the other hand, if you merely use something that
depends on the library, you couldn't care less.

> A great volunteer task to help with the release!

I'm afraid we'd need to come up with some guidelines first, especially with
the above issue in mind.

You can for start with packages you have installed:
zless /usr/share/doc/*/NEWS.Debian*


adequate
   only for a direct user
alsa-utils
   only for a direct user
amd64-microcode
   niche news
apt
   probably valid
apt-listchanges
   sneakily worded "won't work in common situations"
autoconf
   only for a direct user (API changes)
btrbk
   valid -- everyone needs to rewrite their configs
ca-certificates
   spam that belongs in the changelog
ccache
   not relevant (old data will silently expire anyway)
chrony
   valid.  Multiple entries, of varying relevance.
llvm-*
   changelog material
coreutils
   niche news
cron
   niche news
curl
   spam
d-conf
   only for a direct user
dctrl-tools
   spam (apt does this 100% transparently)
debian-keyring
   very niche news
devscripts
   minor behaviour change
dirmngr
   only for a direct user
docbook-xsl
   speculation about future changes...
doomsday
   documenting a bug (one that's easy to fix with some debugging)
ceve
   niche ever for a direct user
dosfstools
   documents a likely breakage, not interesting for a non-user
exim4
   relevant for an admin, spam for those who don't know what a MTA is
exo
   a restart-on-upgrade quirk
findutils
   niche news
fonts-vlgothic
   file rename, 99.9% users use it via fontconfig anyway...
wine
   valid
gconf
   a restart-on-upgrade quirk
[here I got bored]


As you can see, most of the news are relevant only for an immediate user
while being utterly pointless for those who installed package X only via
a dependency.  But, how do you tell them apart?  What about the case you
both use X directly and as a dependency?

And it needs to be stressed: being relevant only for an immediate users
means the news is still _relevant_ for them.


-- 
How to exploit the Bible for weight loss:
Pr28:25: he that putteth his trust in the ʟᴏʀᴅ shall be made fat.

Re: Debian i386 architecture now requires a 686-class processor

[Marc Haber]

On Wed, 11 May 2016 13:54:04 -0700, Russ Allbery 
wrote:
>Marc Haber  writes:
>> On Wed, 11 May 2016 10:18:05 -0700, Russ Allbery  wrote:
>
>>> NEWS.Debian was the solution created for that problem, and it's not
>>> bad.  It can be a bit too verbose in a few cases, but it's almost
>>> always worth reading carefully.
>
>> I'd still like to have something that is vetted by the release team,
>> so that those texts can be pulled into the release notes verbatim.
>
>If someone has time and willingness, reviewing the contents of NEWS.Debian
>across all packages for the stable -> testing delta before the release
>sounds like a very useful thing to do.  A great volunteer task to help
>with the release!

I would ask the maintainers to do so. I think that only a small
fraction of NEWS.Debian actually needs to be in the "release notes".

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: Bug#823465: dpkg: Won't run at all on i586 Pentium MMX due to illegal instruction

[Nikolaus Rath]

On May 11 2016, Theodore Ts'o  wrote:
> On Mon, May 09, 2016 at 10:21:21AM -0700, Nikolaus Rath wrote:
>> > 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.
>> 
>> I'd advise against using LVM snapshots. The time for initial activation
>> seems to go up exponentially with the amount of data in snapshot
>> volumes. I think they are only intended for short-term use
>> (e.g. to take a backup).
>
> If what you want to do is a rollback operation after a package
> installation goes badly, LVM snapshots are sufficient.

Yes, sorry, I didn't make that clear. I was picking up on the
"backups/sys-2016-05-07" example, where the nomeclature seems to imply
that there are a lot of such snapshots.

Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Re: Bug#823465: dpkg: Won't run at all on i586 Pentium MMX due to illegal instruction

[Ben Hutchings]

On Wed, 2016-05-11 at 19:25 -0400, Theodore Ts'o wrote:
> On Mon, May 09, 2016 at 10:21:21AM -0700, Nikolaus Rath wrote:
> > 
> > > 
> > > 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.
> > I'd advise against using LVM snapshots. The time for initial activation
> > seems to go up exponentially with the amount of data in snapshot
> > volumes. I think they are only intended for short-term use
> > (e.g. to take a backup).
> If what you want to do is a rollback operation after a package
> installation goes badly, LVM snapshots are sufficient.  They aren't as
> convenient as btrfs, but they do work.  So what you'd do is do is (a)
> create the snapshot, (b) inststall the package.  If the package looks
> good, then delete the snapshot.
> 
> If you discover that the package hoses your system then to rollback,
> shutdown the system to single-user mode, and remount the file system
> to be read-only, and then use the command lvconvert --merge to restore
> your file system back to the state of the snapshot.  This will consume
> the snapshot, and leave the file system (presumably ext3 or ext4) in a
> potentially confused state, which is why you need to do this with the
> file system remounted read-only.   Then reboot, and you're all set.

What could possibly go wrong?

> I there is a yum plugin for Fedora where you reboot, and the lvconvert
> --merge is done as part of the reboot (either as the system is
> shutting down, or in the initramfs before the file system is mounted).
> That's a much more convenient and user-friendly way to do the
> rollback; creating such a covenience setup is left as an exercise to
> the reader.  :-)

That makes a lot more sense to me than doing weird things behind the
filesystems's back.  Implementing a shutdownfs in initramfs-tools is
certainly something I'd like to do, though I don't have any solid
plans.

Ben.

-- 
Ben Hutchings
If you seem to know what you are doing, you'll be given more to do.

signature.asc
Description: This is a digitally signed message part

Re: Bug#824057: ITP: bitkeeper -- source code management system

[Ben Hutchings]

On Wed, 2016-05-11 at 13:55 -0700, Russ Allbery wrote:
> Daniel Stender  writes:
> 
> > 
> > Distributed source control management/revision control system. Known as
> > being used for the Linux kernel development before Git was created.  The
> > now have put the code under the Apache-2.0 license. Maybe some would
> > like to use this, so it would do no harm to have it as a Debian package.
> FWIW, there was a fairly entertaining exchange on oss-security earlier
> this week in which someone pointed out it was riddled with /tmp
> vulnerabilities found with a simple grep, and the author said that no one
> had cared because it was only deployed behind firewalls.

That's a stunningly blasé attitude to security at this point in time.

I really don't think we need more known-vulnerable software in the
archive.

Ben.

-- 
Ben Hutchings
If you seem to know what you are doing, you'll be given more to do.

signature.asc
Description: This is a digitally signed message part

Re: Bug#824057: ITP: bitkeeper -- source code management system

[Ole Streicher]

Jakub Wilk  writes:
> I strongly recommend against packaging software you don't personally
> use. This never goes well. (I say this as someone who did this mistake
> in the past, multiple times.)

I don't use most of my packages myself, and I don't think it was a
mistake to package them. The reason to package it was that I think they
are important to the community, and I feel competent enough to support
them.

Cheers

Ole

Re: Bug#823465: dpkg: Won't run at all on i586 Pentium MMX due to illegal instruction

[Theodore Ts'o]

On Mon, May 09, 2016 at 10:21:21AM -0700, Nikolaus Rath wrote:
> > 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.
> 
> I'd advise against using LVM snapshots. The time for initial activation
> seems to go up exponentially with the amount of data in snapshot
> volumes. I think they are only intended for short-term use
> (e.g. to take a backup).

If what you want to do is a rollback operation after a package
installation goes badly, LVM snapshots are sufficient.  They aren't as
convenient as btrfs, but they do work.  So what you'd do is do is (a)
create the snapshot, (b) inststall the package.  If the package looks
good, then delete the snapshot.

If you discover that the package hoses your system then to rollback,
shutdown the system to single-user mode, and remount the file system
to be read-only, and then use the command lvconvert --merge to restore
your file system back to the state of the snapshot.  This will consume
the snapshot, and leave the file system (presumably ext3 or ext4) in a
potentially confused state, which is why you need to do this with the
file system remounted read-only.   Then reboot, and you're all set.

I there is a yum plugin for Fedora where you reboot, and the lvconvert
--merge is done as part of the reboot (either as the system is
shutting down, or in the initramfs before the file system is mounted).
That's a much more convenient and user-friendly way to do the
rollback; creating such a covenience setup is left as an exercise to
the reader.  :-)

Cheers,

- Ted

Re: Bug#824057: ITP: bitkeeper -- source code management system

[Jakub Wilk]

Hi Daniel!

* Daniel Stender , 2016-05-11, 20:08:
Distributed source control management/revision control system. Known as 
being used for the Linux kernel development before Git was created. The 
now have put the code under the Apache-2.0 license. Maybe some would 
like to use this, so it would do no harm to have it as a Debian 
package.


This sounds as if you're not a Bitkeeper user yourself. I strongly 
recommend against packaging software you don't personally use. This 
never goes well. (I say this as someone who did this mistake in the 
past, multiple times.)


--
Jakub Wilk

Re: Bug#824057: ITP: bitkeeper -- source code management system

[Daniel Stender]

On 11.05.2016 22:55, Russ Allbery wrote:
> Daniel Stender  writes:
> 
>> Distributed source control management/revision control system. Known as
>> being used for the Linux kernel development before Git was created.  The
>> now have put the code under the Apache-2.0 license. Maybe some would
>> like to use this, so it would do no harm to have it as a Debian package.
> 
> FWIW, there was a fairly entertaining exchange on oss-security earlier
> this week in which someone pointed out it was riddled with /tmp
> vulnerabilities found with a simple grep, and the author said that no one
> had cared because it was only deployed behind firewalls.

Yep, I've seen it now. And ... "only used by trusted personnel" :-)

I'll watch how this develops.

Thanks,
Dan

-- 
4096R/DF5182C8
http://www.danielstender.com/blog/

Re: Bug#824057: ITP: bitkeeper -- source code management system

[Paul R. Tagliamonte]

http://www.openwall.com/lists/oss-security/2016/05/10/5 <-- link to
that discussion!

On Wed, May 11, 2016 at 4:55 PM, Russ Allbery  wrote:
> Daniel Stender  writes:
>
>> Distributed source control management/revision control system. Known as
>> being used for the Linux kernel development before Git was created.  The
>> now have put the code under the Apache-2.0 license. Maybe some would
>> like to use this, so it would do no harm to have it as a Debian package.
>
> FWIW, there was a fairly entertaining exchange on oss-security earlier
> this week in which someone pointed out it was riddled with /tmp
> vulnerabilities found with a simple grep, and the author said that no one
> had cared because it was only deployed behind firewalls.
>
> --
> Russ Allbery (r...@debian.org)   
>



-- 
:wq

Re: Bug#824057: ITP: bitkeeper -- source code management system

[Russ Allbery]

Daniel Stender  writes:

> Distributed source control management/revision control system. Known as
> being used for the Linux kernel development before Git was created.  The
> now have put the code under the Apache-2.0 license. Maybe some would
> like to use this, so it would do no harm to have it as a Debian package.

FWIW, there was a fairly entertaining exchange on oss-security earlier
this week in which someone pointed out it was riddled with /tmp
vulnerabilities found with a simple grep, and the author said that no one
had cared because it was only deployed behind firewalls.

-- 
Russ Allbery (r...@debian.org)   

Re: Debian i386 architecture now requires a 686-class processor

[Russ Allbery]

Marc Haber  writes:
> On Wed, 11 May 2016 10:18:05 -0700, Russ Allbery  wrote:

>> NEWS.Debian was the solution created for that problem, and it's not
>> bad.  It can be a bit too verbose in a few cases, but it's almost
>> always worth reading carefully.

> I'd still like to have something that is vetted by the release team,
> so that those texts can be pulled into the release notes verbatim.

If someone has time and willingness, reviewing the contents of NEWS.Debian
across all packages for the stable -> testing delta before the release
sounds like a very useful thing to do.  A great volunteer task to help
with the release!

-- 
Russ Allbery (r...@debian.org)   

Re: Debian i386 architecture now requires a 686-class processor

[Adam Borowski]

On Wed, May 11, 2016 at 07:27:30PM +0200, Christian Seiler wrote:
> At least on my system (default configuration) apt-listchanges shows
> only NEWS.Debian, not changelog.Debian. The only qualm I have with
> it is that there appears to be no option to abort the install after
> apt-listchanges displays the changes: I run apt-get upgrade, then
> it asks me if I want to update that list of packages, I answer yes,
> then it downloads them all, apt-listchanges shows the NEWS files in
> the configured pager ('less' in my case), and the only option I
> have (other than logging in on another console and force-killing
> APT) is to exit the pager with q, upon which APT immediately starts
> to install the packages.

Ctrl-C cleanly kills both the pager and apt.

Too bad, there has been a misguided change to apt-listchanges recently: if
you run "apt-get -y upgrade" (it's pointless to ask for confirmation twice,
especially when you don't even yet know what you confirm), you _won't_ get
shown the NEWS/changelogs (or rather, they'll be blown to stdout then hidden
by further output, not giving you a chance to read them).  This has
apparently been due to confusion with DEBIAN_FRONTEND=noninteractive.

-- 
How to exploit the Bible for weight loss:
Pr28:25: he that putteth his trust in the ʟᴏʀᴅ shall be made fat.

Re: Debian i386 architecture now requires a 686-class processor

[Manuel A. Fernandez Montecelo]

2016-05-11 18:27 Christian Seiler:

On 05/11/2016 07:01 PM, Marc Haber wrote:

On Wed, 11 May 2016 17:03:05 +0200, Nicolas Dandrimont
 wrote:

* Marc Haber  [2016-05-11 10:47:52 +0200]:


We could have a "show-release-notes" package containing a script that
scans (pre-upgrade) the installed packages and shows all release-notes
relevant to those packages. This would need the release notes to be in
a somewhat automatically-selectable format, most easily a http-served
directory somewhere with a packagename.txt for each package that has
relevant text that went past the package maintainer and the release
team. Some thought needs to go in there for the cases where package
foo is superseded by foo2. Most easily this could be a simple symlink
in the releasenotes directory.


That really sounds like what apt-listchanges already does.


Yes.

Maybe I misremember and it was by reading the changelogs, or blog
entries or something else... but I think that I have seen such warnings
in apt-listchanges through NEWS.Debian in the past, when some Linux
kernel flavours were going to be removed or made incompatible with my
machine (related to PAE?  or maybe this very issue?), and that I stopped
the upgrade and changed to the correct package for that machine.


I think that it's a good solution for cases like this.  I don't know how
many people use apt-listchanges, though.  (And I am not necessarily
saying that it has to be the only measure taken).



The only qualm I have with
it is that there appears to be no option to abort the install after
apt-listchanges displays the changes:


 $ tail /etc/apt/listchanges.conf
 [apt]
 frontend=pager
 email_address=
 confirm=1
 ^
 save_seen=/var/lib/apt/listchanges.db
 which=both

IIRC it's asked by debconf, and can be changed with:

 dpkg-reconfigure apt-listchanges


--
Manuel A. Fernandez Montecelo 

Bug#824057: ITP: bitkeeper -- source code management system

[Daniel Stender]

Package: wnpp
Severity: wishlist
Owner: Daniel Stender 

* Package name: bitkeeper
  Version : 7.2ce
  Upstream Author : Wayne Scott 
* URL : https://www.bitkeeper.org/
* License : Apache-2.0
  Programming Lang: C
  Description : source code management system (SCM)

Distributed source control management/revision control system. Known
as being used for the Linux kernel development before Git was created.
The now have put the code under the Apache-2.0 license. Maybe some would
like to use this, so it would do no harm to have it as a Debian package.

Thanks,
DS

Re: Debian i386 architecture now requires a 686-class processor

[Marc Haber]

On Wed, 11 May 2016 10:18:05 -0700, Russ Allbery 
wrote:
>Marc Haber  writes:
>> apt-listchanges drowns the user in the change logs, most of which are
>> irrevant. I think of a solution that will show text that has been vetted
>> by the package maintainer _and_ the release teams and that documents
>> possible breakage during updates only. At this point, I don't care that
>> a package has bumped its Standards-Version: field, or that a new person
>> was added to Uploaders:.
>
>NEWS.Debian was the solution created for that problem, and it's not bad.
>It can be a bit too verbose in a few cases, but it's almost always worth
>reading carefully.

I'd still like to have something that is vetted by the release team,
so that those texts can be pulled into the release notes verbatim.

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: Debian i386 architecture now requires a 686-class processor

[Christian Seiler]

On 05/11/2016 07:01 PM, Marc Haber wrote:
> On Wed, 11 May 2016 17:03:05 +0200, Nicolas Dandrimont
>  wrote:
>> * Marc Haber  [2016-05-11 10:47:52 +0200]:
>>
 The third reason is the question of how much in detail the release
 notes should actually be. In a strange way in the past they were too
 short. That made me reluctant to suggest entries for low-popcon
 packages as their significance doesn't match the prominence of being
 mentioned in the notes.
>>>
>>> We could have a "show-release-notes" package containing a script that
>>> scans (pre-upgrade) the installed packages and shows all release-notes
>>> relevant to those packages. This would need the release notes to be in
>>> a somewhat automatically-selectable format, most easily a http-served
>>> directory somewhere with a packagename.txt for each package that has
>>> relevant text that went past the package maintainer and the release
>>> team. Some thought needs to go in there for the cases where package
>>> foo is superseded by foo2. Most easily this could be a simple symlink
>>> in the releasenotes directory.
>>
>> That really sounds like what apt-listchanges already does.
> 
> apt-listchanges drowns the user in the change logs, most of which are
> irrevant. I think of a solution that will show text that has been
> vetted by the package maintainer _and_ the release teams and that
> documents possible breakage during updates only. At this point, I
> don't care that a package has bumped its Standards-Version: field, or
> that a new person was added to Uploaders:.

At least on my system (default configuration) apt-listchanges shows
only NEWS.Debian, not changelog.Debian. The only qualm I have with
it is that there appears to be no option to abort the install after
apt-listchanges displays the changes: I run apt-get upgrade, then
it asks me if I want to update that list of packages, I answer yes,
then it downloads them all, apt-listchanges shows the NEWS files in
the configured pager ('less' in my case), and the only option I
have (other than logging in on another console and force-killing
APT) is to exit the pager with q, upon which APT immediately starts
to install the packages. I didn't check any docs though if that is
configurable, just saying that by default apt-listchanges should
ask whether to continue or not, if there were any NEWS entries it
displayed.

(Also, just concatenating them and feeding them to a pager is not
optimal, because if you have a couple of different systems, and you
upgrade them at the same time, you aren't going to read the same
message twice - but in skimming the output on the second system you
upgrade, you might overlook the NEWS entry for a different package
that wasn't installed on the first one. I don't have a good idea
how to improve that, just saying this is worth thinking about.)

Regards,
Christian



signature.asc
Description: OpenPGP digital signature

Re: Debian i386 architecture now requires a 686-class processor

[Marco d'Itri]

On May 11, Russ Allbery  wrote:

> NEWS.Debian was the solution created for that problem, and it's not bad.
> It can be a bit too verbose in a few cases, but it's almost always worth
> reading carefully.
It would help if more people opened bugs on packages with NEWS.Debian 
content which is not actually newsworthy. :-)

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#824052: ITP: python-pattern -- web mining module for Python

[Miriam Ruiz]

Package: wnpp
Severity: wishlist
Owner: Miriam Ruiz 

* Package name: python-pattern
  Version : 2.6
  Upstream Author : Tom De Smedt 
* URL : http://www.clips.ua.ac.be/pages/pattern
* License : BSD
  Programming Lang: Python
  Description : web mining module for Python

Pattern is a web mining module for the Python programming language. It has
tools for data mining (Google, Twitter and Wikipedia API, a web crawler,
a HTML DOM parser), natural language processing (part-of-speech taggers,
n-gram search, sentiment analysis, WordNet), machine learning (vector space
model, clustering, SVM), network analysis and  visualization.

The module is free, well-document and bundled with 50+ examples and
350+ unit tests.

Re: Debian i386 architecture now requires a 686-class processor

[Jonas Smedegaard]

Quoting Marc Haber (2016-05-11 19:01:03)
> On Wed, 11 May 2016 17:03:05 +0200, Nicolas Dandrimont
>  wrote:
> >* Marc Haber  [2016-05-11 10:47:52 +0200]:
> >
> >> >The third reason is the question of how much in detail the release
> >> >notes should actually be. In a strange way in the past they were too
> >> >short. That made me reluctant to suggest entries for low-popcon
> >> >packages as their significance doesn't match the prominence of being
> >> >mentioned in the notes.
> >> 
> >> We could have a "show-release-notes" package containing a script that
> >> scans (pre-upgrade) the installed packages and shows all release-notes
> >> relevant to those packages. This would need the release notes to be in
> >> a somewhat automatically-selectable format, most easily a http-served
> >> directory somewhere with a packagename.txt for each package that has
> >> relevant text that went past the package maintainer and the release
> >> team. Some thought needs to go in there for the cases where package
> >> foo is superseded by foo2. Most easily this could be a simple symlink
> >> in the releasenotes directory.
> >
> >That really sounds like what apt-listchanges already does.
> 
> apt-listchanges drowns the user in the change logs, most of which are
> irrevant. I think of a solution that will show text that has been
> vetted by the package maintainer _and_ the release teams and that
> documents possible breakage during updates only. At this point, I
> don't care that a package has bumped its Standards-Version: field, or
> that a new person was added to Uploaders:.

By default, apt-listchanges show only NEWS entries.

Not exactly what you dream about, but closer than the flood you image, 
it sound like.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Debian i386 architecture now requires a 686-class processor

[Russ Allbery]

Marc Haber  writes:

> apt-listchanges drowns the user in the change logs, most of which are
> irrevant. I think of a solution that will show text that has been vetted
> by the package maintainer _and_ the release teams and that documents
> possible breakage during updates only. At this point, I don't care that
> a package has bumped its Standards-Version: field, or that a new person
> was added to Uploaders:.

NEWS.Debian was the solution created for that problem, and it's not bad.
It can be a bit too verbose in a few cases, but it's almost always worth
reading carefully.

-- 
Russ Allbery (r...@debian.org)   

Re: Debian i386 architecture now requires a 686-class processor

[Marc Haber]

On Wed, 11 May 2016 17:03:05 +0200, Nicolas Dandrimont
 wrote:
>* Marc Haber  [2016-05-11 10:47:52 +0200]:
>
>> >The third reason is the question of how much in detail the release
>> >notes should actually be. In a strange way in the past they were too
>> >short. That made me reluctant to suggest entries for low-popcon
>> >packages as their significance doesn't match the prominence of being
>> >mentioned in the notes.
>> 
>> We could have a "show-release-notes" package containing a script that
>> scans (pre-upgrade) the installed packages and shows all release-notes
>> relevant to those packages. This would need the release notes to be in
>> a somewhat automatically-selectable format, most easily a http-served
>> directory somewhere with a packagename.txt for each package that has
>> relevant text that went past the package maintainer and the release
>> team. Some thought needs to go in there for the cases where package
>> foo is superseded by foo2. Most easily this could be a simple symlink
>> in the releasenotes directory.
>
>That really sounds like what apt-listchanges already does.

apt-listchanges drowns the user in the change logs, most of which are
irrevant. I think of a solution that will show text that has been
vetted by the package maintainer _and_ the release teams and that
documents possible breakage during updates only. At this point, I
don't care that a package has bumped its Standards-Version: field, or
that a new person was added to Uploaders:.

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: Debian i386 architecture now requires a 686-class processor

[Nicolas Dandrimont]

* Marc Haber  [2016-05-11 10:47:52 +0200]:

> >The third reason is the question of how much in detail the release
> >notes should actually be. In a strange way in the past they were too
> >short. That made me reluctant to suggest entries for low-popcon
> >packages as their significance doesn't match the prominence of being
> >mentioned in the notes.
> 
> We could have a "show-release-notes" package containing a script that
> scans (pre-upgrade) the installed packages and shows all release-notes
> relevant to those packages. This would need the release notes to be in
> a somewhat automatically-selectable format, most easily a http-served
> directory somewhere with a packagename.txt for each package that has
> relevant text that went past the package maintainer and the release
> team. Some thought needs to go in there for the cases where package
> foo is superseded by foo2. Most easily this could be a simple symlink
> in the releasenotes directory.

That really sounds like what apt-listchanges already does.
-- 
Nicolas Dandrimont

BOFH excuse #147:
Party-bug in the Aloha protocol.


signature.asc
Description: Digital signature

Re: Debian i386 architecture now requires a 686-class processor

[Marc Haber]

On Wed, 11 May 2016 00:31:00 +0200, Matthias Klose 
wrote:
>On 11.05.2016 00:17, Lisandro Damián Nicanor Pérez Meyer wrote:
>> On Saturday 07 May 2016 13:23:30 Ben Hutchings wrote:
>>> Last year it was decided to increase the minimum CPU features for the
>>> i386 architecture to 686-class in the stretch release cycle.  This
>>> means dropping support for 586-class and hybrid 586/686
>>> processors[1].(Support for 486-class processors was dropped, somewhat
>>> accidentally, in squeeze.)
>>>
>>> This was implemented in the Linux kernel packages starting with Linux
>>> 4.3, which was uploaded to unstable in December last year.
>>
>> I guess the answer is "no", but just to be sure: does this means that i386
>> supported processors need to implement SSE2?
>
>no.

Please at least try to be helpful by answering the question that
Lisandro actually wanted to ask.

I am not asking whether the needed feature is CMOV since I don't want
to give you the opportunity to be an ass for a second time.

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: Debian i386 architecture now requires a 686-class processor

[Marc Haber]

On Tue, 10 May 2016 08:13:40 +0200, Christoph Biedl
 wrote:
> Why is feature X in the new Debian release broken?
> Because you haven't read the release notes.
>(Same for NEWS.Debian)

Would you instead want the text part from release notes and/or
NEWS.Debian pasted in IRC?

>While technically true, that kind of behaviour drives people away from
>Debian for no good reason.

Those people who complain about releases changing things in a
distribution won't find a OS fitting their needs at all.

>There was no input from my side. One reason was specific for jessie: It
>took me until June 2015 to get systemd running reliably. That was of
>course way too late to share experiences from the upgrades that
>followed.

In my experience, and contrary to my own loudly voices predictions,
the sysvinit -> systemd migration was quite painless aside from a lot
of local changes getting lost during the upgrade because systemd
doesn't care. That's something one needs to get used to, but the
apache 2.2 => 2.4 upgrade was much more painful than all systemd
issues I experienced with jessie combined. Incidentally, the (few)
wheezy systems that are left up to now are those running more complex
apache setups.

>Second is a problem of social interaction. If I notice an upgrade issue
>in a package, I'll have to deal with two parties instead of just one.
>Should I ask the maintainer to submit the text to you, or do this on my
>own at the risk this is considered hostile? Also the release notes
>editors wish to be convinced, might deny the necessity, argue ... more
>time needed to write things down ... there's so little incentive to
>contribute to the release notes, and passing the information but other
>means like blogs or (for the maintainer) NEWS.Debian avoids all the
>hazzle.[1]

File a bug against the package, slap the future "release-notes" tag on
it, and let automatism and check lists do the rest.

>The third reason is the question of how much in detail the release
>notes should actually be. In a strange way in the past they were too
>short. That made me reluctant to suggest entries for low-popcon
>packages as their significance doesn't match the prominence of being
>mentioned in the notes.

We could have a "show-release-notes" package containing a script that
scans (pre-upgrade) the installed packages and shows all release-notes
relevant to those packages. This would need the release notes to be in
a somewhat automatically-selectable format, most easily a http-served
directory somewhere with a packagename.txt for each package that has
relevant text that went past the package maintainer and the release
team. Some thought needs to go in there for the cases where package
foo is superseded by foo2. Most easily this could be a simple symlink
in the releasenotes directory.

>>From past upgrades I estimate I could easily create 20 to 30 bits of
>that kind, and also that size. Do you consider such information
>relevant for the release notes? Then, given enough input, that document
>would become huge and rather a knowledge database. Probably nobody
>would read that completely. But wouldn't have to: Per package
>information, assessment ("you should know", "cosmetic issue", "manual
>intervention suggested", "will break your package", and a few more), a
>client using the list of packages actually installed - and I'd have a
>list of issues I should be prepared for on this very computer. That was
>nice to have.

Oh, You were faster with the idea than I was.

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: Debian i386 architecture now requires a 686-class processor

[Marc Haber]

On Mon, 9 May 2016 18:42:52 +, Niels Thykier 
wrote:
>But with that
>remark you make me feel like I have wasted my time and effort trying to
>the write the Jessie release notes.

You have not wasted your time. I do read the release notes, but I have
to admit that I only do so _after_ the release since I do not run
testing on production machines. I do however acknowlegde that it is
impossible to document all possible gotchas in the release notes.

Those who do run testing should be aware that there are no release
notes for a non-release, should expect breakage, and should document
such breakage in a way that it could be easily included in the release
notes for the case that the issue will be in the release.

Maybe we should introduce a BTS tag "release notes" so that (1) bug
reports of such gotchas can be flagged appropriately and (2) it is
easily possible to track such reports and thus checklist the release
notes' completeness.

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: Bug#823465: dpkg: Won't run at all on i586 Pentium MMX due to illegal instruction

[Marc Haber]

On Mon, 9 May 2016 23:13:19 +0200, Philipp Kern 
wrote:
>On Sun, May 08, 2016 at 07:46:52PM +0200, Marc Haber wrote:
>> 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".
>
>Could you please back up those claims (which seem pretty severe) with
>links to the threads?

You can look up my name in the linux-btrfs archives. I have not posted
otherwise there in the last few months.

Oh, yeah, I forgot the obligatory "your hardware is bad" hints.

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