Bug#1066938: Fwd: Bug#1066938: libfiu: FTBFS on arm{el,hf}: /tmp/cc54dEva.s:726: Error: symbol `open64' is already defined

[Alberto Bertogli]

On Sat, Apr 20, 2024 at 12:00:00AM +0200, Santiago Vila wrote:

El 25/3/24 a las 20:12, Chris Lamb escribió:

Alberto Bertogli wrote:


If you know of a functional official image that I can use to try to
reproduce the problem, or recently-tested steps I can follow to get
a working qemu install, please let me know.


Alas, I can't actually be helpful here. There are no official images
as far as I know… and somewhat annoyingly I (ie. a Debian Developer)
actually have access to some machines set aside for this purpose. I
call this "annoying" because I naturally can't then give you direct
SSH access transitively — but I can proxy ideas, of course.


Hi.

I can't offer ssh access either (for now), but I've checked and
this error may be reproduced easily on an arm64 machine using an
armel chroot.


Oohhh this is good to know, I didn't know that was a viable option.  
Thank you for the suggestion!


I will try to reproduce it this way, I'll let you know how it goes.

Thank you!
Alberto

Bug#1066938: Fwd: Bug#1066938: libfiu: FTBFS on arm{el,hf}: /tmp/cc54dEva.s:726: Error: symbol `open64' is already defined

[Alberto Bertogli]

On Mon, Mar 25, 2024 at 07:12:24PM +, Chris Lamb wrote:

Alberto Bertogli wrote:


If you know of a functional official image that I can use to try to
reproduce the problem, or recently-tested steps I can follow to get
a working qemu install, please let me know.


Alas, I can't actually be helpful here. There are no official images
as far as I know… and somewhat annoyingly I (ie. a Debian Developer)
actually have access to some machines set aside for this purpose. I
call this "annoying" because I naturally can't then give you direct
SSH access transitively — but I can proxy ideas, of course.


I totally understand the access part, that's very reasonable on Debian's 
part.


But unfortunately, if I can't even run a local VM to try to reproduce 
the problem, it's too limiting for me. Especially considering the kind 
of issues libfiu often runs into, which tend to be a bit on the esoteric 
side :)




Hm, googling the actual error message a little, I think this might be
a bigger issue... or perhaps more accurately, at least one that has
potentially been also solved elsewhere:

 * Same think in lightdm: <https://bugs.debian.org/1067561>

 * Some kind of "_FILE_OFFSET_BITS"-related patch for v4l-utils
   <https://www.spinics.net/lists/linux-media/msg230147.html>


Thank you for looking at this!

I think they could be similar; in particular the second one.

Maybe there's something like `#define pread pread64` in the 
architecture's headers that is triggering these errors?




Does this spark anything worth trying? :-)


Maybe seeing the preprocessor output and the actual (temporary) file 
getting the complaints could be useful in figuring out what's going on.


That said, even if we find what the problem is, we may keep finding 
other issues in the future. If I'm not able to have a VM for this
platform where I can try to reproduce problems, I'm not sure it's viable 
to support the package on it :(


Thanks!
Alberto

Bug#1066938: Fwd: Bug#1066938: libfiu: FTBFS on arm{el,hf}: /tmp/cc54dEva.s:726: Error: symbol `open64' is already defined

[Alberto Bertogli]

On Sun, Mar 24, 2024 at 06:00:51PM +, Chris Lamb wrote:

Alberto Bertogli wrote:


I'll try to get a debian install to boot for armhf, but it'll take me a
bit because it's not straightforward (to put it mildly :).


Oh, yeah. :/ Perhaps qemu might be better option here. There might
even be pre-built disk images flying around.


Sorry, yes that's what I meant! To install it under qemu!

Unfortunately, I haven't been able to get it to work.

I managed to get bookworm installed, and then extracted the 
kernel+initrd from inside the virtual disk (as apparently that's 
needed), but the kernel won't boot due to: `Unhandled fault: synchronous 
abort (translation table walk)`.


At this point I'm not really keen on debugging whatever that armhf 
kernel issue is :(


If you know of a functional official image that I can use to try to 
reproduce the problem, or recently-tested steps I can follow to get a 
working qemu install, please let me know.


Thanks,
Alberto

Bug#1066938: Fwd: Bug#1066938: libfiu: FTBFS on arm{el,hf}: /tmp/cc54dEva.s:726: Error: symbol `open64' is already defined

[Alberto Bertogli]

On Mon, Mar 18, 2024 at 12:29:40PM +, Chris Lamb wrote:

Dear Alberto,


Hi!



Hope this finds you well. Any quick/immediate ideas on what might be
behind this build failure? Note that this is on ARM architectures
rather than amd64 — I often misread and conflate them at speed. :) Oh,
and I can't reproduce this on amd64 locally, at least, so I don't think
it is, say, due to some *general* update to the GLIBC build toolchain.


Nothing obvious.

It's a bit strange because the "symbol X already defined" errors most 
likely come from the assembler when building the individual files, not 
from linking stage.


While it's impossible to be 100% sure because of the parallel build and 
the lack of command-output correlation in the logs, everything points to 
that being the case.


I'll try to get a debian install to boot for armhf, but it'll take me a 
bit because it's not straightforward (to put it mildly :).


How urgent/important is this issue?

Thanks,
Alberto




- Original message -
From: Sebastian Ramacher 
To: Debian Bug Tracking System 
Subject: Bug#1066938: libfiu: FTBFS on arm{el,hf}: /tmp/cc54dEva.s:726: Error: 
symbol `open64' is already defined
Date: Friday, 15 March 2024 6:50 PM

Source: libfiu
Version: 1.2-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=libfiu=armhf=1.2-2=1710292712=0

cc -D_XOPEN_SOURCE=600 -fPIC -DFIU_ENABLE=1 -D_LARGEFILE64_SOURCE=1 -I. -I../../libfiu/ -g 
-O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security 
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 
-Wl,-z,relro -Wl,-z,now -D_GNU_SOURCE -c codegen.c -o codegen.o
/tmp/cc54dEva.s: Assembler messages:
/tmp/cc54dEva.s:726: Error: symbol `open64' is already defined
/tmp/cchEoHpC.s: Assembler messages:
/tmp/cchEoHpC.s:474: Error: symbol `mmap64' is already defined
make[4]: *** [Makefile:67: modules/posix.mm.mod.o] Error 1
make[4]: *** Waiting for unfinished jobs
make[4]: *** [Makefile:67: modules/posix.custom.o] Error 1
/tmp/cct4HXD3.s: Assembler messages:
/tmp/cct4HXD3.s:1810: Error: symbol `pread64' is already defined
/tmp/cct4HXD3.s:3995: Error: symbol `pwrite64' is already defined
/tmp/cct4HXD3.s:5803: Error: symbol `truncate64' is already defined
/tmp/cct4HXD3.s:6480: Error: symbol `ftruncate64' is already defined
/tmp/ccInAMjZ.s: Assembler messages:
/tmp/ccInAMjZ.s:437: Error: symbol `fopen64' is already defined
make[4]: *** [Makefile:67: modules/posix.io.mod.o] Error 1
/tmp/ccInAMjZ.s:1099: Error: symbol `freopen64' is already defined
/tmp/ccInAMjZ.s:3393: Error: symbol `tmpfile64' is already defined
/tmp/ccInAMjZ.s:5973: Error: symbol `ftello64' is already defined
/tmp/ccInAMjZ.s:7007: Error: symbol `fseeko64' is already defined
/tmp/ccInAMjZ.s:7699: Error: symbol `fsetpos64' is already defined
make[4]: *** [Makefile:67: modules/posix.stdio.mod.o] Error 1





Alberto

Bug#1060091: chasquid: v1.11.1 with backported SMTP smuggling fix was released, will this be released in debian stable?

[Alberto Bertogli]

On Fri, Jan 05, 2024 at 09:02:26PM +0100, Matěj Volf wrote:

Package: chasquid
Version: 1.11-2+b2
Severity: normal

Hi all,

you might have heard about the latest SMTP smuggling vulnerability. 
Author of chasquid responsed by releasing 1.13 and 1.11.1 
() with 
the backported fix. From , I 
understand that 1.13 was automatically accepted into testing, but I 
didn't notice anything happening regarding 1.11.1 (my server is on 
Debian stable, which only has 1.11), so I wanted to politely ask if 
this could be processed as well.


Thanks for requesting this!


I have very little knowledge about the Debian packaging and release 
process, so please correct if I have any major misunderstanding of the 
process and what I'm asking is unreasonable.


That's viable, and it was discussed in the debian-go mailing list too: 
https://lists.debian.org/debian-go/2023/12/msg00121.html


Unfortunately, I don't have time to work on this due to some unexpected 
personal circumstances, and I won't be able to do the 1.11.1 Debian 
package for (probably) a few more weeks.


Hopefully someone can do it in the meantime.

Otherwise, a workaround is to build chasquid v1.11.1 locally, and copy 
the binary to /usr/lib. It's not pretty, but it should work.


Again, apologies for not being able to fix this in a timely fashion for 
Debian this time.


Thanks a lot!
Alberto

Bug#1054777: Fwd: Bug#1054777: libfiu: FTBFS: dh_auto_test: error: make -j8 test V=1 LC_ALL=C returned exit code 2

[Alberto Bertogli]

On Sun, Oct 29, 2023 at 02:00:32PM +, Chris Lamb wrote:

Dear Alberto,


I think this is likely a problem I already fixed back in February in
commit 5dcc6d4.


Ah, cherry-picking that commit fixed it for me. I've gone ahead and
uploaded that to Debian in order to close this RC bug, but please do
feel free to also release a libfiu v1.2 as well.

That would have the added advantage of "clearing out" the other patch
we had to apply re. Link-Time Optimisation.


Great!

I've just released libfiu 1.2 then :)

Just in case, one of the possibly-impacting patches is updating to 
setuptools, that may need some adjustments in the build-depends:


https://blitiri.com.ar/git/r/libfiu/c/88b961aad6b1fcbc0e1decbf34a0bc9510600988/

Hopefully with that you can clear the other patch!

Thank you!
Alberto

Bug#1054777: Fwd: Bug#1054777: libfiu: FTBFS: dh_auto_test: error: make -j8 test V=1 LC_ALL=C returned exit code 2

[Alberto Bertogli]

On Sat, Oct 28, 2023 at 09:58:14AM +0100, Chris Lamb wrote:

Hey Alberto,

Hope all is well with you. Just wondering if you received the below
re. a recently-filed bug report against libfiu. I can reproduce it
locally if that helps.


I got it, but I appreciate you forwarding it explicitly anyway just in 
case, and the confirmation of a reproduction!




./wrap-python 3 ./test-basic.py
Can't find python3 bindings, run make python3
make[3]: *** [Makefile:96: py-run-test-basic] Error 1


Looking at this, I don find any issues with the Makefile dependency 
chain itself.


I think this is likely a problem I already fixed back in February in 
commit 5dcc6d4.


https://blitiri.com.ar/git/r/libfiu/c/5dcc6d449dc86d4ba9abc99ac52fd5798e573738/

There have been a few commits since v1.1, I think a v1.2 is probably 
overdue at this point in any case.


Chris, do you want to confirm that patch fixes the issue in the Debian 
build environment? And if so I can just make a 1.2 including it. Do you 
think that would be the most practical course of action here?


Thank you!
Alberto

Bug#1050168: FTBFS: test_no_local_cert: tlsv13 alert certificate required

[Alberto Bertogli]

On Mon, Aug 21, 2023 at 05:32:53PM +0800, Shengjing Zhu wrote:

Source: kxd
Version: 0.15-4
Severity: serious
Tags: ftbfs
X-Debbugs-Cc: albert...@blitiri.com.ar, z...@debian.org

I'm not sure if it's related to golang-defaults -> golang-1.21 recently.


[...]

Traceback (most recent call last):
 File "/<>/tests/run_tests", line 360, in test_no_local_cert
   self.assertEqual(err.reason, "SSLV3_ALERT_BAD_CERTIFICATE")
AssertionError: 'TLSV13_ALERT_CERTIFICATE_REQUIRED' != 
'SSLV3_ALERT_BAD_CERTIFICATE'
- TLSV13_ALERT_CERTIFICATE_REQUIRED
+ SSLV3_ALERT_BAD_CERTIFICATE


Thanks for filing this!

Yeah I think it's likely, this looks like a more specific and accurate 
error is now reported in this case, either due to the Go TLS library, or 
OpenSSL (which the tests use because they're written in Python).


I have a patch in the `next` branch that should update the test 
accordingly:


https://blitiri.com.ar/git/r/kxd/c/ca7d96cc6088cddbdd9904cc8de8192b417a9340/

https://blitiri.com.ar/git/r/kxd/c/ca7d96cc6088cddbdd9904cc8de8192b417a9340.patch

Would you mind giving it a try? It should solve the problem.

Thanks!
Alberto

Bug#1015487: libfiu: ftbfs with LTO (link time optimization) enabled

[Alberto Bertogli]

On Thu, Aug 18, 2022 at 11:00:24AM -0700, Chris Lamb wrote:

Hey Alberto,

Just briefly reaching out to you just in case this slipped your mind
during your time away from the internet. Hopefully, it's quite an easy
fix.


Indeed it had sneakily gone away from my TODO list, so thanks for the 
reminder!




On 20 July 2022 00:18:29 GMT-06:00, Chris Lamb  wrote:

Hi Alberto,

Any ideas why libfiu fails to build with -flto=auto -ffat-lto-objects
(etc.) enabled?


Just FYI I have extremely limited connectivity until the end of the
month, so I'm afraid I won't have a chance to look before then :(



cc -I../../libfiu/ -L../../libfiu/ -D_XOPEN_SOURCE=600 -D_GNU_SOURCE
-fPIC -DFIU_ENABLE=1 -g -O2 -ffile-prefix-map=/<>=.
-flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat
-Werror=format-security -std=c99 -pedantic -Wall -std=c99 -pedantic
-Wall tests/strdup.c -lfiu -o tests/strdup.bin
LD_LIBRARY_PATH=../libfiu/
LD_PRELOAD=./libs/fiu_run_preload.so:./libs/fiu_posix_preload.so
./test-enable_stack
test-enable_stack: test-enable_stack.c:39: main: Assertion `func2() ==
1' failed.


From this it seems the issue is with the stack trace collection. If LTO
is doing some inlining for example (which wouldn't surprise me) then it
could cause the test to fail.


That's exactly what's happening: "-flto=auto -O2" was causing one of the 
functions of the stack to be inlined, and causing the tests to fail.


Patch 
https://blitiri.com.ar/git/r/libfiu/c/902b282375587352dccf6467fa740330d6900e54/ 
(currently on the `next` branch, I'll move it to `master` once you 
confirm it fixes the issue in the automated builds too) should fix this 
issue.


Thanks a lot!
Alberto


PS: That patch can be downloaded in text format from
https://blitiri.com.ar/git/r/libfiu/c/902b282375587352dccf6467fa740330d6900e54.patch

Bug#1015487: libfiu: ftbfs with LTO (link time optimization) enabled

[Alberto Bertogli]

On 20 July 2022 00:18:29 GMT-06:00, Chris Lamb  wrote:
>Hi Alberto,
>
>Any ideas why libfiu fails to build with -flto=auto -ffat-lto-objects
>(etc.) enabled?

Just FYI I have extremely limited connectivity until the end of the month, so 
I'm afraid I won't have a chance to look before then :(


>> cc -I../../libfiu/ -L../../libfiu/ -D_XOPEN_SOURCE=600 -D_GNU_SOURCE 
>> -fPIC -DFIU_ENABLE=1 -g -O2 -ffile-prefix-map=/<>=. 
>> -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat 
>> -Werror=format-security -std=c99 -pedantic -Wall -std=c99 -pedantic 
>> -Wall tests/strdup.c -lfiu -o tests/strdup.bin
>> LD_LIBRARY_PATH=../libfiu/ 
>> LD_PRELOAD=./libs/fiu_run_preload.so:./libs/fiu_posix_preload.so 
>> ./test-enable_stack
>> test-enable_stack: test-enable_stack.c:39: main: Assertion `func2() == 
>> 1' failed.

From this it seems the issue is with the stack trace collection. If LTO is 
doing some inlining for example (which wouldn't surprise me) then it could 
cause the test to fail.

I'll look in more detail at the beginning of August.


Thank you!
Alberto

Bug#997757: kxd: FTBFS: go: go.mod file not found in current directory or any parent directory; see 'go help modules'

[Alberto Bertogli]

On Sun, Oct 24, 2021 at 01:37:43PM +0200, Lucas Nussbaum wrote:

Source: kxd
Version: 0.15-2
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20211023 ftbfs-bookworm

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):

make[1]: Entering directory '/<>'
go build -o ./out/kxd ./kxd
go build --tags netgo -a -o ./out/kxc ./kxc
go build -o ./out/kxgencert ./kxgencert
go: go.mod file not found in current directory or any parent directory; see 'go 
help modules'
make[1]: *** [Makefile:17: kxc] Error 1


This is because kxd has no go.mod file (it wasn't needed before).

I've added one upstream:

Browse: 
https://blitiri.com.ar/git/r/kxd/c/e5b1abe3b5dc235b083953e8fba01a0acf53e484/
Raw patch: 
https://blitiri.com.ar/git/r/kxd/c/e5b1abe3b5dc235b083953e8fba01a0acf53e484.patch

I'll add it to the Debian package later, unless someone else gets to it 
first :)


Thanks!
Alberto

Bug#986393: dnss: Recent update overwrote modified configuration files - broke DNS

[Alberto Bertogli]

On Mon, Apr 05, 2021 at 12:31:43PM -0700, Steve Ellis wrote:

Hi Alberto,
Thanks for replying so quickly.

I really appreciate being able to use dnss.  In Canada, our domain
registrar (CIRA.CA) also provides safe and secure DNS resolution
services including DOH and dnss is the perfect open-source solution.


Thank you, I'm glad to hear you find it useful :)



I think that the dnss setup is more easily configured using the
/lib/systemd files than using /etc/default/dnss for specifying
everything; as mentioned, I made changes to all 3 files.  I don't
understand why /lib/systemd are not considered configuration files -
perhaps this is the real bug.


I understand (and to a large degree share) the frustration about 
/lib/systemd, but that's beyond dnss, it's a Debian-wide policy based on 
how systemd works.


If you have other packages where you've overridden their systemd files 
in /lib/systemd, the same thing will happen when they change.


What I do for overriding systemd default configs is to create your own 
service files in /etc/systemd, which will take precedence if they exist.
This (and a couple of variants) is documented in 
https://wiki.debian.org/systemd#Creating_or_altering_services.




In any case, I always run "apt upgrade" manually because I always want
to see and evaluate any configuration files changes.  I did not see the
usual configuration file changes prompts from apt (dpkg) when dnss was
updated.  Unfortunately, dpkg.log does not include such details.
However, /var/log/apt/term.log does and there is no record of any such
prompting about /etc/default/dnss for this update:

 Preparing to unpack .../dnss_0.0~git20200927.0.6aad832e-1+b1_amd64.deb ...
 Unpacking dnss (0.0~git20200927.0.6aad832e-1+b1) ...
 Setting up dnss (0.0~git20200927.0.6aad832e-1+b1) ...
 Created symlink /etc/systemd/system/multi-user.target.wants/dnss.service → 
/lib/systemd/system/dnss.service.
 Created symlink /etc/systemd/system/sockets.target.wants/dnss.socket → 
/lib/systemd/system/dnss.socket.
 Job failed. See "journalctl -xe" for details.
 A dependency job for dnss.service failed. See 'journalctl -xe' for details.

I don't think I have any configuration issues with apt.  As mentioned,
I am used to being prompted about configuration file changes.  I have
included the details as requested in the attached file
apt-config.dump.out.txt.


Honestly I don't know what might have caused you not getting a prompt on 
/etc/default/dnss. I will try to reproduce it in a VM and will report 
back, but this seems more of a Debian issue than a dnss issue :(


Sorry for the super trivial question, but are you sure /etc/default/dnss 
was also overriden by you, and not just the systemd files, right?


In any case, maybe someone more well versed in Debian can help identify 
what's going on here.




Thank you for your work on the dnss package.  I hope that you find my
experience useful to your work.


Thanks again for your kind words, and for taking the time to report 
bugs and help troubleshoot the problem!


Alberto

Bug#986393: dnss: Recent update overwrote modified configuration files - broke DNS

[Alberto Bertogli]

On Sun, Apr 04, 2021 at 06:45:09PM -0700, se wrote:

  * What led up to the situation?
- running "apt upgrade"

  * What exactly did you do (or not do) that was effective (or
ineffective)?
- had to restore all 3 confuration files from backup:
  /etc/default/dnss
  /lib/systemd/system/dnss.socket
  /lib/systemd/system/dnss.service

  * What was the outcome of this action?
- restoring from backup and re-enabling and re-starting dnss restored function

  * What outcome did you expect instead?
- asking about modified configuratiuon files before overwriting them.
- not breaking DNS resolution.


Hi, thanks for reporting this, and sorry you run into this!

The dnss package uses the standard Debian way of packaging configuration 
files, so the behaviour should match what you see in other packages.


- /etc/default/dnss appears in conffiles, which is what tells apt that 
  it is a configuration file that *shouldn't* be overwritten if the user 
  has made changes, and you should get asked what to do (see [1] and 
  [2]).


- The /lib/systemd/ files do not appear in conffiles and *will* get 
  overwritten. I think that's expected, since for overriding systemd 
  configuration the expectation is that you do it in /etc/systemd/ (see 
  [3]). I'm not saying I love it, but it's how systemd configuration 
  file layout is designed to work.
  I'm sorry that you had to restore these from backups, but this will 
  happen with _any_ package, it was probably just bad luck that you saw 
  it with dnss.


So, /lib/systemd/ files being silently overwritten is working as 
intended (as unfortunate as that is), but /etc/default/dnss should not 
be automatically overwritten under normal conditions.



Was this an unattended upgrade? If so, do you have a log of the upgrade?
Like /var/log/unattended-upgrades/unattended-upgrades.log and
/var/log/unattended-upgrades/unattended-upgrades-dpkg.log.

Do you have any special apt configuration that might be behind this? An 
"apt-config dump" should show the full apt configuration, it might be 
useful to include it as well.


Thanks again,
Alberto

[1]: https://www.debian.org/doc/debian-policy/ch-files.html#behavior
[2]: https://www.debian.org/doc/debian-policy/ap-pkg-conffiles.html
[3]: https://wiki.debian.org/systemd#Creating_or_altering_services

Bug#972527: Support arbitrary arguments in /etc/default/dnss

[Alberto Bertogli]

On Wed, Mar 10, 2021 at 10:13:45AM +0100, Florian Schlichting wrote:

Control: severity 972527 important

Dear dnss maintainers,


/lib/systemd/system/dnss.service uses curly braces with
${MONITORING_FLAG} and ${MODE_FLAGS}, which means each one can only
have a single argument in it.


please please fix this? It just needs dnss.service to not use curly braces:


Sorry for dropping this issue, and thanks for reporting and pinging 
about it.


I just uploaded the fix to salsa (commit 06d21499). Sorry I didn't see 
the merge request in time, I didn't realize from the email that it was 
about this issue :S


I can't upload a new package (I'm not a DD) but will ask on irc if 
anyone is available to do that.


Thanks again,
Alberto

Bug#961814: marked as pending in golang-google-protobuf

[Alberto Bertogli]

On Fri, Jan 08, 2021 at 11:30:21PM +0800, Shengjing Zhu wrote:

On Fri, Jan 8, 2021 at 11:17 PM Alberto Bertogli
 wrote:


On Thu, Jan 07, 2021 at 11:12:24PM +0800, Shengjing Zhu wrote:
>On Thu, Jan 7, 2021 at 10:59 PM Alberto Bertogli
> wrote:
>> But those issues are not made worse by allowing golang-google-protobuf
>> to go in, right?
>>
>
>Let golang-google-protobuf go in is one thing, it's not difficult.
>However without golang-goprotobuf 1.4.x it's not useful currently. But
>it will be changed if upstream has switched to golang-google-protobuf
>only.

But IIUC that's what foka@'s lastest changes do - now the two packages
are independent so golang-google-protobuf can go in?

This would unblock:
1) Some upstream packages that have upgraded to the new library and are
using pregenerated pb.go without the dependency.
2) Packages that have moved/want to move to the new library and generate
pb.go as part of the build (without needing grpc).

And no packages are forced into anything, since upstream needs to do the
update explicitly anyway, the ones using golang-goprotobuf will continue
to function just fine.

I understand not all problems are fixed and some things remain, but it
seems it'd be a step in the right direction since at least some packages
will be able to move forward, without causing any new
complications/regressions.

Or am I missing something?



You are right. The only concern from my side is the usefulness of
golang-google-protobuf without upgrading golang-goprotobuf to 1.4.
If some packages are already ready for using golang-google-protobuf
solely, sure we should try.


Yeah, the reason I'm personally interested in this is I have one package 
I'm upstream for (chasquid) in this situation. I've already done the 
required patching and is blocked on this package.


I am also waiting on the change to move other projects forward for the 
same reason :)


Let me know if there's anything I can do, or how can I help!

Thanks again!
Alberto

Bug#961814: marked as pending in golang-google-protobuf

[Alberto Bertogli]

On Thu, Jan 07, 2021 at 11:12:24PM +0800, Shengjing Zhu wrote:

On Thu, Jan 7, 2021 at 10:59 PM Alberto Bertogli
 wrote:

But those issues are not made worse by allowing golang-google-protobuf
to go in, right?



Let golang-google-protobuf go in is one thing, it's not difficult.
However without golang-goprotobuf 1.4.x it's not useful currently. But
it will be changed if upstream has switched to golang-google-protobuf
only.


But IIUC that's what foka@'s lastest changes do - now the two packages 
are independent so golang-google-protobuf can go in?


This would unblock:
1) Some upstream packages that have upgraded to the new library and are 
   using pregenerated pb.go without the dependency.
2) Packages that have moved/want to move to the new library and generate 
   pb.go as part of the build (without needing grpc).


And no packages are forced into anything, since upstream needs to do the 
update explicitly anyway, the ones using golang-goprotobuf will continue 
to function just fine.


I understand not all problems are fixed and some things remain, but it 
seems it'd be a step in the right direction since at least some packages 
will be able to move forward, without causing any new 
complications/regressions.


Or am I missing something?

Thanks!
Alberto

Bug#961814: marked as pending in golang-google-protobuf

[Alberto Bertogli]

On Thu, Jan 07, 2021 at 04:43:43PM +0800, Shengjing Zhu wrote:

On Thu, Jan 7, 2021 at 2:51 PM Anthony Fok  wrote:


Hi Shengjing,

On Tue, Jan 5, 2021 at 8:42 AM Shengjing Zhu  wrote:
>
> Hi Anthony,

Thanks for writing to me!  Sorry for the late reply.
I was going to re-open this with the pseudo header "Control: reopen
-1" to keep this new version out of testing (buster), but then I
decided to study the issue further, I think we are safe to move
forward, allowing golang-google-protobuf to enter testing, while
keeping the old golang-goprotobuf 1.3.x if necessary.

> The reason that I haven't uploaded new version of this package, is
> that using golang-google-protobuf usually means using
> golang-goprotobuf 1.4+ as well.

Looks like that is not the case any more.
While golang-google-protobuf and protoc-gen-go v1.25.0 would still
pull in the old golang-goprotobuf 1.4+ package in the generated file,
apparently for backward compatibility during the 6-month transition
period that Joe Tsai @dsnet set:

import (
proto "github.com/golang/protobuf/proto"
...
)

Well, I think we have good news!

1.25.0+git20201208.160c747 doesn't do that any more.
The import proto "github.com/golang/protobuf/proto" line is gone;
the "const _ = proto.ProtoPackageIsVersion4" is also gone.

The latest golang-google-protobuf makes a clean break from the past.
It is now self-contained, and no longer pulls in the legacy golang-goprotobuf.
It is just like what you predicted: once GitHub issue #1077 is fixed,
we can move forward.

Thank you for your packaging of golang-google-protobuf which also
allows the clean separation with the old golang-goprotobuf ecosystem.



The problem is currently all upstream still use golang-goprotobuf to
generate pb.go, not the plugin from
https://github.com/protocolbuffers/protobuf-go/tree/master/cmd/protoc-gen-go
If we choose to use this plugin ahead of upstream, and leave
golang-goprotobuf not updated(and not used in B-D), then things will
be fine. But upstream says there are still missing features like grpc
support, which are moved to grpc package itself. I haven't looked at
this part. However it will become a difficult transition, which
involves golang-google-grpc-dev, golang-google-genproto-dev, etc...


But those issues are not made worse by allowing golang-google-protobuf 
to go in, right?


What's blocking golang-google-protobuf from moving to testing now that 
the dependency on golang-goprotobuf is no longer there?


Is the issue that golang-google-protobuf source also builds a 
protoc-gen-go?


Why can't the latter be split, so upstreams that include pre-generated 
.pb.go (as is the official recommendation) can be included in Debian 
as-is using the corresponding dependency?


Thanks!
Alberto

Bug#971123: kxd: FTBFS: dh_auto_test: error: make -j4 test returned exit code 2

[Alberto Bertogli]

On Mon, Sep 28, 2020 at 08:58:41PM +0100, Alberto Bertogli wrote:

On Sun, Sep 27, 2020 at 08:45:30PM +0200, Lucas Nussbaum wrote:

Source: kxd
Version: 0.14-2
Severity: serious
Justification: FTBFS on amd64
Tags: bullseye sid ftbfs
Usertags: ftbfs-20200926 ftbfs-bullseye

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


This is due to a change in x509 certificate handling in Go 1.15. It 
has been fixed in upstream release 0.15.


In this repo you can find an updated Debian package for kxd 1.15; I 
don't have access to upload it to salsa directly, and it would need a 
DD to do a review and upload in any case:


https://blitiri.com.ar/git/r/debian:kxd/


FYI the changes to update kxd to 1.15, which fixes this issue, are in 
the Salsa repository now, https://salsa.debian.org/debian/kxd


This just needs a DD to review and upload.

Thanks,
Alberto

Bug#971123: kxd: FTBFS: dh_auto_test: error: make -j4 test returned exit code 2

[Alberto Bertogli]

On Sun, Sep 27, 2020 at 08:45:30PM +0200, Lucas Nussbaum wrote:

Source: kxd
Version: 0.14-2
Severity: serious
Justification: FTBFS on amd64
Tags: bullseye sid ftbfs
Usertags: ftbfs-20200926 ftbfs-bullseye

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


This is due to a change in x509 certificate handling in Go 1.15. It has 
been fixed in upstream release 0.15.


In this repo you can find an updated Debian package for kxd 1.15; I 
don't have access to upload it to salsa directly, and it would need a DD 
to do a review and upload in any case:


https://blitiri.com.ar/git/r/debian:kxd/

Thanks,
Alberto

Bug#954287: libfiu: FTBFS on amd64/unstable: Segmentation fault (core dumped)

[Alberto Bertogli]

On Sat, Mar 28, 2020 at 11:52:37AM +, Alberto Bertogli wrote:

On Fri, Mar 27, 2020 at 11:58:05PM -, Chris Lamb wrote:

Hi Alberto,


libfiu now fails to build from source in unstable/amd64:

 […]

 ./wrap-python 3 ./test-set_prng_seed.py
 LD_LIBRARY_PATH=../../libfiu/
LD_PRELOAD="../../preload/run/fiu_run_preload.so
../../preload/posix/fiu_posix_preload.so" ./tests/open.bin
 LD_LIBRARY_PATH=../../libfiu/
LD_PRELOAD="../../preload/run/fiu_run_preload.so
../../preload/posix/fiu_posix_preload.so" ./tests/fread.bin
 rm tests/open.bin tests/fread.bin./wrap-python 3 ./test-fiu_ctrl.py
  tests/open64.bin tests/strdup.bin tests/pread.bin tests/pread64.bin
tests/malloc.bin./wrap-python 3 ./test-basic.py
  tests/mmap.bin tests/fprintf.bin tests/kill.bin tests/fopen.bin
 make[4]: Leaving directory '/tmp/buildd/libfiu-1.00/tests/generated'
 ./wrap-python 3 ./test-onetime.py
 ./wrap-python 3 ./test-set_prng_seed-env.py
 make[3]: *** [Makefile:96: py-run-test-failinfo_refcount]
Segmentation fault (core dumped)
 make[3]: *** Waiting for unfinished jobs
 make[4]: Leaving directory '/tmp/buildd/libfiu-1.00/tests/utils'
 rm test-enable_stack test-ferror test-enable_stack_by_name
 make[3]: Leaving directory '/tmp/buildd/libfiu-1.00/tests'
 make[2]: *** [Makefile:58: test] Error 2
 make[2]: Leaving directory '/tmp/buildd/libfiu-1.00'
 dh_auto_test: error: make -j9 test V=1 LC_ALL=C returned exit code 2
 make[1]: *** [debian/rules:33: override_dh_auto_test] Error 25
 make[1]: Leaving directory '/tmp/buildd/libfiu-1.00'
 make: *** [debian/rules:13: binary] Error 2
 dpkg-buildpackage: error: debian/rules binary subprocess returned
exit status 2

 […]

I suspect this to be Python 3.8 related. Alberto, any ideas? :)  The
full build log is attached if it helps.


Indeed it's related to Python 3.8 although I think it just surfaces a 
but that's always existed.


https://blitiri.com.ar/git/r/libfiu/c/ffa89556eda5fc05cd496150880519b575c2908e/
should fix it.

While at it I noticed a few other things so if this fixes the build in 
Debian too, I will probably include it in master and do a release in the 
next few days.


If you try the patch above, please let me know how it goes.

Thanks!
Alberto

Bug#954287: libfiu: FTBFS on amd64/unstable: Segmentation fault (core dumped)

[Alberto Bertogli]

On Fri, Mar 27, 2020 at 11:58:05PM -, Chris Lamb wrote:

Hi Alberto,


libfiu now fails to build from source in unstable/amd64:

  […]

  ./wrap-python 3 ./test-set_prng_seed.py
  LD_LIBRARY_PATH=../../libfiu/
LD_PRELOAD="../../preload/run/fiu_run_preload.so
../../preload/posix/fiu_posix_preload.so" ./tests/open.bin
  LD_LIBRARY_PATH=../../libfiu/
LD_PRELOAD="../../preload/run/fiu_run_preload.so
../../preload/posix/fiu_posix_preload.so" ./tests/fread.bin
  rm tests/open.bin tests/fread.bin./wrap-python 3 ./test-fiu_ctrl.py
   tests/open64.bin tests/strdup.bin tests/pread.bin tests/pread64.bin
tests/malloc.bin./wrap-python 3 ./test-basic.py
   tests/mmap.bin tests/fprintf.bin tests/kill.bin tests/fopen.bin
  make[4]: Leaving directory '/tmp/buildd/libfiu-1.00/tests/generated'
  ./wrap-python 3 ./test-onetime.py
  ./wrap-python 3 ./test-set_prng_seed-env.py
  make[3]: *** [Makefile:96: py-run-test-failinfo_refcount]
Segmentation fault (core dumped)
  make[3]: *** Waiting for unfinished jobs
  make[4]: Leaving directory '/tmp/buildd/libfiu-1.00/tests/utils'
  rm test-enable_stack test-ferror test-enable_stack_by_name
  make[3]: Leaving directory '/tmp/buildd/libfiu-1.00/tests'
  make[2]: *** [Makefile:58: test] Error 2
  make[2]: Leaving directory '/tmp/buildd/libfiu-1.00'
  dh_auto_test: error: make -j9 test V=1 LC_ALL=C returned exit code 2
  make[1]: *** [debian/rules:33: override_dh_auto_test] Error 25
  make[1]: Leaving directory '/tmp/buildd/libfiu-1.00'
  make: *** [debian/rules:13: binary] Error 2
  dpkg-buildpackage: error: debian/rules binary subprocess returned
exit status 2

  […]

I suspect this to be Python 3.8 related. Alberto, any ideas? :)  The
full build log is attached if it helps.


Wondering if you got this? I just got a mail that libfiu will be
"autoremoved" from testing soon.


Ack on this!

Sorry I've been slow to respond, but will take a look at this this 
weekend.


I'll send another email once I know more.

Thanks!
Alberto

Bug#936856: libfiu: Python2 removal in sid/bullseye

[Alberto Bertogli]

On Mon, Sep 09, 2019 at 11:37:24AM +0100, Chris Lamb wrote:

Hi Alberto:


> It will be included in the next release, which is probably due by now :)

Neat. Can we tempt you into releasing this whilst I have Python 2.x on
my mind?


Just doing some other Python 3.x porting at the moment so thought of
this one; any update on your end?


Sorry for the delay, I was away traveling.

libfiu 1.00 has been released with, amongst other things, this fix.

Let me know how it goes!

Thanks!
Alberto

Bug#918520: libfiu: FTBFS randomly when built with eatmydata

[Alberto Bertogli]

On Sun, Apr 28, 2019 at 11:25:22AM +0200, Mattia Rizzolo wrote:

On Mon, Jan 28, 2019 at 05:07:34PM +, Alberto Bertogli wrote:

As far as I can see, this is caused by a bug/race in libeatmydata's
initialization, as described before.

It is not a problem in libfiu, or its tests.


The attached patch for libeatmydata fixes the issue, but it's mostly for
illustration since I don't know how the maintainers would prefer to fix
this, and I have not tested it thoroughly (for example there's a chance of
infinite recursion in some very odd conditions, but it might be better to
leave it on purpose to ease debuggability).


I fail to see those, could you maybe expand on where you think there
could be infinite recursions?


Looking at this again, and digging around my git repository, I think I 
wrote this note based on a previous iteration of the patch.


I think the patch in your email fixes the problems I was originally 
worried about, and can't find any infinite recursion paths right now.


Sorry for the confusion!

Thanks!
Alberto

Bug#918520: libfiu: FTBFS randomly when built with eatmydata

[Alberto Bertogli]

On Mon, Jan 28, 2019 at 03:13:46PM +, Alberto Bertogli wrote:
I'll dig in a bit more and see if I can fix libeatmydata, but it might 
end up being too invasive and time consuming.  I'll send another 
message once I know more.


As far as I can see, this is caused by a bug/race in libeatmydata's 
initialization, as described before.


It is not a problem in libfiu, or its tests.


The attached patch for libeatmydata fixes the issue, but it's mostly for 
illustration since I don't know how the maintainers would prefer to fix 
this, and I have not tested it thoroughly (for example there's a chance 
of infinite recursion in some very odd conditions, but it might be 
better to leave it on purpose to ease debuggability).


https://blitiri.com.ar/tmp/eatmydata-safe-init.patch


Thanks!
Alberto

>From 72a074fde1b722a3e784a3648a34cd58c3196598 Mon Sep 17 00:00:00 2001
From: Alberto Bertogli 
Date: Mon, 28 Jan 2019 15:39:31 +
Subject: [PATCH] Make initialization thread-safe, and support early callers

The current initialization code is not thread-safe, and assumes that the
only possible caller of open() before initialization completes is
dlsym(), which is not the case if there are other preloaded libraries.

This patch makes the initialization thread-safe by using thread-local
variables, and adjusts the recursive checking logic to support early
callers.

See Debian bug #918520 for more background:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918520
---
 configure.ac|  2 +
 libeatmydata/libeatmydata.c | 39 ++-
 m4/ax_tls.m4| 74 +
 3 files changed, 98 insertions(+), 17 deletions(-)
 create mode 100644 m4/ax_tls.m4

diff --git a/configure.ac b/configure.ac
index 7343e0a..140387a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -51,6 +51,8 @@ AC_CHECK_DECLS(sync_file_range)
 AC_CHECK_FUNCS(sync_file_range)
 AC_CHECK_FUNCS(open64)
 
+AX_TLS(:,:)
+
 AC_CONFIG_FILES(Makefile libeatmydata.spec)
 
 AC_OUTPUT
diff --git a/libeatmydata/libeatmydata.c b/libeatmydata/libeatmydata.c
index 991146b..b54a98b 100644
--- a/libeatmydata/libeatmydata.c
+++ b/libeatmydata/libeatmydata.c
@@ -50,19 +50,23 @@ typedef int (*libc_sync_file_range_t)(int, off64_t, off64_t, unsigned int);
 typedef int (*libc_fcntl_t)(int, int, ...);
 #endif
 
-static libc_open_t libc_open= NULL;
+/* All the following are thread-local, to avoid initialization races between
+ * threads. */
+static TLS int init_running = 0;
+static TLS int init_complete = 0;
+static TLS libc_open_t libc_open= NULL;
 #ifdef HAVE_OPEN64
-static libc_open64_t libc_open64= NULL;
+static TLS libc_open64_t libc_open64= NULL;
 #endif
-static libc_fsync_t libc_fsync= NULL;
-static libc_sync_t libc_sync= NULL;
-static libc_fdatasync_t libc_fdatasync= NULL;
-static libc_msync_t libc_msync= NULL;
+static TLS libc_fsync_t libc_fsync= NULL;
+static TLS libc_sync_t libc_sync= NULL;
+static TLS libc_fdatasync_t libc_fdatasync= NULL;
+static TLS libc_msync_t libc_msync= NULL;
 #ifdef HAVE_SYNC_FILE_RANGE
-static libc_sync_file_range_t libc_sync_file_range= NULL;
+static TLS libc_sync_file_range_t libc_sync_file_range= NULL;
 #endif
 #if defined(F_FULLFSYNC) && defined(__APPLE__)
-static libc_fcntl_t libc_fcntl= NULL;
+static TLS libc_fcntl_t libc_fcntl= NULL;
 #endif
 
 #define ASSIGN_DLSYM_OR_DIE(name)			\
@@ -87,7 +91,7 @@ void __attribute__ ((constructor)) eatmydata_init(void);
 
 void __attribute__ ((constructor)) eatmydata_init(void)
 {
-	initing = 1;
+	init_running++;
 	ASSIGN_DLSYM_OR_DIE(open);
 #ifdef HAVE_OPEN64
 	ASSIGN_DLSYM_OR_DIE(open64);
@@ -102,13 +106,14 @@ void __attribute__ ((constructor)) eatmydata_init(void)
 #if defined(F_FULLFSYNC) && defined(__APPLE__)
 	ASSIGN_DLSYM_OR_DIE(fcntl);
 #endif
-	initing = 0;
+	init_running--;
+	init_complete++;
 }
 
 static int eatmydata_is_hungry(void)
 {
 	/* Init here, as it is called before any libc functions */
-	if(!libc_open)
+	if(!init_complete)
 		eatmydata_init();
 
 #ifdef CHECK_FILE
@@ -164,9 +169,9 @@ int LIBEATMYDATA_API open(const char* pathname, int flags, ...)
 #endif
 	va_end(ap);
 
-	/* In pthread environments the dlsym() may call our open(). */
-	/* We simply ignore it because libc is already loaded   */
-	if (initing) {
+	/* If we get called recursively during initialization (which should
+	 * be rare but might happen), just fail. */
+	if (init_running > 0) {
 		errno = EFAULT;
 		return -1;
 	}
@@ -191,9 +196,9 @@ int LIBEATMYDATA_API open64(const char* pathname, int flags, ...)
 #endif
 	va_end(ap);
 
-	/* In pthread environments the dlsym() may call our open(). */
-	/* We simply ignore it because libc is already loaded   */
-	if (initing) {
+	/* If we get called recursively during initialization (which should
+	 * be rare but might happen), just fail. */
+	if (init_running > 0) {
 		errno = EFAULT;
 		return -1;
 	}
diff --git a/m4/ax_tls.m4 b/m4/ax_tls.m4
new file mode 1006

Bug#918520: libfiu: FTBFS randomly when built with eatmydata

[Alberto Bertogli]

On Tue, Jan 22, 2019 at 11:17:41AM +, Chris Lamb wrote:

Hi Alberto,


> It could be a couple of weeks before I get time to do this though, as
> I'm away on holidays


No problem; have you managed to get anywhere? :)


I've been looking at this today.

There are some bugs and races in libeatmydata wrt. early initialization 
and threading that I think are the root cause.


If libeatmydata's open() wrapper gets called while libeatmydata's 
constructor is running, it assumes it's because a recursive call in 
dlsym() and makes open() return EFAULT:

https://git.launchpad.net/libeatmydata/tree/libeatmydata/libeatmydata.c#n167

This has a few problems: 1) the check for "is the constructor 
running" is not thread safe; and 2) the assumption about dlsym() is 
wrong.



In the libfiu tests that are failing, it is libfiu's initialization that 
calls open(), not dlsym(), hitting the problem #2 (and also possibly #1).


So libfiu calls open() -> libmetadats's open() -> return EFAULT.
This causes libfiu's initialization fail, and in turn causes the test to 
fail/hang.



I believe this is not happening in the exact same spot all the time 
because the libfiu test triggering this issue is multi-process and 
multi-thread, so depending on the kernel scheduling decisions, which 
thread calls libeatmydata's constructor can change.


In addition, as the check in libeatmydata is also not thread safe, it 
probably adds to the noise and unpredictability.



I'll dig in a bit more and see if I can fix libeatmydata, but it might 
end up being too invasive and time consuming.  I'll send another message 
once I know more.


Thanks!
Alberto

Bug#918520: libfiu: FTBFS randomly when built with eatmydata

[Alberto Bertogli]

On Mon, Jan 07, 2019 at 08:02:12PM +, Alberto Bertogli wrote:
I'll follow up on the ssh offer separately and post my findings later. 
It could be a couple of weeks before I get time to do this though, as 
I'm away on holidays and this seems to be low priority.


FYI thanks to Santiago's kind offer of access to the failing 
environment, I could investigate and then reproduce this issue locally.


Indeed a single test is hanging when ran wrapped with eatmydata.

That test uses some tricky combination with pipes and early 
initialization and I suspect there is some race which eatmydata brings 
up to light, even though there is no sync going on, but it's too early 
to tell for sure.


I'll continue to investigate and will let you know once I have a better 
understanding of what's going on, and a fix.


Thanks,
Alberto

Bug#918520: libfiu: FTBFS randomly when built with eatmydata

[Alberto Bertogli]

On Sun, Jan 06, 2019 at 11:26:01PM +0100, Chris Lamb wrote:

[Adding albert...@blitiri.com.ar to CC]

Dear Santiago,


It is a "just in case". The offer to ssh into my machine is a blurb
which I now add to all my bug reports when the problem is "weird",
for example, when it does not seem to happen in buildd.debian.org or
reproducible-builds.


Awesome -- I just checking as it is somewhat unusual to receive
that offer and I was just 100% confirming before I potenaily spent
cycles on this and I was missing something..

I'm tempted to think that upstream (CC'd) might have an idea at this
stage...? :)


I don't!

libfiu doesn't particularly care for data persistency, there's not a 
single sync/fsync/etc. call.


But it could be a tight race in the build rules that eatmydata makes it 
more prone to manifest.


I'll follow up on the ssh offer separately and post my findings later. 
It could be a couple of weeks before I get time to do this though, as 
I'm away on holidays and this seems to be low priority.


Thanks!
Alberto

Bug#911733: libfiu: FTBFS on 32-bit architectures?

[Alberto Bertogli]

On Wed, Oct 24, 2018 at 11:17:56PM -0400, Chris Lamb wrote:

Hi Alberto,

I think this is what we need:

 
https://salsa.debian.org/lamby/pkg-libfiu/commit/f80fb7ab3a96fe206e8610fc1f01dd1b370f206e


Thanks a lot, applied!

Alberto

Bug#909843: libfiu: frequent parallel FTBFS

[Alberto Bertogli]

On Mon, Oct 01, 2018 at 10:34:51AM +0100, Chris Lamb wrote:

Hi Alberto,


I think this newly written patch fixes the problem:
https://blitiri.com.ar/git/r/libfiu/c/b4c21a6b2a714c1ad9cdfe96358f843688c3a77e/


Still no way of getting a patch from the web interface, out of
interest?


Just implemented it :)

Append ".patch" to the commit base path, like this:
https://blitiri.com.ar/git/r/libfiu/c/0d4f662733045f0e3f6e2936e94518cd4186129e.patch

Let me know if something doesn't work, I did this 5s ago so there could 
be bugs or issues.




I'm having a problem even getting this from the git
repository itself:

 $ git clone https://blitiri.com.ar/repos/libfiu
 $ cd libfiu
 $ git show b4c21a6b2a714c1ad9cdfe96358f843688c3a77e
 fatal: bad object b4c21a6b2a714c1ad9cdfe96358f843688c3a77e


Sorry, my bad. I rebased the branch afterwards (for unrelated reasons).

Try commit: 0d4f662733045f0e3f6e2936e94518cd4186129e

https://blitiri.com.ar/git/r/libfiu/c/0d4f662733045f0e3f6e2936e94518cd4186129e/
https://blitiri.com.ar/git/r/libfiu/c/0d4f662733045f0e3f6e2936e94518cd4186129e.patch

Thanks,
Alberto

Bug#909843: libfiu: frequent parallel FTBFS

[Alberto Bertogli]

On Sat, Sep 29, 2018 at 06:45:53PM +0100, Alberto Bertogli wrote:

On Sat, Sep 29, 2018 at 03:36:51PM +0300, Adrian Bunk wrote:

./wrap-python 2 ./test-fiu_ctrl.py
./wrap-python 2 ./test-basic.py
cc -I../../libfiu/ -L../../libfiu/ -D_XOPEN_SOURCE=600 -D_GNU_SOURCE -fPIC 
-DFIU_ENABLE=1 -g -O2 -fdebug-prefix-map=/build/libfiu-0.96=. 
-fstack-protector-strong -Wformat -Werror=format-security -std=c99 -pedantic 
-Wall -std=c99 -pedantic -Wall tests/open.c -lfiu -o tests/open.bin
Traceback (most recent call last):
File "./test-fiu_ctrl.py", line 21, in 
  cmd = run_cat()
File "./test-fiu_ctrl.py", line 16, in run_cat
  return fiu_ctrl.Subprocess(["./small-cat"],
AttributeError: 'module' object has no attribute 'Subprocess'


This is weird.

fiu_ctrl.py definitely defines a class Subprocess, so if the file is 
there and with the proper contents, this should work.


I think this might be caused by building python2 and python3 in 
parallel, because both builds could attempt to generate fiu_ctrl.py 
and they might be stepping onto each other, to the point where one 
copies a partial (or empty) file as the module.


But that's just a wild theory at this point, I will look into it a bit 
more and post again once I have any news.


I think that's what happened.

I can't reproduce it despite multiple runs, probably because of the race 
being too small in my laptop; however, everything I've seen points to 
this being the cause.


I think this newly written patch fixes the problem:
https://blitiri.com.ar/git/r/libfiu/c/b4c21a6b2a714c1ad9cdfe96358f843688c3a77e/


Chris, if you want to give the above patch a try, please go ahead.

That said, I'm going to cut a release soon (I'm waiting on someone's 
confirmation of other unrelated patches), so you might want to consider 
waiting instead :)


Thanks!
Alberto

Bug#909843: libfiu: frequent parallel FTBFS

[Alberto Bertogli]

On Sat, Sep 29, 2018 at 03:36:51PM +0300, Adrian Bunk wrote:

./wrap-python 2 ./test-fiu_ctrl.py
./wrap-python 2 ./test-basic.py
cc -I../../libfiu/ -L../../libfiu/ -D_XOPEN_SOURCE=600 -D_GNU_SOURCE -fPIC 
-DFIU_ENABLE=1 -g -O2 -fdebug-prefix-map=/build/libfiu-0.96=. 
-fstack-protector-strong -Wformat -Werror=format-security -std=c99 -pedantic 
-Wall -std=c99 -pedantic -Wall tests/open.c -lfiu -o tests/open.bin
Traceback (most recent call last):
 File "./test-fiu_ctrl.py", line 21, in 
   cmd = run_cat()
 File "./test-fiu_ctrl.py", line 16, in run_cat
   return fiu_ctrl.Subprocess(["./small-cat"],
AttributeError: 'module' object has no attribute 'Subprocess'


This is weird.

fiu_ctrl.py definitely defines a class Subprocess, so if the file is 
there and with the proper contents, this should work.


I think this might be caused by building python2 and python3 in 
parallel, because both builds could attempt to generate fiu_ctrl.py and 
they might be stepping onto each other, to the point where one copies a 
partial (or empty) file as the module.


But that's just a wild theory at this point, I will look into it a bit 
more and post again once I have any news.


Thanks,
Alberto

Bug#902363: fix build with ld --as-needed

[Alberto Bertogli]

On Mon, Jul 02, 2018 at 10:05:53AM +0100, Chris Lamb wrote:

Hi Alberto,


>FYI I needed to clone the repo to get the "real" patch; does git-arr
>support getting the .diff directly?

Not yet. If you'd find this feature useful, it would be quite easy to
implement, so please let me know.


Please do so; I'm now a bit spoiled using it from $platform from doing
security updates where I don't particularly want to litter my harddrive
with countless repositories when I just want to pull a single patch out
of it...


Sure, I'll add this and let you know (off bug to avoid adding more noise).



>Oh, and git://blitiri.com.ar/libfiu
>failed for me… ;)

This is intentional, I disabled git:// a few months ago  [..] I
think I've updated all references in the documentation but please let
me know if something slipped.


The primary homepage, perhaps? eg. https://blitiri.com.ar/p/libfiu/  :)


Crap, thanks for letting me know :S

Fixed!

Alberto

Bug#902363: fix build with ld --as-needed

[Alberto Bertogli]

On Sat, Jun 30, 2018 at 08:58:08PM +0100, Chris Lamb wrote:

tags 902363 + pending
thanks

Dear Alberto,


https://blitiri.com.ar/git/r/libfiu/c/633bd2ae5d89850fecf71161bc74f21c04904c5b/

Would you mind giving it a try?


Sure thing - uploaded!


Thanks!



FYI I needed to clone the repo to get the "real" patch; does git-arr
support getting the .diff directly?


Not yet. If you'd find this feature useful, it would be quite easy to 
implement, so please let me know.




Oh, and git://blitiri.com.ar/libfiu
failed for me… ;)


This is intentional, I disabled git:// a few months ago as it was almost 
never used and significantly less secure than the https transport.
I think I've updated all references in the documentation but please let 
me know if something slipped.


Thanks again,
Alberto

Bug#902363: fix build with ld --as-needed

[Alberto Bertogli]

On Sat, Jun 30, 2018 at 08:39:47AM +0100, Chris Lamb wrote:

Chris Lamb wrote:


Hi Matthias & Alberto,

> Fix the build with ld --as-needed.
>
> patch at
> http://launchpadlibrarian.net/375907137/libfiu_0.96-3_0.96-3ubuntu1.diff.gz

Alberto, any thoughts on this? :)


Interesting!


Indeed, in my amd64 laptop running debian testing:

$ gcc -Wl,--as-needed -x c /dev/null -lc -shared -o build-libccheck.so
$ ldd build-libccheck.so
   statically linked

This breaks the ability to build the posix preloader, as we cannot find 
the libc soname from this (libc is not linked in, despite the -lc).


clang does not exhibit this behaviour, but that might be a matter of 
time.



I've submitted a different fix in the "next" branch, which makes the 
dummy library actually use a libc function, so it has to be linked in.

This _should_ make the build a bit more robust in a more generic way.

https://blitiri.com.ar/git/r/libfiu/c/633bd2ae5d89850fecf71161bc74f21c04904c5b/

Would you mind giving it a try?



Gentle ping? :)


Sorry for the delay, I was away on holidays and just came back!

Thanks!
Alberto

Bug#895464: dnss FTBFS: FAIL: TestEndToEnd

[Alberto Bertogli]

On Thu, Apr 12, 2018 at 11:04:34PM +0100, Alberto Bertogli wrote:

On Wed, Apr 11, 2018 at 10:29:32PM +0300, Adrian Bunk wrote:

Some recent change in unstable makes dnss FTBFS:

https://tests.reproducible-builds.org/debian/history/dnss.html
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/dnss.html

...
=== RUN   TestEndToEnd
--- FAIL: TestEndToEnd (0.00s)
dnss_test.go:107: error parsing zone: dns: missing TTL with no previous value: 
"A" at line: 1:13


Thanks for letting me know about this.

This was fixed on 2017-10-03 by commit befaea2, I'm surprised it did 
not come up earlier.


https://blitiri.com.ar/git/r/dnss/c/befaea21c4632c7c4fd9988065ccde39d271573e/


I've been making some changes to dnss lately and wanted to advance the 
Debian package soon, so another option is to wait ~a couple of days 
and just make a more up to date package that includes that fix.


dnss 0.0~git20180415.0.18b15770-1 was uploaded yesterday and it includes 
the fix for this problem.


Thanks,
Alberto

Bug#895464: dnss FTBFS: FAIL: TestEndToEnd

[Alberto Bertogli]

On Wed, Apr 11, 2018 at 10:29:32PM +0300, Adrian Bunk wrote:

Source: dnss
Version: 0.0~git20170810.0.860d2af1-1
Severity: serious

Some recent change in unstable makes dnss FTBFS:

https://tests.reproducible-builds.org/debian/history/dnss.html
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/dnss.html

...
=== RUN   TestEndToEnd
--- FAIL: TestEndToEnd (0.00s)
dnss_test.go:107: error parsing zone: dns: missing TTL with no previous value: 
"A" at line: 1:13


Thanks for letting me know about this.

This was fixed on 2017-10-03 by commit befaea2, I'm surprised it did not 
come up earlier.


https://blitiri.com.ar/git/r/dnss/c/befaea21c4632c7c4fd9988065ccde39d271573e/


I've been making some changes to dnss lately and wanted to advance the 
Debian package soon, so another option is to wait ~a couple of days and 
just make a more up to date package that includes that fix.


Thanks,
Alberto

Bug#894776: libfiu: please make the function_lile file reproducible

[Alberto Bertogli]

On Wed, Apr 04, 2018 at 08:43:31AM +0100, Chris Lamb wrote:
> Hi Alberto,
> 
> I'm seeing the following reproducibility issue in libfiu:
> 
> │ │ │ ├── ./usr/share/doc/fiu-utils/function_list.gz
> │ │ │ │ ├── function_list
> │ │ │ │ │ @@ -133,7 +133,14 @@
> │ │ │ │ │  forkposix/proc/fork
> │ │ │ │ │  waitposix/proc/wait
> │ │ │ │ │  waitpid posix/proc/waitpid
> │ │ │ │ │  waitid  posix/proc/waitid
> │ │ │ │ │  killposix/proc/kill
> │ │ │ │ │  signal  posix/proc/signal
> │ │ │ │ │  sigaction   posix/proc/sigaction
> │ │ │ │ │ +forkposix/proc/fork
> │ │ │ │ │ +waitposix/proc/wait
> │ │ │ │ │ +waitpid posix/proc/waitpid
> │ │ │ │ │ +waitid  posix/proc/waitid
> │ │ │ │ │ +killposix/proc/kill
> │ │ │ │ │ +signal  posix/proc/signal
> │ │ │ │ │ +sigaction   posix/proc/sigaction
> 
>   
> 
> 
> Could you guess why this happens? It seems like "just" a duplication
> but I can't see how this might happen as the original is always
> overridden by a "cp.."

Thanks for finding this!

It's another build race, triggered by the parallel make :S

Can you give this patch a try?
https://blitiri.com.ar/git/r/libfiu/c/527317f4a90045c061cada3adb40417efd489aa4/

Thanks!
Alberto

Bug#893049: libfiu FTBFS: recipe for target 'run-test-basic_ctrl.py' failed

[Alberto Bertogli]

On Sun, Mar 25, 2018 at 09:43:44PM +0100, Chris Lamb wrote:
> tags 893049 + fixed-upstream
> thanks
> 
> Hi Alberto,
> 
> > That also explains why it works when you go to the failed directory and
> > run it manually.
> 
> Ahh! Of course. :-)
> 
> > Can you give this patch a try?
> > https://blitiri.com.ar/git/r/libfiu/c/053239cab98817561187dfca491203401fae5b9c/
> 
> Works for me; looking forward to the new release!

Great!

Will try to cut it today, but might get pushed to tomorrow depending on
how the rest of my evening goes.


> (FYI did you see the SYNOPSIS → SYNOPSYS typo correction?)

Yes, I merged that patch last year (but thanks for checking! :)

Thanks!
Alberto

Bug#893049: libfiu FTBFS: recipe for target 'run-test-basic_ctrl.py' failed

[Alberto Bertogli]

On Fri, Mar 16, 2018 at 03:28:24PM +, Chris Lamb wrote:
> Hi Alberto and Adrian
> 
> > https://github.com/lamby/pkg-libfiu/commit/9bf63e144117fbd382f4053a4338041b975b8c67
> […]
> > Thanks for coming up with a patch for this!
> 
> Actually the patch doesn't work. Or, rather, it's stranger than that. If
> I build the package using fairly vanilla scripts (or on the official buildds
> as Adrian as pointed out and reopened to match) the package fails to build,
> even with this patch.
> 
> However, if I then go into the failed build directory and run `make test`
> the test passes (same chroot/container!). Does that help diagnose it at
> all? :)

It does!  Sorry for the delay in replying.

It's a build race issue.  I managed to reproduce this locally by running
with -j 8 (but weirdly, not if I teed its output!).

That also explains why it works when you go to the failed directory and
run it manually.


Can you give this patch a try?
https://blitiri.com.ar/git/r/libfiu/c/053239cab98817561187dfca491203401fae5b9c/

Once you confirm it works (fingers crossed), I'll include it in the
master branch and cut a new release (it's been a while and there are
other changes as well).

Thanks a lot!
Alberto

Bug#893049: libfiu FTBFS: recipe for target 'run-test-basic_ctrl.py' failed

[Alberto Bertogli]

On Fri, Mar 16, 2018 at 02:08:54AM +, Chris Lamb wrote:
> > https://buildd.debian.org/status/package.php?p=libfiu=sid
> > 
> > ...
> > ./generate-test -c tests/malloc.conf -o tests/malloc.c
> > make[4]: Leaving directory '/<>/tests/generated'
> > make[4]: Entering directory '/<>/tests/utils'
> > LD_LIBRARY_PATH=../../libfiu/ ./test-basic_ctrl.py > 
> > output-test-basic_ctrl.py.txt 2>&1
> > Makefile:38: recipe for target 'run-test-basic_ctrl.py' failed
> > make[4]: *** [run-test-basic_ctrl.py] Error 1
> 
> Adrian, I've fixed this in Git, pending upload:
> 
>   
> https://github.com/lamby/pkg-libfiu/commit/55bcc37af0b142ddd4e121802df8ebb45e723d9e

I get a 404 on that one, is it a previous version of:
https://github.com/lamby/pkg-libfiu/commit/9bf63e144117fbd382f4053a4338041b975b8c67
?

Thanks for coming up with a patch for this!


> Alberto, do you know why this is now required? (Feel free to take
> the patch upstream, naturally...)

I don't know, but it seems suspicious.

Unfortunately I may not have a chance to look at this until next week,
but I'll investigate and let you know.

Thanks!
Alberto

Bug#882801: chromium: segfaults like crazy

[Alberto Bertogli]

Just FYI, I'm also seeing this.

On an up to date Debian testing, same version (62.0.3202.89-1).

I can reproduce it on a fresh profile, and also incognito is affected,
so it's completely unusable.
-g makes no difference in my case (also crashes).


If I "rm -r ~/.config/chromium" and then run "chromium --incognito", it
opens and runs for about 4m of light use (browsing simple websites in
two tabs, for example) before crashing.  Subsequent runs crash right
after launching.

This seems to be 100% reproducible here.


Traceback obtained with gdb:

Thread 1 "chromium" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt  
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x7fffec49319a in __GI_abort () at abort.c:89
#2  0x5754ebc5 in base::debug::BreakDebugger() ()
#3  0x57568835 in logging::LogMessage::~LogMessage() ()
#4  0x567a75be in 
content::RenderProcessHostImpl::GetProcessHostForSiteInstance(content::BrowserContext*,
 content::SiteInstanceImpl*) ()
#5  0x56836fe7 in content::SiteInstanceImpl::GetProcess() ()
#6  0x5685fb5e in 
content::WebContentsImpl::Init(content::WebContents::CreateParams const&) ()
#7  0x5685d5d6 in 
content::WebContentsImpl::CreateWithOpener(content::WebContents::CreateParams 
const&, content::FrameTreeNode*) ()
#8  0x587a6cac in chrome::Navigate(chrome::NavigateParams*) ()
#9  0x587b437d in 
StartupBrowserCreatorImpl::OpenTabsInBrowser(Browser*, bool, 
std::vector const&) ()
#10 0x587b5df9 in 
StartupBrowserCreatorImpl::RestoreOrCreateBrowser(std::vector const&, StartupBrowserCreatorImpl::BrowserOpe
nBehavior, unsigned int, bool, bool) ()
#11 0x587b64b1 in 
StartupBrowserCreatorImpl::ProcessLaunchUrlsUsingConsolidatedFlow(bool, 
std::vector const&) ()
#12 0x587b66d8 in StartupBrowserCreatorImpl::Launch(Profile*, 
std::vector const&, bool) ()
#13 0x587b2c7d in 
StartupBrowserCreator::LaunchBrowser(base::CommandLine const&, Profile*, 
base::FilePath const&, chrome::startup::IsProcessStartup, chrome::startup::
IsFirstRun) ()
#14 0x587b37b8 in 
StartupBrowserCreator::ProcessCmdLineImpl(base::CommandLine const&, 
base::FilePath const&, bool, Profile*, std::vector const&) ()
#15 0x587b3aba in StartupBrowserCreator::Start(base::CommandLine 
const&, base::FilePath const&, Profile*, std::vector > const&) ()
#16 0x57484e61 in ChromeBrowserMainParts::PreMainMessageLoopRunImpl() ()
#17 0x57485160 in ChromeBrowserMainParts::PreMainMessageLoopRun() ()
#18 0x5659f8f4 in content::BrowserMainLoop::PreMainMessageLoopRun() ()  

#19 0x5683dfba in content::StartupTaskRunner::RunAllTasksNow() ()   
   
#20 0x565a26f6 in content::BrowserMainLoop::CreateStartupTasks() ()
#21 0x565a42ab in 
content::BrowserMainRunnerImpl::Initialize(content::MainFunctionParams const&) 
()
#22 0x5659f05f in content::BrowserMain(content::MainFunctionParams 
const&) ()
#23 0x572e9e0b in content::ContentMainRunnerImpl::Run() ()
#24 0x572f1210 in service_manager::Main(service_manager::MainParams 
const&) ()
#25 0x572e9514 in content::ContentMain(content::ContentMainParams 
const&) ()
#26 0x5613512c in ChromeMain ()
#27 0x7fffec47e561 in __libc_start_main (main=0x561241ef , 
argc=9, argv=0x7fffdeb8, init=, fini=, 
rtld_fini=,
stack_end=0x7fffdea8) at ../csu/libc-start.c:297
   
#28 0x56134fba in _start () 
   


I hope this helps!

Thanks!
Alberto

Bug#875490: ITP: golang-blitiri-go-spf -- SPF (Sender Policy Framework) implementation in Go

[Alberto Bertogli]

Package: wnpp
Severity: wishlist
Owner: Alberto Bertogli <albert...@blitiri.com.ar>

* Package name: golang-blitiri-go-spf
  Version : 0.0~git20170821.0.33aa985-1
  Upstream Author : Alberto Bertogli <albert...@blitiri.com.ar>
* URL : https://blitiri.com.ar/git/r/spf/
* License : MIT (Expat)
  Programming Lang: Go
  Description : SPF (Sender Policy Framework) implementation in Go

blitiri.com.ar/go/spf is an open source implementation of the Sender Policy
Framework (SPF) in Go.

It is used by the chasquid SMTP server (package "chasquid"), and will soon be
a dependency of it.

Bug#875489: ITP: golang-blitiri-go-systemd -- Utilities to interact with systemd sockets in Go

[Alberto Bertogli]

Package: wnpp
Severity: wishlist
Owner: Alberto Bertogli <albert...@blitiri.com.ar>

* Package name: golang-blitiri-go-systemd
  Version : 0.0~git20170821.0.aec3508-1
  Upstream Author : Alberto Bertogli <albert...@blitiri.com.ar>
* URL : https://blitiri.com.ar/git/r/systemd/
* License : MIT (Expat)
  Programming Lang: Go
  Description : Utilities to interact with systemd sockets in Go

systemd is a Go package implementing a way to get network listeners from
systemd, similar to C's sd_listen_fds() and sd_listen_fds_with_names().

Supports named file descriptors, which is useful if your daemon needs to be
able to tell the different ports apart (e.g. http vs https).

It can be used by daemons to listen on privileged ports without needing to run
as root.


This will soon be a dependency for package "chasquid".

Bug#875486: ITP: golang-blitiri-go-log -- Simple logging library in Go

[Alberto Bertogli]

Package: wnpp
Severity: wishlist
Owner: Alberto Bertogli <albert...@blitiri.com.ar>

* Package name: golang-blitiri-go-log
  Version : 0.0~git20170910.0.2b2e1b6-1
  Upstream Author : Alberto Bertogli <albert...@blitiri.com.ar>
* URL : https://blitiri.com.ar/git/r/log/
* License : MIT (Expat)
  Programming Lang: Go
  Description : Simple logging library in Go

blitiri.com.ar/go/log is a Go package implementing a simple logger.

It implements an API somewhat similar to glog, with a focus towards simplicity
and integration with standard tools such as systemd.


This will soon be a dependency for package "chasquid".

Bug#870673: cryptsetup causes piuparts test to fail

[Alberto Bertogli]

Package: cryptsetup
Version: 2:1.7.3-4
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

A new version of the kxc package fails piuparts due to cryptsetup not being
able to be removed correctly.

I belive this is unrelated to kxc itself, and it's blocking the move to
testing.

https://piuparts.debian.org/sid/fail/kxc_0.13+git20170730.6182dc8-1.log

Relevant extract from the log (output of apt-get remove):

  Removing kxc (0.13+git20170730.6182dc8-1) ...
  Removing cryptsetup (2:1.7.3-4) ...
  /dev/mapper/control: open failed: No such device
  Failure to communicate with kernel device-mapper driver.
  Check that device-mapper is available in the kernel.
  Incompatible libdevmapper 1.02.137 (2016-11-30) and kernel driver (unknown 
version).
  Command failed


Interestingly, the same output is in the passing cryptsetup piupart run
(https://piuparts.debian.org/sid/pass/cryptsetup_2:1.7.3-4.log), but I cannot
see anything else failing so I'm hoping you can take a look and see if you
know why this would cause a failure on an unrelated package.

Thanks a lot!
Alberto

Bug#868973: kxd: FTBFS: Test failures

[Alberto Bertogli]

On Wed, Jul 19, 2017 at 10:26:20PM +0200, Lucas Nussbaum wrote:
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build on
> amd64.

Thanks for the report!

I think this is something that has been fixed since 0.12, and updating
to a newer version should solve it.

I'm talking with Maxy about doing this, so hopefully this will be fixed
before 17/August (the autoremoval deadline).

Alberto

Bug#851927: Raise severity?

[Alberto Bertogli]

Hi!

So now that testing is frozen in preparation for the upcoming release,
the behaviour users of the next Debian stable will be:

 - Cannot install extensions from the standard store (as they do in all
   other platforms).
 - Extensions they already have will stop working.
 - They won't be able to use Debian's package manager to install
   extensions either, as there is only a single one available.

While a workaround exists (editing a file in /etc), I think it's not
practical to expect users of a web browser know how to do it.


This situation seems quite unfortunate and I think will, in practice,
end up affecting a lot of users, specially the non-technical ones.

Can you consider raising the priority of this issue to serious/critical,
and allowing extensions by default again?

Thanks,
Alberto

Bug#846159: ITP: dnss -- Tool for encapsulating DNS over HTTPS or GRPC

[Alberto Bertogli (debian)]

Package: wnpp
Severity: wishlist
Owner: Alberto Bertogli (debian) <albert...@blitiri.com.ar>

* Package name: dnss
  Version : 0.0~git20161126.0.162090e-1
  Upstream Author : Alberto Bertogli <albert...@blitiri.com.ar>
* URL : https://blitiri.com.ar/git/r/dnss/
* License : Apache-2.0
  Programming Lang: Go
  Description : Tool for encapsulating DNS over HTTPS or GRPC

dnss is a tool for encapsulating DNS over more secure protocols, like HTTPS or
GRPC.

In HTTPS mode, it can act as a DNS-over-HTTPS proxy, using
https://dns.google.com (or any other with the same API) as a server.

For GRPC, it can act as a proxy that listens to DNS requests and pass them on
to a server using GRPC, and also as a GRPC server which resolves the queries
using a normal, fixed DNS server.

Bug#618862: [systemd-devel] Debian Bug#618862: systemd: ignores keyscript in crypttab - a possible solution

[Alberto Bertogli]

I hit this issue after upgrading a system that used keyscript to Jessie,
and it would no longer boot with systemd [1].

That led me to look into adding a password agent for my use case, and/or
creating a generic one that would invoke keyscripts as a workaround...


On Wed, Feb 05, 2014 at 12:16:00AM +0100, Lennart Poettering wrote:
 On Thu, 30.01.14 10:40, David Härdeman (da...@hardeman.nu) wrote:
 
  a) getting the name of the cryptdev that the password request
  corresponds to currently involves parsing the prompt message
  (Please enter passphrase for disk %s!) which is obviously not a
  real solution...
  
  This issue is fixable with minor upstream changes, e.g. by extending
  the PasswordAgent protocol to add Subsystem=cryptsetup and
  Target=diskname entries to the ask. file.
 
 I'd be fine with adding a field Id= or so, which then is filled by an
 identifier of some kind be the cryptsetup tool that is useful to
 identify the device to query things on. for example:
 Id=cryptsetup:/dev/sda5 or so could be one way how this could be
 filled in. We wouldn't enfoce any kind of syntax on this, just suggest
 some common sense so that people choose identifiers that are unlikely to
 clash with other subsystems, and somewhat reasonable to read...

... and I ran into a problem with this, because in practise this field
can look like:

  Id=cryptsetup:ST1234AB567-1CD234 (cbackups) on /var/backups/

for a crypttab line like:

  cbackups /dev/disk/by-id/ata-ST1234AB567-1CD234_1XY2ZWAB-part2 cbackups 
luks,keyscript=/usr/bin/kxc-cryptsetup


because it comes from the name, which seems to be constructed for
human consumption, at
http://cgit.freedesktop.org/systemd/systemd/tree/src/cryptsetup/cryptsetup.c#n596

So a password agent _still_ needs to resort to brittle parsing of the
Id field in order to find the corresponding crypttab entry.


Would changing get_password() to take an additional id, which would be
the volume name (argv[2]), and use that for the ask_password_auto() id,
be ok with you?

That would allow password agents to have a reliable id to work with
without doing brittle parsing, and matching what's in crypttab.


In theory, existing code should not need to adjust to the change, as the
proposed change is already a possibility when neither the mount point or
description are available, see
http://cgit.freedesktop.org/systemd/systemd/tree/src/cryptsetup/cryptsetup.c#n607
I don't know of any password agents to verify in practise, though.



  b) the password agent implementation in systemd doesn't seem to
  handle binary strings (i.e. strings with '\0'), as can be seen by
  calls to e.g. strlen()...
  
  Whether making it binary safe would be a major change or not is
  something I haven't researched yet but it seems like a change that
  should be generally useful upstream...
 
 I'd be OK with this, as discussed at FOSDEM, and I see you already
 posted a ptach for this.

Has this been merged?

Is it safe for a password agent to write content with \0 back to the
socket?

Thanks!
Alberto


[1]: In case it helps anyone else, I added the initramfs option to
crypttab as a workaround, which works in my case because the script
(kxc) is initramfs-ready.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#763212: kxd: FTBFS: Tests failures

[Alberto Bertogli]

On Sun, Sep 28, 2014 at 11:09:34PM +0100, Alberto Bertogli wrote:
 On Sun, Sep 28, 2014 at 07:02:30PM +0200, David Suárez wrote:
  Source: kxd
  Version: 0.12-2
  Severity: serious
  Tags: jessie sid
  User: debian...@lists.debian.org
  Usertags: qa-ftbfs-20140926 qa-ftbfs
  Justification: FTBFS on amd64
  
  Hi,
  
  During a rebuild of all packages in sid, your package failed to build on
  amd64.
  
  Relevant part (hopefully):
   make[1]: Entering directory '/«PKGBUILDDIR»'
   go build -o ./out/kxd ./kxd
   go build --tags netgo -a -o ./out/kxc ./kxc
   python tests/run_tests -b
   .F.
   ==
   FAIL: test_server_cert (__main__.TrickyRequests)
   --
   Traceback (most recent call last):
 File tests/run_tests, line 408, in test_server_cert
   self.assertTrue(sock.cipher()[2]  128)
   AssertionError: False is not true
 
 Hi! I am traveling this week without a laptop so I won't be able to look
 at this properly until next Monday or so.
 
 However, looking at the output and the test itself, it is very likely
 that this is an issue with the test and not the code.

I confirm that the issue is with the tests.

It seems the openssl defaults have changed, so that the new negotiated
cipher is 'ECDHE-RSA-AES128-GCM-SHA256' with a 128 bit key, which fails
the test.

I've pushed a patch to the next branch, which should fix this:
a3195eb (tests: Assert negotiated cipher secret size = 128 bits)
https://blitiri.com.ar/git/r/kxd/c/a3195ebb69084ea7365324ef69f96ad17c5bd4ae/

Would you mind giving it a try?

Once you confirm it works, I'll move it to the master branch and
possibly make a new release with it and the other 3 patches that have
accumulated since 0.12.

Thanks,
Alberto


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#763212: kxd: FTBFS: Tests failures

[Alberto Bertogli]

On Sun, Sep 28, 2014 at 07:02:30PM +0200, David Suárez wrote:
 Source: kxd
 Version: 0.12-2
 Severity: serious
 Tags: jessie sid
 User: debian...@lists.debian.org
 Usertags: qa-ftbfs-20140926 qa-ftbfs
 Justification: FTBFS on amd64
 
 Hi,
 
 During a rebuild of all packages in sid, your package failed to build on
 amd64.
 
 Relevant part (hopefully):
  make[1]: Entering directory '/«PKGBUILDDIR»'
  go build -o ./out/kxd ./kxd
  go build --tags netgo -a -o ./out/kxc ./kxc
  python tests/run_tests -b
  .F.
  ==
  FAIL: test_server_cert (__main__.TrickyRequests)
  --
  Traceback (most recent call last):
File tests/run_tests, line 408, in test_server_cert
  self.assertTrue(sock.cipher()[2]  128)
  AssertionError: False is not true

Hi! I am traveling this week without a laptop so I won't be able to look
at this properly until next Monday or so.

However, looking at the output and the test itself, it is very likely
that this is an issue with the test and not the code.

Thanks!
Alberto


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#755036: kxd: FTBFS: tests fail

[Alberto Bertogli]

On Fri, Jul 18, 2014 at 12:41:02AM -0400, Aaron M. Ucko wrote:
 Alberto Bertogli albert...@blitiri.com.ar writes:
  It's in the next branch of the repository (git://blitiri.com.ar/kxd),
  once you confirm this works, I'll move it to master and will include it
  into the next release.
 
 I'm happy to confirm that I can reproduce the errors only without the
 patch; please do go forward with it at your convenience.

Thanks for the confirmation! The patch is now in the master branch and
will be included in the next release.

Alberto


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#755036: kxd: FTBFS: tests fail

[Alberto Bertogli]

On Wed, Jul 16, 2014 at 11:18:02PM -0400, Aaron M. Ucko wrote:
 Source: kxd
 Version: 0.12-1
 Severity: serious
 Justification: fails to build from source
 
 Builds of kxd have been failing due to test suite errors.  There are
 two problems, each affecting multiple tests:

Thanks for opening this bug! I saw the failures this morning but I'm
only now at the computer.


 * Many tests call os.getlogin, which has been throwing OSError, AFAICT
   because stdin isn't a terminal:
 
 Traceback (most recent call last):
   File tests/run_tests, line 213, in setUp
 self.server = ServerConfig()
   File tests/run_tests, line 162, in __init__
 self.gen_certs(self_sign)
   File tests/run_tests, line 93, in gen_certs
 self.name, os.getlogin(), platform.node())),
 OSError: [Errno 25] Inappropriate ioctl for device

The patch at
https://blitiri.com.ar/git/r/kxd/c/2af6c0892cf34ca25e66cc7be328b75d6444970c/
should fix it.

It's in the next branch of the repository (git://blitiri.com.ar/kxd),
once you confirm this works, I'll move it to master and will include it
into the next release.


 * In addition, test_{both,client,server}_delegated all fail with
 
 Traceback (most recent call last):
   File tests/run_tests, line 220, in tearDown
 if self.daemon:
 AttributeError: 'Delegation' object has no attribute 'daemon'

This one is just a consequence of the previous error.


Thanks again!
Alberto


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#752582: qemubuilder hangs after extracting the packages

[Alberto Bertogli]

Package: qemubuilder
Version: 0.73
Severity: grave
Justification: renders package unusable


Hi!

I'm trying to use qemubootstrap in Debian testing, but it hangs after
extracting the packages and doing some filesystem work, apparently before
running qemu/kvm.

I'm using simple command lines, and reproduced this in two different systems
with different kernels (one using Debian's kernel, the other hand-built),
where I've verified that kvm works just fine. Because of that, I've put this
as grave severity, but please let me know if it's not appropriate.


Here's the summary of the output:

$ sudo qemubuilder --create --distribution sid --basepath vm.img --architecture 
amd64
  forking: mke2fs -q -F -j -m1 -O sparse_super /tmp/t/vm.img
  forking: tune2fs -c 0 -i 0 /tmp/t/vm.img
tune2fs 1.42.10 (18-May-2014)
Setting maximal mount count to -1
Setting interval between checks to 0 seconds
  forking: mount -o loop /tmp/t/vm.img /var/cache/pbuilder/build//qemu.20148
 - Invoking debootstrap
  forking: debootstrap --arch amd64 --foreign sid 
/var/cache/pbuilder/build//qemu.20148 http://debian.heanet.ie/debian/
I: Retrieving Release
I: Retrieving Release.gpg
I: Checking Release signature
I: Valid Release signature (key id A1BD8E9D78F7FE5C3E65D8AF8B48AD6246925553)
I: Retrieving Packages
I: Validating Packages
I: Resolving dependencies of required packages...
I: Resolving dependencies of base packages...
I: Found additional required dependencies: insserv libaudit-common libaudit1 
libbz2-1.0 libcap2 libdb5.3 libdebconfclient0 libsemanage-common libsemanage1 
libslang2 libustr-1.0-1
I: Found additional base dependencies: init-system-helpers libee0 libestr0 
libffi6 libgmp10 libgnutls-deb0-28 libgnutls-openssl27 libhogweed2 libidn11 
libjson-c2 liblogging-stdlog0 liblognorm0 libmnl0 libnetfilter-acct1 libnettle4 
libnfnetlink0 libp11-kit0 libsqlite3-0 libtasn1-6 libxapian22 perl perl-modules
I: Checking component main on http://debian.heanet.ie/debian...
I: Retrieving libacl1 2.2.52-1
I: Validating libacl1 2.2.52-1
I: Retrieving adduser 3.113+nmu3
I: Validating adduser 3.113+nmu3
I: Retrieving apt 1.0.5
I: Validating apt 1.0.5
[...]
I: Retrieving liblzma5 5.1.1alpha+20120614-2
I: Validating liblzma5 5.1.1alpha+20120614-2
I: Retrieving zlib1g 1%3a1.2.8.dfsg-1
I: Validating zlib1g 1%3a1.2.8.dfsg-1
I: Chosen extractor for .deb packages: dpkg-deb
I: Extracting libacl1...
I: Extracting libattr1...
I: Extracting libaudit-common...
I: Extracting libaudit1...
I: Extracting base-files...
I: Extracting base-passwd...
I: Extracting bash...
[...]
I: Extracting mount...
I: Extracting util-linux...
I: Extracting liblzma5...
I: Extracting zlib1g...
 - Doing architecture-specific /dev population
mkdir chroot-/dev: File exists
  forking: umount /var/cache/pbuilder/build//qemu.20148
  forking: mke2fs -q -F -j -m1 -O sparse_super 
/var/cache/pbuilder/build//qemu.20148.dev
  forking: tune2fs -c 0 -i 0 /var/cache/pbuilder/build//qemu.20148.dev
tune2fs 1.42.10 (18-May-2014)
Setting maximal mount count to -1
Setting interval between checks to 0 seconds
  forking: mount -o loop /var/cache/pbuilder/build//qemu.20148.dev 
/var/cache/pbuilder/build//qemu.20148
  forking: umount /var/cache/pbuilder/build//qemu.20148
/usr/bin/kvm
[here it hangs]


If I do a ps auxf at this point, I see:

root 20147  0.0  0.0  61400  2028 pts/30   S+   22:42   0:00  \_ sudo 
qemubuilder --create --distribution sid --basepath vm.img --architecture amd64
root 20148  0.0  0.0  12592  1036 pts/30   S+   22:42   0:00  \_ 
qemubuilder --create --distribution sid --basepath vm.img --architecture amd64
root 24468  0.0  0.0  0 0 pts/30   Z+   22:44   0:00  \_ 
[qemubuilder] defunct


An strace shows it seems to be trying to read from a file descriptor, which
upon inspection in /proc and lsof, it's an unix socket.

If there's anything else you need to know or want me to try, please let me
know.

Thanks!
Alberto




-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.14.2 (SMP w/4 CPU cores)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages qemubuilder depends on:
ii  debootstrap 1.0.60
ii  libc6   2.19-3
ii  pbuilder0.215
ii  qemu-kvm [kvm]  2.0.0+dfsg-6+b1

qemubuilder recommends no packages.

qemubuilder suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#741628: Additional info

[Alberto Bertogli]

On Wed, Apr 09, 2014 at 02:33:51AM -0400, Mike Paul wrote:
 I ran into this bug today while copying a tree of files from one Debian
 amd64 system to another, both running sid and with the rsync package
 version 3.1.0-2 installed.  The options used were -avzh, plus
 --progress and some --exclude options that I doubt are relevant.
 
 The first file that failed was 1078591488 bytes in size, and it failed
 with the message:
 
 inflate returned -3 (6 bytes)
 rsync error: error in rsync protocol data stream (code 12) at token.c(557) 
 [receiver=3.1.0]
 rsync: [generator] write error: Broken pipe (32)
 rsync error: error in socket IO (code 10) at io.c(837) [generator=3.1.0]

Just another data point.

I have an rsync server with Debian stable, running rsync version 3.0.7
protocol version 30.


I used to be able to sync to it from another machine running Debian
testing, but today after upgrading to rsync version 3.1.0  protocol
version 31, I ran into this bug.

The server (running in rsync --daemon mode) complained:

inflate returned -3 (0 bytes)
rsync error: error in rsync protocol data stream (code 12) at token.c(546) 
[receiver=3.0.7]
rsync: connection unexpectedly closed (114 bytes received so far) [generator]
rsync error: error in rsync protocol data stream (code 12) at io.c(601) 
[generator=3.0.7]

Trying from that same client without --compress worked just fine,
similar to what others have said in this bug.


The same command, from an Ubuntu 13.10 with rsync version 3.0.9
protocol version 30, always worked just fine.

I hope this helps!

Thanks,
Alberto


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#746774: docker.io: Docker's systemd config does not honour /etc/default/docker.io

[Alberto Bertogli]

Package: docker.io
Version: 0.9.1~dfsg1-2
Severity: normal

Dear Maintainer,

The provided docker.io's systemd configuration does not honour
/etc/default/docker.io daemon options, so the user is forced to override the
configuration completely if they want to pass a particular option to the
daemon.

I understand the fix would be to change the configuration to do:

  [Service]
  EnvironmentFile=-/etc/default/docker.io
  ExecStart=/usr/bin/docker.io -d $DOCKER_OPTS


That way, the daemon startup options can be overriden from
/etc/default/docker.io as it is usually expected.

For an example of another system that does this, see sshd
(/lib/systemd/system/ssh.service).

Thanks!
Alberto


-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.14.2 (SMP w/4 CPU cores)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages docker.io depends on:
ii  adduser  3.113+nmu3
ii  init-system-helpers  1.18
ii  iptables 1.4.21-1
ii  libapparmor1 2.8.0-5+b1
ii  libc62.18-4
ii  libdevmapper1.02.1   2:1.02.83-2
ii  libsqlite3-0 3.8.4.3-1
ii  perl 5.18.2-2+b1

Versions of packages docker.io recommends:
pn  aufs-toolsnone
ii  ca-certificates   20140325
pn  cgroupfs-mount | cgroup-lite  none
ii  git   1:1.9.2-1
ii  xz-utils  5.1.1alpha+20120614-2

Versions of packages docker.io suggests:
pn  btrfs-tools  none
ii  debootstrap  1.0.59
ii  lxc  1.0.0-8
pn  rinsenone

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#690545: /usr/bin/fiu-ctrl: ignores deprecated options silently

[Alberto Bertogli]

On Tue, Oct 16, 2012 at 11:23:18AM +0200, Serafeim Zanikolas wrote:
 On Mon, Oct 15, 2012 at 10:55:16PM +0100, Alberto Bertogli wrote:
  Thanks for the bug report!
 
  I've wrote commit 17fdac5 that should fix it:
  http://blitiri.com.ar/git/?p=libfiu;a=commit;h=17fdac56.

 Thank you too Alberto.

 If you don't mind some nitpicking:

Not at all, quite the contrary, thanks for looking into this!


 deprecated means still supported but going
 away in the future. That's not the case for fiu-ctrl's deprecated options, so
 you might want to change the wording to something more explicit, eg. ignoring
 deprecated option.

 https://en.wikipedia.org/wiki/Deprecation

Thanks, I am aware of the meaning of deprecation, and the options
*should* be working, not ignored.

If they're not working, that's a bug. I'll try to make them fail, and
send another email once I know more.

Can you send me the command line that is failing for you?

Thanks a lot,
Alberto


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#690545: /usr/bin/fiu-ctrl: ignores deprecated options silently

[Alberto Bertogli]

On Wed, Oct 17, 2012 at 09:00:33PM +0100, Alberto Bertogli wrote:
 On Tue, Oct 16, 2012 at 11:23:18AM +0200, Serafeim Zanikolas wrote:
 If they're not working, that's a bug. I'll try to make them fail, and
 send another email once I know more.

Allright, I found the problems (there were more than one), hopefully
they should all be fixed in 82621d9
(http://blitiri.com.ar/git/?p=libfiu;a=commitdiff;h=82621d9).
Sorry for the trouble!

Can you give that a try and confirm that it works for you?

Thanks a lot!
Alberto


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#690545: /usr/bin/fiu-ctrl: ignores deprecated options silently

[Alberto Bertogli]

On Mon, Oct 15, 2012 at 02:19:38PM +0200, Serafeim Zanikolas wrote:
 fiu-ctrl ignores deprecated options silently. Please make it print a warning
 on stdout, if not fail loudly.
 
 Also, the listing of deprecated options in -h output does not include -d.

Thanks for the bug report!

I've wrote commit 17fdac5 that should fix it:
http://blitiri.com.ar/git/?p=libfiu;a=commit;h=17fdac56.

Thanks again,
Alberto


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#574752: libfiu: core dumps on kfreebsd-*

[Alberto Bertogli]

On Sat, Mar 20, 2010 at 08:37:06PM +0100, Serafeim Zanikolas wrote:
 Hi again,
 
 libfiu core dumps on kFreeBSD-{ia64,i386} when the following call is made:
 
 lock_fd = open(path, O_WRONLY|O_CREAT, 0600);
 
 Here's the backtrace from a failure in asdfasdf.debian.org (GNU/kFreeBSD
 8.0-1-amd64):
 
 fiu-run -x ./beanstalkd -l 127.0.0.1 -p 11400 -b /tmp/bnch86651.d -s 1000 
 
 [..]
 Core was generated by `beanstalkd'.
 Program terminated with signal 4, Illegal instruction.
 
 $ gdb beanstalkd beanstalkd.core
 [..]
 (gdb) bt
 #0  0x000800a372c0 in open (pathname=0x7fffdf10 
 /tmp/bnch86651.d/lock, flags=513) at modules/posix.custom.c:44
 #1  0x0040407a in binlog_lock () at binlog.c:691
 #2  0x004026ac in main (argc=9, argv=0x7fffe4b0) at 
 beanstalkd.c:298

Thanks for the detailed bug report.

It seems strange, because that line is at va_start(). I see nothing obviously
wrong there (the open() call includes the mode as it should when using
O_CREAT), so I'll install that platform and try to reproduce it.

I test libfiu on DragonFlyBSD every once in a while and I've never hit
anything like this, but since it's a related platform I'll also give it a try,
just in case.

Thanks again,
Alberto




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#574752: libfiu: core dumps on kfreebsd-*

[Alberto Bertogli]

On Sun, Mar 21, 2010 at 05:40:25AM -0300, Alberto Bertogli wrote:
 On Sat, Mar 20, 2010 at 08:37:06PM +0100, Serafeim Zanikolas wrote:
  Hi again,
  
  libfiu core dumps on kFreeBSD-{ia64,i386} when the following call is made:
  
  lock_fd = open(path, O_WRONLY|O_CREAT, 0600);
  
  Here's the backtrace from a failure in asdfasdf.debian.org (GNU/kFreeBSD
  8.0-1-amd64):
  
  fiu-run -x ./beanstalkd -l 127.0.0.1 -p 11400 -b /tmp/bnch86651.d -s 
  1000 
  [..]
  Core was generated by `beanstalkd'.
  Program terminated with signal 4, Illegal instruction.
  
  $ gdb beanstalkd beanstalkd.core
  [..]
  (gdb) bt
  #0  0x000800a372c0 in open (pathname=0x7fffdf10 
  /tmp/bnch86651.d/lock, flags=513) at modules/posix.custom.c:44
  #1  0x0040407a in binlog_lock () at binlog.c:691
  #2  0x004026ac in main (argc=9, argv=0x7fffe4b0) at 
  beanstalkd.c:298
 
 Thanks for the detailed bug report.
 
 It seems strange, because that line is at va_start(). I see nothing obviously
 wrong there (the open() call includes the mode as it should when using
 O_CREAT), so I'll install that platform and try to reproduce it.

I can't reproduce the bug on an amd64 install, but I see a compile-time
warning about it, and it makes sense.

Can you test with the attached patch?

You can also find it in the next branch of the repository (which is subject
to rebases), at git://blitiri.com.ar/libfiu (which can be browsed at
http://blitiri.com.ar/git/?p=libfiu;a=shortlog;h=refs/heads/next).

Thanks,
Alberto

From 37f6a98110e3bb59bbb4971241baa3a385c3f724 Mon Sep 17 00:00:00 2001
From: Alberto Bertogli albert...@blitiri.com.ar
Date: Sun, 21 Mar 2010 15:43:43 -0300
Subject: [PATCH] preload/posix: Pass an appropriate promoted type to va_arg()

va_arg() can only take a promoted type, which that means just an int in this
case.

On some platforms passing mode_t works, but on others (like Debian's kFreeBSD
amd64) causes a compile-time warning and a run-time error, as reported by
Serafeim Zanikolas on Debian bug 574752.

This patch fixes this by passing int as the argument to va_arg(), instead of
mode_t.

It also fixes the mode variable's type, which was int when it should have
been mode_t.

Signed-off-by: Alberto Bertogli albert...@blitiri.com.ar
---
 preload/posix/modules/posix.custom.c |   11 +--
 1 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/preload/posix/modules/posix.custom.c b/preload/posix/modules/posix.custom.c
index 5caff6f..1c709cd 100644
--- a/preload/posix/modules/posix.custom.c
+++ b/preload/posix/modules/posix.custom.c
@@ -37,12 +37,19 @@ int open(const char *pathname, int flags, ...)
 
 	/* Differences from the generated code begin here */
 
-	int mode;
+	mode_t mode;
 	va_list l;
 
 	if (flags  O_CREAT) {
 		va_start(l, flags);
-		mode = va_arg(l, mode_t);
+
+		/* va_arg() can only take fully promoted types, and mode_t
+		 * sometimes is smaller than an int, so we should always pass
+		 * int to it, and not mode_t. Not doing so would may result in
+		 * a compile-time warning and run-time error. We asume that it
+		 * is never bigger than an int, which holds in practise. */
+		mode = va_arg(l, int);
+
 		va_end(l);
 	} else {
 		/* set it to 0, it's ignored anyway */
-- 
1.7.0.270.g320aa

Bug#574405: libfiu: has hardwired (and hence works only with) libc.so.6

[Alberto Bertogli]

On Wed, Mar 17, 2010 at 11:23:15PM +, Chris Lamb wrote:
 Hi Alberto,
 
 Not sure if you are subscribed to the bug list but I received this bug
 report in Debian:

I am, but thanks for forwarding it anyway.


 Serafeim Zanikolas wrote:
 
  [..]
  libfiu-0.13/preload/posix/codegen.c has a hardwired reference to libc.so.6:
  
  _fiu_libc = dlopen(libc.so.6, RTLD_NOW);
  if (_fiu_libc == NULL) {
  fprintf(stderr, Error loading libc: %s\n, dlerror());
  exit(1);
  }
  
  This makes the library unusable in systems with any other libc version (eg.
  FTBFS of a package which Build-Depends on fiu-utils, in caballero.d.o
  which has libc.so.6.1
 
 Just to translate from Debian-ese a little: caballero is an IA64 machine
 which uses libc.so.6.1. The alpha architecture does this as well.

How interesting. I had no idea about that.

I could check the libc's soname at build-time, and use that inside the code.


Is the ldd tool available in the build environment? If so, I can find out the
libc's soname using something like:

ld -o libccheck.so -lc -shared  \
ldd libccheck.so | grep libc.so | awk '{ print $1 }';
rm -f libccheck.so;


 Please let me know if want anything compiled/tested on these machines.

I'll have a patch for this using the trick mentioned above in a few minutes.
When it's ready, could you give it a try on those machines?

Thanks,
Alberto




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#444901: darcsweb: please allow _darcs/prefs/motd as repository description (was Re: Bug#444901: darcs: please add support for _darcs/description)

[Alberto Bertogli]

On Tue, Oct 23, 2007 at 11:08:29PM +0200, Luca Capello wrote:
 Alberto: can you read the whole backlog at [1], please?  In case you'd
 find my idea useful, I can write a patch ;-)

Sorry for the huge delay, this had got lost and I found it by chance.


 On Sun, 14 Oct 2007 23:07:53 +0200, Luca Capello wrote:
  Even if I still prefer _darcs/prefs/description, I'll reassign this
  bug to darcsweb in one week from now if no other replies in favor of
  _darcs/prefs/description.

darcsweb already picks out the description from
_darcs/third_party/darcsweb/desc, because of the lack of a common place
for a description.

If there is some other tool that uses (or agrees to use)
_darcs/prefs/description (or equivalent), I'd be glad to make darcsweb
use it too (actually only the first line, because repository
descriptions for darcsweb must be only one-liners because of interface
reasons).

Regarding the use of motd as an extended description to use in the
project's summary, I'm not sure it fits. motd is, well, message of the
day. But if people and documentation agree that's a reasonable usage, I
don't mind implementing as well.

So, in summary:

 - If you know there is some other tool that uses
   _darcs/prefs/description, let me know and I'd be glad to make
   darcsweb use it.
 - If you want darcsweb to use motd as an extended description, ask in
   darcs' users list. If there is a reasonable agreement that it's an
   appropriate use for motd, I'll implement it.


Thanks a lot,
Alberto




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#444035: Reopening due to a revert

[Alberto Bertogli]

On Fri, May 16, 2008 at 07:44:16PM -0300, Margarita Manterola wrote:
 Even if Spanish itself does not include ã or õ, Portuguese does.  And we
 live in an integrated world. Specially in Latin America, where the biggest
 country of the region is Brazil, which speaks Portuguese, not Spanish.
 It's very important for all of us to be able to write the characters of our
 neighbour countries.
 
 Take for example the case of the argentinian NIC service which from now on
 will allow domains with special characters: http://www.nic.ar/616, it not
 only allows the special characters for Spanish, but also the ones for
 Portuguese.

The link is http://www.nic.ar/616.html.

In case you don't understand spanish, it is (as Marga said) an official
resolution allowing the use of non-ascii characters for .ar domains. It
not only will allow spanish characters (ñ, á, é, í, ó, ú) but also
portuguese ones, on the basis of economic and social regional
integration. 


 Most people complained about this because of habit more than because of
 real causes.  Yet sometimes changes have to be made that mean that people
 have to get used to them, and eventually they'll be glad that the change
 was made.

To me, depriving the users of the possibility of writing portuguese
characters directly from their keyboards is a *very* serious bug.

Writing portuguese names and words is common practise, lots of schools
here in Argentina teach portuguese as a second or third language, and is
undoubtedly a very important language in our every day life.


Besides, Mercosur's importance is growing every day, and without the
tilde dead key we won't be able to write in either portuguese or guaraní
(Mercosur's official languages, beside spanish) with ease.


Another important point is that in the whole Paraguay and (at least) in
some provinces of Argentina, where spanish and latin-american keyboard
layouts are the most common, guaraní is an official language.

Guaraní alphabet includes the ã, ~e, ~g, ĩ, õ, ũ, and ~y (the ones of
the form ~[letter] are compositions that I'm unable to type). Without
the dead key, those can't be typed.

That means that, without a dead key, an official language in a region
where spanish and latin-amerincan keyboards are (by far) the most
common, can't be properly written.


I obviously understand the people who get annoyed by this change,
because it breaks a long term typing habit; but I think they are able to
get used to it without too much effort (there will be at least one
non-dead key anyway), and not having the tilde as a dead key has no
simple workaround (besides having some char map always open to
copy-paste from) and it is a very real social need.


Thanks,
Alberto




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#399751: darcsweb: Should prepend configuration directory

[Alberto Bertogli]

On Sun, Oct 14, 2007 at 10:48:28PM +0200, Luca Capello wrote:
 Hello!
 
 On Wed, 03 Oct 2007 02:53:21 +0200, Alberto Bertogli wrote:
  On Mon, Oct 01, 2007 at 01:46:23PM +0200, Luca Capello wrote:
  Cc:ing upstream author, since this bug is clearly upstream and I'd
  like his opinion about my patch.
 
  In the future, please attach the patches uncompressed and inline. It
  makes me able to comment on them inside the mail.
 
 Even if I don't like inline patches [1], the next time I'll do as you
 prefer.

Thanks. Using inline attachments is also fine by me.


 The main reason against the change is if /etc/darcsweb/ is intended to
 store other than a single file, config.py, which doesn't seem the
 case ATM.

I'm sorry, but I honestly don't believe this is worth breaking backwards
compatibility. If it's just to avoid creating a directory that in the
future might even be necessary or desirable, I don't think it's worth
it.


 I don't know anything about python, but what if the first place in
 sys.path contains a config.py?  The problem should be the same :-(

The first place is always '.', that's why it works: it looks in the same
directory as darcsweb for a config file, and if it can't find one, it
looks in /etc/darcsweb.

That way you can have multiple darcswebs on the same machine with
different configurations, and avoid the name clashing with other python
modules.

Thanks,
Alberto




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#399751: darcsweb: Should prepend configuration directory

[Alberto Bertogli]

On Mon, Oct 15, 2007 at 02:01:50AM +0200, Luca Capello wrote:
  That way you can have multiple darcswebs on the same machine with
  different configurations, and avoid the name clashing with other
  python modules.
 
 And after considering your point, this is fine as well.
 
 I just discovered that you fixed this upstream with patch:

Sorry, I actually thought I had written about it in the previous mail.

It wasn't set in stone, but as I wanted to do an -rc1 today, I thought
it was worth adding it just in case.

Thanks a lot for taking the time to report and following this up. If you
have any further bugs, questions or comments, please let me know.

Alberto




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#399751: darcsweb: Should prepend configuration directory

[Alberto Bertogli]

On Mon, Oct 01, 2007 at 01:46:23PM +0200, Luca Capello wrote:
 Cc:ing upstream author, since this bug is clearly upstream and I'd
 like his opinion about my patch.

Thanks.

In the future, please attach the patches uncompressed and inline. It
makes me able to comment on them inside the mail.

I know darcs is nice, but their patch format sucks for human reading, so
using diff -u format would be highly appreciated too, at least for
discussion.

For (much) more information on this, I recommend you to read
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/SubmittingPatches;hb=HEAD,
specially point 7.


 On Tue, 21 Nov 2006 20:25:59 +0100, Philipp Kern wrote:
  darcsweb appends `/etc/darcsweb' to sys.path in line 29. This fails if
  another `config.py' is in the path before the one specifying darcs's
  configuration. In my case this was presumably
  `var/lib/python-support/python2.4/config.py'.

It makes sense.


  Instead it should prepend the path to the variable.
 
 Or, better, use a less generic name.

That would have been nice, but sadly it breaks backwards compatibility
and I don't think it's worth it.


 And while we're at here, I'd suggest to move the configuration to
 /etc/darcswebconf.py (even if the best would be /etc/darcsweb.conf),
 since AFAIK /etc/darcsweb/ contains config.py only.  Upstream patch
 attached.

Maybe a better solution that doesn't breaks backward compatibility is to
add /etc/darcsweb at the second place in sys.path.

I don't want to put it in front because it would prevent you from having
a /etc/darcsweb/config.py and then another darcsweb install with a local
configuration.

Any thoughts on that fix?

Thanks a lot,
Alberto




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]