Re: Firmwares (was Re: Bits from the DPL)

[Didier 'OdyX' Raboud]

Le lundi, 1 avril 2024, 19.41:45 h CEST Andrey Rakhmatullin a écrit :
> Why is updating the firmware packages not trivial? Is it because of
> licensing issues? I always thought it's just copying a bunch of files from
> the linux-firmware repo (but I also often wondered why is the package
> often not up to date).

My recollection, after getting some MRs merged in the firmware-nonfree package 
last cycle (oh, a year gone already), is that it's a mix of:

* the maintainers in position to review, then merge the proposed changes are 
few, and have plenty on their hands;

* firmware packages seem to have lower priority during the development cycle, 
in favour of larger updated shortly-before (or during) the freeze;

* upstream and Debian (maintainers) are not in complete agreement on what can, 
or should be shipped in packages; from README.source:
> Also, some of its contents are not clearly redistributable, and some are
> obsolete for Debian's purposes.

So almost every file addition needs a careful `git log` review to check for 
origin, updates, reasoning, version strings, etc. Unless there's tooling I 
have not found; it's tedious, error-prone (and not very interesting) work 
(although quite arguably necessary).

* packaging is very smart, but peculiar (or at least, quite different to what 
I had been used to before I touched it). Despite good documentation, it's 
quite a steep intro for newcomers.

All-in-all, I think it's an all-too-classical case of "we don't have enough 
humanpower for the job we set out to do". Add a team of motivated individuals 
to gain the confidence of the existing "already-plenty-on-their-plates 
maintainers", to then maintain the package on their own. Oh, wait…

-- 
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: xz backdoor

[Didier 'OdyX' Raboud]

Le dimanche, 31 mars 2024, 21.23:10 h CEST Arto Jantunen a écrit :
> Didier 'OdyX' Raboud  writes:
> > Le dimanche, 31 mars 2024, 14.37:08 h CEST Pierre-Elliott Bécue a écrit :
> >> I would object against creating a PGP key on the HSM itself. Not having
> >> the proper control on the key is room for disaster as soon as you lose
> >> it or it dies.
> > 
> > For subkeys, isn't that a benefit rather than a disadvantage?
> > 
> > You lose the key, or it gets destroyed / unusable; good, you get a new
> > subkey instead of reusing the existing one on a different HSM.
> 
> For the authentication and signing subkeys this is indeed true. For the
> encryption subkey significantly less so (as things encrypted against
> that key then become impossible to decrypt).

I was missing that perspective; thanks!

-- 
OdyX

Re: xz backdoor

[Didier 'OdyX' Raboud]

Le dimanche, 31 mars 2024, 14.37:08 h CEST Pierre-Elliott Bécue a écrit :
> Hello,
> 
> Iustin Pop  wrote on 31/03/2024 at 13:13:27+0200:
> > Option 2: Generate keys on the yubikey and have them never leave the
> > secure enclave. That means having 2 yubikeys per developer, and ensuring
> > you keep track of _two_ keys, but it does ensure there's a physical
> > binding to the key.
> > 
> > Are there other options? And which option is proposed?
> 
> I would object against creating a PGP key on the HSM itself. Not having
> the proper control on the key is room for disaster as soon as you lose
> it or it dies.

For subkeys, isn't that a benefit rather than a disadvantage?

You lose the key, or it gets destroyed / unusable; good, you get a new subkey 
instead of reusing the existing one on a different HSM.

-- 
OdyX

Bug#1060006: ITP: brpc -- Apache's brpc - Industrial-grade RPC framework

[Didier 'OdyX' Raboud]

Package: wnpp
Severity: wishlist
Owner: Didier 'OdyX' Raboud 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: brpc
  Version : 1.7.0
  Upstream Contact: d...@brpc.apache.org
* URL : https://brpc.apache.org/
* License : Apache-2.0
  Programming Lang: C++
  Description : Industrial-grade RPC
 Apache bRPC is often used in high performance systems such as Search,
 Storage, Machine learning, Advertisement, Recommendation, etc

(the short and long descriptions' are really bad; suggestions welcome!

In the context of packaging typesense /
https://github.com/typesense/typesense/, it looks like brpc is needed
too, so here I come.

The currently quite messy packaging is over at
https://salsa.debian.org/typesense-team/brpc and I really welcome any
help to make that a clean addition to Debian!

Bug#1058699: ITP: blupimania -- Blupimania - A mind boggling (brain twisting) game of logic

[Didier 'OdyX' Raboud]

Package: wnpp
Severity: wishlist
Owner: Didier 'OdyX' Raboud 
X-Debbugs-Cc: debian-devel@lists.debian.org

 Package name: blupimania
 Version : 1.6.2
 Upstream Contact: Mathieu Schroeter 
 URL : https://blupi.org/mania/
 License : GPLv3
 Programming Lang: C
 Description : Blupimania - A mind boggling (brain twisting) game of logic

 Blupi comes out of a hole holding on to a balloon. Unfortunately he
 let's it blow away. Blupi is lost, he turns to the left or the right
 and does various unpredictable things of his own. The object of the
 game is to help him find another balloon, so that he can move on to the
 next riddle.

This 1994-1995 game, first released for Smaky's, was ported to DOS in
1996, then the source code was lost. It got found again on a CD-R in
2021, then ported to SDL, which now makes it available natively on
GNU/Linux.  That piece of history can now be made avaiable to Debian!

Bug#1037176: ITP: typesense -- Fast, typo-tolerant search engine

[Didier 'OdyX' Raboud]

Package: wnpp
Severity: wishlist
Owner: Didier 'OdyX' Raboud 
X-Debbugs-Cc: debian-devel@lists.debian.org

  Package name: typesense
  Version : 0.24.1
  Upstream Contact: TypeSense team 
  URL : https://typesense.org
  License : GPL-3
  Programming Lang: C++

Typo-tolerant search engine optimized for instant search-as-you-type
experiences and developer productivity. Push data to it and then allow
users to search through this data via a search UI in a site or app.

I plan to package this under https://salsa.debian.org/debian/typesense.
If there's a matching packaging team, more than happy to move there!

Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

[Didier 'OdyX' Raboud]

Le mardi, 16 mai 2023, 17.06:38 h CEST Russ Allbery a écrit :
> I don't know if anyone has written an ABI compliance test for binaries.
> That sounds like something that would be in scope for the Linux Test
> Project, though, and it's possible their existing tests do some of this.

This has existed in a (now distant) past as the "Linux Distribution Checker", 
in the context of the Linux Standard Base, that Debian and Ubuntu stopped 
caring about in late 2015.

I'm not aware of more recent efforts in that direction; but it's an 
understatement to say the landscape has changed quite a bit since: containers, 
sandbox environments (and others) have forever changed the way we think about 
distributing binary executable. LSB had that ambition, and failed.

-- 
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: Introducing Declarative Debian

[Didier 'OdyX' Raboud]

Le dimanche, 2 avril 2023, 15.41:12 h CEST Micha Lenk a écrit :
> I'm not quite sure I got the concept. Is this just (also) another way of
> expressing things we currently express with virtual packages?
> 
> For example:
> * httpserver-is-apache
> * imapserver-is-dovecot

You need to think larger!

* christoph-got-you-to-think-about-this-seriously
* april-s-fool-is-less-and-less-fun-in-an-era-of-fakenews
* I-genuinely-giggled-though

-- 
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: transitional packages? (was: Firmware GR result - what happens next?)

[Didier 'OdyX' Raboud]

3 octobre 2022 11:11 "Santiago Ruano Rincón"  a écrit:
> El 02/10/22 a las 20:42, Michael Biebl escribió:
>> Am 02.10.22 um 20:14 schrieb Luca Boccassi:
>> On Sun, 2022-10-02 at 10:52 -0700, Russ Allbery wrote:
>> In Bullseye we changed the name/syntax for the security repository, and
>> for that a mention in the release notes was enough, no? Isn't this a
>> very similar situation?
>> 
>> The main difference is, that the renaming caused an error message by apt, so
>> you knew something needed to be fixed.
>> 
>> For this particular change, there will be no error. So yes, I have the same
>> fear as Russ that this particular change might go unnoticed.
> 
> Couldn't we handle this via transitional firware* non-free packages,
> that depend on bookworm non-free-firmware packages?

That would only work if we renamed all concerned binary packages, or if apt 
grew a "section/packagename" syntax (which would be bizarre).

Re: Automatic trimming of changelogs in binary packages

[Didier 'OdyX' Raboud]

19 septembre 2022 23:19 "Bill Allombert"  a écrit:
> Le Tue, Sep 06, 2022 at 07:13:30AM +0200, Gioele Barabucci a écrit :
> 
>> On 18/08/22 21:18, Gioele Barabucci wrote:
>> Does anybody have objective objections against activating automatic
>> changelog trimming in binary packages?
>> 
>> Hi,
>> 
>> a couple of weeks since the initial email (thanks everybody for the input),
>> my reading is that there is now consensus in going ahead with the proposed
>> automatic trimming of changelogs.
> 
> Count me out. changelog embbed Debian history. The very first entries
> are often very important.

They can be important _in the source package_. I have yet to see binary packages
for which having access to early debian/changelog entries matters at all.
( debian/NEWS is another story of course, and these are not affected).

Re: Idea: autopkgtest on big-endian for 'Architecture: all' packages to catch endian bugs

[Didier 'OdyX' Raboud]

Le mardi, 2 août 2022, 18.00:40 h CEST Edward Betts a écrit :
> I recently packaged a Python module called sqlite-fts4 written by Simon
> Willison. The package is pure Python, so is 'Architecture: all', but it
> fails on big-endian architectures. The test suite catches this failure.
> 
> The bug was spotted by OpenSUSE because they tried to run the test suite on
> s390x. They filed a bug which upstream has fixed.
> 
> https://github.com/simonw/sqlite-fts4/issues/6
> 
> Simon has written some posts about this problem.
> 
> https://til.simonwillison.net/python/struct-endianness
> https://til.simonwillison.net/docker/emulate-s390x-with-qemu
> 
> It would be nice if the Debian infrastructure could catch this class of bug.
> 
> Building the sqlite-fts4 Debian package runs the test suite, and I've
> configured it to run the tests via autopkgtest.

If these tests are run at build-time, errors halt the build and that provides 
the largest coverage. It's also usually easier to iterate and test than 
autopkgtest.

-- 
OdyX

signature.asc
Description: This is a digitally signed message part.

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

[Didier 'OdyX' Raboud]

Le samedi, 16 juillet 2022, 19.36:17 h CEST Adrian Bunk a écrit :
> What tools did you use to generate this data?
> 
> The irony is that your "fight" requires exactly the tools you want to
> condemn, and data Debian should better not collect at all.

It does not. The whole argument is "gender-guessing if prone to errors, if you 
want to know what gender a person identify themselves, ask them".


signature.asc
Description: This is a digitally signed message part.

Re: I'm orphan my packages and leave the project as maintainer

[Didier 'OdyX' Raboud]

Le vendredi, 26 mars 2021, 16.01:14 h CET Timothy M Butterworth a écrit :
> The FSF with out RMS would be like the Linux Foundations with out
> Linus.

I'm quite sure the Linux Foundation will work just fine without Linus 
Torvalds, and will one day have to.

My hope is that the same goes for the FSF; either it can prove being a useful 
voice leading the Free Software movement without RMS, or it insists it can't 
merely exist without having RMS in the Board. In the latter, we should all 
diverge away (more than was already done) from the FSF and lead the Free 
Software movement without the FSF.

-- 
OdyX

Bug#980200: ITP: pappl -- C-based framework/library for developing CUPS Printer Applications

[Didier 'OdyX' Raboud]

Package: wnpp
Severity: wishlist
Owner: Didier 'OdyX' Raboud 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-print...@lists.debian.org

Package name: pappl
Version : 1.0.1
Upstream Author : Michael R Sweet 
URL : hhttps://www.msweet.org/pappl
License : Apache License Version 2.0 with an (optional) exception to 
allow linking against GPL2/LGPL2 software
Programming Lang: C
Description : C-based framework/library for developing CUPS Printer 
Applications

 PAPPL is a simple C-based framework/library for developing CUPS Printer
 Applications, which are the recommended replacement for printer drivers. It
 was specifically developed to support LPrint and a future Gutenprint Printer
 Application but is sufficiently general purpose to support any kind of printer
 or driver that can be used on desktops, servers, and in embedded environments.

I'll be maintaining this under the Debian Printing Team umbrella. Current 
packaging
is hosted at https://salsa.debian.org/printing-team/pappl/.

Re: On doing 3000 no-source-change source-only uploads in January 2021

[Didier 'OdyX' Raboud]

Le jeudi, 31 décembre 2020, 13.50:30 h CET Holger Levsen a écrit :
> hi,
> 
> as described in Message-ID: <20201231124509.gb3...@layer-acht.org>
> or
> http://layer-acht.org/thinking/blog/20201231-no-source-change-source-upload
> s/ I plan to do 3000 NMUs soon.

Fantastic job, thanks a lot for doing it!

-- 
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: DAM Key and identity requirements

[Didier 'OdyX' Raboud]

Le dimanche, 13 septembre 2020, 09.11:04 h CEST Enrico Zini (DAM) a écrit :
> Hello everyone,
> 
> world-wide changes due to COVID-19 prompted us to conduct a long-overdue
> review of the GPG key requirements for people applying for Debian
> Maintainer (DM) and Debian Developer (DD) membership status.

Oah. Thanks for this much welcome change, along with this excellent 
explanation. \o/

-- 
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Didier 'OdyX' Raboud]

Le samedi, 29 août 2020, 01.01:09 h CEST Raphael Hertzog a écrit :
> Hello,
> 
> following the recent discussions of June and of the last days, I'm
> proposing the changes below to DEP-14. Basically it replaces debian/master
> with debian/latest for all the reasons already discussed earlier. And
> it says that debian/unstable is preferred over debian/sid.
> 
> And it also marks the proposal as ACCEPTED given that it has gained
> traction over the years and that we didn't feel the need to make
> significant change to it.

Thanks for this proposal. I can't help but feel overwhelmed by the upcoming 
change to main branches of "so many" repos to debian/latest, but I feel it's 
definitely worth it (and scriptable).

Seconded.

-- 
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: Tagging in Salsa -> upload: status?

[Didier 'OdyX' Raboud]

Le jeudi, 13 août 2020, 11.19:59 h CEST Christian Kastner a écrit :
> Unless I'm grievously misremembering something, there was a discussion a
> while ago about automatically generating a source package and uploading
> it whenever a Debian release is (signed-)tagged in Salsa.
> 
> If I did remember correctly: may I kindly inquire what the status on
> that is?

I think I was the one with that idea [0], and I threw around some code last 
winter, but I never really finished this; as I've stuck to using `dgit push-
source` for now.

The idea would be to have: a `dgit tag-source-for-upload`, which produces a 
tag with all the metadata needed by a knowledgeable tag consumer to reproduce 
a signed .dsc + a signed _source.changes. That knowledgeable tag consumer 
would run at the end of a salsa pipeline.

But I am not at all perl fluent, and have stalled with a partial python-based 
proof-of-concept, sadly.

-- 
OdyX

[0] https://lists.debian.org/debian-devel/2019/10/msg00301.html

Re: 'No such file or directory' while building coreutils from source package

[Didier 'OdyX' Raboud]

Le jeudi, 7 mai 2020, 21.59:56 h CEST Manuel Wagesreither a écrit :
> Do I need to extract it?
> https://www.debian.org/doc/manuals/maint-guide/build.en.html doesn't
> mention anything like that. Also, it doesn't seem to change the outcome.

The first part of the guide (Chapter 2. First steps) [0] explains a little 
better what different parts constitute a source package, and therefore a 
source directory.

Another good resource is the Debian handbook; specifically it's chapter 5.3 
"Structure of a Source Package" [1].

In short, you need to:
- extract the upstream tarball
- extract the Debian changes on top of the directory containing your upstream 
extracted source code (usually a .debian.tar.*).
- apply the patches

All this is doable by hand, but really, you should rely on Debian's tools:

$ apt-get source coreutils

… will download and extract the coreutils source package from the Debian 
repositories. And by extract, I mean that it will do nothing more than the 3 
steps above.

Regards,
OdyX

[0] https://www.debian.org/doc/manuals/maint-guide/first.en.html
[1] 
https://www.debian.org/doc//manuals/debian-handbook/sect.source-package-structure.en.html

signature.asc
Description: This is a digitally signed message part.

Re: trends.debian.net updated

[Didier 'OdyX' Raboud]

Le mardi, 14 avril 2020, 13.12:55 h CEST Wouter Verhelst a écrit :
> > One could expect from maintainers that they check their packages for
> > compliance regularly and that they document that.
> 
> Perhaps, but it is *also* documented that an upload just to bump the
> Standards-Version is severely frowned upon.

If that is still true, we should change this: a "I checked, it still complies 
with the most recent Policy, had to do no other changes" upload should be 
considered just fine, as the highest cost was the maintainer's time, and it 
might well be saving a lot of other people's.

-- 
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: Overinterpretation of DFSG? QR code for receiving donation is non-free???

[Didier 'OdyX' Raboud]

Le lundi, 30 mars 2020, 21.08:18 h CEST Russ Allbery a écrit :
> Didier 'OdyX' Raboud  writes:
> > Yet one is a string, and the other one an image. If you edit the string
> > before turning it into a QR code, you get a valid QR code (maybe
> > encoding a broken, or misleading URL, but still valid QR code). If you
> > edit the QR code directly, you _can_ get a valid QR code, but chances
> > are that you are not getting what you want. We have a direct "string
> > representation" → "binary artifact", quite like in compilation.
> 
> Putting aside the issue of the embedded graphic, which is a separate
> matter, this doesn't sound right to me.  Surely the QR code is an
> encoding of a string?  If one can do a round-trip conversion into your
> preferred format without loss, I'm having a hard time seeing how this is
> not a preferred form of modification.

It's a modifiable binary artifact, in that you can read it's content, and 
create a different version of itself from the same content, or an alteration 
of it. With (but even without) the image in their center, it takes quite some 
trial-and-error to get the _exact_same_ image. It's easy to get a functionally 
identical QR code; it's quite harder to get the exact same. It _can_ be a bi-
directional lossless conversion; I'd argue that without upstream's build-
parameters, it's not.

Anyway, I am not really arguing that QR codes (even these) are not 
redistributable in Debian source or binary packages (I'm leaving this to the 
FTP masters). I am saying that with the tooling we have (qrencode is one of 
plenty), it is really easy to produce functionally-equivalent QR codes. And 
that I think that the cost of doing so (at build time) is really small with 
regards to the benefit we get in term of transparency (the URL from the QR 
code becomes searchable, the build process is clarified).

Regards,
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: Overinterpretation of DFSG? QR code for receiving donation is non-free???

[Didier 'OdyX' Raboud]

Le lundi, 30 mars 2020, 10.14:13 h CEST Raphael Hertzog a écrit :
> On Mon, 30 Mar 2020, Didier 'OdyX' Raboud wrote:
> > > How should package maintainers deal with QR codes ethically?
> > 
> > Asking package maintainers to rebuild functionally-equivalent QR-codes
> > during the build-process seems entirely reasonable to me.
> 
> To me it looks like wasting my time. There are many pictures that are
> not the preferred form of modification but we accept them as is when
> there's no proof/evidence that some other source exist.
> 
> And here there's no other source really, the source is the string
> associated to the QR code. QR code and the string are two different
> representation of the same underlying data.

Yet one is a string, and the other one an image. If you edit the string before 
turning it into a QR code, you get a valid QR code (maybe encoding a broken, 
or misleading URL, but still valid QR code). If you edit the QR code directly, 
you _can_ get a valid QR code, but chances are that you are not getting what 
you want. We have a direct "string representation" → "binary artifact", quite 
like in compilation.

That said. We don't _have_ to ship these in source or binary packages, and 
therefore getaway without re-building these. But if we are to ship them, 
building them at build-time from their source strings is a really modest price 
to pay; for the sake of "actually building binary artifacts from source".

-- 
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: Overinterpretation of DFSG? QR code for receiving donation is non-free???

[Didier 'OdyX' Raboud]

Hello Mo,

Le lundi, 30 mars 2020, 07.54:23 h CEST Mo Zhou a écrit :
> I think sometimes the DFSG has been over-interpreted. Here I'm talking about
> the recent REJECTion of src:smartdns from our NEW queue, where QR code
> pictures used for donation have been deemed DFSG non-free [1]. I'm not
> satisfied with the explanation, and I think there is over-interpretation on
> DFSG.
> 
> I poked ftp-master about this problem:
> 
>spwhitton: I'm quite confused about REJECTION of src:smartdns. Why
> can the QR code pictures for software author to receive donations be
> DFSG-nonfree?
> 
> And I got the following explanations:
> 
>lumin: IIRC that was not the only reason for REJECT. 
> Otherwise I would have PRODded.
> 
>lumin: An image of a QR code wouldn't be the preferred form of
>   modification.  They are usually generated from something.  If the file it
> was generated from isn't present and the tool to generate it isn't in
> Debian, then it can't be shipped.  Requiring preferred form of modification
> is one area where Debian is often stricter than licenses due to DFSG.
> 
> The pictures we're talking about are (…)
> 
>   Why are they non-free?

They are non-free, because they cannot be rebuilt from their preferred form of 
modification.

> Treating this files as non-free could lead to further problems.
> 
>   1. If I stripped the donation codes from the source.
>  I believe such behaviour is **unethical**.

It's allowed by GPL-3 licensing. Actually, we (Debian) require that this must 
be possible. But you can't be coerced into doing this (you can always opt to 
"not package for Debian").

>   2. If I decoded the QR code and replaced them with the underlying URLs.
>  There is no Chinese user who pay through URL instead of QR code.
> 
>   3. If I stripped the donation codes but re-generated them during the
>  package build process.
>  "Oh damn, this QR code does not look like the original one and the
> hashsum mismatches. Has the Debian developer forged the QR code to be
> evil?" I mean there will be doubt if the distributed QR code is not
> byte-to-byte equivalent to the one distributed by upstream author.

We're _building_ source code towards binary artifacts all the time. Doing this 
(and being trusted to be doing it correctly) is one of the defining 
characteristics of being a "shipping-binaries" Linux distribution. The whole 
point of this exercise is that our build processes are auditable, and that 
eventual forgeries can be found, reported, and fixed.

If you don't consider the result of your builds trustworthy, "we have a 
problem".

> Is a QR code for donation really DFSG non-free?

QR codes are artifacts in binary form, not in their preferred form of 
modification.  By function, QR codes are vehicles of binary information, and 
can be easily reconstructed from said binary information without loss (of 
information).

Frankly, simple lines like the following in debian/rules would do it:

  echo "http://donation-url.example.com/?vendor-id; | qrencode -o qr.png

> Is DFSG over-interpreted in this case?

IANAFM, but I don't think so.

> How should package maintainers deal with QR codes ethically?

Asking package maintainers to rebuild functionally-equivalent QR-codes during 
the build-process seems entirely reasonable to me.

--
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#955126: ITP: libopenaptx -- Audio Processing Technology codec (aptX)

[Didier 'OdyX' Raboud]

Package: wnpp
Severity: wishlist
Owner: Didier 'OdyX' Raboud 

Package name: libopenaptx
Version : 0.1.0
Upstream-Contact: Pali Rohár 
URL : https://github.com/pali/libopenaptx/
License : LGPL2.1+
Programming Lang: C
Description : Audio Processing Technology codec (aptX)

 Support for aptX and aptX HD codec variants; they both operate on raw 24-bit
 signed stereo audio sample; at 6:1 fixed compress ratio for aptX; at 4:1 fixed
 compress ratio for aptX HD.

This is mainly needed for Bluetooth headsets with aptX/aptX-HD support, and
will be maintained in the debian/ salsa group.

Re: USB

[Didier 'OdyX' Raboud]

Hello Kya,

Le vendredi, 13 mars 2020, 15.00:10 h CET Kya Bailey a écrit :
> Me and my family were cleaning a couch that we were getting rid of and I
> found a USB so I checked it out and it had stuff with your logo in the
> pictures and it has stuff like Copyright, changelog.Debain.gz, makefile and
> others like that please contact me if you are interested in ownership the
> USB

The Debian project does not own nor sell USB sticks; so as far as the Debian 
project is concerned, this USB stick was likely lost (or hidden) by someone 
who had used it to install Debian. If at all possible, it is that someone that 
you might want to return the USB key to.

That said, if you are interested in what the Debian project is, and does, I 
would encourage you to look at our homepage: https://debian.org/ and to try 
booting a Debian system by re-flashing a fresh Debian live image on this (or a 
different USB key):

https://www.debian.org/CD/live/

For any questions regarding Debian, you could head to
  http://forums.debian.net/
  the debian-u...@lists.debian.org mailing list.

Thank you for enquiring about this USB key and Debian!

--
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: Debian With Alternate Init Systems

[Didier 'OdyX' Raboud]

Le samedi, 8 février 2020, 16.15:13 h CET Svante Signell a écrit :
> On Sat, 2020-02-08 at 14:51 +0100, Samuel Thibault wrote:
> > Sam Hartman, le sam. 08 févr. 2020 08:27:24 -0500, a ecrit:
> > > It sounds like you were suggesting that people should leave as a way of
> > > pressuring or punishing the project.
> 
> Why not, if the project is heading in the wrong way according to their
> conviction. Some people have already left Debian, as a result of the GR.

The Debian project members voted for a project's position statement of the 
day, that resulted in option B winning [0]. You might dislike this result, but 
option B is the Debian project's current opinion on Init systems, multiple 
init systems, and the use of systemd facilities.

Now with this Debian's position statement in mind, you can choose to help 
making (this) Debian better, or you can choose to put your energy in other 
projects that pursue goals more aligned with yours. That's not pushing you 
out, that's Debian saying "this is where we're going; are you going along?".

> > I'd say do not try to fix it, we've been trying unsuccessfully within the
> > Hurd community.
> 
> Samuel, so you want me to stop working on Hurd? Nice, the first thing I'll
> do is to shut down the Debian/GNU Hurd buildd mahler.

Threats and emotional blackmail are not welcome in Debian. Please stop.

(If you don't feel like maintaining an piece of infrastructure for the Debian 
project, by all means organize its replacement to free it from your 
hands. It's clearly your right. But don't use work you do for the project as 
argumentative lever; that's really not acceptable.)

OdyX

[0] https://www.debian.org/vote/2019/vote_002#textb

signature.asc
Description: This is a digitally signed message part.

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

[Didier 'OdyX' Raboud]

Le mercredi, 5 février 2020, 21.44:43 h CET Dmitry Smirnov a écrit :
> On Wednesday, 5 February 2020 11:01:08 AM AEDT Scott Kitterman wrote:
> > We just had a GR where the project voted it was just fine to systemd all
> > the things, so this sort of thing is to be expected.
> 
> Are you suggesting that voters fully understood the implications?

Let me suggest (out of reading what they wrote in other parts of the thread), 
that I read Scott's message as a mix of despair and sarcasm.

> Is this OK now to replace everything with systemd counterparts?
> 
> I certainly voted with considerations for _init_ system.

The vote was named "init systems and systemd".

> If I recall correctly, no GR option suggested to "use as much systemd
> components as possible" or I think the outcome of GR could have been
> different...

This was option "Choice 1: F: Focus on systemd".

The option that won, "Choice 2: B: Systemd but we support exploring 
alternatives" [0] said:
> Packages may use any systemd facility at the package maintainer's
> discretion, provided that this is consistent with other Policy requirements
> and the normal expectation that packages shouldn't depend on experimental or
> unsupported (in Debian) features of other packages.

Of course, it's ironic to read that under this project's opinion; "src:systemd 
may use any systemd facility at systemd maintainer's discretion".

But, irony aside, we _did_ decide that we were to allow systemd facilities' 
usage, and moving ahead with journal's persistent storage seems to me very 
much inline with the project's latest GR-backed opinion.

I'm not saying the project decided "journald should replace rsyslog" though. 
I'm saying that activating the persistent storage in journald feels very much 
inline with the project's expressed opinion. Also, it is orthogonal to whether 
we should be demoting rsyslog, or to what would happen to it upon upgrade.

OdyX

[0] https://www.debian.org/vote/2019/vote_002#textb

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

[Didier 'OdyX' Raboud]

Le mercredi, 5 février 2020, 07.01:44 h CET Scott Kitterman a écrit :
> 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.

Unless I'm mistaken, exim4 logs nothing to /var/log/mail.log by default, only 
to /var/log/exim4/{mainlog,paniclog}

-- 
OdyX

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

[Didier 'OdyX' Raboud]

Le samedi, 1 février 2020, 14.36:20 h CET Steve McIntyre a écrit :
> Michael Biebl wrote:
> >with today's upload of systemd 244.1-2 I finally enabled persistent
> >journal by default [1]. It has been a long requested feature.
> >
> >The package will create a directory /var/log/journal on upgrades and new
> >installs, which enables persistent journal in so called auto mode.
> 
> Fine for new installations, but please *don't* do this for
> upgrades. Those people with existing logging setups will be surprised
> by this.

I disagree. Please _do_ this for upgrades (it's great functionality!), but 
please do make sure that it is documented in NEWS.Debian (and release notes) 
so that it gets mentioned to host admins upon upgrade.

-- 
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#950260: ITP: lprint -- lprint - A Label Printer Application

[Didier 'OdyX' Raboud]

Package: wnpp
Severity: wishlist
Owner: Didier 'OdyX' Raboud 

  Package name: lprint
  Version : 1.0~b2
  Upstream Author : Michael R Sweet 
  URL : https://www.msweet.org/lprint/ 
  License : Apache-2.0-with-GPL-LGPL-Exception
  Programming Lang: C
  Description : lprint - A Label Printer Application

 LPrint implements printing for a variety of common label and receipt printers
 connected via network or USB. Features include:
 .
  * A single executable handles spooling, status, and server functionality
  * Multiple printer support
  * Each printer implements an IPP Everywhere™ print service and is compatible
with the driverless printing support in iOS, macOS, and Linux clients
  * Each printer can support options such as label modes, tear-off offsets,
media tracking, media top offset, print darkness, resolution, roll
selection, and speed
  * Each printer can print “raw”, Apple/PWG Raster, and/or PNG files
  * Each printer automatically recovers from out-of-media, power loss, and
disconnected/bad cable issues


This will be maintained by the Debian Printing Team.

Re: migration from cron.daily to systemd timers

[Didier 'OdyX' Raboud]

Le mercredi, 8 janvier 2020, 16.33:28 h CET Daniel Leidert a écrit :
> Am Mittwoch, den 08.01.2020, 15:36 +0100 schrieb Philipp Kern:
> > I think there needs to be a sensible choice for *periodic jobs* that we
> > should document as the default unless there is a reason to use something
> > else. It does not need to be cron, though.
> 
> Then go the appropriate way. Get a resolution if the Debian project is ok
> with the new default (…)

We _literally_ just passed a resolution [0] saying:
> Packages may use any systemd facility at the package maintainer's
> discretion, provided that this is consistent with other Policy requirements 
> (…)

Policy says conffile changes must not be overriden; not that their meaning or 
semantics can never change.

> If there is such a resolution: Change the default for new
> installations and leave existing installations a choice.

Philip's proposal at <87eewah0ws@hands.com> ( modify the shipped /etc/
default/spamassassin so that hosts with changes get a prompt; and others just 
start using the systemd timers) seems like a very nice strategy that seem to 
cover your needs.

Cheers,
OdyX

[0] https://www.debian.org/vote/2019/vote_002#textb

Building Debian source packages reproducibly (was: Re: [RFC] Proposal for new source format)

[Didier 'OdyX' Raboud]

Le mercredi, 23 octobre 2019, 15.49:11 h CET Theodore Y. Ts'o a écrit :
> On Wed, Oct 23, 2019 at 11:18:24AM +1000, Russell Stuart wrote:
> > On Tue, 2019-10-22 at 16:52 -0700, Russ Allbery wrote:
> > > That seems excessively pessimistic.  What about Git makes you think
> > > it's impossible to create a reproducible source package?
> > 
> > Has it been done?  Given this point has been raised several times
> > before if it hasn't been done by now I think it's reasonable to assume
> > it's difficult, and thinking that it's so is not excessively
> > pessimistic.
> 
> Generating a reproducible source package given a particuar git commit
> is trivial.  All you have to do is use "git archive".  For example:

When talking about upstream projects, sure.

But generating Debian source packages (.dsc and friends) from a
`debian/master` (+ `pristine-tar`) reproducibly is not really, right?

As far as I understand, `gbp buildpackage -S` is the closest we have, but so 
far, I fail to get it to give me the bit-by-bit identical unsigned .dsc that 
I'd like to get. What am I missing?

(A little digresssion…)

Where I'm coming from is that we were discussing the tag2upload problem at 
miniDebConf Vaumarcus. The heart of the problem is that FTP-Master are 
(currently) not going to accept .dscs built reproducibly by a (even trusted) 
service. tag2upload is built on the idea that a signed git tag is the only 
needed thing (`git tag -s`) to trigger an upload, and that is not going to fly 
currently.

The solution that seemed obvious during the discussion [0] is to instead rely 
on a local tool to produce a git tag with significantly more metadata (such as 
.dsc signature, _source.changes signature); and reconstruct the a signed set 
of .dsc and _source.changes automatically (as last pipeline step in Gitlab 
CI), which are then acceptable by the archive.

In other words, its "tag2upload", but with a reproducible way to:
- build a source package on developer machine;
- sign it locally;
- create and push a special git tag
Then, in a different environment (such as a GitLab CI pipeline step), given a 
special git tag and a repository;
- build the exact unsigned same source package
- unpack the special git tag;
- apply the signatures to get the exact same signed source packages;
- dput to the archive.

The hard part is not the packing and unpacking of the special tag; that's 
mostly just strings massaging. But building the exact same source package in 
different environments is harder than I expected.

Some caveats:
- Q: if you built and signed the source package locally, why not uploading?  
  A: Because you might want to only upload _after_ automated tests, and in an 
 unsupervised manner.
- Q: If one can fit pgp signatures in a git tag; why not inlining the complete 
 .dsc and _source.changes?
  A: Indeed. You still need the debian.tar though.
- Q: What about Dgit: in the .dsc, or buildinfo files?
  A: Currently optional; could just be left out for a prototype.

Of course, all of this can only work if we can have, or make the ".git to 
.dsc" conversion reproducible; hence my query.

All-in-all; would this be a welcome mechanism?


OdyX

[0] It probably was already considered.

signature.asc
Description: This is a digitally signed message part.

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

[Didier 'OdyX' Raboud]

Le dimanche, 24 mars 2019, 09.42:12 h CET Geert Stappers a écrit :
> 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=ini
> t-functions.diff;msg=37 ?

I have now uploaded src:lsb to experimental with Harald's patch. I'm not 
comfortable yet to target buster, I must say, nor do I really have time to 
test this extensively.

Le dimanche, 24 mars 2019, 10.16:25 h CET Vincent Bernat a écrit :
> 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?

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: usrmerge -- plan B?

[Didier 'OdyX' Raboud]

Le jeudi, 22 novembre 2018, 14.56:10 h CET Ian Jackson a écrit :
> There is tradeoff here between risk of breakage, and reduction of
> future work (as most clearly explained by Russ).  The argument that is
> being made is that the risk is low because of a lack of reports of
> breakage.
> 
> Others have observed that systems most likely to experience trouble
> will not have been upgraded.  For example, chiark was first installed
> with Debian 0.93R5 in 1993.  Obviously I haven't usrmerged it.  No-one
> sensible in my position would do so.

Of course you do have backups.  For the sake of the argument, would you 
consider trying an install of usrmerge on a restored backup VM somewhere?

Maybe I'm overlooking something, but it seems that installing usrmerge on a 
production system is going to be a _much_ less demanding task proceeding with 
a stable upgrade.

Cheers,
OdyX

Re: usrmerge -- plan B?

[Didier 'OdyX' Raboud]

Le jeudi, 22 novembre 2018, 00.17:54 h CET Michael Stone a écrit :
> Then this needs to be a very explicit (and much better advertised)
> decision, and it needs a much, much better implementation.

You keep referring to usrmerge as buggy:
> The current usrmerge package has no test mode, will bail with a partially-
> converted system if it runs into problems, and has no way to revert the
> process.

Sorry to be blunt about this, but have you reported these? Sniping at (any) 
package without making the problems you see visible to others (through bugs) 
is not really helpful.

> Pulling in usrmerge during an upgrade isn't going to cut it--we'd need some
> kind of pre-upgrade check that tells people what they need to fix before we
> break it. Designing this in a hurry less than two months before we start
> freezing seems incredibly ambitious.

usrmerge is in the archive for 3+ years now. What seems to be needed now is 
for a lot of us to actually _try_ it, find and report bugs, and get this 
through.

Don't forget that a specificity of our bug report system is that the only 
measure of "it worked without issues" that we have is popcon; we only get a 
measure of how much things fail, not how good they work:

https://qa.debian.org/popcon.php?package=usrmerge

(Funnily enough, it seems to have had a recent spike…)

Cheers,
OdyX

Re: What can Debian do to provide complex applications to its users?

[Didier 'OdyX' Raboud]

Le mardi, 27 février 2018, 14.13:41 h CET Didier 'OdyX' Raboud a écrit :
> tl;dr: a new package format is needed, with a new non-suite-specific
> repository is needed to bring the Debian added-value to these ecosystems.

FTR, my current line of thought and understanding is that guix or nix do 
pretty much what is needed here, and it would be silly to start something from 
scratch.

I plan to spend some brain time playing with guix and report back; I'm aware 
of:

* https://bugs.debian.org/850644 for guix 
* https://bugs.debian.org/877019 for nix
* Diane Trout's efforts 2 years ago on https://github.com/detrout/debian-guix

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: What can Debian do to provide complex applications to its users?

[Didier 'OdyX' Raboud]

Le mardi, 27 février 2018, 15.14:02 h CET Simon McVittie a écrit :
> Here is a different straw man, which I think might be similarly effective
> and a lot less work:
> 
> On Tue, 27 Feb 2018 at 14:13:41 +0100, Didier 'OdyX' Raboud wrote:
> > As Debian, we
> > are insisting that our releases ideally only contain a single version of a
> > software, that we insist is made available at system-level.
> 
> ...
> 
> > In other words, vendorization is the tool that allows developers to get
> > rid of distribution constraints and get on with their development through
> > installing the dependencies from their ecosystem as they see fit
> > (non-root), in the (eventually precise) version they need.
> 
> I can't help wondering whether vendorizing dependencies (embedded code
> copies) would be a better route for ecosystems like npm that we might
> categorise as "aggressively modular" - package the app, but not the
> dependencies, and treat the vendorized/embedded dependencies as part
> of the app. Not embedding or duplicating libraries is already an ideal
> that we have to compromise on for pragmatic reasons - browsers use
> system libraries in testing/unstable but gradually make increasing use
> of embedded code copies in stable[1], drifting further away from the
> "no embedded code copies" ideal as time goes on and the latest browser
> version becomes increasingly unbuildable against the increasingly old
> libraries in stable. It's also how many Rust dependencies are already
> managed, as far as I'm aware.

Sure.  That would just be a different use of these .vdebs where these would be 
embedded/repacked in the end application packages rather than installed 
globally and used from their installation paths.

The added value that Debian can provide are source traceability, and trust 
mechanisms for package updates (although my proposal would most certainly 
weaken that) The issue I have with npm/pypi/you-name-it ecosystems is that I 
have to rely on _binary_ distribution made by non-Debian actors (with their 
own standards), to get dependencies for my applications. (I'm not saying their 
standards are necessarily bad; just that they often are not Debian's.)

So I was talking about Debian providing a new source-to-binary_artifact 
pipeline, which I think is an area where there's something to be done, by 
Debian.  Your proposal about embedding vendorized dependencies within 
applications (through embedded code copies or through Flatpak) is good, but I 
think the two proposals are orthogonal.

The advantage of having Debian-provided version-specific dependencies is the 
centralization of the DFSG-freeness checking, of the copyright assignment, 
etc. (and of the security patching, but that's harder).

I envision a hypothetical situation where instead of having embedded code 
copies of, say, jquery in various software, we had a centralized jquery source 
repository to which any arbitrary version (even patched) could be requested 
from.  Need jQuery Core 2.2.3 ? We have it for your package, so please either:
* depend on jquery_core_2.2.3.vdeb and add a symlink to
  /opt/vdebs/jquery-core/2.2.3;
* build-depend on jquery-core_2.2.3.vdeb and add
  Built-Using: jquery-core_2.2.3

Need jQuery Core 3.3.1 with your specific patches? Add your patches to a 
branch, and get your jquery-core_3.3.1+g1231234.vdeb.

That'd be a neat way to entirely eliminate code copies, and win metadata 
(which is currently fuzzy, at best) about these.

> I'm just not sure that taking the rules we follow for C/C++ shared
> libraries and applying them to every other language's ecosystem is either
> feasible or desirable - nodejs libraries are not the same as C libraries,
> and their tradeoffs are not the same tradeoffs.

Yes.

signature.asc
Description: This is a digitally signed message part.

Re: What can Debian do to provide complex applications to its users?

[Didier 'OdyX' Raboud]

Le mercredi, 28 février 2018, 06.06:54 h CET Sean Whitton a écrit :
> > Furthermore, abandon the patch queue approach to Debian package
> > management.  We will not be able to maintain a big delta to any of
> > these packages anyway.
> 
> No, but we might often have reason to maintain a small delta.  We patch
> upstream source for all sorts of reasons; it is hard to believe it
> wouldn't come up.

It would not be reasonable to ship binary artifacts out of unpatcheable 
source, so I read Ian's point as getting rid of quilt in favour of git 
commits.

signature.asc
Description: This is a digitally signed message part.

Re: What can Debian do to provide complex applications to its users?

[Didier 'OdyX' Raboud]

Le mardi, 27 février 2018, 14.48:48 h CET Ian Jackson a écrit :
> I have some specific comments:
> > Imagine
> > * a new .vdeb format variant that:
> > ** enables for multiple versions to be installed in parallel, where files
> >are unpacked in a version-specific paths
> 
> Instead, establish a formal convention about embedding the (stable
> part of) the version number in the package name.  This is important
> so that it is possible to replace a specific "version" of one of these
> packages with a modified package which is the "same version".

Good point: not all versions are desirable; "majors" can be installed in 
parallel, "minors" are updates to the formers.

But, assuming a new binary format, it feels really weak to abuse of the 
package name to embed a version.  (The filename is a different question). What 
about (in control.tar's control):

Package: simplejson
Version-Unique: 3.13
Version: 3.13.2-1

> > ** forbids any kind of maintainer scripts
> > ** is not bound to a specific suite
> > ** is restricted to be arch:all (~ shipping interpreter scripts)
> 
> These can be verified either the archive server as part of package
> acceptance, or by apt as an annotation in the sources.list.

Again, that's the main advantage I see from a new .*deb format: if these 
restrictions are part of the format, they can be checked and enforced at all 
steps in the process: dpkg-buildpackage would error out if there's a postinst, 
lintian would add an error, the server would block it and dpkg would not 
unpack the postinst, just because 'debian-binary' is 2.0-vdeb.

> > ** (ideally) can be user-installed
> 
> This one would require some thought.  Do the target ecosystems support
> transplantation of installed directory trees, without modification ?
> 
> Perhaps the experience of other projects doing "prefixed" uses of dpkg
> might be relevant.  Eg
>   https://wiki.termux.com/wiki/FAQ#Is_Termux_a_complete_Linux_Environment.3F
> (But the prefix there is baked into the .deb.)
> 
> How is this going to work for build-dependencies ?  If one says
> "build-depends: npm-vdeb-foo", will the build system know to look in
> $HOME as well as /usr ?

user-installation embeds two different problems: prefixed unpack and non-root 
unpack.  Given this is something orthogonal to the vdebs proposal (+ a hard 
problem), it's probably easier (for a start) to just leave that requirement 
off.

> > * a repository of these .vdeb
> > ** whose DFSG-freeness is checked
> > ** which version set is known, and tracked
> > ** that can provide new versions "on-demand"
> 
> It is important to appreciate what we are *discarding* as too hard.

Yes.

> > How does that sound?
> 
> Your proposal depends on continuous and almost-automatic
> incorporation of upstream code.  Our current source package workflows
> are not suited to this.

Yes.  With Debian approval / whitelisting at various points in the lifetime of 
a "package: initial submission (as our NEW) and ideally at later points / 
versions.

> OTOH we do not want to abandon the Debian source package format
> completely because we have lots and lots of tools which understand it
> well.

Although I share the sentiment, I see value in finding a suitable model for 
the problem at hand, rather than massage our existing tools to fix the 
problem, "just because" they are our existing tools.  I think we agree on 
that.

> I would like to suggest a radical approach to the source code
> management for your system: abandon source *packages* in favour of git
> trees.  Furthermore, abandon the patch queue approach to Debian
> package management.  We will not be able to maintain a big delta to
> any of these packages anyway.
> 
> So instead, we should have a Debian branch of each upstream git tree,
> which we should "git merge".  We will have to have a tool, for each
> ecosystem, that converts the metadata provided in the upstream package
> into the Debian format in debian/.  The "update to new upstream"
> process would be:
>git fetch upstream
>git merge upstream/master
>npm-to-debian-autoconvert-update
>git commit -s -a -m npm-to-debian-autoconvert-update debian
> 
> Building should be done with "git clone" followed by
> "dpkg-buildpackage -b" (or some suitable wrapper).

That's pretty much what I had in mind, yes.  I'm not even sure there's much 
need for a complete traditional debian/ directory: iff the .vdeb ecosystem 
does much less than normal .debs, we could aim for a single declarative .vspec 
(yes, I know what you're thinking) file for instance.  Given we're tackling 
wide consistent (hmm) ecosystems, a set of fine tools and very minimal 
declarative packaging per-item could do it.

Thanks for your inputs; I should probably find some time to put a refined 
version of these thoughts in a wiki page somewhere.

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: [Pkg-javascript-devel] three.js_80+dfsg2-2_amd64.changes REJECTED

[Didier 'OdyX' Raboud]

Le jeudi, 1 mars 2018, 07.29:15 h CET Pirate Praveen a écrit :
> 2. CTTE should be able to overrule a delegate when there is a conflict
> just like conflict between two debian developers.

I don't think that's a power the Technical Committee (as a body, or as the 
current collection of its members) wants.

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: What can Debian do to provide complex applications to its users?

[Didier 'OdyX' Raboud]

Le jeudi, 1 mars 2018, 06.29:37 h CET Paul Wise a écrit :
> On Tue, Feb 27, 2018 at 9:13 PM, Didier 'OdyX' Raboud wrote:
> > Now, as a strawman proposition, here's what I fiddled with in my mind for
> > some days now:
> This reminds me a bit of Nix or Gentoo Prefix.

Yes, only for the upper layers' only, on top of your good-old Debian, and "by 
Debian"™.

Maybe what we need is a packaged nix and a standardized nix repository.

> > ** is restricted to be arch:all (~ shipping interpreter scripts)
> 
> Hmm, so this isn't going to cover all npm/pypi packages.

It's not a roadmap, just a braindump :-)  The packages that need compilation 
could still be provided as classical .debs for example.

signature.asc
Description: This is a digitally signed message part.

Re: What can Debian do to provide complex applications to its users?

[Didier 'OdyX' Raboud]

Le mercredi, 28 février 2018, 06.04:27 h CET Sean Whitton a écrit :
> On Tue, Feb 27 2018, Didier 'OdyX' Raboud wrote:
> > ** is restricted to be arch:all (~ shipping interpreter scripts)
> 
> There are compiled binary ecosystems that would benefit from your
> proposal, such as Haskell, so could you say more about why you want this
> restriction?

Mostly out of wanting to (eventually) start small.  It just reduces the 
problem surface.  Arch:all packages can virtually be built anywhere, on any 
architecture, so vdebs wouldn't (really) need a buildd network; or at least 
not a multiple-architectures' buildd network.

At first glance, it would also seem to vastly facilitate reproducibility, and 
reduces potential for executables' injection.

In pretty much the same vein as dh-virtualenv, a possibility would be to do 
install-time build, through triggers for example.


signature.asc
Description: This is a digitally signed message part.

Re: What can Debian do to provide complex applications to its users?

[Didier 'OdyX' Raboud]

Le mercredi, 28 février 2018, 04.57:50 h CET Russell Stuart a écrit :
> On Tue, 2018-02-27 at 14:13 +0100, Didier 'OdyX' Raboud wrote:
> > > - we could ship those applications not as .deb but as container
> > >
> > >   and let them have their own lifecycle
> > 
> > tl;dr: a new package format is needed, with a new non-suite-specific 
> > repository is needed to bring the Debian added-value to these
> > ecosystems.
> 
> To me 'container' is the right solution.

For me, this is orthogonal.  How your binaries or artifacts are orchestrated 
and isolated from eachothers doesn't have much to do with where they come from 
and how they're built.

I'm not looking forward to having to maintain hierarchies of containers in 
which software is pulled from various different sources which don't have a 
shared agreement on what constitutes Free Software, sane security guidelines, 
etc.  Ewww, wait…

The hard problem is how to keep fostering and providing the four software 
freedoms, not (only) how to ship software.

> (a grandiose and far fetched proposal)

I don't disagree that smart containerization would make a better Debian.  But 
not if we loose track of what binary gets installed from which source.  
Reproducibility and traceability are really important, and we should not throw 
them away for sake of more convenient software deployment.

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: What can Debian do to provide complex applications to its users?

[Didier 'OdyX' Raboud]

Le vendredi, 16 février 2018, 16.11:29 h CET Raphael Hertzog a écrit :
> I don't have any definite answers although there are ideas to explore:
> 
> - we could relax our requirements and have a way to document the
>   limitations of those packages (wrt our usual policies)
> 
> - we could ship those applications not as .deb but as container
>   and let them have their own lifecycle

tl;dr: a new package format is needed, with a new non-suite-specific 
repository is needed to bring the Debian added-value to these ecosystems.

My current understanding of the problem is that there are two problems 
entangled with eachothers, for which Debian is currently not providing 
solutions

* version spread
* layer-specific expectations

# Version spread

Certain software will need to be available in multiple versions to satisfy 
reverse dependencies constraints, be it for convenience reasons ("the 
only version of that library my application has been tested with"), 
willingness to use the shiniest and latest, or any other reason.

We have that problem already with jQuery and others, but it seems to be mostly 
contained thanks to reasonable back- and forward- compatibility. As Debian, we 
are insisting that our releases ideally only contain a single version of a 
software, that we insist is made available at system-level. The reasons for 
that are multiple, but the main one is the facilitated tracking and fixing of 
security issues, that we then only have to fix once, thereby protecting all 
its reverse dependencies. As has been mentioned with the example of Django, 
some software change too rapidly and too much for that single-version 
constraint to hold [0], and providing only one version is bound to not satisfy 
most reverse dependencies' needs; in other words, it's not going to be used.

Another aspect of the version spread is that it limits the set of software we 
check DFSG-freeness of. There's an initial "seal-of-approval" from the FTP-
Masters when going through NEW, but then it is currently left to the 
maintainer and the community to do this ongoing check. The cristallization 
towards the stable release will also encourage checking for eventual 
violations in only one version per software.

# Layer-specific expectations

Debian has long insisted that all software shipped in 'main' is constrained by 
the same standards (DFSG, Debian Policy, minimal code duplication, 
buildability, portability, maintainability over the course of a stable release 
cycle, etc), and gets the same support "in return" (security support, common 
bugtracker, etc). This is a very good model for "lower layers"; the plumbing 
(outside of new hardware support): I don't really care what version of CUPS I 
get, as long as I can print; I don't really care what minor version of Apache 
I get as long as it works, etc etc.

On the other hand, when developing a  application, with a rapidly-moving ecosystem, developer will insist on 
having the latest version of plenty of my direct dependencies, because working 
on whatever was released in Debian stable will just be a hassle more than a 
help. Also, the friction for them to fix a bug they have experienced in one of 
these dependencies is much lower than getting it fixed in Debian stable: given 
a responsive maintainer, one can get a new release with a pull request merged 
in a matter of days; and if that doesn't work, the tools allow to get a 
precise git hash for a given project. They can fix the bug, use the fixed 
version, and go on with my development.

The point I'm trying to make, which I hope is obvious, is that the 
expectations upon software in different layers are vastly different: I want 
rock-solid kernel, libc and language interpreter, I want reasonably recent 
intermediate layers, but I want bleeding edge direct dependencies. Of course, 
fast-moving layers will not provide the same warranties as slow-moving layers.
In a Debian-idealistic world, we could hold all layers up to the same 
standards, stabilize them up to a point where they can become part of stable, 
and all application developers would use Debian's set of libraries, from 
stable. Point is, that's not what is expected from Debian either: a Python 
application will only use Debian's python interpreter and virtualenv, all the 
rest will be taken from somewhere else than Debian, because it's way closer to 
how it'll be developped, and in many cases (just one missing library in 
stable), the only reasonable way to deploy said application. Then, instead of 
having only Debian as 'security' counterpart (getting the host to a secure 
state through a `apt upgrade`), the application developer now has to (do 
they?) care about the closer layer's security hirself.

# Now, onto a solution

In other words, vendorization is the tool that allows developers to get rid of 
distribution constraints and get on with their development through installing 
the dependencies from their ecosystem as they see fit (non-root), in the 
(eventually 

Re: Extended Long Term Support for Wheezy

[Didier 'OdyX' Raboud]

Le jeudi, 22 février 2018, 19.44:06 h CET Roberto C. Sánchez a écrit :
> If we are going to start applying this sort of logic to naming, then
> there are plenty of other places (e.g., where actual vulgarities are
> used in package names, where abreviations and/or acronyms create words
> that are or can be perceived as offensive, etc.).

It's more prominent in suite names than in package descriptions though, as it 
will go in documentation, in apt sources' snippets, etc.

Anyway, not a battle I'll fight; I fully trust the proponents to have heard 
that argument and make a sane suite name choice :-)

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: Extended Long Term Support for Wheezy

[Didier 'OdyX' Raboud]

Le mardi, 20 février 2018, 16.07:03 h CET Raphael Hertzog a écrit :
> ("super long-term maintenance", SLTS in their jargon)

A small point, but I haven't seen anyone mention it yet: I would not use the 
'slts' acronym, basically anywhere, as it is very close to the 'sluts' smear 
word.

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

CUPS GPL → Apache license change, how to proceed?

[Didier 'OdyX' Raboud]

tl,dr; CUPS has moved from "GPL-2.0 with AOSDL exception" to "Apache-2.0"; how 
should the license incompatibilities be enforced?


As you might have heard [lwn][cups-apache], Apple has changed the CUPS license 
away from a "GPL-2/LGPL-2 with exceptions" to plain Apache-2.0, effective in 
the 2.3 branch [23branch] and available from 2.3~b1 on [23b1].

Despite bold attempts from Fedora and Debian community members to try 
clarifying what issues this change causes and the incompatibilities it 
creates, Apple has, so far, unsurprisingly not changed CUPS' license.

The principal issue, as I understand it, is that the Apache-2.0 license is 
incompatible with GPL-2 [apache-gpl2], although compatible with GPL-3 
(therefore compatible with GPL-2+, and with LGPL through LGPL→GPL-3).  See the 
lengthy explanation by Tom Callaway on Fedora's legal list [fedora-tom].

Further, it is my (current) understanding that having Apache-2.0 software (for 
instance, CUPS) in a dynamically-linked construct together with GPL-2-only 
software makes the result undistributable.  This seems to be a situation which 
Debian needs to protect its users from.

One way out, as outlined by Mike Sweet [system-library] as upstream author, is 
for Debian to consider that libcups/libcupsimage qualify as system-supplied 
libraries for the purposes of GPLv2.  Having these two libraries in LSB could 
support that argument, but, using that argument, Debian could have gone away 
for the OpenSSL case long ago, and didn't.  I made it clear to upstream [odyx-
statement] that this was most certainly not going to happen.

Some questions at this point (Some for FTP Masters, CC'ed):
- Does Debian hold the view that Apache-2.0 and GPL-2.0-only dynamic linking 
is unacceptable for Debian main?  In both directions?
- Can CUPS link against GPL-2-only code?
- Can GPL-2-only code link against CUPS?
- Whose reponsibility is it to check for these incompatibilities, and make 
sure they are not shipped in Debian?


Now, onto the ways forward. From a quick glance, the libraries CUPS links 
against don't seem to be an issue [CUPS-links-to], so let's focus on the 
libraries linked against CUPS' libraries (libcups2, libcupsmime1, 
libcupsppdc1, libcupsimage2, libcupscgi1).  Using `build-rdeps`, it appears 
there are 5345 packages that (also indirectly) build-depend on these packages 
(attached). I am not going to review all these by hand.  So, new questions:

- What tools should I be using to identify which of these will be 
undistributable constructs?  Aka: how, given a list of source packages, can I 
determine which are GPL-2-only in the codepaths that link against CUPS?
- What fields could I / should I use in src:cups to enforce these?  I was 
initially thinking of setting versionless Breaks: in each src:cups' library 
against the identified GPL-2-only culprits, then mass-filing bugs against 
these, promising to add version constraints when/if the licensing issue gets 
lifted. Does that sound like a good way forward?

Many thanks in advance for your insights!

Cheers,
OdyX

(
  A build-ready package is available from CUPS' Vcs-Git, in branch
  debian/experimental [cups-deb], just `dch -v2.3~b3-1local0` before building
)

[lwn] https://lwn.net/Articles/738531/
[cups-apache] https://lists.cups.org/pipermail/cups-devel/2017-November/
017085.html
[23branch] https://github.com/apple/cups/tree/master
[23b1] https://github.com/apple/cups/releases/tag/v2.3b1
[apache-gpl2] https://www.apache.org/licenses/GPL-compatibility.html
[fedora-tom] https://lists.fedoraproject.org/archives/list/
le...@lists.fedoraproject.org/message/NEQDL6V4RBRQTPI3YYBSZH5CTZG257F2/
[system-library] https://lists.cups.org/pipermail/cups-devel/2017-November/
017095.html
[odyx-statement] https://lists.cups.org/pipermail/cups-devel/2017-December/
017097.html
[cups-deb] https://salsa.debian.org/printing-team/cups/tree/debian/
experimental

[CUPS-links-to] CUPS dynamically links against
(excluding 'system libraries' such as libc, libgcc, libstdc++)
- cups → libusb-1.0-0 (LGPL-2.1)
- libcups2 → libavahi-client3 & libavahi-common3 (GPL-2+)
- libcups2 → libc6 (GPL-2+)
- libcups2 → libgnutls30 (LGPL-2.1+)
- libcups2 → libgssapi-krb5-2 (MIT)
- libcups2 → zlib1g (Zlib)0ad
2048-qt
389-admin-console
389-console
389-ds-console
3depict
3dldf
4pane
4ti2
a2ps
aac-tactics
abego-treelayout
abgate
abinit
abiword
ableton-link
abntex
aboot
abx
accerciser
access-modifier-checker
accessodf
ace
acedb
ace-link
ace-popup-menu
acetoneiso
ace-window
acl2
aclock.app
actiona
activemq
activemq-activeio
activemq-protobuf
actor-framework
adacontrol
ada-reference-manual
adasockets
addresses-for-gnustep
adql
adun.app
advi
adwaita-icon-theme
adwaita-qt
aegisub
aeskulap
aespipe
aether
aether-ant-tasks
aewm
afew
affiche
afterburner.fx
afterstep
agda
agenda.app
aggressive-indent-mode
aghermann
aiksaurus
airlift-airline
airlift-slice
airport-utils
aiscm
aisleriot
akonadi

Re: Debian Stretch new user report (vs Linux Mint)

[Didier 'OdyX' Raboud]

Le lundi, 4 décembre 2017, 23.18:21 h CET Philipp Kern a écrit :
> On 04.12.2017 19:03, Holger Levsen wrote:
> > On Mon, Dec 04, 2017 at 05:36:30PM +, Ian Jackson wrote:
> >> Lars Wirzenius writes:
> >>> Myself, I would prefer us to keep both the free-software-only ISO and
> >>> the non-free ISO with firmware and other things needed to get typical
> >>> modern hardware running, and improve the discoverability of the
> >>> latter. I think we can do that without having to have a GR to change
> >>> the Social Contract or the DFSG.
> >> 
> >> Yes.
> > 
> > yes, I also agree this would work and be better than the status-quo.
> > however I'm inclined to believe doing this and adding a fourth repo,
> > non-free-firmware (additionally to main, contrib and non-free) would
> > be even better and also not need a GR.
> 
> I like that this *finally* gets some traction. I have floated a GR
> before but people seem to be reluctant to have yet another vote.

It's a healthy discussion to be had, but we really should stop being scared by 
GRs. We had 3 in 2016 without much problems afterall.

Instead of assuming a consensus from a debian-devel discussion, I certainly 
see value in both the wordsmithing happening during the discussion, and in the 
relative weighing of various slightly nuanced versions that comes as output 
from the vote.

There's also value for the Debian project to be explicit when and if diverging 
from a longstanding tradition. We're discussing various different options 
here, and they don't all have the same symbolic weight:
* making the current "embeds distributable non-free firmware" ISO image more 
visible;
* splitting non-free in subsets;
* adding a non-free-firmware area;
* making the above ISO image the default image;
* etc.

To be honest, I don't think we are currently at a point in the discussion 
where we all feel the same consensus given the above (non-finite) set of 
options. Having an explicit vote will help better understanding where we stand 
as a project; also how we prioritise these.

tl:dr; don't be afraid of a GR, just do it calmly :-)

Cheers,
OdyX

Re: Auto-update for sid? Auto-backport?

[Didier 'OdyX' Raboud]

Le jeudi, 16 novembre 2017, 09.03:47 h CET Alexander Wirt a écrit :
> On Wed, 15 Nov 2017, Didier 'OdyX' Raboud wrote:
> > Le mercredi, 15 novembre 2017, 16.43:17 h CET Steffen Möller a écrit :
> > > I would really like to see updates performed in some automated fashion.
> > 
> > Debian updates are in fact different steps:
> > * inclusion of upstream changes;
> > * packaging updates;
> > * .changes signing with a key in the Debian keyring;
> > * dput of the .changes and associated files.
> 
> Testing the package. Maybe the most important point. From my experience as
> backports ftpmaster I could say that I am not very thrilled to see such
> automatic upload repos. 

Oh, absolutely. But testing can have multiple forms, and we could imagine 
requiring autopkgtest before migrating stuff from this automatic suite to 
user-facing suites. Something along the lines of what Ubuntu AFAIK does with 
their pre-development release suite; a no-delay britney that checks suite 
coherency (migrations) and autopkgtests.

OdyX

Re: Auto-update for sid? Auto-backport?

[Didier 'OdyX' Raboud]

Le mercredi, 15 novembre 2017, 16.43:17 h CET Steffen Möller a écrit :
> I would really like to see updates performed in some automated fashion.

Debian updates are in fact different steps:
* inclusion of upstream changes;
* packaging updates;
* .changes signing with a key in the Debian keyring;
* dput of the .changes and associated files.

The two first ones can (and often should) be automated, but a human check 
should happen at either of the two latter ones, most probably the signing one, 
as that where the uploading DD certifies the upload.

People in various areas of Debian (as well as outside) have automated one or 
multiple of these steps, but with uploads outside of Debian suites: automated 
build from git heads, automated uploads to reprepro repositories, etc. But I'm 
not aware of unsupervised uploads to Debian.

(At this point of the discussion, it seems to me that an unsupervised upload 
to Debian unstable is not a problem _per se_; a broken one would certainly be 
though.)

> Maybe into a different section of Debian like sid-auto? The problem with
> that obviously is the missing scrutiny by the human maintainer, so it
> cannot go straight into sid. Or can it?

An interesting infrastructure could provide a suite to which (unsigned ?) 
source packages could be sent for build. The output would be a build log and a 
_source.changes. As maintainer you'd be left with checking the build and 
`debsign -r` the .changes file that could then be auto-dput to Debian.

Now that we have source only uploads, none of that would need to be on Debian 
infrastructure; the build would be there merely for guaranteeing that your 
package actually builds.

> Maybe with an auto-created bug report against the package so it does not 
> auto-migrate into testing?

I would not (ab)use bugs for something that should also be automated. Iff 
we're going to have automated uploads, then it should be somehow integrated in 
britney: massaging bugs for that purpose feels wrong.

Cheers,
OdyX

Bug#879214: ITP: planetblupi -- Planet Blupi - A delirious spell-binding game

[Didier 'OdyX' Raboud]

Package: wnpp
Severity: wishlist
Owner: Didier 'OdyX' Raboud <o...@debian.org>

Package name: planetblupi
Version : 1.11.0
Upstream Author : Mathieu Schroeter, Daniel Roux, EPSITEC SA & Denis Dumoulin
URL : http://blupi.org/
License : GPL-3+
Programming Lang: C++
Description : Planet Blupi - A delirious spell-binding game
 Planet Blupi is a strategy and adventure game. It subtly blends action with
 thought-provoking challenges. Behind the quiet and gentle facade, you'll enjoy
 a fascinating diversion full of surprises.

This is another of the finally-freed games from Epsitec. The other one is
Colobot (src:colobot), already in Debian.

Its build-dependencies have reached NEW already. I will put it under the
Debian Games Team umbrella.

Bug#879103: ITP: doctest -- Light and feature-rich C++ testing framework

[Didier 'OdyX' Raboud]

Package: wnpp
Severity: wishlist
Owner: Didier 'OdyX' Raboud <o...@debian.org>

Package name: doctest
Version : 1.2.5
Upstream Author : Viktor Kirilov <vik.kiri...@gmail.com> 
URL : https://github.com/onqtam/doctest
License : MIT
Programming Lang: C++
Description : Light and feature-rich C++ testing framework
 doctest is a light and feature-rich C++98 / C++11 single-header testing
 framework for unit tests and TDD.
 .
 It is inspired by the unittest {} functionality of the D programming
 language and Python's docstrings - tests can be considered a form of
 documentation and should be able to reside near the production code
 which they test. This isn't possible (or at least practical) with any
 other testing framework for C++.

Justification: doctest is a B-D of argagg (ITP #878641)
Package name: doctest-dev, as the package installs /usr/lib/doctest/doctest.h

I welcome suggestions on the source or binary names, as well as packaging :)

Bug#878673: ITP: sdl-kitchensink -- FFmpeg and SDL2 based library for audio and video playback

[Didier 'OdyX' Raboud]

Package: wnpp
Severity: wishlist
Owner: Didier 'OdyX' Raboud <o...@debian.org>

Package name: sdl-kitchensink
Version : 0.0.7
Upstream Author : Tuomas Virtanen <katajak...@gmail.com>
URL : https://github.com/katajakasa/SDL_kitchensink
License : MIT
Programming Lang: C
Description : FFmpeg and SDL2 based library for audio and video playback
 * Decoding video & audio via FFmpeg
 * Dumping video data on SDL_textures
 * Dumping audio data in the usual mono/stereo interleaved formats
 * Automatic audio and video conversion to SDL2 friendly formats
 * Synchronizing video & audio to clock
 * Seeking forwards and backwards
 * Bitmap & libass subtitle support. 

Justification   : sdl-kitchensink is a build dependency of "Planet Blupi"
 (http://blupi.org) which I intend to package for Debian.
Package names   : libsdl-kitchensink0 libsdl-kitchensink-dev

Bug#878641: ITP: argagg -- Argument Aggregator - Simple C++11 command line argument parser

[Didier 'OdyX' Raboud]

Package: wnpp
Severity: wishlist
Owner: Didier 'OdyX' Raboud <o...@debian.org>

Package name: argagg
Version : 0.4.6
Upstream Author : Viet The Nguyen <vietjtngu...@gmail.com>
URL : https://github.com/vietjtnguyen/argagg
License : MIT
Programming Lang: C++
Description : Argument Aggregator - Simple C++11 command line argument 
parser
 This is yet another C++ command line argument/option parser. It was
 written as a simple and idiomatic alternative to other frameworks like
 getopt, Boost program options, TCLAP, and others. The goal is to achieve
 the majority of argument parsing needs in a simple manner with an easy
 to use API. It operates as a single pass over all arguments, recognizing
 flags prefixed by - (short) or -- (long) and aggregating them into easy
 to access structures with lots of convenience functions. It defers
 processing types until you access them, so the result structures end up
 just being pointers into the original command line argument C-strings.
 .
 argagg supports POSIX recommended argument syntax conventions.

Justification   : argagg is a build dependency of "Planet Blupi"
 (http://blupi.org) which I intend to package for Debian.
Package names   : argagg-dev & argagg-dev-doc

Re: changes to upload queue for security archive

[Didier 'OdyX' Raboud]

Le lundi, 9 octobre 2017, 20.20:15 h CEST Simon McVittie a écrit :
> For embargoed issues, is it better to upload via ssh and have the upload
> briefly readable by other DDs, or to upload via ftp and have the upload
> briefly readable by everyone on the network path between the DD and
> security.upload.debian.org?

It seems to me that the question embeds the answer.

-- 
OdyX

Re: Bug#877212: [Pkg-javascript-devel] Bug#877212: node-d3-color: B-D npm not available in testing

[Didier 'OdyX' Raboud]

Le jeudi, 5 octobre 2017, 13.29:16 h CEST Ian Jackson a écrit :
> I have also heard of packages which do "apt-get source" in their rules
> files.

debian-installer-netboot-images does a similar thing, but it's more of a shell 
re-implementation of a trust chain check:
http://sources.debian.net/src/debian-installer-netboot-images/
20170615%2Bdeb9u1/get-images.sh/

(Patches welcome, of course)

The reason for that (and #807168 documents this) is that:
* d-i-n-i binary packages are arch:all packages with arch-specific content; 
because we want to ship any arch's netboot images on all architectures; and 
forcing the use of multiarch for that is overkill.
* building these arch:all packages in an arch:any build (such as d-i's) is not 
supported and would be a heavy arm-twisting of our buildd infrastructure.

tl;dr; It's certainly no good, but it's the best we have.

> I think that both of these activities are reasonable things to do.
> They don't violate the self-containedness of Debian.  If they are
> technically forbidden by policy then policy should be changed.

Well. #807312 tracks a way to eventually do the above in a policy-compliant 
way: build arch:any packages containing netboot images and build d-i-n-i using 
multiarch Build-Depends.

As for changing Policy; what matters is that we ultimately build things from 
known and DFSG-free _sources_, in a reproducible way. dpkg, apt and sbuilds 
are just (_FANTASTIC_) means to that end. So we either need better tooling 
than the above hideous shell, or massage everything into existing tooling. I 
prefer the "there's a RC bug to fix" situation over a "weaker policy", for now.

Cheers,
OdyX

Re: Debian Policy 4.0.1.0 released

[Didier 'OdyX' Raboud]

For further reference, the full TC decision text is at:
[0] https://lists.debian.org/debian-devel-announce/2015/09/msg0.html

Le dimanche, 6 août 2017, 11.40:26 h EDT Guillem Jover a écrit :
> At this point I guess the decision to cope fairly with such subpar and
> imposed policy that a maintainer that has a package shipping both a
> desktop file and a menu file is either to:
> 
>  - ignore it, very sadly violating policy, :( at least until there's
>a proper transition plan that does not leave users and WM/DE
>maintainers in the cold,

In September 2015 [0], the TC proposed a transition plan, in the form of 
points 3. & 4. :
>3. We further resolve that "menu programs" should not depend on the
>Debian Menu System and should instead rely on .desktop file
>contents for constructing a list of applications to present to
>the user.
>4. We advise the maintainers of the 'menu' package to update that
>package to reflect this increased focus on .desktop files by
>modifying the 'menu' package to use .desktop files for the
>source of menu information in addition to menu files.

One "proper transition plan" has been proposed, and there was no visible 
result in almost two years; it's certainly sad that`xdg-menu` (from Arch, see 
[1]) has not been packaged; nor did our very own `menu` [2] receive enough 
love.

The other recourse was (well, still is) a GR, which hasn't happened either.

As I wrote back then [3] (and I haven't changed my mind) : 
> the burden of keeping the trad-menu relevant would be (IMHO correctly) put
> on people who care about it, instead of leaving it on all package
> maintainers through the Debian Policy.

Also in [4]:
> The "trad-menu" database will be preserved iff there is enough manpower
> to make this happen: either through an automated desktop-to-menu
> translation interface, or through a centralisation of that database.

Le dimanche, 6 août 2017, 11.40:26 h EDT Guillem Jover a écrit :
>  - protest it, and still be policy compliant, by going the Solomonic
>route and removing both files.

That would be stupid, to be blunt.

The next step is that this policy change is likely to find its way as a Lintian 
warning (or error). But we're still _very_ far from mass bug reports, without 
even talking about their severity (and several TC members indicated they were 
against 'serious' severity).

OdyX

[1] https://wiki.archlinux.org/index.php/xdg-menu
[2] https://tracker.debian.org/pkg/menu
[3] https://lists.debian.org/debian-ctte/2015/08/msg00076.html
[4] https://lists.debian.org/debian-ctte/2015/08/msg00046.html
[5] https://lists.debian.org/debian-ctte/2015/09/msg5.html

signature.asc
Description: This is a digitally signed message part.

Re: -all driver packages

[Didier 'OdyX' Raboud]

Le lundi, 12 juin 2017, 23.26:01 h CEST Rebecca N. Palmer a écrit :
> However, those involve Depends relationships (where an -all package is 
> needed to allow the option of only installing one) and/or multiple 
> depending/recommending packages and a changing set of providers (making 
> it desirable to be able to make such changes in one central place). 
> Hence, I agree that it wouldn't be worth it for *-microcode.

The printer-driver-all package uses Recommends, but its source package also 
builds the printer-driver-all-enforce alternative package that has the same 
relations but as Depends. As britney only checks for Depends when verifying 
migration requirements, this setup makes sure that the printer-driver-all 
package only ever migrates if all its Recommends are satisfied. the -enforce 
alternative is not meant to be used by end-users.

-- 
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: Hello! How can I delete Debian from menu before Windows loading?

[Didier 'OdyX' Raboud]

Le samedi, 27 mai 2017, 21.01:46 h CEST Александр Макаров a écrit :
> Hello!
> 
> I am thinking to use Debian, but later, because I have no time now.
> 
> How can I delete Debian from menu before Windows loading?

You need to uninstall win32-loader using its' uninstaller, which should be 
located in `C:\win32-loader\Uninstall.exe`

Cheers,
OdyX

Re: Is missing SysV-init support a bug?

[Didier 'OdyX' Raboud]

Le lundi, 29 août 2016, 12.07:23 h CEST Dmitrii Kashin a écrit :
> But I know a lot of them. And not only in Debian community. And they
> don't agree that migrating will give them greater control over their
> systems.

This is not a popularity contest, in which we'd count points either way. We, 
as the Debian community, are discussing what we want to offer to our users, 
given our interests, capabilities, and manpower. Mobs don't produce patches.

> If you want I'll ask them to write here too.

Please don't.

-- 
Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Refresh the CUPS driver recommends (was: Re: Opt out style recommends)

[Didier 'OdyX' Raboud]

Package: cups
Version: 1.5.2-9

Le vendredi, 8 avril 2016, 10.31:17 Josh Triplett a écrit :
> I'm not going to go through a full analysis here, but here's a *tiny*
> subset of the output on my system, with some annotations:
> 
> (…)
> cups Recommends: printer-driver-gutenprint
> 
> Why does cups recommend some printer drivers and only suggest others?
> For instance, I have printer-driver-hpcups installed instead.

This should indeed be changed. Reporting a bug to keep track.

-- 
Cheers,
OdyX

Re: Status of the src:lsb package

[Didier 'OdyX' Raboud]

Le jeudi, 17 septembre 2015, 23.00:51 Michael Biebl a écrit :
> Am 17.09.2015 um 14:56 schrieb Didier 'OdyX' Raboud:
> > After the discussion [0] about these changes back in July (on both
> > debian-lsb@ and debian-devel@), I have uploaded src:lsb 9.20150826
> > to
> > unstable, building no LSB compatibility packages anymore (besides
> > lsb- release and lsb-base). As far as I could see, this didn't
> > affect anything in unstable at the time (and that's how things
> > should be).
> So far I only stumbled upon one proprietary deb which has a Depends:
> lsb, which will be broken by dropping the lsb compat packages.
> It's the closed-source Epson printer driver [1]. It's a rather badly
> maintained package (using alien), still wanted to mention it as a data
> point.

LSB-"compliant" (FSVO 'compliant') printing drivers are certainly a 
problem. That said, it's a problem that I'd rather tackle with re-
packaging, upload to non-free, or any other more Debian-specific method. 
In this specific case, there's at least some part that comes in LGPL 
source form.

The Debian Printing Team welcomes all interested parties :-)

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: Status of the src:lsb package

[Didier 'OdyX' Raboud]

Hi Nikolaus,

Le jeudi, 17 septembre 2015, 09.27:56 Nikolaus Rath a écrit :
> On Sep 17 2015, Didier 'OdyX' Raboud <o...@debian.org> wrote:
> > Le jeudi, 17 septembre 2015, 08.46:24 Nikolaus Rath a écrit :
> >> I don't know about formal LSB compatibility, but there are several
> >> proprietary applications that require nothing but the
> >> /{lib,lib64}/ld-lsb.so* symlinks to work properly under Debian. So
> >> it would be great if they could be preserved.
> > 
> > FYI, this used to be in lsb-core, and is to be found in the package
> > VCS history.
> > 
> > I will not work towards this, but feel free to adopt the package and
> > upload an updated version.
> 
> I'm only a DM and having to search for a fresh sponsor for every
> upload is very frustrating. Would you be generally available to
> sponsor my uploads (ideallyl until you feel comfortable to give me
> upload privileges)?

Given that I'm (so far) convinced that _not_ providing the lsb packages 
at all is the correct thing to do for Debian, I'd prefer if another DD 
could sponsor any upload of src:lsb re-introducing these (and drop me 
from Uploaders).

That said, as for the technical issue at hand, iff these symlinks [0] 
are useful to make Debian relevant for (some) non-free software out 
there, couldn't they be handled directly by libc6 on the various 
architectures ?

src:eglibc maintainers: opinions ?

Cheers,
OdyX

[0] 
http://anonscm.debian.org/cgit/collab-maint/lsb.git/tree/debian/lsb-core.postinst?id=96a2bf324aa67a68d30387804f18ccb5a7bb0d88

signature.asc
Description: This is a digitally signed message part.

Re: Status of the src:lsb package

[Didier 'OdyX' Raboud]

Le jeudi, 17 septembre 2015, 08.46:24 Nikolaus Rath a écrit :
> I don't know about formal LSB compatibility, but there are several
> proprietary applications that require nothing but the
> /{lib,lib64}/ld-lsb.so* symlinks to work properly under Debian. So it
> would be great if they could be preserved.

FYI, this used to be in lsb-core, and is to be found in the package VCS 
history.

I will not work towards this, but feel free to adopt the package and 
upload an updated version.

Cheers,
OdyX

P.S. Please keep debian-lsb@ in the loop.

Status of the src:lsb package (was: Debian LSB compliance)

[Didier 'OdyX' Raboud]

Hi all,

It is time for an update about the lsb source package status, especially 
as a quite important change landed in testing.

After the discussion [0] about these changes back in July (on both 
debian-lsb@ and debian-devel@), I have uploaded src:lsb 9.20150826 to 
unstable, building no LSB compatibility packages anymore (besides lsb-
release and lsb-base). As far as I could see, this didn't affect 
anything in unstable at the time (and that's how things should be).

This change landed in stretch on September 14. and is de facto the 
"outright giving up" of LSB support for Debian, from stretch onwards. As 
mentionned in the NEWS.Debian entry, the lsb-base (init-functions) and 
lsb-release packages are still available, and are here to stay: lsb-
release has 102 reverse-depends, and lsb-base has 800+ reverse-depends.

But Debian's not throwing all of the LSB overboard: we're still firmly 
standing behind the FHS (version 2.3 through Debian Policy; although 3.0 
was released in August this year) and our SysV init scripts mostly 
conform to LSB VIII.22.{2-8}. But don't get me wrong, this src:lsb 
upload is an explicit move away from the LSB.

I will keep an eye on src:lsb, but really, I don't intend to invest much 
more time; so I'll happily hand over maintainership to anyone wanting to 
invest time in LSB 5.0 Debian support.

Cheers,
OdyX

[0] https://lists.debian.org/4682310.7LIWdV4Lar@gyllingar

signature.asc
Description: This is a digitally signed message part.

Re: Security concerns with minified javascript code

[Didier 'OdyX' Raboud]

Le mardi, 1 septembre 2015, 17.50:26 Vincent Bernat a écrit :
>  ❦  1 septembre 2015 08:21 -0700, Nikolaus Rath  :
> >>> Couldn't we just use the non-minified versions in most situations?
> >>> A
> >> 
> >> Not for anything which has actual users over the network.
> > 
> > Why? (Don't forget about gzip encoding).
> 
> See:
>  https://mathiasbynens.be/demo/jquery-size

What this tells us is that the size wins for the latest jquery version 
are the following :

* gzip only -> 29.7%
* zopfli only -> 28.1%
* minifying + gzip -> 11.9%
* minfying + zopfli -> 11.5%

So, taking this jquery example, if minifying is too hard, we can still 
go below 30% of the total size by applying gzip only.

That said…

We should not forget that "minified+gzipped JS" is only a temporary 
state of things. The web ecosystem moved from "ship the full JS source 
to users" (which was way easier in terms of software freedom) to 
"miinified JS". We're at the point where we debate whether this 
"minified JS" is valid source for us (technically, it is valid JS code, 
but not the preferred form of modification).

But the web ecosystem is moving towards WebAssembly [0,1], that will be 
"a portable, size- and load-time-efficient binary format" [2]. Where 
"minified JS" could be seen as source-code, WebAssembly will definitely 
not. If we accept the compromise to not run the compilation step from JS 
to "minified JS", will it be tenable to not run it either for 
_binaries_?

Although I'm concerned by this, I don't doubt much that WebAssembly (or 
any other binary format for the web) _will_ be coming to the web, our 
upstreams, and will become their preferred way to ship frontend code to 
their users. We'll have to deal with that, and we should get ourselves 
ready for that.

The current web compilation stack is arguably ugly, painful to maintain, 
and a big source of frustration, and I can therefore understand how 
maintainers end up not doing the compilation in the Debian package 
build; but really, if we don't do it now, what will happen with binary 
formats?

I think we should take a strong move there and exercise (as well as 
justify to the outer world) our free software right to recompile the 
software that we ship to our users: this could mean to only merge & gzip 
JS files if minifying isn't realistic [3]. Not doing so _is_ going to 
hurt our ability to exercise our freedoms in the future, it's also 
making a disservice to our users.

Cheers,
OdyX

[0] https://blog.mozilla.org/luke/2015/06/17/webassembly/
[1] https://github.com/WebAssembly
[2] https://github.com/WebAssembly/design/blob/master/HighLevelGoals.md
[3] Reducing to 29% instead of 12% might be the price of our freedom
there…

Re: Debian LSB compliance

[Didier 'OdyX' Raboud]

Le vendredi, 3 juillet 2015, 13.20:08 Mats Wichmann a écrit :
 On 07/03/15 07:28, Didier 'OdyX' Raboud wrote:
  The crux of the issue is, I think, whether this whole game is worth
  the work: I am yet to hear about software distribution happening
  through LSB packages [4]. There are only _8_ applications by 6
  companies on the LSB certified applications list [5], of which only
  one is against LSB = 4. Amongst the distributions, RHEL 7.0 is
  LSB4.1, and Oracle 6, RHEL 6.0 and Ubuntu 9.04 are LSB 4.
  
  As a data point, I've just noticed that the Linux Foundation issued
  LSB 5.0 and FHS 3.0 [6] just yesterday. But that doesn't change the
  arguments, I think.
 
 The current distribution checker is actually quite easy to set up,
 it's just a package to install and off you go, answer a few questions
 through a web interface. Should you have the patience to fire off 10+
 hours of tests and then want to look at them. You would need that for
 compliance which has never directly been a Debian goal, as you say.

Fair enough, but then what?

Let's assume we test 'stretch', our next stable release.

Case a) Tests show that it is compliant so far, and by some magic 
trickery, this stays true until release day. In this case, we should 
apply for full certification, and use that as an sales argument.

Case b) Tests show that it isn't: some problems might point to 
meaningful changes, but some others might not be fixable? We'd be non-
compliant, and all that work would be a wasted effort.

From what I understand (given the timescales), changing the LSB to be 
whatever Debian as well as all other actors in the FLOSS world are 
_actually_ doing is a painful, long and boring process, that the people 
involved in the LSB processes are only very slowly doing by themselves 
(no offense intended).

The packages we currently have were built for LSB4.1, and the LSB5.0 
just went out. Are there people out there interested in making the LSB 
relevant through certifying Debian 'stretch' for LSB5 [0]? Let's face 
it: given the current importance of Debian in the distributions' 
ecosystem, our decision with regards to becoming LSB5 certified (or not) 
could be decisive: if we commit to it, and establish efficient 
communication channels to push for LSB changes (eventually leading to a 
LSB5.1 == Debian strectch), then this /could/ make LSB5 somewhat more 
relevant than it ever was.

If we don't, and instead outright give up on LSB support, then this 
might very well be a further nail in the LSB coffin.

Given
a) the work that certifying Debian would take;
b) the interest in having Debian be certified (I am yet to see any of 
that interest);
c) the marginal interest by application vendors for the LSB;

… I'm leaning towards outright giving up.

Of course, I could simply orphan src:lsb and be done with it, but I feel 
we'd be much better off with a src:lsb package that either does, or 
doesn't at all provide LSB5 certification: the middle ground that we've 
stayed in is helping neither Debian or LSB.

So, are there any volunteers to make Debian LSB-certified? I'm likely to 
work on src:lsb during DebConf, so please make yourself known before 
then!

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Debian LSB compliance (was: Re: Standard-producing bodies and Debian)

[Didier 'OdyX' Raboud]

Hi Gunnar,

just jumping on one specific point, sorry to hijack the thread…

(Reply-To set to debian-lsb, please followup there…)

tl;dr: proposal to shrink src:lsb to only produce lsb-base and lsb-
release

Le jeudi, 2 juillet 2015, 09.15:12 Gunnar Wolf a écrit :
 But then I realized I was lying.
 
 Debian does take care to implement several standards (i.e. following a
 LSB-compliant POSIX system

This is only true to a certain extent: we do [0] care about a certain 
level of compatibility with LSB around initscripts and the existence of 
a lsb_release binary [1]. Debian has (ab)used the src:lsb package to 
host more and more common code over the years (see your /lib/lsb/init-
functions{,.d/} and all of lsb-base): left info blocks, all the 
log_{daemon,progress,end,action_msg shell functions, etc. (Sadly enough, 
there's even a code difference between the Ubuntu and Debian versions of 
pidofproc. /o\ )

But… the largest part of the LSB specification is about API 
compatibility: all the 
lsb-{base,core,cxx,desktop,graphics,languages,multimedia,printing,security} 
packages _try_ to make sure that the correct packages are present, but 
there is (as far as I know) nobody on the Debian side actually 
_checking_ that all symbols are actually present, or that they stay 
present. At the time of LSB4.1, for x86, we were talking about 1493 
components, 1672 libs, 38491 commands, 30176 classes and 716202 
interfaces [2].

(There's of course also the FHS, that we modify with our own exceptions 
anyway, but it is part of the LSB.)

We're also not checking this because the LSB compatibility of Debian 
releases has never been a topic and I don't see anyone asking a library 
maintainer to stay at an older version and/or maintain a patch series to 
keep this compatibility [2]. By the way, the only organism that I know 
is regularly checking Debian's LSB compatibility, is the Linux 
Foundation [3]. They haven't tried Jessie yet apparently.

(There _exists_ a Distribution Checker, but last I looked, it was an 
intense headache to setup.)

The crux of the issue is, I think, whether this whole game is worth the 
work: I am yet to hear about software distribution happening through LSB 
packages [4]. There are only _8_ applications by 6 companies on the LSB 
certified applications list [5], of which only one is against LSB = 4. 
Amongst the distributions, RHEL 7.0 is LSB4.1, and Oracle 6, RHEL 6.0 
and Ubuntu 9.04 are LSB 4.

As a data point, I've just noticed that the Linux Foundation issued 
LSB 5.0 and FHS 3.0 [6] just yesterday. But that doesn't change the 
arguments, I think.

I've held an LSB BoF last year at DebConf [7], and discussed src:lsb 
with various people back then, and what I took back was roughly noone 
cares. Since then, the package just floated in the limbo down my TODO 
list.

Now, given all this, I'm considering the following (and seeking advice 
and/or support):

* accepting that LSB certification is not a goal for us, and give up 
explicitely,
* therefore truncating the src:lsb package to the only things that are 
still obligatory: lsb-base  lsb-release.

Opinions? Thanks in advance, and sorry for the quite long mail!

Cheers,
OdyX


[0] Mostly _did_, when SysVinit was the de-facto standard…
[1] Which is currently broken for sid users, as I just noticed now when 
writing this email.
[2] The package descriptions contain:
  The intent of this package is to provide a best current practice way
  of installing and running LSB packages on Debian GNU/Linux. Its
  presence does not imply that Debian fully complies
  with the Linux Standard Base, and should not be construed as a
  statement that Debian is LSB-compliant.
[3] http://www.linuxbase.org/navigator/browse/distr.php?cmd=list-byidDid=476
[4] There are some OpenPrinting driver packages, but that shouldn't 
matter for all FLOSS drivers.
[5] https://www.linuxbase.org/lsb-cert/productdir.php?by_lsb
[6] http://www.linuxfoundation.org/collaborate/workgroups/lsb/lsb-50
[7] DebConf14 BoF: 
https://summit.debconf.org/debconf14/meeting/104/lsb-for-debian-bof/ and 
debconf14/bof/LSB on gobby.debian.org


signature.asc
Description: This is a digitally signed message part.

Bug#787889: general: USB keyboard stops working after a few seconds due to USB suspend

[Didier 'OdyX' Raboud]

Le vendredi, 5 juin 2015, 17.19:46 Jesse Hallett a écrit :
 Attempted to use USB keyboard in, in Xorg and in virtual TTY.
 (…)
 There appeared to be no input from the keyboard. After disconnecting
 and reconnecting the keyboard it functioned; but after a period of
 seconds it consistently stopped working until it was disconnected and
 reconnected again.
 (…)
 
 * Is there a workaround?
 
 I am able to work around the issue by overriding USB power management
 for the keyboard device:
 
 cat on | sudo tee /sys/bus/usb/devices/3-1.2.2/power/level

Do you have laptop-mode-tools installed ?

This smells very much like https://bugs.debian.org/671405 and friends.

Cheers,
OdyX


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/3583846.QuONxlSbeV@gyllingar

Re: Bits from the dpkg project: 1.17.x series, general news

[Didier 'OdyX' Raboud]

Le dimanche, 19 avril 2015, 10.25:11 Cyril Brulebois a écrit :
 Thanks so much for all the hard (and not only technical) work,
 Raphaël!

Indeed, thank you buxy!

OdyX

signature.asc
Description: This is a digitally signed message part.

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

[Didier 'OdyX' Raboud]

Le lundi, 16 février 2015, 13.38:01 Adam Borowski a écrit :
 Second, all but one (upower) of affected packages can be recompiled to
 drop the dependency.  If you bothered to read lists you're subscribed
 to, you would probably know of my set of deinfected packages at:
  deb http://angband.pl/debian nosystemd
  deb-src http://angband.pl/debian nosystemd
 which are included for example in Trios.  After such a recompilation,
 you can have a systemd-free system with no functionality loss -- in
 fact, it does solve some regressions compared to systemd-using hacks
 like -shim.

Given a common interface (such as 'nosystemd' in DEB_BUILD_OPTIONS), 
I, for one, would most probably include (whishlist-level) patches 
reducing this repetitive work to needing to set up automatic buildds 
setting the correct options.

I'm mostly happy with systemd, but unhappy when people go monkey-patch a 
lot of packages when scalable and maintainable solutions could make 
everyone's life easier. Sure, including patches for build-time toggling 
of systemd support slightly increases the maintenance, but now that we 
have VCS'es everywhere, I tend to think it's mostly a one-time work.

Cheers,
OdyX


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2118253.4PMAVtGAYT@gyllingar

Bug#773356: ITP: ippusbxd -- Daemon for IPP-over-USB printer support

[Didier 'OdyX' Raboud]

Package: wnpp
Severity: wishlist
Owner: Didier 'OdyX' Raboud o...@debian.org

  Package name: ippusbxd
  Version : 1.21.2
  Upstream Author : Daniel Dressler danieru.dress...@gmail.com
  URL : https://github.com/daniel-dressler/ippusbxd
  License : Apache-2
  Programming Lang: C
  Description : Daemon for IPP USB printer support

  ippusbxd is a userland driver for USB devices supporting the IPP USB
  specification. It enables these USB printers to be seen as regular
  network IPP printers.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141217112933.26725.87.reportbug@gyllingar

Re: Please respect Freeze Policy

[Didier 'OdyX' Raboud]

Le jeudi, 4 décembre 2014, 07.46:25 Bart Martens a écrit :
 On Wed, Dec 03, 2014 at 10:42:54AM +0100, Didier 'OdyX' Raboud wrote:
  Le mercredi, 3 décembre 2014, 10.20:32 W. Martin Borgert a écrit :
   Would it be OK to abuse experimental for new upstreams during
   freeze?
  
  during freezes, where unstable should only have changes targeted at
  testing (and therefore, currently, at jessie).
 
 I don't read that in the freeze policy. Do you?

It's indeed not mentioned there, although the following paragraph is of 
interest:

 If the version in unstable has significant changes that cannot be
 reversed or stuck behind other packages that are not acceptable,
 please contact the release team (i.e. file a bug) for doing your
 upload to testing-proposed-updates. However, please remember that
 stricter rules apply to testing-proposed-updates (see here for the
 rules.)

The November Bits from the release team [0] have a different phrasing 
too :
 Uploads to unstable
 
 Since many updates (hopefully, the vast majority) will be via
 unstable, changes there can be disruptive if they would be unsuitable
 for Jessie.
 Please be mindful of this, particularly if you maintain a library or
 key package.

My understanding of the situation is that the Release Team considers 
unstable to be the ante-chamber of testing, and that they expect it to 
only contain changes suitable for inclusion in the next stable release.

The problem with new upstream releases in unstable during the freeze is 
not these uploads /per se/, but with what they inflict on related 
packages and on testing. As others have mentioned in this thread:

* RC bugs discovered in the testing version of the package ?
  ↳ Needs to go through t-p-u
* Package is used in Build-Depends of other packages ?
  ↳ Other packages need to go through t-p-u

So, of course, the heart of the problem is the insufficient usage of t-
p-u by users, leading to /de facto/ uploads straight to testing. But 
this isn't easily solved: we already have three major suites and 
documenting all the additional partial suites in ways that make users 
_want_ to use these (and report bugs they see) isn't easy. Many of us 
developers are users of unstable: having this suite as close to testing 
as possible (especially during freezes) is _good_ for the quality of our 
stable releases.

I'd encourage the RT to push even more for an 'unstable' suite dedicated 
to the release process. Development can perfectly continue in 
experimental.

Cheers,
OdyX

[0] https://lists.debian.org/debian-devel-announce/2014/11/msg3.html

signature.asc
Description: This is a digitally signed message part.

Re: Please respect Freeze Policy

[Didier 'OdyX' Raboud]

(Moving to debian-devel, please followup there)

Le mercredi, 3 décembre 2014, 10.20:32 W. Martin Borgert a écrit :
 Would it be OK to abuse experimental for new upstreams during
 freeze? It is not the purpose of experimental to contain such
 packages, of course. But it might be a less harmful form of
 civil disobedience.
 
 (Nothing private in my part of the message.)

(Snipping others' parts, and moving to -devel)

Given the (current) small exposure of testing-proposed-updates (aka the 
repository has very few users, therefore the packages there get very few 
testing), unstable is supposed to stay the anti-chamber of testing, 
mostly at all times: whatever you upload to unstable should be aimed at 
the next stable release.

None of this changes during freezes, where unstable should only have 
changes targeted at testing (and therefore, currently, at jessie).Using 
experimental for new upstream versions is not at all an abuse; it's 
exactly the suite one should be targeting for these changes!

Cheers,
OdyX


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2460101.JeghnMkdZR@gyllingar

Re: Using USB serial device with a cdc-acm driver

[Didier 'OdyX' Raboud]

Le mardi, 2 décembre 2014, 13.02:49 Matthias Urlichs a écrit :
 Dmitriy Fitisov:
   lsof /dev/ttyACM0
  
  That I also tried last week. Nothing is open.
 
 The next target of interest would be udev.
 Which rules fire, and do they start anything?

In particular, do you have usb-modeswitch installed and running?

OdyX


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/3112008.5Q5dKWHIPJ@gyllingar

Bug#769907: general: non-sysvinit init systems are made of fail

[Didier 'OdyX' Raboud]

Le jeudi, 20 novembre 2014, 12.06:45 Sam Hartman a écrit :
  Didier == Didier 'OdyX' Raboud o...@debian.org writes:
 Didier Systems cross-craded from Ubuntu to Debian are absolutely
 Didier not supported, and I wouldn't be surprised if some of the
 Didier issues you're seeing are in some way related to this.
 
 I've seen both these issues on pure Debian systems.
 
 And I do consider both of them likely to be significant problems on
 upgrades from wheezy.
 I've been burned by both of the identified issues on multiple systems.

Fair enough, and thanks for pointing this out. I also apologize to 
Michal for having jumped too rapidly to conclusions.

Steve's suggestions stands though: separated and actionable bugs for 
these two issues filed on the corresponding packages are way more 
helpful than a general non-sysvinit init systems are made of fail.

Cheers,
OdyX


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/3920626.IYNqfL8Hhi@gyllingar

Bug#769907: general: non-sysvinit init systems are made of fail

[Didier 'OdyX' Raboud]

Le mercredi, 19 novembre 2014, 09.34:22 Michal Suchanek a écrit :
 On 19 November 2014 08:02, Didier 'OdyX' Raboud o...@debian.org 
wrote:
  Le mercredi, 19 novembre 2014, 00.00:48 Michal Suchanek a écrit :
  I had Ubuntu base system on this particular PC some years ago and I
  noticed this issue and spent a few minutes trying to figure out
  where that value is stored. I did not figure it out and since the
  upgrade to Debian base system is not supposed to handle this
  situation it is technically not a bug in Debian. It's only a
  cosmetic issue so I left it at that.
  
  Systems cross-craded from Ubuntu to Debian are absolutely not
  supported, and I wouldn't be surprised if some of the issues you're
  seeing are in some way related to this.
 
 Sure, it's always user error when something fails.

I didn't write that.

 Systems upgraded from Ubuntu are not supported

That should be obvious, yes.

 systems upgraded from Debian are not supported, nor are systems
 freshly bootstrapped and booted inside qemu. Because all these fail.

This depends on your definition of fail (which was quite vague in this 
general bug-report). These two use-cases don't fail for me here.

OdyX


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5076940.tJqDfecBa5@gyllingar

Bug#769907: general: non-sysvinit init systems are made of fail

[Didier 'OdyX' Raboud]

Le mercredi, 19 novembre 2014, 00.00:48 Michal Suchanek a écrit :
 On 18 November 2014 18:57, Jordi Mallach jo...@debian.org wrote:
  El dl 17 de 11 de 2014 a les 15:41 +0100, en/na Michal Suchanek va
  escriure:
  -- System Information:
  Distributor ID:   Ubuntu
  Description:  Ubuntu GNU/Linux testing (jessie)
 
 It's a cosmetic issue ;-).
 
 I had Ubuntu base system on this particular PC some years ago and I
 noticed this issue and spent a few minutes trying to figure out where
 that value is stored. I did not figure it out and since the upgrade to
 Debian base system is not supposed to handle this situation it is
 technically not a bug in Debian. It's only a cosmetic issue so I left
 it at that.

Systems cross-craded from Ubuntu to Debian are absolutely not supported, 
and I wouldn't be surprised if some of the issues you're seeing are in 
some way related to this.

OdyX


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/30809294.EYYie8BeKM@gyllingar

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

[Didier 'OdyX' Raboud]

Le mardi, 14 octobre 2014, 01.13:48 Wookey a écrit :
 I'm just pointing out that interested people, who are moderately
 well-involved, really did miss that a GR was attempted.

For the record, I don't disagree; I'm just saying that the GR call was 
on the right list and that I think that the project's documented 
expectation is that those interested in GR calls should have been 
following -vote, as documented on our website:

https://lists.debian.org/2644371.u0TgOhpbrd@gyllingar

Cheers,
OdyX


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/3544854.5pQuf1ujCs@gyllingar

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

[Didier 'OdyX' Raboud]

I really don't buy the argument that the GR proposal was too quiet to 
be noticed by 6+ people. I mean: the proposition happened to be in the 
middle of the post-TC decision wave, on the mailing lists where it 
belonged. The people who cared about the whole default init for Debian 
question _were_ following and contributing to these various lists. I'm 
therefore claiming that the people who missed the GR proposal were not 
sufficiently interested (otherwise they would've been subscribed to 
either -vote or -project, where these proposals belong). I'm also 
thankful that the proposer limited his proposal to these lists (I'd have 
considered a spread of the call over -devel, -user or other lists an 
abuse).

Le lundi, 13 octobre 2014, 16.15:02 Ian Jackson a écrit :
 If four other DDs send me and Matthew Vernon private email to say that
 they would support a GR on this subject, I will restart this
 conversation on -project.

Doing this now despite the fact that the GR didn't reach its 6 seconds, 
7 months ago, will lead to an incredibly bigger waste of time, just when 
we're about to freeze testing.

The GR train passed…

Cheers,
OdyX


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/17667995.ybzVghadep@gyllingar

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

[Didier 'OdyX' Raboud]

Le lundi, 13 octobre 2014, 12.23:00 Miles Fidelman a écrit :
 Didier 'OdyX' Raboud wrote:
  I really don't buy the argument that the GR proposal was too quiet
  to be noticed by 6+ people.
 
 Actually - I'd contest that, for four reasons:
 
 - as I've previously noted - the major impacts of systemd are being
 (going to be) felt by sysadmins and upstream developers - who don't
 necessarily follow debian-devel all that closely -- or have input

Mind you, most if not all of the CTTE are both sysadmins and upstream 
developers, and I'd go as far as saying that most of DDs are either too.

 - the actual GR call for vote was buried on debian-vote - immediately
 jumped on regarding wording and procedural discussions

Yes, and? There was a proposal on -vote, which could have been followed 
by seconds, totally ignoring the side-discussions. Don't expect 
launching a GR about a) overriding a Debian body; b) the default init 
system to be a quiet ride.

 - actual discussion of the GR on -devel was completely swamped by all
 the other discussion of systemd

My feeling is that the swamping happened because some people disagreeing 
with the CTTE vote vented a lot of frustration through whining and 
complaining instead of focusing their energy to formulate a concrete 
proposal for a GR.

We're talking about finding _6_ seconds, so I'd only buy this argument 
if the threshold was 50 (or so) and we'd have only found a dozen 
seconds.

OdyX


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2605439.lZGhNDzrLW@gyllingar

Re: Trimming priority:standard

[Didier 'OdyX' Raboud]

Le mardi, 16 septembre 2014, 23.17:51 Joerg Jaspert a écrit :
 On 13698 March 1977, Didier Raboud wrote:
   One thought... there will probably be trademark concerns with
   unix.[1] So we might have to choose a name for the tasksel task
   to be someting like unix-like.
  
  Or we could just call it standard system.
  
  Could we make sure the full vim is in that then? I miss it on
  every
  new installation and I'm quite sure that's not uncommon.
 
 ONLY if we put emacs there too (…)

Apparently I just need to learn to use the 'nocompatible' option for 
vim, sorry for the noise.

OdyX



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/3592821.OyjbmjOk0H@gyllingar

Re: Trimming priority:standard

[Didier 'OdyX' Raboud]

Le vendredi, 12 septembre 2014, 13.55:53 Joey Hess a écrit :
 Theodore Ts'o wrote:
  One thought... there will probably be trademark concerns with
  unix.[1] So we might have to choose a name for the tasksel task
  to be someting like unix-like.
 
 Or we could just call it standard system.

Could we make sure the full vim is in that then? I miss it on every 
new installation and I'm quite sure that's not uncommon.

Cheers,
OdyX


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/3087012.x4OgC7KCFP@gyllingar

Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Didier 'OdyX' Raboud]

Le jeudi, 31 juillet 2014, 22.19:28 Pau Garcia i Quiles a écrit :
 How is it better to have libav, which does a lot less security
 bugfixing, in?

Our security team has to prepare the libav updates over the lifetime of 
wheezy anyway. Introducing ffmpeg in jessie (with or without dropping 
libav) means (at least) duplicating that work.

OdyX


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5354151.iF7zqzrZRY@gyllingar

Re: sysvinit is still here, and here to stay for jessie (was Re: systemd is here to stay, get over it now)

[Didier 'OdyX' Raboud]

That will be my last contribution to this pointless discussion.

Le jeudi, 3 juillet 2014, 16.59:25 Thorsten Glaser a écrit :
  or without systemd btw). Given that the technical committee has made
  a decision which stayed unchallenged (so far), I've now come to
  think that
 No, there just has not been any challenge that met the form and
 other requirements… and I am at a bit of loss at what to do here.
 
 Besides, it’s not that the TC made a decision. Rather, the TC was
 split, and the chairman threw in his weight.

Sorry, but this is plain wrong (and you know it); the TC followed its 
decision-making process (outlined in the project's constitution [0,1]) 
which led to what is now a TC decision. The detail of the votes doesn't 
change the outcome. Quoting [2]:
 The committee decided that the default init system for Linux 
 architectures in jessie should be systemd.

There are no possible weak or strong decisions; the outcome of a TC 
or GR decision is either resolution accepted or further discussion. 
Giving importance to the winning majority is your choice but doesn't 
change the decision itself.

 This is absolutely not what I’d call a project(!) decision.

I was careful enough to not say it was a project decision, mind you. 
That said, our technical decision body took a decision that stayed 
unchallenged (so far); this fact makes it a /de facto/ project decision.

  Can we get over this now and start making Jessie the most awesome
  stable release we've ever prepared together?
 
 To do that, it MUST work without systemd, if alone for upgrade
 scenarios.

That's wrong: as far as the default init is concerned, it only MUST work 
without systemd-as-init until the first post-dist-upgrade reboot. I 
don't think any work outside of that scope should be imposed on the 
package maintainers [3].

 And alone the fact that the systemd issue *continuously* pops up
 shows you that it is nowhere even near solved.

I don't think that's true. From my (most-certainly) biased point of 
view, the issue continues to pop up because some very vocal systemd 
opponents keep vocally insisting that other fellow project volunteers 
ensure that their pet use-cases keep working with a non-default init 
system (or even without a specific non-init package). As far as I am 
concerned, I'm putting my energy to make sure my packages (and my setup) 
work as good as possible with the _default_ init that was picked for 
jessie. The rest is best-effort.

 Furthermore, the TC(-chairman) decision only was on the default
 init system for the Linux ports of jessie.

Please stop spreading the FUD that the default init decision was a TC-
chairman decision. This is plain wrong, as our constitution outlines.

 This means that
 • installing jessie with other init systems
 • switching between init systems
 • default init system for kFreeBSD ports
 • default init system for Hurd port
 • which non-default init systems are there?
 are still on the table.

Sure. They are on the we want Debian Jessie to work with other inits 
than the default persons' table, they have no reason to be on 
everyone's. As mentioned above: if you want this to work, make sure it 
does, propose patches, test scenarios, etc. Pushing for a package 
conflicting with systemd is not helping any of this.

 (Due to Debian’s requirements for sane upgrades, running a jessie
 system that was upgraded from an older release with sysvinit MUST be
 fully supported, anyway.)

Wrong, see above.

 I’m a bit torn between throwing it all (which is a bad idea ofc),
 writing a GR myself (which is also a bad idea due to my lack of
 language skills), packaging BSD init for my own repo, joining the
 (currently unheard) runit-as-init crowd…

Frankly, if voting on a default init GR would ensure we'd finally stop 
these bikeshed discussions (after few other weeks of mudslinging), by 
all means, go for it. That said, as far as I remember, the latest GR 
proposal [4] on this subject failed to gather the mandatory K seconds 
though. For me, this indicates that not even K=5 DDs were interested in 
having that discussion. We currently need half a percent of DDs to 
trigger a GR and it has not happened; could we get over this now?

OdyX

[0] https://www.debian.org/devel/constitution
[1] Which you agreed to.
[2] https://www.debian.org/devel/tech-ctte
[3] It doesn't mean they should not accept patches for adaptations for
other init systems though.
[4] https://lists.debian.org/debian-vote/2014/03/msg0.html


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1627463.lsrZH6mOqL@gyllingar

systemd is here to stay, get over it now (was: Re: Pinning vs. conflicting)

[Didier 'OdyX' Raboud]

Folks,

Le jeudi, 3 juillet 2014, 14.20:24 Juliusz Chroboczek a écrit :
 Isn't the proper solution to add blacklisting support to dpkg, then?

The proper solution is to stop trying to hide ourselves from to the fact 
that some sort of systemd interfaces have been made unavoidable in 
modern desktop environments (fact which is rightfully reflected in our 
dependencies tree). Many of the interfaces of systemd are here to stay 
and will make their way through our stack (like it or not); fact is they 
already made it quite far in at least Gnome and KDE.

As developers of Debian (which this list is about afterall), our proper 
solution is not to forbid systemd on our various systems while hoping 
that not too many things will end up depending on its interfaces and 
that our working setup for so long that I can't even remember will 
magically keep working while the underlying stack keeps evolving (with 
or without systemd btw). Given that the technical committee has made a 
decision which stayed unchallenged (so far), I've now come to think that 
this behavior (and its flaming counterpart) is actively hurting the 
project.

The proper solution is to fix (or help fix) all use-cases that became 
broken with the arrival of systemd and/or make sure that the 
dependencies tree allows the systemd shim to be installed and working, 
as well as making sure this shim stays relevant and a working and 
transparent replacement to systemd itself.

We are collectively developing an operating system, not only assembling 
a set of packages for our own benefit. Our priority is our users and 
they rightfully expect a rocking Jessie release, which will happen with 
systemd as default init system. Will we make this happen or will we just 
end up having gone through an endless bikeshedding discussion about a 
package that forbids the installation of the default init system!?

Can we get over this now and start making Jessie the most awesome stable 
release we've ever prepared together?

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: MATE 1.8 has now fully arrived in Debian

[Didier 'OdyX' Raboud]

Le vendredi, 27 juin 2014, 23.02:51 Thomas Goirand a écrit :
 On 06/27/2014 06:31 PM, Michael Englehorn wrote:
  Wouldn't glibc then fall into the list of things you don't like as a
  required framework? By that logic, all libraries must be
  hot-swappable with no additional effort by the end-user. That's
  just not realistic.
  
  -Michael
 
 Are you aware that we're switching away from eglibc? Just saying...

Are you aware that we never had both glibc and eglibc simultaneously 
available in a suite? Just saying…

OdyX


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2568562.DDxbkL30vz@gyllingar

Re: systemd-fsck?

[Didier 'OdyX' Raboud]

Le mardi, 13 mai 2014, 17.21:45 Thorsten Glaser a écrit :
 Didier 'OdyX' Raboud dixit:
 Le mardi, 13 mai 2014, 16.25:31 Thorsten Glaser a écrit :
  On Mon, 12 May 2014, Tollef Fog Heen wrote:
   Are you aware that Joss isn't a systemd maintainer?  (He's one of
   the GNOME maintainers.)
  
  There’s not really a line between them, you know. (But it was
 
 On top of your first sentence being factually wrong (check the
 maintainer fields of the respective packages), I really think your
 
 I *know* that the people listed as maintainers of the respective
 Debian packages, (…)

Please don't quote private mails in public. Also, don't evade the 
criticism on on your unacceptable words and retract your statement.

TIA, OdyX


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2755547.vUKYPZ7X3A@gyllingar

Re: Bug #702005: Where can i get more attention on this?

[Didier 'OdyX' Raboud]

Le jeudi, 8 mai 2014, 13.05:52 Ian Jackson a écrit :
 Unfortunately, Luis's mail domain is hosted at Hotmail which hates
 chiark:

Pot calling the kettle black: chiark hates a lot of servers out there 
when it's Irritated…

OdyX


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1915138.zsAfhk3TAZ@gyllingar

Re: gnutls28 transition

[Didier 'OdyX' Raboud]

Le dimanche, 4 mai 2014, 02.14:17 peter green a écrit :
 Personally I'd add a (build-)depends on the relicensed gmp in the next
 gnutls28 upload. That way packages can (build-)depend on the new
 gnutls and be assured of getting a GPLv2 compatible version.

For cups, as it doesn't build-depend on libgmp directly, I added the 
inverse relationship:

# libgmp-dev is not GPL-2 compatible before it's 6 release, which makes
# it also GPL-2+
Build-Conflicts: libgmp-dev ( 2:6)

Dimitri John Ledkov wrote:
 Should we start transition to gnutls28 by default, for all packages
 that are compatible?

Yes, please.

Cheers,
OdyX


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2156746.eBzsy0u8Yc@gyllingar

Bluez5 and KDE (was: Re: Bits from the systemd + GNOME sprint)

[Didier 'OdyX' Raboud]

Hi Jordi, and thanks for this interesting report!

One point I'd like to see discussed is the Bluez5 transition:

Le vendredi, 2 mai 2014, 01.26:15 Jordi Mallach a écrit :
 We finally discussed how to tackle Bluez5. Bluez 4 is the current
 release available in Debian, which is dead upstream and deprecated
 since late 2012.  GNOME 3.12 only supports Bluez 5, while the rest of
 Bluez users in Debian (including KDE, Xfce and other environments)
 haven't been ported yet to Bluez 5.

For what is worth, the KDE Bluetooth stack (Bluedevil) has a new 
upstream version that supports Bluez5: 2.0~rc1. It's mostly an upload 
away and I might help the Qt-KDE Team out by just doing it soon… It 
works fine here at least.

 Both releases are not parallel
 installable, so we concluded that a potential solution could be to
 upload Bluez 5 as “bluez5”, and let it conflict with ”bluez”
 [BLUEZ5BTS]. Desktops would then recommend their supported release
 instead of depending on it, which would allow for parallel
 installation of different desktop environments, while respecting the
 bluez conflict.

Given that Bluez4 is already deprecated for a year (and will be for two 
at freeze time), I'd rather be leaning towards moving to Bluez5 as soon 
as possible to force the various environments to migrate (but I'm not 
a Bluez maintainer)…

Cheers,

OdyX

signature.asc
Description: This is a digitally signed message part.

Re: Bits from the Security Team

[Didier 'OdyX' Raboud]

Hi,

Le lundi, 17 mars 2014, 10.33:32 Holger Levsen a écrit :
 I think you've missed one significant benefit here: (I believe) for
 quite many people by now it's a showstoper to join a team which is
 using subversion for it's workflow.

git-svn usage is a manpage away: once you've learned `git svn rebase` 
and `git svn dcommit`, you're basically with pure git.

 I would certainly *not* join the security team while you're using
 subversion. (And I doubt I'm alone here.)

That's quite ironic from a DebConf chair's mouth. :-P

Cheers,
OdyX


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/7470528.AlHlBr3Krs@gyllingar

Re: jquery debate with upstream

[Didier 'OdyX' Raboud]

Le mardi, 11 mars 2014, 19.02:55 Ian Jackson a écrit :
 Thomas Goirand writes (Re: jquery debate with upstream):
  In one of my package, I had openssl.dll in the source tarball (it
  was of course removed later on).
  
  Would you consider it ok as well to have it in a source package, as
  long as it's not used during the build? And what about a windows
  .exe? Is it different from having a minified .js that is also not
  in use?
 Yes, I think all of these things are tolerable, so long as the files
 are in fact redistributable (which depending on the licence they might
 not be).

I disagree: I don't think it's tolerable to ship a .exe freeware [0] in 
a source package in main, just because it happens to be redistributable; 
in my reading, considering that the source package _is_ a component of 
the Debian system, doing so violates at least SC§1 and DFSG§2. I don't 
think there should be a standards' difference between our source and 
binary packages.

That said, the minified .js case is slightly different iff it can be 
proved that it can be recreated from DFSG-free sources, which should 
then really be actually done in the build phase.

Now, if the problem is that stripping out non-free stuff from upstream 
archives is boring work, then that's the thing to solve using smart 
tools rather than bending our standards.

Cheers,
OdyX

[0] And that's without speaking of actively harmful executables…

signature.asc
Description: This is a digitally signed message part.

Re: jquery debate with upstream

[Didier 'OdyX' Raboud]

Le mercredi, 12 mars 2014, 12.58:51 Ian Jackson a écrit :
 Didier 'OdyX' Raboud writes (Re: jquery debate with upstream):
  I disagree: I don't think it's tolerable to ship a .exe freeware [0]
  in a source package in main, just because it happens to be
  redistributable; in my reading, considering that the source
  package _is_ a component of the Debian system, doing so violates
  at least SC§1 and DFSG§2. I don't think there should be a
  standards' difference between our source and binary packages.
 
 I have a completely different approach to the DFSG.  The DFSG is not
 carefully drafted document and it doesn't stand up to detailed
 legalistic interpretation.  Rather, it is a statement of aims and
 values.

My intent was not to draw a legalistic line, I was merely explaining 
what my (current) interpretation of these aims and values are with 
regards to shipping non-free binaries in source packages in main.

 That purpose is to improve the freedom of software users (and to an
 extent developers) by providing an operating system which they can
 (individually and collectively) examine, modify and share.
 
 If an interpretation of the DFSG suggests that we should be doing work
 which does not further those objectives, then I think that
 interpretation is a misreading.

SC§1 states that we want Debian to remain 100% free; the common 
interpretation of that is that one can download anything from Debian 
main and only get DFSG-free material; I think our sources are held to 
the same expectation. In fact, we _are_ shipping source and binary 
packages in the exact same way through our mirrors network.

Now, granted, making Debian 100% free is not improving the freedom of 
software users if they don't use these non-free parts (and having them 
in the source packages only is certainly a blocker), but I strongly feel 
that weakening our promise to only address binary packages for the sake 
of practicability is certainly not worth the practical benefit.

 No-one has come up with any practical benefit from the repacking of
 source tarballs to remove nonfree files.

There's no practical benefit, granted, but doing so is a service to our 
users and a continued statement that we hold ourselves to high standards 
with regards to software freedom.

 The requirement to be sure that these nonfree files aren't unwittingly
 relied on by our build processes could be easily achieved by removing
 them in clean targets, filtering in dpkg-source, or whatever.

I think that, given proper tools, the explicit work of making sure that 
some non-free files are not used in the build process is equivalent to 
making sure they are not present in the source package.

 If we are worried that users might be misled about the status of these
 files, filtering them out in dpkg-source would suffice.

That would protect sources.debian.net from publishing these indeed. I 
still disagree it's sufficient though.

 The result would be that the only people who saw them would be people
 who are using our archive as a convenient location to fetch the
 upstream tarball.  I would argue that everyone's freedom is served,
 rather than hindered, by having those people come to us for that (as
 it is in a similar way for the nonfree archive sections).

… besides main is not the non-free archive section.

At the risk of repeating myself: I value our promise that Debian will 
remain 100% free and I want that promise to include our source archives 
because access to sourcecode is what free software is all about. I'd be 
saddened by a decision to exempt the source archives from that freeness 
requirement.

Cheers,
OdyX

P.S. There's no need to CC me, as I can't CC you in return and am 
subscribed to the list…

signature.asc
Description: This is a digitally signed message part.

Re: Bits from the Security Team

[Didier 'OdyX' Raboud]

Le lundi, 10 mars 2014, 22.00:09 Christoph Biedl a écrit :
  The problem is that there is no policy in place to make us support
  oldstable-to-testing upgrades. If there's interest, that'd need to
  be decided with a more firm policy than encourage maintainers.
 
 Would you have preferred to read something putting the burden onto
 the maintainers?

Re-reading my statement again after hitting the send button made me 
admit that I didn't express what I intended to…

I was trying to say that there is no policy currently in place to ensure 
that skip-upgrades actually work, and at least one maintainer has 
already started to cleanup pre-wheezy stuff from his packages [0]. 
People encouraging maintainers not to gratuitously break skip-upgrades 
on debian-devel is by far not equivalent to a Release Team decision on 
bug severity for a failure to skip-upgrade for example.

Cheers,
OdyX

[0] I'd be surprised to be the only one, who knows.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/7312246.zXeI0qdFfj@gyllingar

Re: Bits from the Security Team

[Didier 'OdyX' Raboud]

Le lundi, 10 mars 2014, 13.52:59 Ian Jackson a écrit :
 Paul Wise writes (Re: Bits from the Security Team):
  Debian doesn't support skipping releases right now and I expect if
  we
  support releases for a longer amount of time that won't change.
 
 But, in practice, skip upgrades often work anyway.  I'd encourage
 maintainers not to gratuitously break them.  For example, aggressively
 removing compatibility code is a bad idea.  (It's bad for our
 downstreams too).

I, for one, have been routinely dropping transitional binary packages 
that were in the latest stable; they were needed to migrate from (the 
releases which are now) oldstable to stable but are only archive noise 
now. Delaying that cleanup for an additional stable release cycle really 
feels like unnecessary delay, during which we pretend to maintain code 
that hardly anyone tests.

The problem is that there is no policy in place to make us support 
oldstable-to-testing upgrades. If there's interest, that'd need to be 
decided with a more firm policy than encourage maintainers.

Cheers,
OdyX


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/69734414.qmXaMjuj1O@gyllingar

Re: Bits from keyring-maint: Pushing keyring updates. Let us bury your old 1024D key!

[Didier 'OdyX' Raboud]

Le mercredi, 5 mars 2014, 10.47:07 Paul Wise a écrit :
 On Wed, Mar 5, 2014 at 1:55 AM, Xavier Roche wrote:
  I have a rather silly question: would a mail (signed with this key)
  request to the DDs who already signed the initial key (and checked
  the identity) to sign the replacement key considered unreasonable ?
 Considering that the initial keys are now considered weak, I expect
 that it would be reasonable for people to not trust a key transition
 statement where the only available trust anchor is the old weak key.

Well, the project currently considers these old keys to be trustworthy 
enough to let the people who control them to upload any packages on the 
archive (modulo these keys are in the uploading keyring).

If we trust that the people behind the keys haven't changed, we should 
let them use easy ways to stronger keys. On the other hand, if we think 
the keys have been compromised, then we should really drop the upload 
rights!

Cheers,
OdyX


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1698122.Pbb9aiM70E@gyllingar

Re: default init on non-Linux platforms

[Didier 'OdyX' Raboud]

Le jeudi, 20 février 2014, 22.28:56 Thomas Goirand a écrit :
 On 02/20/2014 09:02 PM, Tom H wrote:
  What features does sysvinit+openrc have that
  sysvinit+sysv-rc+insserv doesn't have?
 
 Just to name a few:
 - getting rid of the ugly LSB headers

They might be ugly, but they encode the dependency tree; by what are 
they replaced in OpenRC?

 - cgroup supports to kill processes

On non-Linux ports ?

--
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: default init on non-Linux platforms

[Didier 'OdyX' Raboud]

Le mardi, 18 février 2014, 22.55:32 Thomas Goirand a écrit :
 Once I consider OpenRC ready for it, would it be ok to just replace
 sysv-rc by OpenRC, and transform sysv-rc into a transitional package?
 What is the opinion of other DDs? Is there anyone which would like to
 keep the old featureless sysv-rc?

I think we should focus on one init system change at a time.

Having the good-old sysvinit setup still working in a satisfactory 
manner is nice while preparing Jessie: that's what Wheezy has and 
therefore has to be supported to upgrade to Jessie (think partial 
upgrades, full-upgrade-not-rebooted-yet, etc etc). When testing crazy 
stuff with systemd, I know I can always fallback to sysvinit if I broke 
any .socket or .service unit I'm working on. It will be slower and feel 
old, but would most certainly boot and provide me with comfortable ways 
to debug. If that was changed to OpenRC, we'd exchange the sysvinit 
safety net that all got to know in exchange for a brand new safety net 
that we don't really know yet.

Moving to OpenRC as the secondary init for Jessie looks like changing 
the two wheels of a bike at the same time. I'd widely prefer to keep 
sysvinit (as old it might feel) for Jessie, especially as transition 
point from Wheezy and have these discussions again after Jessie is 
released.

That shouldn't stop you from providing the best OpenRC integration in 
Debian, be it for the ports or in preparation for jessie+1.

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: default init on non-Linux platforms

[Didier 'OdyX' Raboud]

Le mercredi, 19 février 2014, 01.11:21 Thomas Goirand a écrit :
 Actually, thinking about it a 2nd time, I think there would be a major
 drawback in delaying to Jessie +1. If we decide that sysv-rc goes
 away, then starting at the Jessie release, we don't have to care
 anymore about LSB header scripts. Meaning that we could write systemd
 service files, plus OpenRC runscripts (for those who cares about
 OpenRC, or our non-linux ports).
 
 If we delay it, this means that we'd have to keep maintaining LSB
 header scripts in Sid for all the life of Jessie (for those who cares
 about non-linux ports or having OpenRC / sysv-rc support).

I don't think that's true. If we decide that sysvinit scripts (hence LSB 
headers) have to be supported in jessie but are deprecated, then 
jessie+1 can start to drop them completely (given reasonable replacement 
for non-init defaults of course). Dropping them in the jessie suite 
would complicate the upgrade path from Wheezy for no reason that I would 
value high enough.

OdyX


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4440019.su1Rqjt91a@gyllingar