Bug#1043507: ITP: wtmpdb -- Year 2038 safe wtmp implementation
Package: wnpp Severity: wishlist Owner: Sven Joachim X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: wtmpdb Version : 0.8.0 Upstream Contact: Thorsten Kukuk * URL : https://github.com/thkukuk/wtmpdb * License : BSD 2-Clause Programming Lang: C Description : Year 2038 safe wtmp implementation Wtmpdb is a replacement for the `/var/log/wtmp` file which stores login and logout time of users as well as boot and shutdown times of the machine. These data are stored in an SQLite database and use 64-bit timestamps on all architectures, thus it will keep working beyond the year 2038. OpenSUSE seems to be switching from the wtmp file to wtmpdb already[1]. Whether Debian should or will do the same remains to be seen, but as a first step I intend to package wtmpdb so it can be evaluated. It should be noted that the planned transition to 64-bit time_t on most 32-bit architectures will have an immediate impact on the /var/log/wtmp file, because programs built with a 64-bit time_t can suddenly write 64-bit timestamps into the wtmp file or misread existing ones. See bug #1042562[2] (which only talks about utmp, but wtmp should be equally affected). I will need a sponsor at least for the initial upload. Should wtmpdb gain popularity or even become the default wtmp implementation, I would like to handle it over to a team. 1. https://microos.opensuse.org/blog/2023-06-28-switch-to-wtmpdb/ 2. https://bugs.debian.org/1042562
Re: Potential MBF: packages failing to build twice in a row
On 10/08/23 at 14:38 +0200, Lucas Nussbaum wrote:
> On 08/08/23 at 10:26 +0200, Helmut Grohne wrote:
> > Are we ready to call for consensus on dropping the requirement that
> > `debian/rules clean; dpkg-source -b` shall work or is anyone interested
> > in sending lots of patches for this?
>
> My reading of the discussion is that there's sufficient interest for
> ensuring that building-source-after-successful-binary-build works.
>
> Also, for most packages, fixes are trivial, and can be implemented as
> durable fixes (not requiring changes for each upstream release).
>
> So my proposal would be to file bugs against affected packages, with
> severity:minor for now (even it is a clear policy violation).
> The bugs would be properly usertagged to allow tracking, and point to a
> wiki page where we can share recipes for specific issues.
>
> The rate at which packages are fixed could be useful input to determine
> if we can just live with that requirement, or if we needed to change
> policy.
>
> After some time, when enough bugs are fixed, the severity could be
> increased to release-critical. And to ensure that we don't regress again
> on this, this check could easily be added to archive rebuilds.
Hi,
I prepared this wiki page:
https://wiki.debian.org/qa.debian.org/FTBFS/SourceAfterBuild
And I plan to use the following bug template:
--
From: {{ fullname }} <{{ email }}>
To: sub...@bugs.debian.org
Subject: {{ package }}: Fails to build source after successful build
Source: {{ package }}
Version: {{ version }}
Severity: minor
Tags: trixie sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-sab-{{ date_without_slashes }} ftbfs-source-after-build
Hi,
This package fails to build a source package after a successful build
(dpkg-buildpackage ; dpkg-buildpackage -S).
This is probably a clear violation of Debian Policy section 4.9 (clean target),
but this is filed as severity:minor for now, because a discussion on
debian-devel showed that we might want to revisit the requirement of a working
'clean' target.
More information about this class of issues, included common problems and
solutions, is available at
https://wiki.debian.org/qa.debian.org/FTBFS/SourceAfterBuild
Relevant part of the build log:
{% for line in extract %}> {{ line }}
{% endfor %}
The full build log is available from:
http://qa-logs.debian.net/{{ date }}/{{ filename }}
If you reassign this bug to another package, please mark it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects
If you fail to reproduce this, please provide a build log and diff it with mine
so that we can identify if something relevant changed in the meantime.
--
I will first focus on packages where 'dpkg-buildpackage -S' fails after
a successful build.
I might do the same work for packages where 'dpkg-buildpackage -b' fails
after a successful build.
Lucas
Re: guile-gnutls not picked up by sid autobuilders
Hi Andreas On Sat, 12 Aug 2023 at 05:15, Andreas Metzler wrote: > guile-gnutls was uploaded almost a week ago to sid, but the unstable > autobuilders seem to ignore it. > https://buildd.debian.org/status/package.php?p=guile-gnutls > > Is there anything I can do? The experimental uploads were picked up > seamlessly. If you look at the log view, you can see the build was picked up and failed: https://buildd.debian.org/status/logs.php?pkg=guile-gnutls&arch=amd64 Regards Graham
Bug#1043533: ITP: python-coincidence -- Helper functions for pytest
Package: wnpp Severity: wishlist Owner: Josenilson Ferreira da Silva X-Debbugs-Cc: debian-devel@lists.debian.org, nilsonfsi...@hotmail.com * Package name: python-coincidence Version : 0.6.5 Upstream Contact: Dominic Davis-Foste * URL : https://github.com/python-coincidence/coincidence * License : MIT/Expat Programming Lang: Python Description : Helper functions for pytest package needed to run the tests of these packages: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020324 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026963 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026975
tracker.d.o displaying inconsistent information
Hi, if you look at the tracker.d.o page for libvirt[1] you'll see that it displays inconsistent information. Specifically, the "news" sections mentions the recent (2023-08-08) upload of 9.6.0-1[2], but the "action needed" section still claims that a new upstream version is available; the vcswatch message is consistent with this. A security issue is also mentioned as still open in sid, while in reality the recent upload addressed it and the security tracker[3] correctly reports this. Further down, in the "testing migrations" section, the excuses reported are for the *9.5.0-2* version, which is an earlier (2023-07-25) upload. Looking at the current excuses[4] correctly refer to the 9.6.0-1 version, where migration is apparently held up because of gnutls28. There are more inconsistencies, but you get the point. I'm pretty sure everything will go back to normal given enough time, but it looks like the particular set of circumstances around the libvirt package have fallen through the cracks of tracker.d.o's logic and it could be interesting to investigate them while the issue is still manifesting itself. Cheers! [1] https://tracker.debian.org/pkg/libvirt [2] https://tracker.debian.org/news/1451405/accepted-libvirt-960-1-source-into-unstable/ [3] https://security-tracker.debian.org/tracker/source-package/libvirt [4] https://qa.debian.org/excuses.php?package=libvirt -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Bug#1043540: ITP: python-mapclassify -- Classification Schemes for Choropleth Maps
Package: wnpp Severity: wishlist Owner: Josenilson Ferreira da Silva X-Debbugs-Cc: debian-devel@lists.debian.org, nilsonfsi...@hotmail.com * Package name: python-mapclassify Version : 2.6.0 Upstream Contact: PySAL Developers * URL : https://github.com/pysal/mapclassify * License : BSD-3-Clause Programming Lang: Python Description : Classification Schemes for Choropleth Maps Module needed to run the tests package "spopt that is under ITP: #1023521 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023521
Re: tracker.d.o displaying inconsistent information
Hello, > There are more inconsistencies, but you get the point. I'm pretty > sure everything will go back to normal given enough time, but it > looks like the particular set of circumstances around the libvirt > package have fallen through the cracks of tracker.d.o's logic and it > could be interesting to investigate them while the issue is still > manifesting itself. I've noticed issues for other packages[0][1][2][3] and they might all be related. grequests has been accepted 3 days ago and its tracker page is missing data. nmap's migration counter is stuck at 0: "Too young, only 0 of 5 days old". licenseutils and dd-opentracing-cpp both have RC bugs that don't show up on tracker, they likely have already been picked by the autoremoval tool (and might have a removal date set). I haven't looked for it, but there's probably a bug somewhere for this already. [0] https://tracker.debian.org/pkg/grequests [1] https://tracker.debian.org/pkg/nmap [2] https://tracker.debian.org/pkg/licenseutils [3] https://tracker.debian.org/pkg/dd-opentracing-cpp Cheers, -- Samuel Henrique
Re: tracker.d.o displaying inconsistent information
> I haven't looked for it, but there's probably a bug somewhere for this > already. I could not find any opened bugs, so I created one against the tracker virtual package: https://bugs.debian.org/1043546 Cheers, -- Samuel Henrique
Re: autodep8 test for C/C++ header
On martes, 8 de agosto de 2023 04:50:04 -03 Helmut Grohne wrote: > Hi Sune, > > On Tue, Aug 08, 2023 at 06:46:38AM -, Sune Vuorela wrote: > > I don't think this is a important problem that some headers might have > > special conditions for use. I'd rather have our developers spend time > > fixing other issues than satisfying this script. > > A while ago, I've performed a similar analysis for Python and given my > experience there, I disagree with you here. As far as I understand both > you and Peter, you argue that such an autodep integration would fail for > some package for various (valid) reasons. What Benjamin seems to propose > is adding support for an automated check that is opt-in (not opt-out). > As a developer, you have to explicitly enable it in order to use it. > Given the numbers presented by Benjamin and the examples presented by > both Peter and you, I expect that Benjamin's script would just work for > at least half of the packages. And for those where it just works, I see > it as a useful safety measure. > > > Is it a problem that Qt -dev packages also ships windows, mac or android > > specific addons headers? I don't think so. Rather the opposite. When > > doing cross platform work, it is nice that grepping across the includes, > > I also see some of the platformspecific functions in separate files. > > > > Is it a problem that a header file is also shipped that provides > > integration with other-big-thing but 99% of developres/downstream users > > don't care about and no Depends is in place? I don't think that's a > > problem. I'd rather have the header available for the 1% than having to > > create an extra -dev package just for that. > > > > Debian development resources is a finite resource, so let's not waste > > it. > > This goes both ways. The team at Canonical is currently dealing with > lots of failures that are tangential to time64. Let's not waste their > time either. I'm experiencing a similar issue with my work on > /usr-merge. In order to complete that transition in a safe way, I need > file conflicts to be precisely declared, but people frequently introduce > new ones and some even argue about their severity. That's also "wasting" > my time. > > So from my point of view, we need to strike a balance here. Benjamin is > offering an opt-in tool to reduce his waste time. Having half of the > packages opt into it, would already reduce QA work significantly, so > that sounds like a very good measure to me. > > Can we agree on moving forward with this while not forcing it onto each > and every package? I can definitely agree with this as long as it's an opt-in. In fact it could be useful to run it from time to time or even have a way to say "run but ignore this or that case". Of course this might be trickier: it is totally possible for a header to declare conditional includes depending on the platform. signature.asc Description: This is a digitally signed message part.
Re: Potential MBF: packages failing to build twice in a row
On sábado, 5 de agosto de 2023 12:06:27 -03 Lucas Nussbaum wrote: > Hi, > > Debian Policy section 4.9 says: > clean (required) > This must undo any effects that the build and binary targets may > have had, except that it should leave alone any output files > created in the parent directory by a run of a binary target. Now this is something I never understood why it would be needed and it seems that it might be necessary on other types of flows from the one I use. Normally my repos only have the stuff in debian/ committed in them. If a package fails in a way I need to dig deeper I create a chroot, install the build dependnecies, untar the source code and work. If I need to clean, git clean -xdff && untar source code again. I could be easily missing something beneficial for my workflow there but, to be honest, I never really required debian/clean to work. And yes, if someone wants to build my packages then they need to understand how to use git and untar the source code. If they don't, I point them to the docs (we do have them). Also I never seen building a package twice in a row on the archive happening... so no, at least in my use case, I do not see the value of debian/ clean. But again, I might be missing something here. signature.asc Description: This is a digitally signed message part.
Re: Potential MBF: packages failing to build twice in a row
On sábado, 12 de agosto de 2023 20:26:09 -03 Lisandro Damian Nicanor Perez Meyer wrote: > On sábado, 5 de agosto de 2023 12:06:27 -03 Lucas Nussbaum wrote: > > Hi, > > > > Debian Policy section 4.9 says: > > clean (required) > > > > This must undo any effects that the build and binary targets may > > have had, except that it should leave alone any output files > > created in the parent directory by a run of a binary target. > > Now this is something I never understood why it would be needed and it seems > that it might be necessary on other types of flows from the one I use. > > Normally my repos only have the stuff in debian/ committed in them. If a > package fails in a way I need to dig deeper I create a chroot, install the > build dependnecies, untar the source code and work. If I need to clean, git > clean -xdff && untar source code again. > > I could be easily missing something beneficial for my workflow there but, to > be honest, I never really required debian/clean to work. > > And yes, if someone wants to build my packages then they need to understand > how to use git and untar the source code. If they don't, I point them to the > docs (we do have them). > > Also I never seen building a package twice in a row on the archive > happening... so no, at least in my use case, I do not see the value of > debian/ clean. > > But again, I might be missing something here. Scott Kitterman was kind enough to discuss the issue with me, and he asked me what would I do if I have to work with a Debian source from the archive. That was actually a pretty good question, as I have to do it from time to time: apt-get source foo cd foo-x.y.z git init git add -A debian/ And voilá, now I can work with **any** package from the archive in the way I like. If I need to clean up and start over: git clean -xdff tar -xf ../foo_x.y.x.org.tar.gz --strip=1 Someone might say "hey, but you need to clean and untar each time!". Well, to be honest, I prefer that than relying on a add-on prepared by someone who is probably not upstream, ie, us maintainers. Let's be honest, this might be a flaky target unless you test it each and every time... waste of resources. Someone might say "I do not want git installed". Well, I hope you don't use gbp on your packages either. Now I **do** see value if you are using something like gbp to keep the source code, as you might have modified files there. But that's a peril of your workflow, not mine. I can also understand why that was a fair thing to have when stuff like git was not around, but nowadays... And **again**, I might easily be missing something very important here, but so far I see no reason to do two builds of my packages when I can easily solve it with a couple of commands. Note that I am not saying that we should remove the feature. If the package happens to work with it, the better. If it doesn't and you provide a patch to make it work, awesome! Making it mandatory? No, so far I see no value in wasting my time on that. signature.asc Description: This is a digitally signed message part.
