libtool -D_FILE_OFFSET_BITS= (empty) breaks build
I just got report https://buildd.debian.org/status/fetch.php?pkg=lcmaps&arch=amd64&ver=1.6.6-3.1%2Bb2&stamp=1730151515&file=log which shows an error: In file included from /usr/include/x86_64-linux-gnu/bits/libc-header-start.h:33, from /usr/include/stdio.h:28, from ../../src/lcmaps_account.c:59: /usr/include/features.h:398:52: error: operator '&&' has no right operand 398 | #if defined _FILE_OFFSET_BITS && _FILE_OFFSET_BITS == 64 |^~ In file included from /usr/include/x86_64-linux-gnu/bits/libc-header-start.h:33, from /usr/include/stdio.h:28, from ../../src/lcmaps.c:94: /usr/include/features.h:398:52: error: operator '&&' has no right operand 398 | #if defined _FILE_OFFSET_BITS && _FILE_OFFSET_BITS == 64 |^~ Which is true because libtool sets this to an empty string. What I think was supposed to happen is not defining this at all; leaving it empty makes the expression syntax invalid. Anybody else see this? OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Binary uploads into the archive
On Oct 29, Dennis van Dok wrote: > I think what I should do is update the release number and do another (source > only) upload. Correct: these uploads are supposed to be accepted because binary uploads are still needed for passages in NEW (in that case: it's to target experimental for the first upload of the pair). -- ciao, Marco signature.asc Description: PGP signature
Re: Binary uploads into the archive
On 28-10-2024 22:09, Daniel Leidert wrote: Hi, by accident, I uploaded a binary package today (ruby-rouge) instead of its source-package into the archive. I expected the binary package being rejected once I discovered my mistake. But it was accepted instead, and it was also not being rebuilt. Didn't we turn off binary package uploads? Shouldn't this be rejected? Coincidentally did the exact same thing (with igtf-policy-bundle); but this is now stuck as it cannot migrate to testing (unless somebody manually intervenes). I think what I should do is update the release number and do another (source only) upload. Dennis
Bug#1086331: ITP: golang-github-areyoulazy-libhosty -- A pure golang library to manage /etc/hosts files
Package: wnpp Severity: wishlist Owner: Reinhard Tartler * Package name: golang-github-areyoulazy-libhosty Version : 2.0.1-1 * URL : https://github.com/areYouLazy/libhosty * License : Apache-2.0 Programming Lang: Go Description : A pure golang library to manage /etc/hosts files libhosty is a pure golang library to manipulate hosts-like files. It is inspired by txeh (https://github.com/txn2/txeh), with some enrichments.
Re: Most optimal way to import NMU into existing git-builpackage repository?
Andrey has already said much of what I could add to the thread, but I think I can slightly clarify the needs of NMUers. On Fri, Oct 25, 2024 at 08:45:16AM +0200, Andreas Henriksson wrote: > I would very much prefer if it was possible in Debian to not allow > the archive to get out of sync with packaging git repo (for example > when it lives under salsa.debian.org/debian which uploaders should have > access to already). There are three quite fundamental pieces missing to achieve this. There needs to be simple way to turn a git commit into a source package. If the source of truth ever is to become git, the .dsc becomes an export format and then this becomes a hard requirement. We can turn git commits into source packages. The problem is that there is not one way to do this, but about a hundred and you need to know which package uses which. That does not scale. There needs to be a simple way to figure out the commit that corresponds to an upload. This problem has been approached in two ways. For one thing, there is DEP14 recommending a particular tag layout, but I think this is backwards. It assumes that the git repository is trusted, but in reality git repositories allow for much wider access than Debian uploads. What we really needs is a source package to know the commit id it was generated from. These operations need to round-trip. If you take a source package, identify the git commit and export it to .dsc, it must be functionality equivalent to what you started with. Timestamps may differ, but file content or contained files very much not. To me, these are hard requirements for using maintainer git repositories for performing NMUs. Now the dgit users among us will be grinning already as what I have written here, very much reads like a specification of (parts of) dgit. Once again, I question whether salsa as we use it now is the solution or the problem. I note that it is practically possible to push your dgit history to salsa and then NMUers can easily do meaningful MRs for their uploads even when your maintainer git has changes that have not yet been uploaded. Helmut
Updating the Front Desk delegation
Dear developers, I'm pleased to announce the appointment of Tiago Bortoletto Vaz to the Debian Front Desk team. Welcome, Tiago! Delegation -- I hereby appoint the following as members of the Debian Front Desk team: - Enrico Zini - Jonathan McDowell - Mattia Rizzolo - Pierre-Elliott Bécue - Sam Hartman - Santiago Ruano Rincón - Tiago Bortoletto Vaz - Tobias Frost Any previous Front Desk delegation not explicitly listed above is revoked. The delegation is not time-limited; it will be effective until further changes by present or future Project Leaders. Task Description The Front Desk is the team that runs the NM (New Maintainer) process and supports the Debian Account Managers (DAM). Activities of the team include: - Acting as points of contact and support for Application Managers (AMs), applicants, advocates and everyone involved in the NM process. - Assigning AMs to applicants. - Checking AM reports for consistency, and approving NM processes under the supervision of DAM. - Ensuring that the NM process runs smoothly. - Dealing with requests for Debian Maintainer status, in accordance with the requirements set out by the FTP team, DAM and Keyring Maintainers. - Dealing with requests for temporary porter accounts, in accordance with the requirements set out by the Debian System Administrators. - Managing the NM web interface, database, mailing aliases, and other infrastructure. - Managing the contributors.debian.org web interface, vetting the collected data sources, and maintaining the associated infrastructure. All of these activities are shared with the Debian Account Managers. Appendix You can learn more about the activities and responsibilities of the Front Desk team here: https://wiki.debian.org/Teams/FrontDesk The previous delegation for this team can be found here: https://lists.debian.org/debian-devel-announce/2021/03/msg2.html The current delegation for the Debian Account Managers can be found here: https://lists.debian.org/debian-devel-announce/2022/02/msg3.html - Andreas Tille, Debian Project Leader signature.asc Description: PGP signature
Re: Binary uploads into the archive
On Tue, Oct 29, 2024 at 02:56:46PM +0100, Dennis van Dok wrote: > Coincidentally did the exact same thing (with igtf-policy-bundle); but this > is now stuck as it cannot migrate to testing (unless somebody manually > intervenes). > > I think what I should do is update the release number and do another (source > only) upload. Yes, because it builds arch:all packages (otherwise a binNMU would be enough and one would be scheduled automatically). -- WBR, wRAR signature.asc Description: PGP signature
Bug#1086246: ITP: python-pywaze -- asynchronous Waze client for calculating routes and travel times
Package: wnpp Severity: wishlist Owner: Jason Blackwell X-Debbugs-Cc:debian-devel@lists.debian.org * Package name: python-pywaze Version : 1.1.0 Upstream Contact: Kevin Stillhammer * URL :|https://github.com/eifinger/pywaze| * License : MIT Programming Lang: Python Description : asynchronous Waze client for calculating routes and travel times python3-pywaze is a python client used to estimate travel time and distance between two coordinates using the Waze API. I intend to maintain this package within the home asssistant team.
Re: libtool -D_FILE_OFFSET_BITS= (empty) breaks build
On Tue, 29 Oct 2024 at 14:52:17 +0100, Dennis van Dok wrote: > https://buildd.debian.org/status/fetch.php?pkg=lcmaps&arch=amd64&ver=1.6.6-3.1%2Bb2&stamp=1730151515&file=log > > libtool sets [_FILE_OFFSET_BITS] to an empty string. What I think was supposed > to happen is not defining this at all; leaving it empty makes the expression > syntax > invalid. libtool is not choosing to set this to an empty string: some higher-level component (perhaps Autoconf or Automake or the package-specific build system) is asking libtool to set _FILE_OFFSET_BITS empty (by giving it the command-line option "-D_FILE_OFFSET_BITS="), and libtool is obediently passing on that option to gcc. I recently uploaded dbus_1.14.10-6 which is another autoconf/automake/libtool package, and that built successfully on all release and -ports architectures (except for alpha and hppa where it has not been tried yet), so it seems like this is not a completely general problem with autoconf/automake/libtool or with dpkg-buildflags. I would suggest looking for the root cause in some higher-level component or in the lcmaps package itself. smcv
Re: libtool -D_FILE_OFFSET_BITS= (empty) breaks build
On Tue, 29 Oct 2024 at 16:03:17 +0100, Jakub Wilk wrote:
> $ grep -rP 'D_FILE_OFFSET_BITS=(?!64)' /usr
> /usr/lib/x86_64-linux-gnu/pkgconfig/globus-common.pc:Cflags:
> -D_FILE_OFFSET_BITS= -I${includedir}
Thanks, I've reported (plus a wishlist
bug report suggesting the addition of a superficial autopkgtest to
globus-common, which would probably have detected this).
smcv
Re: libtool -D_FILE_OFFSET_BITS= (empty) breaks build
* Simon McVittie , 2024-10-29 14:38:
I would suggest looking for the root cause in some higher-level
component or in the lcmaps package itself.
$ grep -rP 'D_FILE_OFFSET_BITS=(?!64)' /usr
/usr/lib/x86_64-linux-gnu/pkgconfig/globus-common.pc:Cflags:
-D_FILE_OFFSET_BITS= -I${includedir}
--
Jakub Wilk
