Re: Bug#978636: move to merged-usr-only?

[Matthias Klumpp]

Am Di., 29. Dez. 2020 um 23:13 Uhr schrieb Marco d'Itri :
>
> On Dec 29, Matthias Klumpp  wrote:
>
> > For package upgrades, we can already perform so-called "offline
> > upgrades", where the system reboots into a smaller systemd target,
> > applies all updates and then reboots again into the updated system.
> > This is implemented in PackageKit as an option and used by GNOME.
> > Fwupd uses similar concepts for certain firmware updates as well.
> > Maybe hooking into these facilities is also an option for the usrmerge
> > upgrade? (unless of course systemd is still interfering even in a
> > minimal target, that would be a dealbreaker).
> It depends on which units are started (this trouble is caused by the
> ProtectSystem directive and maybe others like it): having usrmerge
> stop and then restart the daemons involved would work as well, but I am
> not sure of how many corner cases (gdm...) we would find before just
> rebooting would become simpler again.
> I think that depending on PackageKit would be more complex than an
> initramfs-tools hook, since just about everybody is supposed to have
> that around.

You wouldn't have to depend on PackageKit, the offline-upgrades stuff
can be implemented by other tools that aren't PK as well (you could
pretty much use the same mechanism, with some safeguards to not
interfere with PK/GNOME). However, ensuring that no service with
ProtectSystem starts may be a problem, as that feature is used quite
extensively by services that are part of the systemd project, and I
don't know whether it is possible to exclude them all from a potential
usrmerge target without causing other problems.

Also, of course this would only work on systemd systems, in the same
way that the initramfs-tools solution won't work for Dracut users.
Looks like quite a tricky problem, but one that could definitely be
addressed by the project.

Cheers,
Matthias



-- 
I welcome VSRE emails. See http://vsre.info/

Re: Bug#978636: move to merged-usr-only?

[Matthias Klumpp]

Am Di., 29. Dez. 2020 um 17:39 Uhr schrieb Marco d'Itri :
>
> On Dec 29, Ansgar  wrote:
>
> > as suggested in [1], I would like to see Debian to move to support
> > only the merged-usr filesystem layout.  This would simplfy things for
> > the future and also address the problem with installing files under
> > aliased trees that dpkg has to do for both variants to be supported.
> As the architect of the Debian merged-usr transition, I agree: removing
> support for unmerged systems would simplify many things.
> Thank you Ansgar for bringing this to the CTTE.

Indeed!

> > I'm not asking the committee to decide on a concrete technical
> > implementation for this.  Obviously we would need to also implement a
> > migration path for legacy installations for a move to merged-usr-only
> > to be implemented.  This also isn't relevant for Debian 11 (bullseye),
> > but I would like to have enough time in the Debian 12 (bookworm)
> > cycle.
> Agreed.
> FWIW: we have had for a long time a reliable migration method, the
> usrmerge package.
> Except that on a live system it requires a reboot mid-conversion (due to
> bind mounts created by systemd): since this is inconvenient and mildly
> scary I did not propose wider adoption for buster.
> The best workaround would probably be to run it from the initramfs, but
> I have not been able to actually make this[1] work: I expect that
> somebody who knows initramfs-tools better than I do can fix it quickly.

For package upgrades, we can already perform so-called "offline
upgrades", where the system reboots into a smaller systemd target,
applies all updates and then reboots again into the updated system.
This is implemented in PackageKit as an option and used by GNOME.
Fwupd uses similar concepts for certain firmware updates as well.
Maybe hooking into these facilities is also an option for the usrmerge
upgrade? (unless of course systemd is still interfering even in a
minimal target, that would be a dealbreaker).
More info about offline-upgrades can be found at [1], could be
interesting to look into.

This discussion is probably OT through for the issue at hand (*if* we
make that switch, not the *how* we make it in particular).

Cheers,
Matthias

[1]: 
https://www.freedesktop.org/software/systemd/man/systemd.offline-updates.html

-- 
I welcome VSRE emails. See http://vsre.info/

Re: CITL Releasing 7000 defects/vulnerabilities

[Matthias Klumpp]

Am So., 1. Nov. 2020 um 15:22 Uhr schrieb Xavier :
>
> Hi,
>
> Ubuntu is based on testing and does not import our fixes after its release 
> (except a few list), then it's normal to find a lot of vulnerabilities. See 
> https://lemonldap-ng.org/documentation for exemple
>
>
> Le 1 novembre 2020 14:59:32 GMT+01:00, Utkarsh Gupta  a 
> écrit :
>>
>> [CCing team@security.d.o]
>>
>> On Sun, Nov 1, 2020 at 7:09 PM Ole Streicher  wrote:
>>>
>>> I just stumbled upon the following web page:
>>> https://cyber-itl.org/2020/10/28/citl-7000-defects.html
>>> They claim to have found ~7000 defects in Ubuntu packages (a number of
>>> those are maintained by me).
>>
>>
>> On a *very* quick look, some of these packages have CVE(s) issued
>> against them and are already fixed as well, I think.
>>
>> That said, it'd be a bit weird if they don't report these issues and
>> ask for a CVE assignment against these.
>> Anyway, the security team might know more about this.

-
While CITL doesn’t particularly want to see software remain vulnerable
or flawed, it is not CITL’s mission to improve the software itself.
CITL’s mission is to create scientific, quantifiable, and reproducible
ways to measure software binaries to understand how fragile or robust
they may be. The work CITL performs is ultimately to allow consumers
(for a wide definition of consumers) to evaluate software the software
they use or intend to use. All of this work is designed to happen
behind the scenes, as CITL was never designed for high-touch
interfacing.
-

Is it just me, or does that paragraph sound very fishy?
In addition to that, some of the crashes they list terminate with
SIGABRT, which makes me think it's highly unlikely that there is any
security vulnerability involved. Even the segmentation faults may not
be security issues. Regardless, it would have been nice if they had
reported the issues they found while fuzzing binaries.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Re: DEP-14: renaming master to main?

[Matthias Klumpp]

Am Mo., 22. Juni 2020 um 23:30 Uhr schrieb Colin Watson :
>
> On Mon, Jun 22, 2020 at 05:50:02PM +0200, Michael Biebl wrote:
> > there has been a lot of talk recently about how master is a loaded term
> > that should be avoided.
> > If I read the news correctly, github and others are going to change the
> > default master branch to main.
> > I don't really have any strong opinion on that matter myself.
>
> For a while I'd thought that it was relatively harmless in comparison to
> full-blown uses of master/slave metaphors, but I saw some analysis of
> the history recently that pointed out that git got it from BitKeeper
> which did in fact use a master/slave metaphor [1].
> [...]

This is actually untrue and has been clarified by Bastien:
https://mail.gnome.org/archives/desktop-devel-list/2020-June/msg00023.html

Even though the "Git master" originates from "master recording" /
"master copy" though, I don't think it's worth the fight or
complaining a lot about people wanting to change it, as long as there
is another metaphor which is equally valid. I think "main" would kind
of fit that original intent best, but let's see what the other
stakeholders in the Git community decide (the guy who originally came
up with the name suggesting a change is certainly influential!).
Personally, I do wonder how the "Git master branch" separates from
other stuff with "master" (but no "slave") in it, like "mastering a
subject" or "Master of science", but I am also not a native speaker,
and lots of people seem to be bothered by it, so changing the name
does make sense to me (definitely for new projects where there is no
risk of breaking something).

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

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

[Matthias Klumpp]

Am Do., 6. Feb. 2020 um 17:12 Uhr schrieb Simon Richter :
>
> Hi Marco,
>
> On Thu, Feb 06, 2020 at 03:08:28PM +0100, Marco d'Itri 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.
>
> Adoption of systemd on machines with popcon installed and active, which are
> largely desktop and laptop installations, i.e. those cases where systemd
> provides a tangible benefit.
>
> Popcon is useful for determining what goes on the first installation DVD,
> but neither popcon nor mirror download statistics can measure the impact a
> particular package has.
>
> I'd expect servers and embedded systems to be vastly underrepresented in
> both of these statistics, but that doesn't mean these use cases are in any
> way uninteresting to the project.

Those are also the usecases where defaults matter the least though. We
can certainly expect administrators of a server to be able to `apt
install rsyslog` if they want to use it. On embedded systems I
personally actually found the systemd journal to be very nice to use,
but embedded systems are the most customized Debian installations out
there, so we can't choose a default that works for all of them anyway.

>From personal experience, all that's needed to switch to the journal
for an admin is to re-learn a couple of commands and be open to a bit
of change. I so far found nothing that I could do with rsyslog to be
impossible with the journal.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Re: opentmpfiles & opensysusers, and its use in the Debian policy

[Matthias Klumpp]

Am Sa., 4. Jan. 2020 um 00:16 Uhr schrieb Russ Allbery :
>
> The Wanderer  writes:
>
> > What I'm concerned about is dbus socket activation, or similar, leading
> > to e.g. logind getting activated by logging in at the text console.
>
> > I thought I understood that socket activation via dbus was one of the
> > features which didn't require systemd as PID-1 to function.
>
> It may be that the user service manager in systemd supports D-Bus socket
> activation, but none of the user services provided in the systemd package
> seem to start logind, so I don't think you'll get that service started
> that way.  I'm only seeing systemd-exit and systemd-tmpfiles.
>
> Also, I'm not sure what would start the user service manager if you're not
> running systemd as PID 1.

Indeed. Looking through the large set of binaries and interfaces
provided by the systemd package, I do wonder though: One of the points
of the systemd project is to actually provide interfaces applications
and the OS can rely on being present. For that matter, it simply
doesn't make sense to split up the systemd package, as it makes
maintenance harder and may only introduce issues. At the same time
though, the usecase of containers and minimal chroots exists, where
you sometimes want to save as much space as possible and where you
will never ever run a full initsystem / service manager.
The systemd maintainers already split out machinectl and nspawn into
their own systemd-container package, as it's not needed in every
configuration.

Potentially, splitting out the bare minimum binaries to run a Debian
system in a container setting / minimal chroot makes sense for the
Debian systemd maintainers. This, coincidentally, would also put users
of other init systems at ease. I believe by approaching the problem
that way, there may actually be a possibility for mutually beneficial
synergies here.
Looking through the postinst scripts and contents of the systemd
package, I am very certain that it won't suddenly run anything if
you're not already on a systemd-as-PID1 system. So having it should be
safe for alternative initsystems (however, note that I haven't tested
that).

The systemd package currently (244-3) contains the following utilities[1]:

## (mostly) User-invoked CLI tools
Those are components usually invoked by a human, but may be used in
scripts as well.
 * journalctl: Read the system journal, if available (otherwise does nothing)
 * loginctl: Control login sessions, logind related stuff
 * systemctl: Control system services / system state
 * systemd-escape: Escape strings for usage in systemd unit names
 * systemd-inhibit: Execute a program with an inhibition lock taken
(e.g. prevent sleep/idle)
 * bootctl: Control the firmware and boot manager settings
 * busctl: Introspect the bus (D-Bus)
 * hostnamectl: Control system hostname and related stuff
 * kernel-install: Add and remove kernel and initramfs images to and from /boot
 * localectl: Change system locale
 * timedatectl: Modify system time/date
 * resolvectl: Introspect and reconfigure the DNS resolver
 * systemd-analyze: Analyze and debug system manager (only useful if
systemd is PID1)
 * systemd-cat: Connect a pipeline or program's output with the journal
 * systemd-cgls: Recursively show control group contents
 * systemd-cgtop: Show top control groups by their resource usage
 * systemd-delta: Find overridden configuration files
 * systemd-id128: Generate and print sd-128 identifiers
 * systemd-mount, systemd-umount: Establish and destroy transient
mount or auto-mount points
 * systemd-path: List and query system and user paths
 * systemd-run: Run programs in transient scope units, service units,
or path-, socket-, or timer-triggered service units (needs the service
manager to be PID1)
 * systemd-socket-activate: Test socket activation of daemons

## Systemd core components
These components are usually invoked by scripts, but may be used by
humans as well.
 * systemd: PID1
 * systemd-ask-password: Query for a root password, e.g. when a
bootsplash is active. Possibly useful w/o sd PID1
 * systemd-machine-id-setup - Initialize the machine ID in /etc/machine-id
 * systemd-notify: Notify service manager about start-up completion
and other daemon status changes
 * systemd-sysusers: Allocate system users and groups
 * systemd-tmpfiles: Creates, deletes and cleans up volatile and
temporary files and directories
 * systemd-tty-ask-password-agent: List or process pending systemd
password requests

 * systemd-detect-virt: Detect execution in a virtualized environment
 * systemd-stdio-bridge: STDIO or socket-activatable proxy to a given
DBus endpoint.

## Daemons
Some of them are enabled by default, some of them are optional and
have to be activated by the users, some of them (like journald) run in
modes which actually only forward data to other preexisting services
by default (rsyslog) unless instructed otherwise by the user.
None of those are run on systemd where systemd isn't PID1, because all
of the

Re: Appstream + Gnome

[Matthias Klumpp]

Am Do., 2. Jan. 2020 um 21:58 Uhr schrieb Jeff :
>
> On 02/01/2020 16:53, Matthias Klumpp wrote:
> > @Jeff Did your changes include adding a launchable tag? If not, adding
> > one may already fix this issue.
>
> Yes, I had.
>
> > When transitioning:
> >  1) Make sure you add a launchable tag - it may not be essential, but
> > it certainly is more explicit. Also, you'll get a validator info hint
> > if you don't have one.
> >  2) Add the old ID to , so tools can still associate older
> > data with the new name (if they ćare about that)
>
> The workaround I've found is to duplicate the .desktop file, one with
> the correct ID, and one matching the executable name.

Ah! In this case renaming of the .desktop file probably was the issue?
Since you have two .desktop files now, make sure the old one has
either NoDisplay=True set, or contains the X-AppStream-Ignore=True
field (or both), otherwise your application will appear twice in
software centers.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Re: opentmpfiles & opensysusers, and its use in the Debian policy

[Matthias Klumpp]

Am Do., 2. Jan. 2020 um 18:41 Uhr schrieb Simon McVittie :
> [...]
> I seem to remember a systemd upstream developer being asked during
> recent discussions whether they were willing to guarantee that
> systemd-tmpfiles and systemd-sysusers will continue to work when used on
> non-systemd-booted systems (not just sysvinit, but also chroots, Docker,
> etc.), but I'm afraid I've lost track of what the answer was.
> [...]

No problem! => https://lists.debian.org/debian-devel/2019/12/msg00060.html

Am Mo., 9. Dez. 2019 um 00:23 Uhr schrieb Zbigniew Jędrzejewski-Szmek
:
> Hi,
>
> [disclaimer: on work on systemd upstream, I'm not an active Debian
> user anymore.]
>
> Using systemd-sysusers and systemd-tmpfiles more widely was mentioned
> a few times, along with a statement that an implementation for
> non-systemd systems would need to be provided. Both those programs
> work just fine without systemd not running as PID1. (systemd has unit
> files to start them automatically during boot and at regular
> intervals, so that part would need to be reimplemented appropriately
> for a given init system if desired. The programs themselves don't care
> at all how they are started.)
>
> For example, upstream distributes rpm scriptlets [1] to invoke them
> from an rpm transaction, i.e. possibly without any programs running in
> the install root.
>
> [1] 
> https://github.com/systemd/systemd/blob/master/src/core/macros.systemd.in#L123
>
> Zbyszek
>

I find that statement quite encouraging. Of course they don't commit
to not having those depend on systemd-as-PID1, but there really isn't
a reason to create that dependency, and if for whatever reason there
will be one at some point, we can switch away on systems that don't
support that change rather easily.
Since both features are covered by the interface stability promise (
https://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/
) I think assuming that this will work for a really, really long time
is very reasonable.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Re: opentmpfiles & opensysusers, and its use in the Debian policy

[Matthias Klumpp]

Am Do., 2. Jan. 2020 um 17:28 Uhr schrieb Ansgar :
>
> Thomas Goirand writes:
> > [...]
> > I'm not sure why
> > there's both /bin/systemd-sysusers and /usr/bin/systemd-sysusers, and
> > which one should be used.
>
> For the same reason there is /bin/bash and /usr/bin/bash probably?

I don't have both of those. Since I am on an usrmerged system though,
/bin/systemd-sysusers and /usr/bin/systemd-sysusers are exactly the
same binary. Maybe that's the thing that caused a bit of confusion?

Personally, I think it might make a lot more sense to have tools
depending on systemd-sysusers depend on the original systemd package,
given that those binaries can be used without systemd being PID1. That
of course needs people to write initscripts for them, which may need
to live in a separate package (or possibly even be part of the
alternative initsystems themselves, for easy maintenance) so people
who want them can pull them in. If pulling in the bigger systemd
package is a problem (as not everything in there works if systemd
isn't PID1), possibly splitting the sysusers binaries out to a
separate package may work as well.
By using the systemd-provided files, we can ensure that any possible
new features are immediately available everywhere and nothing has to
"catch up", and systemd systems won't get confused over which
implementation is the right one currently.

In any case, the existence of opensysusers/opentmpfiles is really
great already, that makes using these features viable faster and with
much less friction, since every system will be supported

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Re: Appstream + Gnome

[Matthias Klumpp]

Hi everyone!
Sorry for the delayed reply, I was busy with traveling around during
the new year. For that matter: Happy new year! :-)

I am the upstream maintainer of AppStream as well as in Debian.

Am Mi., 1. Jan. 2020 um 13:17 Uhr schrieb Jeff :
>
> Firstly - apologies for sending this to -devel. Please point me at a
> better place to ask the question if there is one.

I don't think there's one explicitly for Debian. The Freedesktop
mailinglist occasionally gets distro-related questions, and if you
suspect a bug a report against src:appstream will work. But I am also
fine with this on d-devel.

> One of my packages is an application and ships a .desktop file and
> appstream xml. The tracker.debian.org page for the package complained
> that the ID for package didn't follow the {tld}.{vendor}.{product}
> scheme[1], so I modified so that it did.
>
> Now I have a report from a Gnome 3 user that since the above change, it
> is no longer possible to add the application as a "favorite".

To clarify: Do they claim it's no longer possible to add the app as
favourite in GNOME Shell, or in the GNOME Software app?

> [...]

Am Mi., 1. Jan. 2020 um 21:35 Uhr schrieb Simon McVittie :
>
> On Wed, 01 Jan 2020 at 13:17:34 +0100, Jeff wrote:
> > One of my packages is an application and ships a .desktop file and
> > appstream xml. The tracker.debian.org page for the package complained
> > that the ID for package didn't follow the {tld}.{vendor}.{product}
> > scheme[1], so I modified so that it did.
>
> My understanding is that downstream distributors like Debian should
> not be changing the AppStream ID: this is something that should be done
> in a coordinated way by the package's upstream developers, so that all
> downstream distributions (both traditional OS distributions like Debian
> and Fedora, and app frameworks "above" the OS like Flatpak and Snap)
> end up using the same ID.

Exactly, and this is actually a very important thing in AppStream. IDs
should be static and shouldn't be changed by individual downstream
projects, because that makes the software component essentially a
different one in the eyes of AppStream. That can lead to multiple
issues, like tools using the data getting confused when fetching
information about the software, or ratings and reviews not getting
attributed to the right software.

The validator hint exists to basically forward this issue upstream and
ask them to change the ID if it's a new application - new AppStream
metainfo files should ideally not ever start with a non-reverse-DNS
ID. That the other scheme exists is a mistake of the past, which we
will now support forewer. This also means that if the app doesn't
follow the rDNS scheme, they may not want to change the ID if the old
one has been established for years. That's fine too in that case.
A way to transition IDs exists by putting the old ID as a provided ID, like so:
```
tld.domain.MyCoolApp

  mycoolapp.desktop

```
Some tools (but not all!) will do the right thing then and merge
external data associated with both IDs.

Since the warning originates from the upstream metainfo file
validator, the message is light on info about what we as a
*distributor* should actually do.
I am very tempted to implement a way to override this particular
message to make it much more clear to Debian developers on what to do
here, or maybe even to potentially hide this particular issue from the
developer dashboard / issue pages (not sure what is better here, the
former feels a bit more honest to do). Do you (Simon, Jeff, Mattia)
have any preferences / ideas on that?

> The AppStream ID and the .desktop filename will usually also need to be
> coordinated. For example, GNOME Builder (package name and executable:
> gnome-builder) ships /usr/share/applications/org.gnome.Builder.desktop,
> which means its freedesktop.org app ID (derived from the .desktop file)
> is "org.gnome.Builder.desktop", and its AppStream ID needs to be either
> "org.gnome.Builder.desktop" or "org.gnome.Builder". (In fact it's the
> latter, so it has /usr/share/metainfo/org.gnome.Builder.appdata.xml.)
>
> Again, any changes to the .desktop filename should happen upstream first.

It was this way in the past, but nowadays AppStream is *way* more
explicit. Older versions of AppStream were a pretty useful hack to
"just get the info we need quickly" and were tailored much more for
being autogenerated data for distributions. Nowadays, with newer
versions, a lot of the magic has been drained from the spec and pretty
much every change should now be explicit, focusing much more on making
metainfo files easy to write and understand by humans.
That means in this case in particular: You can pick literally and rDNS
name for your component that you want, as long as no other app is
using it already. That creates a component that is, initially, not
launchable. This is sometimes desired, for example WINE is a
type=desktop-application GUI application that doesn't have a "main
app" that works on its own

Re: Is it the job of Lintian to push an agenda?

[Matthias Klumpp]

Am Sa., 13. Juli 2019 um 22:04 Uhr schrieb Vincent Bernat :
>
>  ❦ 13 juillet 2019 11:52 -07, Russ Allbery :
>
> >> Previously, we had a sort of agreement (through the TC decision) that
> >> such scripts should be maintained by people caring about them and we
> >> should only act on bug reports with proper patches to have them.
> >
> > I don't agree that this was ever the agreement.
>
> I was referring to
>  but it seems
> it only applies to non-SysV init script, my bad.
>
> I am still unhappy with the situation, but I don't think it is worth
> arguing about it as I am pretty sure it will have no impact whatsoever.

What will have an impact is moving
 forward, I
guess.
Writing init scripts for sysvinit is a massive amount of work for
non-simple cases, and my own software as well as other software
projects don't actually ship sysvinit scripts anymore (simply because
testing them just isn't worth the time and effort if you can actually
achieve what you wanted easier).
While I think it's fair to request from package maintainers to merge
compatibility scripts for sysvinit, forcing them to write sysvinit
scripts while our default init systemd is systemd and where even
testing those scripts is a major pain is IMHO not.
There was a long discussion on not-shipping / dropping sysvinit
scripts in a request to the TC in 2016
, I am
assuming you meant that when talking about a TC ruling. No decision
was made there though, and normal policy processes should resolve
this.
With two Debian stable releases defaulting to systemd now, I think a
solid case could be made to at least relax the "must" requirement to a
"should" in policy (but that should better go to the respective bug
report).

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Re: mandatory source uploads (was: Bits from the Release Team: ride like the wind, Bullseye!)

[Matthias Klumpp]

Am Mo., 8. Juli 2019 um 09:14 Uhr schrieb Thomas Goirand :
>
> On 7/8/19 12:34 AM, Scott Kitterman wrote:
> > As long as your build-depends are properly versioned, why can't you just
> > upload all the source and let wanna-build sort it out?
> >
> > Scott K
>
> This means that I have to baby-sit the Debian archive and upload
> everything in the correct order, waiting for the previous upload to be
> accepted and online.

But why? If the build dependencies are tightened enough so that builds
are run in order anyway, this issue shouldn't occur. If a dependency
isn't built in the correct version yet, the package will just wait
with its build until the dependency does become available.

> BTW, one very important thing: are the buildds configured to use
> incoming at least? If so, that probably could be bearable.

AFAIK they indeed do that.

> []

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Re: Content Rating System in Debian

[Matthias Klumpp]

Am Mi., 26. Juni 2019 um 10:40 Uhr schrieb Bagas Sanjaya :
>
> On 25/06/19 20.19, Matthias Klumpp wrote:
> > [...]
>
> So APT need to do what you mention, that is determining age rating not
> only based on AppStream metadata, but also on system locale?

Yes. Since the things that determine age ratings depend on regional
(!) legislation, varying wildly between different countries or even
within countries, that is the only way.
I am currently working on a plan to centralize the age mapping in
libappstream, but tbh I do not thing that we will ever have a fully
legally sound solution for this without employing a lot of lawyers.
There is just so much stuff to take care of, and so much regional
variation, that a software solution will likely not be able to cover
all cases.

See https://hughsie.github.io/oars/ (which is used in AppStream) for
details. As the intro text says, we rely on people being honest about
things and are purely informational.

Cheers,
Matthias



-- 
I welcome VSRE emails. See http://vsre.info/

Re: Re: Re: Content Rating System in Debian

[Matthias Klumpp]

Am Di., 25. Juni 2019 um 11:51 Uhr schrieb Bagas Sanjaya :
>
> Simon McVittie:
>
> Appstream metadata, which is canonically provided by upstreams and is
> distro- and package-type-agnostic (available in at least apt and Flatpak),
> has this as an optional field for self-rating:
>
> https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-content_rating
> https://hughsie.github.io/oars/
>
> I suspect that's the only way this could possibly work without money
> changing hands.
>
> There are no age classifications, however.
>
> So based on content_rating tag on AppStream metadata, we can add logic to apt 
> in order to determine age rating for our
> packages. However, external review (maintainers) may be need in order to 
> prevent misleading information on
> content_rating.

To clarify: Age ratings vary wildly between countries. So what we
expect is that software centers will not actually display
content_rating information, but instead compile an age rating out of
it based on the user's current location/locale and then display that.
Having a "one-size fits all" generic rating isn't very practical.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Re: Re: Content Rating System in Debian

[Matthias Klumpp]

Am Di., 25. Juni 2019 um 10:15 Uhr schrieb Simon McVittie :
>
> On Tue, 25 Jun 2019 at 09:31:44 +0200, Philip Hands wrote:
> > Also, it seems clear to me that the same game in all Linux disros is
> > very likely to get the same rating, so this would be better done as a
> > distribution agnostic level
>
> Appstream metadata, which is canonically provided by upstreams and is
> distro- and package-type-agnostic (available in at least apt and Flatpak),
> has this as an optional field for self-rating:
>
> https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-content_rating
> https://hughsie.github.io/oars/
>
> I suspect that's the only way this could possibly work without money
> changing hands.

Indeed :-) Also, metainfo files can be written for every software
component, not only for apps (although I thing GUI applications are
the things age-rating is most relevant for).
If any features in this are missing, let me or Richard Hughes know.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Re: Question about Debian build infrastructure

[Matthias Klumpp]

Am Do., 6. Juni 2019 um 20:33 Uhr schrieb Kyle Edwards
:
>
> Hello all,
>
> I have been preparing Ubuntu releases for CMake on our own APT
> repository for several months now. We did this by preparing our own
> repository infrastructure - we have a machine that builds packages, and
> a machine that hosts an Aptly instance and pushes the repository to our
> web server. However, all of these things had a lot of manual steps to
> set up and use, and I'm wondering how Debian handles this problem. Here
> are some of my questions:

Hello! :-)
I am not involved with either the ftpmasters team or the wanna-build
admins, but I did set up infrastructure like this a few times already.
For the last time for the PureOS derivative and for the first time for
the Tanglu derivative where the goal was to explicitly "use what
Debian uses", so I gained quite a bit of insight into the process.
Some information I have may be dated by now though, so please correct
me in these cases.

> 1. What software do the official Debian repositories use? Do they use
> Aptly or reprepro or something else?

The main Debian repositories use dak, the Debian Archive Kit.
You can find more information on it at [1] and get its code on Salsa at [2].
Dak was written specifically for Debian's needs and was in the past
quite Debian-specific with lots of hardcoding of Debianisms (like
suite names) and expectations on the host environment. This has
changed quite a bit in the past few years, and while there are still a
bunch of Debian-hardcoded parts, dak is generally useful for
non-Debian repositories as well.
Its setup is still orders of magnitudes more complex than using
reprepro or Aptly (you will need to write some dedicated scripts for
your distribution), but for huge package repositories it is from my
experience one of the most performant and painless options. You also
gain all the features the Debian archive has instantly.
If your repository is small though, using dak may be overkill - it
really shines if you have thousands of packages, with just a few
reprepro could get the job done easier with less manual work.

> Is there a downloadable OS image which comes with this pre-set up?

No, unfortunately not.

> Does it run on a cron job or does it
> have some sort of continuous monitoring? (We have ours run on a cron
> job every 10 minutes.)

Dak actions are triggered by multiple cronjobs which run different
actions. There is one to process incoming uploads which runs roughly
every 15min, hourly, daily, weekly and monthly cleanup and
statistics-generating actions as well as the "dinstall" task which
will run about 4 times a day and publish new packages in the archive
so users can access them. The dinstall task is actually comprised of
many individual actions, which deal with different aspects of the
archive (e.g. translations and AppStream metadata), so summarizing it
is not that easy.
In order to not have the autobuilder network wait on publication, dak
can maintain special queues for the builders to fetch packages from
prior to them being published officially.

> 2. According to https://wiki.debian.org/BuilddSetup, there seems to be
> a distinction between the build broker (wanna-build) and the build
> workers (buildd). Do either of these roles have their own OS images one
> can download?

AFAIK there are no OS images, but I would bet that the buildd machines
have an Ansible recipe or something similar somewhere, as those are
continuously updated and refreshed. I would strongly advise against
using wanna-build for anything - when I tried to use it in the past
that attempt turned out to be virtually impossible because there was
no documentation on it and it heavily relied on grown structures
within Debian itself. If you dig into it, you will also find some
interesting historical trivia, e.g. apparently in the past an
autobuilder was building a package and then sending the build log to a
developer, which then looked over it, signed it and submitted it back
to get the build actually accepted in the archive.
So, IMHO wanna-build is really not something that should be used in
new projects...

> 3. I understand that source packages are signed by developers before
> being sent to the build farm, but what about the binary packages built
> by the build farm and uploaded to the repository? Do the build farm
> servers have their own GPG keys?

Indeed they have - they sign the package with their own key which is
valid for binary uploads of the builder's respective architecture.

> Does the repository server recognize
> these keys?

Yes, they do - builders are registered with dak as well.

> Thanks in advance, all this info would be helpful for me as I expand
> our Ubuntu build infrastructure.

I don't know how about the scale of your build farm, but if it is a
small-ish amount of packages, using Jenkins+reprepro may be all you
need. For bigger things, I had some success with Debile[3] in the past
which was building all of Tanglu for a while and was used withi

Re: Debian Buster will only be 54% reproducible (while we could be at >90%)

[Matthias Klumpp]

Am Mi., 6. März 2019 um 10:40 Uhr schrieb peter green :
>
> > Because of their design, binNMUs are unreproducible, see #894441 [3] for
> > the details (in short: binNMUs are not what they are ment to be: the source
> > is changed and thrown away)
> To be specific, the source tree is extracted, then an entry is added to 
> debian/changelog and then the package is built. This modified source tree is 
> not retained.
> [...]

(Experience report incoming)

I have once tried that in the Tanglu derivative, and found out that
this wasn't as easy as I initially thought because a lot of packages
run special tools prior to building their sources, e.g. to edit
d/control or to read d/changelog and inject data in several places.
So, the option there was either to create a chroot dedicated to the
source package rebuild (installing all Build-Deps and Pre-Deps prior
to the actual source rebuild), or to not actually rebuild the source
package but just edit the d/changelog file and recreate the tarball.
For Tanglu we went for the "just edit d/changelog and re-tar, re-sign
& upload" which worked fine and without any noticeable issues - this
was mainly due to the limited build power we had at the time. For
Debian, which has a lot more resources, just full rebuilding the
source with all dependencies is likely much cleaner, but this approach
might be a bit slow for huge transitions.

At Ubuntu, some people seem to do this process manually, that is run
some scripts locally, rebuild sources locally & upload (unless that
has changed recently).
In general, having source d/changelog aligned with the actual binaries
produced is a really great goal!

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Re: package management symlink

[Matthias Klumpp]

Am Di., 5. Feb. 2019 um 12:03 Uhr schrieb Ansgar :
>
> Sören Reinecke writes:
> >> I'm not convinced that having to remember different package manager
> >> names is a significant problem for new people adopting a Linux
> >> distribution. The name is a very small part of the
> >> differences between
> >> the package managers (they have very different
> >> behaviour models, not
> >> just names), and the package managers are a small part of all the
> >> differences between distributions.
> >
> > Many developers don't provide their software via a repository instead
> > they provide the source code with an INSTALL file. They depend on
> > dependencies they resolve through the repositories. Approving "nimue"
> > just as symlink that points to the package management system across
> > linux systems would enable them to write just one install script for
> > debian and red hat systems for example.
>
> No, that already stops working when package are named differently which
> is frequently the case.  There is no readline-devel package in Debian
> and no libreadline-dev in Red Had or Gentoo.
> [...]

Additionally to what Ansgar already said, we already have had
PackageKit for ages. Just use the `pkcon` tool to trigger package
installations in a distribution-agnostic way - if you know the names
of the packages you want to install for each distribution, of course.
(for applications and very few software components, AppStream can jump
in as a distro-agnostic way to install software via `appstreamcli
install `.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Re: usrmerge -- plan B?

[Matthias Klumpp]

Am Fr., 23. Nov. 2018 um 14:47 Uhr schrieb Stephan Seitz
:
>
> On Fr, Nov 23, 2018 at 02:04:05 +0100, Matthias Klumpp wrote:
> >If there are actual issues encountered, we can always revert a change
>
> And how do you revert this change? As far as I have understand you can’t
> remove the usrmerge package and have your system in the old state again.

You don't - it's unstable, for testing these things. If it breaks, you
file a bug and fix the system.

> As others in the thread have mentioned they don’t see the risk with new
> installations but with old systems with different admins and third-party
> software.
>
> >anyway. During distribution upgrades there is a lot that can be wrong
> >and a lot of stuff the administrator needs to care about (config file
>
> Right, and it means he has enough to do and doesn’t want to debug the
> usrmerge. I don’t want to have a usrmerge at a dist-upgrade. You don’t
> really know the sequence of the package updates. I think the risk is too
> big to have a partial upgraded system.

For the sequence of installations, the APT maintainers can shed light
on what the proper plan could be to ensure the usrmerge update happens
at the right time.

> >with information to the system administrator on what to do in case of
> >an error, and works for 98% of all users anyway, I see no reason not
>
> If the update of 2% of our systems won’t work because of failing usrmerge
> I would be asked if Debian is the right distribution.

There are always unforseen issues to be expected when upgrading. And
at the moment, the only issues that are known when installing the
usrmerge package is when there are different binaries with the same
name in /bin and /usr/bin (or /sbin), and I really don't think that
this is actually a likely scenario.
For these cases though maybe the usrmerge script could ask the admin
on what to do to handle these particular binaries, instead of failing.

I am not strongly advocating for going down this route and actually
migrating all systems on update, but I do not want us to dismiss that
option because we are scared that something might go wrong without
actually knowing that there are unfixable cases where the update might
inevitably break on older installations. Instead, I would rather want
to try out the migration on a bigger scale - potentially and
temporarily break unstable (with a warning, of course), instead of
discussing over and over again potential issues that might not
actually be real and delaying a useful change because of that.

(TBH, for the buster release not switching the buildds to usrmerge and
keep debootstrap/the installer to install in an usrmerged
configuration and then do the final switch during bullseye seems
sensible and I don't see any issue this would cause. Of course if the
reproducible-builds test turns out that we only need to fix a small
amount of packages to make the usrmerge happen on buildds as well,
switching them as well could make sense still)

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Re: usrmerge -- plan B?

[Matthias Klumpp]

Am Fr., 23. Nov. 2018 um 13:45 Uhr schrieb Ian Jackson
:
> Russ Allbery writes ("Re: usrmerge -- plan B?"):
> > This is a much better summary of the thread, and I wish that you would
> > have said this instead of claiming incorrectly that those same people are
> > the ones advocating for a full merge of all systems.
>
> Marco d'Itri writes ("Re: usrmerge -- plan B?"):
> > If you are seriously concerned with the small issuses caused by the
> > transition to merged-/usr then I have a better proposal.
> > Plan C: just stop supporting non-merged-/usr systems since these
> > problems are caused by having to support both, and there is no real
> > benefit in doing that other than pleasing the few people who are scared
> > by changes.

For this I actually wonder: Why don't we just do that and enforce the
usrmerge on unstable?
I think we are caring too much about the stability of the unstable
suite, and absolutely miss the chance of just running experiments to
gather data on the feasibility of changes.
What we could do in this case is for example to just make the usrmerge
migration mandatory for users of the unstable suite and see what kind
of issues and how many of them users will actually encounter. The
suite is called unstable afterall :-)
If there are actual issues encountered, we can always revert a change
and not have it go into stable, but in any case we will get a lot
better testing on the migration and a lot more data on whether there
actually are any issues.

Since new installations will be usrmerged by default anyway and there
is no reason or easy way to swich back to a split-usr system, I think
the issues related to a split-usr-system will go away in the long run
anyway. During distribution upgrades there is a lot that can be wrong
and a lot of stuff the administrator needs to care about (config file
changes, different featuresets of tools, software being removed from
the archive, ...), so if the usrmerge package has a sensible fallback
with information to the system administrator on what to do in case of
an error, and works for 98% of all users anyway, I see no reason not
to try using it and save us from an eternal transition period or pain
of maintaining two configurations.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Re: usrmerge -- plan B?

[Matthias Klumpp]

Am Mi., 21. Nov. 2018 um 22:51 Uhr schrieb Marco d'Itri :
>
> On Nov 21, Michael Stone  wrote:
>
> > How many long-running production systems do you think people have run
> > usrmerge on? I'd guess close to zero, since there is no advantage whatsoever
> Actually I have quite a lot personally, with exactly zero problems.
> On some of them I also enjoy advantages of merged-/usr, like having
> multiple containers share the same /usr.

Ditto, I did the same with about 8 machines about two weeks ago  with no issues.
It feels to me that there are a lot of people just assuming issues
will happen without data to back it up.
With the reproducible builds testing for changes based on usrmerge vs
non-usrmerge builds now, I hope at least for the "how does changing
the build chroots affect compatibility of built packages" we'll have
reliable data soon.

(At the moment I don't actually see the upcoming doom - a few packages
broke, bugs were fixed, life goes on. If it turns out that we are not
able to cope with new bugs in time, we can always change decisions
later).

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Re: Our build system may be broken: /bin vs /usr/bin

[Matthias Klumpp]

Am Mo., 19. Nov. 2018 um 16:52 Uhr schrieb Dirk Eddelbuettel :
>
>
> Hi Ian,
>
> Thanks for the follow-up.
>
> On 19 November 2018 at 15:45, Ian Jackson wrote:
> | Dirk Eddelbuettel writes ("Our build system may be broken: /bin vs 
> /usr/bin"):
> | > tl;dr:  We may be messing up /bin and /usr/bin on some platforms
> |
> | This is the result of the change of the buildds to have `usrmerge', ie
> | merged /bin and /usr/bin.  I think this shows that this change is
> | generating RC bugs in packages, and should be reverted.
>
> That was very much my gut feel but I am a little removed from the more core
> moving and shaking and I didn't know what changed recently.
>
> FWIW GNU R is an rather obsessively clean user of to the autotools stack, so
> I would agree that it failing here is a good-enough proof for having to
> possibly revisiting things in our stack. I would expect much more breakage to
> follow.

Ideally the build system would correctly detect an usr-merged system
and set paths accordingly. While reverting the change on the build
machines temporarily (e.g. until the next release is out) feels
sensible, depending on how many issues we actually encounter, at some
point we'll have to go through with it. And knowing what actually
fails in this scenario and fixing the affected packages is a good
thing to do.
So, if you have the time, it might be useful to investigate whether
you or upstream can tweak the build system to e.g. explicitly assume a
split-user system even if the system the package is built on is
usr-merged.

I wonder how this was handled on other distributions when they made
the change - even if the change was applied on all systems, there must
have been at least one release where both modes were supported.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Re: no{thing} build profiles

[Matthias Klumpp]

Am Mo., 22. Okt. 2018 um 17:32 Uhr schrieb Marvin Renich :
>
> * Matthias Klumpp  [181021 14:04]:
> > libgpgme is communicating with gnupg in the background - having
> > libgpgme without gnupg itself will render the library completely
> > unusable and break existing users of the library.
>
> This keeps getting repeated in this thread in spite of the fact that
> multiple people have stated that having libgpgme installed without gnupg
> is useful in a very reasonable scenario.
>
> > Also, gnupg/libgpgme are tiny, so you won't waste much disk space
> > here.
>
> See Steve Langasek's reply.
>
> Why are some maintainers so adamant about using Depends when Recommends
> is the correct dependency?
> [...]

Because having a real dependency eliminates another source of bugs.
The library will throw weird (for unexperienced end-users) errors and
they have to hunt down a solution for why something isn't working as
they expect. However, if a dependency relation exists, the package
maintainer can *ensure* that the shipped package is always in a usable
state, preventing end-users from wasting time in figuring out why
something does not work, while only adding the additional cost of
consuming a bit more disk space for people who don't use the feature.

I have seen this happening countless of times. Ensuring the user has a
working configuration and can't accidentally break it is pretty key.
Experienced users will always be able to track issues down in case
modules are missing, but the average user who just installed something
from a software center, will get frustrated and waste time in finding
a solution for their problem.
The "Recommends" relation should work here in theory, in practice
though people manage to remove stuff that was recommended by accident,
or even configure APT to never install recommends, and then end up
with things not working (granted, in the latter case it's their own
fault).

I've seen this when changing the dependency relation of some
PackageKit libraries on the packagekit daemon to a Recommends - that
initially resulted in lots of issues, as the PackageKit libraries
don't do much with their accompanying D-Bus activated daemon. As an
end result, the dependency relations were just shifted from the
library to the tools depending on the library, to ensure users have a
working configuration and don't break their GUI updater.
In this particular case I think a Recommends relation is justified,
because some server software also exists where the admin might not
want PK to be running, as it is first a D-Bus daemon and second an
admin tool to install software.

Due to that experience though I am pretty certain that if someone
removed a vital dependency from a shared library and the software that
uses it receives bug reports from users who can't use the adverties
feature, the maintainer of said software would not hesitate to add
that dependency to the software to ensure it functions properly for
users who need that feature (unless that dependency was very big).

The situation is entirely different though for software that is
designed to be extensible and handles the case of a missing module
gracefully. In that case, a soft dependency is better. In any case, I
think that is up to the maintainer to decide, as they know the
software best and can make sure that it works well for most of its
audience.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Re: no{thing} build profiles

[Matthias Klumpp]

Am So., 21. Okt. 2018 um 18:13 Uhr schrieb Marvin Renich :
>
> * Sune Vuorela  [181021 06:05]:
> > On 2018-10-21, Jonas Smedegaard  wrote:
> > > I disagree that libgpgme11 should depend/recommend/suggest gnupg at all:
> > > As a library it cannot possibly declare how tight a relationship to
> > > declare - instead, all _consumers_ of the library must declare whether
> > > they depend/recommend/suggest gnupg.
> >
> > libgpgme is completely useless without gnupg. I think it is perfectly
> > fine for these kind of relations, unless we really are in corner-case
> > territory. See for example fam.
>
> I strongly agree with Jonas.  Upstream links to libgpgme as a .so to
> provide optional behavior.  This requires libgpgme to be installed in
> order to even run neomutt, whether the user wants the feature or not.
> It is perfectly reasonable to want to install neomutt but want to _not_
> install gnupg.
> [...]

libgpgme is communicating with gnupg in the background - having
libgpgme without gnupg itself will render the library completely
unusable and break existing users of the library.
Therefore, if you have something that wants libgpgme, you will also
always want gnupg installed to ensure the library functionality is
actually provided.

Also, gnupg/libgpgme are tiny, so you won't waste much disk space
here. No daemon gets run in the background as well, so I don't
understand the need to create lots of additional work to free up a
tiny amount of disk space. If you don't need the feature, don't use
it. If you do need the feature, great, it's readily available for you.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#886238: Please introduce official nosystemd build profile

[Matthias Klumpp]

2018-01-07 20:00 GMT+01:00 Hleb Valoshka <375...@gmail.com>:
> On 1/6/18, Chris Lamb  wrote:
>>> > (accusing Debian to "vandalize" open source by supporting systemd)
>> […]
>>> 1) Proofs please. DDG & Google find only your words.
>>
>> I was accused of this on the "dng" mailing list. It should be easy to
>> find the relevant threads.
>
> To be honest there were quite opposite statements as well, weren't
> they? From another Devuan's core team member.
>
> And you were accused because you had removed (broken) functionality
> from sysv script and had reimplemented it but for systemd only.

Well, removing broken functionality is a fair deal. And implementing a
systemd-only version is as well - afterall, it is his decision on how
he spends his time and which usecases he supports. It helps nobody to
have someone write code for a feature they don't actually use (the
result will be bad in any case, due to limited testing).
This situation would have an easy fix though: People who do care about
SysVInit could provide a patch to fix the broken functionality.
Debian lives from collaboration, and if enough people care about a
feature (like SysVInit support) and work on it, that particular
feature will be supported. If on the other hand, no work is done to
keep the feature alive, its codepaths will first deteriorate and after
a while it will be removed entirely.

So, tl;dr and what a lot of people have said before: SysVInit needs
developers interested or paid to work on it to stay alive in Debian.
It also requires users to find and report bugs related to it. A new
build profile will not magically create developers to address SysVInit
issues.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Re: Please add lzip support in the repository

[Matthias Klumpp]

2017-07-03 14:42 GMT+02:00 Maria Bisen :
> [...]
> 4- As a result, lzip is almost never used alone (without xz), and Debian can
> justify forever the lack of lzip support
>
> You need to consider all four points to understand the issue.

No, please read again the mails previous developers wrote. Lzip is
considered if it is widely used, *not* if it is widely used *alone* as
the sole format.
So, if a huge number of projects starts to ship xz and lzip tarballs,
or gz and lzip tarballs, this would already provide a metric for
sufficient upstream interest to support lzip as source package format.

But just like other interated over countless of times, this is a very
long process Debian will not do lightly, nobody is stopping upstreams
from providing only lzip sources (in which case we would just
recompress the tarball at the moment) and lzip is already maintained
in Debian so any user who wants to use it, can use it.

So, lzip isn't adopted widely, that's certainly not because of Debian
or any other Linux distribution.

Cheers,
Matthias

Re: Packaging of libraries with unstable ABI (D, Rust, Go, ...)

[Matthias Klumpp]

2017-05-19 2:35 GMT+02:00 Paul Wise :
> On Thu, May 18, 2017 at 10:37 PM, Matthias Klumpp wrote:
>
>> Unfortunately though, the D language ABI isn't stable, so any future
>> compiler update might break the software in weird ways unless all D
>> software is recompiled when a new compiler is released.
>> To make things worse, D also has three different compilers (which
>> share the same frontend), the GNU D Compiler (GDC), LLVM D Compiler
>> (LDC) and the reference compiler Digital Mars D compiler (DMD).
>> All compilers have different advantages, but they also have
>> incompatible ABI, especially because each comes with a separate
>> version of the D runtime and standard libraries.
>
> Is there any chance of the D community creating a standard ABI that
> will be stable and shared all of the compilers?

There is a chance, and I was pushing rather hard for that, but I don't
think this will happen in the near future. It's also one of these
cases where you ask others to do something for you which has never
been a big issue for them.
For the record, see 
https://forum.dlang.org/post/och4d8$1i1n$1...@digitalmars.com

(Very) long-term, there might be a stable, shared ABI, in the short
term though, that definitely won't be the case.

Re: Packaging of libraries with unstable ABI (D, Rust, Go, ...)

[Matthias Klumpp]

2017-05-18 19:52 GMT+02:00 Sean Whitton :
> Hello Matthias,
>
> On Thu, May 18, 2017 at 04:37:58PM +0200, Matthias Klumpp wrote:
>> Looking at what other languages with the same problem have done, there
>> are basically two ways to deal with the issue:
>>
>>  1) Rebuild every reverse-dependency of the languages' compiler every
>> time the compiler is updated. This is done by Haskell and OCaml and
>> resulted in permanent transition trackers for the libraries.
>>
>>  2) Ship source code instead of libraries in packages, and compile it
>> directly into the target binaries. That way, the maintenance overhead
>> of the languages' packages is greatly reduced, but code is statically
>> linked (boo!) and a lot of code needs to be rebuilt for every
>> dependency (meaning more work for the autobuilders). This is done by
>> Go, and apparently also the plan to do for Rust.
>
> Note that Haskell is statically linked, too.  We rebuild every
> reverse-dependency of every library that changes, not just the compiler.
>
> Are you saying that with D, it's only changes to the compiler that are
> problematic?

No. D can also build shared libraries even. The problem is that you
can only combine libraries and binaries built with the same D compiler
and the same D compiler version.
This results in problems:
If I have an application A that depends on (shared or static) library
B, and we update the D compiler that was used to build both components
initially, and then do an upload of application A, we will get linker
errors. Since A is now built with the newer compiler and B still has
the ABI used with the old D compiler, a mismatch happens.

So, if a new D compiler is made available in the archive, we would
need to ensure all D stuff gets rebuilt in order.
If source code is shipped, the code is only compiled once, so we
wouldn't run in that issue (but doing that is maybe no so nice?).

Cheers,
Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/

Packaging of libraries with unstable ABI (D, Rust, Go, ...)

[Matthias Klumpp]

Hi!
Recently, I have been packaging some libraries written in the D
programming language[1]. Since the D team didn't have many libraries
packaged, there was no policy on how to package libraries, so I
packaged them like C/C++ libraries: Make a shared lib package and have
the software requiring it depend on that.
Unfortunately though, the D language ABI isn't stable, so any future
compiler update might break the software in weird ways unless all D
software is recompiled when a new compiler is released.
To make things worse, D also has three different compilers (which
share the same frontend), the GNU D Compiler (GDC), LLVM D Compiler
(LDC) and the reference compiler Digital Mars D compiler (DMD).
All compilers have different advantages, but they also have
incompatible ABI, especially because each comes with a seperate
version of the D runtime and standard libraries.
So, if we ship a D package containing a shared library compiled with
LDC, there is a high chance that you can't use that with DMD or GDC.
Also, D makes excessive use of template programming, so quite a bit of
code gets embedded into the target executable even if you have shared
libraries.

Looking at what other languages with the same problem have done, there
are basically two ways to deal with the issue:

 1) Rebuild every reverse-dependency of the languages' compiler every
time the compiler is updated. This is done by Haskell and OCaml and
resulted in permanent transition trackers for the libraries.

 2) Ship source code instead of libraries in packages, and compile it
directly into the target binaries. That way, the maintenance overhead
of the languages' packages is greatly reduced, but code is statically
linked (boo!) and a lot of code needs to be rebuilt for every
dependency (meaning more work for the autobuilders). This is done by
Go, and apparently also the plan to do for Rust.

The workflows for packaging we have in Debian are very tailored to
C/C++ packages. So I wonder, for new packages for a programming
language with no ABI stability guarantees, what is the best way to
package libraries?

Also more specifically: If we ship source-code, should the packages
shipping it also build the source code, or should we rely on the
dependencies to build the code and catch issues?
What about very large libraries, or ones which take long to compile?
Should those be always recompiled too, for every dependency, or should
there be exceptions for it?

In general, I am interested in whether we have a "best practices" for
this issue yet, and I would love to hear from people maintaining
Go/Rust/etc. stuff on what works and how this issue should be handled.

Cheers,
Matthias

P.S: The D language authors are aware of the ABI issue, and apparently
there is even come level of compatibility between the GDC and LDC
compilers at least. D also has some rules for how it's ABI should
work, but apparently going the final steps is rather difficult and
given the template-centric nature of D, stabilizing the ABI doesn't
have the highest priority too (it apparently also is impractical in
some cases).
In ay case, ABI compatibility does sometimes work, but we can not rely
on it at all, especially not with multiple compilers.

[1]: https://dlang.org/

-- 
I welcome VSRE emails. See http://vsre.info/

Re: Graphical package installers & debconf (was: What's a safe way to have extensions in chromium in Debian?)

[Matthias Klumpp]

2017-03-23 22:04 GMT+01:00 Sean Whitton :
> Hello Jeremy,
>
> On Thu, Mar 23, 2017 at 07:14:35AM -0400, Jeremy Bicha wrote:
>> It is also useless for someone who will install Chromium from the
>> Software app (gnome-software) included in 'gnome-core' since the
>> Software app does not display debconf prompts.
>
> Do you know if this is a missing feature or a deliberate choice?

This is likely a missing feature, since PackageKit does support
Debconf prompts and GNOME PackageKit does as well. Debconf stuff is
kind of hacked into it though (but given the architecture of Debconf
and PackageKit, there is no better way to do this).
So, I guess someone would need to implement proper Debconf support in
GNOME Software.

Cheers,
Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/

Re: AppStream Re: Depends/Recommends from libraries

[Matthias Klumpp]

2017-03-10 9:05 GMT+01:00 Rebecca N. Palmer :
> On 10/03/17 00:10, Jeremy Bicha wrote:
>>
>> I think a lot of those appstream installs are from KDE and GNOME which
>> install plasma-discover and gnome-software by default.
>
> Do those things display AppStream "packages related to this hardware" by
> default?

I think GNOME Software doesn't, and Plasma Discover only displays them
as regular install-items. A feature like that would be really nice to
have though, it's maybe worth filing a feature request.

>> But beignet-opencli-icd's appstream metadata is invalid [copyleft not
>> allowed].
>
> This was done because parts of the metadata are automatically extracted from
> the (LGPL) code; it's only a warning in 'appstreamcli validate', and the
> people I discussed it with at the time thought it would be OK.

It's a warning because the data isn't completely useless (in case you
don't want to aggregate it, for example), but in general a warning
means a failed validation - to be safe, the data needs to be warning
and error free (exit-code of appstreamcli validate needs to be zero).

Debian's appstream-generator didn't reject metadata with
non-permissive licenses until August 2016 though.

> Upstream have since granted permission for the metadata to be MIT, but too
> late for the freeze.

Nice :-) The license restraints are annoying, but it might keep us
from trouble when mixing data with multiple different licenses in one
file.

>> Also, do you have a link for more information about what
>> beignet-opencl-icd does?
>
> The homepage field of the metadata is set, to
> https://www.freedesktop.org/wiki/Software/Beignet/
>
>

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/

Re: Debian packaging with meson

[Matthias Klumpp]

2017-02-18 0:29 GMT+01:00 Simon McVittie :
> On Fri, 17 Feb 2017 at 18:08:01 -0500, Jeremy Bicha wrote:
>> GNOME 3.24 modules have begun including meson build scripts.
>
> It looks as though Meson approximately follows the Autotools-like
> build pipeline that dh assumes, so something like this should work:
>
> override_dh_auto_clean:
> rm -fr debian/build
>
> override_dh_auto_configure:
> mkdir -p debian/build
> cd debian/build && meson \
> --prefix=/usr \
> ... more options ... \
> CFLAGS="${CFLAGS}" \
> ... more compiler flags ...
> ../..
>
> override_dh_auto_build:
> cd debian/build && ninja -v
>
> override_dh_auto_test:
> cd debian/build && ninja test
>
> override_dh_auto_install:
> cd debian/build && DESTDIR=${CURDIR}/debian/tmp ninja install
>
> (This is all entirely untested and based on what was said in
> .)

I use Meson to build the appstream-generator package:
https://anonscm.debian.org/git/pkg-packagekit/appstream-generator.git/tree/debian/rules
It's really easy to use already, debhelper integration would be pretty
neat though.

Cheers,
Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/

Re: no-strong-digests-in-dsc MBF

[Matthias Klumpp]

2017-01-18 0:14 GMT+01:00 Stuart Prescott :
> Hi Adrian,
>
>> I want to do a MBF for all packages without a SHA256 checksum field
>> in the .dsc [1] - only SHA1 as hash would not be good in stretch.
>
> I missed two details here:
>
> * why is this worth going at all
>
> * why is this important enough for the bugs to be release-critical (which
> means, after all: either drop the package or delay the release).
>
> The hashes inside the .dsc file are not used in Debian once the package has
> been accepted by dak.

I do require them in Debian derivatives (Tanglu / PureOS) and .dsc
files without the up-to-date signatures are quite a pain to handle. I
was already thinking about ways to mitigate this problem without
sacrificing security, but to do so would be quite some effort.
(Admittedly, updating the Debian packages will be too, but that way we
will also filter out unmaintained packages)

IMHO the bugs don't need to be RC, but it would be absolutely amazing
to have the checksums available in .dsc files too. Which means that
this has to be RC at some point (but maybe not directly before the
freeze).

> * The trustable way of getting the source package is with apt-get source,
> when apt verifies the Release signature → hashes → Sources → hashes for each
> part of the source package: dsc, orig.tar.gz, diff.gz/diff.tar.xz

If you mirror Debian's archive into dak again, this becomes a problem,
since dak (for good reason) will not import packages with weak
checksums, so re-importing source packages is a challenge.

> [...]

Cheers,
Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/

Re: opinions of snappy packages

[Matthias Klumpp]

2016-06-19 21:51 GMT+02:00 Zlatan Todoric :
>
> On 06/19/2016 09:12 PM, Raphael Hertzog wrote:
>>
>> [...]
>> This is an annoying habit for many of their projects and it might be a
>> part of the reason why many of their interesting projects do not really
>> take off.
>>
>> $ apt search snapcraft
>> Sorting... Done
>> Full Text Search... Done
>> $ apt show lxd
>> N: Unable to locate package lxd
>> E: No packages found
>>
>> Same for Unity and many other things that I would have tried when they
>> marketed them.

You can at least run Snappy stuff, see the snapd and
ubuntu-core-launcher packages in Debian. Building them doesn't seem to
be possible yet...
(but I haven't tried that)

> Also, comparing to Flatpak I don't see anything why I would choose snappy
> packages (and comparing Libreoffice Flatpak vs Libreoffice snap package is
> insane - I do not want suddenly all Linux packages start using my disk space
> because I just have it - I rather prefer having 10GB of system and 490GB for
> my data than 200GB of system vs 300GB for my data). Also it seems that
> Canonical wants to build central repository from where others should fetch
> snap packages while flatpak is openly distributed among people, distros etc.

I shamelessly advertise my bundling talk at Debconf for that :) One
part of it will be a quick walk through the main differences between
the bundling systems.
The Flatpak bundle would be about the same size as the Snappy one if
you would count the Flatpak runtime accompanying the LibreOffice
bundle. Fortunately, that big runtime is shared by multiple apps.
Limba is an attempt to have a modular runtime and strong validity
checks for bundles to apply a certain policy, but it has been less
popular than Snappy or Flatpak. IMHO Flatpak is a better solution
because it allows at least some sharing of libraries due to its
runtimes, and also allows great diskspace reduction due to its use of
OSTree (which deduplicates data automatically).
Although Snappy seems to have measures in place to reduce the size of
installations as well - I am currently reading up on Snappy, to be
able to comment on it better.
AppImageKit essentially requires you to bundle all the stuff (= huge
size), but it has the advantage of not needing anything installed on
the target system in order to run its applications, compared to all
other bundling systems.

All the bundling systems have their strengths and weaknesses,
unfortunately I think we will need to wait and see which of them will
stick - and ideally make sure upstreams follow some packager's quality
guidelines (hardening flags, correct install locations, maybe
reproducible builds, ...) when creating their bundles.

Cheers,
Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/

Re: Before I send a bug report to change DebTags please do some sanity check

[Matthias Klumpp]

2016-02-08 15:14 GMT+01:00 Ben Hutchings :
> On Mon, 2016-02-08 at 15:10 +0100, Petter Reinholdtsen wrote:
>> [Ben Hutchings]
>> > I don't think it's there yet, but AppStream will get some support from
>> > upstream developers (including through existing .desktop files)
>> > whereas debtags presumably doesn't.
>>
>> It is already possible to search for packages announcing support for
>> MIME types, and the data set is populated with data from the desktop
>> files.  See
>> ;
>> for a recipe.
> [...]
>
> I know that, but full integration would mean prompting the user to
> install a suitable package automatically, e.g. when trying to open an
> email attachment and there is no previously chosen program (or no
> installed program at all) that can handle that MIME type.

GNOME Software can do that, AFAIK - but it will not do that for
non-GUI applications, which is a design decision by GNOME.
So, to get support for this beyond appstreamcli, someone would need to
write a small tool for it. Fortunately, that's really easy and also
very simple to integrate (as long as linking against the AppStream
library or using the GIR is not an issue).
Cheers,
Matthias

Re: Going ahead with non-free-firmware

[Matthias Klumpp]

2016-01-09 21:15 GMT+01:00 Marco d'Itri :
> On Jan 09, Dominic Hargreaves  wrote:
>
>> On Sat, Jan 09, 2016 at 11:51:08AM +0100, Ansgar Burchardt wrote:
>> > I think there was consensus to introduce the non-free-firmware section
>> > and move the non-free firmware blobs there.  I'm wondering what we need
>> > to do next?
>> I applaud this call for action; I'd certainly be an enthusiastic
>> user.
> Me too, it's too bad that it took almost 15 years to reach a consensus
> over what I proposed at the time.

Count me in as well!

>> I think the *policy* for this section should be firmware, as defined
>> as code not executing on the main CPU, or something like that.
> Indeed.

I wonder if we should widen the scope of a "non-free-firmware"
component a little, to "anything non-free you sometimes unfortunately
need to make your hardware usable".
This would mean having a "non-free-hardware" section instead, which
could possibly also include non-free drivers for certain software
components later.
Cheers,
Matthias

Re: overlayfs (was: Re: support for merged /usr in Debian)

[Matthias Klumpp]

I am using overlayFS in Limba[1], and it works well (and is really
fast!) for read-only filesystems, read-write sometimes has issues if
you are using multiple OverlayFS layers (which made me adjust the code
so this doesn't happen anymore).

2016-01-06 17:29 GMT+01:00 Jonathan Dowland :
> I wish I could, but I can't, sorry. All I know is I got mysterious ENOENT
> errors at unpredictable times at some point in the layer stack when using
> it as a docker back-end and developing docker images. I can't recall what
> version of overlayfs/kernel I was using at the time; probably latest RHEL
> 7.* but I'm not sure.

Did you use Linux 4.2 and were maybe hit by this bug:
https://lkml.org/lkml/2015/10/7/289 ?

Cheers,
Matthias

[1]: https://packages.debian.org/sid/limba

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/

Re: AppStream / DEP-11 support now available in the Debian archive

[Matthias Klumpp]

2015-12-15 1:45 GMT+01:00 Charles Plessy :
> Hi Matthias,
>
> congratulation for this release !
>
> In the upstream-metadata project (https://wiki.debian.org/UpstreamMetadata) we
> document some information, some of which is redundant with what is now found 
> in
> AppStream, and some of which is not.
>
> For example, we document bibliographic reference to the scientific litterature
> where a given sofwtware has been published. This particular data has been the
> driving need behind the creation of upstream-metadata project. But the moment,
> I do not have enough free time to take care of the upstream-metadata project
> properly.
>
> Given that the scope of AppStream has grown, do you think that it could be
> further extended to support the kind of information that we distribute in the
> debian/upstream/metadata files ?

Coming from a science background myself, I like this idea very much!
However, we shouldn't add each and every metadata to the AppStream
document, so we would need to go through what the UpstreamMetadata
project offers and see if we can integrate it with AppStream.
The main purpose of AppStream is to provide data to have people decide
if they want to install the software, its secondary purpose is to
contain data which the users might find useful to know when browsing
applications.

I think having a  tag or something similar would be
pretty cool - searching in the AppStream data pool for applications
associated with a publication, or just have the publications at hand
when looking atthe application would be awesome!

Even if there is useful data which we don't include in the AppStream
data, we can probably link it and load it on-demand. I have some ideas
for this for parts of AppStream (like the  tag) already, but
haven't worked out the details - so far, this is just early
experimentation to see whether something like that makes sense.

So, in summary: I'll look at the wiki page to familiarize a bit with
your upstream-metadata project, so I can say something more
meaningful. But I think adding most of the data to the AS metadata
would be a good and viable idea :-)

Cheers & sorry for the delay in replying!
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Re: Future of the Linux upstream tracker

[Matthias Klumpp]

2015-12-06 22:54 GMT+01:00 Ponomarenko Andrey :
> [...]
> But ... Good news everyone! I've spent about a half-year to implement an 
> open-source alternative of the tool from scratch and I'm glad to inform you 
> that it's finally ready and available at: https://github.com/lvc/abi-tracker
>
> So everyone can set up their own ABI tracker for the interested libraries. 
> The reports and architecture of the tool are much better than the old ones. 
> Also I've set up a new small upstream tracker for the core Linux libraries 
> (glibc, openssl, freetype, Qt, etc.) here: http://abi-laboratory.pro/tracker/

This is awesome! Thank you very much for your work!
Cheers,
Matthias

Re: binNMU or reproducible builds (choose only one)

[Matthias Klumpp]

2015-09-27 17:54 GMT+02:00 Paul Wise :
> On Thu, Sep 24, 2015 at 6:09 PM, Henrique de Moraes Holschuh wrote:
>
>> Let's answer that one, and if the answer is "lets drop binNMUs", then we can
>> work towards source-based auto-NMUs being at least as easy to use/trigger as
>> binNMUs currently are.
>
> I guess automated source-NMUs would be useful for automatic rebuilds
> of architecture all binary packages too, which is occasionally needed.

At Tanglu, we can use such a tool, which basically just adds a new
changelog entry to the package (generating a new source package) and
then has dak import it.
This only works with source format 3.0 though (otherwise we would have
to edit a .diff, which is even more ugly), and there could be some
drawbacks of this approach, since a few packages need to run custom
scripts taking the version number in the changelog into account.
So far, we haven't found issues with this, though.
But since not every package is using the 3.0 source package format,
and sometimes it's just easier to do manual uploads to catch
everything, doing sourceful rebuild uploads like in Ubuntu is still
the most common way for us to rebuild things.
Cheers,
Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/

Re: [CTTE #741573] Debian Menu System

[Matthias Klumpp]

2015-09-05 3:49 GMT+02:00 Osamu Aoki :

> [...]
> >2. In addition to those changes, the Technical Committee resolves
> >   that packages providing a .desktop file shall not also provide a
> >   menu file for the same application.
>
> That's good idea in general.  I hope lintian warning should come soon.
>
> This reminds me some DE dependent .desktop file.  Is there any best
> practice how to do it for Debian?  KDE app not showing up on GNOME and
> vice versa.  How to decide how much .desktop data are NotShowIn for what
> environment?
>

In general: Do not use NotShowIn/OnlyShowIn for most applications.
There are only a few areas where it is actually useful, and this is almost
exclusively configuration tools specific to one desktop environment.


> Another question: Is there any list of DE names supporting .desktop
> file?  Whitelisting with "OnlyShowIn" entry requires such list.
>

You mean the list of registered desktop environments?
Take a look at
http://standards.freedesktop.org/menu-spec/menu-spec-latest.html#onlyshowin-registry



> Maybe we shoyld recommend explicit black list using "NotShowIn" entry
> over whitelisting with "OnlyShowIn" entry.
>

Why that? OnlyShowIn makes usually much more sense, but in general it
heavily depends on the case which of the keys makes the most sense.

Cheers,
Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/

Re: Polkit: prompt for root password

[Matthias Klumpp]

2015-09-01 19:49 GMT+02:00 Jayson Willson :

> I have also tried creating
> /usr/share/polkit-1/rules.d/49-rootpw_global.rules with the same contents,
> [...]


The problem with that is simply that the PolicyKit in Debian
Unstable/Testing/Stable does not read the JavaScript rules files.
Only the version using JS-based rules files (in experimental for ages) does
that. So you might want to search for a solution using the old
configuration syntax here.
Cheers,
Matthias

Re: system upgrade by GNOME (was: system upgrade by systemd)

[Matthias Klumpp]

2015-08-31 17:45 GMT+02:00 Russ Allbery :

> Philip Hands  writes:
>
> > Is it not the case that we're actually witnessing is:
>
> >   Option e): get updates applied only at reboot, with no prior
> >   notification that they are available, such that people who always
> >   suspend, or simply leave systems running all the time get no updates
> >   until something bad happens, and they suffer a forced reboot.
>
> >   Consequences: Unexpected changes of behaviour which will give a false
> >   impression of being caused by reboots, leading to the impression that
> >   Debian cannot be trusted to maintain behaviour between boots.  Often
> >   out of date system.  Corrosive loss of user confidence, since they'll
> >   feel like they're not in charge A steady trickle of irrelevant bugs.
>
> That this would happen with no prior notification or user approval is
> absolutely a bug, which I believe everyone involved in this thread has
> agreed about.  I think I saw a message go by indicating that the bug was
> already located and fixed.
>

Yes, offline-installations in GNOME happen only if the user explicitly
triggers that.
And since this functionality is triggered by things high up in the stack,
removing PackageKit is not really a great idea (since this will also
prevent you from ever installing online-updates using a GUI).
Instead, just disable the feature.


> Can we take a step back here and figure out what we're still arguing
> about?  I'm wondering if we may all be in vigorous agreement, except for
> some disagreement over whether we like the GNOME UI for asking the user
> whether they want this behavior.
>

The current issue seems to be the downloading of updates in the background,
which indeed could become expensive.
I am a very strong opponent of the ask-user-about-each-and-everything
approach. I don't think our users are idiots, but I do thing the system is
there to serve the users and stay in the background as much as possible,
which includes not nagging with questions but instead picking sane defaults
which are suitable for most users.
The so-called power-users can still configure the system to their liking,
while the average user doesn't need to care about all the technical details
happening in the background.

That being said, I think showing the user that updates are being downloaded
in the background with a nice explanation and an option to turn the
(default-on) behavior off in the firstrun GNOME welcome dialog does make
sense.
I can raise this upstream, if that hasn't been done already, and see what
happens.


> [...]
> In particular, I think it's been pretty well-established in this thread
> that the only involvement systemd has in the whole affair is making
> available a mechanism for upgrade on reboot that GNOME is (so far as I'm
> aware) the only consumer of, thus making the subject line a bit
> misleading.  I'm happy to let the systemd packagers decide whether it
> makes sense to package that with systemd or separately; any bugs of
> sufficient urgency to warrant a debate on debian-devel seem, to me at
> least, to be in whatever makes use of that infrastructure without giving
> the user enough advanced warning.  Which, to repeat, appear to have
> already been identified and fixed?


You are correct with that - although technically this is a feature of
PackageKit, which did receive some support in systemd and Plymouth to work.
And again, it needs to be explicitly triggered by some component, and you
can even use PolicyKit to restrict access to the methods triggering this
even further.
Currently, only GNOME-Software makes use of this, while you can continue to
use GNOME-PackageKit for doing online updates just as well.

One thing which really helps is interacting with upstream on this: We can
complain loudly on debian-devel, nothing will change unless someone will
actually write the code to implement a different solution or configuration
option and takes that upstream.

Cheers,
Matthias

Re: system upgrade by systemd

[Matthias Klumpp]

2015-08-28 6:03 GMT+02:00 Michael Meskes :

> > Having just read this entire thread, and been affected by this once, it
> > occurs to me that the likely answer has been offered, but I suspect you
> > may have thought Matthias' reference to “GNOME Software” to be a generic
> > answer (apologies if I'm wrong). But in fact the name of the relevant
>
> No, you're absolutely right.
>

:D Sorry, it never occurred to me that this was an ambiguous statement.

Anyway, the issue you encountered was highly likely bug #797138 which is
already fixed in case you have PackageKit 1.0.8 installed.
So, this problem is resolved now and was a bug, not intended behavior.
Cheers,
Matthias

Re: system upgrade by systemd

[Matthias Klumpp]

2015-08-26 15:17 GMT+02:00 Michael Biebl :

> Am 26.08.2015 um 14:48 schrieb Matthias Klumpp:
> > Actually, this query:
> >
> http://codesearch.debian.net/perpackage-results/trigger-offline-update%20-package%3Apackagekit%20-package%3Aaptdaemon/2/page_0
> > is more complete, and shows that likely gnome-settings-daemon would
> trigger
> > this.
>
> Are you sure? "apt-file search /usr/libexec/pk-trigger-offline-update"
> doesn't yield any results.
>

Correct, because there is no /usr/libexec in Debian - the file is in
/usr/lib/packagekit. So we have the opposite issue here, that g-s-d can't
trigger an offline update at all.
We should probably fix this upstream at GNOME and make the path
configurable, or fix this at Debian.

So, this pretty much leaves me clueless on what triggered this - unless
Michael Meskes simply overlooked the "Install updates" checkbox when
shutting down the system...
There is actually no code anywhere triggering an offline update without
user interaction at time...

-- 
I welcome VSRE emails. See http://vsre.info/

Re: system upgrade by systemd

[Matthias Klumpp]

2015-08-26 14:40 GMT+02:00 Matthias Klumpp :

> 2015-08-26 14:27 GMT+02:00 Michael Meskes :
>
>> On Wed, Aug 26, 2015 at 01:26:13PM +0200, Matthias Klumpp wrote:
>> > 1) This feature is not enabled by default. It only gets triggered if a
>> > frontend tool makes use of it, and will not be activated automatically.
>> So,
>> > you will only see it when you use GNOME with GNOME-Software or any other
>> > tool which triggers the functionality. Also, if it triggers the offline
>>
>> And if whatever GNOME software that is triggers the feature by default it
>> is
>> enabled. Nobody is trying to blame any single package AFAICT, we're
>> trying to
>> find out which one enables a (anti-)feature by default that it shouldn't.
>>
>
> According to
> http://codesearch.debian.net/results/org.freedesktop.packagekit.trigger-offline-update%20-package%3Apackagekit%20-package%3Aaptdaemon/page_0
> , the only tools triggering this are GNOME-Software and GNOME-Shell. For GS
> we have #787485 <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787485>
> (which complains about always needing to restart for updating only, not
> about this being triggered).
>

Actually, this query:
http://codesearch.debian.net/perpackage-results/trigger-offline-update%20-package%3Apackagekit%20-package%3Aaptdaemon/2/page_0
is more complete, and shows that likely gnome-settings-daemon would trigger
this.

-- 
I welcome VSRE emails. See http://vsre.info/

Re: system upgrade by systemd

[Matthias Klumpp]

2015-08-26 14:27 GMT+02:00 Michael Meskes :

> On Wed, Aug 26, 2015 at 01:26:13PM +0200, Matthias Klumpp wrote:
> > 1) This feature is not enabled by default. It only gets triggered if a
> > frontend tool makes use of it, and will not be activated automatically.
> So,
> > you will only see it when you use GNOME with GNOME-Software or any other
> > tool which triggers the functionality. Also, if it triggers the offline
>
> And if whatever GNOME software that is triggers the feature by default it
> is
> enabled. Nobody is trying to blame any single package AFAICT, we're trying
> to
> find out which one enables a (anti-)feature by default that it shouldn't.
>

According to
http://codesearch.debian.net/results/org.freedesktop.packagekit.trigger-offline-update%20-package%3Apackagekit%20-package%3Aaptdaemon/page_0
, the only tools triggering this are GNOME-Software and GNOME-Shell. For GS
we have #787485 <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787485>
(which complains about always needing to restart for updating only, not
about this being triggered).



> > update, you will have chosen to do that by clicking the "Reboot and
> > Restart" button.
>
> Eh? This neither makes sense nor is it true. A "Reboot and Restart" button
> (if such a thing existed, could this be a typo?) would not give you any
> hint
> whatsoever that the reboot process will perform updates. And besides, I
> completely switched off my system and started it again later, when that
> dreaded updated kicked in.
>

Jup, sorry, that was a typo. It's called something like "Restart & Install
updates"



> > 2) I tried to reproduce the behavior of getting offline-updates by only
> > installing PackageKit in a clean Sid VM. Everything was behaving as
> > expected, no offline-upgrade was triggered without a frontend tool
> > requesting it. So, there is something really strange happening on your
> > system to trigger this - more feedback would be welcome. It could be that
> > GNOME-Software was installed, has triggered the upgrade once and the file
> > triggering the upgrade has just not been removed, so the machine will
> > endlessly try to upgrade. Although, this should actually never happen,
> and
> > I would be very suprised if it does.
>
> No, the file has not been there. I've had the problem before and checked
> for
> it after the first incident.
>

Strange - then the install-updates mode should not have been entered in the
first place.


> [...]
> > 4) The offline-uügrade failing is definitively a bug, but:
> >
> > 2015-08-26 10:44 GMT+02:00 Andreas Tscharner :
> >
> > > No, I think it's the GCC 5 and the corresponding ABI update that causes
> > > this. aptitude proposed to remove 64 packages yesterday...
> > >
> >
> > Since PK is not doing anything special and is just calling Apt to do
> > things, any removal done by it is highly likely related to our GCC
> > transition taking place. So at time, it's a good idea to perform updates
> > manually.
>
> Ha ha ha. I wouldn't have started this thread if I had wanted my system to
> perform updates automatically. Statements like this are not exactly
> helping.
>
> > To not trigger offline-upgrades, ensure that the file "/system-update"
> does
> > not exist. (this file will only be created when some other tool triggers
> > offline-upgrades).
>
> Are you seriously suggesting I should check for that file *every* time I
> reboot?
>

Nope, but checking if it appears while you don't want to execute
offline-updates would help, because then we would be certain that something
is triggering the update.

Cheers,
Matthias

Re: system upgrade by systemd

[Matthias Klumpp]

Calm down, people...

A few more clarifications:

1) This feature is not enabled by default. It only gets triggered if a
frontend tool makes use of it, and will not be activated automatically. So,
you will only see it when you use GNOME with GNOME-Software or any other
tool which triggers the functionality. Also, if it triggers the offline
update, you will have chosen to do that by clicking the "Reboot and
Restart" button.

2) I tried to reproduce the behavior of getting offline-updates by only
installing PackageKit in a clean Sid VM. Everything was behaving as
expected, no offline-upgrade was triggered without a frontend tool
requesting it. So, there is something really strange happening on your
system to trigger this - more feedback would be welcome. It could be that
GNOME-Software was installed, has triggered the upgrade once and the file
triggering the upgrade has just not been removed, so the machine will
endlessly try to upgrade. Although, this should actually never happen, and
I would be very suprised if it does.

3) If you want to complain, complain at GNOME for making this the default
behavior for updating software. The lower layers are really not to blame
here for executing a request from other tools.

4) The offline-uügrade failing is definitively a bug, but:

2015-08-26 10:44 GMT+02:00 Andreas Tscharner :

> No, I think it's the GCC 5 and the corresponding ABI update that causes
> this. aptitude proposed to remove 64 packages yesterday...
>

Since PK is not doing anything special and is just calling Apt to do
things, any removal done by it is highly likely related to our GCC
transition taking place. So at time, it's a good idea to perform updates
manually.
To not trigger offline-upgrades, ensure that the file "/system-update" does
not exist. (this file will only be created when some other tool triggers
offline-upgrades).

Cheers,
Matthias

Re: system upgrade by systemd

[Matthias Klumpp]

2015-08-25 23:53 GMT+02:00 Simon McVittie :

> On 25/08/15 16:18, Michael Meskes wrote:
> > And for the second time it
> > destroyed my system by deinstalling a lot of packages, instead of
> putting the
> > conflicting packages on hold.
>
> That's the major issue here: packagekit and/or gnome-software (I'm not
> sure which of them is the relevant part here, most likely PK) doesn't
> understand apt holds,


PK does understand apt holds - only Aptitude doesn't set them correctly,
see bug #683099

and the problem resolver that gets used is too
> willing to remove packages. It would work fine for stable-updates, and
> probably OK for testing most of the time, but unstable gets transient
> uninstallability too often (particularly now!) for an approach that
> simple to work


PackageKit uses the very same resolver as apt itself does...
A log file of what actually happened would be very helpful here, to
determine the problem causing the package removal.

-- 
I welcome VSRE emails. See http://vsre.info/

Re: system upgrade by systemd

[Matthias Klumpp]

This is a feature of systemd and PackageKit.
See http://www.freedesktop.org/wiki/Software/systemd/SystemUpdates/

The only thing which makes use of this feature is GNOME through
GNOME-Software, so if you don't want this, removing GNOME-Software will be
enough.
Nothing else in Debian uses this[1].

Cheers,
Matthias

P.S: A log file on why the update failed would be very helpful though,
because even if you don't use it, the functionality should be usable for
those who want to use it.


[1]: I know that thanks to codesearch

Re: Bug#791857: ITP: daemonize -- tool to run a command as a daemon

[Matthias Klumpp]

2015-07-09 19:25 GMT+02:00 Clint Byrum :
> Excerpts from md's message of 2015-07-09 10:18:50 -0700:
>> On Jul 09, Martín Ferrari  wrote:
>>
>> > I can say that it does: start-stop-daemon misses some functionality you
>> > need for programs that don't daemonise and log to stdout/stderr, which
>> > is something I needed only last week. Having said that, I think that
>> This looks like a job for systemd.
>>
>
> Yes, all problems are just nails for that hammer!

Systemd does starting/stopping and managing services very well.
The tool you want to use in this case is systemd-run, which starts a
transient service for the command you want to run in the background.
Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/


--
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/caknhny8fd4hbr76bfw2yxq+hkxp69v5fydwweb7bxdzybds...@mail.gmail.com

Re: aptitude has Priority: standard, why?

[Matthias Klumpp]

2015-03-31 15:18 GMT+02:00 Henrique de Moraes Holschuh :
> On Tue, Mar 31, 2015, at 05:14, Fabian Greffrath wrote:
>> I am curious why the aptitude package still has Priority: standard, i.e.
>> why it is installed next to apt in each and every Debian installation?
>>
>> Aptitude isn't recommended for dist-upgrading since Lenny, I think.
>>
>> Do we really need to have two CLI package management tools installed, is
>> this reasonable?
>
> Well, aptitude IS the CLI package manager.  As far as I know, it is also the 
> most complete and advanced package manager Debian has.  Make no mistake: 
> aptitude is the Debian package manager you should be using if you can deal 
> with text mode and the command line.
>

My main problem with Aptitude is that it currently has a lot of bugs
and does not follow some Apt policy and instead rolls its own, for
example see bug #683099, which I consider really important to resolve.
Currently, there seems to be some trouble in the Aptitude development
team, and to be fair, I can't really blame a small team of volunteers
for bugs (which are even tagged "help" now...).
But with the new "apt" tool available in Jessie, I think it is sound
to raise the question whether we need apt, aptitude and apt-* all in
the standard set, and if there is a recommendation which tool should
be used by default (or if there should be none at all).

IMHO the "apt" tool is already close to optimal, although I am missing
a few features at time (which will probably be added later).
Cheers,
Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/


--
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/caknhny9h3c_xfbslwmt+fxg4wfnny-3m2cwo5dnyjefbcqh...@mail.gmail.com

Bug#779383: ITP: limba -- 3rd-party software manager

[Matthias Klumpp]

Package: wnpp
Severity: wishlist
Owner: Matthias Klumpp 

* Package name: limba
  Version : 0.4.0
  Upstream Author : Matthias Klumpp 
* URL : http://people.freedesktop.org/~mak/limba/
* License : LGPL-2.1+ and GPL-2+
  Programming Lang: C
  Description : 3rd-party software manager

Limba allows 3rd-party developers to easily distribute their software on
multiple Linux distributions while keeping the amount of testing needed for the
different platforms minimal.
It uses modern Linux kernel features to isolate the software components from
the main system.


-- 
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/20150227224657.19295.31729.reportbug@sirius

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

[Matthias Klumpp]

2015-02-17 13:57 GMT+01:00 Alastair McKinstry :
> [...]
>
> Examination after the fact showed that if I'd had the correct packages
> installed, it would have worked.
> So from a Debian perspective this was 'notabug'.
> (modules that were not needed day-to-day had been deleted by hand to
> make space on /.
> A broken initrd was then built during dist-upgrade. My fault).
>
> But this didn't change the user experience: a system broke badly during
> systemd upgrade due to local changes. A blaming exercise of "your own
> fault for doing X" and "you should have known Y"  doesn't change the
> fact that systemd changes are so comprehensive and all-invasive that
> systemd works well for two groups:

With that argumentation, we could not make any changes to Debian
anymore, because users could do any arbitrary change which could break
upgrade, e.g. removing stuff from /sbin manually etc.
If you perform invasive changes on your system, and then do a Debian
upgrade, you should be able to handle the upgrade and take additional
care to make the upgrade work properly with your local changes.

> either 'simple users' who make no changes to the standard
> configurations, or full systemd developers who know the detailed changes
> that it makes in all areas and the consequences for their computers.
>
> Users who make a few local changes to their system, not simple
> configuration changes but code / scripting
> changes of their own, now live in trepidation to what systemd will do.

That's not systemd-specific. If you make bigger invasive changes, I
would expect you to *know* what you are doing and be able to handle
the consequences of the changes. There is no way we can account for
random changes in Debian packaging.

> Its no longer enough to run a "standard Debian + a unique firewall whose
> design I made and know well"
> now live in trepidation, not sure what systemd changes will come next.

Everything is changing constantly :-) And systemd does have migration
paths in case stuff is changed. But again, this particular "I don't
know what change will be next" issue is not specific to systemd -
Debian itself might introduce new default packages at any time, or
perform large transitions like the multiarch-transition, which break
your assumptions on how stuff usually was (in that example, libraries
suddently being installed into /usr/lib/).

> Most components in Linux are small, self-contained, concisely
> documented. Not so for systemd.

That's a false assumption. Systemd consists of small, well-documented
tools which happen to be shipped in one tarball and are designed to
work together and work together well.
Just take a look at the contants of the "systemd" Debian package ;-)

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/


-- 
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/CAKNHny8PoSv00nbqHbX0jNpob2tOUOTb80AYrYr=lyuusfp...@mail.gmail.com

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

[Matthias Klumpp]

2015-02-16 16:26 GMT+01:00 Alastair McKinstry :
> [...]
> An an example, i've been a long-term linux developer, DD; i've developed
> and promoted Linux not just on the desktop but both in embedded systems
> and in HPC systems. In all these I've been comfortable that I've been
> able to adapt Linux, reconfigure, do what was needed to get it going on
> any size of device, and get my changes either accepted upstream,
> maintain them locally in my organisation or both. With systemd I don't
> think I could do that, and thats very disempowering.

Why do you think you can't do that anymore? Systemd is used on
embedded devices, reaching from the Jolla smartphone to things like
the Vocore or Raspberry Pi.
Getting changes accepted upstream is also not a hard thing, systemd is
not different from any other upstream we have. Suure, there will be
patches which are not in-scope, some will receive criticism, need to
be adapted and rewritten, but that happens basically everywhere.
For projects using systemd features, adapting them to do what you want
also shouldn't be a problem, and the systemd unit files (from the
initsystem part of it) can easily be changed and overridden to serve
custom needs.
So, do you have concrete bad experience? If so, working on that and
fixing the associated bugs would be a useful thing to do.

> [...]

Cheers,
Matthias

P.S: Does this really have to be crossposted to -user and -devel?


-- 
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/caknhny9+39n7vcxqmzsfr_fek9ydom3p2hj10gsr7dabed-...@mail.gmail.com

Re: length of a package extended description

[Matthias Klumpp]

2015-01-10 4:31 GMT+01:00 Russ Allbery :
> Don Armstrong  writes:
>
>> It would probably be ideal if there was a better way of indicating which
>> latex modules were in each texlive package than currently, but until a
>> better method is found, this is probably the best of bad options.
>
> +1.  I cannot overstate how useful it is to have this sort of thing appear
> in a field searchable by apt-cache.
>
> We have enough packages with this issue that maybe it would be worth
> designing some other way to allow this, but until then, please keep the
> lists in packages like this or firmware-linux-nonfree so that apt-cache
> search can find the right package.  And having at least *some* description
> for humans to view with a pager and forward search is really nice.

A possible solution designed for this kind of issue could be DEP-11[1].
Unfortunately, not even the AppStream part of this thing is ready yet,
but I am certain that we will have it for Stretch.
(and can then extend it for useful usecases)

[1]: https://wiki.debian.org/DEP-11

-- 
I welcome VSRE emails. See http://vsre.info/


-- 
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/CAKNHny8iX8WzgLW=2_xppovrvke3stjq477bdjvanpj-yjt...@mail.gmail.com

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

[Matthias Klumpp]

2014-11-29 22:25 GMT+01:00 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).

It never was a democracy - it was and is a meritocracy, described as
"the reign of knowledge"[1].
And we are going quite well with that.

[1]: 
http://debian-handbook.info/browse/wheezy/sect.debian-internals.html#idp5715200


-- 
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/caknhny9tvwok2yyutyjmokta+yh+uyk0sga8dralf8gjzmi...@mail.gmail.com

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

[Matthias Klumpp]

2014-11-28 23:29 GMT+01:00 Adam Borowski :
> On Fri, Nov 28, 2014 at 10:36:22PM +0100, Olav Vitters wrote:
>> On Fri, Nov 28, 2014 at 10:21:48PM +0100, Marc Haber wrote:
>> > Is that as "easy" as running current GNOME without systemd, which is
>> > surely possible?
>>
>> Much easier. Note that if you want GNOME without systemd, it required
>> actual effort instead of doing petty jabs on mailing lists. Actual
>> effort was done amongst others the developers of systemd-shim. Currently
>> not having systemd and use GNOME is quite easy on Debian.
>
> Uh?
> gnome-settings-daemon → libpam-systemd → systemd
>
> (There's more to systemd than just pid 1.)

I think he meant systemd, the PID 1 specifically here.
As for the other parts: You couldn't have GNOME without ConsoleKit or
GTK+ before either...


--
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/caknhny9qf1kuvn1o6jhafxrdrgbjsq344nrv37tdmauw7se...@mail.gmail.com

Re: systemd, fstab, noauto and nofail

[Matthias Klumpp]

2014-11-22 22:10 GMT+01:00 Simon McVittie :
> On 22/11/14 19:54, Matthias Klumpp wrote:
>> (Maybe systemd has smarter methods for that case which I don't know of)
>
> I think RequiresMountsFor is what you're looking for.
>
> ConditionFileExists is not the right thing here: the Condition* family
> more or less means "if the condition is absent, behave as if all the
> Exec* were /bin/true". It's a way to do things like skipping a one-time
> initialization unit if a flag-file exists, or skipping a virtualization
> helper unless systemd is running inside the appropriate technology, or
> whatever.
>
> RequiresMountsFor means "however desirable it might be, this unit isn't
> going to work unless the mountpoint ancestors of all these paths exist".

That is very good to know, thank you! (I fortunately used the "wrong"
solution only temporarily to debug a startup issue)
Looks like nothing speaks against starting ssh as early as possible on
systemd systems then.


-- 
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/caknhny_riynrkjffuuoho9avm8o8gbdzookqe7rtjpt2nup...@mail.gmail.com

Re: systemd, fstab, noauto and nofail

[Matthias Klumpp]

2014-11-22 20:30 GMT+01:00 Russ Allbery :
> Jonas Smedegaard  writes:
>> Quoting Russ Allbery (2014-11-22 18:01:12)
>
>>> I also like the idea of not having ssh depend on all local file systems
>>> to be mounted.  I think it's going to be pretty rare to have a system
>>> that has /lib and /etc mounted but can't start ssh.  In theory, that's
>>> possible with a split / and /usr, but as we've discussed in other
>>> threads, that's an extremely unusual configuration these days.
>
>> It surprises me that it is considered "extremely unusual": It is an
>> option offered in stable debian-installer without any advanced trickery
>> (just select LVM and pick the last option) - I quite commonly use that,
>> and would be surprised if I am alone in that.
>
> Sorry, I didn't express that very well.  I know that people do partition /
> and /usr separately; what I was going to say and then didn't is that the
> *error* case is extremely unusual.  In other words, if you can mount /,
> you're probably going to be able to mount /usr, because it's generally on
> the same disk.
>
> What's extremely unusual is a local / and a network-mounted /usr, or other
> sorts of split situations where it's at all likely that mounting / would
> succeed but mounting /usr would fail.
>
> The question, though, is can we express this requirement properly?  We do
> need to make sure that /usr is mounted before ssh is started, but we don't
> really want to wait for mounting all the random other file systems that
> someone might have.
I did that once by just creating a ConditionFileExists on a file in
/usr. It's a pretty dumb workaround, but it worked...
(Maybe systemd has smarter methods for that case which I don't know of)


-- 
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/caknhny-zwtwydawvo5ecdoapgvfxjggxp-2xy+tk46hhbde...@mail.gmail.com

Re: systemd breaking display manager - no way to force?

[Matthias Klumpp]

2014-11-22 2:53 GMT+01:00 Norbert Preining :
> Hi Andrei,
>
>> - purge lxdm (remove might do it as well, but just for good measure)
>> - reconfigure lightdm (to make sure display-manager.service symlink
>>   points to lightdm.service)
>
> Yes, indeed, there is a bug in the service file shipped by lxdm
> which breaks all other dms. Removing and hand adjusting the
> display-manager.service helped.
>
> Still, my question is open:
>
>> > Is there *any* way to *force* systemd to start lightdm ...?
>
> I mean, it seems there is no way to override what systemd believes
> is correct.
You can always drop an override unit into /etc to fix the (wrong)
assumptions made in an unit file.
It's not different compared to editing a sysvinit script to do what you want ;-)
For the "File exists" message, it would indeed be nicer to get a bit
more details there, without having to look into the service file.

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/


-- 
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/caknhny9kscajzxba35zg19bqrrnwtdglum9jujz28y2hqrk...@mail.gmail.com

Re: init system policy

[Matthias Klumpp]

2014-11-20 17:44 GMT+01:00 Jonas Smedegaard :
> Quoting Matthias Klumpp (2014-11-20 17:15:50)
>> 2014-11-20 16:12 GMT+01:00 Jonas Smedegaard :
>> > Quoting Vincent Danjean (2014-11-20 14:25:59)
>> >>   Hi,
>> >>
>> >> On 18/11/2014 18:36, Ansgar Burchardt wrote:
>> >> > With systemd you can ship a default configuration in
>> >> > /lib/systemd/system and administrators can override specific options,
>> >> > for example:
>> >> >
>> >> > +---
>> >> > | [Unit]
>> >> > | Description=Some Helpful Description
>> >> > | Documentation=man:minidlda(1)
>> >> > |
>> >> > | [Service]
>> >> > | User=minidlda
>> >> > | ExecStart=/usr/sbin/minidldad -S
>> >> > +---[ /lib/systemd/system/minidlda.service ]
>> >> >
>> >> > Then an admin can override the entire file by writing his own
>> >> > /etc/systemd/system/minidlda.service or only override specific settings:
>> >> >
>> >> > +---
>> >> > | [Service]
>> >> > | User=some-other-user
>> >> > +---[ /etc/systemd/system/miniblda.service.d/user.conf ]
>> >>
>> >>   I did not know that. It is very interesting.
>> >>
>> >> But, is there a way to be notified at upgrade time that the system
>> >> service file has been modified when there is local (partial or full)
>> >> changes ?
>> >
>> > I was wondering the same.
>> At least for the systemd-case, you can easily notice changes using the
>> systemd-delta command:
>>  $> systemd-delta --diff
>> This will list all overrides and the differences in case something has
>> changed.
>
> Thanks.  Sounds like only a diff between system-provided and
> sysadmin-overrided config, however: That might help for the latter part
> of the question - notify only when system service file is overridden
> locally (by suppressing notification if systemd-deta is empty).
>
> How to do first part of the question - be notified with a diff between
> old versus new _effective_ config when a package update changes a system
> service file?
I don't now of any tool which does that yet - but it shouldn't be hard
to write one that does it (maybe we could even run that by default if
a package touches a vendor-supplied configuration in /lib).
It would just be comparing checksums before and after installation of
a package, and then point the sysadmin at the changed file.

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/


-- 
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/caknhny_n20kjy4rmk3ekkjrr8nz2qnxekki3grfcldcotx9...@mail.gmail.com

Re: init system policy

[Matthias Klumpp]

2014-11-20 16:12 GMT+01:00 Jonas Smedegaard :
> Quoting Vincent Danjean (2014-11-20 14:25:59)
>>   Hi,
>>
>> On 18/11/2014 18:36, Ansgar Burchardt wrote:
>> > With systemd you can ship a default configuration in
>> > /lib/systemd/system and administrators can override specific options,
>> > for example:
>> >
>> > +---
>> > | [Unit]
>> > | Description=Some Helpful Description
>> > | Documentation=man:minidlda(1)
>> > |
>> > | [Service]
>> > | User=minidlda
>> > | ExecStart=/usr/sbin/minidldad -S
>> > +---[ /lib/systemd/system/minidlda.service ]
>> >
>> > Then an admin can override the entire file by writing his own
>> > /etc/systemd/system/minidlda.service or only override specific settings:
>> >
>> > +---
>> > | [Service]
>> > | User=some-other-user
>> > +---[ /etc/systemd/system/miniblda.service.d/user.conf ]
>>
>>   I did not know that. It is very interesting.
>>
>> But, is there a way to be notified at upgrade time that the system
>> service file has been modified when there is local (partial or full)
>> changes ?
>
> I was wondering the same.
At least for the systemd-case, you can easily notice changes using the
systemd-delta command:
 $> systemd-delta --diff
This will list all overrides and the differences in case something has changed.
Cheers,
Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/


-- 
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/CAKNHny_YoFgcKTOY1d0BqobqoG8cG0XXw9nBj-B56efwCDR=a...@mail.gmail.com

Re: Being part of a community and behaving

[Matthias Klumpp]

2014-11-13 22:56 GMT+01:00 Patrick Ouellette :
> On Thu, Nov 13, 2014 at 01:39:52PM -0800, Russ Allbery wrote:
>> Patrick Ouellette  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).
>>
>
> By making it the new default, and causing apt-get dist-upgrade to install
> systemd (which is what happened to one of my systems) in place of sysvinit
> we most certainly are.  Did the system implode in a fiery pool - no, but I
> was forced to deal with the unexpected aftermath. There was some breakage,
> and some things did not work as expected.  (Sure, people would say
> I shouldn't be following unstable or SID but then I wouldn't have development
> environments.)
When upgrading your OS, you should *always* expect that you might have
to learn things - systemd is just one detail, but a lot of other
applications have changes too which force people to re-learn things
they took for granted before. So nothing new here...

> By not having a meta-package "init-system" provided by an actual package,
> we are forcing anyone who upgrades to also change init systems unless they
> take special precautions to not do so.
Previously on Debian, you didn't have any choice in init-systems:
Sysvinit was the only option.
Now, we provide a "init" metapackage, which ensures an init system is
installed. We make systemd default here and switch older installations
over to it currently. If you want to stick with a different
initsystem, you have the *choice* to choose any other one the "init"
package depends on, and even pre-select it on upgrade.
This should pretty much make everyone happy, those who care about
which PID1 they are running, and those who don't.

> For the record, I really don't care about the init system per-say.  I am
> more annoyed with the systemd insistence on logging to binary files than
> anything.  Log files should be plain text.
Rsyslog is srill installed by default (and I guess that won't change
soon), so you now have even better textlogs.
The binary logs are great for quick searching (just run systemctl
status on a service) and provide some extra benefits for working with
logs (I, for example, love the ability to group entries by priority),
but that's not something someone is forced to work with.

Cheers,
Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/


-- 
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/CAKNHny9B14=d9djbcoxn6a_8ex-a06g0hspgsct9zmprgxe...@mail.gmail.com

Bug#768471: ITP: pk-update-icon -- Displays an update-notification tray icon

[Matthias Klumpp]

Package: wnpp
Severity: wishlist
Owner: Matthias Klumpp 

* Package name: pk-update-icon
  Version : 1.0.0
  Upstream Author : Guido Berhoerster 
* URL : https://code.guido-berhoerster.org/projects/pk-update-icon/
* License : GPL-2.0+
  Programming Lang: C
  Description : Displays an update-notification tray icon

pk-update-icon displays notifications and an icon in the tray area of the panel
when package updates are available.


-- 
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/20141107154919.4773.2484.reportbug@sirius

Re: piece of mind

[Matthias Klumpp]

2014-10-21 17:24 GMT+02:00 Robert Lemmen :
> hi matthias,
>
> On Tue, Oct 21, 2014 at 04:35:20PM +0200, Matthias Urlichs wrote:
>> [...]
>> first place. Having ten processes responsible for bits&pieces of what
>> systemd-as-PID1 does instead of one isn't a benefit -- not if all you gain
>> by that is nine additional processes.
>>
>> "It's a big monolithic thing, and big monolithic things are bad and evil
>> and non-Unix-y, so there!!1!" is not a valid argument.
>
> but that's the thing, to some (e.g. me) ten separate processes that each
> do a fairly small thing with understandable interfaces between them is
> an *enormous* benefit over one bigger thing that does all that in an
> integrated fashion. to the point that even if the one big thing would
> have nice,additional features, I would still opt for the decomposed
> one.
Well, you just now described systemd. The systemd project develops
many small tools which do one thing ant interact together via defined
interfaces.
The init daemon is a bit more powerful that sysvinit, but it still
only does what it is supposed to do: Starting, stopping and monitoring
services. The other tools under the systemd umbrella do different
things.
Did you play around with systemd already?
Cheers,
Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/


-- 
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/CAKNHny8Uh=+wC=8k60m1raifbh4ssbo-v8ky6usdblol6hd...@mail.gmail.com

Re: piece of mind (Re: Moderated posts?)

[Matthias Klumpp]

2014-10-13 18:23 GMT+02:00 Miles Fidelman :
> Didier 'OdyX' Raboud wrote:
>>
>> I really don't buy the argument that "the GR proposal was too quiet to
>> be noticed by 6+ people". I mean: the proposition happened to be in the
>> middle of the post-TC decision wave, on the mailing lists where it
>> belonged. The people who cared about the whole "default init for Debian"
>> question _were_ following and contributing to these various lists. I'm
>> therefore claiming that the people who missed the GR proposal were not
>> sufficiently interested (otherwise they would've been subscribed to
>> either -vote or -project, where these proposals belong). I'm also
>> thankful that the proposer limited his proposal to these lists (I'd have
>> considered a spread of the call over -devel, -user or other lists an
>> abuse).
>>
>>
>
> Actually - I'd contest that, for four reasons:
>
> - as I've previously noted - the major impacts of systemd are being (going
> to be) felt by sysadmins and upstream developers - who don't necessarily
> follow debian-devel all that closely -- or have input
>
> - the actual GR call for vote was buried on debian-vote - immediately jumped
> on regarding wording and procedural discussions
You do understand that we have procedured at Debian to handle stuff
like GR proposals, right? And that procedure involves posting to
debian-vote, so doing that was the right thing to do.


> - actual discussion of the GR on -devel was completely swamped by all the
> other discussion of systemd
That's why it was posted to -vote, where it belonged to.

> - folks have just now pointed to the -project list --- this is the first
> I've ever heard of that list - and I note that it is not even listed on
> https://lists.debian.org/users.html or https://lists.debian.org/devel.html
> -- only on the full list of lists, where it's buried without a description
> of what it's for
Debian Developers know of this (or at least should know of these lists
and subscibe to the ones they are interested in). Since we are
building the distribution and have to carry the additional work our
decisions cause, it's good to follow well-established procedures. That
was done here, and the attempt has failed.
If users notice these project-internal things is not really a concern
- for users we write release notes, and encourage involvement in
discussions about the subject (or even explicitly request feedback).
So, there is really nothing wrong or broken here, everything works as it should.
And the thing we have to do now is to make Jessie as good as possible,
and the systemd transition as painless and bug-free as possible. And
of course, also document what people need to do if they want sysvinit
instead of systemd.
Cheers,
Matthias



-- 
I welcome VSRE emails. See http://vsre.info/


-- 
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/caknhny8jefmhuhieco_bnvncmorq-28znd3fe3socdakhw3...@mail.gmail.com

Re: Bug#761348: ftp.debian.org: need machine-readable metadata about suites & repositories

[Matthias Klumpp]

2014-09-14 15:08 GMT+02:00 Paul Wise :
> [Drop the bug since it seems OT there]
>
> On Sun, Sep 14, 2014 at 9:02 PM, Holger Levsen wrote:
>
>> we have the python-distro-info package which at least holds some of that 
>> info.
>>
>> how/where would you see that in your "picture"?
>
> That has the same problem; it hardcodes information about the archive
> in a place outside of the archive. I've long been of the opinion that
> distro-info (and associated packages) is the wrong solution.
Since we had issues with that in Tanglu as well, we also created a solution ;-)
It's a damn simple YAML file, which describes the suites names,
versions, supported architectures and arch-specific settings, and
points the tools to the current development suite.
YAML has the advantage that you can create suite hierarchies, e.g.
bartholomea:
  state: development
  description: Tanglu 2 (development version)
  suites:
  update:
description: Tanglu 2 updates
A generic solution which is used by Debian and its derivatives would
be an awesome thing, and help a lot in sharing the tools used across
distributions.
Cheers,
Matthias


-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/


-- 
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/caknhny8ounovejxomdnhqhcofjg4pbkgch4zbywuj5qyvf-...@mail.gmail.com

Re: PackageKit cleanup: Do you use these functions?

[Matthias Klumpp]

2014-09-12 15:35 GMT+02:00 Thorsten Glaser :
> On Thu, 11 Sep 2014, Ansgar Burchardt wrote:
>
>> Well, online updates do break software from time to time on my system.
>
> I’ve had to do unattended updates of our old Kubuntu desktop at work
> at shutdown time as well, due to breakage involved in upgrading them
> while being in use (especially the desktop software, most noteworthy
> Mozilla ware).
>
> Sometimes, rebooting (or, at least, logging out then in again) after
> upgrades that touch “desktop” components is better.
>
> Funnily enough, this isn’t so much true for server systems, where we
> just restart the dæmons affected, and occasionally want a new kernel
> if even that.
I fully agree with that, and Simons analysis. I will talk to the
relevant people again, maybe we can get offline-updates happen on
shutdown afterall...
Cheers,
Matthias


--
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/CAKNHny-be2U1X3yL_XL2edODdhf0VfsOh==tzwp5ko0tfup...@mail.gmail.com

Re: PackageKit cleanup: Do you use these functions?

[Matthias Klumpp]

2014-09-12 1:49 GMT+02:00 Cameron Norman :
> El mié, 10 de sep 2014 a las 5:34 , Matthias Klumpp 
> escribió:
>> [...]
>
> What are the options?
>
> I would like if apps could say somehow (maybe an extension to the AppStream
> format?) whether they need offline updates, or if online is fine, so that it
> is only when needed. Also, an option to ignore apps' preferences and just do
> always offline or always online should be present (in PK's configuration).
That would probably be an overkill, although details like that could
theoretically be stored in the AppStream/DEP-11 metadata.

> Is this how the feature has been implemented? Do you think upstream (and you
> as an AppStream supporter / developer) would be enthusiastic about adding
> this, if it is not the status quo?
Possible, but unlikely - I don't think it's needed.

Here is a brief explanation about what actually happens when
"offline-updates" are enabled:
the online-updaters will work as always, even PackageKit is able to
perform online-updates like it always did. But if a desktop like GNOME
(and I am really only talking about desktops here) recognizes updates,
it will tell PackageKit to download updates locally. Whan that is
done, the user is notified about available updates (and might be asked
for reboot), or the shutdown button simple gets an "reboot & update"
sign.
Now, if the user reboots, the system enters a special mode where
updates are installed using PK (progress is shown on Plymouth), then
it reboots again and enters the desktop.
Now, in case an offline-update was prepared and the user does an
online-update, the "reboot & install updates" sign will simply vanish,
and everything will behave like it always did.
This feature is meant for unexperienced users, so, as Steve pointed
out, it would have to be default - but even if it was, it would be
pretty non-invasive.
Currently, GNOME-Software makes heavy use of offline-updates, and I
don't know of anything else which does (except for the cli tools).

The problem with restarting applications and subsystems is that you
never know if the loose state information if you just restart them
(e.g. Inkscape going down on upgrade would be pretty annoying). Also,
if e.g. a bug in a shared library gets fixed which is used by many
programs, you would have to re-execute quite a lot of stuff. On
servers, I expect people to handle that and know about this, but for
desktop users, I see some value in offline-updating.
Restarting the whole system is a pretty pragmatic solution for the
problem, you have to restart to use a new kernel as well anyway.

One thing I personally disagree with is how this is implemented
technically at time (we have systemd, which can reliably enter
different targets (runlevels) and ensure services are started and
stopped properly, but we still reboot twice "for safety reasons"), but
Lennart has a different opinion (and admittedly some valid points
about his position).

Relevant things to read:
http://www.freedesktop.org/wiki/Software/systemd/SystemUpdates/
http://fedoraproject.org/wiki/Features/OfflineSystemUpdates

One thing I want to highlight again is that this would be a pretty
non-invasive change for users used to the existing behaviour, and that
the decision to use it lies by the Debian desktop teams (KDE/GNOME)
and their upstreams, which implement it or not.
What I want to do for Jessie+1 is implement this reliably - it should
better be working properly than being half-usable.
Cheers,
Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/


--
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/CAKNHny8=5vpoastacc2kl20vndnm3zvlsanhrcyym6khzek...@mail.gmail.com

Re: PackageKit cleanup: Do you use these functions?

[Matthias Klumpp]

2014-09-11 16:33 GMT+02:00 Salvo Tomaselli :
> In data giovedì 11 settembre 2014 15:40:31, Ansgar Burchardt ha scritto:
>> Well, online updates do break software from time to time on my system.
>> For system services they usually work fine as they can be restarted by
>> the upgrade process, however user applications break...
> But I normally don't restart for weeks. That would make a reboot an extremely
> long process.
That's why the offline-upgrade procedure is an optional thing (and as
an option, I see no problems in making it work well).
Unexperienced users will get an update-on-reboot, and others can
update the way they want.

> Perhaps we should just change dpkg to have a flag that prevents upgrade if the
> process is running, and that shows some warning that tells to restart software
> X to avoid problems.
We have that in PackageKit, but I think it wasn't working well and has
been removed (I need to check that).

Cheers,
Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/


--
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/CAKNHny-0ybcmo=-Qm�xgq_F=t3if=sxOgat=JoE=hbcju...@mail.gmail.com

PackageKit cleanup: Do you use these functions?

[Matthias Klumpp]

Hello!
(This is just a quick heads-up for the PackageKit-using people in
Debian, so if you don't use PK, you can skip this mail.)
We are currently cleaning up PackageKit[1] upstream, which means some
functionality will soon no longer be available anymore.
Short-term (= with one of the next uploads to Debian), I will remove
the Smart backend from Debian, to use PackageKit with the Smart
package-manager. This backend has also been removed upstream.
So if you use/want to use PK with that backend, act now and implement
the necessary bits upstream! The backend is currently broken in
Debian, and carrying it around does not make much sense.
The other long-term removed features include:
 * Transaction hooks (scripts to run after and before Pk transactions)
 * Support for plugins
 * .desktop file database and package-list caches
 * maybe the debug-info installer as well, although that's in discussion

So, if you use one of these things, it would be good to think about a
replacement, or give feedback upstream to keep these features.
Depending on the state of PackageKit's reverse dependencies and other
factors (use of the features described above by users), I will include
the next release of PackageKit (1.0) which has the cleanup done in
Jessie or not (currently, keeping 0.9.x seems more likely)

PackageKit also has support for systemd-based offline-updates for a
while now, which downloads updates while the system is running, and
installs them in a special mode when the system is rebooting. This
should ensure that no breakage happens when running applications are
replaced with new versions. This is, however, a completely optional
feature, and updates of the system while it is running are still
possible with PK.
GNOME (and especially GNOME-Software) seems to make more use of
offline-updates, so we need to think about supporting it in Debian
(main issue is debconf questions, which don't work well during
offline-updates). I am not going to push that for Jessie, since it
will require some precautions in Apt/the PK aptcc backend. But if you
want, you can try it already. (Note that I want to keep this
desktop-only, since on servers it does not make that much sense (esp.
in case an error happens and the system doesn't recover correctly,
which might happen until we have btrfs, which is upstream's plan)).

Cheers,
Matthias

[1]: http://www.freedesktop.org/software/PackageKit/


-- 
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/CAKNHny-Di-mstbo=0c6aU=cix-js2ws8iamxrb-asxbkgca...@mail.gmail.com

Re: Cinnamon environment now available in testing

[Matthias Klumpp]

2014-09-05 19:52 GMT+02:00 Zack Weinberg :
> Steve Langasek wrote:
>
>> No, that's not the true package relationship.  There's no reason that
>> you should always get this added service by default when you install
>> a system with non-systemd init that doesn't need logind.  Making this
>> a recommends would be a workaround for bad metadata in the
>> libpam-systemd package; we should fix that problem at its source the
>> right way.
>
>
> I filed bug #746578 against libpam-systemd back in May; I believe the
> proposed change (depend on systemd-shim | systemd-sysv rather than the other
> way around) addresses most if not all of this class of issues.  It is
> currently WONTFIXed.
>
> Abstractly, I believe the ideal situation would be for all init systems in
> the archive to be *completely* co-installable, with /sbin/init a symlink
> under control of the administrator; under no circumstances would installing
> or upgrading any package change that symlink.  (It follows that systems
> upgraded from wheezy might wind up with systemd _installed_, but sysvinit
> would remain the active init until the local admin changed things manually.
> Obviously this would need to be documented.)
>
> This would necessitate that all packages depending on specific functionality
> from the _running_ init be capable of detecting its absence at runtime and
> gracefully degrading their behavior.  That may be nontrivial, but I believe
> that we need it _anyway_ so that when a system is deliberately converted
> from one init to another it continues to function more-or-less correctly
> until next rebooted.
>
> Unfortunately, it may be too late for this for jessie :-(
I did not test this, but AFAIK PID 1 can not be a symlink...
Cheers,
Matthias


-- 
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/CAKNHny96avseu=d-tr+pytjizp_tcfz_be57e31dxe3csoj...@mail.gmail.com

Re: systemd, again (Re: Cinnamon environment now available in testing)

[Matthias Klumpp]

2014-09-05 17:23 GMT+02:00 Svante Signell :
> On Fri, 2014-09-05 at 16:07 +0200, Matthias Klumpp wrote:
>> 2014-09-05 15:12 GMT+02:00 Svante Signell :
>> > On Fri, 2014-09-05 at 14:20 +0200, Matthias Urlichs wrote:
>
>> > How? All efforts so far and bugs reported are being brought down
>> > actively.
>> Install systemd-shim + sysvinit-core, or simply pin systemd-sysv will
>> be enough to install the shim and don't get systemd.
>> So yes, this is possible, and the systemd maintainers are doing a
>> great job in creating a seamless transition without blocking anyone
>> who doesn't want to use systemd for whatever reason.
>
> And proposing a solution for a systemd-free (advanced) menu item in the
> installer will be accepted too?
If someone stands up and does the work, I guess so - but doing that is
a non-trivial task, since systemd is seeded by debootstrap at a very
early stage.
It would probably be much less pain to simply swap systemd-sysv with
sysvinit-core as soon as the system is installed.
Cheers,
Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/


-- 
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/caknhny9vqzqrdpbgn1j0kaamrb9uzh38wuorb6az7q6zq65...@mail.gmail.com

Re: systemd, again (Re: Cinnamon environment now available in testing)

[Matthias Klumpp]

2014-09-05 15:12 GMT+02:00 Svante Signell :
> On Fri, 2014-09-05 at 14:20 +0200, Matthias Urlichs wrote:
>> Hi,
>
>> Thus, unless the user explicitly tells the apt{-get,itude} subsystem not
>> to switch to systemd (by whatever means, the details of which I personally
>> am not at all interested in), a dist-upgrade should do so.
>
> How? All efforts so far and bugs reported are being brought down
> actively.
Install systemd-shim + sysvinit-core, or simply pin systemd-sysv will
be enough to install the shim and don't get systemd.
So yes, this is possible, and the systemd maintainers are doing a
great job in creating a seamless transition without blocking anyone
who doesn't want to use systemd for whatever reason.

Cheers,
Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/


-- 
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/CAKNHny9TmwgfmK2X2p7VANmLZqFjUSBWA_0Q=y7mnzb0ga4...@mail.gmail.com

Re: Reverting to GNOME for jessie's default desktop

[Matthias Klumpp]

2014-08-13 22:59 GMT+02:00 Theodore Ts'o :
> On Wed, Aug 13, 2014 at 10:18:49PM +0200, Matthias Klumpp wrote:
>> Well, Linus' extensions won't break because GNOME updates them with
>> every release and ships them with the official GNOME release.
>
> From the README found in "gnome-shell-extensions" sources:
>
> GNOME Shell Extensions is a collection of extensions providing additional
> and optional functionality to GNOME Shell.
> Since GNOME Shell is not API stable, extensions work only against a very
> specific version of the shell, usually the same as this package (see
> "configure --version"). Also, since extensions are built from many
> individual contributors, we cannot guarantee stability or quality for any
> specific extension.
> For these reasons, distributions are advised to avoid installing or 
> packaging
> this module by default.
That's odd - I remember someone from the GNOME folks saying that they
develop these extensions together with the Shell and as part of
official GNOME so they do not break and users can rely on them.
Also, they provide the stuff needed for GNOME Classic, which is the
default desktop on RHEL (so I kind of expect that stuff to work and to
be developed in future).
But that README file is indeed very clear about the extensions repo...

> So again, it'll be interesting to see how many extensions work when
> 3.14 gets released, and how many just break or just silently
> disappear
>
> Of course, not anything which is officially in GNOME is guaranteed to
> stick around, either.  Functionality which is part of "official" GNOME
> have commonly disappeared in a version "upgrade" as well, and the
> Gnome Shell Extensions has a lesser guarantee of stability than
> features in core GNOME.
>
> At least for me, it's a case of "Fool me once, shame on you; fool me
> twice, shame on me."
That's why I use KDE (GNOME also has some small annoyances like having
to delete things in Nautilus using ALT+ENTF etc.) - but admittedly,
the GNOME experience is very usable, and the common reaction I get
from new Linux users is some kind of "wow" effect, since they like the
clean and modern design of GNOME as well as it's workflow, which lets
people focus on screen content instead of desktop chrome.
So if that's the people we want to reach with the default desktop,
GNOME is certainly a good option. I would also recommend to go for
this user group when selecting a default, since any more experienced
user can absolutely be expected to pick the right image with their
favourite flavour of Debian, or change some options in the installer.
Unexperienced users usually don't really know what they want, so
selecting a good default for them would be useful.
People for computers with low specs could pick an image with Xfce or
LXQt and experience a great desktop environment - since there isn't
really a "second class" desktop in Debian, only different levels of
how well something is maintained.
Cheers,
Matthias

P.S: Of course, KDE Plasma would also be a great choice as DE
default-selection ;-)

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/


-- 
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/caknhny8nek6aw3zeyrxzrbvmvfsb4apherxm1vsgc5tpacs...@mail.gmail.com

Re: Reverting to GNOME for jessie's default desktop

[Matthias Klumpp]

2014-08-13 22:05 GMT+02:00 Anthony F McInerney :
>> But I'm actually back to gnome3 because with the right
>>  extensions it is more pleasant."
>
> So the question is does debian have the extensions he speaks of?
> (and) Have debian tweaked those extensions by default, to his liking?
>
> And to quote a not so famous computer user who said "what's that crap on the
> screen, i don't like that, why have they made it look like android"(main
> gnome3 menu + app list) and "i can't login to your laptop now". (GDM3)
> I asked for no opinion or expressed one either way. But since we're now just
> quoting things people said.
> The user has far more experience with windows in general, but has no
> problems with lightdm+ e17. (never seen xfce)
> Again i suppose it depends who debian is targetting by default.
Well, Linus' extensions won't break because GNOME updates them with
every release and ships them with the official GNOME release.
They are also available in Debian:
https://packages.debian.org/sid/gnome-shell-extensions
In order to use a "classic" GNOME, the only thing the user has to do
on a Debian installation is (if the extensions package is installed)
to select "GNOME Classic" from the login screen.
So it's not complicated at all.
Cheers,
Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/


-- 
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/caknhny_p64kxeppqaqu5nmtbq3eogzzoxsuqzocp8hhgxsu...@mail.gmail.com

Re: systemd-sysv/shim in testing

[Matthias Klumpp]

2014-07-27 22:08 GMT+02:00 Sven Bartscher :
> On Sun, 27 Jul 2014 21:21:56 +0200
> Holger Levsen  wrote:
>
>> Hi,
>>
>> On Sonntag, 27. Juli 2014, Dominik George wrote:
>> > >To make it short: I suggest that systemd should only migrate together
>> > >with systemd-shim.
>> > ACK!
>>
>> I think you missed the mail (on this list) which explained that systemd has
>> been waiting for >6 months for systemd-shim to catch up.
>
> Yeah, I kind of missed that.
> It's right that my suggestion is not going to work if systemd-shim is
> that much behind.
> As a solution I would suggest that a few more people help with the
> development of the shim. (Of course, only if that's alright for the
> current maintainer.)
> For this matter I would offer my help for issues of this kind in the
> future, in the hope that we will be able to keep the shim up to date
> with systemd without blocking it too much.
That would, in fact, completely solve the issue and help everyone :-)
And I am pretty sure the -shim maintainers are glad for every helping
hand.
Cheers,
Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/


-- 
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/CAKNHny_=pe+olugyhtg5tdi9ryudm_-jy38eerywjbq4-oq...@mail.gmail.com

Re: I have to write a software center application

[Matthias Klumpp]

Hi!
Only a short answer, because I am currently on the run - if you need
more information on this matter, feel free to contact me off-list.
First, I recommend using PackageKit[1][2], which is an easy-to-use
abstraction layer for package managers, running on a wide variety of
distributions. This software lets you install packages (and do other
stuff) on almost any distribution (great if you want to make your
stuff available to other distros as well!). Qt and GObject interfaces
to PK are available via libpackagekit-glib2 and libpackagekit-qt. A
Debian-only and Qt-only solution would be using QApt as alternative to
PackageKit.
You will also need metadata to show in your software-center
application. That data is currently not available in Debian yet, but I
have a SoC student working on this matter (integration help is highly
appreciated!).
More information about AppStream is avauilable at [3] and [4].
You can access the AppStream data via libappstream (GObject interface)
or libappstreamqt (Qt4 interface). Both libraries are currently
available on Debian.
These libs will already provide some spare metadata (via
app-install-data). The larger chunk will come with the completion of
my student's project.
There is also a student working on a Muon[5| port to Debian and
AppStream - Sune Vuorela knows more about that.
Also, it might be worth to take a look at GNOME-Software[6] which we
might be able to make ready for Debian Jessie in time (depends on the
completion of a few prerequisite projects).
If you have further questions, feel free to ask off-list (since this
list is about the development of Debian, and this issue might be
slightly off-topic)
Cheers,
Matthias


[1]: http://packagekit.org
[2]: https://packages.debian.org/sid/packagekit
[3]: http://www.freedesktop.org/wiki/Distributions/AppStream/
[4]: http://www.freedesktop.org/software/appstream/docs/
[5]: 
http://kde-apps.org/content/show.php/Muon+Package+Management+Suite?content=137507
[6]: https://wiki.gnome.org/Apps/Software


-- 
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/CAKNHny_w15t8MRYAPOvmuftpQTr+wUSYb6BqdFTk26Yp2Sm=z...@mail.gmail.com

Re: let missing-debian-source-format lintian tag be a warning!

[Matthias Klumpp]

2014-07-16 0:44 GMT+02:00 Mattia Rizzolo :
> On Wed, Jul 16, 2014 at 12:39 AM, Michael Gilbert  wrote:
>> This would be far better solved with a system conffile of some sort
>> like /etc/dpkg/dpkg-source.cfg, which admittedly doesn't exist yet.
>
> in general I feel the lack of a $HOME/.dpkg.conf conffile...
> Luckily there are wrappers (debuild?) that take care of passing the
> options I want to dpkg-* programs.
That config file sounds like a really great idea to suit everyone.
With something like that in place and the one-patch solution for
people who want to maintain their patches differently, there shouldn't
be disadvantages of switching to 0.3 (quilt), or am I missing some?
Cheers,
Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/


-- 
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/caknhny9krwn50g4xxg5bzxq8kgqw5b4k84n2yrgszrwcb-r...@mail.gmail.com

Re: How to avoid stealth installation of systemd?

[Matthias Klumpp]

2014-07-03 0:40 GMT+02:00 Norbert Preining :
> On Wed, 02 Jul 2014, Joerg Jaspert wrote:
>> And should we open the archive for a series of "i hate $tool, i never
>> want it" packages, where do we stop? In theory we could end up with a
>> load of them.
>
> Joertg, please be reasonable. You know exactely why there is a difference
> between a conflict-package against systemd that comes in as indirect
> reference via hundreds of channels, while all the other stuff
> will hardly pulled in unless you install a package of that suite
> on purpose.
>
> You are comparing apples with watermelons, or better, apples with trees.
>
> Why do you state such things despite the fact that you are well
> aware that systemd is different from all the others? The only
> explanation is that you don't want people to keep systemd out.
Just because the package's purpose in itself is - sorry - idiotic it
shouldn't make it's way into the archive. We are building a consistent
operating system here, with packages which add components to the OS.
Some package preventing stuff to be added does not make sense from
this point of view.
But furthermore, the package does not fulfill the purpose it is
designed for: It will *not* prevent the installation of systemd
components, since nothing depends on it, in order to satisfy the
dependency chain, Apt will simply remove the package. This can be
circumvented by making the -must-die package essential or required,
but that will never happen for obvious reasons. So you would have to
pin that package in order for it to be "useful". But this means that
the package is not useful out-of-the box (what we expect from every
Debian package), also you can pin the systemd-sysv package directly to
prevent the init-system from becoming default. So adding the package
to Debian is completely pointless. Having it in a private repo,
however, is of course up to anyone who would like to use it. But for
the reasons stated above, and of course for the "must-die" attitude,
which, although maybe meant funny, does not come across as joke for
all people, such a package could never be added to the Debian
repositories.
Please, just pin systemd-sysv and be done with it. And if you really
want to help with making a systemd-init-free Debian, you should invest
work in systemd-shim to make it use cgmanager. That is an open task
where the systemd-shim authors could likely need help, and which would
immediately help your case.
Cheers,
Matthias


-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/


-- 
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/CAKNHny_70HCi+n=kl0ox2mkwhqkc4pqhzpt-1kq-cok29qj...@mail.gmail.com

Re: Re: How to avoid stealth installation of systemd?

[Matthias Klumpp]

2014-07-01 19:38 GMT+02:00 Eric Valette :
>> I think that this would be an annoying waste of time for most users,
>> since only a few people care so much about not being tainted by systemd
>
>
> I do not care being tainted by systemd when it works. Actually on two very
> different machines it means no audio for me.
>
> On a NAS it means no boot(probably because of RAID10 fs in /etc/fstab), so I
> reverted it on all machines
>
> Bug for pulse is open for a while but so far no change.
>
> and BTW, rtkit does not work with systemd208, udsiks2 depends on
> libpam-systemd,   and systemd-shim is incompatible with systemd-shim meaning
> usb key hotplus is now unavailable and rtkit also.
>
> I think that as long as the transition is not smooth, whithout any religious
> conveiction, people will complain. For me, the forced transition was
> introduced too early
These are valid points, and thank you for reporting bugs! However, as
unstable user, some breakage can be expected, and the point for
transitioning early in unstable is to make the transition as smooth as
possible when someone uprades Debian stable, which is not affected by
init-system changes at all.
So I think the transition was just at the right time to create a great
Jessie release.
Cheers,
Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/


-- 
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/caknhny_e0p3_7+crdwbmopixlw0278so8qxbmufhhq3w9pg...@mail.gmail.com

Bug#752900: ITP: appstream-glib -- Library for AppStream metadata access

[Matthias Klumpp]

Package: wnpp
Severity: wishlist
Owner: Matthias Klumpp 

* Package name: appstream-glib
  Version : 0.1.6
  Upstream Author : Richard Hughes
* URL : http://people.freedesktop.org/~hughsient/appstream-glib/
* License : LGPLv2+
  Programming Lang: C
  Description : Library for AppStream metadata access

This package is relevant mainly for it's metadata validator, which is more
versatile than appstream-validate. Also, some tools might want to depend on
libappstream-glib in future.


-- 
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/20140627161136.4133.90634.reportbug@sirius

Re: systemd-fsck?

[Matthias Klumpp]

2014-05-13 15:01 GMT+02:00 Marc Haber :
> On Mon, 12 May 2014 13:58:31 +0200, Josselin Mouette 
> wrote:
>>Le lundi 12 mai 2014 à 12:16 +0200, Andrew Shadura a écrit :
>>> > As far as GDM is concerned, any bug reported with systemd-shim installed
>>> > will be ignored. The bug script should probably be updated to that
>>> > effect, BTW.
>>>
>>> This sort of behaviour is precisely why so many people not only
>>> dislike systemd, but also it's maintainers.
>>
>>Thank you so much for volunteering to contribute to GNOME packaging and
>>to make it work on configurations nobody will actually ever use.
>>
>>We are eagerly waiting for your patches.
>
> This sort of behavior is precisely why many users are migrating away
> from Debian.
While the "nobody will actually ever use" can hardly be called
"deescalating", admittedly, in the matter Joss is absolutely right:
Better spend the limited time we as volunteers have to support one
thing best, instead of having multiple half-baked solutions, like
"GNOME support 4 init-systems, unfortunately session management
doesn't work properly on any of them".
If you want an additional configuration to be supported, where nobody
is working on yet, you should commit to maintaining it. If there is a
huge group of people who *want* that feature to happen, it will happen
and it will get all the manpower it needs.
And I am pretty sure Joss wouldn't block properly maintained patches
for alternative configurations (as long as they don't lead to problems
in the default configuration). In the same way, nobody will (and
should) block properly maintainer upstart/sysvinit/systemd units.
Cheers,
Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/


--
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/caknhny8bgxzgv4em8zgl5aqrpbh9cj3i4_gr2p_i30q6sgc...@mail.gmail.com

Re: Avoiding systemd

[Matthias Klumpp]

2014-05-11 15:55 GMT+02:00 Marc Haber :
> On Sun, 11 May 2014 14:50:55 +0200, Florian Lohoff  wrote:
>>There is no way to avoid the "userspace.exe" blob Debian is soon made of.
>
> To be fair, the major Linuxes will soon be made of that. Red Hat wants
> it that way.
Oh come on!
Do we really have to repeat the same init-FUD crap for all eternity on
any discussion like that?

Sidenote: I am pretty glad how people are working together to fix
init-transition related errors :-) (with people from upstart and
sysvinit-sides involved constructively as well, which is great and
will in the end lead to a pretty robust solution, I think)

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/


-- 
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/CAKNHny_phu=2ebnn6s805a8d001u2vlrxbcdiygogz_c2o6...@mail.gmail.com

Re: concurrent installation of different pkg versions

[Matthias Klumpp]

2014-04-28 2:16 GMT+02:00 Don Armstrong :
> On Sat, 26 Apr 2014, Russ Allbery wrote:
>> And simultaneous installation of multiple versions of packages is
>> simply a requirement for many research computing scenarios, usually
>> because there's a lot of bespoke scientific code that accomplishes
>> some specific goal but was not written to the standards one would
>> expect from professional programmers, and therefore doesn't easily
>> work with newer versions of libraries.
>
> The right way to handle this for research computing scenarios is to
> deploy virtual machines with specific versions otherwise you're
> constantly battling with trying to make sure that you're actually using
> the version that you think you're using.
>
> The quality of almost every single piece of scientific code I've ever
> worked with is so appalling that I'm always amazed when any of it
> produces any useful results, ever. And lets not even talk about whether
> the results it produces are accurate or reproducible...
I absolutely agree with both statements. And I would love to print out
the last quote in poster-size and place it in our lab :-)
However, there is some pretty good scientific software around, and
there are labs where programmers and other researchers work together
well to produce great software and great results.
But anyway, to give some input: We're exploring containerization here
for exactly that purpose (running old software versions in a defined
environment with less overhead).
Cheers,
Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/


-- 
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/caknhny8_njwa7psm_lt-qi2leebkkx-pfx5p4cut8gt4ya+...@mail.gmail.com

Re: Debian default desktop environment

[Matthias Klumpp]

2014-04-05 20:18 GMT+02:00 brian m. carlson :
> On Sat, Apr 05, 2014 at 07:57:50PM +0200, Josselin Mouette wrote:
>> Could you please sum up those discussions and explain what kind of
>> changes you would consider to be productive?
>
> I can sum up the discussions that were had last time on debian-devel for
> you, at least as I remember them.
>
> * XFCE fits on one installation CD, which is relevant for those people
>   who have slow or expensive Internet access (which is many parts of the
>   developing world).  The older machines which may be more likely to be
>   in use in those areas may not have a DVD drive, or downloading 4 GB
>   for a DVD may be prohibitive in time or cost.
> * It works better on older and less powerful machines[0].
> * Some people claim that the interface is more familiar for
>   non-technical people coming from other operating systems.  This is the
>   subject of much debate, however.
> * Similarly, some people dislike the GNOME shell interface and prefer a
>   more traditional desktop environment[1].
> * There were concerns about accessibility support, "particularly for the
>   blind"[2].
> [...]
Those aren't "solid" arguments...
Replace "Xfce" with $anydesktop and you will get the same result. MATE
is not an argument for the vague "some people dislike GNOME-Shell"
(who is some people? why are they more important than the ones who
like the GNOME-Shell?) - some people didn't like KDE so they started
Trinity, so you could use the same argument there.
GNOME could be made to fit on CD1 (we use stronger compression now and
could leave out some components)[1].
For the accessibility stuff, I would say GNOME offers one of the best
experiences - and I say that as KDE user and developer.
So, we need other arguments to switch to GNOME/Xfce/KDE as default
than that ones.
Cheers,
Matthias

[1]: Personally, I think we should offer a DVD instead of a CD as
primary installation medium. A CD could still be optional, offering a
installation media with reduced components (e.g. no LibreOffice by
default) for those who need/want it.

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/


-- 
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/CAKNHny-V5zoKdb=sr+j559jbyx2wza5gys5xywoy56nczun...@mail.gmail.com

Re: its developers and its users. [was: something from util-linux]

[Matthias Klumpp]

2014-02-12 12:26 GMT+01:00 Oleg :
> On Wed, Feb 12, 2014 at 11:51:38AM +0100, Tzafrir Cohen wrote:
>> >   I'm using debian and i don't want to use systemd in any form (with 
>> > gnome3,
>> > etc).
>>
>> Great. gnome3 does not depend on systemd directly. It depends on some
>> interfaces provided (solely, currently) by systemd. And it's not gnome3
>> alone.
>>
>> Go and help reimplement those interfaces (coding, testing, whatever), or
>> otherwise do something constructive.
>
>   I do my job. And i have no enough time to do a job of others. This is a
> strange logic: if something goes wrong, we must throw our work and do a work
> of others.
So we, who are mostly freelancers and work on Debian *and* our jobs,
should do extra work in order to support sysvinit?
I don't think so... If you want something done, do it. But don't try
to get others to do it for you, unless you want to pay them.

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caknhny_ymz5m2ot-qu40c4txqslwpgs4-7aqc_n-x9tgbnf...@mail.gmail.com

Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.

[Matthias Klumpp]

2014-02-11 17:03 GMT+01:00  :
>[...]
> And if I _really_ needed a binary index, I would put it in a separate file.
Guess what journald is doing ;-) And if the journal is not running in
persistent mode, this extra logfile only exists temporarily and
everything is forwarded to rsyslog, so you gat your syslog-textfile
(but with much more structured content)
First try the software, then complain. Complaining about something you
never tried and/or don't know about doesn't make any sense.
Cheers,
Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKNHny9mx2ggVMepf0eADjtP=wqdjkmvoo3dcas1j+wjpdg...@mail.gmail.com

Re: CUPS is now linked against OpenSSL

[Matthias Klumpp]

2014/1/11 Andreas Metzler :
> Svante Signell  wrote:
> [...]
>> What are the chances of cups re-licensing (dual-licensing) to GPL2+?
>> This would be a step in the right direction. (in worst case use some
>> other software package than cups as default for printing)
>
> I'd guess minimal, iirc Apple has no love for GPLv3.
Changing this would only mean that CUPS forks have the option to be
distributed under GPLv3. I don't see a reason why Apple should be
against this.
But I guess a decision like this would run with low priority over there...
Cheers,
Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKNHny-x=3wjuhq1spxdy6htsbwkxtckzpnoocqkopk7plu...@mail.gmail.com

Re: Debian Developers team in Launchpad

[Matthias Klumpp]

2013/12/16 Tae Wong :
> Here is a post to LibreOffice's problem with the editing copyright message:
> http://lists.freedesktop.org/archives/libreoffice/2013-December/058214.html
>
> You're not subscribed to debian-devel and LibreOffice's mailing list.
I have the feeling that this is indeed some kind of bot trying to
waste time of people.
Tae Wong, please reply to this message (show any reaction at all and
indicate that you understand that debian-devel is the wrong place for
what you want to say, as you have already been told over 4 times by
different
people (who also gave advice on how to proceed with the issues)). In
any other case, I would be really happy now if the listmasters would
ban this address from posting to the list.
Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKNHny9YRuQDv9YnTU=msaUjgP56OBzig3K4=fghneeg8wp...@mail.gmail.com

Re: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

[Matthias Klumpp]

2013/10/29 Steven Chamberlain :
> [...]
>
> Just wondering, if systemd upstream cares only for Linux and that's
> considered okay, might they also start dropping support for
> architectures they stop caring about (or for commercial reasons)?  Say
> MIPS, s390, SPARC.  In that case, permanently ditching SysV init could
> put even some Linux ports in jeopardy.  Perhaps Upstart carries the same
> risk if Ubuntu releases only for i386/amd64/arm.
systemd upstream made clear some time ago that they aim to support
every architecture Linux is running on, and also aim for mobile and to
some extend embedded devices.
So I wouldn't worry about that. Patches for architecture support are
also welcomed.
Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKNHny_NWfsy=ch1jmifpukggm_hz4kzrp_zzfx85w1npxa...@mail.gmail.com

Re: Proposal: let’s have a GR about the init system

[Matthias Klumpp]

2013/10/25 Colin Watson :
> [...]
> One thing I will say here and now: if I feel under pressure from my
> employer to vote a particular way, then I will immediately recuse myself
> from the vote and from further part in the discussion.  I'd hope that
> would be generally understood as ethical behaviour.
And *that* is the point :-) All members of the TC have contributed
lots of useful stuff to Debian, and I trust everyone of them to has
the knowledge to decide on something for Debian, finding the
(technically) best solution. If some of the members do also contribute
to Ubuntu is irrelevant, and there are also other members who aren't
associated with Ubuntu.
The only thing I would not accept would be if a company forced a TC
member to manipulate a decision - I trust the individual TC members,
but not necessarily their employers.
But I don't see that risk here :-) Thank you so much, Colin, for
bringing this (IMHO very important) point up!
Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKNHny_pJECoMFYo8RE+aHWQNP7pQ8-0ezM_k1A7=a6ylal...@mail.gmail.com

Re: let's split the systemd binary package

[Matthias Klumpp]

2013/10/25 Neil Williams :
> On Fri, 25 Oct 2013 10:36:30 -0400
> Marvin Renich  wrote:
>
>> However, it is obviously true that systemd as the default init
>> system is controversial, and that GNOME depends on it.  While GNOME
>> may work with systemd installed but not PID 1 at the moment, in
>> another message Uoti Urpala says that systemd as PID 1 will be
>> required in an upcoming release.  If this is true, regardless of
>> motives, then if GNOME is the default DE, systemd will be the de
>> facto default init system.  The default init system should be decided
>> _before_ the DE, not _by_ the DE.
>
> Exactly.
>
> It is not up to GNOME to assume that systemd is the only init system it
> can choose to support. That decision is entirely separate and outside
> the scope of the GNOME developers. The desktop environment has no
> business assuming it knows best and the developers of that environment
> have no business dictating the use of one init system above another.
>
> It's not about whether the GNOME developers or maintainers should have
> chosen one init system or another based on activity of that system,
> it's about whether GNOME developers even have the option of making that
> choice. I submit that they do not. Their decision to do so is
> presumptive and disruptive. Debian does not have to respect that
> decision and should not follow blindly.
No, but GNOME has a mission to create a great desktop-environment
which is easy to use and "just works". And logind (in combination with
systemd) offers features to accomplish that goal and provides some
truly awesome features for session-management, multiseat etc. which
GNOME decided to support.
So, GNOME did not make a decision "for an init-system", but a decision
for a set of features they assume should be integral part of a
well-working Linux desktop. And there's nothing wrong with doing that,
IMHO.
Cheers,
Matthias


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKNHny_b1_Ni3u1ox3Ey=a7b_acrmyc0tmsnpmy+zkvrm65...@mail.gmail.com

Re: Proposal: let’s have a GR about the init system

[Matthias Klumpp]

2013/10/25 Thorsten Glaser :
> Paul Tagliamonte  debian.org> writes:
>
>>Decide any technical matter where Developers' jurisdictions overlap.
>
> This is more or less a political question (and one of trust and one to
> FINALLY decide what package maintainers and porters can depend on, so
> that we can move on).
No, it is a technical question and a question of what Debian should maintain.

> Also, I’d not like to “maybe have a GR later”. Let’s have one now, then
> move forward, whatever the outcome is.
>
>> Supporting two different init systems is something I don't think
>> *anyone* wants to get into. Remember they use different files, so this
>
> Erm, we already support sysv-rc, file-rc, systemd, upstart…
> so my favourite GR outcome would just say that Debian fully
> commits to continue doing that.
We support three init-systems badly. We should fully support one
init-system and make it awesome and easy to use, and not having many
half-baked solutions which are a pain to maintain.
Switching init-systems is nothing anyone would want to do, except for
maybe supporting sysvinit on kFreebsd, while supporting systemd on
Linux - but these are different OSes, and different usecases.
Cheers,
Matthias


-- 
I welcome VSRE emails. See http://vsre.info/


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKNHny8Ados9hiML4Rhgx4kfy_SpTcFZ_OGqeat4K+=v+bn...@mail.gmail.com

Re: Proposal: switch init system to systemd or upstart

[Matthias Klumpp]

2013/10/25 Neil Williams :
> On Fri, 25 Oct 2013 14:29:54 +0200
> m...@linux.it (Marco d'Itri) wrote:
>
>> It is more and more obvious that modern software needs an event-based
>> init system.
>>
>> Pros:
>> - more features
>> - stable support for advanced boot/SAN environments
>> - being more similar to one of the other relevant distributions (RHEL
>> or Ubuntu)
>> - things like gnome become easier to package
>>
>> Cons:
>> - some work to do (how much depends on the choice and on the details.
>>   but keeping sysvinit on life support is not free either)
>
> Are either of the alternatives, at the versions currently in Debian
> testing, ready for the migration? (I have no idea, I'm wondering out
> loud).
>
> How long might the migration take? Are we talking Jessie or Jessie+1
> here? Jessie+2?
>
> I can see some / many services being migrated but *all* ?
>
> Who is going to do all that work?
Both systemd and upstart contain compat layers for LSB init-scripts,
so there is no need to switch *everything* immediately. There can be a
slow migration.
And in case of systemd, many upstreams already ship systemd services,
which work on Debian without further modifications.
So, I think some partial migration would be possible for Jessie, and a
"full" migration could be planned for Jessie+1.
Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caknhny82_hqu-trwg78903bfthunnxpd70wzqk5fg6fxddo...@mail.gmail.com

Re: systemd effectively mandatory now due to GNOME

[Matthias Klumpp]

2013/10/24 Steve Langasek :
> [...]
>> If Gnome depends on gnome-settings-daemon, which now depends on systemd,
>> this might be a worrying trend, as non-Linux kernels don't support systemd.
>
> Well, that's one more reason the init system and the dbus services should be
> separated out in the packaging.
Some of the services consume functions and features provided by
systemd (the init system). So splitting it out is not an easy task.
Ubuntu manages to do that by heavily patching systemd and their own
upstart to support a systemd-less system. (of course, there is stuff
which does not need systemd[1].
Cheers,
Matthias

[1]: 
http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/

-- 
I welcome VSRE emails. See http://vsre.info/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKNHny_3SbPqaJ37SWiP2y4kSj08==js9oyPMnzfN6sXO3=r...@mail.gmail.com

Re: Bug#719673: ITP: needrestart -- needrestart checks which daemons need to be restarted after library upgrades

[Matthias Klumpp]

2013/10/14 Paul Wise :
> On Tue, Oct 15, 2013 at 12:21 AM, Matthias Klumpp  wrote:
>
>> It just checks that - I wanted it to look for upload-priorities in
>> Debian changelogs some time ago, but doing that was just way too slow.
>
> Higher upload priorities doesn't indicate a security fix. It could be
> an RC bug fix or certain people using higher priority without that
> being appropriate.
Yes, that was more like a hint, because I didn't know a better way to
set update-priorities back then ;-)

>> That would be a nice feature to have! I think when this features was
>> revised some time ago, these options where not yet available.
>> It would just have to be fast enough, because PK needs the security
>> status almost immediately (otherwise the updater UI will have very
>> long loading times).
>
> debsecan and the security tracker has been around since before the
> etch release, so I guess it existed before PK. As to speed, it could
> update the debsecan data before every apt-get update.
>
> http://archive.debian.net/search?keywords=debsecan
Nice! I learned about debsecan just about 4 months ago, so I thought
it was new... (this falls in the category of cool tools you should
have been using for years, but didn't)
If aptcc could gain support for this, it might even make sense to make
PackageKit recommend it, so it gets pulled in by default.
Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKNHny-ZFi4=qgvtz8ghhkjmi9u-iu49e7ra5v3htash1ch...@mail.gmail.com

Re: Bug#719673: ITP: needrestart -- needrestart checks which daemons need to be restarted after library upgrades

[Matthias Klumpp]

Hi!

2013/8/22 Paul Wise :
> On Thu, Aug 22, 2013 at 11:17 AM, Matthias Klumpp wrote:
>
>> PackageKit can do that ;-) It has a plugin to check for shared
>> libraries in use, I just haven't tested in yet. It should show the
>> names of services which need to be restarted after a security update.
>
> Cool.
>
>> This info is at least shown on the command line (and only for security 
>> updates).
>
> How does it know if an update fixes a security issue? Just checking if
> it comes from security.d.o would not be enough since updates to
> unstable often fix security issues.
It just checks that - I wanted it to look for upload-priorities in
Debian changelogs some time ago, but doing that was just way too slow.

> I guess it uses the
> debsecan/security-tracker data?
That would be a nice feature to have! I think when this features was
revised some time ago, these options where not yet available.
It would just have to be fast enough, because PK needs the security
status almost immediately (otherwise the updater UI will have very
long loading times).
Cheers,
Matthias


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caknhny9iaur5bcsz5atvtk+awce4eip+ere6svmfytnebdv...@mail.gmail.com

Re: jenkins vs. debile [was: Re: Bits from the Release]

[Matthias Klumpp]

Hi!
2013/9/27 Michael Tautschnig :
>> [...]
>
> Would you/Matthias be willing to share the feedback on jenkins more widely? I 
> do
> presently run a system with ~60,000 jobs, and, yes, this is probably somewhat
> beyond what jenkins was meant to scale to. Yet jenkins does have the practical
> advantage of being widely used, with lots of plug-ins, and being well
> documented. Not all of this seems to be the case for debile at present...
>
>> I don't doubt that jenkins.d.n can be leveraged for the time being,
>> giving the low amount of autopkgtests currently available. But you might
>> want to check with Matthias or similar experiences before committing to
>> using Jenkins for this.
>>
> [...]
>
Additionally to the points Paul already mentioned: The lots of plugins
stuff does not really matter for the Debian use-case, because Jenkins
was built for an entirely different purpose.
For example: In Debian, we need at least 5 states a build can be in:
dependency-wait, building, uploaded, installed and failed. Jenkins
only provides built and failed, and adding more states is lots of
work.
Also, packages function differently compared to Jenkins jobs: You can
e.g. build different versions of a single package, so foobar is build
in versions 1.0 and 1.2 for different target suites. This can not be
easily reflected in Jenkins.
We worked around all of these issues in Tanglu. For example, we have a
depwait state by taking the control over builds from Jenkins to an
external application and adding dependency-wait information to the job
descriptions. We can then find stuff in depwait using a RegEx.
To solve the multiple-versions issue, we append the version number to
the jobname, and jobs get renamed if necessary by the
Jenkins-controlling tool. Because we don't have uploaded/installed
states, the Jenkins-helper is patrolling the jobs to guess these
states and schedule rebuilds.
You can see the stuff in action here: http://buildd.tanglu.org/
(currently, some build slaves are broken, which is really sad and
needs to be fixed soon)

So, I really think that Debile is a sane approach with less hackish
solutions. I will start to work on it too, as soon as I find time, and
most likely migrate Tanglu to it, so we do no longer rely on Jenkins
for that.
On the pro side, of course, Jenkins has cool plugins to analyze job
output, and it has live buildlogs - but having it build the Debian
archive is hackish. Also, Jenkins gets incredibly slow... The machine
powering our build-master and archive is very powerful (Octocore, I
think at least 16GB of RAM), and Jenkins performance is still bad.
Maybe because it is using one large XML file to store job data.
Cheers,
Matthias


-- 
I welcome VSRE emails. See http://vsre.info/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKNHny-d2Tb4AyAU_4OxF+B6OAkULPUX+Six-kBEs=tk9q_...@mail.gmail.com