Re: Git Packaging Round 1: Hopefully Easy Stuff

[Philip Hands]

Jonathan Carter  writes:

> On 2019/08/14 20:02, Sam Hartman wrote:
>> If you're going to set up a repository for Debian packaging on Salsa,
>> you need to either:
>>
>> 1) turn off merge requests
>
> That would be quite horrible IMHO, this is the de facto method that
> young (let's say under 35 years old) developers use to submit
> improvements to other projects. We have all the infrastructure and tools
> conveniently in place to accommodate this, it seems suboptimal to treat
> MRs as a second class citizen.

Would it not be possible to have a webhook (or similar) that could
receive notifications of MRs, and automatically create a bug report
containing the current state of the MR as a patch?

Of course, if people then fiddle with their MR, the patch may well be
useless, which is likely to force one to actually deal with the MR
within gitlab anyway (or to bugs in the BTS with streams of mostly
useless generated patches ... but at least one would have captured the
history that way).

If the generated bug report included links to guide the maintainer
straight to the diff as it currently exists that would minimise the pain
for non-MR-happy maintainers ... along with a link to a wiki page where
we could collect tips like the one just mentioned by Holger.

The webhook could also add a comment to the MR linking to the new bug in
the BTS.

That way, people that intend to mostly ignore MRs could still allow
people to make contributions in their preferred style, while gently
guiding them towards interacting via the BTS, simply by adding the
relevant webhook to the project's Integrations settings.

That seems rather more welcoming than simply turning MRs off, which is
likely to make some people go and find something more enjoyable to do
with their time than contributing to that project.

Cheers, Phil.
--
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

init.d scripts and unit files lexical order or {daily,weekly,monthly} cron jobs?)

[Enrico Zini]

[changed subject because I can't stand the old one]

On Fri, Aug 09, 2019 at 08:46:18PM +0200, Simon Richter wrote:

> I can totally see the benefit of using systemd unit files as init scripts
> through start-stop-daemon, because we could have a common "open socket,
> chroot, drop privileges" wrapper that way, most of the code is already
> there (start-stop-daemon's command line is a descriptive interface) and it
> would still be simple enough to fully understand in a single day.
> 
> If I went and implemented the "API" by implementing all the features in the
> man pages, I would indeed get the single property I like the least about
> systemd: that its specification is always in flux.
> 
> I am fairly sure it would be possible to define a more powerful API than
> init scripts. Alas, that hasn't happened yet, because nobody is willing to
> create a normative reference.

Alternatively, we can decide on a subset of unit files that would cover
the normal start-stop-daemon features, and like 80% of initscripts, and
would be very unlikely to be changed anytime soon by systemd upstream,
and decide that if that's all you need for your /etc/init.d script, you
can just ship the unit file and delegate the sysvinit case to the
start-stop-daemon equivalent.

Those packages that use more unit file features can still ship an init.d
script, but at least all those packages that just start/stop a service
don't need to bother about maintaining yet another shellscript that
bitrots dangerously over time.

I even have a python implementation of most such unit file features that
I can offer as a starting point, please give me a few days[1] to talk to
one of my customers about putting it into a public git repo.


Enrico

[1] today's a national holiday in Italy: 
https://en.wikipedia.org/wiki/Ferragosto
-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

[Ian Jackson]

Simon McVittie writes ("Re: Generating new IDs for cloning (was Re: duplicate 
popularity-contest ID)"):
> Somehow describing which containers and chroots should have a machine ID,
> which ones should share the host's machine ID and which ones don't need
> either is a gap in my proposal.

Do we have a list of all the things this is (or might be) used for ?
I think that would help us think about these kind of questions, and
also decide how important it was to improve this area.  (Please
forgive me if someone already mentioned such a list which I overlooked
in this thread.)

We need to think about the privacy implications.  Certainly the
machine id should not normally go into network protocols.

Can we think of other uses of the machine id that might seem like a
good idea to some upstreams, but of which we would disapprove (whether
for technical or ethical reasons) ?

I wonder if we should in Debian have a "sticky door" policy on the use
of machine-id, like we do for virtual packages: "please come to -devel
for a peer review".  We could spot these issues with a lintian check
maybe.

Sorry that these considerationsn probably seem rather negative.  It's
in my nature to try to spot the downsides and problems with things;
please take this as an attempt at constructive foresight.

If we decide this machine-id is a good thing that should be in X and Y
and Z (containers, chroots, "pets" running sysvinit, or whatever
combination, etc.) then we could implement that in our own
arrangements even if upstream haven't taken those patches yet.

Regards,
Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: salsa.debian.org partially down

[Thomas Goirand]

On 8/15/19 11:03 AM, Ian Jackson wrote:
> (off-list)
> 
> Ian.

You replied off-list, so I wont quote you, though I would like my answer
to be public.

I probably should have mentioned that my remark was not so much related
to the crash, but more to what I experienced using Salsa's CI. It's
currently super slow, as apparently, it's using GCE using the smallest
instance possible (maybe because we have a limited credit?). As a
result, adding the salsa CI team's script just fails in some packages
like for example OpenVSwitch, because of the slowness. In the extreme
case of OpenVSwitch, during build, mostly all tests are timing-out. I
found the overall experience frustrating, and the Salsa CI not very
helpful because too slow.

So, instead of what I experienced, I thought using Zuul + Nodepool like
in the OpenStack CI would probably solve the slowness and resource
starvation issues. What's done there, is that OpenStack based cloud
providers are sponsoring a pool of VMs (. They are maintained using
nodepool, that "pre-provision" the VMs. That's a bit like with apache
prefork, where processes are spawned in advance to be ready for the next
connections, except here, we're talking about VMs ready to accept CI
jobs. Then Zuul does the job queue and scheduling. Overall, this is a
very efficient CI, which is able to spawn thousands of jobs, on many
different cloud providers.

I'm not sure exactly what the Salsa issue was. Whatever it was, I
strongly believe that Zuul + Nodepool would help:

1/ CI Jobs going faster
2/ Have a way more workers
3/ Don't have all our eggs on the same Google basket
4/ Use free software platforms instead of GCE
5/ Stop being bound to a single VM provider [1]

Not only OpenStack uses Zuul, big companies like Netflix and MediaWiki
foundations too.

I've read that this year, there was some efforts to add Gitlab support
to Zuul. I don't know what the status is though, but I know that it's
possible to add Gerrit in front, and then have Gerrit plugged to Zuul.
I've used Gerrit previously to do OpenStack packaging (the version of
OpenStack in Stretch was done this way), and I was very happy of it. I'd
love if I could have the opportunity to do this again, but with Salsa
and the Debian infra this time.

Cheers,

Thomas Goirand (zigo)

P.S: If you want an idea of what it is like with nodepool in action, go
here: http://grafana.openstack.org then click on "Home" and select
nodepool. There you'll see graphs of spawned instances.

[1] The OpenStack CI is currently configured to use VMs from:
Fortnebula, OVH (2 regions), Rackspace (2 regions), and Vexxhost, though
it used to have a large amount of sponsors.

Re: init.d scripts and unit files lexical order or {daily,weekly,monthly} cron jobs?)

[Simon Richter]

Hi,

On Thu, Aug 15, 2019 at 10:40:22AM +0200, Enrico Zini wrote:

> [changed subject because I can't stand the old one]

Good idea.

> Alternatively, we can decide on a subset of unit files that would cover
> the normal start-stop-daemon features, and like 80% of initscripts, and
> would be very unlikely to be changed anytime soon by systemd upstream,
> and decide that if that's all you need for your /etc/init.d script, you
> can just ship the unit file and delegate the sysvinit case to the
> start-stop-daemon equivalent.

This will be difficult for services that in the systemd world are
demand-activated to avoid having to specify their dependencies. I am fairly
sure that most people using sysvinit still want to start up services
immediately on boot, which unit files for demand-activated services don't
even describe how to do.

So we might have to invent magic comments still and/or convinve systemd
people that it might be a good idea to have unit files that can support
both immediate and on-demand start.

> Those packages that use more unit file features can still ship an init.d
> script, but at least all those packages that just start/stop a service
> don't need to bother about maintaining yet another shellscript that
> bitrots dangerously over time.

I doubt people really use more unit file features, at least not for user
space services (where the systemd and sysvinit worlds overlap), so that
shouldn't be much of an issue. I still expect some init scripts to stick
around for cases where unit files are not expressive enough, and I expect
that to get worse when systemd actually gets a versioned API.

> I even have a python implementation of most such unit file features that
> I can offer as a starting point, please give me a few days[1] to talk to
> one of my customers about putting it into a public git repo.

I'd still be in favour of adding this to start-stop-daemon, because all
that needs is an unit file parser in addition to its command line parser
(which is already complex). Helpers for socket and dbus activation would
also be possible, but I'm not convinced this is actually what people want.

   Simon

Re: init.d scripts and unit files lexical order or {daily,weekly,monthly} cron jobs?)

[Vincent Bernat]

 ❦ 15 août 2019 14:11 +02, Simon Richter :

> So we might have to invent magic comments still and/or convinve systemd
> people that it might be a good idea to have unit files that can support
> both immediate and on-demand start.

It's already the case. Require the socket for on-demand start, require
the service for immediate start.
-- 
I do desire we may be better strangers.
-- William Shakespeare, "As You Like It"


signature.asc
Description: PGP signature

Re: init.d scripts and unit files lexical order or {daily,weekly,monthly} cron jobs?)

[Simon Richter]

Hi,

On Thu, Aug 15, 2019 at 02:49:32PM +0200, Vincent Bernat wrote:

> > So we might have to invent magic comments still and/or convinve systemd
> > people that it might be a good idea to have unit files that can support
> > both immediate and on-demand start.

> It's already the case. Require the socket for on-demand start, require
> the service for immediate start.

Hmm, if we can just unconditionally start a service even if there is no
incoming connection, then we can just do that from start-stop-daemon with a
small extension. That wouldn't work for Accept=true, though.

   Simon

Re: Making mailcap optional ?

[Michael Stone]

On Thu, Aug 15, 2019 at 08:29:45AM +0900, Charles Plessy wrote:

Please let me know your thoughts (perhaps after waiting a day or two to
let your thoughts mature).


I don't really see a benefit to this. A system capable of running a 
"modern desktop environment" isn't going to notice the "overhead" of 
mailcap.

Re: Git Packaging Round 1: Hopefully Easy Stuff

[Sam Hartman]

> "Philip" == Philip Hands  writes:

Philip> Jonathan Carter  writes:
>> On 2019/08/14 20:02, Sam Hartman wrote:
>>> If you're going to set up a repository for Debian packaging on
>>> Salsa, you need to either:
>>> 
>>> 1) turn off merge requests
>> 
>> That would be quite horrible IMHO, this is the de facto method
>> that young (let's say under 35 years old) developers use to
>> submit improvements to other projects. We have all the
>> infrastructure and tools conveniently in place to accommodate
>> this, it seems suboptimal to treat MRs as a second class citizen.

Philip> Would it not be possible to have a webhook (or similar) that
Philip> could receive notifications of MRs, and automatically create
Philip> a bug report containing the current state of the MR as a
Philip> patch?


It would be possible to have many things.
I think it's great that you're coming up with these ideas, and I hope
that you or someone capture them somewhere.

If such a web hook existed, it would be a great way to make merge
requests available for a certain class of maintainers.

I don't think they fit well into a discussion I'm facilitating about
what our current best practices should be.

While we do sometimes defer choosing a best practice because something
else might be possible, I think that decision to defer articulating what
we have today is rarely in and of itself a best practice:-)

How to use subjects (was: Re: salsa.debian.org partially down)

[Bastian Blank]

Hi Thomas

On Thu, Aug 15, 2019 at 12:22:58PM +0200, Thomas Goirand wrote:
> I probably should have mentioned that my remark was not so much related
> to the crash, but more to what I experienced using Salsa's CI.

If your remarks don't relate to the subject, please start a new thread,
or at least properly change the subject.

Regards,
Bastian

-- 
Dismissed.  That's a Star Fleet expression for, "Get out."
-- Capt. Kathryn Janeway, Star Trek: Voyager, "The Cloud"

Re: Git Packaging Round 1: Hopefully Easy Stuff

[Adam Borowski]

On Wed, Aug 14, 2019 at 10:32:29PM +, Holger Levsen wrote:
> On Wed, Aug 14, 2019 at 09:08:44PM +0200, Jonas Smedegaard wrote:
> > I systematically turn off Gitlab MR support for projects I am involved 
> > in, because I am not confortable and efficient using it myself, it is 
> 
> what helps me is having a note with this line:
> 
> git config alias.mr '!sh -c "git fetch $1 merge-requests/$2/head:mr-$1-$2 && 
> git checkout mr-$1-$2" -'
> 
> which I copy & paste into a shell running inside the directory of a git
> repo, and after that "git mr origin 2" will checkout the merge request #2.

Thanks!

You do want --global for the alias, though -- that removes the need to
repeat the config for every machine:checkout pair, requiring it just once
per machine.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian is one big family.  Including that weird uncle
⢿⡄⠘⠷⠚⠋⠀ and ultra-religious in-laws.
⠈⠳⣄

Re: Git Packaging Round 1: Hopefully Easy Stuff

[Holger Levsen]

On Thu, Aug 15, 2019 at 07:02:37PM +0200, Adam Borowski wrote:
> You do want --global for the alias, though -- that removes the need to
> repeat the config for every machine:checkout pair, requiring it just once
> per machine.

thanks for this as well! :)


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Re: Git Packaging Round 1: Hopefully Easy Stuff

[Vincent Bernat]

 ❦ 14 août 2019 22:32 +00, Holger Levsen :

>> I systematically turn off Gitlab MR support for projects I am involved 
>> in, because I am not confortable and efficient using it myself, it is 
>
> what helps me is having a note with this line:
>
> git config alias.mr '!sh -c "git fetch $1
> merge-requests/$2/head:mr-$1-$2 && git checkout mr-$1-$2" -'

If you prefer, you can avoid to create a local branch with:

git fetch $1 merge-requests/$2/head && git checkout FETCH_HEAD
-- 
"... all the modern inconveniences ..."
-- Mark Twain


signature.asc
Description: PGP signature

Re: Building GTK programs without installing dconf-service?

[Simon McVittie]

On Wed, 14 Aug 2019 at 22:53:33 +0200, Jonas Smedegaard wrote:
> Quoting Simon McVittie (2019-08-14 22:20:05)
> > The preferences stored in this way are not vitally important, so 
> > perhaps it would be OK for them to just not be propagated outside the 
> > application or stored after it exits (with a warning on stderr) if the 
> > GSettings backend is missing; but it isn't obvious to me that there 
> > would be consensus about that not being a (RC?) bug, which is why I 
> > asked.
> 
> Would it be fair to describe both widget and application needs for 
> file-based config backend as required in "all but unusual 
> installations."

At least that strong, perhaps stronger. The definition of Depends in
Policy says "required for the depending package to provide a significant
amount of functionality", so GTK's settings probably don't qualify for
that, but application configuration maybe does.

I'm a little surprised that Policy §7.2 doesn't have anything to say
about packages having enough Depends to make the package work correctly,
work as designed or work without data loss, but perhaps that's considered
to be unnecessary, on the principle that Policy doesn't have to enumerate
every possible wrong thing.

> Based on your enlightening me above, I'd say that libgtk-3-0 should 
> recommend those backends, and consumers of the config API provided by 
> libgtk-3-0 should also (ideally only by default, possible to 
> relax/tighten by each concrete package) recommend those backends as 
> well.

This is not currently implementable without bypassing dh_installgsettings,
which doesn't currently have any way to add a weaker dependency than
Depends. I'll open a feature request at some point.

The conservative default would be Depends to avoid data loss
(configuration not being stored), but in any case debhelper can't
change its default for this without a compat bump: that would be an
incompatible change, and in particular packages don't normally use the
${misc:Recommends} substvar, so moving from Depends to Recommends without
per-package changes would in practice result in no relationship at all,
which is definitely too weak.

> > If libgtk-3-0 only had a Recommends on 
> > libatk1.0-0 (because libgtk-3-0 contains both GDK and GTK, and 
> > strictly speaking you can use GDK without ATK, as long as you don't 
> > also link to GTK), I think there would be consensus that it would be 
> > wrong to consider "libgtk-3-0 should depend on libatk1.0-0" to be 
> > not-a-bug.
> 
> Not sure I follow you above.

Sorry, this makes a rather less obvious example if you aren't familiar
with the libraries in question...

libgtk-3-0 contains libgdk-3.so.0 (GDK), a lower-level library,
and libgtk-3.so.0 (GTK), a higher-level library that depends on GDK.
Basically all users of these libraries depend on both, either because
they use both or because they only use the higher-level GTK, which depends
on the lower-level GDK itself; that's why the two libraries are combined
into a single binary package.

libgtk-3.so.0 (GTK) has an ELF DT_NEEDED relationship with
libatk-1.0.so.0, but libgdk-3.so.0 (GDK) doesn't.

If a program is linked to libgdk-3.so.0 (GDK) only, it can work without
libatk-1.0.so.0 being installed, so the libgtk-3-0 package does have some
(very niche) functionality without libatk-1.0.so.0. (I am not aware of
any specific programs that genuinely do this.)

If a program is linked to libgtk-3.so.0 (GTK), it cannot work at all
without libatk-1.0.so.0 being installed: ld.so exits with an error before
any user code has the opportunity to run.

I don't think it would be appropriate to weaken libgtk-3-0's
${shlibs:Depends} on the package that contains libatk-1.0.so.0 to a
Recommends, and then respond to the resulting grave bug report by saying
"well, *technically*, you *might* only be using GDK, so a Depends is too
strong", because in practice it's vanishingly rare to depend on GDK but
not GTK, and the failure mode when you depend on GTK but don't have its
library dependencies is that the program doesn't work at all.

(This is not about crashing or segfaulting, and is not about whether you
call particular functions; it's about whether the program can even reach
the beginning of main().)

smcv

Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

[Simon McVittie]

On Thu, 15 Aug 2019 at 09:54:44 +0100, Ian Jackson wrote:
> Do we have a list of all the things this is (or might be) used for ?

As I said, I don't think a comprehensive list is feasible without
resorting to something like codesearch, because it's of similar scope to
a list of reasons to use the hostname (as in gethostname(2)), and indeed
some current uses of the hostname would probably be better to use the
machine ID (if that's possible to do without breaking compatibility,
which in some cases it won't be).

I believe the original reasoning for the D-Bus machine ID (from which
systemd took the idea) went something like this:

- I need to do $something per-machine
- but what if the user decides they don't like their current hostname
  (which after all is user-facing) and changes it to one that is more
  aesthetically appealing? then I won't be able to find the state that I
  previously stored in the home directory, X11 display or whatever is the
  shared resource
- conversely, what if the hostname is not unique among the machines sharing
  the X11 display/home directory/other shared resource, because they
  all think they are called "debian" or "localhost" or similar? then
  they will overwrite each other's state

so "like the hostname, but opaque" is quite a good mental model for it.

The second point (hostname sometimes changing) was exacerbated by the
tendency for some distros to pass a hostname received from DHCP to
sethostname(), although I think (I hope) everyone has now decided that
was a bad idea and stopped doing so.

The dbus commit that switched from hostnames to machine IDs in the X11
autolaunch protocol appears to have been in 2006, which was before
my first commit to dbus - I'm making an informed guess about former
maintainers' motivations here, not stating why I made a decision.
I cannot, now, change how dbus uses machine IDs without breaking backwards
compatibility.

Another precursor of the machine ID is gethostid(), but that's only
32 bits long, which is clearly not enough to be "unique among all UNIX
systems in existence" as its man page claims.

> I wonder if we should in Debian have a "sticky door" policy on the use
> of machine-id, like we do for virtual packages: "please come to -devel
> for a peer review".

I can see the reasoning for suggesting this, but we don't ask for peer
review for uses of other identifying properties like the hostname, MAC
address, chassis serial number, etc., and I don't think it's realistic
to expect the authors of upstream software to come to Debian seeking
permission to use an OS interface. (In some cases the machine ID forms
part of an upstream API or an interface between stored data and the
software, from which Debian maintainers cannot diverge without breaking
compatibility, so the upstream design is relevant here.)

Also, this suggestion appears to be closing (or at least applying glue
to) the door of a stable that has not contained horses for more than a
decade. The concept of a machine UUID is far from new or innovative at
this point.

systemd's machine-id(5) now recommends using a HMAC of the machine
ID with an application-specific key (reference implementation:
sd_id128_get_machine_app_specific()), which is not something that the
D-Bus maintainers thought of back in 2006, but with hindsight is an
improvement over just having one form of the machine ID; but again,
not everything can do this without it being an incompatible change.

(If machine-id(5) already existed, but D-Bus didn't, and I was designing
D-Bus now, then I'd probably be using sd_id128_get_machine_app_specific()
or equivalent for the "is this peer on the same machine as me?" APIs
in the D-Bus specification; but that isn't the order in which things
happened.)

smcv

help

[seydi mouhamadou moustapha ndiaye]

Hello,

I'm a student in computer engineering field from africa and I look for a 
mentor who can  help me to accurate my computer skills mainly on coding.


Bests regards.

Re: unsigned repositories

[Thorsten Glaser]

>JFTR: aptitude (and all other libapt-based frontends) can make use of
>that feature via the config option APT::Sources::With, the commandline
>flag is just syntactic sugar.

Doesn’t match my use case of repository injection for anything
that might call apt later.

I could, perhaps, add stuff to apt.conf.d, if these things are
cumulative, but it doesn’t feel right.

My use case here is to use (unpatched) cowbuilder with pbuilder
to build packages for distributions reaching back from sid to
as far as, sometimes, lucid and sarge, although mostly precise
and wheezy (with the occasional lenny thrown in) are the upper
end these days.

Incidentally, I need these features *more* on the *older*
distros, and for debian-ports.

I agree on [trusted=yes] and Release-less repos being needed
only for the file case (although others reported needing
[trusted=yes] for some remore repos… OBS specifically doesn’t
need it though, they publish Release.gpg and, recently, even
InRelease files nowadays).

bye,
//mirabilos
-- 
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database”  ‣‣‣ Please, http://deb.li/mysql and MariaDB, finally die!

Re: duplicate popularity-contest ID

[Thorsten Glaser]

> Change popularity-contest by transmissing the hostid after it has been
> hashed with the content of /etc/machine-id.

Heh, there is no /etc/machine-id on my Debian system.

I have an …/etc/machine-id in buster and stretch chroots I created
and xenial, bionic and disco pbuilder base.cow directories, and
a /var/lib/dbus/machine-id file on my host system (sid), another sid
chroot, and the stretch chroot.


But depending only on files is the wrong approach anyway.

I’ve published images for Debian/m68k back when I was still
active in the revival business. I *had* preinstalled popcon
but removed the hostid and included running dpkg-reconfigure
in the first-boot-setup instructions. (Maybe few did, but I
reset the package state, so the first apt call would do.)

The thing is, unless you create clones from a running system,
and never distribute an image for others to use, you cannot
just recreate them automatically on first start (otherwise
they’ll likely turn out the same), you need some user input,
outside-world date/time, hardware IDs (MAC addresses are a
start, full dmesg is better) and random bits.

I envision a thing that, while booting a cloned VM/image,
interactively asks the user for some keystrokes and offers
to download random data from a couple of known systems (I
know of four or five and have my own as well) or a manual
URL or by ssh’ing out (ssh -l user host dd if=/dev/urandom
count=4 | dd of=/dev/urandom). — This can only work if the
image is first-booted interactively, though. (It then has
to recreate SSH host keys, popcon ID, and apparently a
machine-id file I know nothing about… plus there are things
you cannot regenerate like filesystem-embedded NFS generation
numbers, crypto and LV names… you might wish to change the
hostname and perhaps the ext2fs label but for doing the same
to swap it needs to be recreated, and ext2fs retains the UUID,
etc.)

Cloning systems is doomed to fail ☹

For my m68k case, it might have been useful to use as bootstrap
image (write it into your swap partition, boot it from TOS,
create new ext4 and debootstrap there, reboot that, mkswap over
the temp image). Others like solutions like ANSI-BEL, Puppet,
preseeding d-i, shell scripts, …

bye,
//mirabilos
-- 
 Beware of ritual lest you forget the meaning behind it.
 yeah but it means if you really care about something, don't
ritualise it, or you will lose it. don't fetishise it, don't
obsess. or you'll forget why you love it in the first place.

Re: Generating new IDs for cloning

[Thorsten Glaser]

>At a glance, there are also unique LVM IDs in /boot/grub/grub.cfg,
>though whether those would need to be changed when cloning I don't know.

Normally, you mount the root filesystem, chroot into it (more complex
than you think, either bind-mount tons of filesystem from the host,
and this is only safe-ish if both run sysvinit, or use grml-chroot,
which does that for you and which I don’t know has been adapted for
the systemd case), then run update-grub there (or dpkg-reconfigure
-plow grub-pc which also takes care of reinstalling the stage1 loader).

Also, update-initramfs -u (or -uk all if you have old *buntu).

Now this rewrites a couple of configuration files…

… when your LVM is also encrypted, and you use the nice grml-crypt
tool to mount the storage, it WILL have a different name than during
normal system operation, and this name will be embedded into the new
configuration… making the next boot fail for different reasons.

Life is hard, don’t clone systems, don’t distribute system images.

(And… do not forget to consider lack of entropy.)

Meh,
//mirabilos
-- 
(gnutls can also be used, but if you are compiling lynx for your own use,
there is no reason to consider using that package)
-- Thomas E. Dickey on the Lynx mailing list, about OpenSSL

Re: Generating new IDs for cloning

[Dominik George]

>than you think, either bind-mount tons of filesystem from the host,
>and this is only safe-ish if both run sysvinit

Like most of the time, your allegation is lacking any facts and sources.

Why should that not work on systemd?

-nik

Re: Building GTK programs without installing systemd-sysv?

[Thorsten Glaser]

Hi Simon,

I ran into the same problem… in a chroot. Due to some bug,
systemd-sysv just did not want to install under cowbuilder
for some time.

I discovered that using the second alternative for *conf
worked: put this into /etc/apt/preferences:

Package: dconf-gsettings-backend
Pin: version *
Pin-Priority: -1

This will cause gconf-gsettings-backend to be used during
the build instead, which does not depend on systemd-sysv.

gl hf,
//mirabilos
-- 
This space for rent.

https://paypal.me/mirabilos to support my work.

Re: Building GTK programs without installing dconf-service?

[Jonas Smedegaard]

Quoting Simon McVittie (2019-08-15 20:55:04)
> On Wed, 14 Aug 2019 at 22:53:33 +0200, Jonas Smedegaard wrote:
> > Quoting Simon McVittie (2019-08-14 22:20:05)
> > > The preferences stored in this way are not vitally important, so 
> > > perhaps it would be OK for them to just not be propagated outside the 
> > > application or stored after it exits (with a warning on stderr) if the 
> > > GSettings backend is missing; but it isn't obvious to me that there 
> > > would be consensus about that not being a (RC?) bug, which is why I 
> > > asked.
> > 
> > Would it be fair to describe both widget and application needs for 
> > file-based config backend as required in "all but unusual 
> > installations."
> 
> At least that strong, perhaps stronger.

Stronger than unusual how?

Are you arguing that an installation where in-memory storage of config 
is fine is perhaps not an "unusual installation" but a "very super 
dooper weird installations" and therefore does not match Debian Policy 
about using Recommends?

Really?


[...]

> > > If libgtk-3-0 only had a Recommends on libatk1.0-0 (because 
> > > libgtk-3-0 contains both GDK and GTK, and strictly speaking you 
> > > can use GDK without ATK, as long as you don't also link to GTK), I 
> > > think there would be consensus that it would be wrong to consider 
> > > "libgtk-3-0 should depend on libatk1.0-0" to be not-a-bug.
> > 
> > Not sure I follow you above.
> 
> Sorry, this makes a rather less obvious example if you aren't familiar 
> with the libraries in question...
> 
> libgtk-3-0 contains libgdk-3.so.0 (GDK), a lower-level library, and 
> libgtk-3.so.0 (GTK), a higher-level library that depends on GDK. 
> Basically all users of these libraries depend on both, either because 
> they use both or because they only use the higher-level GTK, which 
> depends on the lower-level GDK itself; that's why the two libraries 
> are combined into a single binary package.
> 
> libgtk-3.so.0 (GTK) has an ELF DT_NEEDED relationship with 
> libatk-1.0.so.0, but libgdk-3.so.0 (GDK) doesn't.
> 
> If a program is linked to libgdk-3.so.0 (GDK) only, it can work 
> without libatk-1.0.so.0 being installed, so the libgtk-3-0 package 
> does have some (very niche) functionality without libatk-1.0.so.0. (I 
> am not aware of any specific programs that genuinely do this.)
> 
> If a program is linked to libgtk-3.so.0 (GTK), it cannot work at all 
> without libatk-1.0.so.0 being installed: ld.so exits with an error 
> before any user code has the opportunity to run.
> 
> I don't think it would be appropriate to weaken libgtk-3-0's 
> ${shlibs:Depends} on the package that contains libatk-1.0.so.0 to a 
> Recommends, and then respond to the resulting grave bug report by 
> saying "well, *technically*, you *might* only be using GDK, so a 
> Depends is too strong", because in practice it's vanishingly rare to 
> depend on GDK but not GTK, and the failure mode when you depend on GTK 
> but don't have its library dependencies is that the program doesn't 
> work at all.
> 
> (This is not about crashing or segfaulting, and is not about whether 
> you call particular functions; it's about whether the program can even 
> reach the beginning of main().)

If applications cannot even start without libatk then obviously that's a 
dependency (not a recommendation).

Your providing 2 libraries somewhat in concert one with different 
requirements than the other seems to me a good case for using a 
debian/*.symbols file: Only packages actually linking with GTK gets the 
ATK dependency and packages only needing GDK API don't.


 - Jonas

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

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


signature.asc
Description: signature

Re: Building GTK programs without installing systemd-sysv?

[Simon McVittie]

On Thu, 15 Aug 2019 at 20:51:36 +, Thorsten Glaser wrote:
> I discovered that using the second alternative for *conf
> worked: put this into /etc/apt/preferences:
> 
> Package: dconf-gsettings-backend
> Pin: version *
> Pin-Priority: -1
> 
> This will cause gconf-gsettings-backend to be used during
> the build instead, which does not depend on systemd-sysv.

This seems like a bug in gconf-gsettings-backend. gconf versions since
2012 need a D-Bus session bus just as much as dconf does: they have a
similar architecture (clients use D-Bus to talk to a server that handles
writes, to provide change notification and avoid write conflicts),
except that GConf stores many tiny XML files and has a lot more D-Bus
round-trips (because in GConf, reads are also done via D-Bus).

I suspect gconf-gsettings-backend should probably not have Provides
on gconf-backend, since it won't be used unless you specifically ask
for it with GSETTINGS_BACKEND=gconf (because GConf is obsolete, and
automatically storing settings in it would invite apparent data loss
when you install dconf-gsettings-backend, GLib prefers that one, and
the settings in GConf are no longer read) so the practical effect is
that your settings are probably not stored.

smcv

Re: Generating new IDs for cloning

[Thorsten Glaser]

Dominik George dixit:

>>than you think, either bind-mount tons of filesystem from the host,
>>and this is only safe-ish if both run sysvinit

>Why should that not work on systemd?

I wrote safe-ish and deliberately didn’t focus on this
as it’s not relevant for the point I was trying to make.

Longer answer: it’s complicated, but I’m sure there’s
a set of bind and non-bind mounts that will work for
systemd as well.

Back to topic now. Or I’m going pet the cat.

bye,
//mirabilos
-- 
18:47⎜ well channels… you see, I see everything in the
same window anyway  18:48⎜ i know, you have some kind of
telnet with automatic pong 18:48⎜ haha, yes :D
18:49⎜ though that's more tinyirc – sirc is more comfy

Work-needing packages report for Aug 16, 2019

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 1403 (new: 16)
Total number of packages offered up for adoption: 163 (new: 3)
Total number of packages requested help for: 53 (new: 0)

Please refer to https://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   cfingerd (#934415), orphaned 5 days ago
 Description: configurable finger daemon
 Installations reported by Popcon: 86
 Bug Report URL: https://bugs.debian.org/934415

   cgilib (#934416), orphaned 5 days ago
 Description: Simple CGI Library
 Installations reported by Popcon: 47
 Bug Report URL: https://bugs.debian.org/934416

   cvs-mailcommit (#934417), orphaned 5 days ago
 Description: Send CVS commitments via mail
 Installations reported by Popcon: 8
 Bug Report URL: https://bugs.debian.org/934417

   dbview (#934418), orphaned 5 days ago
 Description: View dBase III files
 Installations reported by Popcon: 713
 Bug Report URL: https://bugs.debian.org/934418

   dhcpdump (#934419), orphaned 5 days ago
 Description: Parse DHCP packets from tcpdump
 Reverse Depends: forensics-extra
 Installations reported by Popcon: 989
 Bug Report URL: https://bugs.debian.org/934419

   dhcping (#934420), orphaned 5 days ago
 Description: DHCP Daemon Ping Program
 Installations reported by Popcon: 756
 Bug Report URL: https://bugs.debian.org/934420

   dtaus (#934421), orphaned 5 days ago
 Description: Paperless money transfer with German banks on floppies
 Installations reported by Popcon: 8
 Bug Report URL: https://bugs.debian.org/934421

   gerstensaft (#934422), orphaned 5 days ago
 Description: Frontend for Simple Asynchronous File Transfer
 Installations reported by Popcon: 10
 Bug Report URL: https://bugs.debian.org/934422

   gui-apt-key (#934423), orphaned 5 days ago
 Description: Graphical Key Manager for APT
 Installations reported by Popcon: 202
 Bug Report URL: https://bugs.debian.org/934423

   mailto (#934424), orphaned 5 days ago
 Description: WWW Forms to Mail Gateway
 Installations reported by Popcon: 23
 Bug Report URL: https://bugs.debian.org/934424

   newmail (#934437), orphaned 5 days ago
 Description: Notificator for incoming mail
 Installations reported by Popcon: 627
 Bug Report URL: https://bugs.debian.org/934437

   rbootd (#934433), orphaned 5 days ago
 Description: Remote Boot Daemon
 Installations reported by Popcon: 2
 Bug Report URL: https://bugs.debian.org/934433

   rpl (#934276), orphaned 6 days ago
 Description: replace strings in files
 Installations reported by Popcon: 923
 Bug Report URL: https://bugs.debian.org/934276

   sendfile (#934436), orphaned 5 days ago
 Description: Simple Asynchronous File Transfer
 Reverse Depends: gerstensaft
 Installations reported by Popcon: 101
 Bug Report URL: https://bugs.debian.org/934436

   uucpsend (#934426), orphaned 5 days ago
 Description: Alternative Frontend for UUCP Batching with INN
 Installations reported by Popcon: 1
 Bug Report URL: https://bugs.debian.org/934426

   xxgdb (#934428), orphaned 5 days ago
 Description: An X front-end to the GNU debugger gdb
 Installations reported by Popcon: 271
 Bug Report URL: https://bugs.debian.org/934428

1387 older packages have been omitted from this listing, see
https://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   biniou (#934539), offered 3 days ago
 Description: flexible binary data format in OCaml
 Installations reported by Popcon: 39
 Bug Report URL: https://bugs.debian.org/934539

   caml2html (#934531), offered 3 days ago
 Description: HTML and LaTeX colored syntax from OCaml source files
 Installations reported by Popcon: 8
 Bug Report URL: https://bugs.debian.org/934531

   yojson (#934714), offered 2 days ago
 Description: JSON library for OCaml
 Reverse Depends: botch
 Installations reported by Popcon: 35
 Bug Report URL: https://bugs.debian.org/934714

160 older packages have been omitted from this listing, see
https://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

   autopkgtest (#846328), requested 988 days ago
 Description: automatic as-installed testing for Debian packages
 Reverse Depends: autodeb-worker debci-worker
 Installations reported by Popcon: 1178
 Bug Report URL: https://bugs.debian.org/846328

   balsa (#642906), requested 2881

Re: salsa.debian.org partially down

[gregor herrmann]

On Wed, 14 Aug 2019 08:39:22 +0100, Ian Jackson wrote:

> Alexander Wirt writes ("Re: salsa.debian.org partially down"):
> > It is already recovered. We will investigate where we can extend the
> > ressources. But some misusages (like requesting >1300 merge requests via API
> > on a big project, that in consequence run >1300 ci jobs, that...) can't be
> > solved regardless on how many resources we add. 
> Thanks for the reports from you and Bastian.  Thanks also for having
> the energy and effort to deal with this kind of thing.  It's annoying
> when a thing you're responsible for breaks because of foolish user
> action, and then you have to scramble to fix it.

From what I know, this what not a "foolish user action" but an action
by a dedicated maintainer who enabled salsa-ci for all packages
("projects") of a specific team; so they used a service advertised by
the salsa and salsa-ci teams. That this service doesn't work as
advertised or at least doesn't work for the amount of packages a
medium-sized team might have is deplorable and needs some action but
I don't see any reason for calling this action itself foolish.
 

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Janis Joplin: Cry Baby (live)


signature.asc
Description: Digital Signature

Re: Git Packaging Round 1: Hopefully Easy Stuff

[gregor herrmann]

On Wed, 14 Aug 2019 20:25:05 +0200, Jonathan Carter wrote:

> On 2019/08/14 20:02, Sam Hartman wrote:
> > If you're going to set up a repository for Debian packaging on Salsa,
> > you need to either:
> > 1) turn off merge requests
> That would be quite horrible IMHO, this is the de facto method that
> young (let's say under 35 years old) developers use to submit
> improvements to other projects. We have all the infrastructure and tools
> conveniently in place to accommodate this, it seems suboptimal to treat
> MRs as a second class citizen.


Most MRs I've seen so far on salsa lead to packages not building
anymore.


And I dispute that we have "the infrastructure and tools". Because
gitlab is targetted at single projects of single persons; for a team
you don't know who gets mails about MRs / who has enabled those
notifications. -- Whereas bug reports arrive at the maintainer
mailing list.

(And the poor support for teams in gitlab is a general issue IMO.
But that's another discussion.)
 
> > 2) Monitor them and process them.
> > 
> > I don't want to get into how frequently you look at merge requests just
> > as I don't want to get into how responsive you need to be to the BTS.
> > But I hope we can agree that if you're going to have merge requests
> > enabled that they cannot go into a black hole.
> > 
> > I think the question of whether people should use merge requests is more
> > complex.  Sean pointed out some reasons why we might prefer the BTS.
> > And yet it's clear that many people do find merge requests useful.
> 
> The Debian QA DDPO pages will show you whether you have MRs on the same
> page where you see how many open bugs, RC bugs, lintian errors, etc you
> have. This makes it super easy to notice MRs when doing routine checks
> of your general package health overview.

DDPO is not a useful tool for maintainers with lots of packages and
for teams. (And I don't see any MRs there but that might be
correlated. If you have lots of time, grab a $beverage and load
https://qa.debian.org/developer.php?login=pkg-perl-maintain...@lists.alioth.debian.org
)


Personally I am monitoring MRs and I'm acting on them. But my
enthusiasm about them is quite limited so far. So I think Sam's
attempt in wording ("turn them off or monitor and process them") is
quiter accurate.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Flying Pickets: Road To Nowhere


signature.asc
Description: Digital Signature

Re: Git Packaging Round 1: Hopefully Easy Stuff

[Russ Allbery]

Jonathan Carter  writes:

> The Debian QA DDPO pages will show you whether you have MRs on the same
> page where you see how many open bugs, RC bugs, lintian errors, etc you
> have. This makes it super easy to notice MRs when doing routine checks
> of your general package health overview.

Is there some way for me to get email when there's a new MR, the way that
GitHub does?

Unless there's a push notification, I'm probably not going to remember to
go check something when I'm busy, so I'll probably turn off MRs, even
though I generally agree with you that they're the way a lot of people
prefer to contribute and it's kind of a shame.  But having to poll some
external system is not really viable for me.

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

Re: salsa.debian.org partially down

[Aron Xu]

On Thu, Aug 15, 2019 at 6:23 PM Thomas Goirand  wrote:
> [...]
> 1/ CI Jobs going faster
> 2/ Have a way more workers
> 3/ Don't have all our eggs on the same Google basket
> 4/ Use free software platforms instead of GCE
> 5/ Stop being bound to a single VM provider [1]
>

Would it be more attractive to use dedicated hardware for such a long
running, resource hungry service? We already have quite some servers
running at our hosting partners' places, adding a few more won't be a
hugh problem. Doing so will make the service a lot more reliable and
flexible in the long run, even we can have its own Openstack
installation if the team really like it.

Regards,
Aron

Re: Generating new IDs for cloning

[Dominik George]

>Longer answer: it’s complicated, but I’m sure there’s
>a set of bind and non-bind mounts that will work for
>systemd as well.
>
>Back to topic now. Or I’m going pet the cat.

Well, it *is* on topic. I have been using the same strategy for sysvinit and 
systemd systems for many years with great success, and I would like to know 
what I did wrong.

-nik

Re: salsa.debian.org partially down

[Alexander Wirt]

On Fri, 16 Aug 2019, gregor herrmann wrote:

> On Wed, 14 Aug 2019 08:39:22 +0100, Ian Jackson wrote:
> 
> > Alexander Wirt writes ("Re: salsa.debian.org partially down"):
> > > It is already recovered. We will investigate where we can extend the
> > > ressources. But some misusages (like requesting >1300 merge requests via 
> > > API
> > > on a big project, that in consequence run >1300 ci jobs, that...) can't be
> > > solved regardless on how many resources we add. 
> > Thanks for the reports from you and Bastian.  Thanks also for having
> > the energy and effort to deal with this kind of thing.  It's annoying
> > when a thing you're responsible for breaks because of foolish user
> > action, and then you have to scramble to fix it.
> 
> From what I know, this what not a "foolish user action" but an action
> by a dedicated maintainer who enabled salsa-ci for all packages
> ("projects") of a specific team; so they used a service advertised by
> the salsa and salsa-ci teams. That this service doesn't work as
> advertised or at least doesn't work for the amount of packages a
> medium-sized team might have is deplorable and needs some action but
> I don't see any reason for calling this action itself foolish.

All our services have somewhat limited ressources and need to work for all
developers. To be honest: I do expect from everyone, using any of our
(debian) services, to think before doing things like that. Be it sending a
few thousand mails to our mailing lists, creating a few thousand jobs on
salsa, uploading a few thousand packages, creating a few thousand bugs. 

Alex



signature.asc
Description: PGP signature