Re: Please help test the PAM in experimental

[Svante Signell]

Hi,

you don't seem to address:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029097
why?

On Fri, 2024-01-19 at 11:40 -0700, Sam Hartman wrote:
> 
> There are a number of changes, and I'd just like a bit more
> confidence
> that it works as expected before uploading to unstable in about a
> week.
> 
> Changes include:
> 
> * Running pam_umask with usergroups support by default.
> 
> * libpam-modules now depends on libsystemd0 because utmp is not
>   y2038-clean and upstream has decided to depend on elogind for that.
> 
> * New PAM upstream and thus newly rebased patches.
> 
> So, it would be helpful especially if you would install libpam-
> modules
> and libpam0g from experimental.

Re: merged-/usr transition: debconf or not?

[Svante Signell]

On Thu, 2021-11-11 at 16:07 -0500, Zack Weinberg wrote:
> Marco d'Itri  wrote:
> > Since some significant work on dpkg is reasonably not forthcoming
> 
> Yeah, because _you,_ Marco, prefer to spend your time trying to
> gaslight the project into thinking there isn't a critical-severity
> bug in usrmerge.  This could have all been over by now if you had
> rolled up your sleeves and written the necessary patches for dpkg
> when Guillem originally notified you of the problem (in 2016;
> #848622; the bug log does not reflect the actual severity, but again
> that appears to be all on you).

I'm not sure he has the skill or experience enough to submit a patch to
dpkg. Complaining is much easier than proposing something constructive.

Just my $5c.

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Svante Signell]

On Tue, 2021-07-20 at 21:51 +, Holger Levsen wrote:
> On Tue, Jul 20, 2021 at 11:15:33PM +0200, Svante Signell wrote:
> [...]
> > Debian, the Universal Operating System was used some years ago!
> 
> Svante, fine. You are unhappy with Debian since years, you're not
> using it anymore, you are not contributing, this is debian-devel@ not
> debian-rant@, so please STFU.

Hi Holger, I would have expected a reply like this from you. I do still
use Debian, some of my boxes are still Debian-based. Soon they will
probably be converted to Devuan though. I do still contribute to
Debian, mainly to Debian GNU/Hurd and Debian GNU/kFreeBSD. As long as
these ports are still alive within Debian I won't go away.

Holger (and others), please consider the arguments and facts given in
the latest postings to this thread, these issues are serious and not
something you just can easily close with an STFU argument to me!

Thanks!

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Svante Signell]

On Tue, 2021-07-20 at 15:34 -0400, Polyna-Maude Racicot-Summerside
wrote:
> Hi,
> 
> On 2021-07-20 3:30 p.m., Marc Haber wrote:
> > On Tue, 20 Jul 2021 14:47:04 +0200, Svante Signell
> >  wrote:
> > > According to the dpkg developer and maintainer Guillem users can
> > > still rescue their systems from merged-/usr-via-aliased-dirs with
> > > the aid of dpkg-fsys-usrunmess(8), see 
> > > https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Does_dpkg_support_merged-.2Fusr-via-aliased-dirs.3F
> > 
> > The naming of the utility alone gives me the impression that we
> > have a dpkg maintainer who has gone to war with the rest of the
> > distribution. I am not sure whether Debian should accept that.
> > 
> I think that the option "usrunmess" says pretty much the state of
> mind regarding the person who named it this way.
> 
> Something like "usrunmerge" would be more realistic.

It is really stunning that the Debian project, including the TC
overrides the dpkg developer and maintainer Guillem, and still using
dpkg for package management. Maybe Debian should switch to some other
software, like rpm-based used by Fedora or even guix used by GNU?? Or
perhaps the Debian project should come to senses with the force of
things upon users and developers/maintainers without their approval
(consensus-free)? 

Debian, the Universal Operating System was used some years ago!

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Svante Signell]

On Tue, 2021-07-20 at 13:41 +0200, Andreas Metzler wrote:
> 
> Hello,
> Isn't this kind of crying over spilt milk? I also wish we never had
> ended up with the buster/bullseye state where both unmerged and
> merged-/usr-via-aliased-dirs are fully supported. However there is
> now a huge number of merged-/usr-via-aliased-dirs installations out
> there and we cannot make them magically disappear. Undoing
> merged-/usr-via-aliased-dirs would be very error-prone while afaiui
> we have a relatively simple plan to get a clean merged /usr in
> bookworm or bookworm +1:

According to the dpkg developer and maintainer Guillem users can still
rescue their systems from merged-/usr-via-aliased-dirs with the aid of 
dpkg-fsys-usrunmess(8), see 
https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Does_dpkg_support_merged-.2Fusr-via-aliased-dirs.3F

I for one will always use that whenever I (accidentally?) install
Debian in the future. All my old installations does not carry this bug.
Or is there some easier way to avoid merged-/usr except using --no-
merged-usr in debootstrap with new installations as written in 
https://wiki.debian.org/Teams/Dpkg/MergedUsr?

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Svante Signell]

On Sun, 2021-07-18 at 20:58 +0200, Svante Signell wrote:
> On Wed, 2021-07-14 at 23:40 +0200, Guillem Jover wrote:
> > On Wed, 2021-07-14 at 19:54:56 +, Thorsten Glaser wrote:
> > > Sean Whitton dixit:
> > > > * #978636 move to merged-usr-only?
> > > > 
> > > >  We were asked to decide whether or not Debian 'bookworm'
> > > > should
> > > >  continue to support systems which are not using the merged-usr
> > > >  filesystem layout.  We decided that support should not
> > > > continue
> > > > beyond Debian 'bullseye'.
> > > 
> > > What? WHAT? ＷＨＡＴ？
> > > 
> > > >  The decision is captured here:
> > > >  <https://bugs.debian.org/978636#178>
> > > 
> > > No reason provided either. This stinks. I’m v̲e̲r̲y̲
> > > disappointed.
> > > Debian is becoming untenable. Years ago, I had hoped it won’t.
> > 
> > I've been meaning to send a note about this for some time now, but
> > as I feel it keeps getting ignored, it always seems a bit
> > pointless.
> > 
> > But in any case, given that merged-usr-via-aliased-dirs is not
> > really
> > supported by dpkg anyway, it is broken by design [B], I have no
> > intention whatsoever to break any of my systems with such layout
> > going forward, I'm thus planning to spend any necessary volunteer
> > time implementing any fix, workaround or solution required to avoid
> > having to use it, in detriment of other Debian volunteer time. I
> > alreadystarted some time ago with dpkg-fsys-usrunmess(8), present
> > already inthe upcoming bullseye release.
> > 
> [B] 
> https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Does_dpkg_support_merged-.2Fusr-via-aliased-dirs.3F
> 
> Since the dpkg developer and maintainer Guillem considers merged /usr
> broken by design, maybe Debian should consider to use some other
> package management software for the peace of mind for people involved
> in the project? Maybe guix could be usable?

Again, everybody is just hiding, I wonder from who, the big wolf??
Who is hen? Anybody having the courage to reply to this list about this
issue, not only workarounds/diversions?

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Svante Signell]

On Wed, 2021-07-14 at 23:40 +0200, Guillem Jover wrote:
> On Wed, 2021-07-14 at 19:54:56 +, Thorsten Glaser wrote:
> > Sean Whitton dixit:
> > > * #978636 move to merged-usr-only?
> > > 
> > >  We were asked to decide whether or not Debian 'bookworm' should
> > >  continue to support systems which are not using the merged-usr
> > >  filesystem layout.  We decided that support should not continue
> > > beyond Debian 'bullseye'.
> > 
> > What? WHAT? ＷＨＡＴ？
> > 
> > >  The decision is captured here:
> > >  
> > 
> > No reason provided either. This stinks. I’m v̲e̲r̲y̲ disappointed.
> > Debian is becoming untenable. Years ago, I had hoped it won’t.
> 
> I've been meaning to send a note about this for some time now, but
> as I feel it keeps getting ignored, it always seems a bit pointless.
> 
> But in any case, given that merged-usr-via-aliased-dirs is not really
> supported by dpkg anyway, it is broken by design [B], I have no
> intention whatsoever to break any of my systems with such layout
> going forward, I'm thus planning to spend any necessary volunteer
> time implementing any fix, workaround or solution required to avoid
> having to use it, in detriment of other Debian volunteer time. I
> alreadystarted some time ago with dpkg-fsys-usrunmess(8), present
> already inthe upcoming bullseye release.
> 
[B] 
https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Does_dpkg_support_merged-.2Fusr-via-aliased-dirs.3F
>

Since the dpkg developer and maintainer Guillem considers merged /usr
broken by design, maybe Debian should consider to use some other
package management software for the peace of mind for people involved
in the project? Maybe guix could be usable?

How to undo a merged-user installation?

[Svante Signell]

Hello,

I recently installed Debian/bullseye/sid in a VM from a snapshot. After running
that image I realized the I got a merged-user installation.

As for now I have:
bin -> usr/bin
lib -> usr/lib
lib32 -> usr/lib32
lib64 -> usr/lib64
libx32 -> usr/libx32
sbin -> usr/sbin

Is there some way to achieve a non-merged-user system from the current
situation? 

The Debian Installer does not seem to have an option for a non-merged-user
installation. Is that true?

Thank you for your time!

Re: Debian With Alternate Init Systems

[Svante Signell]

Back on debian-devel.

On Mon, 2020-02-10 at 14:22 +, Sam Hartman wrote:
>From a private reply to me from Sam:
> I hear your frustration at Samuel's message.
I want Samuel to apologize on _this_ email list for insulting me.

Regarding your opinion about the GR becomes very clear by reading 
https://hartmans.livejournal.com/99395.html again.
Not much more to comment about that. This part is especially interesting:
"Proposal B is a systemd focused proposal. It's very similar to Proposal F. The
text is different, but the implications of both proposals are similar."

Not much space for other init systems than systemd within Debian. I was hoping
for too much. Let's move on with our lives.

Thanks!

Re: Debian With Alternate Init Systems

[Svante Signell]

Sam: This reply is addressed to Samuel and another to you follows, then I'll
shut up.

On Sat, 2020-02-08 at 16:40 +0100, Samuel Thibault wrote:

> > Nice, the first thing I'll do is to shut down the Debian/GNU Hurd
> > buildd mahler.

> Can't you see you are here exactly very precisely here *again* putting
> pressure to get something through?

It is not about pressure, definitely not! It's frustration on you trying to
punish me for having an opinion. What do you think would be obtained with the
above words?

BTW: How many euros do you think having a buildd running 24/7 cost me personally
every month? I'm spending a large amount of my time supporting free software,
including hosting several buildds (without a single (euro)cent in funding).

> Really, please grow up. You have already worded such a threat in the
> past. That's at best childish.

I'm asking you to apologize for what you just wrote. The above is an outright
insult to me. And you are talking about pressure! Which is the most polite way
to communicate?

Re: Debian With Alternate Init Systems

[Svante Signell]

Sam: This reply is addressed to you, and another to Samuel, then I'll shut up.

On Sat, 2020-02-08 at 08:27 -0500, Sam Hartman wrote:

> I can't speak for anyone else, but yeah I've come to my own conclusions.
> I was fairly open about them:
> https://hartmans.livejournal.com/99395.html
> 
> For myself I've concluded that systemd (at least for Linux) is far
> better than anything else out there today.

My question is merely: You believe that systemd is the best solution at the
moment for Linux. Of course your opinion is fully respected. However, there are
a number of Debian Developers, Maintainers and Users that would like to use
something "inferior" like sysvinit, openrc, runit, s6 or Shepherd. These users
are blocked from using these init systems on Debian (they can be used with a lot
of manual intervention but that requires non-trivial knowledge).

I would really like to know what the second part of the sentence "Systemd but we
support exploring alternatives" means.

> Something else might come along tomorrow even better than systemd.

Thank you for your time!

Re: Debian With Alternate Init Systems

[Svante Signell]

On Sat, 2020-02-08 at 14:51 +0100, Samuel Thibault wrote:
> Hello Sam,
> 
> Sam Hartman, le sam. 08 févr. 2020 08:27:24 -0500, a ecrit:
> > Svante> Perhaps all [...] ought to leave the project, including
> > Svante> those having package not being dependent on systemd.
> > 
> > I am frustrated reading this.
> > It sounds like you were suggesting that people should leave as a way of
> > pressuring or punishing the project.

Why not, if the project is heading in the wrong way according to their
conviction. Some people have already left Debian, as a result of the GR.

> That's the way Svante is always behaving, through diverse forms of
> pressure. 

It is not pressure, it is free speech.

> He doesn't seem to know or even be able to learn another way
> of having his goals received.

Ok, you teach me how to achieve my goals. Doing like you, keep silent and suffer
from not voicing your opinion?

> I'd say do not try to fix it, we've been trying unsuccessfully within the Hurd
> community.

Samuel, so you want me to stop working on Hurd? Nice, the first thing I'll do is
to shut down the Debian/GNU Hurd buildd mahler.

Anything else? 

Re: Debian With Alternate Init Systems

[Svante Signell]

On Thu, 2020-02-06 at 21:12 +, Sam Hartman wrote:
> > > > > > "Svante" == Svante Signell  writes:
> 
> Svante> When is
> Svante> Debian ever to offer a non-systemd alternative for
> Svante> installation?
> 
> I hear your frustration that you'd like to see Debian committed to
> supporting alternate init systems.
> I do understand you value that and have spent a lot of time on it.
> 
> Unfortunately, I think that Debian has decided that's not directly our
> focus.

Just to make sure: If I submit patches for the Debian installer for support of
more than one init system, they would be outright rejected.

> In the most recent GR, we committed to providing people the tools they
> need to explore and develop alternate init systems.

It would be nice to grasp all consequences of the GR.

> So, what would it take for us to offer  a non-systemd varient for
> installation?
> Someone would have to develop something that the project looked at and
> said, yeah, that's worth supporting as a first-class alternative to
> systemd.

See above.

> My take on the GR--and certainly my intent in writing proposal B--is
> that would take a new decision of the project.

Maybe another GR?

> I understand that you and many in the project believe that existing
> alternative init systems meet that bar today.  My take on the GR is that
> the project as a whole does not support that conclusion.

Seems like you (and all other systemd-proponents) already have made up your
mind. So non-systemd for Linux is a dead horse in Debian (the Universal
Operating System!).

> You're welcome to work on any of the existing alternate init systems.
> You are welcome to propose patches to make them work better with other
> things. People may or may not take those patches.
> It's okay even if the reason they don't take those patches is they don't
> want to support the alternate init system you are working on.

My comments above are enough as a answer to this.

> Yes, this may mean that the support for a particular alternate init
> system may be better in a downstream that focuses on that system than in
> Debian itself.

Perhaps all Debian Developers and Maintainers opposing systemd ought to leave
the project, including those having package not being dependent on systemd.
Looking at the GR vote results that would be a large number of people,
effectively reducing the projects ability to create releases. All you non-
systemd voters: Consider this option seriously!

Thanks!

Re: Heads up: persistent journal has been enabled in systemd

[Svante Signell]

On Thu, 2020-02-06 at 14:14 -0500, Michael Stone wrote:
> On Thu, Feb 06, 2020 at 08:09:13PM +0100, Svante Signell wrote:

> > > > On a Debian system _not_ running systemd:
> > > > 
> > > > du -sh /var/log
> > > > 74M /var/log

> > Of course it matters. It is about the _default_ setting, or have I
> > understood this thread wrongly?

Yes, maybe I have misunderstood. This is about systems with systemd
installed, but that is the Debian default right? No way to install
Debian without getting it as default. When is Debian ever to offer a
non-systemd alternative for installation?

Quoting the original posting from Michael Biebl:
Depending on how it goes, I might ask the ftp-masters to lower the
priority of rsyslog from important to optional, so it would no longer
be installed by default on new bullseye installations.
This would avoid, that we store log messages twice on disk.
Users that prefer text logs can of course still install rsyslog by
default (or their syslogger of choice). Alternative init systems might
consider adding a Recommends on a syslog implementation of their choice
or creating a task, which would pull in a syslogger.

> You seem to have misunderstood this thread wrongly in many ways.
> It's  not clear what you hope to accomplish by continuing. If you
> just want everyone to know that you dislike systemd, congratulations:
> you've  accomplished that. Now please move on.

So the above quote from Michael is for Debian and as a default you will
get the systemd journald binary logs. This is very much in the same
vein as the discussion with Thomas Goirand about systemd-
{users,tmpfiles}. If systemd is installed the default _has_ to be a
systemd-monolithic add-on, no discussion possible, I realize that now.
The GR had no effect on that.

Fine, but then give us a chance to create a systemd-free Debian
alternative, without blocking every attempt to do that :(

Do you want me to give examples of e.g. bugs/proposed solutions you
have blocked recently?

Re: Heads up: persistent journal has been enabled in systemd

[Svante Signell]

On Thu, 2020-02-06 at 13:41 -0500, Michael Stone wrote:
> On Thu, Feb 06, 2020 at 07:22:07PM +0100, Svante Signell wrote:
> > On a Debian sytem _not_ running systemd:
> > 
> > du -sh /var/log
> > 74M /var/log
> > 
> > And the binary logs from systemd would of course be much smaller
> > since
> > they are binary. Any numbers?
> 
> It looks like you just proved that this discussion doesn't matter
> for 
> your use case. Can we stop this now?

Of course it matters. It is about the _default_ setting, or have Iunderstood 
this thread wrongly? 

Numbers for systemd installations, please!

Re: Heads up: persistent journal has been enabled in systemd

[Svante Signell]

On Thu, 2020-02-06 at 16:09 +, Philip Hands wrote:
> > > I solved this by removing Systemd from my systems.
> > > 
> > > And now what?
> Well, since we're apparently meant to be obsessed about what it is
> like to accept every default, then let's assume for a moment that you
> are asking about rsyslog with the maintainer supplied rsyslog.conf.
> 
> Having just installed this laptop, I can run this:
> 
> # grep -r '5590629f1f60.*delivery successful' /var/log
> /var/log/mail.log:Feb  6 14:51:14 rummy dma[164f55.5590629f1f60]:
> delivery successful
> /var/log/mail.log:Feb  6 14:51:14 rummy dma[164f55.5590629f1f60]:
> delivery successful
> /var/log/mail.info:Feb  6 14:51:14 rummy dma[164f55.5590629f1f60]:
> delivery successful
> /var/log/syslog:Feb  6 14:51:14 rummy dma[164f55.5590629f1f60]:
> delivery successful
> which you'll note is actually triplicating log messages by default.

On a Debian sytem _not_ running systemd:

du -sh /var/log
74M /var/log

And the binary logs from systemd would of course be much smaller since
they are binary. Any numbers?

HTH!

Re: Heads up: persistent journal has been enabled in systemd

[Svante Signell]

On Thu, 2020-02-06 at 15:08 +0100, Marco d'Itri wrote:
> On Feb 06, Svante Signell  wrote:
> 
> > There are still a large number of
> > Debian users opting away from using systemd (and still use Debian,
> > not
> > derivatives). And what about non-linux systems?
> This is not true: adoption of systemd in buster is larger than 99%.
> Other systems will have different defaults.

I see that you are trying to heal the wounds Sam is talking about. Good
luck :D 

Re: Heads up: persistent journal has been enabled in systemd

[Svante Signell]

On Thu, 2020-02-06 at 07:58 +0100, Vincent Bernat wrote:
>  ❦  6 février 2020 09:50 +11, Dmitry Smirnov :
> 
> > > and 2) continuing to use rsyslog isn't an option if the default changes.
> > 
> > No. I just don't want default to change. IMHO rationale for this is weak
> > but everybody keeps arguing that it would not be a big deal. In time we will
> > see how that goes (what could possibly go wrong?) but why do the change in
> > first place?
> 
> To not have logs duplicated in two places.

If this is your motivation for the change it is a _very_ weak one, right? Disk
space is not a crucial problem anymore. Additionally, what would be the defaults
for non-systemd systems running GNU/Linux? There are still a large number of
Debian users opting away from using systemd (and still use Debian, not
derivatives). And what about non-linux systems?

Thank you for your time! 

Re: Integration with systemd

[Svante Signell]

On Fri, 2019-11-01 at 06:47 +, Adam D. Barratt wrote:
> On Fri, 2019-11-01 at 00:54 +0100, Svante Signell wrote:
> > On Thu, 2019-10-31 at 22:40 +0100, Marco d'Itri wrote:
> > > On Oct 31, Svante Signell  wrote:
> > > 
> > 
> > Marco, I think your information about elogind is not up-to-date:
> > https://tracker.debian.org/pkg/elogind
> > 
> No, Marco's statement was entirely correct, and proved so by your own
> quote above.
> 
> That line says that elogind 239.3+20190131-1+debian1 is currently in
> testing, and that an updated version is attempting to migrate. A
> version of elogind has been in testing for 10 months now.

I should have added that the version in testing is _not_ usable for
desktops ... Sorry for being unclear.

Re: Integration with systemd

[Svante Signell]

On Thu, 2019-10-31 at 22:40 +0100, Marco d'Itri wrote:
> On Oct 31, Svante Signell  wrote:
> 
> > When elogind enters testing there would be many more people running
> > Debian with sysvinit/elogind. elogind is needed for desktop usage
> > when not using systemd as PID 1.

> elogind is already in testing: I will be delighted to see how the
> number  of testing/unstable users running sysvinit will change in
> November.

Marco, I think your information about elogind is not up-to-date:
https://tracker.debian.org/pkg/elogind

testing migrations:
excuses:
Migration status for elogind (239.3+20190131-1+debian1 to
241.3-1+debian1): Will attempt migration (Any information below is
purely informational)
Additional info:
Updating elogind fixes old bugs: #939101
Piuparts tested OK - 
https://piuparts.debian.org/sid/source/e/elogind.html
115 days old (needed 5 days)

Yes, 115 days old...

Re: Integration with systemd

[Svante Signell]

On Thu, 2019-10-31 at 15:45 +0100, Marco d'Itri wrote:
> > On Oct 31, Simon Richter  wrote:
> > 
> > No, and that's not our job. There are a lot of people out there
> > building non-systemd systems.
> Data says: not really a lot.

When elogind enters testing there would be many more people running
Debian with sysvinit/elogind. elogind is needed for desktop usage when
not using systemd as PID 1. And as said numerous times Debian
maintainers don't have to create sysvinit scripts, they have only to
_accept_ patches to add or fix sysvinit scripts.

Additionally, do you know that sysvinit (and elogind) has an active
upstream and an active maintainer. The number of bugs on sysvinit-
related packages has been reduced considerably recently! I can try to
find the actual numbers for the last months if somebody is interested.

Any ideas of the non-linux ports: Scrap them, and leave them in the
cold?

Re: Hurd-i386 and kfreebsd-{i386,amd64} removal

[Svante Signell]

On Wed, 2019-06-26 at 12:14 -0300, elementar wrote:
> Where do I find kFreeBSD-amd64 isos, from testing or unstable?
> 
> Em sex, 12 de abr de 2019 17:49, Joerg Jaspert 
> escreveu:
> > Hi
> > 
> > back in August 2018 we discussed architecture inclusion into
> > unstable/experimental.
> > 
> > Today we had our regular FTPMaster meeting and discussed hurd and
> > both kfreebsd architecture and decided to remove them from unstable
> > and experimental 2 weeks from now.

You can find an old image you can upgrade from at:
https://people.debian.org/~jrtc27/debian-unofficial-kfreebsd-amd64-NETINST-1.iso

and then use (selected parts of) for sources.list for upgrades:
deb http://ftp.ports.debian.org/debian-ports sid main
deb http://ftp.ports.debian.org/debian-ports unreleased main
deb-src http://ftp.ports.debian.org/debian-ports unreleased main
deb http://ftp.ports.debian.org/debian-ports experimental main
deb-src http://ftp.se.debian.org/debian/ sid main contrib non-free

Re: Hurd-i386 and kfreebsd-{i386,amd64} removal

[Svante Signell]

On Sat, 2019-04-13 at 12:18 +0200, Samuel Thibault wrote:
> 
> He rightfully means he does not want patches, but patches getting
> submitted upstream, so he does not have to maintain them. A Debian
> package maintainer is not supposed to maintain patches long-term.

Then the question of which responsibilities a package maintainer has
should be investigated by the CTTE. It is not reasonable that a porter
should submit patches to multiple upstreams (really many) when the
package maintainer is (and should be) the natural interface to a single
upstream...

Re: Hurd-i386 and kfreebsd-{i386,amd64} removal

[Svante Signell]

On Sat, 2019-04-13 at 11:51 +0200, Carsten Schoenert wrote:
> Am 13.04.19 um 11:15 schrieb Svante Signell:
> 
> > Please give up on Debian. They clearly have no interest in anything
> > non-linux or non-systemd, that is fully clear. Let's make a joint
> > effort to make a Guix release of Hurd (and kFreeBSD) happen. Or, if
> > you
> > still want to continue using apt-style distributions, join Devuan.
> > Please, don't support the non-universal OS movement driven by
> > Debian people!
> 
> 
> Both architectures haven't seen any major development in the past
> years 

Yes they have, see for example Samuels answer on the latest Hurd
release: 20190109!

> So I disagree on "One person is enough" as long this one person can
> not keep track on all the required main and corner cases so other
> maintainers get to do the workload here alone.

Have you seen this? Look at the age of these bugs. Note also that
several bugs have patches attached to them. Debian maintainers just
don't want to help with non-linux bugs. So your complaint is not valid
at all.

https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-h...@lists.debian.org;tag=hurd

Re: Hurd-i386 and kfreebsd-{i386,amd64} removal

[Svante Signell]

On Sat, 2019-04-13 at 10:58 +0200, Samuel Thibault wrote:
> Joerg Jaspert, le sam. 13 avril 2019 10:24:53 +0200, a ecrit:
> > On 15371 March 1977, Samuel Thibault wrote:
> > 
> 
> Well, it's very odd that a team decision is suddenly made with a
> two-week effect without asking whether the schedule will be fine.
> 
> I guess I have to explicitly confirm here that yes, I know that the
> decision _whether_ to move is not sudden. Again, I'm talking about
> the schedule here. Asking a Debian team to do something time-
> consuming within a two-week timeframe in the middle of the full
> freeze, really...
> 
> I won't have the time to discuss with ftpmaster about it in the
> coming days anyway.

Samuel,

Please give up on Debian. They clearly have no interest in anything
non-linux or non-systemd, that is fully clear. Let's make a joint
effort to make a Guix release of Hurd (and kFreeBSD) happen. Or, if you
still want to continue using apt-style distributions, join Devuan.
Please, don't support the non-universal OS movement driven by Debian
people!

Thanks!

Re: usrmerge -- plan B?

[Svante Signell]

On Wed, 2018-11-21 at 14:43 +, Holger Levsen wrote:
> Hi Simon,
> 
> On Wed, Nov 21, 2018 at 02:05:42PM +, Simon McVittie wrote:
> [...] 
> > > Another question is, why?
> 
> [...]
> 
> thank you very much for explaining in detail why usrmerge is sensible
> and the right thing to do for Debian, the universal OS.
> 
> I'll link your mail on wiki.debian.org/UsrMerge now and encourage
> everyone to read it.

Unfortunately Simon writes too long mails. Who can even thake the time to read
all these verbalism. Things could be written more condensed. Please, can
somebody summarize his verbosity! Maybe he is a politcian?

Re: usrmerge -- plan B?

[Svante Signell]

On Wed, 2018-11-21 at 13:09 +0100, Marc Haber wrote:
> On Wed, 21 Nov 2018 10:52:22 +0100, Adam Borowski
>  wrote:
> > I am seriously claiming that RHEL is in the place Solaris was in 2010. 
> > Rapidly falling user share (like Solaris, it was ubiquitous in the past!),
> > acquired by a company known for wringing dry a small number of lucratious
> > customers -- just like Oracle.  This very scenario has repeated in the past
> > for a number of other Unices.  Some developers (including The Lennart)
> > already sound like they're mulling jumping ship .
> 
> RHEL is also the template for CentOS which has a huge user base.
> 
> Debian, is, btw, also losing quickly for not keeping pace with the
> world around it.

In my opinion it is the other way around, rpm-based systems are decreasing.

YMWV

Re: tinysshd dependency on systemd

[Svante Signell]

On Sun, 2018-10-21 at 23:04 +0200, Vincent Bernat wrote:
>  ❦ 21 octobre 2018 18:12 GMT, Ivan Shmakov :
> 
> > 
> > You know, in almost twenty years of using GNU/Linux, I think
> > it’s the first time I’m requested /not/ to report bugs and
> > contribute patches.  How times did change, indeed!
> 
> Well, reporting bugs about software you don't care or patches you
> don't test is not always useful. For example, you clearly didn't test
> your wrapper (shebang is #!/usr/sh) nor the init script
> (/lib/init/init-d-script is expecting the daemon to fork). The
> maintainer would have to do the testing, possibly the immediate fixes
> and all the future maintenance. Just for you to make a point.

Did you treat the code in the previous message as patches for some bug,
in that case which bug? I did not, Ivan just published some possible
code snippets to help.

Confused.

Re: Debian Buster release to partially drop non-systemd support

[Svante Signell]

On Fri, 2018-10-19 at 09:37 +0200, Philipp Kern wrote:
> On 2018-10-19 08:39, Narcis Garcia wrote:
> > El 18/10/18 a les 22:07, Bernd Zeimetz ha escrit:
> > > For my packages I can state that I do not have a single machine
> > > which is not using systemd - and to be honest - I won't waste my
> > > time in writing/debugging initscripts.
> > 
> > Most of people want to use a GNU operating system.
> > You particularly seem to only need a Systemd operating system.
> 
> So what you want is https://www.gnu.org/software/shepherd/?

Yes please, is it packaged for Debian already? As Debian is/was the
Universal Operating System?

Re: Debian Buster release to partially drop non-systemd support

[Svante Signell]

On Mon, 2018-10-15 at 17:06 +0200, Samuel Thibault wrote:
> 
> It's a matter of people subscribing to the
> pkg-sysvinit-de...@lists.alioth.debian.org list and discussing there,
> I
> don't see why anything heavier would be needed.

I thought alioth was no more, but maybe the mailing list remains?

Re: Re-evaluating architecture inclusion in unstable/experimental

[Svante Signell]

On Mon, 2018-09-03 at 01:07 +0200, Samuel Thibault wrote:
> 
> > So has the debian patch been submitted in #900240 upstream by you or Petter
> > Reinholdtsen yet? I don't believe so!
> 
> I don't think so either, it'd be marked forwarded. That doesn't mean you
> can't help with it.

Regardless who is submitting patches upstream, two problem remains:
1) The delay until upstream makes a new release.
2) The delay until the Debian Maintainer creates an updated package from that
release (if ever). Example: emacs26

And how many maintainers do cherry-pick patches accepted upstream, very few :( 

Re: Re-evaluating architecture inclusion in unstable/experimental

[Svante Signell]

On Mon, 2018-09-03 at 00:19 +0200, Samuel Thibault wrote:
> 
> > I'm sorry Samuel, I asked both you and James Clarke, Cc:ed, for help on this
> > issue and you both said it was not possible to NMU cmake, even if you are
> > both
> > DD's.
> 
> For my part, I was not talking about that patch, but about the
> hurd-related patches.
> 
> For others, I can simply quote what was said:
> 
> Felix Geyer wrote:
> > I suggest that instead you respond to questions on bugs you opened.
> > I'm not interested in maintaining patches for things that clearly
> > belong upstream.  Once upstream has reviewed the changes I'm happy to
> > cherry-pick them.

This is a comment on the Hurd bug, #900200, not the kfreebsd one, #905138.
And I did not open that bug, you did!

> And I agree with it (and also one of the reasons why I didn't just
> NMU-ed cmake with the hurd patch).

So has the debian patch been submitted in #900240 upstream by you or Petter
Reinholdtsen yet? I don't believe so!

Re: Re-evaluating architecture inclusion in unstable/experimental

[Svante Signell]

On Sun, 2018-09-02 at 19:46 +0200, Samuel Thibault wrote:
> Svante Signell, le dim. 02 sept. 2018 19:45:19 +0200, a ecrit:
> > On Sun, 2018-09-02 at 15:21 +0200, Samuel Thibault wrote:
> > 
> > > 
> > > > The statistics and graphs available on the debian-ports page[1] may
> > > > provide some objective statistics or reflection on the actual
> > > > suitability of your architecture's continued inclusion.
> > > >  [1]: https://buildd.debian.org/stats/
> > > 
> > > Such statistics are really difficult to get any real conclusion from.
> > > Sometimes 10% packages are missing just for one tricky nonLinux-specific
> > > issue in one package.
> > 
> > Correct: One example is cmake for both hurd-i386 and kfreebsd-any.
> > It does not even have to be tricky.
> 
> If it's not tricky, a NMU should be able to fix it easily.

I'm sorry Samuel, I asked both you and James Clarke, Cc:ed, for help on this
issue and you both said it was not possible to NMU cmake, even if you are both
DD's. See bugs 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905140
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900240
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905138

I think that the power of a package maintainer is far too big, making it
possible to reject/ignore important and other bugs, especially with patches, for
non-released architectures (and effectively block NMUs).

I think the next step would be to bring the responsibilities and commitments of
a Package Maintainer to the TC, in addition to the full control of everything
related to that package. Maybe the recent salvaging of packages could be helpful
in the future regarding this problem.

Re: Re-evaluating architecture inclusion in unstable/experimental

[Svante Signell]

On Sun, 2018-09-02 at 15:21 +0200, Samuel Thibault wrote:

> 
> > The statistics and graphs available on the debian-ports page[1] may
> > provide some objective statistics or reflection on the actual
> > suitability of your architecture's continued inclusion.
> >  [1]: https://buildd.debian.org/stats/
> 
> Such statistics are really difficult to get any real conclusion from.
> Sometimes 10% packages are missing just for one tricky nonLinux-specific
> issue in one package.

Correct: One example is cmake for both hurd-i386 and kfreebsd-any.
It does not even have to be tricky. For kfreebsd the patch(es) is attached
below!
Index: cmake-3.11.2/bootstrap
===
--- cmake-3.11.2.orig/bootstrap
+++ cmake-3.11.2/bootstrap
@@ -1352,7 +1352,7 @@ else
   libs="${libs} -ldl -lrt"
   ;;
 *BSD*)
-  libs="${libs} -lkvm"
+  libs="${libs} -lkvm -lfreebsd-glue"
   ;;
 *SunOS*)
   # Normally libuv uses '-D_XOPEN_SOURCE=500 -std=c90' on Solaris 5.10,
--- a/debian/control	2018-05-19 10:51:17.0 +0200
+++ b/debian_control	2018-07-29 17:38:11.272777000 +0200
@@ -15,6 +15,7 @@
librhash-dev,
libuv1-dev (>= 1.10),
procps [!hurd-any],
+   freebsd-glue [kfreebsd-any],
python3-sphinx,
qtbase5-dev ,
zlib1g-dev

Where to find git repos of gcc-*?

[Svante Signell]

Hello,

Where are the browsable packages for gcc-* now, when salsa is in use?
>From the web package for gcc-8:
https://tracker.debian.org/pkg/gcc-8

Click on VCS: Browse
http://svn.debian.org/viewsvn/gcccvs/branches/sid/gcc-8/
Server not found

Click on VCS: QA
https://qa.debian.org/cgi-bin/vcswatch?package=gcc-8
Error: svn: E170013: Unable to connect to a repository at URL
'svn://anonscm.debian.org/gcccvs/branches/sid/gcc-8/debian'
svn: E000111: Can't connect to host 'anonscm.debian.org': Connection
refused
Latest update there is for 8.1.0-5
Current release is: 8.1.0-8

Thanks!

Re: How to fix symbols files to work with gcc-7 and gcc-8 (Was: Bug#897794: libquazip: ftbfs with GCC-8)

[Svante Signell]

On Fri, 2018-05-04 at 23:16 +0200, Mattia Rizzolo wrote:
> Yavor,
> 
> On Fri, May 04, 2018 at 04:06:05PM +0300, Yavor Doganov wrote:
> > Andreas Tille wrote:
> > > What's the correct way to fix the symbols file to work with both
> > > versions of gcc?

> Guess what, C++ is more complex than C.

Sorry for being uniformed/not knowing: But why log symbols at all? It
seems to be very much not needed. If so tell me why it is!

Request for kFreeBSD (and Hurd) porters

[Svante Signell]

Hi all,
Cc: debian-devel

The Debian GNU/kFreeBSD port recently obtained a buildd building
packages for the sid distribution, kamp. Thank you very much for your
effort making this happening jrtc27 :) The buildd is now soon up-to-
date building packages being outdated. As you know GNU/Hurd packages
are also built for sid, having two buildds: ironforge and mahler.

Now is the time to submit patches for failing packages. In the
beginning this will be low hanging fruit, like patches not applying for
glibc, a line missing one entry in the symbols file for mpfr4, etc.

GNU/kFreeBSD and GNU/Hurd share many common interests. Mainly most of
the build-related problems are due to non-portable software, i.e. Linux
only designs. Please help us out by submitting bugs with patches to
sub...@debian.org to make kFreeBSD a first class citizen too, in
addition to GNU/Hurd.

Thanks!

Re: Bug#886493: marked as done (general: debian should support nosystemd build profile)

[Svante Signell]

Incredible: What's going on in Debian??

On Sun, Jan 07, 2018 at 12:31:10AM +0100, Svante Signell wrote:
> reopen 886238
> thanks
> 
> Did you see this? I thought this was not discussed through yet! Very nice
> attitude from Debian DD's indeed :(

As I said: don't.

Bastian

[Fwd: Bug#886238: marked as done (Please introduce official nosystemd build profile)]

[Svante Signell]

reopen 886238
thanks

Did you see this? I thought this was not discussed through yet! Very nice
attitude from Debian DD's indeed :(--- Begin Message ---
> -- Forwarded message --
> From: Bastian Blank 
> To: 886238-d...@bugs.debian.org
> Cc:
> Bcc:
> Date: Fri, 5 Jan 2018 11:50:23 +0100
> Subject: Re: Bug#886238: Please introduce official nosystemd build profile
> On Wed, Jan 03, 2018 at 03:12:51PM +0300, Hleb Valoshka wrote:
>> Please introduce official nosystemd build profile so downstream
>> distributions can send patches to package maintainers with
>> systemd-less build instead of keep them in home.
>
> As you have been already told by several people, Debian supports
> systemd-less systems.  If you find bugs running in this mode, please
> file bug reports.
>
> Apart from that, I don't see that you managed to describe what a
> "nosystemd" profile would actually do.  This would be the least we would
> need from such a bug report.
>
> However what I see is, that you and others instead of actually engaging
> in discussions just referred to personal attacks.  I and others consider
> this unacceptable behaviour on our technical mailing lists and our bug
> tracker.  Please be adviced that I will ask both the BTS owner and the
> list masters to block you from ever posting again if this behaviour
> continues.
>
> As I don't think anything new will come up, I'm closing this bug report.
> Don't reopen it, this might just expedite your fate.

Yeah no more debian for me in future.  That last comment is priceless.

Britton

--- End Message ---

Re: Bug#886238: Please introduce official nosystemd build profile

[Svante Signell]

On Fri, 2018-01-05 at 01:47 +0100, Adam Borowski wrote:
> 
> 
> Especially you two shouldn't be fighting.  As far as I know, Svante is
> somewhat involved with eudev maintenance in Devuan (done mostly by parazyd,
> though), while Marco has a great wealth of udev experience.

Well I did the work an parazyd did commit my patches and issued builds. Question
is: Who did do the real work?

> eudev is currently not needed for Debian, but it's good to have ready and
> tested packages we can import when/if udev becomes systemd only (which can
> happen at any moment as its upstream we don't control).

I really doubt Debian would accept eudev and elogind into their repositories. As
you know Debian is no longer "the Universal Operating System". Next in line of
Debian becoming a truly Linux-only distribution would be to throw out Hurd and
kFreeBSD.

Re: Bug#886238: Please introduce official nosystemd build profile

[Svante Signell]

On Fri, 2018-01-05 at 00:41 +, Simon McVittie wrote:
> On Thu, 04 Jan 2018 at 23:01:07 +0100, Svante Signell wrote:
> > What about creating a linux-nosystemd architecture, e.g.
> > dbus-1.12.2/debian/control
> > Build-Depends:
> >  libsystemd-dev [linux-any !linux-nosystemd]
> > etc.

OK, I read you. But you omitted the words about !linux architectures, why?

Re: Bug#886238: Please introduce official nosystemd build profile

[Svante Signell]

On Thu, 2018-01-04 at 23:09 +0100, Marco d'Itri wrote:
> On Jan 04, Hleb Valoshka <375...@gmail.com> wrote:
> 
> > "anti-systemd zealots" Steve, when did you join LP fanclub? When
> > Ubuntu decided to throw away your upstart and use systemd instead?
> 
> Classy...

Yes _your_ reply is classy. Never heard about a more anti-person ever. I hope
you are not a DD. That would really lower the Debian DD quality (and reputation)
 :(

Re: Bug#886238: Please introduce official nosystemd build profile

[Svante Signell]

On Thu, 2018-01-04 at 21:35 +0300, Hleb Valoshka wrote:
> On 1/3/18, Andrew Shadura  wrote:
> 
> > Do we really need systemd-less builds? I'm not convinced this is
> > something relevant to Debian.
> 
> http://angband.pl/deb/archive.html
> 
> https://wiki.debian.org/BuildProfileSpec#Derivative_specific_profiles
> 
> At least some DD have a different POV.

What about creating a linux-nosystemd architecture, e.g.
dbus-1.12.2/debian/control
Build-Depends:
 libsystemd-dev [linux-any !linux-nosystemd]
etc.

There are plenty of packages being built for GNU/Hurd and GNU/kFreeBSD not
depending on *systemd* since it is not available for !linux architectures.

WDYT?

Re: Switching to sysvinit-core fails miserably in buster/sid

[Svante Signell]

On Wed, 2017-10-25 at 18:03 +, Felipe Sateler wrote:

> Mea Culpa. This was a bug in the "defaults-disabled" implementation. I 
> have just uploaded a fixed version.

Hi, when trying to follow which patches are applied to sysvinit, the git link
given in the package page, https://packages.qa.debian.org/s/sysvinit.html is not
up to date: https://anonscm.debian.org/cgit/collab-maint/sysvinit.git
Latest entry there is from February 2017. Where is the recent git repo?

Thanks!

Re: Unsustainable debian/rules as official build entry point?

[Svante Signell]

On Wed, 2017-10-18 at 16:31 +0100, Wookey wrote:
> On 2017-10-18 12:08 +, Felipe Sateler wrote:

> I quite often use the debian/rules binary{-arch,-indep} interface when
> doing porting/bootstrapping work (i.e the package built but something
> goes wrong in the packaging process so I want to retry with a tweak or a
> bodge)
> 
> In theory I should be able to do 
> dpkg-buildpackage -nc --target=binary
> 
> but in practice I find that this often doesn't work as intended and it
> tries to do the whole build again. I have not investigated exactly why
> this is, and I guess you'll want me to give you a concrete example next.

Couldn't agree more. Porting packages is mostly the task of my work on GNU/Hurd
and being able to issue debian/rules configure, build, binary, clean, etc is
extremely useful. Especially for source packages building a lot of binaries.

> Doing the whole build again is sometimes just slow (very slow!), but
> can also be a PITA when porting, and you really do just want to
> package up what you have.

See above. Also, when testing if a package can be built twice in a row (not
necessarily for Hurd) it is important. I've encountered several such packages in
the Debian repository (still there).

Re: Unsustainable debian/rules as official build entry point?

[Svante Signell]

On Wed, 2017-10-18 at 11:54 +0100, Simon McVittie wrote:
> On Wed, 18 Oct 2017 at 11:57:55 +0200, Svante Signell wrote:
> > Building some packages for GNU/Hurd has been impossible in the
> > past, since also tests are run under fakeroot.
> 
> Is there some reason why this would be Hurd-specific? Is fakeroot's
> emulation of real root significantly more limited on Hurd, or do the
> Hurd buildds invoke builds differently, or something?

The problems was revealed when fakeroot was flaky (native
implementation). That fakeroot problem is now solved.

> dbus fails build-time tests under fakeroot on all architectures
> (or at least, I would expect it to, because it tests AF_UNIX
> credentials-passing), which makes me wonder why this failure mode
> would have manifested on Hurd and not Linux in the past. I would have
> expected packages whose tests don't like fakeroot to either succeed
> equally on both, or fail equally on both, if unrelated reasons for
> failure are ignored.

Yes, you are right. From what I remember most packages either succeed
or fail when tests are run when run under fakeroot for all
architectures. In my opinion tests should never be run under fakeroot
(i.e. in the binary target) except when requested specifically (cannot
be solved by a buildd?). The problem is the same as for tests requiring
internet connections, which are not allowed, right?

Re: Unsustainable debian/rules as official build entry point?

[Svante Signell]

On Wed, 2017-10-18 at 11:36 +0200, Guillem Jover wrote:
> Hi!
> 
> So, dpkg 1.19.0 and 1.19.0.1 had a bug where the build target was not
> being called when building packages.

Thanks, this problem has finally been revealed officially. Are you sure
this problem is not older than version 1.19.x? 

Building some packages for GNU/Hurd has been impossible in the past,
since also tests are run under fakeroot. And they should not, they are
part of the build target, not the binary target. We have tried to point
this out several times, but until now was not taken seriously.

Re: dpkg no longer installs conffiles??

[Svante Signell]

On Wed, 2016-11-30 at 13:20 +0100, Simon Richter wrote:
> Hi,
> 
> On Wed, Nov 30, 2016 at 12:19:42PM +0100, Marc Haber wrote:
> 
> [Restoring deleted conffiles]
> 
> > dpkg --force-confmiss --install , as suggested by Simon,
> > didn't work
> 
> Hm, that smells like a bug.

For me it worked on already installed packages. Haven't tried with not-yet-
installed ones though.

Re: dpkg no longer installs conffiles??

[Svante Signell]

Sorry for empty messages, but my mailer: evolution has gone nuts after the
upgrade and recovery :(


On Wed, 2016-11-30 at 11:56 +0100, Svante Signell wrote:
> 

Re: dpkg no longer installs conffiles??

[Svante Signell]

On Tue, 2016-11-29 at 19:18 +0100, Simon Richter wrote:
> Hi,
> 
> On 29.11.2016 17:58, Svante Signell wrote:
> 
> > After upgrading to sid the conffiles don't seem to be installed any longer?
> > Examples are bash, passwd, basefiles and libpam-runtime. Especially the last
> > one cost me a day debugging to find out why logins crashed. What is causing
> > this, do I have some settings disabling conffiles? Or is this all due to the
> > merge of /usr? If so, how to revert that change until it is stable!
> The usual rule applies: if dpkg thinks the conffile has been
> deliberately deleted, it will not install a new version on top. The
> question is how that happened.

The probable cause was a hardware error om my SSD disk. Subsequent disk checking
wiped out several files, among them the important conffiles.

> It would be great if you could archive /var/lib/dpkg prior to repairing
> your system, so in case the dpkg maintainers want to look at it, they at
> least have half a chance of getting to the root of the problem.

I have saved it if somebody is interested. However, the save was after I could
start and log in to the computer again.

> To force reinstallation of configuration files, invoke dpkg with the
> "--force-confmiss" option when installing. This will only restore
> missing configuration files, but not overwrite changed ones. If some
> configuration files were damaged, you can use "--force-confnew" to
> unpack all configuration files; your old files can be found with a
> ".dpkg-old" suffix then.

A problem with essential and important packages is that you can only reinstall
them. So apt-get install --reinstall or dpkg -i  only reinstalls
the package, not the conffiles. Now I know how to get the conffiles back, but
tracing which packages has them is hard: Any ideas?

Anyway, I think the default behaviour of dpkg is wrong: If you have
intentionally or by accident removed some conffiles, they should be installed by
default with a reinstall. I'll file a serious bug on dpkg for it.

Thanks!

Re: dpkg no longer installs conffiles??

[Svante Signell]

Re: dpkg no longer installs conffiles??

[Svante Signell]

dpkg no longer installs conffiles??

[Svante Signell]

Hello Rahpahel,
Cc: debian-devel

Sorry to bother you but I found your name at the following page:
https://raphaelhertzog.com/2010/09/21/debian-conffile-configuration-file-managed
-by-dpkg/

I don't know a suitable forum for this type of question. And please don't refer
me to the high-traffic ML debian-user, I won't use that one.

After upgrading to sid the conffiles don't seem to be installed any longer?
Examples are bash, passwd, basefiles and libpam-runtime. Especially trhe last
one cost me a day debugging to find out why logins crashed. What is causing
this, do I have some settings disabling conffiles? Or is this all due to the
merge of /usr? If so, how to revert that change until it is stable!

Thanks!

Re: package builds crashing under fakeroot

[Svante Signell]

On Tue, 2016-10-04 at 11:34 +0200, Samuel Thibault wrote:
> Jakub Wilk, on Tue 04 Oct 2016 10:55:36 +0200, wrote:
> > * Svante Signell <svante.sign...@gmail.com>, 2016-10-04, 08:54:
> > > From memory I think this is due to usage of the default rule:
> > > %:
> > > dh $@
> > > 
> > > with no override_dh_auto_build and override_dh_auto_test rules.
> > > By default
> > > the tests are run under fakeroot,
> > 
> > No, they're not.
> 
> Err, I've seen them do. This actually triggered fixing some fakeroot
> bugs on hurd-i386 due to various package suddenly failing to build
> after
> some debhelper upgrade (I don't remember which versione exactly),
> just
> because the testsuite was failing to run inside fakeroot.

Hi, found a package (unbound_1.5.10-2) that builds under the binary
target, skipping over the the build target. If the testsuite had been
run in debian/rules it definitely had been run under fakeroot. (Running
the testsuite manually, it fails on GNU/Linux x86_64 at:
testdata/autotrust_rollalgo.rpl failed)

BTW: This package cannot be compiled twice, the clean target removes
config.sub and config.guess files. Will file a separate bug for that.

Re: Interface of `shutdown', 'halt', ... programs

[Svante Signell]

On Thu, 2016-10-06 at 13:51 +0300, Dmitry Bogatov wrote:
> > 
> > > 
> > > #838480
> > > [...]
> > > Any suggestions?
> > Is it possible to use a pointyclicky desktoppy widgety thing to reboot
> > a system with runit ?  I guess from your mails you use the command
> > line.
> > [...]
> > I think if I were you I would try installing a system with runit and
> > GNOME, make enough of an emulation that the GNOME shutdown and reboot
> > functions work, and call that "done".
> Thank you for your advice, Ian. You guessed correctly -- 'sudo init 0' is
> good enough for me and I have little knowledge about "pointy-clicky"
> things.  While I can install GNOME on virtual machine (sigh) there are
> also other desktop enviroments (KDE, XFCE, ...).
> 
> Is there some common way to get "pointy-clicky widget"? I assume
> (correct me, if I am wrong) all desktop enviroments share some
> mechanism how to invoke root-only command (shutdown) as regular user,
> so there may be way to invoke just shutdown menu, without need other
> parts of desktop enviroments.
> 
> More suggestions are welcome.

You might take a look at elogind developed in the Guix sphere:
https://lists.gnu.org/archive/html/guix-devel/2015-08/msg00439.html
https://lists.gnu.org/archive/html/guix-devel/2016-03/msg00247.html

They are addressing the problems with gnome and systemd-logind.
https://github.com/wingo/elogind
https://wingolog.org/pub/elogind/

>From the README:
Elogind does monitor power button and the lid switch, like systemd,
but instead of doing RPC to systemd to suspend, poweroff, or restart
the machine, elogind just does this directly. For suspend, hybernate,
and hybrid-sleep, elogind uses the same code as systemd-sleep.
Instead of using a separate sleep.conf file to configure the sleep
behavior, this is included in the [Sleep] section of
/etc/elogind/login.conf.  See the example login.conf for more.  For
shutdown, reboot, and kexec, elogind shells out to "halt", "reboot",
and "kexec" binaries.

The loginctl command has the poweroff, reboot, sleep, hibernate, and
hybrid-sleep commands from systemd, as well as the --ignore-inhibitors
flag.

Re: package builds crashing under fakeroot

[Svante Signell]

On Tue, 2016-10-04 at 10:55 +0200, Jakub Wilk wrote:
> * Svante Signell <svante.sign...@gmail.com>, 2016-10-04, 08:54:
> > 
> > From memory I think this is due to usage of the default rule:
> > %:
> > dh $@
> > 
> > with no override_dh_auto_build and override_dh_auto_test rules. By default
> > the 
> > tests are run under fakeroot,
> No, they're not.

Maybe the are not run by default. However, as I wrote I've encountered packages
where the tests are run under fakeroot (and openmpi seems to be another one).
Maybe you know exactly why it happens for these packages, I don't remember right
now? It is definitely related to the dh_* tools.

Re: package builds crashing under fakeroot

[Svante Signell]

On Mon, 2016-10-03 at 16:46 +0100, Ian Jackson wrote:
> Christian Seiler writes ("Re: package builds crashing under fakeroot"):
> > 
> > On 10/03/2016 04:50 PM, Alastair McKinstry wrote:
> > > 
> > > So its a legitimate tightening of credential-checking in pmix. However
> > > it causes problems for us running tests under binary-arch.
> > If the tests themselves don't need root (fakeroot is required for
> > Debian's build infrastructure), you could just remove the fakeroot
> > libraries from LD_PRELOAD.
> > 
> > Example script (save as e.g. debian/nofakeroot, make it executable,
> > call the tests via debian/nofakeroot command in debian/rules):
> Yikes.
> 
> > 
> > > 
> > > What do DDs think should be done about this - move all tests outside
> > > binary-arch?
> Yes.
> 
> I think tests should be done in build targets, not binary targets.
> It's probably a bug of some kind that they're not.
> 
> Is that straightforward to do ?

Yes, running tests should definitely not be done in the binary targets. I've
been hit by this a few times. It is a bug. From memory I think this is due to
usage of the default rule:
%:
dh $@

with no override_dh_auto_build and override_dh_auto_test rules. By default the
tests are run under fakeroot, and they should not (except when specified).
 

Re: Libre graphics could become the standard if we push right now

[Svante Signell]

On Fri, 2016-01-15 at 04:57 -0500, shawn wilson wrote:
> 
> On Jan 14, 2016 5:11 PM, "Zlatan Todoric"  wrote:
> 
> > > So I think it is very important that we support AMD right now on what we
> > > can, and ask manufacturers to include AMD graphics in those products.
> > >
> >
> > You do realize that AMD graphics need proprietary firmware to have
> > proper 3D acceleration without which you probably couldn't run any game
> > at all - so goodbye Libre graphics.
> >
> Besides that, AMD's fglrx require X to be running in order to run while nVidia
> does not (kinda sucks if you have a bunch of 8 card nodes using the cards for
> scientific applications). Also, in this setting, there were a lot more issues
> with AMD than nVidia (soft crashes, hard crashes, cards going offline until
> reboot).
> I'm not a big gamer, so maybe there are less issues with AMD in this setting.
> And I'd be thrilled if either fglrx or nv were OSS (would weigh heavily on
> purchasing decisions). However, because AMD really pissed me off here, I had
> to say something here.

Well, I don't think the issue is about the non-free driver fglrx, but the open
source radeon drivers. fglrx is as bad as the nVidia non-free ones. BTW: nv is
OSS (Open Source Software), however with limited performance due to lacking open
documentation of the nVidia graphics hardware. The closed firmware issue is
another story...

Re: support for merged /usr in Debian

[Svante Signell]

On Fri, 2016-01-08 at 19:15 +0100, Marc Haber wrote:

> Quite some developers are getting paid to be Debian users or by
> Debian
> users. We participate in Debian because it makes using Debian easier
> for the people who pay us.On Fri, 08 Jan 2016 09:14:45 -0800,
> Nikolaus Rath 
> 
> 
> If these users stop being Debian users, they have no reason to pay
> developers to make Debian better. This causes significant loss of
> development work.
> 
> Not all Debian contributors are contributing because they're students
> that need to get rid of free time. And, in fact, contributing to
> Debian has significantly lost being fun over the last five years.
> 
> Alas, maybe I'm just too old.

No you are not. Debian following the commercial vendor track will make
them extinguished. Technically there are no real advantages of the new
(in many youngsters mind revolutionary) ideas. The idea of a Debian
Universal Operating System, supporting Free Software (not Open Source
Software), is dead.

Re: support for merged /usr in Debian

[Svante Signell]

On Fri, 2016-01-08 at 09:14 -0800, Nikolaus Rath wrote:
> On Jan 08 2016, Svante Signell <svante.sign...@gmail.com> wrote:

> > The problem is that with Debian heading down this road, the Debian
> > GNU/Linux distribution will not exist in 5 years from now.
> 
> Debian is developed by its developers, not by its users. Do you have
> any evidence (other than your opinion) that loss of users would cause
> loss of development work?

That would be the biggest mistake ever made in Debian history. What
would you do with a distribution having no users?

Re: support for merged /usr in Debian

[Svante Signell]

On Thu, 2016-01-07 at 22:46 +0100, Philip Hands wrote:
> Marc Haber  writes:
> 
> > On Tue, 5 Jan 2016 19:37:03 +0100, Marco d'Itri  wrote:
> > > On Jan 05, Ian Jackson  wrote:
> > > 
> > > > People who have been using a configuration for many years naturally
> > > > become upset when they are told that it has been `unsupported' for all
> > > > of this time and that, implicitly, changes are going to be made which
> > > > will break it.
> > > I think that your summary is correct, and I am quite sure that it would 
> > > be a bad engineering practice to make technical decisions based on 
> > > people's emotions.
> > 
> > Unfortunately, it's emotions that take vendor decisions. Your attitude
> > is driving big users towards the paid-for Enterprise Linuxes, be it
> > logical or not, be it good engineering or not.
> 
> Even if that were true, I fail to understand why we should be worried.

The problem is that with Debian heading down this road, the Debian GNU/Linux
distribution will not exist in 5 years from now. You will make yourselves
extinct due to the competition from commercial alternatives. And it will
definitely not foster new Free Software opportunities. This makes me very sad,
but that maybe is a natural evolution.

[Fwd: Re: [DNG] FW: support for merged /usr in Debian]

[Svante Signell]

Hi, 

This message was not intended to be sent to a debian-* mailing list by
the author. However, since it is (in my opinion) of large interest I
got the permission to forward it to debian-devel. Hopefully, also some
of the debian-devel subscribers will appreciate it too.

Thanks!
 Forwarded Message 
From: Steve Litt 
To: d...@lists.dyne.org
Subject: Re: [DNG] FW: support for merged /usr in Debian
Date: Fri, 1 Jan 2016 12:07:34 -0500

On Fri, 01 Jan 2016 15:45:49 +0100
Micky Del Favero  wrote:

> If I remember well Solaris has /bin linked to /usr/bin since many
> years, so linking /bin to /usr/bin is not a poetteringisation, or
> almost it's not an original idea of poettering.
> 
> Ciao, Micky

Well, OK, if we're really going to discuss this... 

This *is* poetterization, regardless of what Sun or anyone else did
before. It's supported by Freedesktop.org, and I think everyone here
can agree that anything Freedesktop supports is anti-init choice,
anti-simplicity, anti-modularity, and pro-systemd.

http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/

Those of you who have tried to lay down an alternate init system, to
replace systemd, without the aid of a package manager, will probably
agree with me that the toughest obstacle isn't udev, it isn't dbus,
it's initramfs. I looked up the word "black box" in the dictionary last
night, and they had a picture of initramfs.

Hey, I'll be the first to admit that sometimes you need an initramfs.
Maybe you have LUKS plus LVM plus software raid. Merge or not, you'll
need to compile yourself one heck of a kernel to avoid needing
initramfs. But for the very prevalent use case of Ext4, no raid, no
LVM, no LUKS, no silly merge, and a few partitions, initramfs is as
useful as udders on a snake. I mean seriously, in such a use case, you
forego initramfs: boot to the root partition, run /sbin/mount -a, and
bang, you have all resources available to you. But nooo.

Initramfs does have one big benefit for the Poetterists: It provides a
dark, safe place for them to start up their megacomplexities and call
it magic. Oh, there are tools with which you can periscope into
initramfs, but have you ever really looked at everything in an
initramfs? It's a jungle in there. Just right for the Poetterists to
incubate their plague.

Now, the Freedesktop.Org to which I referred earlier in this email has
a link to the following Rob Landley page explaining what they call the
"historical reasons" for separate directories:

http://lists.busybox.net/pipermail/busybox/2010-December/074114.html

Note that Landley's #1 reason for merging is the existance of
initramfs. Now I'm not stupid enough to call the author of Busybox a
Poetterist. He wrote this in 2010, before anyone really knew the
Napoleonistic aspirations of systemd, back in the days when a complex
and opaque "early boot" wasn't a big deal.

But now it's 5 years later, and that early boot black box is exactly
where the Poetterists fester most virulently.

In summary, if you accept the merge and /usr on a separate partition,
you need initramfs. And if you have initramfs, you've just made it
three times as hard to lay down Runit or Epoch or s6 or Suckless Init
plus daemontools-encore plus Littkit.

We all have to pick our own battles, and I'm not sure how much effort
I'd make to roll back the merge. It may indeed be a good thing that
only 3 changes are required to patch up Devuan for the merge. But make
no mistake about it: regardless of its initial motivation, today the
merge's primary beneficiaries are Red Hat and their proxies,
Freedesktop.org and Lennart Poettering.

SteveT

Steve Litt 
November 2015 featured book: Troubleshooting Techniques
 of the Successful Technologist
http://www.troubleshooters.com/techniques

Re: is the whole unstable still broken by gcc-5?

[Svante Signell]

On Sun, 2015-09-13 at 11:21 +0200, Daniel Leidert wrote:
> Am Samstag, den 12.09.2015, 21:55 +0300 schrieb Виталий Филиппов:

> 
> That's what Sid/Unstable is used for. You'll have to live with that :)
> This transition was IMHO a monster compared to the usual transitions
> and it might happen again. Se at the end we probably should discuss,
> what to improve next time.

What about transition to glibc-2.21?

Re: Need help in downgrading evolution

[Svante Signell]

On Sat, 2015-08-15 at 12:59 +0200, Adam Borowski wrote:
 On Fri, Aug 14, 2015 at 02:52:14PM +0200, Svante Signell wrote:
  With the latest debian packages, 3.16.3-1.1 evo cannot any longer
  connect to Contacts and the gmail account. [...]
  Following sid has normally been OK, having to accept packages being
  broken but possible to fix rather easily. However, downgrading evolution
  to 3.12.9~git20141130.241663-1+b1, especially evolution-data-server to
  3.12.9~git20141128.5242b0-2+deb8u1/u2 results in a dependency hell.
  
  There seems to be no easy way to go back to a (working) previous
  version, not even to the stable version if packages in sid and/or
  experimental have been installed. Does a reasonably simple downgrade
  path exist? All ideas are welcomed!
 
 You may do some version-sleuthing like Paul suggested, but as jessie is
 still quite fresh, it might be simpler for you to pin stable to 1000 for a
 moment:
 
 /etc/apt/preferences
 Package: *
 Pin: release a=stable
 Pin-Priority: 1001
 
 then you install evolution then remove the pin.
 
 A more brutal solution, compared to fine-tuning, but doesn't take as much
 work.

Thank you for your help. I've now downgraded to the stable version of
evolution. However, this downgrade and holding of packages:
evolution, evolution-common, evolution-data-server,
evolution-data-server-common, libevolution
creates a broken system due to the gcc-5 migration:
apt-get install gcc
he following packages have unmet dependencies:
 libstdc++6 : Breaks: libboost-date-time1.55.0 but 1.55.0+dfsg-3 is to
be installed
E: Unmet dependencies. Try 'apt-get -f install' with no packages (or
specify a solution).

Solving the brokenness by apt-get -f install does the following:
The following extra packages will be installed:
  libphonenumber6 libprotobuf9v5
The following packages will be REMOVED:
  libboost-date-time1.55.0 libprotobuf9
The following NEW packages will be installed:
  libprotobuf9v5
The following packages will be upgraded:
  libphonenumber6

Unfortunately evolution does not start with libprotobuf9v5 installed due
to an unresolved symbol in libebook-contacts-1.2.so.0:
evolution: symbol lookup error: /usr/lib/libebook-contacts-1.2.so.0:
undefined symbol:
_ZNK4i18n12phonenumbers15PhoneNumberUtil23GetCountryCodeForRegionERKSs

Any ideas how to proceed until bug #795287 is closed?

Need help in downgrading evolution

[Svante Signell]

Hi,

With the latest debian packages, 3.16.3-1.1 evo cannot any longer
connect to Contacts and the gmail account:

Failed to connect to 'Contacts'
Cannot find a corresponding account in the org.gnome.OnlineAccounts
service from which to obtain a password for 'a...@gmail.com'

Failed to connect account 'a...@gmail.com'
The reported error was Source 'a...@gmail.com' doesn't support prompt
for credentials.

The problematic package is evolution-data-server.

I've filed a bug report on evolution-data-server #795287 to hopefully
convince the evo maintainers to upgrade evo to 3.16.4 (where this bug is
solved) or even to 3.16.5, for more info see:
https://bugs.archlinux.org/task/45394

I have also had contact with upstream evolution developers on the
evolution-list where I was recommended to file a bug report, see e.g.
https://mail.gnome.org/archives/evolution-list/2015-August/msg00026.html

Hopefully the evolution maintainers will release a newer version of evo
soon. Until then I'm stuck with a broken gmail account, see also below.

Now to the main question:
Following sid has normally been OK, having to accept packages being
broken but possible to fix rather easily. However, downgrading evolution
to 3.12.9~git20141130.241663-1+b1, especially evolution-data-server to
3.12.9~git20141128.5242b0-2+deb8u1/u2 results in a dependency hell.

There seems to be no easy way to go back to a (working) previous
version, not even to the stable version if packages in sid and/or
experimental have been installed. Does a reasonably simple downgrade
path exist? All ideas are welcomed!

The only package manager I know of being able to have multiple versions
installed is guix.

Thanks

Re: Adding support for LZIP to dpkg, using that instead of xz, archive wide

[Svante Signell]

On Thu, 2015-07-30 at 11:47 -0700, Steve Langasek wrote:
 On Thu, Jul 30, 2015 at 05:48:25PM +0200, Antonio Diaz Diaz wrote:

  Aggressive statement? I guess your community should change its own
  documentation. I merely copied the description from there:
 
  http://www.debian.org/intro/free
  Truly free software is always free. Software that is placed in the public
  domain can be snapped up and put into non-free programs. Any improvements
  then made are lost to society. To stay free, software must be copyrighted
  and licensed.
 
 Thanks for bringing this to our attention.  This is not an official position
 of the Debian project; I've reported this as a bug:
 http://bugs.debian.org/794116

Incredible, Debian does no longer adopt to the world of free software
(not opensource) :( I wonder how RMS feels about this?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1438295412.2785.5.ca...@gmail.com

Re: Bug#786902: O: ifupdown -- high level tools to configure network interfaces

[Svante Signell]

On Wed, 2015-05-27 at 22:12 +0200, Christoph Anton Mitterer wrote:
 On Wed, 2015-05-27 at 20:50 +0100, Simon McVittie wrote: 
  I don't think ifupdown has been Debian's native tool for several years
  now. It is one among several available tools, and happens to be the only
  one with Debian as its upstream; on a wheezy-era sysvinit system that
...
 Further:
 ifupdown has Priority: important and is Recommended by netbase
 while NM has just Priority: optional

I volunteer to take on this package if somebody sponsor me (Andrew?).
Otherwise I'll do the package maintenance within Devuan.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1432761755.4491.3.ca...@gmail.com

Re: Bug#786902: O: ifupdown -- high level tools to configure network interfaces

[Svante Signell]

On Wed, 2015-05-27 at 22:12 +0200, Christoph Anton Mitterer wrote:
 On Wed, 2015-05-27 at 20:50 +0100, Simon McVittie wrote: 
  I don't think ifupdown has been Debian's native tool for several years
  now. It is one among several available tools, and happens to be the only
  one with Debian as its upstream; on a wheezy-era sysvinit system that
...
 Further:
 ifupdown has Priority: important and is Recommended by netbase
 while NM has just Priority: optional

I volunteer to take on this package if somebody sponsor me (Andrew?).
Otherwise I'll do the package maintenance within Devuan.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1432761719.4491.2.ca...@gmail.com

Re: Debian Archive architecture removals

[Svante Signell]

On Tue, 2015-05-05 at 09:17 +0200, Samuel Thibault wrote:
 [Speaking for the debian-hurd team]
 
 Lucas Nussbaum, le Mon 04 May 2015 08:28:22 +0200, a écrit :
  Maybe it's just about supporting and advertising debian-ports as
  Debian's official way to host second-class architectures. Maybe
  there's more to it. What are the current downsides of moving hurd-i386
  and sparc to debian-ports?

One of the main problems with debian-ports is that the Sources.gz file
is empty:
http://ftp.debian-ports.org/debian/dists/unreleased/main/source/
[DIR] Parent Directory
Release16-Aug-2013 08:22  119
Sources.bz205-May-2015 06:22   28
Sources.gz 05-May-2015 06:220

The only allowed sources.gz file is e.g. for sid:
http://ftp.se.debian.org/debian/dists/sid/main/source/Sources.gz

As a work-around architecture-dependent sources have to be uploaded to
the corresponding binary tree, e.g.
http://ftp.debian-ports.org/debian/pool-hurd-i386/main/libg/libgnome-keyring/
*.deb files
libgnome-keyring_3.12.0-1+hurd.1.debian.tar.xz22-Apr-2015 18:59  5.5K
libgnome-keyring_3.12.0-1+hurd.1.dsc  22-Apr-2015 18:59  2.8K
libgnome-keyring_3.12.0.orig.tar.xz   22-Apr-2015 18:58  425K

and the source files can be obtained with dget /path/to/the/*.dsc

The number of architecture-dependent packages is low, for Hurd
currently 26, to be lowered significantly when some Upstream and Debian
bugs have been resolved.

Is there no straight-forward way to solve this problem? According to
Samuel, it is due to Debian Archive Kit (dak) complexity. Can somebody
explain why it is so difficult?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1430830855.4404.142.ca...@gmail.com

Re: Debian Archive architecture removals

[Svante Signell]

On Tue, 2015-05-05 at 15:09 +0200, Samuel Thibault wrote:
 Svante Signell, le Tue 05 May 2015 15:00:55 +0200, a écrit :
  One of the main problems with debian-ports is that the Sources.gz file
  is empty:
  http://ftp.debian-ports.org/debian/dists/unreleased/main/source/
 
 No, this is really a corner issue: unreleased is a very small part of
 the picture.
 
 People working on the port can use dget instead of apt-get source,
 that's really not so cumbersome. Not appearing on buildd.debian.org etc.
 is way more important to discuss about here.

I didn't write this is the main issue, the wording is one of the main
problems, but I wouldn't call it a corner issue. Of course there are
other issues of higher importance, not appearing on buildd.debian.org is
one, and visibility of bugs (especially with patches) is another.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1430833107.4404.158.ca...@gmail.com

Re: how to remove libsystemd0 from a live-running debian desktop system

[Svante Signell]

On Mon, 2015-02-16 at 23:45 +0100, Mart van de Wege wrote:
 Luke Kenneth Casson Leighton l...@lkcl.net writes:
 
  On Mon, Feb 16, 2015 at 11:42 AM, Christian Seiler christ...@iwakd.de 
  wrote:
  Am 16.02.2015 um 02:54 schrieb Luke Kenneth Casson Leighton:
 
  http://lkcl.net/reports/removing_systemd_from_debian/
 
 
  It's funny that when Wheezy (not Jessie!) came out, nobody complained
  that libsystemd-login0 (which is now part of libsystemd0) was as a
  dependency of dbus, so it is probably already installed on most desktop
  systems running current Debian stable.

The amount chew aimed for with today's systemd was not known at that
time.

   my assessment is that it's that total lack of choice that is causing
  people to get so upset.

 And you have a choice: stick with old software, or (help) code a
 replacement yourself. That has always been the Free Software way.

Replacement software is already being developed, no problem! Don't say
that everybody complains, many people see this a challenge to make a
change from ?mainstream?.

 But dictatorially coming in and demanding that volunteers join you in
 riding your hobby horse? Please leave.

I did not see any dictatorial demands in his message, he gave the story
on how to get rid of systemd _within_ Debian, nothing else.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1424163558.12329.32.ca...@gmail.com

Debian has abandoned many users also on upgrades by the CTTE decision on December 4 2014

[Svante Signell]

Hello,

Looking at the IRC log
http://anonscm.debian.org/cgit/collab-maint/debian-ctte.git/tree/meetings/20141204/debian-ctte.2014-12-04-18.00.log.txt
lines 197 to 280 reveals the plan.

Conclusion: quoting vorlon Steve Langasek: we recommend/support
systemd being the default init system for upgrades as well as new
installs

Action point: quoting dondelelcaro Don Armstrong:
#action dondelelcaro to draft affirmative resolution on #762194 noting
#757298 et al

More details: (if using apt, see also #757298 about the grub2 entry)

- upgrading from Wheezy/with sysvinit to Jessie can boot with  
init=/lib/sysvinit/init unless/until the sysvinit package is removed by
e.g. autoclean. 

CAUTION: don't autoclean until you have installed sysvinit-core if you
don't want systemd-sysv!

- dist-upgrading Wheezy/with sysvinit to Jessie will get systemd-sysv,
and sysvinit will be history!! (unless you install sysvinit-core on next
reboot (if your system boots))

- grub will obtain a menu entry to boot with init=/lib/sysvinit/init if
something goes wrong with the switch to systemd-sysv (unless you
dist-upgrade). If you are using some other bootloader, e.g. LILO you are
on your own.

- people not careful enough are on their own: quote from Tollef Fog Heen
at some point, it's the user shooting their foot off

I wonder what the people not having physical access, e.g. ssh, to their
boxes should do, not even able the see the boot screen?

Very nice conclusions and actions ;)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1417804266.3453.97.ca...@g3620.my.own.domain

Re: DE features dependent on Systemd

[Svante Signell]

On Wed, 2014-12-03 at 16:55 +, Simon McVittie wrote:
 On 03/12/14 14:46, Svante Signell wrote:
  On Wed, 2014-12-03 at 14:25 +0100, Vincent Bernat wrote:
  The problem with those groups is that they are not fine grained
  enough.
  
  If more granularity is needed, what's hindering introduction of even
  more groups: like an image group and splitting the fb0 to more devices?
  Or even subdirectories like /dev/snd/* for audio etc.
 
 This does not actually solve the same problem as logind's uaccess, or
 ConsoleKit's udev ACL (which was an older version of the same general
 idea): it just splits it up into a larger number of orthogonal instances
 of the same problem, which is that group membership makes a poor
 encoding for temporary permissions.

Have you ever heard about openafs?

Additionally, I seriously think that much can be done by following the
ancient Unix utmp/wtmp track, e.g. as a start checking and limiting who
is allowed to write to that file. Yes, I've read the manpage. Anyway, it
was developed for a reason, right?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1417814020.3453.111.ca...@g3620.my.own.domain

Re: DE features dependent on Systemd

[Svante Signell]

On Fri, 2014-12-05 at 15:22 -0800, Russ Allbery wrote:
 Svante Signell svante.sign...@gmail.com writes:
  On Wed, 2014-12-03 at 16:55 +, Simon McVittie wrote:
  On 03/12/14 14:46, Svante Signell wrote:
 
  If more granularity is needed, what's hindering introduction of even
  more groups: like an image group and splitting the fb0 to more devices?
  Or even subdirectories like /dev/snd/* for audio etc.
 
  This does not actually solve the same problem as logind's uaccess, or
  ConsoleKit's udev ACL (which was an older version of the same general
  idea): it just splits it up into a larger number of orthogonal instances
  of the same problem, which is that group membership makes a poor
  encoding for temporary permissions.
 
  Have you ever heard about openafs?

 When NFSv4 development
 sparked the modern Linux keyring data model, we were delighted to switch
 (and then got very frustrated by the GPL-only tags on various keyring
 features, but that's another argument).

So I wish you a happy life with current (Debian chosen) technology, it
is perfect! No more problems with bugs popping up or people being unable
to boot their desktop computers/servers. Merry Christmas :) 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1417823756.3453.120.ca...@g3620.my.own.domain

Re: Summary:Re: Bug#762194: Proposal for upgrades to jessie

[Svante Signell]

On Fri, 2014-11-28 at 12:56 +0100, Svante Signell wrote:
 Hello,

 In summary:
 a) Upgrades should _not_ change init: whatever is installed should be
 kept.
 b) New installs should get systemd-sysv as default init with a debconf
 message about alternative init systems.
 
 More detailed:
 1) Fix debootstrap bugs
 2) Add a (non-aborting) debconf message referring to release-notes on
 how to install sysvinit-core when installing from scratch.
 3) Add information in release-notes on how to:
 - Upgrade from stable/testing/sid to jessie to avoid getting
 systemd-sysv installed (this should not strictly be needed if the ctte
 chooses to decide that upgrades will _not_ switch init)
 - Install sysvinit-core after installation and reboot after getting
 systemd-sysv as default.
 
 3.1) I'll file a bug against release-notes as written above.

Hopefully the ctte will make a decision on init system for upgrades to
Jessie today!

FYI: Bugs for release-notes on upgrades, #771825, and installation-guide
(and perhaps debian wiki) on new installs (pending), are in the pipe!



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1417692256.3453.60.ca...@g3620.my.own.domain

Re: DE features dependent on Systemd

[Svante Signell]

On Wed, 2014-12-03 at 14:25 +0100, Vincent Bernat wrote:
  ❦  3 décembre 2014 13:55 +0100, Adam Borowski kilob...@angband.pl :
 
  In both cases (systemd-sysv or systemd-shim), ACLs should be correctly
  set for the current user.
  
  This “adduser first-user audio” was already useless in squeeze and it
  hasn’t changed. 
 
  Only if you run logind or consolekit.  Without them (ie, on headless boxes
  or with classic-type WMs) you do need to access the devices which are mode
  660 root:audio.
 
 A classic-type WM can make use of logind to get the appropriate ACL
 setup.
 
 The problem with those groups is that they are not fine grained
 enough. For example, the video group gives access to the framebuffer
 device (the user can do a screenshot) or to a webcam (the user can spy
 another user). By encouraging the use of those groups, we create big
 security hole.

If more granularity is needed, what's hindering introduction of even
more groups: like an image group and splitting the fb0 to more devices?
Or even subdirectories like /dev/snd/* for audio etc.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1417617989.3453.34.ca...@g3620.my.own.domain

Re: DE features dependent on Systemd

[Svante Signell]

On Wed, 2014-12-03 at 15:49 +0100, Vincent Bernat wrote:
  ❦  3 décembre 2014 15:46 +0100, Svante Signell svante.sign...@gmail.com :
 
  The problem with those groups is that they are not fine grained
  enough. For example, the video group gives access to the framebuffer
  device (the user can do a screenshot) or to a webcam (the user can spy
  another user). By encouraging the use of those groups, we create big
  security hole.
 
  If more granularity is needed, what's hindering introduction of even
  more groups: like an image group and splitting the fb0 to more devices?
  Or even subdirectories like /dev/snd/* for audio etc.
 
 Sure. That is not the case actually. logind/udev are here today.

Sorry if I was not clear. I meant non-logind installations ;)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1417622534.3453.35.ca...@g3620.my.own.domain

Re: Summary:Re: Bug#762194: Proposal for upgrades to jessie (lendows 1)

[Svante Signell]

One claim is changed, see below.

On Fri, 2014-11-28 at 12:56 +0100, Svante Signell wrote:
 Hello,

 In summary:
 a) Upgrades should _not_ change init: whatever is installed should be
 kept.
 b) New installs should get systemd-sysv as default init with a debconf
 message about alternative init systems.

Since there is no interest in adding a debconf message on new installs,
I wish for a menu entry in the advanced part of the installer to be able
to install a new system with sysvinit-core or upstart!




-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1417284908.6826.3.ca...@gmail.com

Re: Technical committee acting in gross violation of the Debian constitution

[Svante Signell]

On Sat, 2014-11-29 at 19:12 +0100, Zbigniew Jędrzejewski-Szmek wrote:
 On Sat, Nov 29, 2014 at 11:51:56AM +0100, Martin Steigerwald wrote:
  Am Samstag, 29. November 2014, 01:32:22 schrieb Zbigniew Jędrzejewski-Szmek:

 New dbus client library is also slated to become
 public when its ready and kdbus is upstreamed. Various dbus apis
 are documented and stable.

Have you seen this?
http://gentooexperimental.org/~patrick/weblog/archives/2014-11.html#e2014-11-23T09_26_01.txt



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1417289407.6826.5.ca...@gmail.com

Re: Bug#762194: Summary:Re: Bug#762194: Proposal for upgrades to jessie (lendows 1)

[Svante Signell]

On Sat, 2014-11-29 at 20:14 +0100, Philipp Kern wrote:
 On Sat, Nov 29, 2014 at 07:15:08PM +0100, Svante Signell wrote:
  One claim is changed, see below.
  
  On Fri, 2014-11-28 at 12:56 +0100, Svante Signell wrote:
   Hello,
  
   In summary:
   a) Upgrades should _not_ change init: whatever is installed should be
   kept.
   b) New installs should get systemd-sysv as default init with a debconf
   message about alternative init systems.
  
  Since there is no interest in adding a debconf message on new installs,
  I wish for a menu entry in the advanced part of the installer to be able
  to install a new system with sysvinit-core or upstart!
 
 That's even more unlikely than to add a debconf message (which would be
 package-owned). Yes, debian-installer is frozen. This would add new
 udebs, new strings, new everything. We're actually trying to release.

This is another nail in the Universal OS coffin: Let's move to devuan,
please! Use Debian as upstream (as long as it lives)

Yes, next Debian release is lendows, not jessie :(


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1417290006.6826.7.ca...@gmail.com

Re: Technical committee acting in gross violation of the Debian constitution

[Svante Signell]

On Sat, 2014-11-29 at 20:27 +0100, Zbigniew Jędrzejewski-Szmek wrote:
 On Sat, Nov 29, 2014 at 06:33:44PM +, Ivan Shmakov wrote:
   Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl writes:
  
  […]
  
The second part, making systemd portable, has already been widely
discussed.  There are significant technical reasons why systemd is
Linux only.  And the potential recepients, like BSD, don't seem to
be interested anyway.
  
  Unless I be mistaken, that also /does/ mean Debian.  That is:
  Debian GNU/kFreeBSD and Debian GNU/Hurd.
 Yes, the technical reasons apply. The other reasons apply too, I think:
 /kFreeBSD and /Hurd ports are interested in staying close to their
 upstream projects and certainly don't have the manpower to take on
 systemd porting on their own.
 
  Sorry for jumping into this discussion without any thorough
  reading, but I have mentioned this point a few times already at
  (other) mailing lists and on IRC, so if I got it wrong, I’d like
  to be corrected, so that I won’t spread confusion any further.
 Please don't do that. Those threads are long enough already, without
 rehashing things which can be googled in 30s.

The best for kFreeBSD and Hurd would be to abandoning the Debian ship.
It is sinking :( (just let the devuan people get things in order first)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1417290209.6826.9.ca...@gmail.com

Re: Bug#762194: Summary:Re: Bug#762194: Proposal for upgrades to jessie (lendows 1)

[Svante Signell]

On Sat, 2014-11-29 at 20:19 +, Adam D. Barratt wrote:
 On Sat, 2014-11-29 at 20:40 +0100, Svante Signell wrote:
  This is another nail in the Universal OS coffin: Let's move to devuan,
  please!
 
 You are of course free to do that. This discussion is about what Debian
 should do, however. If you wish to discuss Devuan, please do so in a
 more appropriate forum.

Yes, I'll do that. But it does not seem like you are realizing what is
happening unfortunately. Debian will not be as it was historically due
to this issue. Maybe the new DDs are to young to learn from history?



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1417292862.6826.11.ca...@gmail.com

Re: Bug#762194: Summary:Re: Bug#762194: Proposal for upgrades to jessie (lendows 1)

[Svante Signell]

On Sat, 2014-11-29 at 22:01 +0100, Philipp Kern wrote:
 On 2014-11-29 21:30, Steve Langasek wrote:
  Debian releases when it's ready.  If large numbers of our users are 
  going to
  have a bad experience with jessie as a result of being switched to 
  systemd,
  then we should take appropriate steps to address that, even if that 
  means
  unfreezing the installer.
 
 Sure. But where is the evidence for that? Is there a bug that has been 
 agreed upon to be RC?
 
  I am not saying that making init systems a choice in the installer is 
  the
  right solution here; I don't think that it is.  But I also don't think 
  that
  the release freeze can reasonably be an argument against it.
 
 Not even the release freeze, rather the d-i freeze. Unless this is RC 
 for d-i, that is

Ok, I've tried to no avail. Debian is no democracy (maybe never was).
ctte do as you feel there are no alternative solutions, just state the
fact with your decision EOT.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1417296351.6826.13.ca...@gmail.com

Re: Technical committee acting in gross violation of the Debian constitution

[Svante Signell]

On Fri, 2014-11-28 at 08:45 +0100, Josselin Mouette wrote:
 Le jeudi 27 novembre 2014 à 21:29 +0100, Marc Haber a écrit : 
  On Thu, 27 Nov 2014 01:19:14 +0100, Josselin Mouette j...@debian.org

 If you want to help our users, you
 can contribute to debianfork, or you can improve your packages in
 Debian. 

The official name of the Debian fork is devuan: https://devuan.org
It will be interesting to see how many Debian Maintainers and Developers
will jump the ship and join them (in addition to the users). Future will
tell...  


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1417164192.11764.382.ca...@g3620.my.own.domain

Summary:Re: Bug#762194: Proposal for upgrades to jessie

[Svante Signell]

Hello,

In the (last) hope that the CTTE will bring this issue on the agenda
next meeting on December 4. Additional information below and a short
summary.

On Wed, 2014-11-26 at 09:56 +0100, Thorsten Glaser wrote:
 On Tue, 25 Nov 2014, Svante Signell wrote:
 
  (another partial? solution is to change order of the (pre-)depends of
  the init package, as proposed in
 
 No, that breaks due to the bug in debootstrap’s dependency “resolver”
 (see #557322, #668001, #768062) and the unwillingness of KiBi to fix
 that. That is, it breaks fresh installs.

Note, this (long-time) refusal to make changes to that package has to be
weighted in when the CTTE is discussing this issue: There are very small
patches available before the freeze Wed, 5 Nov 2014 (Sun, 22 Nov 2009
and  Fri, 17 Oct 2014) that has not been addressed by the maintainer:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=557322#24
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668001#20
and reported working
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668001#50

And according to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762194
with preliminary results in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762194#142
the order of pre-depends for int init package should change from
Pre-Depends: systemd-sysv | sysvinit-core | upstart
to
Pre-Depends: sysvinit-core | systemd-sysv | upstart

(I hope I made the correct links and conclusions)

  1) Heavily advertise (release-notes?) that doing an upgrade from
  wheezy/etc to jessie will give you systemd as init system and inform
  about the apt pinning solution.
 
 That should be a given, a minimum, independent of the others.

I'll file a bug against release notes about the release-notes!

In summary:
a) Upgrades should _not_ change init: whatever is installed should be
kept.
b) New installs should get systemd-sysv as default init with a debconf
message about alternative init systems.

More detailed:
1) Fix debootstrap bugs
2) Add a (non-aborting) debconf message referring to release-notes on
how to install sysvinit-core when installing from scratch.
3) Add information in release-notes on how to:
- Upgrade from stable/testing/sid to jessie to avoid getting
systemd-sysv installed (this should not strictly be needed if the ctte
chooses to decide that upgrades will _not_ switch init)
- Install sysvinit-core after installation and reboot after getting
systemd-sysv as default.

3.1) I'll file a bug against release-notes as written above.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1417175791.11764.416.ca...@g3620.my.own.domain

Re: Technical committee acting in gross violation of the Debian constitution

[Svante Signell]

On Fri, 2014-11-28 at 13:48 +0100, Thorsten Glaser wrote:
 On Fri, 28 Nov 2014, Svante Signell wrote:
 
  It will be interesting to see how many Debian Maintainers and Developers
  will jump the ship and join them (in addition to the users). Future will
 
 I’ll tell you in the present.
 
 Github? Ugh! http://mako.cc/copyrighteous/free-software-needs-free-tools
 The rest is just as bad (mailinglists hosted somewhere in the wild too,
 etc). And the website is illegible, and I curiously wonder who is behind
 all that. But mostly rhetorically, as I’m not really interested…

(about devuan)
This has just started, give them some time, please.

From a comment on the thread about upgrades (that don't belong to the
ctte bugs):
https://lists.debian.org/debian-devel/2014/11/msg01265.html

 Do note that new installs of kFreeBSD and Hurd should not get
 systemd, but what exactly is probably up to the porters for lack
 of a CTTE decision in that.

Maybe it would be a better place for the non-linux debian-ports to be
hosted by devuan (they are currently not release candidates for Jessie):

If Debian ditch all non-linux ports, that would make life easier for all
DMs and DDS:

- no non-linux ports needing other any init than systemd, remove
alternatives
- no requirement for portable code upstream, previously forwarded by DMs
and/or bug reporters.
- no annoying bug reports for patches addressing portability, see above
(mostly ignored anyway).
- ditch all other desktop systems, just go with Gnome
- etc
- based on the above, plenty of packages could be removed, etc

BTW: why not rename Debian 8 Jessie to Debian Lendows(tm) 1, and perhaps
the whole distribution (Lindows was acquired by M$, that name is taken
already) Note, I'm just kidding, or? Is the Universal OS ship sinking?



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1417188308.11764.444.ca...@g3620.my.own.domain

Re: Bug#762194: Proposal for upgrades to jessie

[Svante Signell]

On Wed, 2014-11-26 at 09:56 +0100, Thorsten Glaser wrote:
 On Tue, 25 Nov 2014, Svante Signell wrote:

  2) In case you missed doing the above, you get a debconf prompt when
 
 No, no, no, no, no, no, no!
 
 Again: aborting the dist-upgrade in the debconf of one
 package may leave the system an ugly mess, especially
 if you don’t preconfigure packages.

I did _not_ propose aborting the dist-upgrade here. Sorry for not being
clear enough. The proposed debconf prompt is just for information: hit
return to continue




-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1416993577.11764.317.ca...@g3620.my.own.domain

Re: Bug#762194: Proposal for upgrades to jessie

[Svante Signell]

On Wed, 2014-11-26 at 09:56 +0100, Thorsten Glaser wrote:
 On Tue, 25 Nov 2014, Svante Signell wrote:

  Does that work,
 anyway (i.e. does installing systemd and immediately
 reverting to sysvinit leave the system net unchanged,
 modulo the dependencies it pulls in (see planet post))?

I've installed testing (basic install) on a new box and immediately
after first reboot installed sysvinit-core. That worked for me, but as
written before, it can create problems for people having different
preferences set.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1416994053.11764.322.ca...@g3620.my.own.domain

Re: Bug#762194: Proposal for upgrades to jessie

[Svante Signell]

On Wed, 2014-11-26 at 14:46 +, Neil McGovern wrote:
 Hi,
 
 On Tue, Nov 25, 2014 at 09:29:28PM +0100, Svante Signell wrote:
  1) Heavily advertise (release-notes?) that doing an upgrade from
  wheezy/etc to jessie will give you systemd as init system and inform
  about the apt pinning solution.
  
  3) Heavily advertise (again in release notes?) that you need to install
  sysvinit-core and add the pinning file _before_ dist-upgrading.
  
 
 See
 https://anonscm.debian.org/viewvc/ddp/manuals/trunk/release-notes/en/issues.dbk?view=markup
 lines 170 to 223.
 
 Are you after something different? How about raising a bug against the
 release-notes package before asking tech-ctte to do something?

Is it possible to get access to edit those pages? By filing a bug
against release-notes?

  Note that the only technical in the above is the creation of a debconf
  prompt in pre/post-inst of the init package. All the rest is just a
  matter of writing.

To clarify: debconf prompt - debconf message, meaning that the
install is not to be aborted, only an informal message is written and
hit CR to continue. Is it possible to propose a text here?

 Alternatively: The only hard bit of the above is the creation of the
 release notes. All the rest is just a matter of coding.

YMMV



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1417015399.11764.347.ca...@g3620.my.own.domain

Re: Bug#668001: please help test proposed patch for bug#668001

[Svante Signell]

On Tue, 2014-11-25 at 19:50 +0100, Cyril Brulebois wrote:
 Jonas Smedegaard d...@jones.dk (2014-11-25):
  Quoting Cyril Brulebois (2014-11-25 18:31:33)
   I'm not sure why people seem to believe that broadcasting a call for
   tests through their blog, Planet Debian, various Debian mailing
   lists, etc. is going to change anything here.

 No, I didn't write that either. Please stop making up stuff. It won't be
 considered for jessie, that's all.

And the reason is the freeze?

  If so, then why not release it now for experimental?  If because you
  are too busy releasing Debian, would you perhaps be ok with me doing
  so as an NMU?
 
 To be crystal clear: no, this patch needs to be considered, reviewed,
 whatever, and not randomly uploaded to experimental. Feel free to ping
 this bug report once jessie is released.


From https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668001#60

Is this command something in debootstrap or the installer?
preseed/late_command=in-target apt-get install -y sysvinit-core



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1416945074.11764.290.ca...@g3620.my.own.domain

Proposal for upgrades to jessie

[Svante Signell]

Hello,

Below is a proposal for a (partial) solution for the upgrade problem of
keeping the installed init system:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765803

This has been discussed privately among selected users/DM/DDs and since
the deadline for the ctte is December 4, it has to be known to them (and
-devel for comments).

(another partial? solution is to change order of the (pre-)depends of
the init package, as proposed in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762194
with preliminary results in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762194#142)

1) Heavily advertise (release-notes?) that doing an upgrade from
wheezy/etc to jessie will give you systemd as init system and inform
about the apt pinning solution.

2) In case you missed doing the above, you get a debconf prompt when
installing the init package that if you want to keep sysv/openrc/etc
continue with the installation, get systemd-sysv installed and after
that install sysvinit-core and do the pinning. (This is suboptimal, many
peoples systems could be broken at first reboot, we will find out in due
time).

Another issue is upgrading from testing/sid?/etc (different status) to
jessie:
3) Heavily advertise (again in release notes?) that you need to install
sysvinit-core and add the pinning file _before_ dist-upgrading.

Note that the only technical in the above is the creation of a debconf
prompt in pre/post-inst of the init package. All the rest is just a
matter of writing.

Sincerely!


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1416947368.11764.312.ca...@g3620.my.own.domain

Re: Age of built packages to be part of the jessie release?

[Svante Signell]

On Sat, 2014-11-22 at 15:36 +, Neil Williams wrote:
 On Sat, 22 Nov 2014 16:19:10 +0100
 Svante Signell svante.sign...@gmail.com wrote:
 
  Hello,
  
  I wonder how old a package build can be to be part of the release.
  Some packages are built up to a year ago, and rebuilding them now
  FTBFS. What to do, file a bug or accept status quo?
  
  Thanks!
 
 In summary: Everything released in Jessie must build on Jessie. That's
 why we have intermittent archive-wide rebuilds (which are typically
 only on amd64). We don't routinely rebuild the entire archive prior to
 the release but we need to be able to do so.
 
 Criteria are:
 
 * A package which FTBFS in a clean Jessie build environment and
 * on a release architecture and
 * where there is no existing bug and 
 * the package has previously built on that architecture
 
 - file a FTBFS RC bug with full build log.

Thanks for all replies not only this one. A question remains (for me):
How to build a package in a clean jessie environment? Seems like the
buildds are using sbuild. Is that the preferred way to try out a single
package, built on most buildds since 240 days. I'm currently running sid
boxes. The package at hand, lam, FTBFS at least on my amd64 box.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1416829363.11764.286.ca...@g3620.my.own.domain

Age of built packages to be part of the jessie release?

[Svante Signell]

Hello,

I wonder how old a package build can be to be part of the release. Some
packages are built up to a year ago, and rebuilding them now FTBFS. What
to do, file a bug or accept status quo?

Thanks!


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1416669550.11764.274.ca...@g3620.my.own.domain

Re: Being part of a community and behaving

[Svante Signell]

On Sat, 2014-11-15 at 13:37 +0100, Raphaël Halimi wrote:
 Le 13/11/2014 18:58, Ralf Jung a écrit :
  How does having yet another NTP client shut off existing NTP clients?
  How does having yet another way to configure your network shut off
  existing alternatives?
 
 How does having yet another web browser integrated in the OS shut off
 existing web browsers ? ;)
 
  Even syslog is still working!
 
 No, it's not:
 
 raph@arche:~$ journalctl | grep Forwarding
 nov. 10 20:14:34 arche systemd-journal[207]: Forwarding to syslog missed
 42 messages.
 nov. 14 01:02:44 arche systemd-journal[207]: Forwarding to syslog missed
 1 messages.
 nov. 14 01:25:31 arche systemd-journal[207]: Forwarding to syslog missed
 2 messages.
 nov. 14 01:26:36 arche systemd-journal[207]: Forwarding to syslog missed
 2 messages.
 
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762700
 
 http://lists.freedesktop.org/archives/systemd-devel/2014-August/021897.html
 
 I know it may be biased since I'm the reporter of the bug, but I'm tired
 of reading that systemd replaces all those components smoothly.
 
 It does not.
 
 Now on the technical side, when I reported this bug I looked at the
 source code. In a nutshell, the comment said If syslog is too slow,
 drop the message (IIRC it was even more condescending, like we don't
 have to wait for this or something). Really ? The very piece of code
 which is supposed to talk to syslog... doesn't wait for syslog ?
 
 So if one can't afford to have crippled logs, what's the solution ?
 Getting rid of syslog completely by turning on persistence in journald,
 and go with binary logs ? Thanks, but no thanks.

One effect of having logs stored in binary format:
http://lists.freedesktop.org/archives/systemd-devel/2014-November/025203.html




-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1416062783.2764.3.ca...@gmail.com

Some questions about the GR voting

[Svante Signell]

Hi,

I have two questions about the GR voting going on (I'm not subscribed to
debian-vote, unfortunately, and somebody even wanted me to be
banned :( )

1) If a DD (the only persons able to vote?) change their mind, can they
do so before the deadline, or is their vote set in stone once issued?

2) If DD gives the same number for two alternatives, like 4,4 instead of
4,5 is that still a valid vote?

Thanks!


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1415997517.2764.1.ca...@gmail.com

Re: Being part of a community and behaving

[Svante Signell]

On Thu, 2014-11-13 at 08:25 -0800, Russ Allbery wrote:
 Florian Lohoff f...@zz.de writes:
 
  I meanwhile see the systemd issue as a social problem within
  debian. There are design issues which are REALLY controversial. In the
  past Debian did good by delaying adoption of controversial technical
  issues e.g. devfs and waited in a conservative way until dust settled
  and there was roughly a consensus.
 
 We waited two years, during which positions hardened, people got angrier
 and angrier, and there were increasing demands to force the issue.
 Serious question: how much longer were we realistically going to wait with
 zero sign of forward progress?

The Canonical license arguments was maybe the tipping weight that pushed
Debian towards systemd, right.

 That didn't happen, obviously.  But don't lose sight of the fact that we
 were already in a really bad place.
 
  This has changed - Debian has changed. 
 
  It seems we need to rush in all interesting stuff without looking
  forward past some months - Today systemd might be THE solution to some
  peoples problems. Is it tomorrow? I doubt it.

 If you think waiting two years to make a decision is rushing matters,
 I'm not sure what your idea of moving slowly is.

Isn't it so that systemd has changed a lot since the decision was made
in February this year, and the rate of changes will not stop. In the
meanwhile no stable API is defined and more and more functionality is
integrated in the systemd software, effectively shutting off
alternatives. When CoreOS is fully developed, there will a diminishing
market for other distributions.

Let's hope that Debian at least don't completely rules out (abandons)
alternate init systems. When things are seen in a perspective, a few
years from now, this might have saved Debian from disappearing (and even
obtain new desktop and server users coming from the
not-happy-with-systemd people).


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1415897759.11764.44.ca...@g3620.my.own.domain

ITP? Sponsors of eudev, consolekit2, uselessd?

[Svante Signell]

Hi,

I'm currently looking into packaging eudev, consolekit2, uselessd for
Debian. If doing so, is anybody interested in sponsoring uploads of
these packages? It would be great to know, before digging into the
details. If you wish, please reply to me privately.

Thanks!


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1415902621.11764.51.ca...@g3620.my.own.domain

Re: Being part of a community and behaving

[Svante Signell]

On Thu, 2014-11-13 at 13:39 -0800, Russ Allbery wrote:
 Patrick Ouellette poue...@debian.org writes:
 
  We do tell users of Debian what to do - that's part of the problem right
  now.  We told the users they will switch init systems, and a large
  portion (or at least a vocal portion) don't want to.
 
 Well, no, we didn't.  We said that there would be a different default,
 which is not the same thing.  The project hasn't made a decision about
 switching, and also, at present, sysvinit is still fully supported (modulo
 the normal pre-release bugs).

See #765803. That bug report is about making the user aware of/alerted
to an init switch when upgrading, nothing else. And that issue has not
yet been resolved by the ctte, due to the GR. Hopefully when the GR
result is published, the ctte can decide on this. (assuming the outcome
is a non-gr issue? what happens if not?) 

 Ah, see, I also believe this, which is exactly why I'm so upset about the
 current GR.  The proposed GR (the first option) is exactly about
 overriding the normal practice that the package without a maintainer loses
 by default, and about *forcing* the people who aren't using sysvinit to
 work on maintaining it.  This is one of the fundamental divisions in the
 project right now.

Maybe I'm misunderstanding, but my interpretation is _not_ the above?
Ian?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1415916206.11764.71.ca...@g3620.my.own.domain

Re: Being part of a community and behaving

[Svante Signell]

On Fri, 2014-11-14 at 09:16 +1100, Brian May wrote:
 On 14 November 2014 04:20, Carlos Alberto Lopez Perez
 clo...@igalia.com wrote:
 
 Which would suggest that udev might stop supporting the
 userspace-to-userspace netlink-based transport in the future. However,
 unless I am mistaken, I don't think this means it will no longer work
 on non-systemd systems.

From an irc:(16:06:44) xxx: udevd starts very slowly without systemd...
any chance i can speed it up?

Things evolve with time


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1415917825.11764.74.ca...@g3620.my.own.domain

Re: Being part of a community and behaving

[Svante Signell]

On Fri, 2014-11-14 at 09:46 +1100, Brian May wrote:
 On 14 November 2014 09:30, Svante Signell svante.sign...@gmail.com
 wrote:
 From an irc:(16:06:44) xxx: udevd starts very slowly without
 systemd...
 any chance i can speed it up?
 
 
  Assuming that report is accurate, to me it sounds like a bug that
 should get fixed, as opposed to a clear indication that udevd is going
 to stop supporting non-systemd systems.

The problem is that udevd is part of systemd, i.e. non-systemd systems
are not actively supported (and will not be in due time, I wonder
when?).



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1415919265.11764.78.ca...@g3620.my.own.domain