Bug#895848: RFS: inotify-tools/3.14-5
[2018-04-16 21:49] Sean Whitton> control: tag -1 +moreinfo > control: owner -1 ! > > On Mon, Apr 16, 2018 at 10:25:01PM +0300, Dmitry Bogatov wrote: > > > > I am looking for a sponsor for my package "inotify-tools" > [...] > > Looks like you need to update your symbols file. Yes. Did it. 7c6c6bea1edbec1683dd9e5a5ee524819dcd053d
Bug#889968: RFS: inotify-tools/3.14-4
control: tag -1 moreinfo [2018-04-13 16:37] Gianfranco Costamagna> Hello, > > >The next thing you might try is `git deborig`. But I understand just > >asking Dmitry! Hello. I am a bit lost about state of this RFS, but it seems I did stupid thing with format=1.0; complicating sponsoring. Let me settle things, provide sane package with format=3.0 (quilt), with pristine tar. I will ping once I am ready. Sorry for noise.
Bug#891005: New version
Hello! New version (c762cf4202b415b6b76193cc0c8ddb1faf9955f0), now with autopkgtests. Review is welcome. If you have access to exotic architecture, review is twice as welcome ;)
Bug#891005: RFS: gdbm/1.14.1-5
[2018-02-28 10:21] Ansgar Burchardt> Gianfranco Costamagna writes: > > I think there is nothing to worry about :) > > > > this is the path: > > /usr/lib/*/diet/*/libgdbm.a > > It is a problem as the package might provide different functionality > when someone else builds and uploads it. Well, should I introduce whole binary package with just one single gdbm.a instead?
Bug#891005: RFS: gdbm/1.14.1-5
Hello. > Anyhow, if you want to enable, you can do something like this, to make > me and you happy, and then easily revert when new bugs are opened HAVE_DIETLIBC=no ifeq ($(shell dpkg -s dietlibc-dev | grep -o installed), installed) DIET_LIBDIR := $(shell diet -L gcc) HAVE_DIETLIBC=yes endif ifeq ($(shell dpkg-vendor --derives-from Ubuntu && echo yes),yes) HAVE_DIETLIBC=no endif Thanks, I will add this snippet. > If you want to enable it, please make sure it works :) Okay. I will add some autopkgtests.
Bug#877331: sponsorship-requests: nix/1.1.15 (ITP 877019) -- Purely functional package manager
> W: nix: manpage-has-errors-from-man usr/share/man/man1/nix-store.1.gz 1235: > warning [p 13, 9.7i]: can't break line > W: nix: binary-without-manpage usr/bin/nix-generate-patches > > I hope this is acceptable. // I am not DD; did not read source. As far as I know, lintian warnings and errors are never acceptable. And, as a user, I understand, why missing manpage is treated so severe. I am not familiar with nix, but if nix-generate-patches is not end-user-command, you could install it into private directory, that would fix second warning.
Bug#891005: RFS: gdbm/1.14.1-5
[2018-02-21 17:02] Gianfranco Costamagna> >!Important! This upload re-enables diet libc support {conditional, via > >build profiles}. Input from developers, experienced with Debian > >bootstrap is very, very welcome. > > Since this is causing troubles in Ubuntu (Matthias, please give your opinion > here), > because dietlibc is in main, and gives also troubles to maintain the list of > dietlibc > architectures where it is available, since it causes troubles using dietlibc > (the build seems failing), I would prefer to actually implement it again once > dietlibc folks > makes the whole stuff *working*. > > [... description of problems in Ubuntu ...] With all my respect, I am very relucant to solve problems of Ubuntu at expense of Debian output. What exactly is wrong, Debian-wise, in package we are discussing, apart the need to specify long list of architectures, so I could fix it? > I would prefer a patch from dietlibc folks, with an use case of *why* > they need this static library, rather than building/including > something that caused 4 bugs in Debian, a lot of pain in Ubuntu (and > probably was even broken). > > What is your opinion? I would like to understand why we need this, and > if this had even worked. You ask good question. Short answer: because you need it to link program, using gdbm, with diet libc, resulting small static executable. Full answer: because I believe Debian should provide not only libraries for build-dependencies of something in /bin, but also libraries for developers to develop with. I did some search, and seems this is already happening. We have a lot of leaf libraries (mostly perl and java), for example: - libxmlenc-java - libwx-scintilla-perl Or maybe we just need Guix/Nix? > The other stuff looks good to me :) That is good news.
Bug#889968: RFS: inotify-tools/3.14-4
> > [2018-02-12 13:07] Sean Whitton> >> > Last version is at bacef877c2f9293f9e1fd624b32d5306d7bc3c27 Maybe, > >> > you could try again? > >> > >> Still FTBFSs. Log attached. > >> > >> I suspect that the debomatic sid chroot is out-of-date. > > > > Stange. Just did 'sbuild-update -udcar', and still fails to reproduce. > > I have same version of build-essential, by the way. > > > > Added debomatic admin into CC, maybe he has any opinion about > > situation. If not, I could remove sanitize support, although I am not > > so happy with it. Or maybe you could tar.gz your chroot and upload > > somewhere? > > I tried deleting and rebuilding my chroot and disabling ccache and > tmpfs, and I tried building on my i386 machine, again after rebuilding, > disabling ccache and disabling tmpfs. > > In all cases the package FTBFS. I attach my i386 log.. > > I'm not sure how to proceed. I can't upload this if I can't build it, > and my configuration seems sufficiently standard that even if you are > able to build it, we shouldn't upload. Maybe we should try disabling > sanitize support for now. I understand your concerns, Sean. I invited Gianfranco into thread, maybe he would sponspor instead. Ah, another absurd idea. What about your building package on debomatic? Maybe for some reason your source package, generated from git repository, differs from mine? Also, could you please try to run binaries, built by debomatic? Do they crash? Hello! Gianfranco, could you please consider building and, probably, sponsoring this package? We have issue, that it FTBFS on Sean's setup, but builds on mine and on debomatic. As debomatic admin notified, debomatic is not out-of-date {updated this sunday}. https://salsa.debian.org/iu-guest/inotify-tools
Bug#889968: RFS: inotify-tools/3.14-4
[2018-02-12 13:07] Sean Whitton> > Last version is at bacef877c2f9293f9e1fd624b32d5306d7bc3c27 Maybe, you > > could try again? > > Still FTBFSs. Log attached. > > I suspect that the debomatic sid chroot is out-of-date. Stange. Just did 'sbuild-update -udcar', and still fails to reproduce. I have same version of build-essential, by the way. Added debomatic admin into CC, maybe he has any opinion about situation. If not, I could remove sanitize support, although I am not so happy with it. Or maybe you could tar.gz your chroot and upload somewhere?
Bug#889968: RFS: inotify-tools/3.14-4
[2018-02-10 12:13] Sean Whitton> - It FTBFSs for me. Log attached. Look, debomatic build is succesful: http://debomatic-amd64.debian.net/distribution#unstable/inotify-tools/3.14-4/buildlog Last version is at bacef877c2f9293f9e1fd624b32d5306d7bc3c27 Maybe, you could try again?
Bug#889968: RFS: inotify-tools/3.14-4
[2018-02-10 12:13] Sean Whitton> Review of 3c46a878fd294e9af9f8e7c225d16e8aceb960cf: > > - It looks like you added an entry to the changelog for 3.13-3 that > should have been in the changelog for 3.13-4. Good catch. Will fix it. > - I'm not sure that DPKG_EXPORT_BUILDFLAGS = 1 will have any effect > unless you export it? Not sure; I have not used this feature. This variable is checked not by external programs, but by make code in /usr/share/dpkg/[...]. It is okay. > - It FTBFSs for me. Log attached. Oh, I see, fails on ./configure. Unfortunately, I can't reproduce on my own laptop. Maybe it is because it is i386. I am working on getting it built on debomatic-amd64. I will ping you again, when I get results from debomatic. pgpF6NB9Nt0mB.pgp Description: PGP signature