Re: /usr-move: Do we support upgrades without apt?

[Michael Biebl]

Am 21.12.23 um 11:50 schrieb Christoph Berg:

Re: Helmut Grohne

Is it ok to call upgrade scenarios failures that cannot be reproduced
using apt unsupported until we no longer deal with aliasing?

If the answer is yes here, we'll close #1058937 (Ben's libnfsidmap1 bug)
with no action calling the scenario unsupported.


I think we should only deal with problems that can reasonably happen
in practice. If an extra hammer is required to hit the problem, we
should not spend extra effort on it.


A (dist-)upgrade not using apt is very much a corner case/niche use case.

I'd be interested if #1058937 can be reproduced using aptitude, though.
While the release notes explicitly recommend using apt/apt-get, I do 
think that dist-upgrades using aptitude should not run into those file 
loss issues.


If aptitude is safe, I'd consider #1058937 a bug, that is not release 
critical and I'd assign low(er) priority to it.
Other issues, like getting all packages updated to move their files to 
/usr, have higher priority.


Michael



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed

[Michael Biebl]

This particular issue in dpkg is very much known and nothing new (a 
short recap: dpkg can lose files if files are moved between packages 
*and*  symlinked directores, such as / and /usr, at the same time).



To mitigate it, bluca added a piuparts check which rejects packages that 
move files from / to /usr (for bookworm/sid).
This is overly conservative as strictly speaking, we'd only have to be 
careful of packages that move files from / to /usr and between packages 
within one release cycle.
I.e. it would be perfectly fine to move files for / to /usr if during a 
release cycle those files aren't moved between packages.
I suspect this will be a rare case, that said definitely something to be 
aware of if we don't get a fixed dpkg.


Fwiw, once all files are moved to /usr, the dpkg bug is no longer really 
relevant.


So, I think there isn't any new information here in #1020792 which would 
warrant a halt.


Regards,
Michael



OpenPGP_signature
Description: OpenPGP digital signature

Bug#947847: Fwd: Bug#946456: systemd: Provide systemd-sysusers as an independent package

[Michael Biebl]

Forwarding this to the CTTE, just in case they have some input on this
proposed plan.


 Weitergeleitete Nachricht 
Betreff: Re: Bug#946456: systemd: Provide systemd-sysusers as an
independent package
Datum: Wed, 7 Oct 2020 18:21:39 +0200
Von: Michael Biebl 
An: 946...@bugs.debian.org, Felipe Sateler , Ansgar
, Niels Thykier 

A small update here:
v246 provides a build switch -Dstandalone-binaries=true:
`
option('standalone-binaries', type : 'boolean', value : 'false',
   description : 'also build standalone versions of supported binaries')
`

Atm, those supported binaries are systemd-tmpfiles and systemd-sysusers.
Those binaries do not link against libsystemd-shared and have minimal
dependencies.

Fedora decided to ship those binaries in separate binary packages named
systemd-standalone-sysusers and systemd-standalone-tmpfiles, which
conflict with the main systemd package, i.e. the main systemd package
will continue to ship systemd-tmpfiles and systemd-sysusers linking
against libsystemd-shared.

I like this approach and think we should do the same in Debian.
Users, which have the full systemd package installed don't have any
negative side effects, which could result from splitting out
systemd-tmpfiles/systemd-sysusers and libsystemd-shared.

Restricted/non-systemd environments, like containers, can use
systemd-standalone-sysusers and systemd-standalone-tmpfiles with minimal
dependencies.

We could debate whether systemd-standalone-tmpfiles and
systemd-standalone-sysusers should be provided by a single binary
package, but since Fedora has already done this split this way, I would
simply follow here and use the same binary package names.
The relevant Fedora PR is
https://src.fedoraproject.org/rpms/systemd/pull-request/27 fwiw.

Thankfully, -Dstandalone-binaries=true doesn't require a separate, third
build variant (as with the udeb flavour), so build times shouldn't go up.

If there are no objections to this approach I would proceed and
implement it like this:
- Build systemd with -Dstandalone-binaries=true
- Install the standalone binaries in binary packages named
systemd-standalone-sysusers and systemd-standalone-tmpfiles
- Those binaries packages would only ship /bin/systemd-sysusers resp.
/bin/systemd-tmpfiles and have a Conflicts/Replaces: systemd


In case there are no objections to this plan, I would create a MR on salsa.

Thoughts?

Michael







signature.asc
Description: OpenPGP digital signature

Bug#947847: please install systemd-sysusers using update-alternatives

[Michael Biebl]

Am 27.01.20 um 14:19 schrieb Michael Biebl:
> Am 27.01.20 um 11:18 schrieb Thomas Goirand:
> 
>> It is my view that what you're proposing would be a lot more work for on
>> valid reason. 
> 
> opensysusers as implementation will always lag behind systemd-sysusers
> and/or be incomplete, it might even be incompatible.
> This has the potential to negatively effect a systemd installation
> leading to a less robust system. Those issues will likely be hard to
> diagnose where we as maintainers have to spend time which would be
> better spent elsewhere.
> And all that for what? I don't see a compelling use case why swapping
> out the native reference implementation and running a combination which
> is untested (and unsupported by systemd upstream) would be a good idea.

I'm not subscribed to this bug report, so if the CTTE want's further
feedback on this issue from my side, please CC me.

Michael



signature.asc
Description: OpenPGP digital signature

Bug#947847: please install systemd-sysusers using update-alternatives

[Michael Biebl]

Am 27.01.20 um 11:18 schrieb Thomas Goirand:

> It is my view that what you're proposing would be a lot more work for on
> valid reason. 

opensysusers as implementation will always lag behind systemd-sysusers
and/or be incomplete, it might even be incompatible.
This has the potential to negatively effect a systemd installation
leading to a less robust system. Those issues will likely be hard to
diagnose where we as maintainers have to spend time which would be
better spent elsewhere.
And all that for what? I don't see a compelling use case why swapping
out the native reference implementation and running a combination which
is untested (and unsupported by systemd upstream) would be a good idea.

Regards,
Michael



signature.asc
Description: OpenPGP digital signature

Re: Bug#904558: What should happen when maintscripts fail to restart a service

[Michael Biebl]

Am 07.10.18 um 20:55 schrieb Michael Biebl:
> Am 07.10.18 um 20:46 schrieb Michael Biebl:
>> Let me add here, that a lot of sysv init scripts I looked at do not
>> actually return proper error codes in case the service fails to start.
>> Picking a random example, like anacron, I see for the start action:
>>
>> start-stop-daemon --start --exec /usr/sbin/anacron -- -s
>> log_end_msg 0
>>
> 
> And even if the init scripts use "log_end_msg $?"
> most of them do not exit at this point but have an explicit
> "exit 0" at the end of the script [1].
> So while you get a log message on stdout which indicates failure, you
> don't get a return code which would cause dpkg to abort.
> 
> IIRC, this basically was the reason why we used "|| true" in
> dh_systemd_start to mimic the effective dh_installinit behaviour.

Or putting this a different way:
If the decision is that failure to start a service should result in a
dpkg failure, when this in turn means that most of our sysv init scripts
are insta-buggy and need to be fixed to return proper error codes.
Personally I would welcome this to be the case, but keep in mind that we
have around 1200 init scripts in the archive and afaics only very few
actually do return proper exit codes.

Regards,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Bug#904558: What should happen when maintscripts fail to restart a service

[Michael Biebl]

Am 07.10.18 um 20:46 schrieb Michael Biebl:
> Let me add here, that a lot of sysv init scripts I looked at do not
> actually return proper error codes in case the service fails to start.
> Picking a random example, like anacron, I see for the start action:
> 
> start-stop-daemon --start --exec /usr/sbin/anacron -- -s
> log_end_msg 0
> 

And even if the init scripts use "log_end_msg $?"
most of them do not exit at this point but have an explicit
"exit 0" at the end of the script [1].
So while you get a log message on stdout which indicates failure, you
don't get a return code which would cause dpkg to abort.

IIRC, this basically was the reason why we used "|| true" in
dh_systemd_start to mimic the effective dh_installinit behaviour.

Michael

[1] IIRC not even the skeleton file which is shipped for sysvinit does
this correctly and as a result was copied and pasted into numerous packages.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Bug#904558: What should happen when maintscripts fail to restart a service

[Michael Biebl]

> * dh_installinit: defaults to "failure to (re)start is failure to
>   configure", but can be overridden with --error-handler; some packages
>   set the error handler to "true" (e.g. apache2, isc-dhcp) or to a custom
>   shell function (e.g. krb5, samba).
>   This is used for LSB init scripts, and for systemd units that have a
>   corresponding LSB init script.
> 
> * dh_systemd_start: unconditionally uses "|| true".
>   This is only used for systemd units that *do not* have a corresponding
>   LSB init script. A dh_installinit-style --error-handler would probably
>   be a reasonable feature request.


Let me add here, that a lot of sysv init scripts I looked at do not
actually return proper error codes in case the service fails to start.
Picking a random example, like anacron, I see for the start action:

start-stop-daemon --start --exec /usr/sbin/anacron -- -s
log_end_msg 0

This seems to be a rather common issue among SysV init scripts to signal
a (wrong) return code of 0 even if the service failed.

systemd is much more consistent in that regard as it will report a
failure code if the service failed to start/stop/restart.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#865929: Advice on dealing with GRUB upgrade failure caused by init-select

[Michael Biebl]

On Sun, 25 Jun 2017 23:37:13 +0100 Colin Watson  wrote
> I could have NMUed init-select in both unstable and stretch with a
> corrected conffile (and probably also with a corrected sysvinit

init-select was not part of stretch, so an NMU would not be possible
afaics. At least I would be surprised if the SRMs would allow to
re-introduce a package via a stable upload.

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#850887: To the right bug this time: Why do you want us to keep this open?

[Michael Biebl]

clone 851412 -1
reassign -1 binutils
forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=21054
retitle -1 Forced local symbol rearranging messes up GOT

Hi James

Am 17.01.2017 um 12:18 schrieb James Cowgill:
> On 17/01/17 09:10, Michael Biebl wrote:
>> Am 17.01.2017 um 10:02 schrieb Michael Biebl:
>>> Hi there,
>>>
>>> as additional input, please have a look at [1] which just recently
>>> popped up. There seem to be still unresolved issues with binutils on
>>> mips*.
>>
>> I haven't reassigned this bug report to binutils yet, as I wanted to
>> have confirmation from the mips porters that it's a binutils bug.
>> They sort-of already confirmed it on IRC but wanted to look into it more
>> closely first. In any case, I've CCed them, so maybe they can respond to
>> #850887 or #851412
> 
> I had a closer look yesterday and it looks like a bug in the gold
> linker. You may be able to workaround it by using the bfd linker on mips.
> 
> Upstream bug:
> https://sourceware.org/bugzilla/show_bug.cgi?id=21054

Thanks a lot for your input and for having a look at this issue.
We had a discussion on #debian-release, which I'm quoting for
completeness sake:

 aurel32: are we sure systemd is the only package affected by this?
 mbiebl: no it's not only systemd
 mbiebl: there are some conditions to have the issue, which is
to use the gold linker
 so that's not that many packages given bfd is the default
 in addition you need to have symbols with hidden visibility
 so clearly we'll have to rebuild a few packages when it's
fixed on the binutils side, but we don't have 2.5 weeks of binaries
 aurel32: can we easily compile a list of "gold linker" consumers?
 mbiebl: i think having the workaround in systemd will help to
not accumulate too much packages in the queue
 aurel32: I guess as a first step, I'll clone the current
systemd bug and reassign it binutils
 nthykier: 1) we can parse the build logs from the last 3 weeks
 nthykier: 2) i think there is a way to identify the broken
binaries
 aurel32: and I'll apply the workaround for systemd
 mbiebl: ok, thanks
 ifneq ($(filter $(DEB_BUILD_ARCH), mips mipsel mips64el),)
 export DEB_LDFLAGS_MAINT_APPEND = -Wl,-fuse-ld=bfd
 endif
 does that look ok?
 it looks fine to me


We plan on uploading src:systemd today with this workaround applied
until binutils is properly fixed.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?




signature.asc
Description: OpenPGP digital signature

Bug#850887: To the right bug this time: Why do you want us to keep this open?

[Michael Biebl]

Am 17.01.2017 um 10:02 schrieb Michael Biebl:
> Hi there,
> 
> as additional input, please have a look at [1] which just recently
> popped up. There seem to be still unresolved issues with binutils on
> mips*.

I haven't reassigned this bug report to binutils yet, as I wanted to
have confirmation from the mips porters that it's a binutils bug.
They sort-of already confirmed it on IRC but wanted to look into it more
closely first. In any case, I've CCed them, so maybe they can respond to
#850887 or #851412

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#850887: To the right bug this time: Why do you want us to keep this open?

[Michael Biebl]

Hi there,

as additional input, please have a look at [1] which just recently
popped up. There seem to be still unresolved issues with binutils on
mips*. We had quite a few regressions since the 2.28 snapshots were
uploaded and we still seem to be running into them.

At this point in the release cycle, I'm not sure what the best couse of
action is. Continue uploading 2.28 snapshots from trunk until and
chasing (new) issues/regression or going back to 2.27. My gut feeling is
that the latter is the safer option, but maybe there is a good reason
why we want/need 2.28 for stretch. So far Matthias hasn't responded to
[2] though.

Regards,
Michael

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851412
[2] https://lists.debian.org/debian-release/2017/01/msg00240.html
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#846002: blends-tasks must not be priority:important

[Michael Biebl]

Am 10.12.2016 um 15:20 schrieb Ole Streicher:

> If you mean here why we just didn't put blends-tasks as dependency into
> tasksel-data: this wouldn't help, since the Policy says (§2.5):
> 
> "Packages must not depend on packages with lower priority values"
> 
> Since tasksel-data is Priority: important, blends-tasks would need to
> have this priority as well.

That part of the policy is non-sense and thankfully is in the process of
being fixed [1]. Library and helper packages should never be installed
because of their priority imho.
I deliberately violate that policy in various packages, fwiw.

Regards,
Michael

[I'll stop here since I don't want to derail the discussion to much,
just wanted to give my 2¢]

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758234
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#846002: blends-tasks must not be priority:important

[Michael Biebl]

Am 10.12.2016 um 14:15 schrieb Ole Streicher:
> Hi Michael,
> 
> On 10.12.2016 13:18, Michael Biebl wrote:
>> While I have no opninion on whether blend-tasks is important enough to
>> have installed by default,  I would urge to revisit the idea to (mis)use
>> the package priority to achieve that.
> 
> That is the standard way how tasksel gets its menu: tasksel-data is
> marked as "important" and that way it finds its way onto the installer
> image. So, all arguments you have here are also valid for the default
> tasks. If we think this is wrong, we should get a completely different
> solution here -- which is IMO outside of the scope of this bug.

Well, two wrongs don't make one right.

An obvious solution seemed to me, to make tasksel(-*) depend on
blends-tasks. This why, the package would be marked as auto-installed,
and should you later decide to implement that differently, say directly
in tasksel, then tasksel can simply drop that dependency.
I assume though you have considered this obvious solution and decided
against it for some reason?

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#846002: blends-tasks must not be priority:important

[Michael Biebl]

While I have no opninion on whether blend-tasks is important enough to
have installed by default,  I would urge to revisit the idea to (mis)use
the package priority to achieve that.

If a package was pulled in by debootstrap because of its priority, it's
marked as manually installed.
This is usually bad, because say later on you decide that you want to
change the name of the package or implement this differently, the
manually installed package sticks around.

So, assuming blend-tasks is important enough to be installed by default,
please think of another way to pull it in.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#841294: Overrule maintainer of "global" to package a new upstream version

[Michael Biebl]

On Tue, 15 Nov 2016 21:32:38 +0100 Tollef Fog Heen  wrote:
> I think this sounds quite reasonable, all in all.  It gets us a newer
> version (albeit not for stretch, but I see the points about changing
> that so close to the freeze), it gives users some warning about htags
> going away (and if that's a huge problem, we can adjust course as we
> learn more).

Would it be possible to provide an new upstream release in experimental
(now) and have a 6.* based version in stretch-backports once stretch is
released?

As an outsider, who doesn't really use global but is just reading what's
going on here, this seems like it would satisfy almost everyone

Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#728486: Current patch for resolving lvm/systemd compatibility

[Michael Biebl]

Am 19.01.2014 11:59, schrieb Bastian Blank:
 On Sat, Jan 18, 2014 at 11:33:32PM +0100, Michael Biebl wrote:
 On Sat, Jan 18, 2014 at 01:20:41PM +0100, Bastian Blank wrote:
 - lvm2.service is statically hooked to local-fs.target, as all local
   mounts.
 lvm2.service is not a local mount, so that is not really a justification for
 enabling the service statically.
 
 Please show me a better target.  This is what the generator does, so I
 assume there exists none.

This is a misunderstanding. The target is fine. I was just saying that
using the target as justification for enabling the service statically is
flawed.
That said, I don't really care if you hook up the service statically.
I'm just a bit surprised since you objected the generator as you wanted
the possibility to disable the service.

 
 +ExecStartPre=/bin/udevadm settle
 Please don't run udevadm directly. This is a udev command.
 
 Can you please describe what will be broken by this?

The more important question is: what are you trying to fix with this?
The cryptsetup.target will only be active once all hooked up devices are
ready. There is no point adding a udevadm settle. That is purely useless.
So again, what are you trying to do/fix here?

 Wants=systemd-udev-settle.service
 After=systemd-udev-settle.service ...
 (as the original .service file does).
 
 The generated service files uses both variants:
 - The pre-cryptsetup and pre-local-fs services uses
   systemd-udev-settle.service.


 - The pre-remote-fs service, which is not included here currently, uses
   ExecStartPre.

You don't include that service. And also, just because
pre-remote-fs.service uses the ExecStartPre hack is no justification for
using that in lvm2.service. pre-remote-fs.service is a completely
different beast.

If you need more information, please ask. But please don't cook up your
own patch just for the sake of it. This bug has been open for far too long.

Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#728486: Current patch for resolving lvm/systemd compatibility

[Michael Biebl]

On Sat, Jan 18, 2014 at 01:20:41PM +0100, Bastian Blank wrote:
 Untested patch:
 
 - Static services with the correct name.

Well, the original names from the upstream patch weren't really incorrect.
You just have to make sure that the lvm2 sysv init script is correcly
shadowed by the native service file. Using Alias=lvm2 would have
worked as well.

That said, if you prefer those names, that is ok.


 - lvm2.service is statically hooked to local-fs.target, as all local
   mounts.

lvm2.service is not a local mount, so that is not really a justification for
enabling the service statically. That said, if you want to ship the
symlinks in the package and not allow systemctl enable|disable (via
[Install] WantedBy=), this is something I'd be personally fine with.

 \ No newline at end of property
 Index: debian/tree/lvm2/lib/systemd/system/lvm2-early.service
 ===
 --- debian/tree/lvm2/lib/systemd/system/lvm2-early.service(revision 0)
 +++ debian/tree/lvm2/lib/systemd/system/lvm2-early.service(working copy)
 @@ -0,0 +1,11 @@
 +[Unit]
 +Description=Activation of LVM2 logical volumes
 +Documentation=man:lvm(8) man:vgchange(8)
 +DefaultDependencies=no
 +After=systemd-udev-settle.service
 +Before=cryptsetup.target local-fs.target shutdown.target
 +
 +[Service]
 +ExecStartPre=/bin/udevadm settle

Please don't run udevadm directly. This is a udev command.

Instead please use
[Unit]
...
Wants=systemd-udev-settle.service
After=systemd-udev-settle.service ...

(as the original .service file does).

Wants= will make sure the systemd-udev-settle.service is started
dynamically and After= ensures the correct ordering.


 +ExecStart=/sbin/lvm vgchange -aay --sysinit
 +Type=oneshot
 Index: debian/tree/lvm2/lib/systemd/system/lvm2.service
 ===
 --- debian/tree/lvm2/lib/systemd/system/lvm2.service  (revision 0)
 +++ debian/tree/lvm2/lib/systemd/system/lvm2.service  (working copy)
 @@ -0,0 +1,11 @@
 +[Unit]
 +Description=Activation of LVM2 logical volumes
 +Documentation=man:lvm(8) man:vgchange(8)
 +DefaultDependencies=no
 +After=lvm2-early.service cryptsetup.target
 +Before=local-fs.target shutdown.target
 +
 +[Service]
 +ExecStartPre=/bin/udevadm settle

Please remove this ExecStartPre (see above)


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140118223327.ga9...@pluto.milchstrasse.xx

Bug#688772: [CTTE #688772] Dependency of meta-gnome on network-manager

[Michael Biebl]

On 27.02.2013 00:50, Chris Knadle wrote:
 When this was brought up in the bug report, the response was network-manager 
 can be installed, then disabled, but how to do that wasn't documented 
 anywhere in the network-manager package.  Instead the next suggestion was 
 documenting this issue in the Wheey errata [2], but I don't see network-
 manager or wicd mentioned there, nor mentioned in the Installation Guide [3] 
 for Wheezy.
 
 Suggestions?

I will try to add a section to README.Debian which should be re-usable
for the release notes / errata.

Neil, who should I contact getting those changes into the release notes?
If anyone is willing to review the text, even better.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#699808: Bug#699742: syslinux 5.x support

[Michael Biebl]

On 06.02.2013 17:48, Michael Biebl wrote:
 Hi,
 
 On 06.02.2013 16:36, Daniel Baumann wrote:
 On 02/05/2013 09:33 PM, Michael Biebl wrote:
 I tried this patch against cc123e0 from debian-installer git.
 Unfortunately the problem is still the same.

 indeed; only the first part of the patch was attached; here's the 
 complete one.
 
 I can confirm that this patch works now. Thanks.


I have to correct myself: While the bootloader now does show up (when
trying an installation in VBOX), and I no longer get the error message
about the missing ldlinux.c32 file, it hangs after selecting the Install
option. The screen just stays black.

This didn't happen with syslinux 4.

Michael




-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#699808: tech-ctte: syslinux vs the wheezy release

[Michael Biebl]

On 06.02.2013 23:22, Don Armstrong wrote:
 On Wed, 06 Feb 2013, Russ Allbery wrote:
 Don Armstrong d...@debian.org writes:

 Assuming that the patch for #699742[0] fixes this issue with DI RC
 releases being installed, is there still an outstanding issue for the
 CTTE?

 Earlier in this thread, there had been a couple of reports that fix didn't
 work.  I haven't looked further, though.
 
 Yeah, that was for the first incomplete patch. I was referring to the
 second one.

Unfortunately the second patch doesn't work either. See [1].


Cheers,
Michael

[1] https://lists.debian.org/debian-boot/2013/02/msg00115.html

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#699808: tech-ctte: syslinux vs the wheezy release

[Michael Biebl]

On 07.02.2013 07:30, Daniel Baumann wrote:
 On 02/06/2013 11:48 PM, Michael Biebl wrote:
 Unfortunately the second patch doesn't work either. See [1].
 
 that is incorrect; the patch works, it's just the old vbox version in 
 current debian testing/sid which has a bug (try the image on real 
 hardware or any other virtualization and it works).

Well, VBOX is pretty popular, so shipping an installer which doesn't
work for such an environment is certainly a no-go.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#699808: tech-ctte: syslinux vs the wheezy release

[Michael Biebl]

On 07.02.2013 07:58, Daniel Baumann wrote:
 On 02/07/2013 07:45 AM, Michael Biebl wrote:
 Well, VBOX is pretty popular, so shipping an installer which doesn't
 work for such an environment is certainly a no-go.
 
 again, the syslinux in sid would not be in wheezy. making it a 
 *temporary* problem until vbox has been fixed in debian (which i'm happy 
 to NMU again, will look to cherry-pick the required patch later today).

I think it is obvious by now that reverting to syslinux 4 from wheezy is
the only sensible way forward at this point in the release.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#699808: tech-ctte: syslinux vs the wheezy release

[Michael Biebl]

On 07.02.2013 08:06, Daniel Baumann wrote:
 On 02/07/2013 07:55 AM, Michael Biebl wrote:
 I think it is obvious by now that reverting to syslinux 4 from wheezy is
 the only sensible way forward at this point in the release.
 
 'obvious'?

Imho, yes. But then, it's not up to me to decide.

* patch applied against debian-installer to include the additionally
  required .c32 modules when using vesamenu.c32
 
* patch applied against debian-cd to include the additionally required
  .c32 modules when using vesamenu.c32
 
* cherry-pick upstream commit to fix a bug in vbox

This list is getting longer with each email. Seeing that syslinux 5 has
been in sid for less then 10 days, I'm worried what other issues might
show up.
While I can understand (from personal experience) that freeze-time is
sometimes frustrating, delaying the release even further doesn't help
anyone.
If we want to improve our procedures, how we handle d-i, freeze etc, now
is not the time to discuss/work on this.

Just my 2¢

Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#688772: gnome Depends network-manager-gnome

[Michael Biebl]

On 25.10.2012 22:47, Andreas Barth wrote:
 * Jeremy Bicha (jbi...@ubuntu.com) [121025 18:51]:
 On 25 October 2012 12:17, Don Armstrong d...@debian.org wrote:
 That said, if I'm wrong, and you believe that there is a compromise
 which would resolve the concerns raised beyond those already presented
 (status quo with/without release notes), now would be the time to
 present it.

 My proposal is to:
 1. Add a paragraph to the Release Notes with the one line command
 people should use if they don't want NetworkManager running:
 update-rc.d disable network-manager
 2. And cases where that doesn't work are RC.
 
 How would that prevent startup of n-m during upgrades from stable to
 next-stable?  (Which could already present issues, especially if the
 system is remote managed)

I've been discussing with jordi today about this issue.

One idea that came up was to check wether wicd is in use (or for that
matter ifupdown), and then show a debconf prompt explaining the
situation, and letting the user chose if he wants to take over network
management by NetworkManager.
It would work similar to how we currently handle multiple installed
display managers, like gdm3 or kdm (btw, gdm3 is currently a hard
depends of gnome-core).
If the users choses no, we could disable the service via update-rc.d
disable, so the invoke-rc.d later on in postinst would not start NM.

This would also help in situations where users install both wicd and
network-manager by accident, which usually doesn't really work well
since e.g. both spawn their own instance of wpa_supplicant.

A more detailed reply will follow soon.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#688772: gnome Depends network-manager-gnome

[Michael Biebl]

On 24.10.2012 03:29, Sam Hartman wrote:
 Don, in your option 4B, I wonder if it would be a good idea to  have the
 depend be something like g-n-m|wicd|no-network-manager

The gnome meta-package certainly won't get an alternative dependency
on wicd. That would be completely stupid and miss the point of this
dependency. The GNOME desktop has zero integration with wicd, so this
alternative dependency is completely backwards.
Why don't you force a dependency on ifupdown on us, or ifplugd or whatever.

This whole crusade by the ctte is so ridiculous, but unfortunately I
can't laugh about that anymore.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Bug#688772: gnome Depends network-manager-gnome

[Michael Biebl]

 Russ Allbery writes (Bug#688772: gnome Depends network-manager-gnome):
 I've been thinking about this over lunch, and I do feel like the gnome
 metapackage is substantively different than the gnome-core metapackage.
 I'm not sure if it's sufficiently different to warrant a different
 decision, but it does seem different enough to warrant a separate
 discussion.

One of the major complaints was, that there is no longer a meta-package
which gives a sufficient and complete enough GNOME desktop environment
without a NM dependency. The gnome-session package was considered to be
not appropriate.
Joss solution definitely addresses that while trying to preserve our
vision what we (as a team) and upstream define a default GNOME environment.

Assuming bad faith and the language that was chosen by Ian really
troubles me, especially his attempt to reprimand Joss.
Somehow I have the feeling Ian is taken this whole issue to personally
(which he admits himself) and that clouds his judgements on a technical
level.

That all said, and I hope we can leave this behind us, as this infight
leads nowhere.



 Most of the points that were determinative of our decision on
 gnome-core apply to gnome too.
 
 The historic point of the gnome metapackage is not to just install the
 base machinery of GNOME in the same way that gnome-core is.  It's rather
 to give the user a complete desktop environment built around GNOME.  There
 have historically been all sorts of applications in there that people may
 or may not use.  It's a fairly heavy-weight metapackage; it pulls in
 everything from office suites to a mail client.
 
 All of that is fine but of course as you yourself wrote:
 
   4. For most applications and components, the only drawback of this would
  be some additional disk space usage, since the application, despite
  being installed, wouldn't need to be used.  However, network-manager
  assumes that, if it is installed, it should attempt to manage the
  system's network configuration.  It attempts to avoid overriding local
  manual configuration, but it isn't able to detect all cases where the
  user is using some other component or system to manage networking.
  The user has to take separate, explicit (and somewhat unusual for the
  average user) action to disable network-manager after it has been
  installed.
 
 So n-m is special.

Actually, NM is not really special. The gnome and gnome-core
meta-packages install a wide variety of applications and infrastructure,
which are

a/ active by default. E.g. components like avahi-daemon are started by
default.

b/ being used as default application after being installed, e.g. via
mime associations and default settings. The GNOME desktop environment
sets up a default web browser, email client, Texteditor, Music Player
etc. Whenever you try to open a file, a link, those default applications
will be opened. The user needs to explicitely configure other
alternatives. This can mean changing dconf/gconf settings, and requires,
as Ian called it, unusual, explicit actions.
So it is false to say that those applications only use some disk space
and aren't noticeable when not used.
Indeed, I would argue that for most users, the default choice we set for
the web browser, email client, video or music player, etc. is a much
more visible and important issue.

 But the upgrade issue is the same and will affect nearly as many
 users.  And on the face of it it is simply entirely wrong to upgrade
 the dependency.  I can see no justification for it.  And the
 maintainers haven't even provided one!

This is simply wrong. The GNOME team (and others) has provided a
justification on several occasions. It's simply that Ian conveniently
dismisses/ignores that.
The reason the Recommends was upgraded to a Depends is twofold:
a/ a much tighter integration of NM into the desktop compared to
squeeze.
This involves integration into the Shell, gnome-control-center,
applications making more extended usage of NM, e.g. PackageKit being
more clever and trying to avoid costly updates when being online via
Mobile Broadband. Just to name a few examples.

b/ a change in how our users have become more mobile.
Wireless is a commodity nowadays, Mobile broadband for many is an
essential feature they use on a daily basis. Or the road warrior which
needs VPN access. Only NM provides these features today.

 What you are proposing is a compromise between doing the right thing
 for our users, and upholding the autonomy of the maintainer.

Changing the Depends to Recommends was never the right solution to the
real issue, imo. The underlying problem is that:

a/ some users will always be unhappy with the choices we make for those
meta-packages. Some want A instead of B, some want no C at all, some
want D being added and such. It is simply impossible to please everyone.
My simple recommendation for such users is, to juse not use those
meta-packages then and pick and chose what you want instead.
You 

Bug#681687: missing mime entry

[Michael Biebl]

On 21.07.2012 23:40, Adam D. Barratt wrote:
 On Sat, 2012-07-21 at 23:12 +0200, Michael Biebl wrote:
 On 21.07.2012 09:11, Steve Langasek wrote:

 Now, I think providing a tool to auto-translate .desktop files into mailcap
 entries is a perfectly appropriate way to go about solving this bug, if
 [...]
 The new mime support maintainer team, which took over the package just a
 few days ago, did ask the release team, if it would be possible to still
 apply this patch for wheezy [2].
 [...]
 [2] https://lists.debian.org/debian-release/2012/07/msg01048.html
 
 As far as I can tell, that's very much not what that message says.  In
 fact, it doesn't appear to request anything of the release team at all.

Well, Charles did not specifically ask the release team, but he CCed the
release team and his email contains:

 4) Postpone any other change on the main branch until either #681687 (tech.
comittee) is solved or Wheezy released.

This reads to me as if Charlees is waiting for a decision from the ctte.

If Steve and other members of the ctte consider such a tool as an
approriate way to solve this bug, would the release team also
acknowledge this approach or not?

Anyway, let's put Charles and Laszlo on CC so they have chance to
comment on it.

My position is clearly, that this issue should be solved for good.
Postponing this for another release just doesn't seem right to me, as
simply adding back a single mime file would be an incomplete workaround
at best.

From past experience we still have around 5 months until we release.
This should be enough time to get this ready for wheezy. And as said, if
unsurmountable problems turn up which can't be addressed within say two
months, we can simply drop the converter again and then add back the
evince mime file.

Is this a proposal that the ctte, release team and mime-support
maintainers could agree with?


Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#681687: missing mime entry

[Michael Biebl]

On 21.07.2012 09:11, Steve Langasek wrote:

 Now, I think providing a tool to auto-translate .desktop files into mailcap
 entries is a perfectly appropriate way to go about solving this bug, if
 someone chooses to do that.  If such a tool emerges, I think that's great
 for Debian as a whole, and we can consider revising Policy to consider
 .desktop files the primary interface instead.  But until we have such a tool
 working in the release, it's the responsibility of the evince maintainers to
 make sure their package complies with policy.

A patch providing this converter has been available for a few months
[1]. The mime-support maintainer just never got around to upload it or
even comment on it.

The new mime support maintainer team, which took over the package just a
few days ago, did ask the release team, if it would be possible to still
apply this patch for wheezy [2].
I think this should be the solution we should aim for and I would
appreciate if the release team could give the mime-support maintainers a
green light for the unstable upload.
If the converter solution turns out to be too buggy or requires larger
changes, we have a simple contigency plan, i.e. just drop the converter
again.

I would really appreciate if we could try to fix this *whole* issue for
good for *wheezy*. Re-adding the mime file in evince can still be done
if the proper mime-support fix has not been done in say a month or two.

Michael


[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497779
[2] https://lists.debian.org/debian-release/2012/07/msg01048.html
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#681834: network-manager, gnome, Recommends vs Depends

[Michael Biebl]

On 18.07.2012 23:40, Ian Jackson wrote:

 Secondly, it is possible for dhcp entries to be non-trivial.  They may
 specify interesting scripts to be run, dhcp options, bridging, etc.
 It's not clear to me exactly which of these scenarious result in
 what outcome.

NM doesn't take over any such entries which have more complex options.



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#681687: Bug#658139: missing mime entry

[Michael Biebl]

On 18.07.2012 11:14, Neil McGovern wrote:
 Hi,
 
 On Tue, Jul 17, 2012 at 11:45:42PM +0200, Michael Biebl wrote:
 If a missing mime file would mean an RC bug, this would instantly make
 514 packages RC buggy.
 Interestingly, the particular section in the Debian policy is a should
 directive, not a must, so I don't understand the reasons for making
 #658139 RC.

 
 For info, I do not consider all packages missing a mime file to be RC
 buggy. I consider #658139 RC.

And what is the reason that makes evince special and distinguishes it
from other packages which never shipped a mime file or no longer do?
Your decision seems arbitrary.
mime files were removed across the board from the GNOME packages a long
time ago.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#681834: network-manager, gnome, Recommends vs Depends

[Michael Biebl]

Am 17.07.2012 14:56, schrieb Ian Jackson:
 block 645656 by 681834
 thanks
 
 The argument about the dependency from gnome-core to network-manager
 has now reached the TC.  This has been extensive discussed, most
 recently on debian-devel.  The most recent response from Josselin is
 here:
   http://lists.debian.org/debian-devel/2012/07/msg00210.html
 
 It seems to me that:
 
  * n-m breaks the networking of enough people that this is a
significant problem which should be fixed.

This is pure FUD without further details. Do you have any bug numbers in
particular? I don't claim that there aren't any bugs in NM but if there
are issues, they should be fixed in NM.

  * There is not currently another metapackage besides gnome-core that
would pull in enough of the gnome system.

You can use gnome-session and install the additional packages you want.

Also, as an alternative if you can't use network-manager for whatever
reasons,  you can install gnome-core and disable network-manager. This
is as simple as

update-rc.d network-manager disable


  * There is no good reason not to use Recommends (or indeed Suggests)
in a metapackage.

Not true, Joss put it very well at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=645656#65

Ian, you can of course dismiss all those reasons (as you did in the
past), but that doesn't mean that those reasons are not valid.
I have the impression that you are biased against NM regarding this
issue and in general.

  * In particular, tests have shown that the remainder of gnome
functions as expected when network-manager is not installed; the
situation appears to be the similar to that which occurs if n-m is
installed but the system's active network connection is not one
made by n-m.

Those so called tests have been done by Adam Borowski, who is known to
hate NM, so he is not impartial on this topic.

And no, it doesn't work as expected. GNOME users expect to be able to
setup their network with a single click.
None of the alternatives has a comparable integration into GNOME as
network-manager. Not wicd, and definitely not ifupdown.

We want to provide a coherent environment where the differenct
compontents are integrated as best as possible.

As for the situation where nm is installed but doesn't manage the
network connection: This is actually extremely confusing to users as
various bug reports have shown.

 So I would propose that we:
 

  * Overrule the maintainer of gnome-core, requiring that the
dependency on network-manager be changed to Recommends;

If you force us to do that against our better judgement, I'm handing in
my resignment tomorrow.



Michael





signature.asc
Description: OpenPGP digital signature

Bug#681834: network-manager, gnome, Recommends vs Depends

[Michael Biebl]

On 17.07.2012 22:30, Russ Allbery wrote:
 Michael Biebl bi...@debian.org writes:
 
 Also, as an alternative if you can't use network-manager for whatever
 reasons,  you can install gnome-core and disable network-manager. This
 is as simple as
 
 update-rc.d network-manager disable
 
 [...]
 
 As for the situation where nm is installed but doesn't manage the
 network connection: This is actually extremely confusing to users as
 various bug reports have shown.
 
 Are these two points consistent?  In other words, *is* it as simple as
 running:
 
 update-rc.d network-manager disable
 
 and installing wicd or something else, or is that configuration extremely
 confusing to users? 

I think those points are consistent. Users which deliberatly chose to
install wicd (or use other mechanisms) will most likely know what they
are doing and that this will have effects on how their desktop
environment will behave, e.g. that they will no longer be able to
configure their network via gnome-control-center, the network indicator
in the top panel will be gone, on/offline detection no longer being
available, etc.

As for the point of non-managed devices being confusing to users, I
probably need to say a few words:
In the network-manager package we go to great lengths to be a good
citizen and respect existing configuration. That means, if the
network-manager daemon finds a configuration in /etc/network/interfaces
for a given physical device, it does not manage that device under the
assumption that the user/administrator deliberately set up /e/n/i to
have ifupdown manage this interface.
It is hard to distinguish, which entries were created manually and which
by the debian installer, though.
The d-i installer typically creates a /e/n/i configuration, so users
weren't able to manage this device with network-manager after a
successfull installation, unless they manually removed the configuration
from /e/n/i.
This was extremely confusing for less experienced users and I got
numerous bug reports over the years [1].
We thus tried a compromise, where the network-manager postinst script
automatically comments out dhcp-type connections in /e/n/i (and restores
them, in case the package is removed again,fwiw).
This is admittedly quite ugly, but ifupdown didn't provide a nicer
interface to achieve that at the time.
Andrew has signaled interest in providing a better interface for that in
ifupdown, so hopefully we can solve that in a nicer way. IIRC, the
Ubuntu graphical installer no longer creates any /e/n/i configuration at
all, to avoid this problem completely.


 If there's a clean way to disable network-manager, I think that's a
 reasonable alternative to either creating yet another meta-package or
 arguing about Depends vs. Recommends in gnome-core.  But there seems to be
 a lot of debate over this point.

Disabling network-manager via update-rc.d network-manager disable is a
reliable and clean way to stop network-manager from running. It won't be
magically re-enabled on upgrades or restarted, since invoke-rc.d
respects if a sysv service is disabled this way.



Michael


P.S: I apologize for the threats to leave in my last email. I know this
is not professional. This whole issue is extremely frustrating though
and I'm currently quite pissed so I reacted more emotionally, then I
should have.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606268
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature