Re: ifupdown maintenance

[Vincent Bernat]

On 2024-07-07 15:56, Daniel Gröber wrote:


 From where I'm sitting ifupdown2 is completely out of the question as *the*
Debian ifupdown since it doesn't even support *basic* IPv6 use-cases like
DHCPv6. Upstream community seems nonexistant since this is software by a
corp for a corp where community building was probably never the
goal. Admittedly I didn't look very hard, this is just my impression
currently.


This is quite unfair. Cumulus tried very hard to make ifupdown2 a 
community projects, with notably a presentation at Debconf 14 and 
Debconf 16. One of its killer feature is the ability to go from the 
running state to the target state with one command (ifreload). It never 
took as we prefer old broken software over something not 100% compatible 
and also because it is written in Python and we didn't want Python in 
the base installation.


Since Cumulus has been bought by Nvidia, things have changed and 
development of ifupdown2 is now done behind closed doors. See 
https://github.com/CumulusNetworks/ifupdown2/pull/271#issuecomment-1706260260

Re: Validating tarballs against git repositories

[Vincent Bernat]

On 2024-04-01 12:44, Bastian Blank wrote:


So in the end you still need to manually review all the stuff that the
tarball contains extra to the git.  And for that I don't see that it
actually gives some helping hands and makes it easier.

So I really don't see how this makes the problem in hand any better.
Again the workload of review is on the person doing the job.  Aka we do
fragile manual work instead of possibly failing automatic work.


I think that if Debian was using git instead of the generated tarball, 
this part of the backdoor would have just been included in the git 
repository as well. If we were able to magically switch everything to 
git (and we won't, we are not even able to agree on simpler stuff), I 
don't think it would have prevented the attack.

Firmwares (was Re: Bits from the DPL)

[Vincent Bernat]

On 2024-04-01 18:05, Jonathan Carter wrote:

The included firmware contributed to Debian 12 being a huge success,
but it wasn't the only factor.


Unfortunately, the shipped firmwares are now almost a year old, 
including for unstable. I am following the progress since quite a few 
years and I have seen many possible contributors trying to help and 
fail. The current situation is that Debian does not work well with 
recent AMD-based laptops due to firmware being too old. Therefore, we 
are back at users trying to update the firmware by copying them from 
random places (as for myself, I am using the deb generated by upstream's 
Makefile).


My personal impression is that we are repeating a common scheme in 
Debian: maintainers don't have time to move forward due to the task 
being non-trivial for reasons of our own, people are proposing to help 
(6 people in [1]), but this is ignored by the maintainers as they don't 
have time.


[1]: https://salsa.debian.org/kernel-team/firmware-nonfree/-/merge_requests

Re: inability to resolve localhost to 127.0.0.1 in IPv6-only environments

[Vincent Bernat]

On 2023-12-01 12:30, Simon McVittie wrote:

This does not prevent to have 127.0.0.1. I don't think this is a good use of
time to fix builds broken because there is no IPv4 loopback. This is the
same kind of artificial conditions as the 1-core builders.

Unfortunately, no, it's a bit more complicated than that.


Thanks for your explanation on that!

I retract my position about building on IPv6-only environments and agree 
you should be able to build with an IPv6-only connectivity.

Re: Clarification for broken packages in IPv6-only environments

[Vincent Bernat]

On 2023-11-30 22:42, Dale Richards wrote:

I recently submitted a patch for uvloop that was FTBFS on IPv6-only
builds (#1024079) and it really didn't take very long. While
building/running in IPv6-only environments is not currently mandated in
the Policy it's a fairly safe bet that it could/should be in future
updates, so it makes sense to start making all packages agnostic of IP
version now.


This one seems to be because localhost was resolved to ::1, which is not 
Debian-default configuration where localhost is 127.0.0.1. Also, the 
patch is overly complex and is not upstreamed. While correct (even if 
the original test was testing with and without name resolution), this 
may become a maintenance hurdle in the future.

Re: Clarification for broken packages in IPv6-only environments

[Vincent Bernat]

On 2023-11-30 21:38, Paul Tagliamonte wrote:


Now I would like to know if being able to run in an IPv6-only environment is
a must have feature for any debian package?


I run an IPv6 only LAN on my home network, where I use `jool`, and
`dns64-prefix`+`unbound` to interoperate with legacy IP space. There's
no assigned IPv4 addresses for hosts on that LAN.


This does not prevent to have 127.0.0.1. I don't think this is a good 
use of time to fix builds broken because there is no IPv4 loopback. This 
is the same kind of artificial conditions as the 1-core builders.

Re: Bug#1052004: libcbor: requires source-only upload to transition

[Vincent Bernat]

On 2023-09-15 21:04, Sebastian Ramacher wrote:

Source: libcbor
Version: 0.10.2-1
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

https://qa.debian.org/excuses.php?package=libcbor

Issues preventing migration:

 Not built on buildd: arch amd64 binaries uploaded by bernat
 Not built on buildd: arch all binaries uploaded by bernat, a new 
source-only upload is needed to allow migration


What's the status of throwing away the binaries when doing a 
non-source-only upload? This is a major pain point for me. You upload 
the package a first time as a source-only upload and get an error 15 
minutes later telling you it's NEW and you have to do a binary upload. 
Then, it gets accepted and you need another source-only upload.

Re: Potential MBF: packages failing to build twice in a row

[Vincent Bernat]

On 2023-08-10 14:38, Lucas Nussbaum wrote:

On 08/08/23 at 10:26 +0200, Helmut Grohne wrote:

Are we ready to call for consensus on dropping the requirement that
`debian/rules clean; dpkg-source -b` shall work or is anyone interested
in sending lots of patches for this?


My reading of the discussion is that there's sufficient interest for
ensuring that building-source-after-successful-binary-build works.


There is a bias asking d-devel@. You'll get people with enough time on 
their hands to care about this. Nobody ever complained about not being 
able to build twice in a row for years. We are asking a lot of people to 
fix problems that don't really exist.


I don't have time to deal with the amount of bug reported against my own 
packages (most of them with Python) and just having the social pressure 
to spend time on them make me wonder if I really want to invest time at 
all. If these bugs become RC, so be it.

Re: Potential MBF: packages failing to build twice in a row

[Vincent Bernat]

On 2023-08-05 17:06, Lucas Nussbaum wrote:
Should we give up on requiring a 'clean' target that works? After all, 
when 17% of packages are failing, it means that many maintainers don't 
depend on it in their workflow.


Yes, please, this does not make sense anymore to enforce such a rule 
when it is now easy to use "git clean -fxd" or to build in a chroot. 
Moreover, binary packages in the archive are now built by an official 
builder.

Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie

[Vincent Bernat]

On 2023-07-12 07:54, Gioele Barabucci wrote:


1) It's an extra layer. [...]

2) It's a layer that you cannot ignore when editing the config. [...]


I'd also add 3) It requires Python and various Python libraries. At 
least the CLI tool does.


In some circumstances installing Python and a bunch of libraries is not 
going to be a big issue (e.g., in desktop installs), but for many server 
installations that is an unnecessary new burden.


(To be fair, Lukas opened his email stating that for minimal 
installations sd-netwokd is a more fitting alternative. I just wanted to 
explicitly mention one reason supporting that statement.)


If Python is an option, ifupdown2 is IMO a far better candidate than 
netplan:


1. It reuses the familiar syntax we have with ifupdown
2. It knows how to converge to the provided configuration from the 
running configuration (this makes notably the trivial workflow "let's 
modify the IP address of this interface" just works, but more complex 
scenario like "let's put this interface and IP address in a VLAN on a 
bond devices").


It has been some time since the latest release (almost 3 years), but it 
looks still maintained.

Re: Please, minimize your build chroots

[Vincent Bernat]

On 2023-01-28 13:59, Adrian Bunk wrote:

I am not saying that trying to force maintainers to spend time on such
issues by making them release critical is better, but you are also
creating extra work and frustration for the people who are doing QA work
in Debian.


It also pushes some maintainers to give up on packages. I gave up on 
maintaining any Go package after the whole "everything should compile 
with only one CPU because policy says so" fiasco. The most rare resource 
we have is volunteer time. Creating artificial problems is not helping.

Re: Please, minimize your build chroots

[Vincent Bernat]

On 2023-01-28 00:20, Santiago Vila wrote:

Release Policy exists as a canonical list of what should be RC and > what not, 
and it's intended to avoid stupid discussions like this one.


Extending build-essential is easier than asking many people to do 
pointless work to satisfy a set of non-existing users. It is not like we 
had several reports of people complaining they can't build a package 
because they are in an environment without tzdata. It is not OK to 
create problems to force many volunteers to do extra work.

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Vincent Bernat]

On 2022-09-29 15:01, Michael Stone wrote:

On Wed, Sep 28, 2022 at 09:02:15PM -0600, Sam Hartman wrote:

* Finally, I can use bluetooth on linux with reasonably good audio
 quality!


Aren't they both using the same backend? ldac/aptx weren't in pulseaudio 
for a long time, but they are now. Or is there something else?


Pipewire has AAC, but not in Debian because libfdk-aac is still 
considered non-free by us while everyone else, including the FSF, 
consider it free.

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Vincent Bernat]

On 2022-09-09 04:51, Paul Wise wrote:

On Thu, 2022-09-08 at 17:58 +0200, Dylan Aïssi wrote:


I have been asked several times regarding when Debian will switch its default
sound server from PulseAudio to PipeWire without having an official answer.
Thus, I suppose it's the right time to start a discussion about that.


I switched to PipeWire some time ago. I don't have particularly complex
audio needs (just AUX/headphones on a desktop). When the system is
under load and the CPU throttled, I get choppy audio, which is
especially annoying when the load is caused by a video. That doesn't
happen with PulseAudio and setting the quantum to 2048 is a workaround.

pw-metadata -n settings 0 clock.force-quantum 2048

Probably there are more of these sorts of issues, so I agree we should
switch to it by default sooner rather than later to find the problems.


I also had this issue. This was greatly improved since May and I am now 
using it instead of PulseAudio. Check that you have rtkit-daemon 
installed. It helps.

Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation

[Vincent Bernat]

On 2022-08-27 15:53, M. Zhou wrote:


That's why I still hope ftp team to recruit more people. This is
a very direct and constructive way to speed up everything.
More volunteers = higher bandwidth.
Recruiting more people doesn't seem to have a serious disadvantage.


It does not seem to work. Either people don't want to do that, either 
the FTP team is too picky on the candidates.



I forecast this thread will eventually end up with
"calm down and take a break" solution again.


Yes. Unhappy people will just continue to silently wind down their 
involvement in Debian.

Re: Bug#1017716: ITP: muon-meson -- Meson-compatible build system

[Vincent Bernat]

On 2022-08-19 23:14, Andrea Pappacoda wrote:

Would alternatives really be that bad? What if the current /usr/bin/muon 
was moved to /usr/bin/muon-kde, muon-build was installed to 
/usr/bin/muon-build and /usr/bin/muon was shared between the two 
packages? What issues could it cause?


I don't think users really invoke KDE Muon via the terminal that often 
anyway, it is a Graphical APT frontend...


I think your best bet is to ask KDE maintainers if they can rename the 
executable on their side. As it is likely started from a .desktop, they 
may not mind that.

Re: A mail relay server for Debian Members is live

[Vincent Bernat]

On 2022-07-16 23:49, Pierre-Elliott Bécue wrote:

In the past months, it's been clear that sending mails from an
@debian.org address to some mail providers, including GMail, has become
harder and harder. While user DKIM feature (documented on [0]) can help,
we thought providing a relay server for our users to send their Debian
mail was a more long-term solution.

This service is now operational behind mail-submit.debian.org (AKA
stravinsky.debian.org). Documentation about how to use this service can
be accessed via [1]. The page behind [0] will be updated on the next
release we make of userdir-ldap-cgi.

Mails sent via this server will be DKIM-signed if the from is a
debian.org, debconf.org or ftp-master.debian.org address. If any
additional domain should be considered, feel free to ask.

This server requires an active Debian Account, and that one sets their
mailPassword up (again, see [1]) to be able to use the service. I've
tried to provide some useful tips on the doc.

If you have any question or issue, please don't hesitate to reach out.


Hey!

Would it be possible to also make it available on port 465 without 
STARTTLS? I am using smtp_tls_security_level=secure and 
smtp_tls_wrappermode=yes with my other providers and having 
mail-submit.debian.org on top of that is adding a bit of complexity that 
I would like to avoid if possible.


Thanks.

Re: A mail relay server for Debian Members is live

[Vincent Bernat]

On 2022-07-17 10:29, Dominik George wrote:


tl;dr: DKIM-signed mail is verifiable, but only the headers; the body can be 
tampered with


That's not true. The body is always part of the signature (in a strict 
or relaxed way).


> The Signer/Verifier MUST compute two hashes: one over the body of the
> message and one over the selected header fields of the message.

Re: Bug#1014908: ITP: gender-guesser -- Guess the gender from first name

[Vincent Bernat]

On 2022-07-14 17:14, Russ Allbery wrote:

(Also, due to the limitations and history of naming conventions, the
software is inherently trying to map into a gender binary, which if one is
attempting to capture self-identification is likely to be unhelpful for
many populations, such as ones with lots of people under 30, due to not
having a way to represent nonbinary people.)


This one does not. It maps a first name to male, female, androgynous, 
mostly make, mostly female, or unknown.

Re: Bug#1013132: ITP: BabaSSL -- BabaSSL is a base library for modern cryptography and communication security protocols.

[Vincent Bernat]

On 6/30/22 16:16, Sam Hartman wrote:


However there are some other features from the ITP:

-Support NTLS (formal GM dual-certificate protocol) handshake processing, 
according to GB/T 38636-2020
TLCP
-QUIC API support


Is it compatible with QuicTLS, which is another fork of OpenSSL? Some 
context here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011391. 
QuicTLS has some users already: curl, haproxy, apache, nodejs, ngtcp2.

Re: Firmware: Scope of non-free-firmware

[Vincent Bernat]

 ❦ 10 May 2022 14:30 -06, Sam Hartman:

> 2) We value being able to build from source when we can. We value
> being able to have reproducible builds when we can. We don't want to
> take steps backward in those areas in order to get hardware working
> better.

Is there any firmware that would match this? This seems like a
complication without any current application.

> As a reminder, firmware does sometimes run on the CPU (microcode, UEFI),
> sometimes is software, sometimes is more like data.

I see microcode as a firmware for the CPU. It is loaded into the CPU and
is not executed by the CPU in the regular way (loaded in memory, PC
point to it). We do not distribute non-free UEFI implementation and I
don't see how it would help to use hardware (usually, this is shipped
with the hardware). All the firmwares we are interested in are the ones
that get loaded to a piece of hardware.

[...]
> * Proprietary Nvidia graphics drivers.
>
> Personally I think most if not all of the above are in the same category
> as firmware at least in terms of how I think about them and software
> freedom.

This is quite a stretch. Maybe discuss this later. Otherwise, we will
never have anything.
-- 
Write and test a big program in small pieces.
- The Elements of Programming Style (Kernighan & Plauger)

Re: Seeking consensus for some changes in adduser

[Vincent Bernat]

 ❦ 10 March 2022 11:34 -05, Michael Stone:

 On systems that don't use usergroups for all/some users, doesn't this
 change make all files writable by other users by default?  That would
 seem like a very unsecure change on upgrades (or as a default).
>>>
>>> AFAIK systems that don't use usergroups are already not running in
>>> standard Debian configuration, since we default to USERGROUPS_ENAB being
>>> 'yes' in login.defs (and likewise USERGROUPS 'yes' in adduser.conf).
>>
>>Has it always been the case? On my oldest system, my primary group is "users".
>
> It was always configurable, but was enabled out of the box in hamm...

My system was installed on Potato if I remember correctly (or maybe
Woody, but definitely not older than Potato). But maybe my home was
imported from a SuSE installation and I tweaked something.
-- 
Don't use conditional branches as a substitute for a logical expression.
- The Elements of Programming Style (Kernighan & Plauger)

Re: Seeking consensus for some changes in adduser

[Vincent Bernat]

 ❦ 10 March 2022 11:21 +01, Philip Hands:

>> On systems that don't use usergroups for all/some users, doesn't this
>> change make all files writable by other users by default?  That would
>> seem like a very unsecure change on upgrades (or as a default).
>
> AFAIK systems that don't use usergroups are already not running in
> standard Debian configuration, since we default to USERGROUPS_ENAB being
> 'yes' in login.defs (and likewise USERGROUPS 'yes' in adduser.conf).

Has it always been the case? On my oldest system, my primary group is "users".
-- 
Don't patch bad code - rewrite it.
- The Elements of Programming Style (Kernighan & Plauger)

Re: Bug#1006885: ITP: lumin -- pattern match highlighter

[Vincent Bernat]

 ❦  7 March 2022 18:33 +01, Adam Borowski:

>> lumin highlights matches to a specified pattern (string or regular
>> expression) in files, using color. This is similar to grep with
>> colorized output, but it outputs all lines in the given files, not
>> only matching lines.
>
> .--[ ~/bin/hl ]
> #!/bin/sh
> sed 's/'"$*"'/\c[[1;33m&\c[[0m/g'
> `

grep --color -C4000 pattern

There are other suggestions here:
https://stackoverflow.com/questions/981601/colorized-grep-viewing-the-entire-file-with-highlighted-matches
-- 
Let the data structure the program.
- The Elements of Programming Style (Kernighan & Plauger)

Re: chromium: Update to version 94.0.4606.61 (security-fixes)

[Vincent Bernat]

 ❦ 14 February 2022 22:39 +01, Jonas Smedegaard:

> I am trying hard to read good faith into your last sentence above, but 
> have quite some difficulty reading as anything but you describing 
> unbundling as inevitably leading to disaster.

That's how you should read it.

> Maybe my point was unclear, so let me try again: When maintaining a 
> package with embedded code copies, then please if giving up on 
> unbundling at least file RFP bugreports so that others can help.  Help 
> *you* the package maintainer, who has the final say on when and how such 
> separately packaged dependencies is used to *improve* your maintenance 
> (not make your work harder or drive you towards giving up).

The current state of Chromium is that it wasn't able to catch with
security updates for months (even before Bullseye release). Adding more
source-dependencies is a recipe to make it even more difficult to
provide timely updates.

As I don't maintain Chromium, my opinion has little weight. I am just
stating it to counter-balance the peer pressure on the subject.
-- 
Write clearly - don't sacrifice clarity for "efficiency".
- The Elements of Programming Style (Kernighan & Plauger)

Re: chromium: Update to version 94.0.4606.61 (security-fixes)

[Vincent Bernat]

 ❦ 14 February 2022 10:56 +01, Jonas Smedegaard:

>> I've finally give up and am just using ALL the bundled node packages: 
>> https://salsa.debian.org/chromium-team/chromium/-/commit/a418d219f0217d6398a01c30035d35c42f7a76f1
>> 
>
>> It's not ideal, but at least with this we'll match all of the node 
>> stuff with what upstream is testing, with the single exception of 
>> nodejs itself (which we're still using from debian). The only other 
>> alternative I can think of is to get all the node packages into 
>> debian, and they'd also need to be backported to bullseye. I haven't 
>> looked into this yet, but it might be necessary if upstream breaks 
>> compatibility with nodejs 12. So, uh, if anyone is bored and looking 
>> for some node packages to maintain :)
>
> I fully recognize the pain of maintaining a big package and then on top 
> of that paying attention to packaging a pile of Node.js modules.
>
> It is also, however, a pain to maintain a pile of Node.js modules and 
> then on top of that paying attention to big packages struggling with 
> bundled Node.js modules.
>
> Suggestion: Please consider filing RFP bugreports for each Node.js 
> module that you give up on unbundling.  That is far more helpful towards 
> delegating the work than mentioning deep inside a mailinglist thread 
> without "help needed packaging Node.js modules" as subject.
>
> A next step (independent, not necessarily by you) could then be to 
> user-tag RFP bugs tied to unbundling, to help prioritize those among the 
> many WNPP bugreports.

Unbundling also means that each update may require waiting for many
dependencies, leaving users vulnerable in the meantime. Firefox has a
very good track record with updating both in unstable and in stable
thanks to glandium uploading new version the day after the release. I
don't know what the bundling state is, but even with such a good track
record, it sometimes lag a bit behind upstream due to dependencies.
Currently, Firefox 97 is waiting for a rust update and nothing seems to
go forward. Once someone will move forward, it seems we will have to
also wait a bit on the NEW queue due to the rust update (most of the
time, I think rust gets quickly approved in a day or two). I have myself
switched to the binaries provided by Mozilla. I'll switch back once
unstable is up-to-date again because I am confident this won't happen
often, but I suppose at some point, I will switch to the Flatpak, like I
did for Chromium.

My point is that packaging dependencies independently will just lead us
to difficult to package browsers with maintainers giving up.
-- 
Test programs at their boundary values.
- The Elements of Programming Style (Kernighan & Plauger)

Re: Unplanned freeze?

[Vincent Bernat]

 ❦ 28 January 2022 22:52 +01, Sebastian Ramacher:

>> > http://bugs.debian.org/1004272
>> > I agree that it should have been announced somewhere in addition to the
>> > #debian-devel topic.
>> 
>> Running unstable, are we at risk having problems? Are the packages
>> updated in the last few days being rebuilt?
>
> All potentially affected packages have been rebuilt over the last couple
> of days.

Great, thanks!
-- 
Use library functions.
- The Elements of Programming Style (Kernighan & Plauger)

Re: Unplanned freeze?

[Vincent Bernat]

 ❦ 28 January 2022 12:34 +05, Andrey Rahmatullin:

> http://bugs.debian.org/1004272
> I agree that it should have been announced somewhere in addition to the
> #debian-devel topic.

Running unstable, are we at risk having problems? Are the packages
updated in the last few days being rebuilt?
-- 
Make sure every module hides something.
- The Elements of Programming Style (Kernighan & Plauger)

Re: Cloud team plans for cloud-hosted mirrors

[Vincent Bernat]

 ❦ 26 January 2022 10:04 +01, Marc Haber:

>>> Are the IP ranges of the Cloud Providers registered that badly that
>>> deb.debian.org wouldn't reliably point to the mirrors inside the
>>> provider's infrastructure? Or are the cloud providers' mirrors
>>> differnet from what we expect from a Debian mirror?
>>
>>deb.debian.org is served from fastly and AWS CDNs - so it's outside of most
>>cloud provider's infrastructure.
>
> So it is not possible to hook arbitrary mirrors into deb.debian.org
> and we're dependent on Fastly and AWS here?
>
> I thought it was something more flexible.

This was redir.debian.org. I was very happy with it. I never understood
why we replaced it by something centralized. There were problems with it
and nobody was fixing them, but I think we have never been told exactly
what the problems were. But I can understand how using an external CDN
is less a burden than maintaining a redirector like our customn one or
something like MirrorBrain (not packaged in Debian but used by many open
source projects).

deb.debian.org is just a CNAME to Fastly.

At my location (France, 1st ISP, FTTH; was the same in Switzerland),
Fastly is very slow from time to time (once every two months? less than
100 KB/s). Their support fix it in a day or two once you tell them. I
have switched back to geographic mirrors: ftp.fr and ftp.ch never failed
to deliver good performance.
-- 
Use the fundamental control flow constructs.
- The Elements of Programming Style (Kernighan & Plauger)

Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not

[Vincent Bernat]

 ❦ 25 January 2022 21:51 +01, Jonas Smedegaard:

>> I didn't comment at first because I thought someone else would raise 
>> the idea. But it seems people still like the idea of a NEW queue. Not 
>> me. The NEW queue is a hindrance.
>
> For the record, I don't "like" the NEW queue.
>
> I don't like current copyright laws, and I suspect a fair amount of 
> people involved in Free Software doesn't.
>
> I just don't think the solution is to ignore copyright or licensing 
> statements.

I mentioned it. No need to ignore, just file regular bugs. I said:

> For me, the copyright check is just a bad excuse. People upload
> non-distributable stuff everywhere and it seems the world continue to
> go round. What amount of non-distributable packages is stopped by the
> NEW queue?
-- 
Use the "telephone test" for readability.
- The Elements of Programming Style (Kernighan & Plauger)

Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not

[Vincent Bernat]

 ❦ 21 January 2022 09:51 -05, M. Zhou:

> I'd rather propose choice C. Because I to some extent understand
> both sides who support either A or B. I maintain bulky C++ packages,
> and I also had a little experience reviewing packages on behalf of
> ftp-team.

I didn't comment at first because I thought someone else would raise the
idea. But it seems people still like the idea of a NEW queue. Not me.
The NEW queue is a hindrance. I have stopped contributing to Python
stuff for this reason. Packaging something can take weeks because you
need to upload one package, wait for it to be reviewed, then package the
next one, etc. You could upload many packages at once, but it makes
testing and building more difficult. New contributors may just give up
by the time their first package is accepted. I think we have many
unmaintained packages for this reason (no real stats on my side, but
when a package is several versions late, it's usually a sponsored upload
or one of my packages).

I would propose that there should be a reputation system. You can get
points by uploading stuff without issues and lose them if there are
errors. If you have enough points, you can spend them to skip the check.
But someone would have to implement it and the team being understaffed
for whatever reason (and maybe not convinced by this system), I know
this won't be done (we don't have PPA because FTP team wants to
implement it but no time, we don't have autosigned packages because
nobody has time to implement it, etc).

For me, the copyright check is just a bad excuse. People upload
non-distributable stuff everywhere and it seems the world continue to go
round. What amount of non-distributable packages is stopped by the NEW
queue?

I think we should forego the NEW queue. If people want to check
packages, they can do it once they are in unstable with regular bugs.
Current checks are partly done by Lintian and I suppose people could
watch new Lintian warnings and detect bad packages quickly. This could
be done when src is not NEW as a test. People could loose their upload
rights if they are caught abusing the system (and get DM rights for some
selected packages instead). This could be opt-in if people find this
idea offensive.
-- 
Avoid temporary variables.
- The Elements of Programming Style (Kernighan & Plauger)

Re: ungoogled-chromium?

[Vincent Bernat]

 ❦  7 December 2021 23:35 GMT, Simon McVittie:

> I believe what Vincent meant is that the generic non-Flatpak binaries
> provided by the "Ungoogled Chromium" project are compiled on unknown
> machines and require trusting their submitters, whereas the Flatpak
> binaries provided by Flathub are compiled from the same source
> code provided by the "Ungoogled Chromium" project, but compiled on
> Flathub infrastructure.

Yes.
-- 
Don't stop with your first draft.
- The Elements of Programming Style (Kernighan & Plauger)

Re: ungoogled-chromium?

[Vincent Bernat]

 ❦  7 December 2021 21:46 +01, Mathias Behrle:

>> (I have been running an ungoogled-chromium for a while (ca. a year 
>> ago?), however at that time their chrome wasn't extremely stable so I 
>> gave up again. Does anybody have experience using it recently?)
>
> (Using chromium only as fallback browser if necessary):
>
> Since the removal of chromium from Debian was announced I gave 
> UngoogledChromium
> on flatpak a try and it runs very stable so far.

Same here. And they are now following security updates closely (in the
past, there could lag two or three weeks behind). Flatpak compiles it
from source (while UngoogledChromium let contributors compile it and
publish the binary because GitHub CI does not allow such resource-heavy
build).
-- 
After all, all he did was string together a lot of old, well-known quotations.
-- H. L. Mencken, on Shakespeare

Re: Bug#995189: RFH: isc-dhcp

[Vincent Bernat]

 ❦ 28 September 2021 13:04 -05, Richard Laager:

> Are you saying "everything breaks" as in:
> A) the change is not applied (correctly) in the way that it would be if
>the system was rebooted, or
> B) the change is applied, but the human made a mistake in the config and
>the change breaks things, or
> C) B + the human gets cut off from e.g. SSH due to the error?
>
> I would say (generally) that A is a bug, B is inherent to any tooling
> applying a human's instructions, and C can be addressed by a rollback 
> function.
>
> `netplan try` covers C (and thus also B).
>
> `netplan apply` (and thus `netplan try`) have a caveat that they don't
> remove virtual devices that are no longer described in the config.
> This feels like an example of A, though it's arguable how much it
> matters.

I am saying: remove the IP address from an interface, move it to a VLAN
instead. You'll get a duplicate IP.

>> ifupdown2
>> is smart and will converge to the new configuration. Network Manager can
>> restart and minimize impact. AFAIK, systemd-networkd is as dumb as
>> ifupdown and does not know how to converge.
>
> What does converge mean in this context? Is something needing to apply
> parts of the changes iteratively to arrive at the desired state?

It makes a diff between the current system state and the desired state
and applies actions to move to this state. The current system state
could be from a previous application of the tool or from manual action
from the operator, it does not matter (this is a second advantage of
such a tool). The above situation is handled perfectly.

>> My point is that ifupdown2 was a possible successor to ifupdown but was
>> never adopted because written in Python. As netplan is written in
>> Python, ifupdown2 seems a far better replacement.
> Am I understanding correctly that ifupdown2 is an alternative to
> systemd-networkd and NetworkManager (as opposed to netplan, which is a 
> layer on top of them)?

Yes.
-- 
Don't use conditional branches as a substitute for a logical expression.
- The Elements of Programming Style (Kernighan & Plauger)

Re: Bug#995189: RFH: isc-dhcp

[Vincent Bernat]

 ❦ 28 September 2021 11:16 -05, Richard Laager:

>>> As to what should be the distro default, I'm not sure I am convinced
>>> either way, but to argue the other side... There is some value in
>>> using netplan by default. Some random thoughts:
>> [...]
>> OTOH, netplan is just an abstraction above existing systems
>
> Agreed.
>
>> and does not
>> allow proper reconfiguration.
> What do you mean?

Make a change, reload your configuration, everything breaks. ifupdown2
is smart and will converge to the new configuration. Network Manager can
restart and minimize impact. AFAIK, systemd-networkd is as dumb as
ifupdown and does not know how to converge.

My point is that ifupdown2 was a possible successor to ifupdown but was
never adopted because written in Python. As netplan is written in
Python, ifupdown2 seems a far better replacement.
-- 
... A solemn, unsmiling, sanctimonious old iceberg who looked like he
was waiting for a vacancy in the Trinity.
-- Mark Twain

Re: Bug#995189: RFH: isc-dhcp

[Vincent Bernat]

 ❦ 28 September 2021 01:29 -05, Richard Laager:

> As to what should be the distro default, I'm not sure I am convinced
> either way, but to argue the other side... There is some value in
> using netplan by default. Some random thoughts:
[...]

OTOH, netplan is just an abstraction above existing systems and does not
allow proper reconfiguration. ifupdown2 is also written in Python and
has an implementation of "ifreload -a" which just works.
-- 
Use statement labels that mean something.
- The Elements of Programming Style (Kernighan & Plauger)

Re: Debian package manager privilege escalation attack

[Vincent Bernat]

 ❦ 12 August 2021 10:31 +02, Ansgar:

>> I give myself password less sudo to "apt update" (without additional
>> options), "apt upgrade" (same), "apt full-upgrade" (same). I was
>> thinking this should be safe, but now I need to check if the pager is
>> properly restricted when displaying NEWS file.
>
> These are not safe to be run under `sudo` without giving the invoking
> user full access. As a random example: dpkg's conffile prompt offers to
> open a shell.

Ack. I'll avoid this from now on.
-- 
Keep it simple to make it faster.
- The Elements of Programming Style (Kernighan & Plauger)

Re: Debian package manager privilege escalation attack

[Vincent Bernat]

 ❦ 12 August 2021 11:38 +05, Andrey Rahmatullin:

>> >> I just ran across this article
>> >> https://blog.ikuamike.io/posts/2021/package_managers_privesc/ I tested
>> >> the attacks on Debian 11 and they work successfully giving me a root
>> >> shell prompt.
>> > I don't think calling this "privilege escalation" or "attack" is correct.
>> > The premise of the post is "the user should not be a root/admin user but
>> > has been assigned sudo permissions to run the package manager" and one
>> > doesn't really need a long article to prove that it's not secure.
>> 
>> I think the article is interesting nonetheless. Some people may think
>> that granting sudo on apt is OK. 
> Some people may think granting sudo to vim is OK, but we need to educate
> in general that some programs can run other programs, and so restricted
> sudo is not as restricted as it sounds.

That's the point of the article, isn't it? Your example is how I got
fast-forwarded admin when I was at school/uni. So, it's unlikely to
change.
-- 
Habit is habit, and not to be flung out of the window by any man, but coaxed
down-stairs a step at a time.
-- Mark Twain, "Pudd'nhead Wilson's Calendar

Re: Debian package manager privilege escalation attack

[Vincent Bernat]

 ❦ 12 August 2021 10:39 +05, Andrey Rahmatullin:

>> I just ran across this article
>> https://blog.ikuamike.io/posts/2021/package_managers_privesc/ I tested
>> the attacks on Debian 11 and they work successfully giving me a root
>> shell prompt.
> I don't think calling this "privilege escalation" or "attack" is correct.
> The premise of the post is "the user should not be a root/admin user but
> has been assigned sudo permissions to run the package manager" and one
> doesn't really need a long article to prove that it's not secure.

I think the article is interesting nonetheless. Some people may think
that granting sudo on apt is OK. In the past, I think "apt install
./something.deb" was not possible.

I give myself password less sudo to "apt update" (without additional
options), "apt upgrade" (same), "apt full-upgrade" (same). I was
thinking this should be safe, but now I need to check if the pager is
properly restricted when displaying NEWS file. A similar
"vulnerability" was fixed in systemd:

 - https://gtfobins.github.io/gtfobins/systemctl/
 - 
https://github.com/keszybz/systemd/commit/612ebf6c913dd0e4197c44909cb3157f5c51a2f0

Maybe it would be worth to also set LESSSECURE (less is not the default
pager on minimal installs but I think it is the most common, more cannot
be secured this way).
-- 
Use data arrays to avoid repetitive control sequences.
- The Elements of Programming Style (Kernighan & Plauger)

Re: Steam Deck: good news for Linux gaming, bad news for Debian :(

[Vincent Bernat]

 ❦ 11 August 2021 11:27 +02, Steffen Möller:

> I have no exact idea what to change, though. A rolling Debian would be
> cool, yes, but also a bit late when compared with environments that
> Conda offers or the ease that comes with multiple installations of conda
> to e.g. avoid name conflicts. If we had a chroot for which you do not
> need to be root, then together with snapshot.d.o we would be darn close
> to what Conda is offering. I have no idea how to get there, though. With
> singularity maybe?

We package only a very small subset of Conda, I don't see in what
universe we could be competitive, rolling or not rolling.

I think we have more systemic issues. I am quite impressed how Nix/NixOS
is able to pull so many packages and modules with so few people. But
they use only one workflow, one way to package, one init system, etc.
Looking at Arch, one workflow, one way to package, one init system, etc.
Looking at Fedora, one workflow, one way to package, one init system.
Let me take again the example with Nix. Anyone can do a simple pull
request and gets its change accepted. Each package has a maintainer, but
the ownership is quite weak. The maintainer may say no, but if they are
just busy, someone else may merge the change if it looks reasonable.

In Debian, we have many workflow (BTS, MR to submit changes, Git, not
Git, Git workflow 1, Git workflow 2, Git workflow 3), many ways to
package (just one makefile, old debhelper, new dh), many init systems.
And the ownership problem prevents people to help from time to time.
There are so many packages I come accross that could just be updated to
a more recent version and looks like semi-abandoned but I just don't try
any more because there are so many ways to fail.

I still trust Debian to be the most technically excellent distribution,
but that's not all it makes to stay relevant. My point is that it would
help to reduce the technical liberties we take in Debian. However, I
don't think that's who we are.

Today, it is very difficult to only use Debian own packages. We just
tell people "just add random repositories". Nix and Arch are able to
have almost everything packaged. Nix is able to include into a single
workflow most other language ecosystems.
-- 
The last thing one knows in constructing a work is what to put first.
-- Blaise Pascal

Re: Making Debian available

[Vincent Bernat]

 ❦ 23 janvier 2021 15:39 +02, Jonathan Carter:

> But the sentiment above and in other similar messages were that the
> completely free images are broken for many users that might need some
> non-free firmware. This is simply not true. I've only ever installed
> using the free images, and then afterwards just install the firmware
> packages I actually need. On all my thinkpads this was typically just
> the intel wifi firmware, which is super quick and simple, on my AMD
> laptop I needed some amd graphics firmware which wasn't on the media,
> but also a very quick install and it works flawlessly, so I think
> implying that the free images are completely unusable for people who
> might need firmware is an unreasonably large stretch. I also like that I
> know exactly which non-free firmware packages are installed on my
> system.

This is an anecdotical evidence. To my knowledge, it's not possible to
make a wireless card work without a proprietary firmware. As laptops are
getting thinner, the Ethernet port is getting away and dongles to get
port the RJ45 port are not bundled anymore.

> Again, I'm not saying that there shouldn't be images that contain
> non-free firmware, but dismissing the images that don't have firmware on
> as useless is harmful and misleading.

If a novice user is presented with "download this image if you need
non-free firmware", "download this image otherwise", they will likely
choose the second, won't they? We would just succeed in confusing our
users and send them to a more friendly distribution.

As for myself, firmwares were burnt in a ROM before, they didn't get
less free by being side-loaded but at least they can now be updated. So,
I really don't care about how many firmwares I have on my laptop.
-- 
Avoid temporary variables.
- The Elements of Programming Style (Kernighan & Plauger)

Re: [External] Re: Intel SOF audio firmware packaging

[Vincent Bernat]

 ❦ 11 décembre 2020 20:36 -05, Mark Pearson:

>> They seem to say future releases will be tagged. So, I think you should
>> use in gbp.conf:
>> 
>> upstream-tag = v%(version%~%-)s
>> pristine-tar = False
>> 
>> No need for upstream-branch since you won't use "gbp import-orig" as the
>> origin lives directly in git repository.
>> 
> Got it - I've made these changes and pushed them to the repository

You need to use "~rc" instead of "-rc", otherwise, users won't be able
to upgrade to "1.6" when they have "1.6-rc3" installed.

#v+
diff --git a/debian/changelog b/debian/changelog
index 1b404ac5e2e6..a5a29a905188 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,4 +1,4 @@
-firmware-sof (1.6-rc3-1) UNRELEASED; urgency=medium
+firmware-sof (1.6~rc3-1) UNRELEASED; urgency=medium

   * Initial release. (Closes: #960788)

diff --git a/debian/gbp.conf b/debian/gbp.conf
index 12bd6acf629c..ac06bdd3b375 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -1,5 +1,5 @@
 [DEFAULT]
 debian-branch = debian/latest
-upstream-tag = v%(version%-%-)s
+upstream-tag = v%(version%~%-)s
 pristine-tar = False

#v-

> What do I need to do going forward to look after this? Is there anything
> in particular that is needed as new sof firmware is released? Just
> wanting to check what expectations are going forward and if there is
> anything I should be looking out for etc.

We wait until monday and then we can upload. When a new firmware is
released, you upgrade your repository on Salsa, ping me, I'll review and
upload. At some point, you may want to become a DM (Debian Maintainer)
to do upload of known packages yourself.

>> Also, did you test the package on real hardware or do you need me to
>> test it? I can test it, I just need to spend 10 minutes doing it.
> Tested on my X1Carbon7 and it works well. I have a bunch of other
> platforms I can try it on too if that helps but it will have to be next
> week.

No need, I'll test it on mine during the week-end.
-- 
It is often the case that the man who can't tell a lie thinks he is the best
judge of one.
-- Mark Twain, "Pudd'nhead Wilson's Calendar"

Re: [External] Re: Intel SOF audio firmware packaging

[Vincent Bernat]

owner 960788 markpear...@lenovo.com
quit

 ❦ 11 décembre 2020 12:15 -05, Mark Pearson:

>>> I did have to comment out "overlay = True" in the gbp.conf - it gave me
>>> an error that I'll have to dig into.
>> 
>> That's because you went for the first "classic" solution. I was pushing
>> for the overlay solution as the upstream git repository is pushing some
>> big files at each release and your git repository will become bigger and
>> bigger. With the overlay solution, you only have a debian/latest branch
>> and the user is expected to retrieve the tarball to make it work (this
>> is automated by uscan, thanks to the debian/watch).
> Ah - that makes sense.
> Should I be looking at changing what I've done or is the current
> solution OK? I'd like to get it as right as it can be.
>> 
>> However, you can keep your repository as is and add to gbp.conf:
>> 
>> upstream-branch = stable-v1.6
>> upstream-tag = v1.6-rc3
>> pristine-tar = False
> Great - I've updated the repository with this change. Thank you.
>> 
>> This should do the trick. You may want to tag the upstream commit
>> yourself with upstream/1.6 if you upstream is not consistent with
>> tagging (which seems the case).
> I'm not sure what I need to do here - do I create a tag on my repository
> with the name 1.6 on the v1.6-rc3 branch?
> Just want to make sure I do the right steps :)

Well, for all these questions, upstream versioning strategy is
confusing. There is the branch stable-v1.6. There is the v1.6-rc3 which
is not part of the stable-v1.6 branch. We need to have a stable version
number. Either the branch stable-v1.6 doesn't move anymore or there are
tags, but upstream is inconsistent because there is no tag others than
v1.6-rc3. Other users are complaining about this as well:

https://github.com/thesofproject/sof-bin/issues/25

They seem to say future releases will be tagged. So, I think you should
use in gbp.conf:

upstream-tag = v%(version%~%-)s
pristine-tar = False

No need for upstream-branch since you won't use "gbp import-orig" as the
origin lives directly in git repository.

And you need to use 1.6~rc3-1 in debian/changelog since this is the
version you are packaging (1.6~rc3 and the -1 is the Debian part).
1.6~rc3 orders before 1.6 while 1.6-rc3 orders after, that's why we want
to use "~", while upstream uses "-".

Also, debian/watch is incorrect as it is watching branches instead of tags.
You need to fix it with:

version=4
opts="filenamemangle=s%(?:.*?)?v?(\d.*)\.tar\.gz%@PACKAGE@-$1.tar.gz%;s%-rc%~rc%"
 \
 https://github.com/thesofproject/sof-bin/tags \
 (?:.*?/)?v?(\d.*)\.tar\.gz debian uupdate

You can test with "uscan --report --verbose".

As for using an overlay or not, let's stick to your current strategy. If
the repository becomes too big, it's always possible to start a new one.
Not using an overlay is easier for everybody since it's the most common
workflow.

>> You may want to either rename firmware-sof-signed.install to install or
>> rename postinst to firmware-sof-signed.postinst. The #!/bin/sh is
>> missing at the top of the postinst script.
> I think I've fixed this now

You also added "#v+" and "#v-" markers. It was not part of the file.
Some mailers use this to mark code blocks, that's why I have added them.
It was unclear, sorry.

Also, nitpicking, but either use:

 - firmware-sof-signed.install and firmware-sof-signed.postinst
 - install and postinst

Since you have only one binary package, it's equivalent, but it's just
better to not mix the two.

Everything else looks good.

> As I understand it the next step is to find a DM or DD who can sponsor
> this? Any recommendations on how that process works?

Usually, you can go through mentors.debian.net, upload your package
there and file an "RFS" (request for sponsor). But you don't really need
to do that as I can upload it for you. So, fix the last details above,
I'll do another review and I'll upload if anything is correct.

Also, did you test the package on real hardware or do you need me to
test it? I can test it, I just need to spend 10 minutes doing it.

We should also take over the RFS. We were a bit fast in this process. I
am doing that in this email as well for you (with you as owner). We'll
wait a few days if anyone protests.
-- 
Be careful of reading health books, you might die of a misprint.
-- Mark Twain

Re: [External] Re: Intel SOF audio firmware packaging

[Vincent Bernat]

 ❦ 10 décembre 2020 12:57 -05, Mark Pearson:

> I did have to comment out "overlay = True" in the gbp.conf - it gave me
> an error that I'll have to dig into.

That's because you went for the first "classic" solution. I was pushing
for the overlay solution as the upstream git repository is pushing some
big files at each release and your git repository will become bigger and
bigger. With the overlay solution, you only have a debian/latest branch
and the user is expected to retrieve the tarball to make it work (this
is automated by uscan, thanks to the debian/watch).

However, you can keep your repository as is and add to gbp.conf:

upstream-branch = stable-v1.6
upstream-tag = v1.6-rc3
pristine-tar = False

This should do the trick. You may want to tag the upstream commit
yourself with upstream/1.6 if you upstream is not consistent with
tagging (which seems the case).

You may want to either rename firmware-sof-signed.install to install or
rename postinst to firmware-sof-signed.postinst. The #!/bin/sh is
missing at the top of the postinst script.

Most firmware-* packages seem to ship to /lib/firmware, not
/usr/lib/firmware. As I am using a usr-merged system (this is the
default now), I don't see a difference. From my understanding, in the
future, packages need to ship this way. I think Linux will look into
/lib/firmware only and therefore, this will fail on non-usr-merged
systems. You can fix that by modifying the install file with:

builddir/usr/lib /

In debian/control, you also need to add Vcs-Browser and Vcs-Git fields
to point to Salsa. Also, maybe the source pakcage could be
`firmware-sof` instead of sof-bin, to match your repository name. Just
update debian/control and debian/changelog.

Everything else looks OK for me.
-- 
Make it right before you make it faster.
- The Elements of Programming Style (Kernighan & Plauger)

Re: Intel SOF audio firmware packaging

[Vincent Bernat]

 ❦  7 décembre 2020 08:57 -05, Mark Pearson:

> I'd like to solve the lack of Intel SOF audio firmware & topology
> files being available on Debian - I know it's impacting a lot of users
> on some of the newer Thinkpads. I figured I should have a stab at this
> exercise myself and see what happens.
>
> I did a bit of reading this weekend, and started the process. Having
> created appropriate files under a debian sub-dir, and messed around a 
> bit, now when running 'debuild -us -uc' from the 1.6 cloned branch of
> the sof-bin git repo I end up with a .deb file that I can install and 
> makes audio work. Feels like progress :)
>
> There are plenty of warnings along the way, and it's my first time
> doing this so I'm sure I'm doing all sorts of things wrong (there
> seems like a lot of different options on how to do this); but I
> figured I have a good starting point. I wasn't sure where to go with
> this next.
>
> Is there anybody in the Debian community with the expertise to spend a
> bit of time guiding me through the next steps? I think I need someone 
> who can review what I have done and point out where it needs
> fixing/improving. Once it's good enough then I think I need someone to 
> help me actually get it uploaded and into Debian. There is a bug
> already available (https://bugs.debian.org/960788) if that helps.
> Obviously happy to share all the work I've done in an appropriate
> format if that helps too.
>
> Note - I'm new to packaging, I'm not a SOF expert and I'm not a DM or
> a DD - so someone with patience for dumbass questions would be a
> bonus.

Hello Mark,

I can help you, using the easy way: shipping binary firmwares as
non-free. I don't think this is worth the effort trying to compile from
source while it is not possible to use the compiled firmwares.

You can either use salsa.debian.org or mentors.debian.net to expose your
current work. Tell me if it means something for you or if I need to
explain.
-- 
Avoid temporary variables.
- The Elements of Programming Style (Kernighan & Plauger)

Chromium outdated in unstable

[Vincent Bernat]

Hey!

Chromium is stuck at version 81.0.4044.92 since April. Current stable is
83.0.4103.97 and, like often, it includes many security fixes. It seems
Michael is not currently available and no work is done to update
Chromium to the latest version, both in unstable and stable. Is there
someone familiar enough about the process to update, build and test
Chromium?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958450
-- 
Modularise.  Use subroutines.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: default email client from gsettings

[Vincent Bernat]

 ❦  4 mai 2020 11:23 +02, Jeff:

> The Fedora maintainer for a package for which I am upstream has pointed
> out that it still uses gconftool or gconftool-2, which is way out of
> date and should use gsettings[1].
>
> Unfortunately, my search engine foo is failing me and I can't find the
> right incantation to get gsettings to tell me the default email client.
>
> Would someone mind putting me on the right track?

Maybe:

 xdg-mime query default "x-scheme-handler/mailto"

But unsure if it uses something from gsettings.
-- 
As to the Adjective: when in doubt, strike it out.
-- Mark Twain, "Pudd'nhead Wilson's Calendar"


signature.asc
Description: PGP signature

Re: Salsa update: no more "-guest" and more

[Vincent Bernat]

 ❦ 26 avril 2020 15:04 -07, Russ Allbery:

>> This is not how this is implemented. I am using GitHub and GitLab with
>> 2FA enabled and I am rarely asked to enter any token. Once you get
>> authenticated on a device, it remains for a long time.
>
> Pretty much every time I go to salsa.debian.org, I have to log back in
> again.  The "long time" seems subjectively to be a week or two (or maybe a
> month).  Am I doing something wrong?

You are right. I don't have this issue on hosted gitlab.com, but maybe
it's because I work with it everyday. I have just enabled 2FA on Salsa.
I'll see if you also have to reenter 2FA each time.
-- 
Truth is the most valuable thing we have -- so let us economize it.
-- Mark Twain


signature.asc
Description: PGP signature

Re: Salsa update: no more "-guest" and more

[Vincent Bernat]

 ❦ 26 avril 2020 20:29 +00, Jeremy Stanley:

> You're already seeing quite a few folks responding that being
> required to use an additional application or device each time they
> authenticate would be an inconvenience to them. This is a signal. I
> personally wouldn't enjoy being prompted to activate my TOTP client
> software every time I invoke `git push` so I can understand the
> resistance to your proposal.

This is not how this is implemented. I am using GitHub and GitLab with
2FA enabled and I am rarely asked to enter any token. Once you get
authenticated on a device, it remains for a long time. The model threat
is to prevent someone stealing your password through
phishing/spying/guessing to login into your account. SSH keys being
asymmetrical, they are not covered by this.
-- 
10.0 times 0.1 is hardly ever 1.0.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#958908: ITP: bgpq4 -- automatic BGP filter generator using IRR routing data

[Vincent Bernat]

Package: wnpp
Severity: wishlist
Owner: Vincent Bernat 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: bgpq4
  Version : 0.0.6
  Upstream Author : Job Snijders
* URL : https://github.com/bgp/bgpq4
* License : BSD 2-clause
  Programming Lang: C
  Description : automatic BGP filter generator using IRR routing data

bgpq4 eases BGP filter maintenance by automatically generating prefix
lists, (extended) access lists, policy statement terms and AS-path lists
using RADB data. It features IPv6 prefix-/access-list support,
aggregation of generated filters and output compatible with Cisco,
Juniper, Mikrotik, Nokia, OpenBGPD and BIRD.

It is a fork of bgpq3.

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl6lpMkSHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5Bw8P/007Ol3MXLxs2b68J0nxz0wLsqw4q+Cb
WMEdff8Hw2isNQuBkaZmOIcR19v7SjuLH1cYi/GgJEtBtTvxSrU/j85/+OHz5wY8
VwAhM8I7qBigwlyvH2GoWq119RyEAcDP+mH+0dekwiG5Rq60m9TuTpaKjx1fkkP2
Q5Zxz+GIxf2XXYOMoDF9ekJIS1H0gh6zqniQS5PV5zmkk7Yc5wI+0ar8QmuiAGMa
8ihn+o0NpANRCOmaRhFpTb/I0CoCX1pw0lpuPTeIQreKddyEKrFLRGjAnOOHQy/r
FarNfDd7ql0RZcU+MSND/KIxy5zSyrY3KdGDi9FunZ6fIGegSMRRWADUtX8waqwF
LmgaGeNZ06va2AvUUp6uBd7qAmHi0I1QzLRY2zDIKkPckOhbqAkB1NYYU9jUjcgc
pyLzy0cyxV4oKawjLB2kuN8tgzJCQRVLiEjze9sFO8tIB3Zb+of6yZiHI9GbI3gD
QUPii0rqZkzwegxbUHXm0l3VbnYC4xqHGhW1SjlZTGnE/Q7uTNBl8UIIbwe8YbpK
DrRJGuLnwZwhYQb0FutfPyEbaLFs7vV7VxhNZ8xGfoK8emDRQuJbyq0aPpBtZGiA
UUycJgn31Itjp6ZBzt4mekD2OOlIBqyrr7lWfjwdiv2TYKrrd71cJ7XvE/Ggo3gT
XHpzescaJu/S
=4Oxg
-END PGP SIGNATURE-

Re: Salsa update: no more "-guest" and more

[Vincent Bernat]

 ❦ 26 avril 2020 14:07 +02, Bernd Zeimetz:

> There are even cli tools that do the same stuff. I'd guess there is at
> least one on Debian.

There is oathtool.
-- 
I dote on his very absence.
-- William Shakespeare, "The Merchant of Venice"


signature.asc
Description: PGP signature

Re: What to do when DD considers policy to be optional? [kubernetes]

[Vincent Bernat]

 ❦ 25 mars 2020 15:57 +01, Jonas Smedegaard:

>> rpm packages record the package license information in a one-line License:
>> field.
>
> Is your point that 9 lines can be reduced to one, or that 100 lines can 
> be reduced to one?
>
> It is legal in Debian to write debian/copyright files looking like
> this:

Redhat also drops the license files in /usr/share/licenses/packagename
without much structure.
-- 
Don't over-comment.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: new kubernetes packaging

[Vincent Bernat]

 ❦ 24 mars 2020 16:30 -07, Russ Allbery:

> On the other hand (and I don't follow this community closely, so apologies
> if I have the details wrong here), my impression is that the Go community
> is not planning to support shared libraries, loves its staticly-linked
> binaries, and makes extensive use of the fact that different packages can
> pin to different versions and this doesn't matter for their intended
> output format (a static binary).

Go supports shared libraries since quite some time but I don't think
it's widely used. Notably, the tooling around it is quite primitive.
Even the plugin system (which is mostly like dlopen() and could be
useful in many cases) is seldomly used.
-- 
This night methinks is but the daylight sick.
-- William Shakespeare, "The Merchant of Venice"


signature.asc
Description: PGP signature

Re: new kubernetes packaging

[Vincent Bernat]

 ❦ 24 mars 2020 16:30 -07, Russ Allbery:

> On the other hand (and I don't follow this community closely, so apologies
> if I have the details wrong here), my impression is that the Go community
> is not planning to support shared libraries, loves its staticly-linked
> binaries, and makes extensive use of the fact that different packages can
> pin to different versions and this doesn't matter for their intended
> output format (a static binary).

Go supports shared libraries but I don't think it's widely used.
Notably, the tooling around it is quite primitive.
>
> Trying to shoehorn the latter into a shared library update model is almost
> certain to fail because it's working at intense cross-purposes to
> upstream.
>
>> This isn't necessarily such a new thing - the scale is new, but the
>> practice isn't. There are several C/C++ libraries in Debian that are
>> specifically designed to be vendored into dependent projects (either
>> because they are not API-stable or to simplify dependency management),
>> like gnulib (which exists as a package, but I think it's only there to
>> facilitate vendoring bits of it?), libstb (which does exist as a
>> separate package with a shared library, but I don't have a good picture
>> of how API- and ABI-stable it is), and libglnx.
>
> Indeed, I have a package, rra-c-util, which is vendored into every C
> package that I personally maintain and package, because it's my version of
> gnulib plus some other utility functions.  I recognize the potential
> concern should a security vulnerability be found in any of its functions,
> and accept the cost of providing security updates for every one of my
> packages that use it.  This still is, in my opinion, a better maintenance
> choice, not so much for Debian but for many non-Debian users of those C
> packages who do not want to (and often get confused by trying to) install
> a shared library as a prerequisite to installing the thing they actually
> care about.  (Also because, like gnulib, rra-c-util consists of a lot of
> different pieces, most of which are not needed for any given package, and
> includes pieces like Autoconf machinery that are tricky to maintain
> separately.)

-- 
This night methinks is but the daylight sick.
-- William Shakespeare, "The Merchant of Venice"


signature.asc
Description: PGP signature

Re: What to do when DD considers policy to be optional? [kubernetes]

[Vincent Bernat]

 ❦ 24 mars 2020 14:18 +01, Julien Puydt:

>> There are other reasons, notably that you speed up builds by having
>> all the source code ready.
>
> Sorry, I don't know much about how go works, but : can't the developer
> just have the deps ready -- and just not commit them to the repo and
> not ship them?

These projects heavily rely on automated builds. Depending on platform,
it may or may not be easy to have shared cache for these builds. If they
have, you have to debug them as well. From their point of view, it's
simpler to deliver the artifacts with the rest of the source code.
Fast, simple and more reliable.

Moreover, the vendor directory is absolutely not a problem for Debian
(except for licensing where you would have to do a repack for stuff not
distributable). Debian just has to ignore the vendor directory and have
all the dependencies ready. The tooling around Go in Debian already
handles that. The problem is the number of dependencies.

> From what I have read in this thread, go developers seem to be about as
> sloppy as javascript ones : put junk together and throw it to the
> world...

That's not comparable. Go is not using micro-dependencies. However, they
don't have optional dependencies, so anything cloud-based has a lot of
dependencies to manage.
-- 
Make it clear before you make it faster.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: What to do when DD considers policy to be optional? [kubernetes]

[Vincent Bernat]

 ❦ 24 mars 2020 05:37 -05, Michael Lustfield:

>> > Kubernetes is already using Go modules. They happen to have decided to
>> > keep shipping a `vendor/` directory but this is not uncommon. It is
>> > often considered as a protection against disappearing modules. So, there
>> > is nothing to be done upstream. And BTW, there are currently 616
>> > dependencies, pinned to a specific version.  
>> 
>> I wonder if the existence of Software Heritage could convince them
>> disappearing modules aren't a problem, or if another service is
>> needed.
>
> I think this is a symptom of the tools being used. Using 'go vendor' is a
> documented step in nearly all golang-based "release tutorials." Most never 
> even
> get as far as considering that maybe their source should have a version,
> because the toolset mentality is "download latest at build time."

With Go modules, that's not true anymore. It will use the minimal
version satisfying the minimal versions specified in go.mod.
-- 
Follow each decision as closely as possible with its associated action.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: What to do when DD considers policy to be optional? [kubernetes]

[Vincent Bernat]

 ❦ 24 mars 2020 10:14 +00, Paul Wise:

>> Kubernetes is already using Go modules. They happen to have decided to
>> keep shipping a `vendor/` directory but this is not uncommon. It is
>> often considered as a protection against disappearing modules. So, there
>> is nothing to be done upstream. And BTW, there are currently 616
>> dependencies, pinned to a specific version.
>
> I wonder if the existence of Software Heritage could convince them
> disappearing modules aren't a problem, or if another service is
> needed.

There are other reasons, notably that you speed up builds by having all
the source code ready. If the vendor/ directory wasn't there, the
presence of `go.sum` would ensure you get something reproducible by
downloading all the deps, but I think it implies a full checkout of all
deps, which can be lengthy. There is also a caching mechanism (local and
remote).
-- 
Make sure every module hides something.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: What to do when DD considers policy to be optional? [kubernetes]

[Vincent Bernat]

 ❦ 24 mars 2020 03:11 +00, Paul Wise:

>> Specifically, as README.Debian states, the vendor/ subdirectory of the
>> source package contains more than two hundred Go libraries.
>
> There are a *lot* of embedded code/data copies in Debian already.
> While it would be nice to remove them, sometimes it isn't possible.
> Often the copies are forked, or upstream refuses to remove them,
> sometimes even though they forgot why they were added in the first
> place. In addition the developer culture in various communities
> encourages embedded copies. I think the best action we can do is send
> patches to upstream projects to switch from vendoring to using the
> native dependency system of the package manager for the related
> language community. ISTR reading that Go has one of those now.

Kubernetes is already using Go modules. They happen to have decided to
keep shipping a `vendor/` directory but this is not uncommon. It is
often considered as a protection against disappearing modules. So, there
is nothing to be done upstream. And BTW, there are currently 616
dependencies, pinned to a specific version.
-- 
Don't just echo the code with comments - make every comment count.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: tmpfiles.d and docker images (was Re: opentmpfiles & opensysusers, and its use in the Debian policy)

[Vincent Bernat]

 ❦ 19 février 2020 13:55 +13, Michael Hudson-Doyle 
:

> So in Ubuntu we got this interesting bug
> https://bugs.launchpad.net/ubuntu/+source/haproxy/+bug/1855140 which can be
> summarized as saying that haproxy doesn't work out of the box in a docker
> container, because it installs a tmpfiles.d snippet but nothing processes
> it (I haven't tried, but I very much expect that the behaviour is the same
> between Debian and Ubuntu here).

The shipped init script contains the appropriate code to create
/run/haproxy. If the user is using the systemd unit file, the directory
was created by tmpfiles.d. If they are using the init script, the
directory is created by the init script. If the user uses neither of
them, there is not much we can do. We cannot create this directory at
install time, since /run can be wiped out on boot (the fact Docker
doesn't do that is likely an implementation detail).

> But the approach I outlined seems simplest and easiest to implement. Does
> it make sense to people here? I can try to work on a patch (although my
> perl isn't the greatest).

The simplest path would be to not do anything. Docker users can add "RUN
install -d -m 2775 -o haproxy -g haproxy /run/haproxy" in their
Dockerfile or work on a solution where the tmpfiles present in the image
are processed when spawning the image (like the fact that
`/etc/resolv.conf` is updated to match the current network
configuration). Adding more non-declarative stuff in postinst scripts
does not seem a good solution for me.
-- 
Don't stop at one bug.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

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

[Vincent Bernat]

 ❦  6 février 2020 10:45 +01, Svante Signell :

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

For individual systems, not running an additional daemon and not wasting
space on disk doesn't seem to be that a weak motivation. On my
workstations, I am disabling the syslog daemon since a long time since I
prefer browsing logs through journalctl and its superior abilities for
filtering (grep, date ranges, services).

People can still install the syslog daemon on their choices. On servers,
I prefer syslog-ng to rsyslog and I configure it to use journald as its
source for local logs as it gives me access to structured logs and more
information.

On non-Linux systems, a arch-specific package could just pull back
rsyslog.
-- 
A man was reading The Canterbury Tales one Saturday morning, when his
wife asked "What have you got there?"  Replied he, "Just my cup and
Chaucer."


signature.asc
Description: PGP signature

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

[Vincent Bernat]

 ❦  6 février 2020 09:50 +11, Dmitry Smirnov :

>> and 2) continuing to use rsyslog isn't an option if the default changes.
>
> No. I just don't want default to change. IMHO rationale for this is weak but 
> everybody keeps arguing that it would not be a big deal. In time we will see 
> how that goes (what could possibly go wrong?) but why do the change in first 
> place?

To not have logs duplicated in two places.
-- 
Use statement labels that mean something.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

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

[Vincent Bernat]

 ❦  5 février 2020 01:01 -05, Scott Kitterman :

> Not particularly useful IMO.  In /var/log/mail.log I can see log entries from 
> all the programs configured to log to the mail facility.  That way I can see 
> the interaction between them.  On a typical server that is for sending mail I 
> often need to see log entries from postfix, clamsmtp, and dkimpy-milter 
> together to understand how a message is (or isn't) making it through the 
> system.
>
> Of course the fact that I can't use all the tools available to manipulate 
> text 
> files to follow or analyze logs is problematic.  If I'm using journalctl, how 
> do I replicate 'tail -f /var/log/mail.loog'?

You can use:

journalctl -f SYSLOG_FACILITY=2
-- 
Its name is Public Opinion.  It is held in reverence.  It settles everything.
Some think it is the voice of God.
-- Mark Twain


signature.asc
Description: PGP signature

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

[Vincent Bernat]

 ❦  4 février 2020 11:30 -08, Russ Allbery :

>> As a heavy user or Rsyslog features I feel that switching default
>> logging system yields no benefits to say the least.
>
> As a heavy user, perhaps you're not the target audience for a default?
> You're going to install rsyslog no matter what, since you know it well and
> use it heavily.  The only effect of this change on you will be a one-line
> change to whatever you use for configuration management for new
> systems.

rsyslog even knows how to directly pull logs from the journal, which
gives you access to stuff not logged to syslog (stdout/stderr of service
files, applications logging directly to journal), as well to structured
logs (comm pid, user, unit and more when the service supports journald
directly).
-- 
Use the good features of a language; avoid the bad ones.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: BITS from the DPL For September/October 2019

[Vincent Bernat]

 ❦ 31 octobre 2019 21:49 +01, Thomas Goirand :

> The idea has always been that it would be on best-effort from people who
> volunteer, without forcing anyone to do any sysv-rc support if they
> don't feel like it. What you describe goes along this line.

I have raised my concern about this a few months ago and it seems this
is not the consensus:

 
 

My impression is that there are some people pushing sysvinit related
work to all maintainers through this policy item but keeping quiet
during discussions like this. A GR would give us a better view of what
the project thinks.
-- 
I do desire we may be better strangers.
-- William Shakespeare, "As You Like It"


signature.asc
Description: PGP signature

Re: Integration with systemd

[Vincent Bernat]

 ❦ 31 octobre 2019 17:51 -07, Russ Allbery :

> I think we should adopt sysusers.d fragments as the preferred mechanism
> for creating system users (with some rules, such as a standard for how to
> name the users and a requirement that the UID be specified as - unless one
> goes through the normal base-passwd registration process).  It supports a
> declarative syntax, doesn't require putting runes of code into a shell
> script, moves us farther down the path towards reducing us of maintainer
> scripts for most packages, and avoids the whole dependency and
> pre-dependency mess with adduser that took forever to sort out.  The
> syntax for sysusers.d is straighforward to parse, and support for
> non-systemd init systems via a trigger or boot-time script (or both) via
> adduser could be easily written, hiding the distinction between init
> systems.
[...]

An alternative for many system users is to use the DynamicUser feature
of systemd.
-- 
Use statement labels that mean something.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Bits from the DPL (August 2019)

[Vincent Bernat]

 ❦  2 octobre 2019 05:47 +02, Jean-Philippe MENGUAL :

> An idea: establishing a time of discussion. At the end, if there is not
> consensus (as Gitlab), there is not. If there is, ensuring every DD can
> still have an opinion via GR or changes proposals in some guidelines
> (Debian Policy, etc). While mails are too much and so long to be
> followed by "silent" DDs, no DD can ignore a GR or a change in the
> guideline, or he is respnosible. Would help for ensuring a full
> consensus, limiting some repeats mails. We do his successfully for DPL
> election.

If a consensus is needed on debian-devel@ldo to get to the next step, we
will never have it. When was the last time we did get a consensus here?
-- 
Whenever you find that you are on the side of the majority, it is time
to reform.
-- Mark Twain


signature.asc
Description: PGP signature

Re: GPL for package under MIT license upstream; repack?

[Vincent Bernat]

 ❦ 24 septembre 2019 10:41 +02, Gard Spreemann :

> A package I maintain (src:gudhi) was mostly under GPL-3+ up to and
> including the current version in the archives. Since then, upstream has
> switched to an MIT license, but with the caveat that many parts of the
> code has GPL dependencies and that "for practical purposes this code is
> GPL-3 for the user" [1].
>
> Instead of having to carefully figure out precisely which parts of the
> code should be considered GPL for the Debian package, I'm tempted to
> consider the whole codebase GPL for this purpose.
>
> Does this sound sane? Are there some particular steps I should follow?
> Should I create a Debian repack of the source where every file's
> copyright header reflects the above, or do I only need to do this for
> (header) files included in the binary packages? Or does it suffice for
> d/copyright to reflect it?

You cannot change the header files. The MIT license requires you to
leave them intact. Just document the license of each file in
d/copyright. No need to tell the whole work is licensed as GPL-3+ (you
may use GPL-3+ in the "wildcard" section of d/copyright if you want to
highlight it).
-- 
Use data arrays to avoid repetitive control sequences.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#939936: ITP: xtl -- basic tools (containers, algorithms) used for xtensor and xeus

[Vincent Bernat]

Package: wnpp
Severity: wishlist
Owner: Vincent Bernat 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: xtl
  Version : 0.6.5
  Upstream Author : QuantStack
* URL : https://github.com/QuantStack/xtl
* License : BSD
  Programming Lang: C++
  Description : basic tools (containers, algorithms) used for xtensor and 
xeus

This package contains additional containers and tools missing from STL
C++14.

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl13dsISHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX50i0P/2hQdi8/hP/3VkEOEd5IHmOg3qzADUcY
FxoRxQ0jnL8Ula0QjCRiCU/aQKD7aQKVlNKeAW1++Trq5UILwG/Q7vLWVJk/7j6C
x8bRusrRMd3txIn8q+XAiFdoaEiZgvmcy+kNd88S92ANBnpDFO95Xcqc7o6eZfXz
HFPvmeN3EpgzJGNp3SjqNyR7/yl3+7tCobx98smfRJVKRODWHdNcMk0kKqoQVH2U
JAjc7FhF+AJtV4z4cGXoQA4XPCiZJtKNa6y+YRQvgw9XXUd4TUMkvExK5Eryidid
N5ad+/hDF7syN/wP4mbQ5iS0Mq1BAfmKU8srDtIFQtFbSeiw12kMAfNOHdxEfXrx
+3lahGCCcXpQLrz+KuCMp1V3jQBFqBO3GjIHHHADKNIOmGGKtJzmF37OZknlVlO9
vlQ8G9PyXTgIK919tFxi62KyVEoucpgLuhaj/tYo/lQ714sI6yTKOGqlvMm4uLnt
6AC5ZVSoLOZeC8xnfchR/GAewhjvCeODFeHLQ840s1aYLI4gbleCtb1kvfP71Z1e
/szgk4HjJ1VwV9CnhybTBXsYc+AzvcxST+cqUeldGTN74dAsNIGqkHsJd4XqIGw+
E1sTsg7SlfQhVR2NzoXLU8hBoxIzf3LIbNOyeDWfIxx1MObOgtPitiTTp82wv0Ob
h0ohhmsQKSSq
=+wJw
-END 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: 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: Please stop hating on sysvinit (was Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?)

[Vincent Bernat]

 ❦ 11 août 2019 10:27 +02, Marc Haber :

>>* Better restart semantics and monitoring of services/ways to configure
>>  restart.
>
> We have, however, failed to make use of that. "systemctl restart" is
> nearly useless in Debian because a non-negligible part of our daemon
> packages make systemd think the daemon is running while it is actually
> not, and systemd does for some reason not to anything in this case.
>
> I have watched myself involuntarily changing to a systemctl stop;
> systemctl start scheme, because this has a way higher chance of doing
> what I want. I haven't dug in deeply in this matter though.

systemd cannot guess if a SysV init script should leave a daemon behind
or not. Therefore, they are converted as "Type=forking", "Restart=no"
"GuessMainPID=no" and "RemainAfterExit=yes". So, when a daemon stops
unexpectedly, it is not restarted and "restart" doesn't work because the
unit is still active.
-- 
Tell the truth or trump--but get the trick.
-- Mark Twain, "Pudd'nhead Wilson's Calendar"


signature.asc
Description: PGP signature

Re: Please stop hating on sysvinit

[Vincent Bernat]

 ❦  9 août 2019 09:22 +02, Martin Steigerwald :

>> Reality seems different. Almost nothing was using inetd (tftpd is the
>
> I note that you wrote "seems". But still:
>
> As if there would just be *one* reality. Actually there is. But I never 
> saw any human being being able to express it in words. So I'd rather 
> not. I believe it can be experienced at any time. But for me it is 
> beyond words and so much else.
>
> With arguing about what reality might be and claiming it is this or 
> such… the trouble starts. Cause then people who somehow dare to manage 
> to experience a different reality can easily be made wrong. I think this 
> has been one of the core issues around the conflicts regarding Systemd. 
> How dare you see things different than me? But you just need to talk to 
> ten people to recall a situation they experienced together and you will 
> receive ten different story. Now: which one would be right?

The one which provides real-world examples. One says "socket activation
is not used for decades, let's just not use it", I say "it is used right
now, see the following examples". You come and you say "I don't use it
with dovecot". Sorry, but upstream did implement socket activation for a
reason, not out of the blue of nothing.
-- 
Treat end of file conditions in a uniform manner.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Please stop hating on sysvinit (was Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?)

[Vincent Bernat]

 ❦  8 août 2019 21:47 +02, Simon Richter :

>> inetd performance is very low because it needs to spawn one instance for
>> each connection. systemd socket activation has absolutely 0 overhead
>> except on the first connection (where systemd needs to start the
>> service).
>
> If you specify "wait" instead of "nowait" for a TCP service, your service
> is handed the listening socket, and can continue to accept more connections
> on that socket.
[...]

My bad, I didn't know that.

> This feature went unused not because noone thought of it, but because there
> is no real world use case that benefits from it. Either the service is used
> regularly, then it makes sense to keep the daemon in memory, or it isn't,
> then the reduced complexity for one-shot services (to the point where you
> can use a shell script as a service) is the benefit.

Reality seems different. Almost nothing was using inetd (tftpd is the
only daemon I have in mind), while many daemons adopted systemd socket
activation. For example, OpenSSH (optional), Docker (by default), CUPS
(by default), libvirt (by default, several services), Dovecot (by
default). It seems the key difference is that socket-activated services
are regular services. They can be started manually if we want them to be
and they inherit everything systemd is able to provide to services.
-- 
Localise input and output in subroutines.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Please stop hating on sysvinit (was Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?)

[Vincent Bernat]

 ❦  8 août 2019 19:10 +02, Simon Richter :

> For servers, the benefit is rather limited. There is no local user who
> makes system-wide policy decisions, and hardware is not changing
> dynamically either. The actual services provided are either implemented as
> daemons (i.e. not microservices), or proper microservices run inside a
> site-wide microservice framework such as Docker+Kubernetes, because a
> system-local framework such as systemd is too limited to express the
> dependencies. System boot time is significantly less important than service
> response time, so "socket activation" for daemons is not useful in this
> context either. We have had this for -literally- decades in the form of
> inetd, and it has not been widely used, precisely for that reason.

inetd performance is very low because it needs to spawn one instance for
each connection. systemd socket activation has absolutely 0 overhead
except on the first connection (where systemd needs to start the
service).
-- 
After all, all he did was string together a lot of old, well-known quotations.
-- H. L. Mencken, on Shakespeare


signature.asc
Description: PGP signature

Re: file(1) now with seccomp support enabled

[Vincent Bernat]

 ❦ 28 juillet 2019 12:11 +02, Philipp Kern :

>> Just a quick note: seccomp filters may need adaptations from one libc
>> to another (and from one kernel to another as the libc may adapt to
>> the current kernel). For example, with the introduction of "openat"
>> syscall, the libc has started to use it for "open()" and the new
>> syscall has to be whitelisted. On the other hand, if you start
>> implementing seccomp filters late, you may have whitelisted only the
>> "openat" syscall while older libc (or current libc running on older
>> kernels) will invoke the "open" syscall.
>>
>> I am upstream for a project using seccomp since a long time and I have
>> never been comfortable to enable it in Debian for this reason. However,
>> they enable it in Gentoo and I get the occasional patches to update the
>> whitelist (I am not doing anything fancy).
>
> But technically it should be possible to test this in an autopkgtest,
> no? I don't think perfect has to be the enemy of good here, as long as
> we can detect breakage and remediate it afterwards?

Yes, but I was thinking to cases where you run kernel from oldstable
with stable for example. This is something currently allowed that may
not work anymore. I am just providing the information, I don't have a
strong opinion if seccomp should or shouldn't be enabled.
-- 
Terminate input by end-of-file or marker, not by count.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: file(1) now with seccomp support enabled

[Vincent Bernat]

 ❦ 19 juillet 2019 17:18 +02, Christoph Biedl :

> Upstream of the file package added seccomp support a while ago, and
> probably everyone with even a small concern about security will agree
> the file program, often being used on dubious or even doubtless
> malicious input, should use seccomp to make the attack surface smaller.
> However I refrained from enabling this feature back then just weeks
> before the buster freeze, in restrospect: indeed the right decision.
> Now this early moment in the bullseye development cycle is a good time,
> so there's version 1:5.37-2, accepted in unstable a few moments ago.

Hello,

Just a quick note: seccomp filters may need adaptations from one libc to
another (and from one kernel to another as the libc may adapt to the
current kernel). For example, with the introduction of "openat" syscall,
the libc has started to use it for "open()" and the new syscall has to
be whitelisted. On the other hand, if you start implementing seccomp
filters late, you may have whitelisted only the "openat" syscall while
older libc (or current libc running on older kernels) will invoke the
"open" syscall.

I am upstream for a project using seccomp since a long time and I have
never been comfortable to enable it in Debian for this reason. However,
they enable it in Gentoo and I get the occasional patches to update the
whitelist (I am not doing anything fancy).
-- 
Use the good features of a language; avoid the bad ones.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: systemd services that are not equivalent to LSB init scripts

[Vincent Bernat]

 ❦ 14 juillet 2019 12:30 -07, Russ Allbery :

> There seems to be a clear infrastructure gap for the non-systemd world
> here that's crying out for some inetd-style program that implements the
> equivalent of systemd socket activation and socket passing using the same
> protocol, so that upstreams can not care whether the software is started
> by systemd or by that inetd, and provides an easy-to-configure way for
> Debian packages to indicate this should be used if systemd isn't in
> play.

What's the point? The alternative to not using systemd socket server is
to run the daemon as usual. If an upstream decides to tie a daemon to
systemd socket server by delegating the socket creation to systemd, why
would we need to implement anything? Don't we have better things to do?
This init diversity crusade is eating our time.
-- 
Make sure every module hides something.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: systemd services that are not equivalent to LSB init scripts

[Vincent Bernat]

 ❦ 14 juillet 2019 19:23 +01, Simon McVittie :

> Some systemd system services are meant to start on-demand via socket
> events (systemd.socket(5)), and can work via inetd on non-systemd-booted
> systems. micro-httpd appears to be an example of this - I'm a bit surprised
> there aren't more. Perhaps this indicates limitations in the infrastructure
> around inetd services making it hard to implement "use systemd.socket(5)
> under systemd or inetd otherwise"?

inetd uses stdin/stdout to communicate with the daemon and have to
launch one instance for each client connecting. systemd.socket pass a
regular listening socket on first connection to the daemon and the
daemon can then serve multiple clients. It is simple to convert an
existing daemon to systemd.socket and it doesn't come with a performance
impact. It can even simplify some aspects of an always-running daemon,
like reloading without impacting the traffic.
-- 
Familiarity breeds contempt -- and children.
-- Mark Twain


signature.asc
Description: PGP signature

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

[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.
-- 
Modularise.  Use subroutines.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Is it the job of Lintian to push an agenda?

[Vincent Bernat]

Hey!

Lintian got a new tag to enforce Policy 9.11:

 Packages may integrate with these replacement init systems by
 providing implementation-specific configuration information
 about how and when to start a service or in what order to run
 certain tasks at boot time. However, any package integrating
 with other init systems must also be backwards-compatible with
 sysvinit by providing a SysV- style init script with the same
 name as and equivalent functionality to any init-specific job,
 as this is the only start-up configuration method guaranteed to
 be supported by all init implementations.

Lintian tag:
 


This tag has false positives, see:
 

Original bug introducing this tag is:
 

The policy update is being discussed here:
 

As usual with a policy change, it will take years. Some people will push
back and the result is that a few people can impose to everyone else the
additional work to maintain SysV init script.

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. Thanks
to this new Lintian tag, the current situation is that packages won't
pass NEW without a SysV init script (unless a FTP-masters ignore this
specific tag despite its severity).

This Lintian tag was introduced by the maintainer of runit in a clear
attempt to push more work towards people not shipping SysV init script.
Could it be just reverted on the ground of the TC statement and the fact
that systemd is not an alternative init?
-- 
Zounds!  I was never so bethumped with words
since I first called my brother's father dad.
-- William Shakespeare, "Kind John"


signature.asc
Description: PGP signature

Bug#883393: ITP: jool -- Open Source SIIT and NAT64 Translator for Linux

[Vincent Bernat]

Package: wnpp
Followup-For: Bug #883393

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey!

Any progress on this? Do you need help packaging?

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl0mDQYSHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5SVQP/2rf1gCpD3aw71BxPFf7xAzwQLaMezWG
0uuJVw6ZLp6bBcYWaOzQsAeit4Je/NkILsCkltKXCVOa2OSr82BMIbeW2tVUnENI
ZXP6sXy0EuTh1Eb+WhutLjIkialCtRgmmgzZWHqyFLWBtsnd+430G8G+/lUso+SX
D3clxPPcPFWhbp8rwoNaaXU7C25pTHfqxUDcdywuBV6pj7LAkxtwuzbkPrWdRR5n
PkAZHYzrABKCFKSM8HnOyW328cOUZ7SkPB5XtwkcO191O/onnrm/XaVEVMXUQR0k
jb6qZ/c0sfEtkn50BiFA/MkEOaFb9xpBZ/3S2pwXLQK7zWNKxCnVSxKO8ig7aS6e
r2aJ25E5/mDai2nzJYSXOSw2TIfvRkEnt4plD4dPF21OzNGs5M3hkytCGuDqUR11
yl9JSdVq+bjq3xiWkQ4TrgyKvBKnHv/VxIsr292lnSUayvkzFY+HS3ATISUdbVCo
pvEpNh7ykxwQzQhAplOVnoppeXA2xNIDzgrHWA/EEqGG8MI6wp1MlJiYunBaKd9C
VG9A5OYeOPGHGZ6pUVbsBdJSshYD3ZcGwqA8gOBoKQRPRN2Lz6O8w4JfwXsp2MTs
ZyZsISTZrdO+A1AHeGb+DcVLOzTHQroBkAzYUDE1HKmUeu7mblyAFzbz0yZZltGm
qGTrTJaInWpa
=fm8W
-END PGP SIGNATURE-

Re: Question about Debian build infrastructure

[Vincent Bernat]

 ❦ 12 juin 2019 14:02 +08, Paul Wise :

>> * I had to patch reprepro to support multiple versions:
>> https://github.com/profitbricks/reprepro
>
> I think it would be very helpful to a lot of derivative distros and
> small or private apt repositories if this patch could be merged
> upstream and made available to Debian users. Has Profitbricks
> considered working on that?

It's https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570623

Maintainer doesn't seem to be interested or have no time to consider the
patch since many years.
-- 
Choose a data representation that makes the program simple.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Do we want to Require or Recommend DH

[Vincent Bernat]

 ❦  4 juin 2019 15:47 +01, Ian Jackson :

> If not, how do you think the question you pose should be answered ?
> Since it is a question of tradeoffs, with no definite right or wrong
> answer, perhaps we should hold a GR ?  What do you think the result of
> such a GR would be ?
>
> I think such a GR would be a collosal waste of time.  This issue is
> not important enough.  In particular, because the consensus is *not*
> that you will *have to* change your packages.  What this discussion
> has mostly concluded is that we should issue a *recommendation*.
> *Not* a mandate.

Well, a GR can be quick and it would help to know where people stand
instead of having a few vocal people decide for everyone. I think we
should impose the use of "dh" for bullseye (with an exception for teams
with more then 50 packages), but I honestly don't know how much this
opinion is shared.

It seems there is a pattern to dissuade people to hold a GR. The last GR
I remember is about changing "Chairman" to "Chair" in our constitution.
I don't remember it was a waste of time and it was pretty quick. And the
last "technical" GR was for systemd in 2014. We are in a project where
it is very hard to be heard because you can only participate in endless
debates.
-- 
Let him choose out of my files, his projects to accomplish.
-- Shakespeare, "Coriolanus"


signature.asc
Description: PGP signature

Re: Difficult Packaging Practices

[Vincent Bernat]

 ❦ 28 mai 2019 06:50 +00, PICCA Frederic-Emmanuel 
:

>> packages. While my Perl is a bit rusty, I can propose some "dh_fetch"
>> helper for this if there is no huge opposition against this approach.
>
> why not a dh_uscan ?
>
> what is the fundamental difference between dh_fetch and what you can
> achieve by using uscan from the rules file ?

Yes, it would work too.
-- 
Use statement labels that mean something.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Difficult Packaging Practices

[Vincent Bernat]

 ❦ 28 mai 2019 06:30 +00, Niels Thykier :

> I.e. with the proper implementation of "make-it-work" (in the lack of a
> better name - maybe something "fetch-and-build"), the following should
> be possible
>
> """
> #!/usr/bin/make -f
>
> # DISTRIBUTION = $(shell sed -n "s/^VERSION_CODENAME=//p" /etc/os-release)
> export VERSION=1.5.16
> # PACKAGEVERSION = $(VERSION)-0~$(DISTRIBUTION)0
> export TARBALL = memcached-$(VERSION).tar.gz
> export URL = https://www.memcached.org/files/$(TARBALL)
>
> %:
> dh $@ --with make-it-work
>
> # override_dh_gencontrol:
> # dh_gencontrol -- -v$(PACKAGEVERSION)
> """
>
> This could inject a tool to run the wget + tar extraction (incl. the
> distro version sed'ing) after dh_testdir and before
> dh_update_autotools_config.  From there, the dh's standard tools would
> "just work(tm)" until dh_gencontrol where we have to inject the full
> version (the commented lines works around that if re-enabled).
>
> @Vincent: Do you feel something like this would be helpful, useful and
> doable? My only reference in the memcached, so the above is tailored to
> the above.

That would be very useful as it would reduce the boilerplate but also
solve some of the problems of hijacking the clean target, notably the
fact it is executed twice by some tools (like pbuilder, once outside,
once inside). I didn't propose anything like that as I was thinking it
was very likely to be rejected as it is of no use for proper Debian
packages. While my Perl is a bit rusty, I can propose some "dh_fetch"
helper for this if there is no huge opposition against this approach.

> Would it help if we could remove the dependency on having a d/changelog
> (i.e. make it optional)?  I have not fully checked if it is doable, but
> I can look into it if it makes sense and if someone wants to help me
> test this.

Yes, it would help too.
-- 
Use library functions.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Difficult Packaging Practices

[Vincent Bernat]

 ❦ 28 mai 2019 08:59 +08, Paul Wise :

>> People using tools like fpm will never get familiar with our tools and
>> will never be contributors.
>
> I enjoyed your blog post about pragmatic packaging using Debian's
> tools instead of fpm, it seems like a good approach if one is
> committed to using Debian, especially since it allows for incremental
> improvement towards a package that could even enter Debian.
>
> https://vincent.bernat.ch/en/blog/2019-pragmatic-debian-packaging
>
> OTOH I get the feeling that most FLOSS upstreams are interested in
> cross-OS and cross-distro packaging rather than Debian-specific
> packaging. I don't have a good feeling for how "sticky" OS/distro
> choices are for folks who are building non-FLOSS services on top of
> FLOSS distros.

Yes, upstreams are more likely to prefer one tool. However, if you
contribute a native implementation that works accross the same set of
Debian-derivative distributions, in my experience, they are usually
eager to accept it it stays simple enough to not be a maintenance
burden. Of course, it helps if they didn't start with fpm.
-- 
Make sure your code "does nothing" gracefully.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Difficult Packaging Practices

[Vincent Bernat]

 ❦ 27 mai 2019 16:15 +10, Ben Finney :

>> If you just want to get upstream's idea of their package onto a system
>> with their release schedule and their recommended dependency versions,
>> there are better ways than getting a package into Debian.
>
> In the Debian mentors forum (that is, the chat channel, the mailing
> list, etc.) we make a point of saying: that's fine!
>
> Not every package needs to be in Debian, for its users to install that
> package. Someone who wants what you describe above can learn how to make
> a Debian package that will only be side-loaded from that community's own
> repository, or whatever.

People using tools like fpm will never get familiar with our tools and
will never be contributors.
-- 
The man who sets out to carry a cat by its tail learns something that
will always be useful and which never will grow dim or doubtful.
-- Mark Twain


signature.asc
Description: PGP signature

Re: Consensus Call: Do We Want to Require or Recommend DH; comments by 2019-06-16

[Vincent Bernat]

 ❦ 26 mai 2019 12:04 +02, Jonas Smedegaard :

>> > * People who make changes across the archive such as enabling 
>> >   hardening, cross-building, bootstrapping, etc benefit 
>> >   significantly from more uniformity in packaging practices.  The 
>> >   time they spend working on packages that use dh is significantly 
>> >   less.  That is, people working on making Debian more reproducible 
>> >   benefit from when we adopt more uniform practices.
>> 
>> It has also been said that non-unformity makes also the life of 
>> everybody more difficult when they look at a random package. This 
>> includes non-DD/DM people. We have a reputation of having difficult 
>> packaging practices. We uphold this reputation as long as we have so 
>> many ways to do the same thing.
>
> We "uphold this reputation" by maintaining many packages, which is
> good.

Do we? I am now using nix to get packages for stuff not in Debian. Our
package count is artificially inflated by *-perl packages, golang-*
packages which may not be present in some other distributions. But for
some ecosystems, we are severely behind. We may argue we are better on
some metrics, but this has nothing to do with the fact we have so many
ways to build a package.
-- 
English literature's performing flea.
-- Sean O'Casey on P. G. Wodehouse


signature.asc
Description: PGP signature

Re: Consensus Call: Do We Want to Require or Recommend DH; comments by 2019-06-16

[Vincent Bernat]

 ❦ 25 mai 2019 13:26 -04, Sam Hartman :

> * People who make changes across the archive such as enabling hardening,
>   cross-building, bootstrapping, etc benefit significantly from more
>   uniformity in packaging practices.  The time they spend working on
>   packages that use dh is significantly less.  That is, people working
>   on making Debian more reproducible benefit from when we adopt more
>   uniform practices.

It has also been said that non-unformity makes also the life of
everybody more difficult when they look at a random package. This
includes non-DD/DM people. We have a reputation of having difficult
packaging practices. We uphold this reputation as long as we have so
many ways to do the same thing.
-- 
Say what you mean, simply and directly.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Do we want to Require or Recommend DH

[Vincent Bernat]

 ❦ 19 mai 2019 23:53 -04, Sam Hartman :

> >> As promised, I'd like to start a discussion on whether we want to
> >> recommend using the dh command from debhelper as our preferred
> >> build system.
>
> Sean> For those who haven't seen it, the original author of dh, Joey
> Sean> Hess, has just published a blog post relevant to the
> Sean> discussion we're having:
>
> I've read the blog post.
>
> I think Joey's points are very consistent with our discussion here.

Is there an example of a package where dh cannot be used? Making 96% of
packages simpler and 4% of packages moderately more complex seems to be
a good argument to uniformize our packaging practices towards dh.
-- 
Use the fundamental control flow constructs.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

[Vincent Bernat]

 ❦  9 avril 2019 08:41 +10, Ben Finney :

>> >> yes, it can be done, but it is a lot more work for individual
>> >> packagers.
>> >
>> > Sure. And, on the other hand, providing an APT repository for arbitrary
>> > packages of unknown copyright status is also a lot of work to expect
>> > disinterested volunteers to do without motivation.
>>
>> Disinterested volunteers are never forced to work for Debian.
>
> Yes, that's why I said “expect” and not “force”.

Being forced is the definition of expect.

"to consider bound in duty or obligated they expect you to pay your
bills" 

>> What is the point of being so negative?
>
> Not sure who you're addressing here, and I'm sorry if the discussion
> appears negative to you.

I am addressing you. You try to dissuade people on the basis this is
work you are not interested to do. If someone was implementing PPA/DPA,
what would be the downside for people not interested in them? None. You
can just ignore the feature.
-- 
Must I hold a candle to my shames?
-- William Shakespeare, "The Merchant of Venice"


signature.asc
Description: PGP signature

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

[Vincent Bernat]

 ❦  8 avril 2019 14:46 +10, Ben Finney :

>> yes, it can be done, but it is a lot more work for individual
>> packagers.
>
> Sure. And, on the other hand, providing an APT repository for arbitrary
> packages of unknown copyright status is also a lot of work to expect
> disinterested volunteers to do without motivation.

Disinterested volunteers are never forced to work for Debian. What is
the point of being so negative?
-- 
Keep it simple to make it faster.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Bug#888743: Debian vs Linux namespaces, NMU lsb-base

[Vincent Bernat]

 ❦ 24 mars 2019 14:40 +01, Didier 'OdyX' Raboud :

>> Wouldn't it break chrooted processes? But mostly, as the whole pattern
>> is broken, it seems to be a low-effort solution.
>
> Vincent: what scenario did you have in mind?

For the first part, any daemon chrooting (like HAProxy, lldpd). For the
second part, it's just killing by name is fragile. Supervisors or PID
files should be used instead. start-stop-daemon makes it easy to get a
PID file for a program not able to provide one.
-- 
Make it right before you make it faster.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Debian vs Linux namespaces, NMU lsb-base

[Vincent Bernat]

 ❦ 24 mars 2019 09:42 +01, Geert Stappers :

> What would be the harm to the Buster release
> if lsb-base got NMU
> with 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=888743;filename=init-functions.diff;msg=37
>  ?

Wouldn't it break chrooted processes? But mostly, as the whole pattern
is broken, it seems to be a low-effort solution.
-- 
Soap and education are not as sudden as a massacre, but they are more
deadly in the long run.
-- Mark Twain


signature.asc
Description: PGP signature

Re: Namespace for system users

[Vincent Bernat]

 ❦  9 février 2019 13:10 +01, Philipp Kern :

> Some core packages recently adding system users resorted to names like
> systemd-$daemon and _apt, which both address my concerns - as you can
> come up with simple rules like "no user might include [-_] in their
> username". On the other hand I know that Debian-* was painful and
> annoying for exim, but I suspect mostly because of the length of the
> username and tools dealing poorly with >8 character usernames. I think
> FreeBSD (among others?) picked the underscore at the front of the
> username. Intuitively that feels like a somewhat clean proposal that
> is also friendly to derivatives.
>
> How do others deal with this problem? Could someone think of a viable
> approach on how to approach this from a policy side?

This is a recurring topic. See:
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=248809
-- 
Noise proves nothing.  Often a hen who has merely laid an egg cackles
as if she laid an asteroid.
-- Mark Twain


signature.asc
Description: PGP signature

Bug#918120: ITP: bpftrace -- high-level tracing language for Linux eBPF

[Vincent Bernat]

Package: wnpp
Severity: wishlist
Owner: Vincent Bernat 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: bpftrace
  Version : git
  Upstream Author : IO Visor Project
* URL : https://github.com/iovisor/bpftrace
* License : Apache 2
  Programming Lang: C++
  Description : high-level tracing language for Linux eBPF

BPFtrace is a high-level tracing language for Linux enhanced Berkeley
Packet Filter (eBPF) available in recent Linux kernels (4.x). BPFtrace
uses LLVM as a backend to compile scripts to BPF-bytecode and makes
use of BCC for interacting with the Linux BPF system, as well as
existing Linux tracing capabilities: kernel dynamic tracing (kprobes),
user-level dynamic tracing (uprobes), and tracepoints. The BPFtrace
language is inspired by awk and C, and predecessor tracers such as
DTrace and SystemTap.

The copyright assignment is currently not precise enough. Original
author is Previously, Alastair Robertson.

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAlwuIvwSHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5wFsP+wQh9RbS9wCku2k+QcUyyVMimnSZJURp
l2wJoH3VVAL9AfAYeKB7FYbmapykuripk+XKPRLjGPAxdaNObIid69kTHaa7HyyO
HncqsJECxBRobcy+x8HV4jcaSHTeWqhpHncV3FWLGaF/wMEHfze2dWZPSwCafocB
kXDG5HnaV/1MvpWchOMzHT/wcxy5a7cTksqSgKxB+ssu3AdQNerB6RAxPhCGzVIP
C9DnFAVx8JDq5qsX27V/5pJScZmk6915fsmQPmaOqEKPQx8ZR3OUjZacwsWphZ2v
IKw2RKhr5P5pkj0IRrFvJpHyXqsFu/xW1AD7x2C2XkljhlkyXMMC1aN/rDtG0A7j
HToZeyxS8G9TPEraORmsVtt3+CCuE9hzi8/IDBdv07/TJWrOWhEgg9zuxEEb5YQ/
qq4CMDJlJU8Tv6uu3ojKTPsbHwqTCo1T4nZgQR3Hfq7KB2LkBqq8c04Fe9D7Vufy
O8ZB9w9wH3vsEF90Yz3qbJCYoemNinzhJJsvnWAd9JpYjA3R2y0h7OiF4EeY3kVC
09kPibZaQjPgiaep2x/jFXYb5gTFhL8JWUuvUP9FFo8dpMKD45tgKSTRBOpBa/qy
8uJ+wklHIZWBiHyg0NCIEsnTE1drO3IXEQnv47HfHAnPOTndLBkuil3SRFrQ1NJr
VfEzHG4G734Q
=IGQI
-END PGP SIGNATURE-

Re: usrmerge -- plan B?

[Vincent Bernat]

 ❦ 22 novembre 2018 18:00 +0100, Marco d'Itri :

> Actually I believe that the fact that this could be solved quickly and 
> with a trivial change is a great argument in favour of the quality of my 
> plan and work for switching to merged-/usr.

Thank you for that! My workstation was switched to merged-/usr without
issue three years ago. It is running the same Debian unstable
installation since 2002.
-- 
Make your program read from top to bottom.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

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

[Vincent Bernat]

 ❦ 19 novembre 2018 09:51 -0600, Dirk Eddelbuettel :

> | 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.

I am maintaining a piece of software using autotools and each time I let
slip a path computed at build time, I have bug reports from a handful of
embedded distributions (OpenWRT, buildroot, ...) telling me it breaks
with them. So, it's not something unique to Debian.
-- 
Use library functions.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: I resigned in 2004

[Vincent Bernat]

 ❦ 11 novembre 2018 19:20 +0100, Wouter Verhelst :

> Meanwhile, it makes sense to be courteous to people who were a DD once
> but really couldn't care less now and want to get rid of the nagging,
> which seems like a far more likely scenario.

Then, they should click on the button they are asked to click. This
takes far less time than a long (and discourteous) rant.

I know you have good intention in trying to improve the MIA process, but
I think[*] this sends the wrong message to the current volunteers: you
can act as professionally as you can, you will still get criticism from
a few people on some minor details. Can we spare our volunteers more
carefully than rude people?

[*]: I am not part of the MIA team.
-- 
I'll burn my books.
-- Christopher Marlowe


signature.asc
Description: PGP signature

Re: tinysshd dependency on systemd

[Vincent Bernat]

 ❦ 22 octobre 2018 00:34 +0200, Svante Signell :

>> Well, reporting bugs about software you don't care or patches you
>> don't test is not always useful. For example, you clearly didn't test
>> your wrapper (shebang is #!/usr/sh) nor the init script
>> (/lib/init/init-d-script is expecting the daemon to fork). The
>> maintainer would have to do the testing, possibly the immediate fixes
>> and all the future maintenance. Just for you to make a point.
>
> Did you treat the code in the previous message as patches for some bug,
> in that case which bug? I did not, Ivan just published some possible
> code snippets to help.

You are right, I may have jumped too soon.
-- 
It is often the case that the man who can't tell a lie thinks he is the best
judge of one.
-- Mark Twain, "Pudd'nhead Wilson's Calendar"


signature.asc
Description: PGP signature