Re: gnulib
Jonas Smedegaard writes: > That said, you are welcome to try nudge me if some concrete task > emerges where you image I might be of help. Thanks -- I'm moving this out of 921954@bugs and cc'ing debian-devel to allow others to help and to allow you from not having to feel a need to reply at all :) One of the things that bothered me with the gnulib Debian package that I've been too afraid to touch is the debian/copyright file. It triggers a lot of lintian errors: https://udd.debian.org/lintian/?packages=gnulib For reference here is current debian/copyright: https://salsa.debian.org/debian/gnulib/-/blob/debian/sid/debian/copyright I've seen debian/clscan/ and ran the tools there, but I don't yet feel comfortable patching things, and it didn't produce clean results even for the last version in testing before I started to work on this package, so I'm not convinced this toolchain is the best approach going forward. One problem is that lintian doesn't like [REF01] in lines like this: License: FSFAP [REF01] Is the reason why this is done that you want to record a full copy of the actual text from the particular file AND some more information? Sometimes there is a file X with the FSFAP license and some additional text not part of the core FSFAP license, and another file Y that also uses FSFAP but has some OTHER additional text that you want to record? In some other packages, I've used the Comment: field like this for situations like that. Maybe it is applicable here? Files: * Copyright: 2016 Google LLC. All Rights Reserved. 2022 Trillian Authors. All Rights Reserved. 2016 The Kubernetes Authors. 2017 Google LLC. All Rights Reserved. License: Apache-2.0 Comment: Quoting AUTHORS: # This is the official list of benchmark authors for copyright purposes. Antonio Marcedone Google LLC Internet Security Research Group Vishal Kuo The idea is that from a legal perspective, the copyright notices and keywords 'FSFAP' and 'Apache-2.0' with full text copy of the license is sufficient documentation. However, for reasons like proper attribution and having more background information, it is useful to say something more than what's legally required, including properly quoting the relevant files. I think the Comment: section makes for a better place than License: fields for this. Does anyone have other advice related to gnulib's debian/copyright file? I have yet to fully get a grip on how this file should best reflect reality for a complex package like gnulib, but will try to do my best to resolve lintian complaints and keep it accurate and maintainable. /Simon signature.asc Description: PGP signature
Re: Silent hijacking and stripping records from changelog
On Wed Apr 17, 2024 at 7:26 PM BST, Jonas Smedegaard wrote: > To be fair, I _was_ upset (not with Jonathan, but) earlier in this > thread, which makes it harder to err on the side of a mistake when I > write something that can be read as being sarcastic. I would be upset too if my packages were repeatedly hijacked. > Sorry, Jonathan, for being difficult to read here. No problem: Sorry for lapsing in assuming good faith on my part. WRT Haskell and the monorepo, I've just done a bit of digging to try and remind myself why it was necessary, and I've not found a satisfactory answer. Perhaps there isn't one! [1] says it's "easier to update them in bulk" which, in isolation, I personally don't think is sufficient for the trade-off. I've just noticed that you upload Pandoc, and it (thankfully) is in an individual repo. You don't build a library package, perhaps that's relevant. I haven't traced the history that results in there being a separate haskell-pandoc source package yet. [1] https://lists.debian.org/debian-haskell/2024/02/msg1.html [2] https://tracker.debian.org/pkg/haskell-hakyll -- Please do not CC me for listmail. 👱🏻 Jonathan Dowland ✎j...@debian.org 🔗 https://jmtd.net
Re: Silent hijacking and stripping records from changelog
Hi, * Jonathan Dowland [2024-04-18 08:35]: Sorry, Jonathan, for being difficult to read here. No problem: Sorry for lapsing in assuming good faith on my part. The way both of you handled this misunderstanding was... exemplary. SCNR Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1069229: ITP: python-haproxyadmin -- work with HAProxy via the stats socket
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-haproxyadmin Version : 0.2.4 Upstream Contact: Pavlos Parissis * URL : https://github.com/unixsurfer/haproxyadmin * License : Apache-2.0 Programming Lang: Python Description : work with HAProxy via the stats socket Haproxyadmin is a Python library for interacting with HAProxy load balancer to perform operations such as enabling/disabling servers. It does that by issuing the appropriate commands over the stats socket provided by HAProxy. It also uses that stats socket for retrieving statistics and changing settings. Note: this is a new dependency of the magnum-cluster-api module for OpenStack.
Bug#1069230: ITP: python-sherlock -- distributed inter-process locks with a choice of backend
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-sherlock Version : 0.4.1 Upstream Contact: Vaidik Kapoor * URL : https://github.com/py-sherlock/sherlock * License : Expat Programming Lang: Python Description : distributed inter-process locks with a choice of backend Sherlock is a library that provides easy-to-use distributed inter-process locks and also allows you to choose a backend of your choice for lock synchronization. Note: this is a new dependency of magnum-cluster-api OpenStack module.
Bug#1069245: ITP: tinyusb -- USB stack for embedded systems
Package: wnpp Severity: wishlist Owner: Johannes Schauer Marin Rodrigues X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: tinyusb Version : 0.16.0 Upstream Contact: Ha Thach * URL : https://www.tinyusb.org/ * License : Expat Programming Lang: C Description : USB stack for embedded systems TinyUSB is an open-source cross-platform USB Host/Device stack for embedded system, designed to be memory-safe with no dynamic allocation and thread-safe with all interrupt events are deferred then handled in the non-ISR task function.
Re: Silent hijacking and stripping records from changelog
On 4/9/24 03:25, James McCoy wrote: When I first started looking into Rust packaging it was initially going to be for a workspace of crates. I didn't receive any pushback when I asked about taking over the one crate that had already been packaged and handling it from a single source package for that workspace. In the end I changed my mind and continued using the monorepo for the rest of the crates. If you allow me give my perspective from an outsider: the monorepo thingy for crates is the only place in Debian where I've seen it, and it's *VERY* confusing. Plus there are many reasons where one may want to package something in a different team, so IMO it's not a good idea. Plus what if some project hold a multi-language thing, like rust and another language, as source package, and then we need to generate multiple binaries? (real-life thingy, but can't remember which package) Just my 2 cents... :P Cheers, Thomas Goirand (zigo)
OSSummit
Hi, Hope it all goes well! I am following up to confirm, if you are interested acquiring the Customized Audience List. OSSummit | APRIL 16 - 18|SEATTLE, WASHINGTON Each record will contain details like Contact Name, Number, Email Address, Company Name, URL, Phone etc. Please share your thoughts with us, so we can send reasonable cost and additional info. Best, Keith Burden Sr. Business Analyst
Status of the t64 transition
Hi, as the progress on the t64 transition is slowing down, I want to give an overview of some of the remaining blockers that we need to tackle to get it unstuck. I tried to identify some clusters of issues, but there might be other classes of issues. Let's start with the first category. Those are packages that could be binNMUed, but there are issues that make those rebuilds not have the desired effect. This list include packages that * are BD-Uninstallabe, * FTBFS but with out ftbfs-tagged RC bug, * have hard-coded dependencies on pre-t64 libraries, * have $oldlib | $newlib dependencies (those are at least wrong on armel/armhf and violate policy 2.2.1 once the pre-t64 libraries are decrufted), * have been rebuilt before all dependencies were built, * have broken symbols/shlibs files producing incorrect dependencies, * or might just be missing the binNMU (but those should be few). 3depict arctica-greeter cegui-mk2 condor courier deepin-movie-reborn fastnetmon fcitx-kkc gentle gnome-subtitles gocryptfs gozer gtk-chtheme gvmd gxneur haskell-gi-dbusmenugtk3 haskell-gi-gtk haskell-gi-gtk-hs haskell-gi-vte haskell-gtk-strut hkl hugin hxtools ibus-kkc ippsample jellyfish jskeus lcmaps-plugins-basic lcmaps-plugins-jobrep lcmaps-plugins-verify-proxy lcmaps-plugins-voms libcanberra libosmo-netif lightdm lightdm-gtk-greeter light-locker limesuite llvm-toolchain-17 lmms lyskom-server massxpert2 nautilus-wipe ncl nfs-ganesha obs-advanced-scene-switcher openjdk-20 perdition ppp prads prelude-lml prelude-manager purple-xmpp-carbons purple-xmpp-http-upload python-escript qt5-ukui-platformtheme quorum renpy roger-router rtags sdpa seafile-client slick-greeter sonic-visualiser spectrwm spice-gtk swtpm tfortune thunderbird trantor ui-gxmlcpp ukui-greeter urfkill vdeplug-pcap vdeplug-slirp wine-development worker xbase64 xca Next, packages that need an upload since they build Architecture: all binaries depending on pre-t64 libraries: alsa-ucm-conf anki clearlooks-phenix-theme gtk-sharp3 jruby mandos python-pylibdmtx pyzbar rapid-photo-downloader ruby-ethon ruby-ffi-libarchive sbmltoolbox syncevolution Finally, packages that need rebuilds but currently have open FTBFS (RC + ftbfs tag) bugs: 3dchess ace-of-penguins acm adns adonthell alsa-oss amberol anfo arrayfire audtty barrier blasr boinc-app-eah-brp broker caml-crush cctools clanlib clazy clickhouse code-saturne coz-profiler cp2k cpdb-backend-cups cpm criu curlftpfs dapl darcs das-watchdog deepin-log-viewer dnstop dolphin-emu dradio dub dune-pdelab dvbstreamer dx ecere-sdk elektra epic4 epic5 eterm filament freebayes freebsd-buildutils gabedit gamazons ganeti gdis ggcov ghdl ghemical giblib gigedit glirc gnat-gps gnome-breakout gnome-photos gnunet-gtk google-compute-engine-oslogin grok gsocket gtk-sharp3 gtkterm gwc gyoto hardinfo hping3 hplip httest i2masschroq ibus-anthy info-beamer intel-hdcp irssi-plugin-robustirc isoquery kamailio kbtin kcov kdrill kexec-tools keynav klatexformula kluppe kpatch kraptor kwin-effect-xrdesktop ldapvi lftp libaws libengine-gost-openssl libgovirt libkkc libnginx-mod-http-modsecurity liboqs librm libvma libzorpll lief linssid lintian-brush linuxtv-dvb-apps literki lives llvm-toolchain-16 lmemory lnav loqui lsh-utils mahimahi maildrop matchbox-keyboard matchbox-panel mate-equake-applet mathgl mdbtools mdk4 mit-scheme mldemos mlpcap mod-gnutls moonshot-ui mozillavpn mpqc3 ncrack netdiag newsboat nitrokey-app nng ntopng obs-ashmanix-countdown obs-downstream-keyer obs-ptz obs-scene-notes-dock obs-websocket octave-mpi openems openexr-viewers openjdk-19 openmx opensta openturns openvas-scanner ortools performous-composer pesign pidgin-sipe pixmap pngphoon porg projecteur purify purple-lurch pxe-kexec pyferret pygame-sdl2 pytorch-vision qstopmotion raku-readline ramond rdup recutils regina-normal resvg rmlint ruby3.2 ruby-fcgi ruby-ruby-magic-static ruby-sigar s390-tools sagemath samhain scm scrollz sdaps searchmonkey siconos siridb-server sitecopy slapi-nis slrn sniffit snort spek spotlighter squeak-plugins-scratch stimfit subvertpy supertuxkart swift-im syrthes tcptrack telegram-purple termrec thin-provisioning-tools threadscope tightvnc tlog uhub urweb vart vecgeom veusz vg virtualjaguar whitedune wmweather+ xbill xcolmix xir xneur xpat2 xpra xqilla xrt xshogi xtide yap yrmcds zabbix zeek Note that not all of the packages listed above have bugs filed. Also, the list is produced based on the state in unstable. Packages that were already removed from testing are also on these lists. If you maintain any of the packages above, please check their status and help get them fixed. Any help in filing bugs, fixing packages, requesting removals, etc. is appreciated so that we can look into unblocking the whole stack and migrate it to testing. The dd-list of the packages above is attached. Cheers -- Sebastian Ramacher A Mennucc1 dvbstreamer Adam Borowski kbtin termrec Adrian Knoth qstopmotion (U) Agathe Porte o
Re: Silent hijacking and stripping records from changelog
Quoting Jonathan Dowland (2024-04-18 09:35:41) > On Wed Apr 17, 2024 at 7:26 PM BST, Jonas Smedegaard wrote: > > To be fair, I _was_ upset (not with Jonathan, but) earlier in this > > thread, which makes it harder to err on the side of a mistake when I > > write something that can be read as being sarcastic. > > I would be upset too if my packages were repeatedly hijacked. > > > Sorry, Jonathan, for being difficult to read here. > > No problem: Sorry for lapsing in assuming good faith on my part. > > WRT Haskell and the monorepo, I've just done a bit of digging to try and > remind myself why it was necessary, and I've not found a satisfactory > answer. Perhaps there isn't one! [1] says it's "easier to update them > in bulk" which, in isolation, I personally don't think is sufficient for > the trade-off. I agree with your view. The need for efficiency is the reason that I mentined in my rant previously that the Perl team has made use of myrepos to kinda get a bit of both: Track each package in independent VCS, while easing sweeping operations across a pile of similarly structured packages. > I've just noticed that you upload Pandoc, and it (thankfully) is in an > individual repo. You don't build a library package, perhaps that's > relevant. I haven't traced the history that results in there being a > separate haskell-pandoc source package yet. > > [1] https://lists.debian.org/debian-haskell/2024/02/msg1.html > [2] https://tracker.debian.org/pkg/haskell-hakyll Until recently, Debian source package src:pandoc provided binary packages pandoc (containing an executable binary) and ghc-pandoc-dev (containing a Haskell library). I never liked the Haskell team giant-git-repo thingy, and that source package has been mainained in an independent git repo, with collaboration and coordination with the Haskell team on doing that. The reason for the split was changes to upstream tooling (instead of building lib and binary in concert, they were split into separate git repos and building binary would need library already built), combined with infexible tooling in Debian (Haskell libraries still rely on CDBS which in itself can handle chainloaded builds but it is tricky to do right and even more tricky to do so with the Haskell-specific CDBS addons). I tried but gave up, and handed over maintenance of the Pandoc library part to the Haskell team. I also maintain a few other Haskell libraries and binaries, also outside of the Haskell team giant-git-repo thingy. The Haskell team tolerate that. I am unaware if I am alone in maintaining Haskell packages outside of the team giant-git-repo thingy. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: gnulib
Quoting Simon Josefsson (2024-04-18 09:34:26) > Jonas Smedegaard writes: > > > That said, you are welcome to try nudge me if some concrete task > > emerges where you image I might be of help. > > Thanks -- I'm moving this out of 921954@bugs and cc'ing debian-devel to > allow others to help and to allow you from not having to feel a need to > reply at all :) Thanks for releaving me. ...but then you bring up licensing, which has my special interest :-D > One of the things that bothered me with the gnulib Debian package that > I've been too afraid to touch is the debian/copyright file. It triggers > a lot of lintian errors: > > https://udd.debian.org/lintian/?packages=gnulib > > For reference here is current debian/copyright: > > https://salsa.debian.org/debian/gnulib/-/blob/debian/sid/debian/copyright > > I've seen debian/clscan/ and ran the tools there, but I don't yet feel > comfortable patching things, and it didn't produce clean results even > for the last version in testing before I started to work on this > package, so I'm not convinced this toolchain is the best approach going > forward. When I took over maintenance my first thought was also to get rid of the clscan script, but then I realized how enormous a work it would be to approach it differently and wrapped my head around the script and adjusted it. Does it sound like you are in a similar situation now as I was, or is there something in particular that makes you consider abandoning clscan? If you are simply not fluent in perl, then perhaps reach out to the Debian perl team for help? Or perhaps look in the git history the tweaks that I made - perhaps those are of inspiration to whatever issue you are running into now? > One problem is that lintian doesn't like [REF01] in lines like this: > > License: FSFAP [REF01] I agree with lintian about the above (but we disagree on other things - see bug#786450). I am confident that the above syntax is incorrect: copyright format 1.0 requires a single-word shortname. > Is the reason why this is done that you want to record a full copy of > the actual text from the particular file AND some more information? > Sometimes there is a file X with the FSFAP license and some additional > text not part of the core FSFAP license, and another file Y that also > uses FSFAP but has some OTHER additional text that you want to record? I guess so. While I maintained the package I did some cleanup of the copyright file, but did not get around to tightening the [REFnn] syntax, and I have not been in touch with the previous maintainer who introduced it, Ian Beckwith, which is why I am only guessing here. > In some other packages, I've used the Comment: field like this for > situations like that. Maybe it is applicable here? > > Files: * > Copyright: 2016 Google LLC. All Rights Reserved. >2022 Trillian Authors. All Rights Reserved. >2016 The Kubernetes Authors. >2017 Google LLC. All Rights Reserved. > License: Apache-2.0 > Comment: Quoting AUTHORS: > # This is the official list of benchmark authors for copyright purposes. > Antonio Marcedone > Google LLC > Internet Security Research Group > Vishal Kuo > > The idea is that from a legal perspective, the copyright notices and > keywords 'FSFAP' and 'Apache-2.0' with full text copy of the license is > sufficient documentation. However, for reasons like proper attribution > and having more background information, it is useful to say something > more than what's legally required, including properly quoting the > relevant files. I think the Comment: section makes for a better place > than License: fields for this. I generally agree with your approach above. Specifically for your concrete example above, I find the Comment superfluous. Also, one detail: I would avoid content in first line of the Comment field - i.e. I would move the text "Quoting AUTORS:" down on a separate line, indented same as the following lines. Arguably the syntax used above is technically permitted, but I have not seen it used. Details on that is here: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#formatted-text - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1069256: debian-policy: clarify requirement for use of Static-Built-Using
Package: debian-policy Version: 4.7.0.0 Severity: normal X-Debbugs-Cc: debian-devel@lists.debian.org Dear Policymakers, With the increasing amount of programs in Debian that Build-Depend and statically link with Golang and Rust libraries, it's important that the Debian Policy clearly sets out the requirements for declaring these statically-linked libraries. Currently, section 7.8 of the policy is a bit vague regarding stating static libraries. It begins with saying: Some binary packages incorporate parts of other packages when built but do not have to depend on those packages. Examples include linking with static libraries or incorporating source code from another package during the build. It then states: [The Built-Using field] should be used only when there are license or DFSG requirements to retain the referenced source packages. It should not be added solely as a way to locate packages that need to be rebuilt against newer versions of their build dependencies. This makes it seem that Built-Using shouldn't be used to declare statically-linked dependencies, though that is not the case[1]. In early 2022, Guillem added support for a new Static-Built-Using field to dpkg, encouraging packagers to use it over Built-Using to specify statically-linked dependencies [2]. The commit message states the following: This field mimics the previous Built-Using field semantics, but is specifically intended for shadow dependencies stemming from static builds. In Debian, the Rust and Go teams agreed to use this language agnostic field, instead of one for each of the languages. This means it can be easily supported by dpkg, and can be used by other languages and run-times. This was also added to the deb-control(5) manpage, specifically differentiating it from Built-Using as a field to be used "for static building purposes (for example linking against static libraries, builds for source-centered languages such as Go or Rust[...])". The proposed change is to clarify and formally mandate the requirement to declare statically-linked libraries used to build packages containing binaries in Static-Built-Using. Attached is a draft patch of the proposed change. Feedback is welcome! Kind regards, Maytham [1]: The Go team requires that Built-Using is specified for packages containing binary programs, and this is evident in the templates outputted by dh-make-golang. (This is being migrated over to Static-Built-Using, the correct field for this purpose.) Similarly, the Rust team also requires that Static-Built-Using are specified, as evident in debcargo's output when generating d/control files. (X-Cargo-Built-Using is currently being used but will soon be replaced by Static-Built-Using with the next upload.) The Rust team also uses Built-Using when required, where dh-cargo/cargo will check for and collate a list of any packages with copyleft licenses in the dependency tree that require accompanying source. [2]: https://git.dpkg.org/cgit/dpkg/dpkg.git/commit/?id=16c412439c5eac5f32930946df9006dfc13efc02 https://lists.debian.org/debian-devel-changes/2022/03/msg03007.html From a9b9c513ae985fddca1bf9cceadce6d3d620ce53 Mon Sep 17 00:00:00 2001 From: Maytham Alsudany Date: Thu, 18 Apr 2024 22:29:01 +0300 Subject: [PATCH] Require use of Static-Built-Using to declare statically-linked libraries --- policy/ch-relationships.rst | 36 ++-- 1 file changed, 34 insertions(+), 2 deletions(-) diff --git a/policy/ch-relationships.rst b/policy/ch-relationships.rst index fb9dae8..31a1757 100644 --- a/policy/ch-relationships.rst +++ b/policy/ch-relationships.rst @@ -666,8 +666,8 @@ dependency to install. .. _s-built-using: -Additional source packages used to build the binary - ``Built-Using`` -- +Additional source packages used to build the binary - ``Built-Using`` and ``Static-Built-Using`` + Some binary packages incorporate parts of other packages when built but do not have to depend on those packages. Examples include linking @@ -676,6 +676,9 @@ package during the build. In this case, the source packages of those other packages are part of the complete source (the binary package is not reproducible without them). +``Built-Using`` +~~~ + When the license of either the incorporated parts or the incorporating binary package requires that the full source code of the incorporating binary package be made available, the ``Built-Using`` field must list @@ -710,6 +713,35 @@ requirements to retain the referenced source packages. It should not be added solely as a way to locate packages that need to be rebuilt against newer versions of their build dependencies. +``Static-Built-Using`` +~~ + +When a binary is staticall
Re: Status of the t64 transition
On 2024-04-18 Sebastian Ramacher wrote: [...] > Let's start with the first category. Those are packages that could be > binNMUed, but there are issues that make those rebuilds not have the > desired effect. This list include packages that > * are BD-Uninstallabe, > * FTBFS but with out ftbfs-tagged RC bug, > * have hard-coded dependencies on pre-t64 libraries, > * have $oldlib | $newlib dependencies (those are at least wrong on >armel/armhf and violate policy 2.2.1 once the pre-t64 libraries are >decrufted), > * have been rebuilt before all dependencies were built, > * have broken symbols/shlibs files producing incorrect dependencies, > * or might just be missing the binNMU (but those should be few). > hugin [...] Good morning, thanks for the update. Looking at hugin, I think it is fine on all release-architectures, none of the problems noted above apply here. Am I missing something? TIA, cu Andreas PS: fakeroot seems to be an important blocker not in the list.
