Re: Help with the nftables package: the embedded python module

[Arturo Borrero Gonzalez]

On Sun, Jul 30, 2023, 21:39 Jeremy Sowden  wrote:

> On 2023-07-28, at 18:59:45 +0200, Timo Röhling wrote:
> > * Arturo Borrero Gonzalez  [2023-07-28 18:38]:
> > > I would appreciate additional suggestions and hints. Patches welcome.
> >
> > If you have bad interactions between the Python and non-Python parts
> > of your package, you can try and build them independently, i.e.,
> >
> > override_dh_auto_build:
> > dh_auto_build --package=python3-nftables --sourcedirectory=py
> --buildsystem=pybuild
> >   dh_auto_build --remaining-packages
> >
> > and similar for the other dh_auto_* commands. I did something like
> > that for tinyobjloader and it worked quite nicely.
>
> Thanks for the pointer, Timo.  This does seem to do the trick.
>
> Arturo, I'll push the changes to Salsa.
>
> J.
>

Thanks, Timo and Jeremy.

>

Re: Help with the nftables package: the embedded python module

[Jeremy Sowden]

On 2023-07-28, at 18:59:45 +0200, Timo Röhling wrote:
> * Arturo Borrero Gonzalez  [2023-07-28 18:38]:
> > I would appreciate additional suggestions and hints. Patches welcome.
>
> If you have bad interactions between the Python and non-Python parts
> of your package, you can try and build them independently, i.e.,
> 
> override_dh_auto_build:
> dh_auto_build --package=python3-nftables --sourcedirectory=py 
> --buildsystem=pybuild
>   dh_auto_build --remaining-packages
> 
> and similar for the other dh_auto_* commands. I did something like
> that for tinyobjloader and it worked quite nicely.

Thanks for the pointer, Timo.  This does seem to do the trick.

Arturo, I'll push the changes to Salsa.

J.


signature.asc
Description: PGP signature

Re: Help with the nftables package: the embedded python module

[Timo Röhling]

Hi,

* Arturo Borrero Gonzalez  [2023-07-28 18:38]:

I would appreciate additional suggestions and hints. Patches welcome.

If you have bad interactions between the Python and non-Python parts
of your package, you can try and build them independently, i.e.,

override_dh_auto_build:
dh_auto_build --package=python3-nftables --sourcedirectory=py 
--buildsystem=pybuild
dh_auto_build --remaining-packages

and similar for the other dh_auto_* commands. I did something like
that for tinyobjloader and it worked quite nicely.


Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Re: Help with a libzstd sparc64 FTBFS on the buildd

[Peter Pentchev]

On Thu, Apr 06, 2023 at 05:01:07PM +0200, Paul Gevers wrote:
> Hi Peter,
> 
> On 06-04-2023 15:37, Peter Pentchev wrote:
> > I feel like I cannot ask for an unblock from the release
> > managers since the sparc64 buildd started failing on this package
> > at some point in February:
> 
> sparc64 is not a release architecture. sparc64 will not be better or worse
> if something migrates. I suggest to consider those problem separately.

TBH, that was my own understanding, and I was about to send an unblock
request earlier today, but then I decided to take another look at
the freeze policy and the phrase "migration for packages only allowed if
all their binary packages have been built on buildds" threw me a bit.
But yeah, I should have realized that should only apply to release
architectures... thanks for correcting my thinking!

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Re: Help with a libzstd sparc64 FTBFS on the buildd

[Paul Gevers]

Hi Peter,

On 06-04-2023 15:37, Peter Pentchev wrote:

I feel like I cannot ask for an unblock from the release
managers since the sparc64 buildd started failing on this package
at some point in February:


sparc64 is not a release architecture. sparc64 will not be better or 
worse if something migrates. I suggest to consider those problem separately.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Re: Help with a libzstd sparc64 FTBFS on the buildd

[Peter Pentchev]

On Thu, Apr 06, 2023 at 04:37:16PM +0300, Peter Pentchev wrote:
> Hi,
> 
> The libzstd package in testing is currently missing a couple of
> build-time tests and a fix for a very rare data corruption bug.
> Both of these have been fixed in libstd-1.5.4+dfsg2-5 in unstable;

...of course this should have been libzstd-1.5.4+dfsg2-5

> however, I feel like I cannot ask for an unblock from the release
> managers since the sparc64 buildd started failing on this package
> at some point in February:
> 
>   https://buildd.debian.org/status/logs.php?pkg=libzstd=sparc64
> 
> Now, the -1, -2, and -4 failures I can explain: there were some
> problems in the upstream test suite that were fixed in -3 and -5.
> However, -3 and -5 should really not have failed: they built
> successfully on all other architectures where the build dependencies
> were installable, and they also passed autopkgtest runs:
> 
>   https://ci.debian.net/packages/libz/libzstd/
> 
> I set up a qemu-based sbuild environment on my laptop, and
> I built the libzstd package successfully. Is it possible that
> something is wrong with the sparc64 buildd? Could somebody with
> an actual sparc64 box try to build libstd-1.5.4+dfsg2-5 and
> let me know if it works for them?

...and of course this should also have been libzstd-1.5.4+dfsg2-5

> Thanks in advance!

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Re: Help patching files in dependency package

[Dominic Hargreaves]

On Tue, Jan 17, 2023 at 08:52:50AM +0800, Paul Wise wrote:
> On Tue, 2023-01-17 at 00:55 +0100, Tobias Wackenhut wrote:
> 
> > What would be the cleanest way to package the new version with the 
> > mentioned patch?
> 
> Ask the extension author to get the patch included into the upstream
> rt5 core, get a release of that, then get request-tracker-5 updated.
> 
> Alternatively, drop the patch from the extension upstream and work
> around the issue within the extension upstream codebase instead.
> 
> If neither of these are viable, discuss with the request-tracker-5
> maintainers in Debian about including the patch in that package.

Hi, (somewhat dormant) RT maintainer here.

Thanks Paul, that's spot on. We have in the distant past applied
those sort of patches before they hit RT upstream, but it's definitely
not ideal, and it really depends on the patch. 

However, Tobias, I don't see any patch that needs to be applied in

- Debian already has RT 5.0.3 (>= 5.0.2)?

Let's continue the discussion on
pkg-request-tracker-maintain...@alioth-lists.debian.net (CCed).

Cheers
Dominic

Re: Help patching files in dependency package

[Paul Wise]

On Tue, 2023-01-17 at 00:55 +0100, Tobias Wackenhut wrote:

> What would be the cleanest way to package the new version with the 
> mentioned patch?

Ask the extension author to get the patch included into the upstream
rt5 core, get a release of that, then get request-tracker-5 updated.

Alternatively, drop the patch from the extension upstream and work
around the issue within the extension upstream codebase instead.

If neither of these are viable, discuss with the request-tracker-5
maintainers in Debian about including the patch in that package.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Re: Help setting dbconfig-common for MariaDB, not MySQL

[Marc Haber]

On Mon, 2 Jan 2023 17:08:25 +0100, Paul Gevers 
wrote:
>Hi Marc,
>
>On 02-01-2023 16:58, Marc Haber wrote:
>> On Mon, 2 Jan 2023 16:31:17 +0100, Paul Gevers 
>> wrote:
>>> On 02-01-2023 14:21, Alessandro Vesely wrote:
 A user complained that MySQL doesn't work, because it misses the INET6
 type that the example settings use.
>>>
>>> And is this an absolute must? (It's an example after all?)
>> 
>> It is. We need to stop having "disable IPv6" as measure 1 if something
>> doesn't work right. It's the default IP protocol for a decade.
>
>Are you saying that MySQL doesn't support IPv6? Or just that the "INET6 
>type" in the context of MariaDB is a MariaDB specific implementation of 
>something? (Sorry, I didn't investigate and assumed the latter).

I didn't investigate and assumed some kind of the former.

Anyway, since we have a diversion between MySQL and MariaDB here that
causes dbconfig-common to trip over an IPv6 issue, I see the usual
solution coming over the horizon and wanted to object against that
one.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Help setting dbconfig-common for MariaDB, not MySQL

[Alessandro Vesely]

On Mon 02/Jan/2023 16:31:17 +0100 Paul Gevers wrote:

Hi Alessandro,



Hi, thanks for replying.



On 02-01-2023 14:21, Alessandro Vesely wrote:
please pardon my ignorance about Debian install.  I'm distributing a software 
which could use various DBMS'es by setting a number of parameters.  Example 
parameters are only given for MariaDB.  I distribute a debian/ directory that 
Debian users can use to prepare a package instead of configure, make, make 
install.  However, the debian/postinst supports MariaDB only.


Do I understand you correctly that you don't want to support MySQL?



Yes, it'd be too much work to create, test, and debug the settings for an 
alternative DBMS.



A user complained that MySQL doesn't work, because it misses the INET6 type 
that the example settings use.


And is this an absolute must? (It's an example after all?)



Well the reference example started using INET6 a few years ago, to store both 
IPv4 and IPv6 addresses.  It simplified settings somewhat.  Reverting to the 
previous state is too bad.


A user needing to work with MySQL can replace INET6 with a suitable BLOB, and 
change all the related queries and configs accordingly.  The existing 
debian/postinst won't work in that case.  It could be easily adapted, IF the 
relevant queries and configs were given...



Now I've added "mariadb-client | mariadb-server | dbconfig-no-thanks" to the 
Debian clause in debian/control.


I think that's wrong. At least it would fail to install dbconfig-common in case 
there is a mariadb-client installed. Also, I wonder about the mariadb-server 
part. mariadb-server depends on the versioned mariadb-server-* package which 
depends on the versioned mariadb-client-* package. So in case mariadb-client 
wouldn't be able to be fulfilled, mariadb-server as the second alternative 
isn't going to help. And in my opinion you should not depend on the server 
part. As with most databases, the server part can live on a different host and 
package should really not force the server to be on the same host.



Would "mariadb-client | dbconfig-no-thanks" work?  But see below.


I'm not clear how I could add an (optional) Conflicts mysql-something, also 
because I see no mysql-server in the package cache.


mysql-server is available in unstable, but we don't want to support both MySQL 
and MariaDB in Debian stable at the same time, so currently MySQL is blocked 
from migration. However, derivatives choose differently (Ubuntu supports MySQL 
in their releases).



Indeed, the user who complained was on Ubuntu 22.04 and MySQL version 8.0.23. 
He asked me to add MariaDB to the list of requirements.  Perhaps he can install 
requirements according to what I write in debian/control Depend.  If I only 
require mariadb-client and then the server is MySQL, it won't run.



Is there a way to fail if a user chooses to install the DB but MariaDB is 
missing?  Or is the above enough?


I don't think you can do it with dependencies. If you really want to go this 
route, you have to detect it during run time.



Yeah, not very nice, but still better to discover it at runtime.  The database 
creation with INET6 types will fail on Ubuntu.



Than

Re: Help setting dbconfig-common for MariaDB, not MySQL

[Paul Gevers]

Hi Marc,

On 02-01-2023 16:58, Marc Haber wrote:

On Mon, 2 Jan 2023 16:31:17 +0100, Paul Gevers 
wrote:

On 02-01-2023 14:21, Alessandro Vesely wrote:

A user complained that MySQL doesn't work, because it misses the INET6
type that the example settings use.


And is this an absolute must? (It's an example after all?)


It is. We need to stop having "disable IPv6" as measure 1 if something
doesn't work right. It's the default IP protocol for a decade.


Are you saying that MySQL doesn't support IPv6? Or just that the "INET6 
type" in the context of MariaDB is a MariaDB specific implementation of 
something? (Sorry, I didn't investigate and assumed the latter).


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Re: Help setting dbconfig-common for MariaDB, not MySQL

[Marc Haber]

On Mon, 2 Jan 2023 16:31:17 +0100, Paul Gevers 
wrote:
>On 02-01-2023 14:21, Alessandro Vesely wrote:
>> A user complained that MySQL doesn't work, because it misses the INET6 
>> type that the example settings use.
>
>And is this an absolute must? (It's an example after all?)

It is. We need to stop having "disable IPv6" as measure 1 if something
doesn't work right. It's the default IP protocol for a decade.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Help setting dbconfig-common for MariaDB, not MySQL

[Paul Gevers]

Hi Alessandro,

On 02-01-2023 14:21, Alessandro Vesely wrote:
please pardon my ignorance about Debian install.  I'm distributing a 
software which could use various DBMS'es by setting a number of 
parameters.  Example parameters are only given for MariaDB.  I 
distribute a debian/ directory that Debian users can use to prepare a 
package instead of configure, make, make install.  However, the 
debian/postinst supports MariaDB only.


Do I understand you correctly that you don't want to support MySQL? Or 
that you don't know how to support both at the same time? Most packages 
in Debian that are using MariaDB or MySQL can easily support both (hence 
we have the default-mysql-client and virtual-mysql-client packages), and 
indeed dbconfig-common treats them as equal.


A user complained that MySQL doesn't work, because it misses the INET6 
type that the example settings use.


And is this an absolute must? (It's an example after all?)

Now I've added "mariadb-client | 
mariadb-server | dbconfig-no-thanks" to the Debian clause in 
debian/control.


I think that's wrong. At least it would fail to install dbconfig-common 
in case there is a mariadb-client installed. Also, I wonder about the 
mariadb-server part. mariadb-server depends on the versioned 
mariadb-server-* package which depends on the versioned mariadb-client-* 
package. So in case mariadb-client wouldn't be able to be fulfilled, 
mariadb-server as the second alternative isn't going to help. And in my 
opinion you should not depend on the server part. As with most 
databases, the server part can live on a different host and package 
should really not force the server to be on the same host.


I'm not clear how I could add an (optional) Conflicts 
mysql-something, also because I see no mysql-server in the package cache.


mysql-server is available in unstable, but we don't want to support both 
MySQL and MariaDB in Debian stable at the same time, so currently MySQL 
is blocked from migration. However, derivatives choose differently 
(Ubuntu supports MySQL in their releases). As mentioned above, the 
server part can be on a different host, but ependencies are not able to 
describe incompatibility with what runs on the other host.


Is there a way to fail if a user chooses to install the DB but MariaDB 
is missing?  Or is the above enough?


I don't think you can do it with dependencies. If you really want to go 
this route, you have to detect it during run time.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Re: Help trying to debug an sbuild failure?

[Theodore Ts'o]

On Wed, Dec 28, 2022 at 12:10:51AM +0100, Johannes Schauer Marin Rodrigues 
wrote:
> Note, that if you keep upgrading a Debian unstable chroot across multiple
> releases, it will end up looking slightly different than a freshly
> debootstrapped Debian unstable chroot. So I think there is value in
> semi-regularly re-creating the build chroot from scratch. Maybe write a script
> that does what you need?

That's true, but the number of user/group id's that sbuild would
actually care about is probably quite small and might very well just
be sbuild:sbuild I would think, no?

> Finally, I think this is something that could be solved in sbuild. Ultimately,
> schroot is able to do things as the root user, so it should have sufficient
> permissions to fix up a chroot that carries incorrect permissions. Could you
> quickly note in a bug against sbuild on the Debian BTS which steps exactly you
> carried out so that I am able to reproduce your problem?

Sure, no problem.

> I'm making no promises that I'll find the time to improve the schroot backend
> of sbuild to survive the kind of chroot-rsync that you have performed but if
> this is important to you, then maybe we can make a trade and I implement this
> sbuild functionality and you have a look at pull requests
> https://github.com/tytso/e2fsprogs/pull/118 or #107 and leave some comments in
> return? :)

Thanks for the reminder, I'll take a look.  Most of the patch
proposals for e2fsprogs end up going to linux-e...@vger.kernel.org (so
that other ext4 developers can review them), and I sometimes forgot to
look over the github pull requests.

I'm also about to go on a Panama Canal cruise, where my internet
access may be limited (which is why I was trying to get sbuild setup
on my laptop in the first place :-), and e-mail has the advantage of
being much easily cacheable using offlineimap...

- Ted

Re: Help trying to debug an sbuild failure?

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Theodore Ts'o (2022-12-27 05:19:45)
> On Mon, Dec 26, 2022 at 08:45:53PM +0100, Santiago Vila wrote:
> > El 26/12/22 a las 20:29, Theodore Ts'o escribió:
> > > I: The directory does not exist inside the chroot.
> > 
> > This is really a problem with schroot. I guess that this will not work 
> > either:
> > 
> > schroot -c the-chroot-name
> > 
> > This usually works when you are in your $HOME because this file:
> > 
> > /etc/schroot/default/fstab
> 
> Nope, that's not the issue; yes, /tmp and /home are missing form
> /etc/schroot/sbuild/fstab, but that was true on the *working* setup as
> well, and from what I can tell; that's deliberate.  It looks like the
> goal is to keep things hermetic when building with sbuild, so it's a
> feature that there aren't random directories leaking through from the
> host to the sbuild enviroment.

that is correct. :)

> I think I've figured out the issue.  The problem is that the user and group
> id's for sbuild are different on my desktop and my laptop, and I did an rsync
> to copy the /chroot directories from my desktop to my laptop --- and it
> appears that sbuild is very sensisitve about the user id's being the same
> across the host and chroot environments.
> 
> Apparently sbuild copies the files for the package it is building over
> a directory in /var/lib/sbuild/build, with the permissions being mode
> 770, and that is what sbuild bind mounts into the chroot.  If my
> theory is correct, if the user/group id's are different from between
> the base /etc/passwd and chroot, then things go bad in a hurry.

I think your analysis makes sense.

> >From my working system (while gbp buildpackage was running sbuild):
> 
> % ls -al /var/lib/sbuild/build/
> total 12
> 4 drwxrws--- 3 sbuild sbuild 4096 Dec 26 23:05 ./
> 4 drwxrws--- 4 sbuild sbuild 4096 Dec 19  2020 ../
> 4 drwxrwx--- 3 tytso  sbuild 4096 Dec 26 23:05 f2fs-tools-oT4KHz/
> 
> Amd on the broken (laptop) system:
> 
> # ls -al /var/lib/sbuild/build/
> total 32
> 4 drwxrws--- 8 fwupd-refresh Debian-exim 4096 Dec 26 22:48 ./
> 4 drwxrws--- 4 sbuildsbuild  4096 Dec 25 14:45 ../
> 4 drwxrwx--- 2 tytso Debian-exim 4096 Dec 26 14:01 f2fs-tools-9QfprK/
> 4 drwxrwx--- 2 tytso Debian-exim 4096 Dec 26 16:01 f2fs-tools-btkVPv/
> 4 drwxrwx--- 2 tytso Debian-exim 4096 Dec 26 14:20 f2fs-tools-cVTRAh/
> 4 drwxrwx--- 2 tytso Debian-exim 4096 Dec 26 22:48 f2fs-tools-Myld8j/
> ...
> 
> Each of were created from a failed sbuild invocation...  And
> "Debian-exim" on my laptop has the same group id as "sbuild" on my
> desktop (and which is the group id in my chroots).
> 
> This also explains the error message:
> 
> E: Failed to change to directory ‘/<>’: Permission denied
> 
> Oops.
> 
> So I guess I need to either manually juggle group id's in the chroots
> (and/or my laptop's root directory --- but it's probably easier to do
> it in the chroots, since there are fewer filees to chgrp in the
> chroots), or I could recreate the sbuild chroots from scratch using
> sbuild-createchroot (but then I would need to recreate all of the
> custom hacks so that ccache,eatmydata, apt-auto-proxy, etc. are working
> correctly in the chroot).
> 
> What fun

Note, that if you keep upgrading a Debian unstable chroot across multiple
releases, it will end up looking slightly different than a freshly
debootstrapped Debian unstable chroot. So I think there is value in
semi-regularly re-creating the build chroot from scratch. Maybe write a script
that does what you need?

That being said, I think the biggest problem is, that the main sbuild
contributors these days (me and Jochen) do not use the schroot backend anymore
but the unshare backend instead which doesn't suffer from this kind of problem
(but of course has different quirks that one needs to be aware of). So I must
admit that in the past few years, the schroot backend hasn't gotten the love
that it deserves considering that it's the default backend used on the buildd
machinery.

Finally, I think this is something that could be solved in sbuild. Ultimately,
schroot is able to do things as the root user, so it should have sufficient
permissions to fix up a chroot that carries incorrect permissions. Could you
quickly note in a bug against sbuild on the Debian BTS which steps exactly you
carried out so that I am able to reproduce your problem?

I'm making no promises that I'll find the time to improve the schroot backend
of sbuild to survive the kind of chroot-rsync that you have performed but if
this is important to you, then maybe we can make a trade and I implement this
sbuild functionality and you have a look at pull requests
https://github.com/tytso/e2fsprogs/pull/118 or #107 and leave some comments in
return? :)

Thanks!

cheers, josch

signature.asc
Description: signature

Re: Help trying to debug an sbuild failure?

[Theodore Ts'o]

On Mon, Dec 26, 2022 at 08:45:53PM +0100, Santiago Vila wrote:
> El 26/12/22 a las 20:29, Theodore Ts'o escribió:
> > I: The directory does not exist inside the chroot.
> 
> This is really a problem with schroot. I guess that this will not work either:
> 
> schroot -c the-chroot-name
> 
> This usually works when you are in your $HOME because this file:
> 
> /etc/schroot/default/fstab

Nope, that's not the issue; yes, /tmp and /home are missing form
/etc/schroot/sbuild/fstab, but that was true on the *working* setup as
well, and from what I can tell; that's deliberate.  It looks like the
goal is to keep things hermetic when building with sbuild, so it's a
feature that there aren't random directories leaking through from the
host to the sbuild enviroment.

I think I've figured out the issue.  The problem is that the user and
group id's for sbuild are different on my desktop and my laptop, and I
did an rsync to copy the /chroot directories from my desktop to my
laptop --- and it appears that sbuild is very sensisitve about the
user id's being the same across the host and chroot environments.

Apparently sbuild copies the files for the package it is building over
a directory in /var/lib/sbuild/build, with the permissions being mode
770, and that is what sbuild bind mounts into the chroot.  If my
theory is correct, if the user/group id's are different from between
the base /etc/passwd and chroot, then things go bad in a hurry.

>From my working system (while gbp buildpackage was running sbuild):

% ls -al /var/lib/sbuild/build/
total 12
4 drwxrws--- 3 sbuild sbuild 4096 Dec 26 23:05 ./
4 drwxrws--- 4 sbuild sbuild 4096 Dec 19  2020 ../
4 drwxrwx--- 3 tytso  sbuild 4096 Dec 26 23:05 f2fs-tools-oT4KHz/

Amd on the broken (laptop) system:

# ls -al /var/lib/sbuild/build/
total 32
4 drwxrws--- 8 fwupd-refresh Debian-exim 4096 Dec 26 22:48 ./
4 drwxrws--- 4 sbuildsbuild  4096 Dec 25 14:45 ../
4 drwxrwx--- 2 tytso Debian-exim 4096 Dec 26 14:01 f2fs-tools-9QfprK/
4 drwxrwx--- 2 tytso Debian-exim 4096 Dec 26 16:01 f2fs-tools-btkVPv/
4 drwxrwx--- 2 tytso Debian-exim 4096 Dec 26 14:20 f2fs-tools-cVTRAh/
4 drwxrwx--- 2 tytso Debian-exim 4096 Dec 26 22:48 f2fs-tools-Myld8j/
...

Each of were created from a failed sbuild invocation...  And
"Debian-exim" on my laptop has the same group id as "sbuild" on my
desktop (and which is the group id in my chroots).

This also explains the error message:

E: Failed to change to directory ‘/<>’: Permission denied

Oops.

So I guess I need to either manually juggle group id's in the chroots
(and/or my laptop's root directory --- but it's probably easier to do
it in the chroots, since there are fewer filees to chgrp in the
chroots), or I could recreate the sbuild chroots from scratch using
sbuild-createchroot (but then I would need to recreate all of the
custom hacks so that ccache,eatmydata, apt-auto-proxy, etc. are working
correctly in the chroot).

What fun

- Ted

p.s.  I guess if I had been planning ahead I would have made sure that
various system users and groups which are auto-created by packages at
install-time (and which are therefore different depending on install
order) were pre-created on my laptop with the same numerical id's as
on my desktop, since that would have avoided all *sorts* of random
problems, especially if I was going to play games with copying chroots
around --- or trying to use NFS --- and not getting taken by surprise
by this sort of thing.  Live and learn

Re: Help trying to debug an sbuild failure?

[Santiago Vila]

El 26/12/22 a las 20:29, Theodore Ts'o escribió:

I: The directory does not exist inside the chroot.


This is really a problem with schroot. I guess that this will not work either:

schroot -c the-chroot-name

This usually works when you are in your $HOME because this file:

/etc/schroot/default/fstab

has a line like this:

/home   /home   nonerw,bind 0   0

which makes a bind mount and makes /home to "exist" inside the chroot.

So the solution is to either try sbuild from a directory which is
bind-mounted like that, like $HOME, or add a new entry to fstab
with the directory you need.

Hope this helps.

Re: Help needed for watch file after bitbucket changed download page

[Juri Grabowski]

Hello Andreas,

On 2022-09-29 14:54 4, Andreas Tille wrote:

I confirm this works.  However, uscan does not do the usual link to
orig.tar.gz.  Any idea why this is the case?

I have found this bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896705

But did you have signing key from Rob Egan , because I
didn't found it on keyserver or in debian/upstream/signing-key.asc

Best Regards,
Juri Grabowski

Re: Help needed with a dh_shlibs failure on non amd64 platforms

[Simon McVittie]

On Mon, 04 Jul 2022 at 09:29:54 +0200, Martin Quinson wrote:
> All libraries (eg libns3-bridge.so.36.1) that it cannot find are part of the
> package. They are added to the debian/libns3.36/DEBIAN/shlibs

Independent of the dh_shlibdeps failure that was already diagnosed, if
these libraries are public (i.e. other packages in Debian are allowed to
link against them) and the SONAMEs of the libraries are of the form
libns3-*.so.36.1, then the binary package that contains them should
probably be called something like libns3-36.1, rather than libns3.36.

(Either that, or they should be split up into one binary package per
library, named like libns3-bridge36.1 and so on, by mechanically
transforming their SONAMEs according to the convention documented
in Policy - but I can understand why you would prefer not to do that when
there are a large number of libraries with matching versioning.)

Otherwise, when the SONAMEs jump from libns3-*.so.36.1 to libns3-*.so.36.2
in a future version, any dependent packages that require libns3-*.so.36.1
would be broken by upgrading libns3.36 to a version that no longer contains
libns3-*.so.36.1.

> If you wonder, the cmake macro to define and build a library is in 
>   ns-3.36.1/build-support/custom-modules/ns3-module-macros.cmake
> I already had to patch it to support Debian:
> https://salsa.debian.org/debian/ns3/-/blob/master/debian/patches/library-soversion.diff
> This patch is ugly for now, but I'm already discussing with upstream so that
> they integrate the spirit of this patch to their code. They are receptive.

If you're giving advice to upstream, it's important to be aware of
whether the libraries are private (only to be used by other binary
packages within the same source package, like samba-libs or
libsystemd-shared) or public (with a -dev package that can validly be
used by other source packages, like libsmbclient or libsystemd0 or any
typical shared library like GTK or Qt). The correct advice to give to an
upstream for private shared libraries is not the same as the correct
advice for public shared libraries.

smcv

Re: Help needed with a dh_shlibs failure on non amd64 platforms

[Samuel Thibault]

Hello,

Martin Quinson, le lun. 04 juil. 2022 09:29:54 +0200, a ecrit:
>   dpkg-shlibdeps -Tdebian/libns3.36.substvars 
> debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-wimax.so.36.1

x86_64-linux-gnu is only valid for amd64.

In

./debian/rules: -DCMAKE_INSTALL_RUNSTATEDIR=/run 
-DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu 
-DCMAKE_INSTALL_PREFIX=/usr

you want to use $(DEB_HOST_MULTIARCH) instead of hardcoding x86_64-linux-gnu

Samuel

Re: Help needed: C++ compile error with nix 2.5.1

[Jakub Wilk]

* Thomas Koch , 2022-01-16, 11:23:

https://github.com/NixOS/nix/issues/5923


The first bad commit is:
https://github.com/nlohmann/json/commit/0e694b4060ed55df

(This happens to be also the first bad commit for 
, so I guess it's the same 
issue.)


I don't know what's going on here, but the attached patch seems to fix 
it.


--
Jakub Wilk
diff --git a/src/libstore/realisation.cc b/src/libstore/realisation.cc
index f871e6437..eb3ca0198 100644
--- a/src/libstore/realisation.cc
+++ b/src/libstore/realisation.cc
@@ -78,7 +78,7 @@ Realisation Realisation::fromJSON(
 auto fieldIterator = json.find(fieldName);
 if (fieldIterator == json.end())
 return std::nullopt;
-return *fieldIterator;
+return std::string(*fieldIterator);
 };
 auto getField = [&](std::string fieldName) -> std::string {
 if (auto field = getOptionalField(fieldName))

Re: Help porting Ceph 16.2.6 to mips6el, mipsel and armel

[Thomas Goirand]

Hi Simon,

Thanks a lot for your help.

On 11/20/21 12:55 PM, Simon McVittie wrote:
> [...]
> You'll notice -latomic appears *before* the various .a and .o files, but
> in general, link order matters: each object on the linker command-line is
> only used to satisfy the dependencies of objects that appear before it.
> So you'll want -latomic to appear later, next to other dependencies
> like -ldl.

This was completely right, though the reason for it seems to be the
cmake test failure to take mips64el into account. Hopefully, this patch
fixes it:

https://salsa.debian.org/ceph-team/ceph/-/blob/debian/unstable/debian/patches/cmake-test-for-16-bytes-atomic-support-on-mips-also.patch

> On armel, the error seems to be:
> 
>> /tmp/cc3CvITT.s:2594: Error: selected processor does not support `yield' in 
>> ARM mode
>> make[7]: *** [CMakeFiles/rocksdb.dir/build.make:3436: 
>> CMakeFiles/rocksdb.dir/third-party/folly/folly/synchronization/DistributedMutex.cpp.o]
>>  Error 1
> 
> so probably there is some inline assembly that assumes ARMv6 or later and
> does not account for armel's ARMv5-based baseline.

Hopefully, this patch fixes it:
https://salsa.debian.org/ceph-team/ceph/-/blob/debian/unstable/debian/patches/only-yied-under-armv7-and-above.patch

> On mipsel, it looks like 32 bits of address space might not be enough,
> so you might need to try the same tricks that e.g. webkit2gtk uses to
> save address space:
> 
>> virtual memory exhausted: Cannot allocate memory
>> make[3]: *** [src/msg/CMakeFiles/common-msg-objs.dir/build.make:93: 
>> src/msg/CMakeFiles/common-msg-objs.dir/Message.cc.o] Error 1

I've added a few tricks to hopefully save on memory at build time on 32
bits arch, I'm not sure this will be enough though.

Anyways, now I have a different failure, on all arch this time:

/usr/include/boost/container/detail/copy_move_algo.hpp:1083:10: error:
‘__fallthrough__’ was not declared in this scope; did you mean
‘fallthrough’?
 1083 |  BOOST_FALLTHROUGH;
  |  ^

Any idea what can cause this? To me, this looks like related to the
latest gcc update (but not sure)...

Cheers,

Thomas Goirand (zigo)

Re: Help porting Ceph 16.2.6 to mips6el, mipsel and armel

[Simon McVittie]

On Sat, 20 Nov 2021 at 11:31:04 +0100, Thomas Goirand wrote:
> Latest Ceph doesn't build on 3 arch:
> 
> https://buildd.debian.org/status/package.php?p=ceph=experimental
> 
> (plus the unofficial ports...)
> 
> What worries me the most is mips6el, where the linker says "undefined
> reference to `__atomic_load_16'" (and more like this). I don't
> understand because there really is a -latomic parameter to GCC when
> linking, so it should be working.

If I download and unpack libatomic1_11.2.0-10_mips64el.deb,
libatomic1_11.2.0-10_mips64el/DEBIAN/symbols mentions symbol
__atomic_load_16@LIBATOMIC_1.0, so -latomic should have been
sufficient.

I think this is a problem with compiler argument order. It looks as though
the failing link might be this one (one long line in the log, newlines
added here to make it more comprehensible):

/usr/bin/c++ \
-g \
-O2 \
-ffile-prefix-map=/<>=. \
-fstack-protector-strong \
-Wformat \
-Werror=format-security \
-Wdate-time \
-D_FORTIFY_SOURCE=2 \
-O2 \
-g \
-DNDEBUG \
-Wl,-z,relro \
-Wl,-z,now \
-Wl,--as-needed \
-latomic \
-rdynamic \
-pie \
CMakeFiles/rbd-mirror.dir/main.cc.o \
-o \
../../../bin/rbd-mirror \
 \
-Wl,-rpath,/<>/obj-mips64el-linux-gnuabi64/lib: \
../../../lib/librbd_mirror_internal.a \
../../../lib/librbd_mirror_types.a \
../../../lib/librbd_api.a \
../../../lib/librbd_internal.a \
../../../lib/librbd_types.a \
../../../lib/libjournal.a \
../../../lib/liblibneorados.a \
../../../lib/librados.so.2.0.0 \
../../../lib/libosdc.a \
../../../lib/libcls_rbd_client.a \
../../../lib/libcls_lock_client.a \
../../../lib/libcls_journal_client.a \
../../../lib/libglobal.a \
../../../lib/libheap_profiler.a \
/usr/lib/mips64el-linux-gnuabi64/libtcmalloc.so \
/usr/lib/mips64el-linux-gnuabi64/libssl.so \
/lib/mips64el-linux-gnuabi64/libcryptsetup.so \
../../../lib/libceph-common.so.2 \
../../../lib/libfmt.a \
/usr/lib/mips64el-linux-gnuabi64/libblkid.so \
/usr/lib/mips64el-linux-gnuabi64/libcrypto.so \
../../../lib/libjson_spirit.a \
../../../lib/libcommon_utf8.a \
../../../lib/liberasure_code.a \
../../../lib/libcrc32.a \
../../../lib/libarch.a \
/usr/lib/mips64el-linux-gnuabi64/libboost_thread.so.1.74.0 \
/usr/lib/mips64el-linux-gnuabi64/libboost_atomic.so.1.74.0 \
/usr/lib/mips64el-linux-gnuabi64/libboost_random.so.1.74.0 \
/usr/lib/mips64el-linux-gnuabi64/libboost_system.so.1.74.0 \
/usr/lib/mips64el-linux-gnuabi64/libboost_program_options.so.1.74.0 \
/usr/lib/mips64el-linux-gnuabi64/libboost_date_time.so.1.74.0 \
/usr/lib/mips64el-linux-gnuabi64/libboost_iostreams.so.1.74.0 \
-lstdc++fs \
-pthread \
/usr/lib/mips64el-linux-gnuabi64/libudev.so \
/usr/lib/mips64el-linux-gnuabi64/libibverbs.so \
/usr/lib/mips64el-linux-gnuabi64/librdmacm.so \
-ldl \
/usr/lib/mips64el-linux-gnuabi64/librt.so \
-lresolv

You'll notice -latomic appears *before* the various .a and .o files, but
in general, link order matters: each object on the linker command-line is
only used to satisfy the dependencies of objects that appear before it.
So you'll want -latomic to appear later, next to other dependencies
like -ldl.

A common reason for this to be a problem is adding -latomic (or some
other library) to Automake's foo_LDFLAGS instead of the correct foo_LIBS
or foo_LIBADD, or the equivalent in other build systems. I see ceph is
built with CMake: I don't know the specifics of how this fits together in
CMake, but most likely it has the same distinction between dependencies
and non-dependency linker options that e.g. Automake and Meson do.

Regarding the other failing release architectures:

On armel, the error seems to be:

> /tmp/cc3CvITT.s:2594: Error: selected processor does not support `yield' in 
> ARM mode
> make[7]: *** [CMakeFiles/rocksdb.dir/build.make:3436: 
> CMakeFiles/rocksdb.dir/third-party/folly/folly/synchronization/DistributedMutex.cpp.o]
>  Error 1

so probably there is some inline assembly that assumes ARMv6 or later and
does not account for armel's ARMv5-based baseline.

On mipsel, it looks like 32 bits of address space might not be enough,
so you might need to try the same tricks that e.g. webkit2gtk uses to
save address space:

> virtual memory exhausted: Cannot allocate memory
> make[3]: *** [src/msg/CMakeFiles/common-msg-objs.dir/build.make:93: 
> src/msg/CMakeFiles/common-msg-objs.dir/Message.cc.o] Error 1

I hope this helps,
smcv

Re: Help porting Ceph 16.2.6 to mips6el, mipsel and armel

[Bastian Blank]

On Sat, Nov 20, 2021 at 11:31:04AM +0100, Thomas Goirand wrote:
> What worries me the most is mips6el, where the linker says "undefined
> reference to `__atomic_load_16'" (and more like this). I don't
> understand because there really is a -latomic parameter to GCC when
> linking, so it should be working.

Not all architectures support sub-wordsize atomic operations.  The only
way to fix that is to use a larger type (long usually).

Bastian

-- 
Extreme feminine beauty is always disturbing.
-- Spock, "The Cloud Minders", stardate 5818.4

Re: Help required to determine why some packages are being installed

[Dmitry Shachnev]

Hi David, and thanks for your reply!

On Thu, May 27, 2021 at 04:28:08PM +0200, David Kalnischkies wrote:
> The self-inflicted joy of avoiding a transitional package (see also the
> other thread about transitional packages on d-d@ I should comment) and
> of too strict dependencies (just because its the same source package
> doesn't mean = is a good choice; >= would have avoided that mess). ☺

Who could know that a removed package could make such a mess? :)

> Add the Breaks also to qtbase5-dev. Also, make that breaks versioned so
> that you can reintroduce qt5-default if that turns out to be needed
> (Lintian probably complains about it, too).

Thanks for the suggestion! Adding such Breaks solves most of the problems.
When I run “apt dist-upgrade”, apt no longer tries to remove libqt5gui5.

When I was testing this, I tried to upgrade only a subset of packages using
“apt install libqt5widgets5” (that package was installed, but running
that command should upgrade all Qt packages). Unfortunately, when running
this specific command, apt still wants to remove libqt5gui5 and install
libqt5gui5-gles. But I think we can live with it, as most users who have
not upgraded yet will probably use dist-upgrade (or full-upgrade).

> Usually I would recommend reintroducing qt5-default, but as you
> described it as a sid-user only problem it seems more beneficial to keep
> it removed for everyone rather than to readd for sid only confusing
> users who want to look up if a removal of qt5-default is okay or not.

To be more precise, it is a problem for users of sid and testing who have
not upgraded for a long time. Users of stable should be safe. Things are
a bit worse in Ubuntu, where the bad qt5-default made it to a stable
release. In any case, I discussed with my co-maintainer (Lisandro) and we
don't want to readd qt5-default.

--
Dmitry Shachnev

Re: Help required to determine why some packages are being installed

[David Kalnischkies]

Hi,

On Sun, May 16, 2021 at 10:00:29PM +0300, Dmitry Shachnev wrote:
> We determined that the reason for users getting libqt5gui5-gles installed
> is the qt5-default package. We removed it in October 2020 because it is no
> longer needed. But the latest version of that package that ever existed had
> this dependency:
> 
>   Depends: qtbase5-dev (= 5.14.2+dfsg-5) | qtbase5-gles-dev (>= 5.14.2+dfsg)
> 
> The latest available version of qtbase5-dev cannot satisfy that dependency,
> but the latest version of qtbase5-gles-dev can!

The self-inflicted joy of avoiding a transitional package (see also the
other thread about transitional packages on d-d@ I should comment) and
of too strict dependencies (just because its the same source package
doesn't mean = is a good choice; >= would have avoided that mess). ☺


> So for people who had qt5-default installed, apt tries to replace the normal
> Qt stack with -gles one to keep that dependency satisfied. It does so even
> if it's going to remove qt5-default anyway!

Yeah, greedy solver at its best. The problem is here mostly that an
earlier part of the solver has figured out (since bit more than a year
now) that the dependencies of qt5-default can't be satisfied (as it
tries to remove itself), but a) this knowledge isn't used much in the
caller yet and b) a later part who is usually responsible for contested
remove decisions isn't as good at figuring it out yet, so it decides to
try the bad gles subtree and as greedys are bad at reconsidering their
decisions it leads down to madness.

That specific case might actually be solvable on the apt side with some
more heavy work I intend to do eventually (just like I did for the
mentioned earlier part), but as you might expect, this isn't appropriate
to even think about while in freeze so don't hold your breath – and less
clear instances of this will probably remain out of reach still, so lets
look at our options:


> As an attempt to solve this problem, I added "Breaks: qt5-default" to both
> qtbase5-gles-dev and libqt5gui5-gles packages yesterday [2]. I thought this
> would convince apt to not consider these packages as a way to satisfy
> qt5-default dependency. But that did not work :(

Add the Breaks also to qtbase5-dev. Also, make that breaks versioned so
that you can reintroduce qt5-default if that turns out to be needed
(Lintian probably complains about it, too).

Usually I would recommend reintroducing qt5-default, but as you
described it as a sid-user only problem it seems more beneficial to keep
it removed for everyone rather than to readd for sid only confusing
users who want to look up if a removal of qt5-default is okay or not.


As qtbase5-dev is installed and depended on while nobody likes
qt5-default anymore the ProblemResolver will have an easy time figuring
out that removing qt5-default is better than holding back qtbase5-dev
would be and hence as a second step wont try to save qt5-default by
installing qtbase5-gles-dev (just to then figure out that gles-dev
breaks qt5-default, so it has to remove the later anyhow).


Thanks for looking into this: That seems like a simpler and less
controversial example than the one I used for the last big round of
resolver changes … and sorry it took me a while to reply.


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Re: Help required to determine why some packages are being installed

[Dmitry Shachnev]

Hi again David and all!

I want to ask for the help again.

We determined that the reason for users getting libqt5gui5-gles installed
is the qt5-default package. We removed it in October 2020 because it is no
longer needed. But the latest version of that package that ever existed had
this dependency:

  Depends: qtbase5-dev (= 5.14.2+dfsg-5) | qtbase5-gles-dev (>= 5.14.2+dfsg)

The latest available version of qtbase5-dev cannot satisfy that dependency,
but the latest version of qtbase5-gles-dev can!

So for people who had qt5-default installed, apt tries to replace the normal
Qt stack with -gles one to keep that dependency satisfied. It does so even
if it's going to remove qt5-default anyway!

As an attempt to solve this problem, I added "Breaks: qt5-default" to both
qtbase5-gles-dev and libqt5gui5-gles packages yesterday [2]. I thought this
would convince apt to not consider these packages as a way to satisfy
qt5-default dependency. But that did not work :(

I am attaching a log which was obtained as follows:

- Use sid snapshot from 2020-10-28 (a day before qt5-default was removed).
- Install qt5-default package.
- Change sources.list to use current sid.
- Upgrade apt to the latest version (just in case).
- Run "apt -o Debug::pkgProblemResolver=yes full-upgrade".

As can be seen in that log, apt still tries to remove libqt5gui5 and install
libqt5gui5-gles. If it did not do that, it would have to remove only one
package (qt5-default) and not three.

Can you please give me any advice on how to prevent apt from doing that?

[1]: 
https://tracker.debian.org/news/1187732/accepted-qtbase-opensource-src-5151dfsg-2-source-into-unstable/
[2]: 
https://tracker.debian.org/news/1241122/accepted-qtbase-opensource-src-gles-5152dfsg-4-source-into-unstable/

P.S. The suggestion from your last mail (see my quote below) did not work too.

On Sat, Jan 30, 2021 at 08:51:09PM +0300, Dmitry Shachnev wrote:
> Thanks for the suggestion! Having the reverse doesn’t hurt of course, so
> I have just added it in [1] and will include in the next upload. Let’s see
> if it makes things any better.
>
> [1]: https://salsa.debian.org/qt-kde-team/qt/qtbase/-/commit/4064bf01d808094d

--
Dmitry Shachnev
root@mitya57:/# apt -o Debug::pkgProblemResolver=yes full-upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Starting pkgProblemResolver with broken count: 1
Starting 2 pkgProblemResolver with broken count: 1
Investigating (0) qt5-default:amd64 < 5.14.2+dfsg-6 @ii mK Ib >
Broken qt5-default:amd64 Depends on qtbase5-dev:amd64 < 5.14.2+dfsg-6 -> 
5.15.2+dfsg-5 @ii umU > (= 5.14.2+dfsg-6)
  Considering qtbase5-dev:amd64 0 as a solution to qt5-default:amd64 -2
Broken qt5-default:amd64 Depends on qtbase5-gles-dev:amd64 < none | 
5.15.2+dfsg-4 @un uH > (>= 5.14.2+dfsg)
  Considering qtbase5-gles-dev:amd64 -1 as a solution to qt5-default:amd64 -2
  Try Installing qtbase5-gles-dev:amd64 < none | 5.15.2+dfsg-4 @un uH > before 
changing qt5-default:amd64
  Or group remove for qt5-default:amd64
Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
  fontconfig fontconfig-config fonts-dejavu-core libavahi-client3 
libavahi-common-data libavahi-common3 libboost-iostreams1.67.0 
libboost-iostreams1.71.0 libboost-system1.67.0 libbrotli1 libbsd0 libcups2 
libcwidget3v5 libdbus-1-3
  libdouble-conversion3 libdrm-amdgpu1 libdrm-common libdrm-intel1 
libdrm-nouveau2 libdrm-radeon1 libdrm2 libedit2 libegl-dev libegl-mesa0 libegl1 
libelf1 libevdev2 libexpat1 libfontconfig1 libfreetype6 libgbm1 libgl-dev libgl1
  libgl1-mesa-dri libglapi-mesa libgles2 libglib2.0-0 libglu1-mesa 
libglu1-mesa-dev libglvnd0 libglx-dev libglx-mesa0 libglx0 libgraphite2-3 
libgudev-1.0-0 libharfbuzz0b libice6 libicu67 libinput-bin libinput10 
libjpeg62-turbo libllvm11
  libmd0 libmd4c0 libmtdev1 libnss-nis libnss-nisplus libpciaccess0 
libpcre2-16-0 libperl5.30 libpng16-16 libpthread-stubs0-dev libqt5concurrent5 
libqt5core5a libqt5dbus5 libqt5gui5-gles libqt5network5 libqt5printsupport5 
libqt5sql5
  libqt5test5 libqt5widgets5 libqt5xml5 libsensors-config libsensors5 libsm6 
libvulkan-dev libvulkan1 libwacom-common libwacom2 libwayland-client0 
libwayland-server0 libx11-6 libx11-data libx11-dev libx11-xcb1 libxau-dev 
libxau6
  libxcb-dri2-0 libxcb-dri3-0 libxcb-glx0 libxcb-icccm4 libxcb-image0 
libxcb-keysyms1 libxcb-present0 libxcb-randr0 libxcb-render-util0 
libxcb-render0 libxcb-shape0 libxcb-shm0 libxcb-sync1 libxcb-util0 libxcb-util1 
libxcb-xfixes0
  libxcb-xinerama0 libxcb-xinput0 libxcb-xkb1 libxcb1 libxcb1-dev libxdamage1 
libxdmcp-dev libxdmcp6 libxext-dev libxext6 libxfixes3 libxkbcommon-x11-0 
libxkbcommon0 libxml2 libxrender1 libxshmfence1 libxxf86vm1 libz3-4
  perl-modules-5.30 qt5-qmake qt5-qmake-bin qtbase5-dev-tools qtchooser 
shared-mime-info ucf x11-common x11proto-core-dev x11proto-dev 
x11proto-xext-dev xkb-data xorg-sgml-doctools xtrans-dev
Use 

Re: Help required to determine why some packages are being installed

[Dmitry Shachnev]

Hi David, and thanks for your thorough reply and explanation!

On Sat, Jan 30, 2021 at 12:15:01PM +0100, David Kalnischkies wrote:
> To refine this: apt¹ picks the first alternative which is either:
> 1. already installed and satisfying as is
> 2. already installed, but needs an upgrade to satisfy
> 3. not installed, but can (may) be and would satisfy
>
> [...]

That was my understanding as well (and what you wrote below too).

> That said, I find it a bit odd that only libqt5gui5-gles conflicts with
> libqt5gui5. I doubt it will help apt, but it seems more honest to also
> have the reverse. Fun fact: having it only on one side actually gives
> the one having it a scoring advantage in apts conflict resolution, so
> for apt it reads in fact like -gles is the preferred package of the
> two making it less likely that apt holds back libqt5gui5. In practice
> other score points should level the playing field for libqt5gui5 though.
> (At least on my system more things depend on it than -gles provides).

Thanks for the suggestion! Having the reverse doesn’t hurt of course, so
I have just added it in [1] and will include in the next upload. Let’s see
if it makes things any better.

[1]: https://salsa.debian.org/qt-kde-team/qt/qtbase/-/commit/4064bf01d808094d

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Re: Help required to determine why some packages are being installed

[David Kalnischkies]

On Wed, Jan 27, 2021 at 04:53:50PM +0100, Johannes Schauer Marin Rodrigues 
wrote:
> Quoting Jonas Smedegaard (2021-01-27 16:15:17)
> > I suspect that's not really the case - that instead apt tools might pick at
> > random.
> 
> no, apt does not pick at random. The apt solver prefers the first alternative.

To refine this: apt¹ picks the first alternative which is either:
1. already installed and satisfying as is
2. already installed, but needs an upgrade to satisfy
3. not installed, but can (may) be and would satisfy

(in reality you have to factor in explicit provides and implicit ones
 (like M-A:foreign) for all of them individual as well – and while apt
 has a partial order for those, you don't want to hear the details…
 just pretend its "clever" "random" between different providers of a
 given alternative).

(And for completeness "A|B, B|C" will have you end up with A and B
 installed except if e.g. A depends on C, then it will be A and C.
 So it's depth first for now. If you like this behaviour is a question
 of how preferable A is over B and how co-installable they are)

None of this is explicit requirement by Debian policy (which is silent
on many other things apt is required to do by tradition as well), it
only sort of follows out of "§7.1 Syntax" saying that any will do while
"§7.5 Virtual Packages" says that the default should be the first.


Note that if apt¹ can figure out that an alternative will not work it
will pick another alternative which may or may not be what you meant
with "is not available" as that (especially in unstable) includes if
a dependency of this alternative is not satisfied. Sounds innocent and
simple, right?

Consider that this includes all types of dependencies, not only the
positive depends on a not-yet build other package but also e.g. conflicts
with another package which must be part of the solution (= a direct
chain without other solutions from initial to this package exists) or
breaks you thought are there to force an upgrade of a package, but as
that version isn't built yet effectively means that the package has to
be removed instead.


So, without giving this a deep inspection my guess is simply that in
these cases apt managed to figure out that libqt5gui5 was not a good
alternative at the moment the user made the install/upgrade and went on
and choose the other. That's the point of alternatives after all.


In a way, that might be a regression of me working on those conundrums
last year to have apt figure out these things better to avoid breaking
recommends (in which these or-group and provides problems exist as well)
and letting apt find solutions which would previously be errors (as it
picked an unworkable alternative at first and wouldn't be able to
recover from it later on). So some (not all, apt always tried hard, it
just a bit more clever about it) of these users might previously be
greeted by apt error messages until the unstable archive stabilised
reporting bugs against apt as a solution "clearly" exists while apt will
now find that solution you would prefer it not to find it seems.


> I really would like to prevent this from happening for other users,
> so any suggestions would be welcome.

I don't think there is a solution to your problem – assuming that is
indeed this problem as I am only guessing – as at the very end its a
problem of the user accepting a solution they shouldn't, but to know
that you need to have specific domain knowledge. The hidden joys of
Debian unstable I guess… (doesn't help that it sort of sounds like
a package rename when libqt5gui5 is removed and -gles installed).


That said, I find it a bit odd that only libqt5gui5-gles conflicts with
libqt5gui5. I doubt it will help apt, but it seems more honest to also
have the reverse. Fun fact: having it only on one side actually gives
the one having it a scoring advantage in apts conflict resolution, so
for apt it reads in fact like -gles is the preferred package of the
two making it less likely that apt holds back libqt5gui5. In practice
other score points should level the playing field for libqt5gui5 though.
(At least on my system more things depend on it than -gles provides).


Best regards

David Kalnischkies


¹ Then I say apt here I mean the default resolver parts implemented in
libapt and used wholesale by pretty much everything using that library
including apt, apt-get, synaptics, various software centers, …
aptitude being a notable exception with its own resolver reusing only
some parts and reimplementing others which may or may not include the
parts responsible here (it is not an exaggeration when I say we have no
active Debian contributor who could answer that question as the only
person knowing how the aptitude resolver works went MIA years ago. So
the main reason it still (FSVO) works is that supercow is benevolent).
The other notable exception would be (c)debootstrap, but you have other
problems to worry about if your package is part of the early bootstrap
before those 

Re: Help required to determine why some packages are being installed

[Jonas Smedegaard]

Quoting Johannes Schauer Marin Rodrigues (2021-01-27 16:53:50)
> Quoting Jonas Smedegaard (2021-01-27 16:15:17)
> > I suspect that's not really the case - that instead apt tools might 
> > pick at random.
> 
> no, apt does not pick at random. The apt solver prefers the first 
> alternative.

With the plural "apt tools" I mean not only /usr/bin/apt but all tools 
linked with /usr/lib/*/libapt-pkg.so.* (and tools implementing same 
interfaces in other ways, if such exist).

Is there only one apt solver with only one possible configuration?

Maybe the word "random" is the wrong one to use, but do all those tools 
always pick the first option in all cases?

E.g. would they all _refuse_ to provide a solution that installed any 
packages if asked to install A, where A depends on B and C and B depends 
on "D1 or D2" and C depends on "D2 or D1"? - or which of those direct 
opposite "firsts" would in such scenario be deterministically picked?

It is my (vague!) understanding that the resolver used by aptitude (and, 
I assume, all apt tools) has priority between direct alternatives as one 
factor but other factors exist as well and the order and weight of 
factors is configurable to some degree.


> > It is my understanding that build daemons _ignore_ secondary entries 
> > exactly to avoid such ambiguity.
> 
> More precisely: not only build daemons but sbuild (even if you run it 
> locally) strips out all but the first alternative for Build-Depends, 
> Build-Depends-Indep and Build-Depends-Arch, with the exception of 
> those alternatives that name the same package as the first 
> alternative. Thus, this does *not* have an effect on alternatives in 
> binary packages.

Ah, I was unaware that _only_ build-dependencies was affected.  Thanks!


 - Jonas

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

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

signature.asc
Description: signature

Re: Help required to determine why some packages are being installed

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Jonas Smedegaard (2021-01-27 16:15:17)
> I suspect that's not really the case - that instead apt tools might pick at
> random.

no, apt does not pick at random. The apt solver prefers the first alternative.

> It is my understanding that build daemons _ignore_ secondary entries
> exactly to avoid such ambiguity.

More precisely: not only build daemons but sbuild (even if you run it locally)
strips out all but the first alternative for Build-Depends, Build-Depends-Indep
and Build-Depends-Arch, with the exception of those alternatives that name the
same package as the first alternative. Thus, this does *not* have an effect on
alternatives in binary packages.

Thanks!

cheers, josch

signature.asc
Description: signature

Re: Help required to determine why some packages are being installed

[Jonas Smedegaard]

Quoting Lisandro Damián Nicanor Pérez Meyer (2021-01-27 15:09:41)
> So most packages now have an alternative dependency like libqt5gui5 
> (>= 5.x) | libqt5gui5-gles (>= 5.x). The strange thing is that *some* 
> users upgrading from stable or reinstalling packages [1] get the -gles 
> variant instead of the non-gles one by default. This causes bugs like 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976389
> 
> So far we couldn't reproduce the issue so we are kindly asking for
> your help in order to determine what's causing this behavior.

In above bugreport you write the following:

> All dependencies should be in a form like libqt5gui5 | 
> libqt5gui5-gles, so apt should fall back to the latter package only if 
> the former is not available for some reason. So I want to understand 
> what that reason is.

Is that really correct for all apt tools?  That the first is certain to 
be prioritized?

I suspect that's not really the case - that instead apt tools might pick 
at random.  It is my understanding that build daemons _ignore_ secondary 
entries exactly to avoid such ambiguity.


 - Jonas

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

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

signature.asc
Description: signature

Re: Help with contacting Ubuntu devs for updating critically broken packages

[Eli Schwartz]

Thank you, Norbert, for trying to get this fixed. calibre upstream
already had 6 bug reports and counting in just the last week, for an issue:

- that was fixed in May
- only applicable to people field-testing the python3 transition which
  was marked as beta and is currently superseded by stable releases

Obviously, upstream getting bug reports due to distro respins shipping
*outdated* and broken beta code is one of those "non-ideal" situations...

> The upload needs to be confirmed that it fixes the problem by someone
> else than you before it gets into Ubuntu proper. I haven't had any good
> experience with it.

I guess it would be nice if "I'm the debian maintainer, you accidentally
pulled a beta build which is RC-buggy" had some weight to it.

We'll see how it goes, I suppose. There will be major problems if Ubuntu
keeps this in an LTS release for the next 5 years.

-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: Help with contacting Ubuntu devs for updating critically broken packages

[Norbert Preining]

Hi Scott, hi Andreas,

thanks for your answers.

On Tue, 13 Oct 2020, Scott Talbert wrote:
> better discussed on an Ubuntu mailing list, rather than Debian.

I have sent an email to ubuntu-devel with detailed explanations.

I hoped for some contact here of a Debian *and* Ubuntu developer with
experience in these kinds of actions.

Best

Norbert

--
PREINING Norbert  https://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Re: Help with contacting Ubuntu devs for updating critically broken packages

[Andreas Rönnquist]

On Wed, 14 Oct 2020 07:23:58 +0900,
Norbert Preining wrote:

>Hi all
>
>(please Cc)
>
>is there a way to update hopelessly broken packages in Ubuntu Focal
>LTS?
>
>(packages in question are onedrive and in particular calibre - I
>refrain from commenting on the reasons behind calibre)
>
>Ubuntu seems to pull at arbitrary intervals rather incomplete packages
>that end up in LTS releases, and upstream gets flooded with bug
>reports.
>
>Thanks for any pointer
>

You are probably looking for this:

https://wiki.ubuntu.com/StableReleaseUpdates

The upload needs to be confirmed that it fixes the problem by someone
else than you before it gets into Ubuntu proper. I haven't had any good
experience with it.

-- Andreas Rönnquist
mailingli...@gusnan.se
andr...@ronnquist.net

Re: Help with contacting Ubuntu devs for updating critically broken packages

[Scott Talbert]

On Wed, 14 Oct 2020, Norbert Preining wrote:


Hi all

(please Cc)

is there a way to update hopelessly broken packages in Ubuntu Focal LTS?

(packages in question are onedrive and in particular calibre - I refrain
from commenting on the reasons behind calibre)

Ubuntu seems to pull at arbitrary intervals rather incomplete packages
that end up in LTS releases, and upstream gets flooded with bug reports.


Yes, Ubuntu has a Stable Release Update process[1], but this is probably 
better discussed on an Ubuntu mailing list, rather than Debian.


Scott

[1] https://wiki.ubuntu.com/StableReleaseUpdates

Re: help needed to resolve nodejs transition #963039

[Adrian Bunk]

On Fri, Jul 03, 2020 at 07:50:55PM +0200, Jérémy Lal wrote:
>...
> One can install nodejs 10 along with libnode64, and build node-iconv
> using libnode-dev 12 which links to libnode72.
> 
> However, running node-iconv tests in the autopkgtests environment requires
> the nodejs version that is linked against the same libnode abi (i hope that
> part is obvious).
> 
> But it's not the case: the tests are run with nodejs 10 from testing,
> against a package
> built with libnode72, so the module loading fails.
> 
> Those failures seem to be preventing transition to testing (which is
> understandable).
> Two questions:
> - how to fix the issue now
> - how to fix the issue for good

Is my understanding correct that a module built with a libnode
different from the one used by the nodejs package installed is
nonfunctional?

In other words, having more than one libnode library package installed
is always wrong?

In this case the correct solution is:
Package: libnode72
Breaks: libnode64

A generic version for future updates is:
Package: libnode72
Provides: libnode
Breaks: libnode

libnode64 did not provide libnode, so the generic version needs a 
special case for it:
Package: libnode72
Provides: libnode
Breaks: libnode64, libnode

Alternatively, you could additionally avoid the troubles of having to go 
through NEW for major new upstream versions by moving libnode into nodejs:
Package: nodejs
Provides: libnode72
Breaks: libnode64

> Thanks in advance for any help.
> 
> Jérémy

cu
Adrian

Re: help needed to resolve nodejs transition #963039

[Jérémy Lal]

Le ven. 3 juil. 2020 à 20:53, Jonas Smedegaard  a écrit :

> Quoting Jonas Smedegaard (2020-07-03 20:45:22)
> > Quoting Jérémy Lal (2020-07-03 19:50:55)
> > > I have a problem with the transition of nodejs:
> > > from version 10 with abi libnode64
> > > to version 12 with abi libnode72
> > >
> > > C(++) addons like node-iconv can be compiled using libnode-dev,
> > > so installing an addon automatically installs the right libnodeXX
> version.
> > > (all addons Build-Depend libnode-dev).
> > >
> > > One can install nodejs 10 along with libnode64, and build node-iconv
> > > using libnode-dev 12 which links to libnode72.
> > >
> > > However, running node-iconv tests in the autopkgtests environment
> requires
> > > the nodejs version that is linked against the same libnode abi (i hope
> that
> > > part is obvious).
> > >
> > > But it's not the case: the tests are run with nodejs 10 from testing,
> > > against a package
> > > built with libnode72, so the module loading fails.
> > >
> > > Those failures seem to be preventing transition to testing (which is
> > > understandable).
> > > Two questions:
> > > - how to fix the issue now
> > > - how to fix the issue for good
> > >
> > > Thanks in advance for any help.
> >
> > Have libnodeNN include a symbols file tracking changes to the ABI, so
> > that any C++ addon depending on a part of the ABI which changes gets
> > tightened package dependency on that specific binary release of the ABI.
>
> No wait, that's complete rubbish what I wrote above: We are talking
> about new major releases of the ABI so a symbols file would simply be
> reset completely - and also, what I was thinking should happen already
> does happen: node-iconv depends on a specific libnodeNN.
>
> Problem is (talking to myself here, you already know it) that we need to
> ensure that node-iconv is only ever _loaded_ by that same node as it is
> linked against.
>
> Only way I can imagine ensuring that is to extend symbols/shlibs
> handling to add Breaks (if that is even possible), or add breaks to the
> libnodeNN package itself so that only one libnodeNN can be present on
> the system at once.
>
> In which situations do we need libnodeNN to be co-installable?
>

Some other program linking against libnodePP.
The only case i know of is the one where libnode-dev provides libv8-dev.
But the absence of cases shouldn't be hushhushed.


>
>
>  - Jonas
>
> --
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private

Re: help needed to resolve nodejs transition #963039

[Jonas Smedegaard]

Quoting Jonas Smedegaard (2020-07-03 20:45:22)
> Quoting Jérémy Lal (2020-07-03 19:50:55)
> > I have a problem with the transition of nodejs:
> > from version 10 with abi libnode64
> > to version 12 with abi libnode72
> > 
> > C(++) addons like node-iconv can be compiled using libnode-dev,
> > so installing an addon automatically installs the right libnodeXX version.
> > (all addons Build-Depend libnode-dev).
> > 
> > One can install nodejs 10 along with libnode64, and build node-iconv
> > using libnode-dev 12 which links to libnode72.
> > 
> > However, running node-iconv tests in the autopkgtests environment requires
> > the nodejs version that is linked against the same libnode abi (i hope that
> > part is obvious).
> > 
> > But it's not the case: the tests are run with nodejs 10 from testing,
> > against a package
> > built with libnode72, so the module loading fails.
> > 
> > Those failures seem to be preventing transition to testing (which is
> > understandable).
> > Two questions:
> > - how to fix the issue now
> > - how to fix the issue for good
> > 
> > Thanks in advance for any help.
> 
> Have libnodeNN include a symbols file tracking changes to the ABI, so 
> that any C++ addon depending on a part of the ABI which changes gets 
> tightened package dependency on that specific binary release of the ABI.

No wait, that's complete rubbish what I wrote above: We are talking 
about new major releases of the ABI so a symbols file would simply be 
reset completely - and also, what I was thinking should happen already 
does happen: node-iconv depends on a specific libnodeNN.

Problem is (talking to myself here, you already know it) that we need to 
ensure that node-iconv is only ever _loaded_ by that same node as it is 
linked against.

Only way I can imagine ensuring that is to extend symbols/shlibs 
handling to add Breaks (if that is even possible), or add breaks to the 
libnodeNN package itself so that only one libnodeNN can be present on 
the system at once.

In which situations do we need libnodeNN to be co-installable?


 - Jonas

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

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

signature.asc
Description: signature

Re: help needed to resolve nodejs transition #963039

[Jonas Smedegaard]

Quoting Jérémy Lal (2020-07-03 19:50:55)
> I have a problem with the transition of nodejs:
> from version 10 with abi libnode64
> to version 12 with abi libnode72
> 
> C(++) addons like node-iconv can be compiled using libnode-dev,
> so installing an addon automatically installs the right libnodeXX version.
> (all addons Build-Depend libnode-dev).
> 
> One can install nodejs 10 along with libnode64, and build node-iconv
> using libnode-dev 12 which links to libnode72.
> 
> However, running node-iconv tests in the autopkgtests environment requires
> the nodejs version that is linked against the same libnode abi (i hope that
> part is obvious).
> 
> But it's not the case: the tests are run with nodejs 10 from testing,
> against a package
> built with libnode72, so the module loading fails.
> 
> Those failures seem to be preventing transition to testing (which is
> understandable).
> Two questions:
> - how to fix the issue now
> - how to fix the issue for good
> 
> Thanks in advance for any help.

Have libnodeNN include a symbols file tracking changes to the ABI, so 
that any C++ addon depending on a part of the ABI which changes gets 
tightened package dependency on that specific binary release of the ABI.

 - Jonas

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

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

signature.asc
Description: signature

Re: help needed to resolve nodejs transition #963039

[Paul Gevers]

Hi Jérémy,

On 03-07-2020 19:50, Jérémy Lal wrote:
> Those failures seem to be preventing transition to testing (which is
> understandable).
> Two questions:
> - how to fix the issue now

One option is that the libnode72 add a Breaks on the broken versions of
node-iconv, node-expat, node-* in testing.

> - how to fix the issue for good

I think node-iconv and similar packages need to declare a *versioned*
dependency on nodejs. The trick is of course how to figure out the right
version at build time. (Of course that mostly defeats the purpose of
having co-installable libraries libnode*).

Paul



signature.asc
Description: OpenPGP digital signature

Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

[Ulrike Uhlig]

Hi!

On 06.01.20 19:56, Alexander Wirt wrote:
> On Mon, 06 Jan 2020, Ulrike Uhlig wrote:
>>> On 28.12.19 18:16, Alexander Wirt wrote:
>> >From your replies to emails in this thread I was wondering: do you mean
>> that the Salsa team does not need, or does not want, help? Or does not
>> need, or want, help outside of a sprint?
> That basically means: yes we probably need help. But it also means that
> getting help should be done in a coordinated way, like introducing one or two
> team members during a sprint. Getting someone new involved always means
> overhead and should happen when there is time for such overhead. In my
> experience sprints are ideal for it. I also talked to some people about
> getting them involved in salsa, but there will also be a call for help. 
> 
> I / we plan to add at least one global admin and maybe one or two assistants
> that help with "user" support. 
> 
> We just need some time to plan and coordinate those things (around christmas
> is really a bad timing for such discussions)

Sounds like a good plan! :)

 -- ulrike

Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

[Alexander Wirt]

On Mon, 06 Jan 2020, Ulrike Uhlig wrote:

> Hi formorer,
> 
> > On 28.12.19 18:16, Alexander Wirt wrote:
> >> On Thu, 26 Dec 2019, Otto Kekäläinen wrote:
> >> I am sure there are many ways to help the team and it is not just
> >> about Salsa/Gitlab admin stuff, but also about creating structure in
> >> the team, triaging issues, spreading best practices for users and
> >> helping the most advanced users to grow into admins of Salsa etc.
> >> Right now we don't even have any kind of salsa-related discussion
> >> list on lists.debian.org. Thus I wanted to raise discussion on
> >> debian-devel. In my opinion Salsa is becoming a very central piece of
> >> the Debian infrastructure and it should have more attention on
> >> debian-devel and from the project leader.
> 
> > We are working on it and after my holidays are over I will plan
> > another sprint for improving salsa.
> 
> >From your replies to emails in this thread I was wondering: do you mean
> that the Salsa team does not need, or does not want, help? Or does not
> need, or want, help outside of a sprint?
That basically means: yes we probably need help. But it also means that
getting help should be done in a coordinated way, like introducing one or two
team members during a sprint. Getting someone new involved always means
overhead and should happen when there is time for such overhead. In my
experience sprints are ideal for it. I also talked to some people about
getting them involved in salsa, but there will also be a call for help. 

I / we plan to add at least one global admin and maybe one or two assistants
that help with "user" support. 

We just need some time to plan and coordinate those things (around christmas
is really a bad timing for such discussions)

Alex

Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

[Ulrike Uhlig]

Hi formorer,

> On 28.12.19 18:16, Alexander Wirt wrote:
>> On Thu, 26 Dec 2019, Otto Kekäläinen wrote:
>> I am sure there are many ways to help the team and it is not just
>> about Salsa/Gitlab admin stuff, but also about creating structure in
>> the team, triaging issues, spreading best practices for users and
>> helping the most advanced users to grow into admins of Salsa etc.
>> Right now we don't even have any kind of salsa-related discussion
>> list on lists.debian.org. Thus I wanted to raise discussion on
>> debian-devel. In my opinion Salsa is becoming a very central piece of
>> the Debian infrastructure and it should have more attention on
>> debian-devel and from the project leader.

> We are working on it and after my holidays are over I will plan
> another sprint for improving salsa.

>From your replies to emails in this thread I was wondering: do you mean
that the Salsa team does not need, or does not want, help? Or does not
need, or want, help outside of a sprint?

 -- ulrike

Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

[Alexander Wirt]

On Mon, 06 Jan 2020, Sam Hartman wrote:

> > "Alexander" == Alexander Wirt  writes:
> 
> Alexander> For everything else: we are working on it. 
> 
> I just want to confirm that part of the things that you are working on
> is documenting the issues.  At a number of points you've talked about
> how people are misunderstanding the issues or are thinking it's simply
> more CPU etc.
> 
> That's all doubtless true.
> But part of being in a community is communicating with that community.
> People would almost certainly be more understanding if they had more
> information.
just for the record, I am doing all of this in my spare time and I prefer to
decide on my own what is in my queue and what the priority is. And yes, I do
prefer to fix things instead of documenting what needs to get fixed. 

And if everyone would behave sane instead of st* flame wars, insulting each
other and so on (it was a listmaster month to forget) my motivation to work
with that specific community would be a lot better. 

And for everyones sake: when announcing CI support we told everyone that the
ressources are limited and everyone should play nice with the CI. 

As often, other people decided to make the CI and the runners a quasi
standard, adding it to their workflows and so on. Now everyone is surprised
if things are as we always told everybody. What a surprise. 

Thanks for listening. 

Alex



signature.asc
Description: PGP signature

Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

[Sam Hartman]

> "Alexander" == Alexander Wirt  writes:

Alexander> For everything else: we are working on it. 

I just want to confirm that part of the things that you are working on
is documenting the issues.  At a number of points you've talked about
how people are misunderstanding the issues or are thinking it's simply
more CPU etc.

That's all doubtless true.
But part of being in a community is communicating with that community.
People would almost certainly be more understanding if they had more
information.

Yes, that sort of communication does involve time, and yes that time
could be spent fixing things.
There comes a point though where the communication becomes at least as
important as the fix.

I think I've heard several requests for more information here, and I
just want to confirm that too is in your queue.


--Sam

Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

[Alexander Wirt]

On Wed, 01 Jan 2020, Otto Kekäläinen wrote:

> Hello!
> 
> ti 31. jouluk. 2019 klo 14.55 Alexander Wirt (formo...@debian.org) kirjoitti:
> > On Mon, 30 Dec 2019, Bernd Zeimetz wrote:
> > > Also, if resources are an issue: I've offered several times to see if I
> > > can get some k8s resources for gitlab runners, but never got a reply.
> > > Not even a no.
> > It is not a problem on the runner side.
> >
> > And as said, we are working on the other problems until we can improve
> > something in that part.
> 
> If it is not a problem on the runner side and you don't need more
> runner resources, what is the reason the runner is capped at 1h?
> MariaDB is a huge beast and building it and running all tests take
> 1,5h for completely valid reasons (also note we have ccache on
> Salsa-CI so re-builds are much faster).
We updated the timeout to three hours. However, if that leads to problems on
salsa side we will have to set it back. So please ensure not to create too
much load / jobs that use that extended limit. 

For everything else: we are working on it. 

Alex

Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

[Otto Kekäläinen]

Hello!

ti 31. jouluk. 2019 klo 14.55 Alexander Wirt (formo...@debian.org) kirjoitti:
> On Mon, 30 Dec 2019, Bernd Zeimetz wrote:
> > Also, if resources are an issue: I've offered several times to see if I
> > can get some k8s resources for gitlab runners, but never got a reply.
> > Not even a no.
> It is not a problem on the runner side.
>
> And as said, we are working on the other problems until we can improve
> something in that part.

If it is not a problem on the runner side and you don't need more
runner resources, what is the reason the runner is capped at 1h?
MariaDB is a huge beast and building it and running all tests take
1,5h for completely valid reasons (also note we have ccache on
Salsa-CI so re-builds are much faster).

Could you be kind at set back the default runner time limit to 2h as
it was some weeks ago?
This is stopping me and our contributors from working on putting
mariadb-10.4 in Debian.

It you don't intend to revert the change back to how it was?

Or could you please at least state the reasons at
https://salsa.debian.org/salsa/support/issues/184 ? So far you have
not commented anything in your own bug tracker at salsa/support..

Thanks again for everybody maintaining and developing Salsa, the CI
and all that comes with them. That has been a huge boost in my
motivation to continue Debian work and makes me much more productive
than ever before.


- Otto

Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

[Alexander Wirt]

On Mon, 30 Dec 2019, Bernd Zeimetz wrote:

> 
> 
> On 12/30/19 11:29 AM, Raphael Hertzog wrote:
> > I don't think that salsa-ci is particularly problematic in terms of
> > "efficiency". With the exception of the LXC usage, there's not much
> > that can be "cut" to save resources.
> 
> Also, if resources are an issue: I've offered several times to see if I
> can get some k8s resources for gitlab runners, but never got a reply.
> Not even a no.
It is not a problem on the runner side. 
 
And as said, we are working on the other problems until we can improve
something in that part. 

Alex

Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

[Bernd Zeimetz]

On 12/30/19 11:29 AM, Raphael Hertzog wrote:
> I don't think that salsa-ci is particularly problematic in terms of
> "efficiency". With the exception of the LXC usage, there's not much
> that can be "cut" to save resources.

Also, if resources are an issue: I've offered several times to see if I
can get some k8s resources for gitlab runners, but never got a reply.
Not even a no.


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

[Alexander Wirt]

On Mon, 30 Dec 2019, Raphael Hertzog wrote:

> On Sat, 28 Dec 2019, Alexander Wirt wrote:
> > On Thu, 26 Dec 2019, Otto Kekäläinen wrote:
> > 
> > > Hello!
> > > 
> > > I've seen many times before statements like these so I'd like to raise
> > > some discussion around the topic:
> > > 
> > > pe 13. syysk. 2019 klo 16.36 Bastian Blank (wa...@debian.org) kirjoitti:
> > > > On Sun, Sep 08, 2019 at 05:35:10PM -0400, Sam Hartman wrote:
> > > > > The Salsa CA pipeline is recommended.
> > > >
> > > > For this I need to use my veto as Salsa admin.  With the CI people we
> > > > have to work through too much problems first.
> > The salsa ci pipeline itself has some problematic implementation details
> > waldi lined out in the past. Afaik nothing changed, we had several reports
> 
> This is not really true:
> https://salsa.debian.org/salsa-ci-team/pipeline/issues?scope=all=%E2%9C%93=opened_username=waldi
> 
> Out of 12 issues reported by waldi, 8 have been fixed/closed.
> 
> Among the remaining ones:
> 
> - https://salsa.debian.org/salsa-ci-team/pipeline/issues/93
>   (usage of LXC for autopkgtest)
>   is likely the most problematic one even though you never explained
>   what's the real issue... yeah it's virtualization over virtualization
>   and it downloads a root tarball to do its work, but is this worth than
>   downloading a docker image? It uses more resources than direct execution
>   of autopkgtest but it hasn't broken anything so far?
that second level of virtualisation caused problems where people told us they
are not able to do things in their ci jobs. 

*snip*

> > where people telling us things are not possible on our runners. In the end
> > most of them turned out to be limitations of salsa ci. Salsa ci is also
> > not very efficent, therefore the veto. 
> 
> Claims like "salsa ci is not very efficient" are not actionable. Bugs like
> those above are more useful but you should at least take the time to
> respond to queries of people, otherwise no progress can be made.
> 
> I don't think that salsa-ci is particularly problematic in terms of
> "efficiency". With the exception of the LXC usage, there's not much
> that can be "cut" to save resources.
Thats probably true, but if it is inefficent and may cause problems on our
current architecture / ressources - that can't get fixed easily - a veto is
the only thing we have. 

> > We are working on it and after my holidays are over I will plan another
> > sprint for improving salsa. 
> 
> \o/

Alex - forgive the shortness, I am on vacation


signature.asc
Description: PGP signature

Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

[Raphael Hertzog]

On Sat, 28 Dec 2019, Alexander Wirt wrote:
> On Thu, 26 Dec 2019, Otto Kekäläinen wrote:
> 
> > Hello!
> > 
> > I've seen many times before statements like these so I'd like to raise
> > some discussion around the topic:
> > 
> > pe 13. syysk. 2019 klo 16.36 Bastian Blank (wa...@debian.org) kirjoitti:
> > > On Sun, Sep 08, 2019 at 05:35:10PM -0400, Sam Hartman wrote:
> > > > The Salsa CA pipeline is recommended.
> > >
> > > For this I need to use my veto as Salsa admin.  With the CI people we
> > > have to work through too much problems first.
> The salsa ci pipeline itself has some problematic implementation details
> waldi lined out in the past. Afaik nothing changed, we had several reports

This is not really true:
https://salsa.debian.org/salsa-ci-team/pipeline/issues?scope=all=%E2%9C%93=opened_username=waldi

Out of 12 issues reported by waldi, 8 have been fixed/closed.

Among the remaining ones:

- https://salsa.debian.org/salsa-ci-team/pipeline/issues/93
  (usage of LXC for autopkgtest)
  is likely the most problematic one even though you never explained
  what's the real issue... yeah it's virtualization over virtualization
  and it downloads a root tarball to do its work, but is this worth than
  downloading a docker image? It uses more resources than direct execution
  of autopkgtest but it hasn't broken anything so far?

- https://salsa.debian.org/salsa-ci-team/pipeline/issues/94
  (docker images accumulating in forks)
  this one should have improved a lot AFAIK as GitLab now supports what's
  required to remove images from the CI environment too and there's
  WIP on that front (it might even be live without anyone updating that
  bug, I'm not sure)

- https://salsa.debian.org/salsa-ci-team/pipeline/issues/116
  This one is not clear to me. What jobs are using "docker-in-docker"
  without any legitimate use ?

- https://salsa.debian.org/salsa-ci-team/pipeline/issues/121
  (split into source and build)
  This one seems like wishlist and has no real impact on resources as long
  as we build for a single architecture...

> where people telling us things are not possible on our runners. In the end
> most of them turned out to be limitations of salsa ci. Salsa ci is also
> not very efficent, therefore the veto. 

Claims like "salsa ci is not very efficient" are not actionable. Bugs like
those above are more useful but you should at least take the time to
respond to queries of people, otherwise no progress can be made.

I don't think that salsa-ci is particularly problematic in terms of
"efficiency". With the exception of the LXC usage, there's not much
that can be "cut" to save resources.

> We are working on it and after my holidays are over I will plan another
> sprint for improving salsa. 

\o/

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

[Alexander Wirt]

On Thu, 26 Dec 2019, Otto Kekäläinen wrote:

> Hello!
> 
> I've seen many times before statements like these so I'd like to raise
> some discussion around the topic:
> 
> pe 13. syysk. 2019 klo 16.36 Bastian Blank (wa...@debian.org) kirjoitti:
> > On Sun, Sep 08, 2019 at 05:35:10PM -0400, Sam Hartman wrote:
> > > The Salsa CA pipeline is recommended.
> >
> > For this I need to use my veto as Salsa admin.  With the CI people we
> > have to work through too much problems first.
The salsa ci pipeline itself has some problematic implementation details
waldi lined out in the past. Afaik nothing changed, we had several reports
where people telling us things are not possible on our runners. In the end
most of them turned out to be limitations of salsa ci. Salsa ci is also
not very efficent, therefore the veto. 

> There seems to be a conflict between the Salsa admins and users of
> Salsa: the more Salsa is used, the bigger becomes the maintenance
> burden and the more computing resources Salsa needs. There is however
> no inherent growth feedback loop in the system that would increase
> maintenance commitments as usage commitments grow. In economic terms
> one could say that the Salsa admins don't profit from maintaining
> Salsa and as demand grows there is nothing that grows the supply at
> the moment.
> 
> The reason for Salsa popularity to grow all the time is simply because
> it is such a brilliant service and many Debian Developers and aspiring
> new contributors love to use it. Personally I've had all my packages
> on Salsa since early 2018 and I would never want to go back to the mix
> of Github and Alioth I used before. Using Gitlab-CI is nowadays an
> inherent part of my packaging workflow to test contributions before
> merging them and to do QA before uploads. Any disruptions to Salsa
> basically grinds by packaging work to a halt[1], it is so central for
> me nowadays.
> 
> Since Salsa was officially launched in 2018 there has not been any [2]
> new members to the Salsa admins group [3]. Alexander, Joerg and
> Bastian have done a great job maintaining our Gitlab installation. The
> software suite is a beast and keeping it running well is a major
> effort in itself.
> 
> They need help going forward. The sentiment of restricting vital use
> of Salsa is a sign of them trying to keep things under control. But
> Salsa usage needs to grow, as that is good for Debian as a project.
> For the Debian project I think it would be a priority to find more
> resources to the Salsa admin team. I think that would be the ultimate
> solution to the current conflict.
For more performane salsa would need a proper redesign by moving it from its
monolithic system to a more distributed system. In fact we are already
talking about it for some time. But in fact you - the users - should not
think that everything is as easy as just adding some cpus, disks or workers.
Things are often more complicated and - in the end - everything should be
maintainable by DSA too. 

> Personally I cannot commit to maintain Salsa, unfortunately. If Salsa
> is out of computing resources I can however help find more sponsors
> for public runners. But I have the understanding that Google has
> donated plenty of cloud computing time and the root cause is not in
> lack of computing resources, but in the human scalability aspects of
> Salsa operations.
in fact thats only partially true. 

We are working on it and after my holidays are over I will plan another
sprint for improving salsa. 

Things are not always as easy as it seems.

Alex


signature.asc
Description: PGP signature

Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

[Raphael Hertzog]

On Thu, 26 Dec 2019, Otto Kekäläinen wrote:
> I am sure there are many ways to help the team and it is not just
> about Salsa/Gitlab admin stuff, but also about creating structure in
> the team, triaging issues, spreading best practices for users and
> helping the most advanced users to grow into admins of Salsa etc.
> Right now we don't even have any kind of salsa-related discussion list
> on lists.debian.org. Thus I wanted to raise discussion on
> debian-devel. In my opinion Salsa is becoming a very central piece of
> the Debian infrastructure and it should have more attention on
> debian-devel and from the project leader.

+1 on everything you said. (And IMO you should have started a new thread
instead of replying to an old one)

I do hope we can find some constructive way to go forward because the current
settings are now too strict and are effectively hindering big packages
(exactly those that need help!) and some other advanced use of the
service.

I would also like to mention that we should have #salsa or #debian-salsa and
drop #alioth on IRC, sure it made sense at the start to continue to use
the same place as where we used to be but now it just makes it harder
to find the correct place to discuss issues with Salsa.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: help

[Neil McGovern]

Hi!

On Thu, Aug 15, 2019 at 07:09:18PM +, seydi mouhamadou moustapha ndiaye 
wrote:
> I'm a student in computer engineering field from africa and I look for a
> mentor who can  help me to accurate my computer skills mainly on coding.
> 

That's fantastic, it's really good to see new people come along and want
to help out, thank you for your time!

>From what you've said, probably the best way of getting involved in
Debian is through packaging software for inclusion in the distribution.
There are a number of guides that run through this, which are linked
from https://wiki.debian.org/DebianMentorsFaq

If you're not sure on areas that need help, installing the
how-can-i-help package will give you some ideas.

Finally, I would suggest dropping a mail over to the debian-mentors
mailing list, there's a load of people there who can assist you. You can
find that list at http://lists.debian.org/debian-mentors. There's also
support on IRC via the #debian-mentors channel. More information on IRC
can be found at https://wiki.debian.org/IRC

Hope this helps,
Neil

Re: help

[Tomas Pospisek]

Am 15.08.19 um 21:09 schrieb seydi mouhamadou moustapha ndiaye:

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

Learn by doing. Install Debian on your laptop. Then pick a package you
like or that you think could use improvement. Improve it. Send a bug
report with a patch.
*t

Re: Help needed with a script generating a .deb (Done. Now what?)

[Andrey Rahmatullin]

On Tue, Jul 23, 2019 at 08:31:34PM +0200, dettus wrote:
> Now that I am able to create packages What do I do with them?
Read my link again.
Also, the packaging help list is debian-mentors@.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Help needed with a script generating a .deb (Done. Now what?)

[dettus]

Hello.


So, I succeeded!

There are two Warnings left

W: dmagnetic: description-synopsis-starts-with-article
W: dmagnetic: extra-license-file usr/share/doc/dmagnetic/LICENSE.txt

If you do not mind, I would like to keep them. Now that I am able to
create packages What do I do with them?


Thomas


On 7/23/19 7:22 PM, Andrey Rahmatullin wrote:

On Tue, Jul 23, 2019 at 07:19:32PM +0200, dettus wrote:

Running it ends with  the following feedback:




dpkg-buildpackage: info: full upload (original source is included)
Now running lintian...
W: dmagnetic: missing-depends-line
W: dmagnetic: description-synopsis-starts-with-article
W: dmagnetic: spelling-error-in-description allows to allows one to
W: dmagnetic: extra-license-file usr/share/doc/dmagnetic/LICENSE.txt
W: dmagnetic: manpage-has-errors-from-man
usr/share/man/man5/dMagneticini.5.gz 44: warning: macro `RS' not defined
W: dmagnetic: menu-item-creates-new-section Games usr/share/menu/dmagnetic:2
Finished running lintian.
Now signing changes and any dsc files...
  signfile dsc dmagnetic_0.16-1.dsc Thomas Dettbarn 
gpg: skipped "Thomas Dettbarn ": No secret key
gpg: /tmp/debsign.9vHNgUB3/dmagnetic_0.16-1.dsc: clear-sign failed: No
secret key
debsign: gpg error occurred!  Aborting
debuild: fatal error at line 1045:
running debsign failed
patching file Makefile


Any help with the warnings is appreciated...

You can use lintian-info to read the tag descriptions.

Re: Help needed with a script generating a .deb

[Andrey Rahmatullin]

On Tue, Jul 23, 2019 at 07:19:32PM +0200, dettus wrote:
> Running it ends with  the following feedback:
> 
> 
> 
> 
> dpkg-buildpackage: info: full upload (original source is included)
> Now running lintian...
> W: dmagnetic: missing-depends-line
> W: dmagnetic: description-synopsis-starts-with-article
> W: dmagnetic: spelling-error-in-description allows to allows one to
> W: dmagnetic: extra-license-file usr/share/doc/dmagnetic/LICENSE.txt
> W: dmagnetic: manpage-has-errors-from-man
> usr/share/man/man5/dMagneticini.5.gz 44: warning: macro `RS' not defined
> W: dmagnetic: menu-item-creates-new-section Games usr/share/menu/dmagnetic:2
> Finished running lintian.
> Now signing changes and any dsc files...
>  signfile dsc dmagnetic_0.16-1.dsc Thomas Dettbarn 
> gpg: skipped "Thomas Dettbarn ": No secret key
> gpg: /tmp/debsign.9vHNgUB3/dmagnetic_0.16-1.dsc: clear-sign failed: No
> secret key
> debsign: gpg error occurred!  Aborting
> debuild: fatal error at line 1045:
> running debsign failed
> patching file Makefile
> 
> 
> Any help with the warnings is appreciated...
You can use lintian-info to read the tag descriptions.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Help needed with a script generating a .deb

[dettus]

Hello all.


Thanks to your input, I think I am getting closer.
For debian, I created a repository at 
https://github.com/dettus/ports_and_packages/tree/master/Debian



In it, you will find a debian/ subdirectory. In which I put the files 
that seem to be required for

debuild, if I am not mistaken?


You will also find a script called "mkpackage.sh". It takes care of 
downloading the source file

from my website, and creating the .dsc file.

Running it ends with  the following feedback:




dpkg-buildpackage: info: full upload (original source is included)
Now running lintian...
W: dmagnetic: missing-depends-line
W: dmagnetic: description-synopsis-starts-with-article
W: dmagnetic: spelling-error-in-description allows to allows one to
W: dmagnetic: extra-license-file usr/share/doc/dmagnetic/LICENSE.txt
W: dmagnetic: manpage-has-errors-from-man 
usr/share/man/man5/dMagneticini.5.gz 44: warning: macro `RS' not defined

W: dmagnetic: menu-item-creates-new-section Games usr/share/menu/dmagnetic:2
Finished running lintian.
Now signing changes and any dsc files...
 signfile dsc dmagnetic_0.16-1.dsc Thomas Dettbarn 
gpg: skipped "Thomas Dettbarn ": No secret key
gpg: /tmp/debsign.9vHNgUB3/dmagnetic_0.16-1.dsc: clear-sign failed: No 
secret key

debsign: gpg error occurred!  Aborting
debuild: fatal error at line 1045:
running debsign failed
patching file Makefile


Any help with the warnings is appreciated...



Thomas

On 7/23/19 12:26 PM, Ricardo Mones wrote:

Hi Thomas,

On Tue, Jul 23, 2019 at 11:25:40AM +0200, Thomas Dettbarn wrote:

Hello!

So, I have this awesome project, that I am trying to get into the
package repository of Debian. I already filed an RFP, which can be
found at the WNPP bug tracker, where it is gathering dust.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929619

So, I tried my hand at creating a package myself. Since I am a very
lazy person, I try to script my work whenever possible. So why should
there be an exception for the Debian package generation, right? 

[…]

Right, but Debian requirements for those scripts and the environment
where they run are much tighter than yours.

I'd suggest you should start reading https://wiki.debian.org/Packaging
and it's linked pages and perhaps see some examples of current existing
packages in https://salsa.debian.org.

HTH,

Re: Help needed with a script generating a .deb

[Shlomi Fish]

Hi Thomas!

On Tue, 23 Jul 2019 11:25:40 +0200 (CEST)
Thomas Dettbarn  wrote:

> Hello!
> 
> So, I have this awesome project, that I am trying to get into the
> package repository of Debian. I already filed an RFP, which can be
> found at the WNPP bug tracker, where it is gathering dust.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929619
> 
> So, I tried my hand at creating a package myself. Since I am a very
> lazy person, I try to script my work whenever possible. So why should
> there be an exception for the Debian package generation, right? 
> 
> Anyways, the script that is downloading my project, compiles it, and
> creates a .deb file can be found attached to this email, but you can
> also download it at github, at 
> 
> 
> https://github.com/dettus/ports_and_packages/blob/master/Ubuntu/games/dmagnetic/mkpackage.sh
> 

du gives an error, see
https://www.shlomifish.org/Files/files/images/Screenshot_20190723_130648.webp
.

Perhaps use "set -e -x" (or python/etc.). Did you try
https://lintian.debian.org/ yet?


> (Yes, currently I am sitting at a Ubuntu Machine (At work), but I would still
> like to see my project become part of Debian)
> 
> If you could have a look, and tell me what I might have missed, I would very
> VERY much appreciate it.
> 
> Oh, my project is located at http://www.dettus.net/dMagnetic, it is called
> dMagnetic- A Magnetic Scrolls Interpreter, and can be used to play classic
> text adventures such as "The Guild of Thieves" on modern Hardware in any
> terminal window. The graphics are being rendered in ANSI art.
> 
> 
> Thomas Dettbarn



-- 
-
Shlomi Fish   http://www.shlomifish.org/
Funny Anti-Terrorism Story - http://shlom.in/enemy

Doing linear scans over an associative array is like trying to club someone to
death with a loaded Uzi. — Larry Wall

Please reply to list if it's a mailing list post - http://shlom.in/reply .

Re: Help needed with a script generating a .deb

[Andrey Rahmatullin]

We don't use dpkg-deb -b to create packages.

If you want to create a package that can be uploaded to Debian, start with
https://mentors.debian.net/intro-maintainers

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Help request: Contribute to MariaDB 10.3 in Debian efforts

[Otto Kekäläinen]

Hello fellow Debian Developers and those who want to be one!

MariaDB is a big package and it needs help.

I've updated the list of newcomer friendly bugs in
mariadb-10.3:https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no=mariadb-10.3

Perfect for anybody who wants to learn Debian packaging and take their
first steps in contributing to an existing package. I promise to
review everything you send quickly!

The CI has also been updated to extensively test all contributions for
obvious regressions. See an overview of all 10 test steps at
https://salsa.debian.org/mariadb-team/mariadb-10.3/pipelines/37641


> I've spent the last months preparing MariaDB 10.3 for Debian. I am
> almost done, but there are a bunch of smaller issues I need help with.
> I would be glad for anybody who can look into the issues and give
> solution ideas - or even file a merge request on Debian's Gitlab
> instance where the Debian development happens:
> https://wiki.debian.org/Teams/MySQL/patches
>
> Git repository for the packaging:
> https://salsa.debian.org/mariadb-team/mariadb-10.3
>
> Bugs filed against MariaDB in Debian:
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no=mariadb-10.3
>
> There are a few ones tagged newcomer friendly as well!
>
> Build status in Debian (for porters!):
> https://buildd.debian.org/status/package.php?p=mariadb-10.3

Re: Help to ship a better rsync on Buster

[Boyuan Yang]

Hi,

Looks like the new rsync 3.1.3-1 was uploaded yesterday. Thank you all for the
work (and we may have a better rsync in Buster)!

--
Regards,
Boyuan Yang

在 2018-12-24一的 09:14 +0100，Paul Slootman写道：
> Hi Samuel,
> (replying above the message as it's all quite relevant but I don't have
> anything specific to comment on)
> It's true that I have a lot less time nowadays than a couple of years
> ago to spend on Debian, unfortunately. This is becoming more and more
> obvious.
> Feel free to upload a new release with your changes. I'd like to still
> be to "official" maintainer, so I would like to review your stuff first.
> 
> Thanks for your work!
> 
> Paul
> 
> On Sun 23 Dec 2018, Samuel Henrique wrote:
> > It got to my attention the rsync is a little behind our standards wrt to
> > packaging and it looks like the maintainer doesn't have time to deal with
> > that at the moment.
> > 
> > Basically what I want to do is to upload the new release (along with some
> > packaging fixes), adding new Uploaders while keeping the original
> > Maintainer, or maybe moving it to a team while also keeping the original
> > maintainer.
> > 
> > The few changes that I already made:
> >  - Package the last release (which fixes a good amount of bugs and
> > security
> > issues)
> >  - Create a git repo on Salsa and use git for packaging [0]
> >  - Fix d/watch in order to be able to use uscan to download new releases
> > 
> > Things that I would like to have fixed, either for Buster or later:
> >  - Use debhelper with quilt instead of a complex d/rules that manually
> > apply patches
> >  - Use autopkgtests
> >  - Bug triage
> > 
> > I understand that as I'm not familiar with the rsync packaging, some of
> > the
> > things may have been a explicit maintainer choice with a rational behind
> > it, and that could be either spotted by a more experienced Debian
> > Developer, explained by Paul, or discovered when changing it.
> > 
> > Here are the points which leads me to think the maintainer might need help
> > with rsync:
> >  - Last upload of rsync from maintainer was almost 2 years ago
> >  - Last upload of maintainer (any package) was in March 2017
> >  - There were two NMUs after that
> >  - There is an open bug (#906895) since January asking for packaging of
> > the
> > new release, without replies from maintainer[1]
> >  - A lot of open bugs, 74 as of now.
> > 
> > On a side note, I can see that there was recent (August 2018) email
> > activity from Paul, so hopefully he may reply something about this.
> > 
> > Overall, I can see that rsync is not a simple package to deal with, Paul
> > having made a great job for many years all by himself, I would like to
> > receive help with that so we all can ship a better rsync on Buster :)
> > 
> > The transition freeze is for 12th January of 2019, so we would need to
> > upload this new release asap, in order to account for time to fix any RC
> > bug that may show up before the new release enters Testing. We can also
> > pick which changes we want to ship for Buster and which ones we want to
> > upload to experimental because we don't wanna risk introducing bugs that
> > close to the freeze.
> > 
> > Thanks,
> > 
> > [0]https://salsa.debian.org/debian/rsync
> > [1]https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906895
> > 
> > 
> >  --
> > Samuel Henrique 


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

Re: Help to ship a better rsync on Buster

[Paul Slootman]

Hi Samuel,
(replying above the message as it's all quite relevant but I don't have
anything specific to comment on)
It's true that I have a lot less time nowadays than a couple of years
ago to spend on Debian, unfortunately. This is becoming more and more
obvious.
Feel free to upload a new release with your changes. I'd like to still
be to "official" maintainer, so I would like to review your stuff first.

Thanks for your work!

Paul

On Sun 23 Dec 2018, Samuel Henrique wrote:
> 
> It got to my attention the rsync is a little behind our standards wrt to
> packaging and it looks like the maintainer doesn't have time to deal with
> that at the moment.
> 
> Basically what I want to do is to upload the new release (along with some
> packaging fixes), adding new Uploaders while keeping the original
> Maintainer, or maybe moving it to a team while also keeping the original
> maintainer.
> 
> The few changes that I already made:
>  - Package the last release (which fixes a good amount of bugs and security
> issues)
>  - Create a git repo on Salsa and use git for packaging [0]
>  - Fix d/watch in order to be able to use uscan to download new releases
> 
> Things that I would like to have fixed, either for Buster or later:
>  - Use debhelper with quilt instead of a complex d/rules that manually
> apply patches
>  - Use autopkgtests
>  - Bug triage
> 
> I understand that as I'm not familiar with the rsync packaging, some of the
> things may have been a explicit maintainer choice with a rational behind
> it, and that could be either spotted by a more experienced Debian
> Developer, explained by Paul, or discovered when changing it.
> 
> Here are the points which leads me to think the maintainer might need help
> with rsync:
>  - Last upload of rsync from maintainer was almost 2 years ago
>  - Last upload of maintainer (any package) was in March 2017
>  - There were two NMUs after that
>  - There is an open bug (#906895) since January asking for packaging of the
> new release, without replies from maintainer[1]
>  - A lot of open bugs, 74 as of now.
> 
> On a side note, I can see that there was recent (August 2018) email
> activity from Paul, so hopefully he may reply something about this.
> 
> Overall, I can see that rsync is not a simple package to deal with, Paul
> having made a great job for many years all by himself, I would like to
> receive help with that so we all can ship a better rsync on Buster :)
> 
> The transition freeze is for 12th January of 2019, so we would need to
> upload this new release asap, in order to account for time to fix any RC
> bug that may show up before the new release enters Testing. We can also
> pick which changes we want to ship for Buster and which ones we want to
> upload to experimental because we don't wanna risk introducing bugs that
> close to the freeze.
> 
> Thanks,
> 
> [0]https://salsa.debian.org/debian/rsync
> [1]https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906895
> 
> 
>  --
> Samuel Henrique 


signature.asc
Description: PGP signature

Re: HELP WANTED: security review / pam experts for su transition

[Julien Cristau]

On 08/12/2018 04:58 PM, Andreas Henriksson wrote:
> Hello again,
> 
> My previous mail didn't result in any feedback, so let me try again
> with some more detailed questions that might be easier to discuss
> related to the PAM configuration of su (and su-l).
> 
FWIW I'm not sure -devel is very likely to be read by the people who'd
have useful input for you, you may want to reach out to a more narrow
list or group of people instead.

For what it's worth, I don't think pam_xauth is a good idea in the su
pam config.  (I don't think copying DISPLAY and XAUTHORITY was, either.)

Cheers,
Julien

Re: HELP WANTED: security review / pam experts for su transition

[Andreas Henriksson]

Hello again,

My previous mail didn't result in any feedback, so let me try again
with some more detailed questions that might be easier to discuss
related to the PAM configuration of su (and su-l).

As people are likely aware, the su takeover has now happened and
login (src:shadow) no longer ships su in favour of it being shipped
in util-linux (src:util-linux) instead.

The /etc/pam.d/su configuration was carried over directly from
the old src:shadow (login) su, and might be less then ideal for
the util-linux su implementation. The new /etc/pam.d/su-l configuration
didn't exist before, but mostly just includes the su pam config for now.
Mainly mentioning su-l because we have the option to differentiate
between what pam config we want for 'su -' vs 'su'.

1/
One new issue that has bitten some people is that shadow su used to,
even when you ask for a new clean environment, still copy over
DISPLAY and XAUTHORITY. Apparently some people relied on that even
though X doesn't really give you any real privileges separation.
On fedora the su pam configuration includes pam_xauth which I assume
should solve the same problem. Should we add pam_xauth to /etc/pam.d/su
as well? (For now it's just mentioned in util-linux.NEWS and left to the
user to edit the pam configuration as they find suitable, but if we
can't even figure out the right choice I doubt users will.)

2/
There are some longstanding issues with the pam configuration which
existed before the switch, but seems reasonable to adress still.
For example #711104 asks for 'su -' to reset umask. Should we
include pam_umask? Maybe even in /etc/pam.d/su so both 'su' and 'su -'
gets umask reset?
cf. how the carried over /etc/pam.d/su already contains pam_limits.

3/
The fedora pam configuration seems to contain several more differences.
Anyone interested in investigating and comparing them? Possibly our
ancient su pam config should get a complete overhaul, rather than just
poking at details one by one.


Regards,
Andreas Henriksson

Re: Help: gpb buildpackage no longer builds

[Steve Robbins]

On Sunday, April 8, 2018 1:36:50 PM CDT Emilio Pozuelo Monfort wrote:

> Which version of debhelper are you building with? 

11.2

> The cmake support was
> recently broken and just fixed in debhelper 11.2.1, so make sure you get
> that.

Thanks for the tip!  I'll upgrade and try again.
-Steve



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

Re: Help: gpb buildpackage no longer builds

[Emilio Pozuelo Monfort]

On 08/04/18 20:25, Steve Robbins wrote:
> In the last upload of googletest -- December 2016 -- I successfully used "gbp 
> buildpackage".  Today, with zero changes, it fails to actually do the build: 
> it skips from configuration to running tests.
> 
> The rules file [1] is, I think, pretty simple: there are overrides for  
> dh_auto_configure , _test, _install, and _clean; nothing else.  Am I missing 
> something?
> 
> [1] https://salsa.debian.org/debian/googletest/blob/master/debian/rules

Which version of debhelper are you building with? The cmake support was recently
broken and just fixed in debhelper 11.2.1, so make sure you get that.

Cheers,
Emilio

Re: Help with install of debian stretch

[Steve McIntyre]

boods...@yahoo.com
>
>I'm a newbie at Debian Linux and trying mybest but when I'm
>installing Debian-9.1.0-i386-netinst, I get to a screenthat's asking
>me to insert the disc labeled: 'Debian GNU/Linux 9.1.0
>_Stretch_-official i386 NETINST 20170722-12:43" in the
>'/media/cdrom/" andpress [Enter] I've looked everywhere and I can't
>find this iso todownload and burn to a disc. Please point me in the
>right direction.

Hi Bill,

You'd be better off asking for support on the debian-user list in
future (in CC).

I'm curious how you've managed to get to that message - if you're
installing from debian-9.1.0-i386-netinst, that's exactly the disc the
system is asking for. How have you done your installation, please?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
< sladen> I actually stayed in a hotel and arrived to find a post-it
  note stuck to the mini-bar saying "Paul: This fridge and
  fittings are the correct way around and do not need altering"

Re: Help, I broke sso.debian.org for chrome - Found reason

[Enrico Zini]

On Wed, Sep 06, 2017 at 01:36:55PM +0200, Enrico Zini wrote:

> I found the reason: python-cryptography writes the certificate issuer
> as UTF8 String while the CA certificate has it as Printable String.
> Because of that, the subject names don't match bit-by-bit.

Fixed:
https://anonscm.debian.org/cgit/debian-sso/debian-sso.git/commit/?id=39280a19fd00493580d840dc2fff89ecc8461e5b

Thanks to reaperhulk on #cryptography-dev for the help with making that
workaround work.


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Re: Help, I broke sso.debian.org for chrome - Found reason

[Bjørn Mork]

Enrico Zini  writes:

> On Tue, Sep 05, 2017 at 11:37:01AM +0200, Enrico Zini wrote:
>
>> I refactored the certificate generation code for sso.debian.org, and the
>> certificates it generates now still work in Firefox but not in Chrome.
>
> I found the reason: python-cryptography writes the certificate issuer
> as UTF8 String while the CA certificate has it as Printable String.
> Because of that, the subject names don't match bit-by-bit.
>
> For openssl, encoding does not matter for comparison, while for libnss3
> it does.
>
> I do not know if this is:
>
>  - a bug in openssl, which should be stricter in matching
>  - a bug in libnss3, which should deal with encodings
>  - a bug in python3-cryptography, which should do a bit-for-bit copy
>when copying attributes over:
>
> https://anonscm.debian.org/cgit/debian-sso/debian-sso.git/tree/ca/ca.py#n429

Disclaimer:  I don't know the first thing about this...

But reading

 https://tools.ietf.org/html/rfc5280#section-4.1.2.4
 https://tools.ietf.org/html/rfc5280#section-7.1

and

 https://tools.ietf.org/html/rfc4518#section-2

which the first refers to, I believe this must be a libnss3 bug.

PrintableString and UTF8String are both allowed encodings, and RFC5280
is pretty clear about name comparisons:

   Conforming implementations MUST use the LDAP StringPrep profile
   (including insignificant space handling), as specified in [RFC4518],
   as the basis for comparison of distinguished name attributes encoded
   in either PrintableString or UTF8String.  Conforming implementations
   MUST support name comparisons using caseIgnoreMatch.  Support for
   attribute types that use other equality matching rules is optional.




Bjørn

Re: Help, I broke sso.debian.org for chrome - Found reason

[Enrico Zini]

On Wed, Sep 06, 2017 at 01:36:55PM +0200, Enrico Zini wrote:
> On Tue, Sep 05, 2017 at 11:37:01AM +0200, Enrico Zini wrote:
> 
> > I refactored the certificate generation code for sso.debian.org, and the
> > certificates it generates now still work in Firefox but not in Chrome.
> 
> I found the reason: python-cryptography writes the certificate issuer
> as UTF8 String while the CA certificate has it as Printable String.
> Because of that, the subject names don't match bit-by-bit.

Massive, massive thanks to Luca Filipozzi for assistance!


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Re: Help, I broke sso.debian.org for chrome - Found reason

[Enrico Zini]

On Tue, Sep 05, 2017 at 11:37:01AM +0200, Enrico Zini wrote:

> I refactored the certificate generation code for sso.debian.org, and the
> certificates it generates now still work in Firefox but not in Chrome.

I found the reason: python-cryptography writes the certificate issuer
as UTF8 String while the CA certificate has it as Printable String.
Because of that, the subject names don't match bit-by-bit.

For openssl, encoding does not matter for comparison, while for libnss3
it does.

I do not know if this is:

 - a bug in openssl, which should be stricter in matching
 - a bug in libnss3, which should deal with encodings
 - a bug in python3-cryptography, which should do a bit-for-bit copy
   when copying attributes over:
   https://anonscm.debian.org/cgit/debian-sso/debian-sso.git/tree/ca/ca.py#n429

Please help me report the bugs, while I try to implement a workaround on
sso.debian.org.


I'm attaching a test case that reproduces the issue. Unpack the tarball
and run ./test to reproduce. This is the output of a run:

  $ ./test 
  + trap cleanup EXIT
  + cleanup
  + rm -fr newcerts
  + rm -f index.txt index.txt.attr serial '*.old'
  + certtool -p --outfile=testkey.pem
  + certtool --load-privkey=testkey.pem -s --outfile=testcrt.pem 
--template=testcrt.conf
  + mkdir -p newcerts
  + touch index.txt
  + touch index.txt.attr
  + openssl genrsa -out client.key 2048
  + openssl req -new -sha256 -key client.key -batch
  + openssl ca -batch -config testca.conf -in client.csr -create_serial -days 7 
-keyfile testkey.pem -cert testcrt.pem -out client.crt
  + openssl verify -CAfile testcrt.pem client.crt
  client.crt: OK
  + certtool --load-ca-certificate testcrt.pem --verify --infile client.crt
  Loaded 1 certificates, 1 CAs and 0 CRLs
  
Subject: O=Internet Widgits Pty Ltd
Issuer: O=Test client certificate,CN=Test CA 2017-09-06
Checked against: O=Test client certificate,CN=Test CA 2017-09-06
Output: Verified. The certificate is trusted. 
  
  Chain verification output: Verified. The certificate is trusted. 
  
  + ./utf8ize --crt testcrt.pem --key testkey.pem testcrtutf8.pem
  + openssl x509 -noout -nameopt multiline,show_type -subject -issuer -in 
testcrt.pem
  subject=
  commonName= PRINTABLESTRING:Test CA 2017-09-06
  organizationName  = PRINTABLESTRING:Test client certificate
  issuer=
  commonName= PRINTABLESTRING:Test CA 2017-09-06
  organizationName  = PRINTABLESTRING:Test client certificate
  + openssl x509 -noout -nameopt multiline,show_type -subject -issuer -in 
testcrtutf8.pem
  subject=
  commonName= UTF8STRING:Test CA 2017-09-06
  organizationName  = UTF8STRING:Test client certificate
  issuer=
  commonName= UTF8STRING:Test CA 2017-09-06
  organizationName  = UTF8STRING:Test client certificate
  + openssl verify -CAfile testcrtutf8.pem client.crt
  client.crt: OK
  + certtool --load-ca-certificate testcrtutf8.pem --verify --infile client.crt
  Loaded 1 certificates, 1 CAs and 0 CRLs
  
Subject: O=Internet Widgits Pty Ltd
Issuer: O=Test client certificate,CN=Test CA 2017-09-06
Output: Not verified. The certificate is NOT trusted. The certificate 
issuer is unknown. 
  
Subject: O=Internet Widgits Pty Ltd
Issuer: O=Test client certificate,CN=Test CA 2017-09-06
Output: Not verified. The certificate is NOT trusted. The certificate 
issuer is unknown. 
  
  Chain verification output: Not verified. The certificate is NOT trusted. The 
certificate issuer is unknown. 
  
  + cleanup
  + rm -fr newcerts
  + rm -f index.txt index.txt.attr serial index.txt.attr.old index.txt.old


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


testcase.tar.xz
Description: application/xz


signature.asc
Description: PGP signature

Re: Help, I broke sso.debian.org for chrome

[Anthony DeRobertis]

On Tue, Sep 05, 2017 at 02:08:38PM +0100, Ian Jackson wrote:
> 
> FYI, Enrico, the openssl CLI tool can dump this kind of thing so you
> can compare before and after.  I forget the exact runes I'm afraid.

openssl x509 -in <> -noout -text

is probably the magic line you're looking for.

Re: Help needed for #871234 FTBFS with GCC-7: error: type/value mismatch

[Alex Mestiashvili]

On Tue, Sep 5, 2017 at 8:44 PM, Jeff Epler  wrote:

> On Tue, Sep 05, 2017 at 01:55:58PM +0200, Alex Mestiashvili wrote:
> > GHash.hh:91:44: error: type/value mismatch at argument 1 in template
> > parameter list for 'template struct std::hash'
> >  while (pos
> Nothing in this line is intended to be a template parameter list, but it
> looks like gcc has decided something is; maybe it's "hash", which the
> compiler treats as std::hash due to e.g., an earlier "using" statement.
>
> If so, consider trying
>while (pos^ parenthesize ^
> so that the "<" can't introduce a template parameter list.
>
> My mental model of the C++ grammar doesn't explain to me why the
> compiler thinks this "<" can introduce a template parameter list, but
> that sure seems to be what the compiler states it is doing.  Usually
> when g++ and I disagree about C++ grammar, g++ is right...
>
> Jeff
>

Great! this solved the problem. Thank you very much!

Alex

Re: Help needed for #871234 FTBFS with GCC-7: error: type/value mismatch

[Jeff Epler]

On Tue, Sep 05, 2017 at 01:55:58PM +0200, Alex Mestiashvili wrote:
> GHash.hh:91:44: error: type/value mismatch at argument 1 in template
> parameter list for 'template struct std::hash'
>  while (pos

Re: Help, I broke sso.debian.org for chrome

[Christoph Berg]

Re: Enrico Zini 2017-09-05 <20170905163334.2mi5tzacykzja...@enricozini.org>
> I should have managed to do it, but chrome still doesn't seem to like
> it. Can you generate a new certificate and see if you still find
> differences?

"openssl x509 -text -noout" doesn't show any differences anymore
except for the obvious parts (serial, validity, modulus and sig algo).

One bit that might or might not be relevant is that the CA certificate
was re-issued on Aug 3rd:

/srv/sso.debian.org/etc $ openssl x509 -text -noout < debsso.crt 
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN = SSO CA 2015-08-21, O = Debian SSO client certificate
Validity
Not Before: Aug  3 06:08:36 2017 GMT
Not After : Dec 31 23:59:59  GMT
Subject: CN = SSO CA 2015-08-21, O = Debian SSO client certificate
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:d5:25:0c:36:21:15:32:5c:9c:c0:33:e5:26:18:
...
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
X509v3 Subject Key Identifier: 
D0:E2:7E:26:81:E0:CD:AA:CB:34:5F:B6:7A:26:B2:D7:51:82:93:8E
X509v3 CRL Distribution Points: 

Full Name:
  URI:https://sso.debian.org/spkac/ca.crl

Signature Algorithm: sha256WithRSAEncryption
 1c:4c:87:05:8d:51:79:04:7e:c5:a5:9a:4f:bf:15:1b:ee:b1:
 ...

This file is the one distributed to participating servers, so if
there's something wrong, it will have "infected" the other hosts as
well. I can't see anything wrong there either, though...

Starting with a blank chromium config (.config/chromium + .pki/nssdb)
and importing the client there doesn't help either.

Christoph

Re: Help, I broke sso.debian.org for chrome

[Enrico Zini]

On Tue, Sep 05, 2017 at 12:16:47PM +0200, Christoph Berg wrote:

> My guess is that the new-style certificates are missing some
> attributes:
> 
> Old certificate from 2015:
> 
> X509v3 extensions:
> X509v3 Basic Constraints: critical
> CA:FALSE
> X509v3 Key Usage: critical
> Digital Signature, Key Encipherment, Key Agreement
> X509v3 Extended Key Usage: 
> TLS Web Client Authentication
> 
> New certificate from this week:
> 
> X509v3 extensions:
> X509v3 Subject Alternative Name: 
> email:m...@debian.org
> X509v3 Basic Constraints: critical
> CA:FALSE
> 
> I'll see if I can add that.

I should have managed to do it, but chrome still doesn't seem to like
it. Can you generate a new certificate and see if you still find
differences?


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Re: Help needed for #871234 FTBFS with GCC-7: error: type/value mismatch

[Juhani Numminen]

Hi Alex!

Alex Mestiashvili kirjoitti 05.09.2017 klo 14:55:

parameter list for 'template struct std::hash'
  while (pos
I think the problem is we don't want std::hash but GHash::hash and
GHash::GHashEntry::hash.
(Sorry, I haven't looked deeper into how to get the correct 'hash'.)

Cheers,
Juhani

Re: Help, I broke sso.debian.org for chrome

[Tim Rühsen]

 


With Best Regards, Tim



On 09/05/2017 03:08 PM, Ian Jackson wrote:
> Christoph Berg writes ("Re: Help, I broke sso.debian.org for chrome"):
>> Re: Enrico Zini 2017-09-05 <20170905093701.xncmprl2x4so6...@enricozini.org>
>>> I refactored the certificate generation code for sso.debian.org, and the
>>> certificates it generates now still work in Firefox but not in Chrome.
>>
>> My guess is that the new-style certificates are missing some
>> attributes:
>>
>> Old certificate from 2015:
>>
>> X509v3 extensions:
>> X509v3 Basic Constraints: critical
>> CA:FALSE
>> X509v3 Key Usage: critical
>> Digital Signature, Key Encipherment, Key Agreement
>> X509v3 Extended Key Usage: 
>> TLS Web Client Authentication
> 
> This last one seems like it ought to be there.  I don't know about the
> Key Usage.
> 
> IIRC there are ways to get the openssl CLI to add specific extenstions
> but I don't know how to do that in the API Enrico is using in sso.
> 
> FYI, Enrico, the openssl CLI tool can dump this kind of thing so you
> can compare before and after.  I forget the exact runes I'm afraid.

Or GnuTLS's certtool:

certtool -i --infile tests/certs/x509-ca-cert.pem

Regards, Tim



signature.asc
Description: OpenPGP digital signature

Re: Help, I broke sso.debian.org for chrome

[Ian Jackson]

Christoph Berg writes ("Re: Help, I broke sso.debian.org for chrome"):
> Re: Enrico Zini 2017-09-05 <20170905093701.xncmprl2x4so6...@enricozini.org>
> > I refactored the certificate generation code for sso.debian.org, and the
> > certificates it generates now still work in Firefox but not in Chrome.
> 
> My guess is that the new-style certificates are missing some
> attributes:
> 
> Old certificate from 2015:
> 
> X509v3 extensions:
> X509v3 Basic Constraints: critical
> CA:FALSE
> X509v3 Key Usage: critical
> Digital Signature, Key Encipherment, Key Agreement
> X509v3 Extended Key Usage: 
> TLS Web Client Authentication

This last one seems like it ought to be there.  I don't know about the
Key Usage.

IIRC there are ways to get the openssl CLI to add specific extenstions
but I don't know how to do that in the API Enrico is using in sso.

FYI, Enrico, the openssl CLI tool can dump this kind of thing so you
can compare before and after.  I forget the exact runes I'm afraid.

Ian.

Re: Help, I broke sso.debian.org for chrome

[Christoph Berg]

Re: Enrico Zini 2017-09-05 <20170905093701.xncmprl2x4so6...@enricozini.org>
> I refactored the certificate generation code for sso.debian.org, and the
> certificates it generates now still work in Firefox but not in Chrome.

My guess is that the new-style certificates are missing some
attributes:

Old certificate from 2015:

X509v3 extensions:
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Key Usage: critical
Digital Signature, Key Encipherment, Key Agreement
X509v3 Extended Key Usage: 
TLS Web Client Authentication

New certificate from this week:

X509v3 extensions:
X509v3 Subject Alternative Name: 
email:m...@debian.org
X509v3 Basic Constraints: critical
CA:FALSE

I'll see if I can add that.

Christoph

Re: Help me

[Paul Wise]

On Sat, Jun 17, 2017 at 12:05 AM, МБУЗ ГКБ № 1 wrote:

> Hi no work in Debian 8.8
> No start firebird 2.5 classic and super error

Please contact our support channels for help diagnosing the error:

https://www.debian.org/support

Once you have diagnosed where the problem is, you can report a bug:

https://www.debian.org/Bugs/Reporting

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Help requested: Packages which FTBFS randomly

[Simon McVittie]

On Thu, 23 Feb 2017 at 10:02:55 -0800, Nikolaus Rath wrote:
> Yes, but last time I checked a "apt-get source && debuild -us -uc" still
> defaults to using just a single CPU unless you explicitly set
> DEB_BUILD_OPTIONS=parallel.

Check again - dpkg-buildpackage now defaults to -Jauto
(it sets DEB_BUILD_OPTIONS=parallel=n where n is the detected number of
CPUs), on the basis that every Debian buildd already seems to set
parallel >= 2, so any package that fails to build in that situation is
already effectively unreleasable. (#842845)

If you maintain packages where this can't work, use dh --no-parallel
or put .NOPARALLEL: in your Makefile.

S

Re: Help requested: Packages which FTBFS randomly

[Vincent Bernat]

 ❦ 23 février 2017 10:02 -0800, Nikolaus Rath  :

 Your chosen build environment is not common [...]
>>>
>>> This has come up a few times now. Could someone explain what is so odd
>>> about his envirnoment? It does not look unusual to me.
>>
>> Official buildd have several CPU. Most "important" downstream
>> distribution builders have several CPU. [...]
>
> Yes, but last time I checked a "apt-get source && debuild -us -uc" still
> defaults to using just a single CPU unless you explicitly set
> DEB_BUILD_OPTIONS=parallel. So if this causes the build to fail, it will
> directly affect those users least able to figure out what may be
> wrong.

When the build system is not make-based, it doesn't care for this option
(for example, Go programs compile using all the available
cores). Moreover, tests can do whatever they want.
-- 
Extreme fear can neither fight nor fly.
-- William Shakespeare, "The Rape of Lucrece"


signature.asc
Description: PGP signature

Re: Help requested: Packages which FTBFS randomly

[Nikolaus Rath]

On Feb 21 2017, Vincent Bernat  wrote:
>  ❦ 21 février 2017 09:48 -0800, Nikolaus Rath  :
>
>>> Your chosen build environment is not common [...]
>>
>> This has come up a few times now. Could someone explain what is so odd
>> about his envirnoment? It does not look unusual to me.
>
> Official buildd have several CPU. Most "important" downstream
> distribution builders have several CPU. [...]

Yes, but last time I checked a "apt-get source && debuild -us -uc" still
defaults to using just a single CPU unless you explicitly set
DEB_BUILD_OPTIONS=parallel. So if this causes the build to fail, it will
directly affect those users least able to figure out what may be wrong.

> Accomodating for all build environments is a slippery slope.

In my opinion there is a big difference between asking builds to work
with a single CPU, and supporting "all build environments".


Best,
-Nikoalus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Re: Help requested: Packages which FTBFS randomly

[Simon McVittie]

On Tue, 21 Feb 2017 at 23:35:44 +, Ben Hutchings wrote:
> Having said that, some ioctls that make sense for block-backed
> filesystems, such as FS_IOC_FIEMAP, won't work on a tmpfs (or nfs,
> ubifs, etc.).

One notable omission is that tmpfs doesn't do generic "user." extended
attributes (due to worries about quota control), which results in ostree's
tests preferring /var/tmp over /tmp, and skipping many of the tests if
/var/tmp is a tmpfs too.

S

Re: Help requested: Packages which FTBFS randomly

[Vincent Bernat]

 ❦ 22 février 2017 00:46 +0100, Adam Borowski  :

>> > > * using a qemu build chroot (Debian doesn't do this, other might)
>> > 
>> > Is that because QEMU is slow, or some other reason?
>> 
>> AIUI qemu(-static) cannot handle threading very well. So if a build
>> process uses such applications, things turn bad. Typical observation was
>> msgmerge stuck in an endless loop at 100% CPU. Lesson learned: There is
>> a reason why Debian builds do not use emulation.
>
> That's qemu-user.  On the other hand, qemu-system, while nowhere as
> convenient, is safe and reliable.  Its bugs don't exceed the differences
> between revisions of real hardware.

It doesn't emulate correctly inability of some architectures to do
unaligned memory accesses.
-- 
Make it right before you make it faster.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Help requested: Packages which FTBFS randomly

[Ben Hutchings]

On Tue, 2017-02-21 at 14:18 -0700, Sean Whitton wrote:
> On Tue, Feb 21, 2017 at 02:37:23AM +, Ben Hutchings wrote:
> > > * with /tmp on tmpfs on some archs
> > 
> > [...]
> > 
> > You mean the 64-bit PowerPC architectures?  tmpfs allocates at
> > least a
> > page per file, and they have 64K pages...
> 
> I'm not sure why you're mentioned powerpc archs, but as a hopefully
> relevant data point, two of my arch:all packages FTBFS when / is a
> tmpfs.  There are some weird permissions errors from the test suites.

That sounds like a kernel bug - tmpfs is meant to implement permissions
(including ACLs) just like a "normal" filesystem (e.g. ext4).

Having said that, some ioctls that make sense for block-backed
filesystems, such as FS_IOC_FIEMAP, won't work on a tmpfs (or nfs,
ubifs, etc.).

Ben.

-- 
Ben Hutchings
73.46% of all statistics are made up.



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

Re: Help requested: Packages which FTBFS randomly

[Adam Borowski]

On Tue, Feb 21, 2017 at 11:04:52PM +0100, Christoph Biedl wrote:
> > > * using a qemu build chroot (Debian doesn't do this, other might)
> > 
> > Is that because QEMU is slow, or some other reason?
> 
> AIUI qemu(-static) cannot handle threading very well. So if a build
> process uses such applications, things turn bad. Typical observation was
> msgmerge stuck in an endless loop at 100% CPU. Lesson learned: There is
> a reason why Debian builds do not use emulation.

That's qemu-user.  On the other hand, qemu-system, while nowhere as
convenient, is safe and reliable.  Its bugs don't exceed the differences
between revisions of real hardware.


Meow!
-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11

Re: Help requested: Packages which FTBFS randomly

[Christoph Biedl]

Ben Hutchings wrote...

> > * when using eatmydata
> 
> I can certainly think of a test case that would be broken by eatmydata
> and I would not want to rule out such test cases.  But still, I am
> suprised by this.

#667965 - don't know whether this still exists. I later decided to patch
dpkg so "unsafe-io" skips *all* calls to *sync. This also works better
in mixed-arch environments.

> > * on sbuild using overlayfs
> 
> overlayfs is sadly quite a way from being a POSIX-compliant filesystem.
>  So it seems unreasonable to expect every package to be buildable in
> such a build environment.

Indeed. That's why I'm asking for such a hint file: It would allow me to
switch to a more expensive build mode, but a mode that makes the build
pass.

> > * using a qemu build chroot (Debian doesn't do this, other might)
> 
> Is that because QEMU is slow, or some other reason?

AIUI qemu(-static) cannot handle threading very well. So if a build
process uses such applications, things turn bad. Typical observation was
msgmerge stuck in an endless loop at 100% CPU. Lesson learned: There is
a reason why Debian builds do not use emulation.

Christoph


signature.asc
Description: Digital signature

Re: Help requested: Packages which FTBFS randomly

[Christoph Biedl]

Sean Whitton wrote...

> I'm not sure why you're mentioned powerpc archs

Because that's a surprising feature of that arch and once you've
realized you were caught by this, you will not forget it. Bonus:
Rebuilding on a porter box passes since /home is not a tmpfs.

Christoph

PS: 
https://sources.debian.net/patches/logrotate/3.11.0-0.1/fix-test-pagesize.patch/


signature.asc
Description: Digital signature

Re: Help requested: Packages which FTBFS randomly

[Sean Whitton]

On Tue, Feb 21, 2017 at 02:37:23AM +, Ben Hutchings wrote:
> > * with /tmp on tmpfs on some archs
> [...]
> 
> You mean the 64-bit PowerPC architectures?  tmpfs allocates at least a
> page per file, and they have 64K pages...

I'm not sure why you're mentioned powerpc archs, but as a hopefully
relevant data point, two of my arch:all packages FTBFS when / is a
tmpfs.  There are some weird permissions errors from the test suites.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Help requested: Packages which FTBFS randomly

[Santiago Vila]

On Tue, Feb 21, 2017 at 09:36:58PM +0100, Vincent Bernat wrote:

> Accomodating for all build environments is a slippery slope. What if I
> use a 128MB host with 64GB of swap? Timing-related tests will start to
> fail. Is it Debian job to fix all the test suites? Should I be able to
> build packages on a system not supporting ACL? On a kernel not
> supporting users? On a grsec kernel? With a low ulimit value for the
> number of opened files or on the stack size? On a chroot on an Android
> phone? On the Windows Subsystem for Linux?

I don't really have a problem with multi-core being the only supported
build setup in some distant future, but if such thing ever happens, it
should be because Debian decides it, either the Release Managers at
the start of a release cycle (not at the end), or the Debian
Developers as a whole by way of a General Resolution.

The current scenario where some maintainers think they have the power
to decide about this on their own for their own packages is not
acceptable at all.

Having said that, there are practical reasons why we should keep
support for single-CPU build systems, for example, you can split the
work better if you have a build farm and you can save real money.

Also, the number of packages that we have to fix to support this is
still extremely small, and most of them have been fixed as they have
been reported. The number of packages in stretch which are not
buildable on a single-CPU system may be counted with the fingers of
just one hand.

Nothing to do with the number of problems that would arise if you use
a 128MB host with 64GB of swap or any of the really weird things you
mention. Really, building with a single CPU is not a sin, and people
should not be punished for doing so.

Thanks.

Re: Help requested: Packages which FTBFS randomly

[Vincent Bernat]

 ❦ 21 février 2017 09:48 -0800, Nikolaus Rath  :

>> Your chosen build environment is not common [...]
>
> This has come up a few times now. Could someone explain what is so odd
> about his envirnoment? It does not look unusual to me.

Official buildd have several CPU. Most "important" downstream
distribution builders have several CPU. Your own personal
laptop/workstation have several CPU. Free CI environments usually have
several CPU (eg. Travis CI). Private CI usually have several CPU
(eg. jenkins.debian.net, debomatic).

Just checked with Ubuntu, ri-li builds successfully and reliably on
their platform. Moreover, I don't think we ever had downstream
distributions complained about the inability to compile packages. From
my point of view, we are told to fix bugs that don't affect our users.

Accomodating for all build environments is a slippery slope. What if I
use a 128MB host with 64GB of swap? Timing-related tests will start to
fail. Is it Debian job to fix all the test suites? Should I be able to
build packages on a system not supporting ACL? On a kernel not
supporting users? On a grsec kernel? With a low ulimit value for the
number of opened files or on the stack size? On a chroot on an Android
phone? On the Windows Subsystem for Linux?
-- 
Use variable names that mean something.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Help requested: Packages which FTBFS randomly

[Nikolaus Rath]

> Your chosen build environment is not common [...]


This has come up a few times now. Could someone explain what is so odd
about his envirnoment? It does not look unusual to me.


Best,
-Nikolaus
-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Re: Help requested: Packages which FTBFS randomly

[Ben Hutchings]

On Tue, 2017-02-21 at 11:50 +0800, Paul Wise wrote:
> On Tue, Feb 21, 2017 at 6:36 AM, Christoph Biedl wrote:
> 
> > This is a charming idea altough I have doubt it will work out: As
> > usual the information has to be kept up-to-date, so unless it is
> > collected and verified every now and then automatically, it will
> > become unsuable pretty soon.
> 
> FYI the buildds are automatically collecting disk usage information,
> see the last line of each build log.
> 
> Of course, that information isn't parsed and stored anywhere yet.
> 
> I guess collecting memory usage would be much harder, especially if
> multiple packages are built in parallel.

I think that can be done by putting each build in its own memory
controller cgroup (with high limits, at least for now).

Ben.

-- 
Ben Hutchings
73.46% of all statistics are made up.



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

Re: Help requested: Packages which FTBFS randomly

[Holger Levsen]

On Mon, Feb 20, 2017 at 04:42:49PM -0800, Russ Allbery wrote:
> To say my opinion explicitly, since there's been a lot of discussion here,
> some of which I've been involved in somewhat ambiguously:
 
Thanks for writing this up, Russ. I fully agree with *everything* you said here:

> I think this is a reasonably short and workable list of bugs, and I think
> the *default* assumption should be that any FTBFS, even intermittant, is
> RC.  This is both for fundamental reasons for what we're trying to achieve
> as a free software distribution that's modifyable and rebuildable by our
> users, and for practical reasons to support further development of our
> packages (including security fixes).
> 
> We already have an exception mechanism for handling bugs that shouldn't be
> RC for the current release because the actual impact of the bug turns out
> to be minor for some reason, or because they would have too negative of an
> impact on the release.  Normally, how we handle this is to mark the bugs
> with an RC severity (serious in this case), and then, if the release team
> feels this package warrants a special exception, mark it as ignored for
> the current release.
> 
> To me, that seems like the obvious approach to take here, and given the
> reasonably short list of bugs, I don't feel like that would cause
> unreasonable disruption.  In the cases where the build failures are from
> flaky tests, I think disabling the test is a perfectly reasonable fix.  If
> there is some significant merit to a test that fails in Santiago's
> environment but doesn't on the buildd network for some reason *and* has
> significant value in catching regressions on release architectures, that's
> an obvious case for an exception and could be handled like any other RC
> bug exception.
> 
> I think we're going to keep getting lost in the weeds when we try to
> discuss this in general hypotheticals.  If individual package maintainers
> request individual RC exceptions for their specific cases, the discussion
> can be far more concrete and in most cases will have an obvious outcome.
> 
> So, to be explicit, my opinion (as just a Debian Developer, with no
> special ability to decide this, so just take this as another of the
> contributions to the thread) is that all of these bugs should be set to
> Severity: serious, and the maintainers can ask for stretch-ignore tags (or
> downgrades for their specific bug if that seems more correct for specific
> reasons related to their packge, whatever those may be) if they feel that
> is appropriate.

And with this "+1" mail I shall stop contributing to this thread. Everything
has been said at least once :)

Now let's deal with individual bugs and work on getting Stretch released
eventually!


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: Help requested: Packages which FTBFS randomly

[Steve Cotton]

On Mon, Feb 20, 2017 at 01:12:33PM +0100, Santiago Vila wrote:
> Believe me, this is also frustrating for me. If you absolutely need a
> machine to reproduce this, contact me privately.

If someone creates a patch, then the bug is much more likely to get fixed,
whether it's RC or not.  Any FTBFS that needs an entire VM with an
unusual-configuration to reproduce may be RC, but it's another RC bug that when
volunteers look at the RC bug list, they think "I don't know where to start on
that one".

For these single-CPU buildds, there's a simple way to reproduce it at least the
bug that I looked at in a debugging environment, by using the taskset command
from package util-linux to run the build on CPU #0 only:

$ taskset --cpu-list 0 dpkg-buildpackage -A

For changing policy, I think "must be able to build using a single CPU, for
example using (taskset and the FreeBSD and Hurd equivalents), because otherwise
there's obviously a race condition somewhere" would be much clearer.

Steve