Re: Proposal: plocate as standard for bookworm

[Andrei POPESCU]

On Mi, 10 feb 21, 12:24:20, Andrey Rahmatullin wrote:
> On Tue, Feb 09, 2021 at 03:58:39PM -0500, Marvin Renich wrote:
> > These have come to be expected to be on a typical Linux system by almost
> > every technically-knowledgeable Linux user.  Locate does not satisfy
> > that criterion
> (I'm surprised by this, if this is true)

Possibly a consequence of the portability problem, advice on debian-user 
will almost always[1] use 'find' whenever the problem / solution 
involves searching for files.

For myself, I abandoned 'locate' as soon as I learned 'find', even of 
low power systems with storage on SD cards or connected via USB2.

[1] as in: can't remember *any* occurrence in recent years

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Proposal: plocate as standard for bookworm

[Andrei POPESCU]

On Lu, 08 feb 21, 23:13:10, Steinar H. Gunderson wrote:
> 
> The downside is, of course, the nightly updatedb job, which it is rare that
> anyone will notice, and the space used. 

That's assuming the system is left running over night. It might be 
noticeable if run on next system start.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Debian-wide firmware prober

[Paul Sutton]

On 10/02/2021 06:31, Zlatan wrote:

There is isenkram-cli which can detect and autoinstall the needed firmware.

Z


Ah thanks for this,  I had never heard of that one,   these  tools need 
to be better known.


Also vrms,  lists any non-free software installed it may help anyone who 
wants to keep non-free software to a minimum.  But also both of these 
helps the developers


Also could be a way to audit what is actually out there,  could feed in 
to helping developers.


I understand the dilemma we have here,   trying to create a free OS, 
free of non free software but up against it, usually with the essential 
items such as networking hardware, needing non free firmware / drivers etc.


But anything to help is a good thing, networking is pretty essential, 
and wireless networking is essential on portable devices or they are 
less than portable.


Keep up the good work.

Regards

Paul




On February 10, 2021 3:11:29 AM GMT+01:00, "積丹尼 Dan Jacobson" 
 wrote:


Hey everybody,
wouldn't it be nice if there was a prober,
like lshw,
that probed all the firmware one needed?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982402  

It would say:
"
  You need the following Debian firmware packages
  firmware-X
  firmware-Y
  firmware-Z
  Remember, a proper system needs proper firmware.
  Not too much, but also not too little.
"


--
Sent from my Android device with K-9 Mail. Please excuse my brevity.


--
--
Paul Sutton, Cert Cont Sci (Open)
https://personaljournal.ca/paulsutton/
OpenPGP : 4350 91C4 C8FB 681B 23A6 7944 8EA9 1B51 E27E 3D99

Pronoun : him/his/he



OpenPGP_signature
Description: OpenPGP digital signature

Re: Debian-wide firmware prober

[積丹尼 Dan Jacobson]

Z> isenkram-cli

OK, but it seems to work differently that what I was thinking.

Re: Debian-wide firmware prober

[Thaddeus H. Black]

On Wed, Feb 10, 2021 at 08:31:43AM +, Paul Sutton wrote:
> ... I had never heard of that one, these tools need to be better known.

If Enrico Zini's and Enrico Rossi's 'debtags' is installed, then try
this command:

debtags search hardware::detection

That makes the tools better known.

Additionally worth trying, if 'apt-xapian-index' is installed (and its
index has been updated via /etc/cron.weekly/apt-xapian-index), are
queries like these:

axi-cache search firmware
axi-cache search probe firmware
axi-cache search probe hardware
axi-cache search hardware packages


signature.asc
Description: PGP signature

Re: Debian-wide firmware prober

[Petter Reinholdtsen]

積丹尼 Dan Jacobson  writes:

> Z> isenkram-cli
>
> OK, but it seems to work differently that what I was thinking.

I assume you are talking about isenkram-autoinstall-firmware?  How so?
Perhaps the documentation could be improved to adjust the expectations,
or event the program could be adjusted...

Please keep me on CC for any replies.

-- 
Happy hacking
Petter reinholdtsen

Re: devscripts: wrap-and-sort should default to -ast

[Phil Morrell]

On Tue, Feb 09, 2021 at 08:49:51PM +0100, Thomas Goirand wrote:
> On 2/9/21 7:40 PM, Russ Allbery wrote:
> > Jonas Smedegaard  writes:
> >> Let's see if Debian can agree on a single normalization of 822-ish
> >> files.  For starters, I disagree that "wrap-and-sort -a" is a suitable
> >> normalization, as that will involve re-indentation when keys change.
> > 
> > I've been using wrap-and-sort -ast on all of my packages for a while, with
> > much the same justification.
> 
> For packages generating a lot of binaries, the -b option is also quite
> useful, don't you think?

As a user of -satb, I'd like to point out that the flags are not all
equal. Two of them support a (more objective?) desire that "addition to
a list in line-based VCS should have no deletions". That is -at, whereas
-s is a subjective prettifier and -b could remove information, hence -k.

To make that work as a default, there would need to be something like an
--short-preferred-unless-existing-indent to prevent constant
reformatting. I disagree with jonas on the importance of -s because I'm
not convinced that field names change, especially not often.


signature.asc
Description: PGP signature

Bug#982450: ITP: apertium-fra-frp -- Apertium translation data for the French-Arpitan pair

[Kartik Mistry]

Package: wnpp
Severity: wishlist
Owner: Kartik Mistry 
X-Debbugs-Cc: debian-devel@lists.debian.org, kar...@debian.org

* Package name: apertium-fra-frp
  Version : 1.0.0
  Upstream Author : Apertium Project Management Committee 

* URL : https://www.apertium.org/
* License : GPL-3+
  Programming Lang: 
  Description : Apertium translation data for the French-Arpitan pair

Data package providing Apertium language resources for translating
between the French and Arpitan languages.

Re: devscripts: wrap-and-sort should default to -ast

[Phil Morrell]

On Wed, Feb 10, 2021 at 11:47:12AM +, Phil Morrell wrote:
> To make that work as a default, there would need to be something like an
> --short-preferred-unless-existing-indent

sorry, going by the current default, that should be
--align-preferred-unless-existing-short


signature.asc
Description: PGP signature

Re: Proposal: plocate as standard for bookworm

[Bjørn Mork]

Marvin Renich  writes:
> * Steinar H. Gunderson  [210209 14:27]:
>> On Tue, Feb 09, 2021 at 08:53:10PM +0200, Adrian Bunk wrote:
>> > And there are now also many non-technical Linux users who have never
>> > used a shell.
>> 
>> Well, why do we include netcat, telnet or hdparm? lsof? pciutils?
>> traceroute? host? All of these are irrelevant for a non-technical
>> non-shell user, yet a fairly common part of a Linux installation.
>
> These have come to be expected to be on a typical Linux system by almost
> every technically-knowledgeable Linux user.  Locate does not satisfy
> that criterion, and I think the dissension in this thread is evidence of
> that.

This is subjective.  I don't think arguing about the expectations of
"every technically-knowledgeable Linux user" is going to bring the
discussion anywhere.

FWIW, locate was "always" there.  Before Linux and before PCI.
See https://en.wikipedia.org/wiki/Locate_(Unix).

> However, I agree with others here that anyone who wants a locate
> implementation will know how to find all the packages with "locate" in
> their names and plocate looks to me, from the descriptions, to be the
> best choice.  I don't think it deserves "Priority: standard".

I happen to disagree.  To me this is yet another step away from being a
proper Unix system - to something else.  Which would be fine if it moved
us forward.

But removing functionality can hardly be argued to be a move in the
forward direction?

Sure, I can install mlocate or plocate.  But it's the kind of tool you
expect to be present, with an uptodate database, when you need it.  The
database makes locate different from all the other tools you mention.

I also use Linux systems I don't admininstrate.  I'd hate to have to ask
the admin for every basic Unix tool I need.  Some of the standard tools
you mention are only relevant for admins.  Those don't need to be
standard.  But the ones that are relevant for users should be.


Bjørn

a proper-unix meta package (Re: Proposal: plocate as standard for bookworm)

[Holger Levsen]

On Wed, Feb 10, 2021 at 01:05:04PM +0100, Bjørn Mork wrote:
> I happen to disagree.  To me this is yet another step away from being a
> proper Unix system - to something else.  Which would be fine if it moved
> us forward.

As it's 2021 and 99% of the Linux user base has no idea what UNIX (or Linux)
is, maybe it's time for a src:proper-unix-system package for those who care?


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁   holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
 ⠈⠳⣄

Life is short but a sea of morons is forever.


signature.asc
Description: PGP signature

Re: a proper-unix meta package (Re: Proposal: plocate as standard for bookworm)

[Adam Borowski]

On Wed, Feb 10, 2021 at 12:21:36PM +, Holger Levsen wrote:
> On Wed, Feb 10, 2021 at 01:05:04PM +0100, Bjørn Mork wrote:
> > I happen to disagree.  To me this is yet another step away from being a
> > proper Unix system - to something else.  Which would be fine if it moved
> > us forward.
> 
> As it's 2021 and 99% of the Linux user base has no idea what UNIX (or Linux)
> is, maybe it's time for a src:proper-unix-system package for those who care?

Define "proper Unix"...


-- 
⢀⣴⠾⠻⢶⣦⠀ .globl _start↵.data↵rc: .ascii "/etc/init.d/rcS\0"↵.text↵_start
⣾⠁⢠⠒⠀⣿⡁ mov $57,%rax↵syscall↵cmp $0,%rax↵jne child↵parent:↵mov $61,%rax
⢿⡄⠘⠷⠚⠋⠀ mov $-1,%rdi↵xor %rsi,%rsi↵xor %rdx,%rdx↵syscall↵jmp parent↵child:
⠈⠳⣄ mov $59,%rax↵mov $rc,%rdi↵xor %rsi,%rsi↵xor %rdx,%rdx↵syscall

Re: a proper-unix meta package (Re: Proposal: plocate as standard for bookworm)

[Bjørn Mork]

Adam Borowski  writes:
> On Wed, Feb 10, 2021 at 12:21:36PM +, Holger Levsen wrote:
>> On Wed, Feb 10, 2021 at 01:05:04PM +0100, Bjørn Mork wrote:
>> > I happen to disagree.  To me this is yet another step away from being a
>> > proper Unix system - to something else.  Which would be fine if it moved
>> > us forward.
>> 
>> As it's 2021 and 99% of the Linux user base has no idea what UNIX (or Linux)
>> is, maybe it's time for a src:proper-unix-system package for those who care?
>
> Define "proper Unix"...

The definition depends on whether you are a longhair or shorthair.


Bjørn

Re: a proper-unix meta package (Re: Proposal: plocate as standard for bookworm)

[Ansgar]

On Wed, 2021-02-10 at 13:38 +0100, Adam Borowski wrote:
> Define "proper Unix"...

A system including Emacs.  So we would need emacs at Priority: standard
or even important or required :]

Ansgar

Re: a proper-unix meta package (Re: Proposal: plocate as standard for bookworm)

[Holger Levsen]

On Wed, Feb 10, 2021 at 01:38:56PM +0100, Adam Borowski wrote:
> > As it's 2021 and 99% of the Linux user base has no idea what UNIX (or Linux)
> > is, maybe it's time for a src:proper-unix-system package for those who care?
> Define "proper Unix"...

well, I'd leave this to the people who care.

But surely there could be several flavors, maybe even coming from different
source packages.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁   holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
 ⠈⠳⣄

Everyone is entitled to their own opinion, but not their own facts.


signature.asc
Description: PGP signature

Re: Proposal: plocate as standard for bookworm

[Vincent Lefevre]

On 2021-02-09 22:12:31 +0100, Ansgar wrote:
> "Steinar H. Gunderson" writes:
> > On Sat, Feb 06, 2021 at 10:16:29PM -0800, Josh Triplett wrote:
> >> Furthermore, any mechanism they use to configure one of them
> >> (e.g. for privacy or performance reasons) will not control the other,
> >> and again they may well be unaware of the existence of the other one.
> >
> > I'm not sure what privacy reasons you're referring to? I'm not aware that
> > neither mlocate/plocate nor e.g. tracker will leak data across users.
> 
> If you have an encrypted /home (or /home/), but unencrypted
> /var/lib/plocate, you leak information about the encrypted files.

This would be the user's fault. I can also see /home/ "leaks"
in log files. And mail "leaks" under /var/mail. So, in short, /var
should be encrypted.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

ITP: golang-github-pkg-diff -- golang diff module

[Faustin Lammler]

Package: wnpp
Severity: wishlist
Owner: Faustin Lammler 

* Package name: golang-github-pkg-diff
  Version : 0.0~git20200914.5b29258-1
  Upstream Author : Josh Bleecher Snyder 
* URL : https://github.com/pkg/diff
* License : BSD-3-clause
  Programming Lang: Go
  Description :

 Module github.com/pkg/diff can be used to create, modify, and
 print diffs. The top level package, diff, contains convenience functions for
 the most common uses.
 .
 The subpackages provide very fine-grained control over every aspect:
   *  myers creates diffs using the Myers diff algorithm.
   *  edit contains the core diff data types.
   *  ctxt provides tools to reduce the amount of context in a diff.
   *  write provides routines to write diffs in standard formats.

The motivation behind packaging this golang library is to be able to
package shfmt, see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970393

Regards,

-- 
Faustin Lammler


signature.asc
Description: PGP signature

Re: Possible DEP proposal - contribution preferences

[Niels Thykier]

Russ Allbery:
> Jonas Smedegaard  writes:
> 
>> Let's see if Debian can agree on a single normalization of 822-ish
>> files.  For starters, I disagree that "wrap-and-sort -a" is a suitable
>> normalization, as that will involve re-indentation when keys change.
>> Instead, I propose this as starting point:
> 
>>   wrap-and-sort -ast
> 
> I've been using wrap-and-sort -ast on all of my packages for a while, with
> much the same justification.
> 
> My recollection is that the relevant Config::Model model has a slightly
> different preferred normalization form?  Those are the two most common
> tools used for this, I think, so if the two of them could agree, that
> would go a long way towards having a common format (and this may have
> already happened without me knowing).
> 

Personally, I would be fine with a variant of wrap-and-sort (-bastk or
there abouts) being a Debian-wide recommendation/default *if*
wrap-and-sort would preserve comments.

A case where comments are important to me is the d/control of debhelper,
where I document the rationale for many of the versioned
(build-)dependencies.  It would be a non-starter for me to maintain
those comments elsewhere simply because wrap-and-sort keeps steam
rolling them into oblivion.

~Niels

Re: a proper-unix meta package (Re: Proposal: plocate as standard for bookworm)

[Jonathan Carter]

On 2021/02/10 15:16, Bjørn Mork wrote:
> Adam Borowski  writes:
>>> As it's 2021 and 99% of the Linux user base has no idea what UNIX (or Linux)
>>> is, maybe it's time for a src:proper-unix-system package for those who care?
>>
>> Define "proper Unix"...
> 
> The definition depends on whether you are a longhair or shorthair.

If you're a proper blue-haired person, then the only proper Unix is Debian.

-Jonathan

Re: Possible DEP proposal - contribution preferences

[Jonas Smedegaard]

Quoting Niels Thykier (2021-02-10 17:35:36)
> Russ Allbery:
> > Jonas Smedegaard  writes:
> > 
> >> Let's see if Debian can agree on a single normalization of 822-ish 
> >> files.  For starters, I disagree that "wrap-and-sort -a" is a 
> >> suitable normalization, as that will involve re-indentation when 
> >> keys change. Instead, I propose this as starting point:
> >>
> >>   wrap-and-sort -ast
> > 
> > I've been using wrap-and-sort -ast on all of my packages for a 
> > while, with much the same justification.
> > 
> > My recollection is that the relevant Config::Model model has a 
> > slightly different preferred normalization form?  Those are the two 
> > most common tools used for this, I think, so if the two of them 
> > could agree, that would go a long way towards having a common format 
> > (and this may have already happened without me knowing).
> > 
> 
> Personally, I would be fine with a variant of wrap-and-sort (-bastk or
> there abouts) being a Debian-wide recommendation/default *if*
> wrap-and-sort would preserve comments.

Ah, right.

I totally forgot that, and agree that auto-killing comments is a no-go.


 - 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: Proposal: plocate as standard for bookworm

[Adrian Bunk]

On Tue, Feb 09, 2021 at 12:02:33PM -0800, Russ Allbery wrote:
> Adrian Bunk  writes:
> > On Mon, Feb 08, 2021 at 11:13:10PM +0100, Steinar H. Gunderson wrote:
> >>...
> >> users on
> >> shared systems can expect it to be available without asking an 
> >> administrator
> >> first. To me, locate has always been a standard tool on a UNIX system, so 
> >> it
> >> makes sense to install it by default.
> >>...
> 
> > "Shared systems" have become pretty rare.
> 
> They've become *rarer*, but they're still very common in the academic and
> scientific research world.

Let's not nitpick over words, I assume we can both agree that they still
exist but are a much smaller share of Unix-like systems than 30 years ago.

When I think of hardware running Debian in 2021,
I am thinking of a Raspberry Pi running on an SD card.

cu
Adrian

Re: Proposal: plocate as standard for bookworm

[Russ Allbery]

Adrian Bunk  writes:
> On Tue, Feb 09, 2021 at 12:02:33PM -0800, Russ Allbery wrote:
>> Adrian Bunk  writes:
>>> On Mon, Feb 08, 2021 at 11:13:10PM +0100, Steinar H. Gunderson wrote:

 users on shared systems can expect it to be available without asking
 an administrator first. To me, locate has always been a standard
 tool on a UNIX system, so it makes sense to install it by default.

>>> "Shared systems" have become pretty rare.

>> They've become *rarer*, but they're still very common in the academic and
>> scientific research world.

> Let's not nitpick over words, I assume we can both agree that they still
> exist but are a much smaller share of Unix-like systems than 30 years ago.

I'm not nitpicking; I think shared systems are still common enough that
this is one of several reasons why we should install a locate
implementation by default.

> When I think of hardware running Debian in 2021,
> I am thinking of a Raspberry Pi running on an SD card.

Every person is different.

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

Huh?? sbuild fails and pbuilder succeeds in building a Fortran-containing Python package

[Julian Gilbey]

I wonder if anyone has an idea about this thorny problem.  I'm trying
to create a package and thought I'd got something wrong, but have
found the same behaviour happens with the "amp" package (version
0.6.1-1) and the "spherepack" package (version 3.3~a1-4), which
suggests to me that the problem lies outside of the package itself.
But I have very little idea how to track this bug down.


If I run sbuild:
  sbuild -s -A -d unstable spherepack_3.3~a1-4.dsc
then the build starts OK, but when it comes to compiling the C sources
(or maybe it's actually the Fortran sources - I don't know), I get the
following:

[...]
building 'spherepack' extension
compiling C sources
C compiler: x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare 
-DNDEBUG -g -fwrapv -O2 -Wall -g 
-ffile-prefix-map=/build/python3.9-euU3fN/python3.9-3.9.1=. 
-fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC

creating build/temp.linux-x86_64-3.9/build
creating build/temp.linux-x86_64-3.9/build/src.linux-x86_64-3.9
creating build/temp.linux-x86_64-3.9/build/src.linux-x86_64-3.9/Src
creating build/temp.linux-x86_64-3.9/build/src.linux-x86_64-3.9/build
creating 
build/temp.linux-x86_64-3.9/build/src.linux-x86_64-3.9/build/src.linux-x86_64-3.9
creating 
build/temp.linux-x86_64-3.9/build/src.linux-x86_64-3.9/build/src.linux-x86_64-3.9/Src
compile options: '-Ibuild/src.linux-x86_64-3.9/build/src.linux-x86_64-3.9/Src 
-I/usr/lib/python3/dist-packages/numpy/core/include -I/usr/include/python3.9 -c'
error: [Errno 13] Permission denied

An identical "Permission denied" error happens with the "amp" package
as well, and also with the new package that I'm working on.

However, with pbuilder:
  pbuilder build spherepack_3.3~a1-4.dsc
I get a successful build, and the similar part of the output reads:

[...]
building 'spherepack' extension
compiling C sources
C compiler: x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare 
-DNDEBUG -g -fwrapv -O2 -Wall -g 
-ffile-prefix-map=/build/python3.9-euU3fN/python3.9-3.9.1=. 
-fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -g -O2 
-ffile-prefix-map=/build/spherepack-3.3~a1=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC

compile options: '-Ibuild/src.linux-x86_64-3.9/build/src.linux-x86_64-3.9/Src 
-I/usr/lib/python3/dist-packages/numpy/core/include -I/usr/include/python3.9 -c'
x86_64-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions 
-Wl,-z,relro -g -fwrapv -O2 -Wl,-z,relro -g -O2 
-ffile-prefix-map=/build/spherepack-3.3~a1=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 
build/temp.linux-x86_64-3.9/build/src.linux-x86_64-3.9/Src/spherepackmodule.o 
build/temp.linux-x86_64-3.9/build/src.linux-x86_64-3.9/build/src.linux-x86_64-3.9/Src/fortranobject.o
 -L/build/spherepack-3.3~a1/Src -lsphere -o 
build/lib.linux-x86_64-3.9/spherepack.cpython-39-x86_64-linux-gnu.so
running install_lib
[...]

They are so different, yet supposedly using essentially identical
build environments.  (They are also both using sid repositories.)


If you have any idea why I might be seeing this behaviour, and what I
might be able to do about it, that would be fantastic!

Thanks!

   Julian

Re: Huh?? sbuild fails and pbuilder succeeds in building a Fortran-containing Python package

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Julian Gilbey (2021-02-10 22:51:39)
> I wonder if anyone has an idea about this thorny problem.  I'm trying
> to create a package and thought I'd got something wrong, but have
> found the same behaviour happens with the "amp" package (version
> 0.6.1-1) and the "spherepack" package (version 3.3~a1-4), which
> suggests to me that the problem lies outside of the package itself.
> But I have very little idea how to track this bug down.
>
> [...]
> 
> They are so different, yet supposedly using essentially identical
> build environments.  (They are also both using sid repositories.)
> 
> If you have any idea why I might be seeing this behaviour, and what I
> might be able to do about it, that would be fantastic!

I would actually not be surprised if we find reproducibility problems between
packages built on pbuilder versus packages build with sbuild. For example
sbuild sets HOME=/sbuild-nonexistent which will make packages FTBFS that try to
put anything in $HOME. This is not the problem here, though. If I wrap the call
to dh in debian/rules in strace -p I get:

[pid   609] statfs("/dev/shm/", {f_type=TMPFS_MAGIC, f_bsize=4096, 
f_blocks=2097152, f_bfree=861837, f_bavail=861837, f_files=1495318, 
f_ffree=1426033, f_fsid={val=[0, 0]}, f_namelen=255, f_frsize=4096, 
f_flags=ST_VALID|ST_NOSUID|ST_NODEV|ST_RELATIME}) = 0
[pid   609] futex(0x7f82bf2a7410, FUTEX_WAKE_PRIVATE, 2147483647) = 0
[pid   609] getpid()= 609
[pid   609] lstat("/dev/shm/o5kYxf", 0x7ffcfec00740) = -1 ENOENT (No such file 
or directory)
[pid   609] openat(AT_FDCWD, "/dev/shm/o5kYxf", O_RDWR|O_CREAT|O_EXCL, 0600) = 
-1 EACCES (Permission denied)
[pid   609] close(3)= 0
[pid   609] close(4)= 0
[pid   609] write(2, "error: [Errno 13] Permission den"..., 36error: [Errno 13] 
Permission denied

A workaround for this problem is indeed to add

--chroot-setup-commands="chmod 777 /dev/shm"

to your sbuild invocation. A cursory glance into the pbuilder codebase reveals
that pbuilder will mount a tmpfs into /dev/shm:

https://sources.debian.org/src/pbuilder/0.231/pbuilder-modules/?hl=417#L417

For sbuild, whether this is done, this depends on your chroot backend. The
package builds fine on the buildds though, so I guess they have a schroot setup
that sets /dev/shm up correctly?

Thanks!

cheers, josch

signature.asc
Description: signature

Re: Huh?? sbuild fails and pbuilder succeeds in building a Fortran-containing Python package

[Julian Gilbey]

On Thu, Feb 11, 2021 at 12:15:38AM +0100, Johannes Schauer Marin Rodrigues 
wrote:
> Hi,
> 
> Quoting Julian Gilbey (2021-02-10 22:51:39)
> > I wonder if anyone has an idea about this thorny problem.  I'm trying
> > to create a package and thought I'd got something wrong, but have
> > found the same behaviour happens with the "amp" package (version
> > 0.6.1-1) and the "spherepack" package (version 3.3~a1-4), which
> > suggests to me that the problem lies outside of the package itself.
> > But I have very little idea how to track this bug down.
> >
> > [...]
> > 
> > They are so different, yet supposedly using essentially identical
> > build environments.  (They are also both using sid repositories.)
> > 
> > If you have any idea why I might be seeing this behaviour, and what I
> > might be able to do about it, that would be fantastic!
> 
> I would actually not be surprised if we find reproducibility problems between
> packages built on pbuilder versus packages build with sbuild. For example
> sbuild sets HOME=/sbuild-nonexistent which will make packages FTBFS that try 
> to
> put anything in $HOME. This is not the problem here, though. If I wrap the 
> call
> to dh in debian/rules in strace -p I get:
> 
> [...]
> [pid   609] openat(AT_FDCWD, "/dev/shm/o5kYxf", O_RDWR|O_CREAT|O_EXCL, 0600) 
> = -1 EACCES (Permission denied)
> [...]
> [pid   609] write(2, "error: [Errno 13] Permission den"..., 36error: [Errno 
> 13] Permission denied

Hi Josch,

Wow, thanks!  I tried putting the strace call around the whole build,
but that didn't work.

> A workaround for this problem is indeed to add
> 
> --chroot-setup-commands="chmod 777 /dev/shm"
> 
> to your sbuild invocation. A cursory glance into the pbuilder codebase reveals
> that pbuilder will mount a tmpfs into /dev/shm:
> 
> https://sources.debian.org/src/pbuilder/0.231/pbuilder-modules/?hl=417#L417
> 
> For sbuild, whether this is done, this depends on your chroot backend. The
> package builds fine on the buildds though, so I guess they have a schroot 
> setup
> that sets /dev/shm up correctly?

OK, so I'll submit this as a bug report / feature request to sbuild.

Many thanks for tracking down the cause of this!

Best wishes,

   Julian

Re: a proper-unix meta package (Re: Proposal: plocate as standard for bookworm)

[Gunnar Wolf]

Jonathan Carter dijo [Wed, Feb 10, 2021 at 07:29:14PM +0200]:
> >> Define "proper Unix"...
> > 
> > The definition depends on whether you are a longhair or shorthair.
> 
> If you're a proper blue-haired person, then the only proper Unix is Debian.

Please do note that your definition might be of sufficiency, but is
–to use our common parlance– a Suggests: or, at most, a
Recommends:. It has been observed there are many example cases where
hair style is orthogonal to Unix preferences.

Re: Huh?? sbuild fails and pbuilder succeeds in building a Fortran-containing Python package

[Jonathan Carter]

On 2021/02/10 23:51, Julian Gilbey wrote:
> creating 
> build/temp.linux-x86_64-3.9/build/src.linux-x86_64-3.9/build/src.linux-x86_64-3.9/Src
> compile options: '-Ibuild/src.linux-x86_64-3.9/build/src.linux-x86_64-3.9/Src 
> -I/usr/lib/python3/dist-packages/numpy/core/include -I/usr/include/python3.9 
> -c'
> error: [Errno 13] Permission denied

Is this on a local filesystem? I had similar problems a while back when
building packages over a network filesystem when the build system
couldn't set specific attributes/flags/permissions/etc.

-Jonathan