Re: pre-MBF: fail to build (repack) source
On Sun, 16 Jul 2023 at 00:03:00 +0200, Adam Borowski wrote:
> due to Build-Depends
> being inadequate (per the Policy, B-D-Indep are _not_ necessarily
> installed)
For completeness, B-D-Arch are not guaranteed to be installed during
clean either. Similarly, Build-Conflicts are guaranteed to be absent,
but the rarely-used Build-Conflicts-{Arch,Indep} are allowed to be
present during clean. Policy reference for this is §7.7:
clean
Only the Build-Depends and Build-Conflicts fields must be
satisfied when this target is invoked.
smcv
Re: versioned dependencies between -dev packages
Hi, Le sam. 15 juil. 2023, 17:36, Nicolas Boulenguez a écrit : > Julien Puydt > > - Indeed this is quite fragile; I have two scripts for Coq packages [1]: > > one to tell me about the deps (I give it which package I have to upgrade > > and it gives the list of affected packages by pass) and the other to > > generate the migration script (I give it the list of new packages and > their > > new version and it generates what I have to tell FTP masters), but it's > > still pretty painful. > > Perhaps if there are several such instances of such package > > dependency networks we should try to find a common and efficient > > solution Debian-wide ? > > Ada updates require the NEW queue and or manual Break/Replaces. > Ocaml updates require passes and migration scripts. > Rust updates encounter inconsistent states. > Let us steal as many ideas as possible from each other (but not > necessarily on -devel). > > https://wiki.debian.org/LanguageVersionedDevPackages Well -devel is also where we can expect people to make valuable observations and provide useful ideas. For the Coq packages: - good: packages become uninstallable but are not broken on users' systems; - bad: needs too much human planning (prepare ben script, open transition bug...); - bad: part of the deps aren't computed but handwritten (see dh-coq's tools/coq_packages.py); - etc J.Puydt
Re: virtual packages for Ada libraries
Quoting Jonas Smedegaard (2023-07-15 10:05:24) > Quoting Nicolas Boulenguez (2023-07-12 15:55:09) > > The Ada maintainers are considering a new naming scheme for -dev packages, > > where > > libada-foo-dev Provides: libada-foo-dev-HASH. > > source packages Build-Depend: libada-foo-dev > > binary -dev packages Depend: libada-foo-dev-HASH > > The intent is similar to the one of shared object versions, but the > > name changes often (for example, with the architecture) and is > > computed, so virtual packages seem more appropriate. > > > > Policy 3.6 does not disapprove: > > ... should not use virtual package names (except privately, > > amongst a cooperating group of packages) unless they have been > > agreed upon and appear in the list of virtual package names. > > However politeness recommends to ask for objections before polluting > > the package namespace. > > > > Haskell and Ocaml apparently use a similar scheme. > > I have no objections to this - it sounds like a good approach. > > Just want to point out that experience from Rust packaging indicates > that general Debian tooling does a weaker job at dependency resolving > for vritual packages, which (for Rust libraries) causes breakages of > reverse dependencies, and may even (not quite sure) lead to breakage of > testing due to libraries with unsatisfied (dependencies) migrating. I now recall: The Rust library packages wreaking havoc by prematurely entering testing is (at least partly) due to the Rust team choosing to flag all(!) autopkgtests as flaky, so not really a concern for other teams (read: just don't take inspiration from that particular pattern). - 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: virtual packages for Ada libraries
On Sun, Jul 16, 2023 at 7:50 AM Jonas Smedegaard wrote: > I now recall: The Rust library packages wreaking havoc by prematurely > entering testing is (at least partly) due to the Rust team choosing to > flag all(!) autopkgtests as flaky, so not really a concern for other > teams (read: just don't take inspiration from that particular pattern). They aren't all flaky but skip-not-installable is used frequently. Thank you, Jeremy Bícha
Proposed MBF: Removal of libfreetype6-dev
Hi, I will be removing the transitional package libfreetype6-dev (from the source package freetype) later this year. Currently, there are 219 build-dependencies and 29 (direct) dependencies on libfreetype6-dev, which has been released with bullseye and bookworm. I plan to file bugs with severity: normal in mid-August and drop libfreetype6-dev from October. At this point, I will raise the severity of the bugs to serious. My proposed bug template: -->8 Subject: Please build-depend on libfreetype-dev Severity: normal Usertags: libfreetype6-dev Dear maintainer, I will be removing libfreetype6-dev from Debian in October this year. libfreetype6-dev is a transitional package and was replaced by libfreetype-dev when bullseye was released. Your package currently build-depends on libfreetype6-dev. Please update your package's control file to build-depend on libfreetype-dev. If your package is not updated, it will fail to build from source once libfreetype6-dev is no longer available. This mass bug filing was discussed on debian-devel@: . Thanks, Hugh -->8 I plan to file bugs against source packages first and against any remaining binary packages later. A list of affected source and binary packages is attached. Happy to discuss if anyone has any suggestions or concerns. Hugh "Adam C. Powell, IV" oce (U) A Mennucc1 pygame (U) A. Maitland Bottoms gr-fosphor Abou Al Montacir castle-game-engine (U) Adrian Knoth zita-at1 (U) Alastair McKinstry ncl Alberto Luaces Fernández openscenegraph Albin Tonnerre efl (U) Alessio Treglia clxclient (U) japa (U) Alexander Ponyatykh g15daemon libg15render Alexander Reichle-Schmehl xplanet Andrea Marchesini mozillavpn (U) Andreas Metzler efl (U) Andreas Rönnquist allegro5 (U) Andrej Shadura g15daemon (U) rust-freetype-sys (U) rust-servo-freetype-sys (U) Aniol Martí aegisub Anselm Lingnau abcm2ps Anthony Fok libfont-freetype-perl (U) Anton Gladky libopenshot-audio (U) vtk9 (U) Ari Pollak gimp (U) Aron Xu fcitx-ui-light (U) libucimf (U) Arun Kumar Pariyar dde-qt5integration (U) deepin-album (U) deepin-menu (U) deepin-qt5dxcb-plugin (U) Barry deFreese alien-arena (U) brutalchess (U) Barry deFreese adonthell (U) asc (U) fenix-plugins (U) Bart Martens einstein Bartosz Fenski asc (U) supertux (U) Bas Couwenberg librasterlite2 (U) mapnik (U) Bas Wijnen openmsx Bastien Roucariès imagemagick (U) Beren Minor gemrb Birger Schacht fcft Boris Pek astromenace Boyuan Yang dde-qt5integration (U) deepin-menu (U) deepin-qt5dxcb-plugin (U) Bruno Kleinert scorched3d (U) ChangZhuo Chen (陳昌倬) libucimf (U) Christoph Egger gtkballs (U) herbstluftwm warzone2100 (U) Christoph Ender libpixelif Christopher James Halse Rogers mir (U) Damyan Ivanov libimager-perl (U) Daniel Leidert gamgi (U) David Bremner racket David Paleino mapnik (U) David Weinehall scummvm (U) Debian Astro Team montage Debian Deepin Packaging Team dde-qt5integration deepin-album deepin-menu deepin-qt5dxcb-plugin Debian Edu Packaging Team openboard Debian EFI fwupd Debian Electronics Team oregano Debian Fonts Task Force fontmatrix ttfautohint Debian freedesktop.org maintainers poppler Debian freesmartphone.org Team literki Debian Games Team adonthell alien-arena allegro5 asc astromenace brutalchess cube2font ddnet debian-games fenix-plugins freeorion gplanarity gtkballs libsfml love minetest ogre-1.12 ogre-1.9 quesoglc renpy scorched3d scummvm spring supertux teeworlds tuxpuck warzone2100 Debian GIS Project librasterlite2 mapnik Debian GNOME Maintainers gimp gnome-font-viewer libgxps librsvg Debian GNUstep maintainers popplerkit.framework Debian Input Method Team fcitx-ui-light libucimf Debian Math Team sagemath Debian Med Packaging Team populations Debian Mir Team mir Debian Mono Group libgdiplus Debian Multimedia Maintainers aeolus clxclient freewheeling gmerlin handbrake iem-plugin-suite jaaa japa jkmeter jmeters kodi komposter libopenshot-audio projectm synfig zita-at1 zita-bls1 zita-dc1 zita-dpl1 zita-mu1 zita-rev1 Debian Multimedia Maintainers lv2-c++-tools Debian OCaml Maintainers camlimages Debian Perl Group libfont-freetype-perl libimager-perl Debian PHP Maintainers php8.2 Debian Pkg-e Team efl Debian Python Team matplotlib (U) pygame pyglet pymupdf Debian QA Group awffull directfb gfxboot glob2 openclonk ploticus tpb tvtime webdruid D
Re: Proposed MBF: Removal of libfreetype6-dev
On Sun, 16 Jul 2023 at 22:38:20 +1000, Hugh McMaster wrote: > Currently, there are 219 build-dependencies and 29 (direct) > dependencies on libfreetype6-dev, which has been released with > bullseye and bookworm. Lintian diagnoses this as "[build-]depends-on-obsolete-package" since 2.116.0 (MR at [1], instances of the relevant tags listed at [2] and [3]) which will hopefully help progress towards dropping the transitional package. [1] https://salsa.debian.org/lintian/lintian/-/merge_requests/417 (partially reverted in https://salsa.debian.org/lintian/lintian/-/merge_requests/452 but the freetype part remains) [2] https://udd.debian.org/lintian-tag.cgi?tag=build-depends-on-obsolete-package [3] https://udd.debian.org/lintian-tag.cgi?tag=depends-on-obsolete-package Unfortunately lintian.debian.org is not currently updating, so please don't use that as a source. smcv
Re: Proposed MBF: Removal of libfreetype6-dev
On 2023-07-16 22:38 +1000, Hugh McMaster wrote: > I will be removing the transitional package libfreetype6-dev (from the > source package freetype) later this year. > > Currently, there are 219 build-dependencies and 29 (direct) > dependencies on libfreetype6-dev, which has been released with > bullseye and bookworm. > I plan to file bugs against source packages first and against any > remaining binary packages later. > > A list of affected source and binary packages is attached. > > Happy to discuss if anyone has any suggestions or concerns. My suggestion is to drop the libfreetype6-dev package immediately and not waste your and other people's time with mass-bug filing, because libfreetype-dev already has a versioned Provides on libfreetype6-dev. This is what I did with three transitional -dev packages in ncurses, and although I had initially been skeptical it worked like a charm. See the discussion in #1032708. Cheers, Sven
Bug#1041273: ITP: rust-rustls-webpki -- web PKI X.509 certificate verification
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-rustls-webpki Version : 0.101.1 Upstream Contact: https://github.com/rustls/webpki/issues * URL : https://github.com/rustls/webpki * License : ISC Programming Lang: Rust Description : web PKI X.509 certificate verification rustls-webpki is a library that validates Web PKI (TLS/SSL) certificates. It's used by Rustls to handle certificate-related tasks required for implementing TLS clients and servers. . rustls-webpki is written in Rust and uses ring for cryptographic operations and low-level parsing. . This is a fork of the webpki project which adds a number of features required by the rustls project. . Rustls is a modern TLS library written in Rust. . This package contains the source for the Rust rustls-webpki crate, for use with cargo and dh-cargo. This package is needed for newer releases of package rust-rustls. It will be maintained in the collaborative debian section of salsa, at https://salsa.debian.org/debian/rust-rustls-webpki - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmS0K0YACgkQLHwxRsGg ASGn3A/7BP9I756uFtYaFBjDncLCceCNvtgO9QY+J62IdWaXeg5hj55pKDLrMlFb GS192qei2/y+sEdntXpfv4lgelw2rS9K9F4U3mPMWaiPfsYZSmdER4YwLF4Qlo9H I5igYRC+vF2VvprNGqTfzErm4hC8OfMTrlPiBV9SM1Dpn7zUTx2XkSpbv22shJ70 b7S93XfOwrfxEeZXSlkm1Pft5uX9XiklmPAabptbec1gDI0ZFGtDMsBvoiMnVVe8 hOhj04YD0Oyv6ky97drRlpECbbdgp/OsLkgqgK1GW9ZWQDf0wi5x2taUIKF3y6fs f51MlKVMNUG8aendet+Y0lHFGVjzDnqFc39nb2SGloIlCHnkWCLvjjWlxNwhyGwN 0by/hh27Acta01nAJAa/5ArN0hjxFTu/AC3oZR1dRsadXxZZnEVRquz/JHTlrQlc KeWB8PM1GcdqasKFhH2QNp48x/voo7004Oiq5TfjlBuv1gD3CqDeSZr26+RrhPAI CuJPTtQTUiZzC7xjPb1jQuf5shEyHTt/e96aVK+RNUAHm66NUf2F79mep042wd+P c/mmikCPt0p14mkNPTagstB+Bjb2sUdY6bzqqViRZEDakMO7/FNOjK6KucpqAH0C kQx6PRgIA0YrgjdJDGqaXDApKL8i8uOvdBLUlzzNCphmfrbpZnw= =Bfnz -END PGP SIGNATURE-
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Sat, Jul 15, 2023 at 02:04:57PM -0400, nick black wrote:
> Sam Hartman left as an exercise for the reader:
> > I consider anything that requires me to write wpa_supplicant config to
> > be a bad idea (unless I'm running an AP) and NetworkManager driving
> > wpa_supplicant is a better idea.
>
> i think everyone's agreed on this part.
For my part I tend to prefer writing wpa_supplicant configs, as they're
dead simple and allow for easy setting of priorities. Including them from
/etc/network/interfaces is also trivial.
Example /etc/network/interfaces and /etc/wpa_supplicant/wpa_supplicant.conf
from my laptop, with just the names changed:
---
source /etc/network/interfaces.d/*
auto eth0
iface eth0 inet dhcp
pre-up /sbin/mii-tool eth0 | /bin/grep -qv "no link"
auto wlan0
iface wlan0 inet dhcp
pre-up /sbin/mii-tool eth0 | /bin/grep -q "no link"
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
---
---
network={
ssid="Home"
psk="home password"
# Can also be this, via wpa_passphrase:
# psk=15bd59d568643e6781dd12f7e160b0589242472d3cc299bb5b0c4289d40c01af
priority=20
}
network={
ssid="CoffeeShop"
#psk="coffee password"
psk=ccd48495b2a1b7502f0bb0c5ca3689f6847b4f8532ce195ec17080308acb6bcd
priority=10
}
network={
key_mgmt=NONE
}
---
So, not quite everyone agrees. An advantage to using wpa_supplicant.conf
directly is that it works everywhere, and can generally be distributed as-
is across different operating systems.
--
Mason Loring Bliss ma...@blisses.orghttp://blisses.org/
For more enjoyment and greater efficiency, consumption is being standardized.
signature.asc
Description: PGP signature
Bug#1041285: ITP: pyuvm -- python implementation of UVM
Package: wnpp Severity: wishlist Owner: أحمد المحمودي (Ahmed El-Mahmoudy) * Package name: pyuvm Version : 2.9.1 Upstream Author : Ray Salemi * URL : https://github.com/pyuvm/pyuvm/ * License : Apache-2.0 Programming Lang: Python Description : python implementation of UVM pyuvm is the Universal Verification Methodology implemented in Python instead of SystemVerilog. pyuvm uses cocotb to interact with the simulator and schedule simulation events. pyuvm implements the most often-used parts of the UVM while taking advantage of the fact that Python does not have strict typing and does not require parameterized classes. The project refactors pieces of the UVM that were either overly complicated due to typing or legacy code. - Intend to maintain it Electronics team - Need a sponsor -- أحمد المحمودي (Ahmed El-Mahmoudy) Digital design engineer GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7 GPG Fingerprints: 6E2E E4BB 72E2 F417 D066 6ABF 7B30 B496 A7EF 5761 8206 A196 2084 7E6D 0DF8 B176 BC19 6A94 EDDD A1B7 signature.asc Description: PGP signature
Bug#1041288: ITP: cocotb -- coroutine based cosimulation library for writing VHDL and Verilog testbenches in Python
Package: wnpp Severity: wishlist Owner: أحمد المحمودي (Ahmed El-Mahmoudy) * Package name: cocotb Version : 1.8.0 Upstream Author : Chris Higgs, Stuart Hodgson * URL : https://github.com/cocotb/cocotb * License : BSD Programming Lang: Python Description : coroutine based cosimulation library for writing VHDL and Verilog testbenches in Python cocotb encourages the same philosophy of design re-use and randomized testing as UVM, however is implemented in Python. With cocotb, VHDL or SystemVerilog are normally only used for the design itself, not the testbench. cocotb has built-in support for integrating with continuous integration systems, such as Jenkins, GitLab, etc. through standardized, machine-readable test reporting formats. cocotb was specifically designed to lower the overhead of creating a test. cocotb automatically discovers tests so that no additional step is required to add a test to a regression. All verification is done using Python - Intend to maintain it within Electronics team - Need a sponsor -- أحمد المحمودي (Ahmed El-Mahmoudy) Digital design engineer GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7 GPG Fingerprints: 6E2E E4BB 72E2 F417 D066 6ABF 7B30 B496 A7EF 5761 8206 A196 2084 7E6D 0DF8 B176 BC19 6A94 EDDD A1B7 signature.asc Description: PGP signature
usertagging file conflicts [Was: Re: /usr-merge: continuous archive analysis]
Hi, On Wed, Jul 12, 2023 at 03:34:38PM +0200, Helmut Grohne wrote: > ## Usertagging bugs > > In order to avoid filing duplicates, I need a usertagging scheme for > bugs. Are there opinions on what user I should use for this? In the > simplest instance, I can use my DD login. Roughly speaking every issue > type shall translate to an individual usertag. Is there a common usertag > for undeclared file conflicts to reuse? I did not see any replies towards this aspect. I researched the situation and found that a longer while ago a...@grinser.de and later a...@debian.org used qa-file-conflict. I also discovered that Adreas uses debian...@lists.debian.org together with replaces-without-breaks, which is not what I'm looking for, but closely related. Then I found trei...@debian.org using edos-file-overwrite. That latter one seems like what I need here. Should we move it to the qa space and drop the edos part? I suggest debian...@lists.debian.org usertags file-overwrite. Otherwise, Ralf are you ok with me reusing your tag? What are the precise semantics of the tag? I imagine that it should only be filed against binary packages (one or more) and never with source packages. In case the causing package is known, it should be filed with the causing package and a version while other binary packages should be listed in affects. Otherwise, the bug should be filed against all involved binary packages. It is ok to group related conflicts by filing against multiple binary packages. These bugs should normally be release critical. These semantics allow machine consumption and facilitate avoiding duplicates in an automatic bug filing (to be agreed to). Does anyone have any objections to using this tag with these semantics? It would be most useful if other people filing such bugs would start using this usertag of course. :) I'm adding as possible metadata update at the end of this mail. It only handles conflicts involving possibly aliased paths though as those are my primary interest here. Helmut user debian...@lists.debian.org # android-libnativehelper/bullseye-backports vs android-libnativehelper-dev/bullseye usertags 1040323 + file-overwrite affects 1040323 + android-libnativehelper-dev # cadabra2/bullseye vs python3-notebook usertags 1036021 + file-overwrite affects 1036021 + python3-notebook # discodos/unstable vs mono-devel usertags 966115 + file-overwrite affects 966115 + mono-devel # firebird-utils/experimental vs firebird3.0-server usertags 1040321 + file-overwrite affects 1040321 + firebird3.0-server # kodi-addons-dev/bullseye-backports vs kodi-addons-dev-common/bullseye usertags 1040319 + file-overwrite affects 1040319 + kodi-addons-dev-common # occt vs oce mess usertags 1037067 + file-overwrite affects 1037067 + liboce-modeling-dev liboce-visualization-dev # rawloader usertags 1041299 + file-overwrite affects 1041299 + libplucene-perl graphicsmagick-imagemagick-compat # qt6-base-dev/experimental vs libqt6opengl6-dev usertags 1041300 + file-overwrite affects 1041300 + libqt6opengl6-dev # nex vs nvi usertags 1022957 + file-overwrite affects 1022957 + nvi # nfs-ganesha-ceph/bullseye-backports vs nfs-ganesha/bullseye usertags 1040362 + file-overwrite affects 1040362 + nfs-ganesha
