Re: iproute2: removing /sbin/ip link breaks other packages and possibly user scripts
Hello, Anyone not interested in ancient history can skip this mail. On Thu, Aug 15, 2024 at 11:20:47PM +0100, Colin Watson wrote: > On 2024-07-14 (five days before the iproute2 change was made), there was > this conversation on #debian-devel: > > 19:14 Is there a reason why iproute2 ships a symlink > from /sbin/ip to /bin/ip? I've looked into the packaging repo and it > seems to predate the git log. I was involved with iproute2 during the era when some sbin->bin shuffling happened, but apparently `ip` moving happened long before and only other tools followed later on. >From debian/changelog: iproute (20010824-7) unstable; urgency=medium * Move `ip' binary to /bin to fix FHS violation (closes: Bug#134812) -- Juan Cespedes Mon, 4 Mar 2002 00:20:30 +0100 (My recollection was that formorer moved ip, but apparently not. Calling it a FHS violation is IMHO a very strong claim.) Also relevant: iproute (20051007-4) unstable; urgency=low * Moved *stat binaries to /usr/bin/ (Closes: #350703) [...] -- Alexander Wirt Sun, 5 Feb 2006 09:47:36 +0100 ... and ... iproute (20110629-1) unstable; urgency=low [ Alexander Wirt ] * Install ss to /bin instead of /sbin. [...] -- Andreas Henriksson Mon, 04 Jul 2011 17:29:04 +0200 FWIW I've personally supported sbin and bin merging at some point, just for the simple reason that I'll never get back all the time wasted on arguing with people who want things moved around (but refuse to take it up with upstream). Apparently this is something which is still taking up time and even causing new bugs. > ... > 19:52 petn-randall: > https://codesearch.debian.net/search?q=%2Fsbin%2Fip%5Cb&literal=0 has > a pretty non-trivial list of things that would need fixed before > removing that (and of course some false positives) While I generally don't support hard-coding paths, not having the sbin symlinks means we have nothing in the location where upstream install these tools, which I also think is a bad idea. (I'm not sure if other distros follows upstreams location, but I'm still willing to call having the tools in bin a Debian-ism.) For a current list of tools where we override the upstream install path, see debian/iproute2.install in the source package or at: https://salsa.debian.org/kernel-team/iproute2/-/blob/debian/sid/debian/iproute2.install > > I realize it wasn't petn-randall who made this change, but it seems a > big coincidence that the symlink was dropped a few days after this IRC > conversation; and yet it seems nobody bothered to do the most basic due > diligence that I pointed out here, which is kind of sad. (I fixed > wireless-tools after this change caused an RC bug there.) > > -- > Colin Watson (he/him) [cjwat...@debian.org] > Regards, Andreas Henriksson
Bug#1056784: ITP: bankstown -- barebones, fast LV2 bass enhancement plugin
Package: wnpp Severity: wishlist Owner: Andreas Henriksson X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: bankstown Version : 1.0.0 Upstream Contact: https://github.com/chadmed/bankstown/issues * URL : https://github.com/chadmed/bankstown * License : MIT Programming Lang: Rust Description : barebones, fast LV2 bass enhancement plugin Description --- Speakers found in small devices have trouble reproducing bass and sub-bass faithfully. This is because they are power and space constrained, and cannot move the amount of air required to reproduce such low frequencies at audible volumes. Designers of modern devices get around this problem by taking advantage of the fact that humans are very easy to fool. We generate harmonics of bass and sub-bass frequencies to trick the human brain into thinking there is more bass than there really is. . This package contains a lv2 plugin implementing halfway-decent three-stage psychoacoustic bass approximation. Team maintenance --- I've discussed both with Debian rust-team and bananas-team and we've concluded that since this package does not yet integrate well with existing debcargo-conf tooling, we'll maintain the package under the bananas-team umbrella. Preliminary packaging is available at: https://salsa.debian.org/bananas-team/bankstown Naming --- Upstream name: bankstown crates.io name: bankstown-lv2 My proposition is that we use the upstream name as debian source name (bankstown) and then use `lv2-bankstown` binary package name, as bankstown is a lv2 plugin and that would fit generic naming conventions in Debian about packages fitting into a particular ecosystem. For reference, fedora packaging: https://src.fedoraproject.org/rpms/rust-bankstown-lv2/blob/rawhide/f/rust-bankstown-lv2.spec
Re: New Essential package procps-base
Hello, On Tue, Nov 14, 2023 at 05:29:01PM +1100, Craig Small wrote: > Hello, > For quite some time (since 2006!) there has been a discussion at[1] about > changing from the sysvinit-utils version of pidof to the procps one. A > quick scan of the various distributions shows that only Debian and Ubuntu > (and I assume most other downstreams) use the sysvinit-utils version. I support using procps implementation in Debian, to align us with the rest of the world. > > So to rehash some old drafts, here's the proposal. > > What: > Create a new package procps-base. This uses the existing procps source > package and just enable building of pidof. procps-base will be an Essential > package and only contain pidof. I however do not think pidof needs to be part of the Essential set. Instead I think pidof can just be part of procps package. The sysvinit-utils package will then pull in procps via a dependency (once sysvinit-utils stops being Essential), which would smooth the transition for all sysvinit users until LSB pidofproc has been implemented in all init scripts. > > Why: > This would bring the pidof variant in line with other distributions. > sysvinit-utils would no longer need to be Essential (though that's a > separate issue) and would only have init-d-script, fstab-decode, and > killall5. > > The majority of usage of pidof is in init or pre/post scripts, which really > should be using the LSB pidofproc function. That function in turn > optionally uses pidof if the pidfile parameter is not given. That's > probably a way forward for sometime in the future to not need procps-base > Essential, but it is a way off. Additionally most uses of pidof is `if pidof [...]; then` which will expand to false/else when the pidof command is not available (which it should be on all "normal" systems, as procps is already Priority important). A number of years ago I tested booting a regular debootstrapped system (with all priority important packages, etc) with sysvinit-utils excluded and that did not show a single warning about missing pidof. Someone might want to repeat that experiment. > > sysvinit-utils requires only libc6 while procps-base require libproc-2 but > this is the same library used for the ps,top,w etc tools which are > installed on most systems. > > > 1: https://bugs.debian.org/810018 Regards, Andreas Henriksson
Bug#1055897: ITP: speakersafetyd -- speaker protection daemon for embedded Linux systems
Package: wnpp Severity: wishlist Owner: Andreas Henriksson X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: speakersafetyd Version : 0.1.4 Upstream Contact: https://github.com/AsahiLinux/speakersafetyd/issues * URL : https://github.com/AsahiLinux/speakersafetyd/ * License : MIT Programming Lang: Rust Description : speaker protection daemon for embedded Linux systems Speaker protection for Apple Silicon (and potentially other) laptops with built-in speakers. The Apple M1, M2, etc laptops do not have protection for melting speakers in hardware, so need this (unlike many other laptops). The implementation is generic enough that it could in the future support other systems as well (eg. many embedded systems might be in the same situation if they have speakers). I hope to maintain this package in the rust-team (with the help of the bananas-team). Preliminary packaging available at: https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/560 See also: https://wiki.debian.org/Teams/Bananas Regards, Andreas Henriksson
Bug#1055634: ITP: asahi-nvram -- NVRAM utilities for Apple Silicon (arm) machines
Package: wnpp Severity: wishlist Owner: Andreas Henriksson X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: asahi-nvram Version : 0.2.0-1 Upstream Contact: https://github.com/WhatAmISupposedToPutHere/asahi-nvram/issues * URL : https://github.com/WhatAmISupposedToPutHere/asahi-nvram/ * License : MIT Programming Lang: Rust Description : NVRAM utilities for Apple Silicon (arm) machines I intend to package the asahi-nvram utilities that are useful for Apple Silicon (arm) machines, eg. m1 and m2 (probably also m3, etc). The asahi-nvram includes the following tools (which are separate crates and will thus likely be uploaded as separate source packages): * asahi-nvram - generic utility * asahi-btsync - sync MacOS bluetooth settings to bluez * asahi-wifisync - sync MacOS wifi settings to iwd * asahi-bless - select active boot partition (These all use a common apple-nvram crate/library for parsing the nvram content.) The intention is that the packages will be maintained within the rust-team (with support from the bananas-team) and a MR is available for review at: https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/555 Regards, Andreas Henriksson
Re: Bug#1055198: ITP: lzfse -- LZFSE Compression library
Hello, On Sat, Nov 04, 2023 at 08:47:11PM +0100, Timo Röhling wrote: > Hi, > > * Andreas Henriksson [2023-11-04 18:05]: > > I've previously suggested that maybe it would be better to set a > > debian-specific version (0d?), to avoid the theoretical situation that > > upstream one day ships a different ABI under the 1 so version. > Normally, I would agree, but in this particular case, Fedora already went > ahead and used SOVERSION 1 [1], so that version is "burned" and we might > just as well use it, too. > > [1] https://src.fedoraproject.org/rpms/lzfse/blob/rawhide/f/60.patch Thanks for pointing this out! > > > I would welcome peoples input here on what you think is best from the > > debian perspective. Obviously we're going to be incompatible with > > everyone else. > I don't think that "incompatible" patch you linked creates much of an issue, > because very few (if any) other library consumers will do this rather > unusual dlopen() "soft linking" dance (normal linking with e.g. "gcc > -llzfse" will automatically use the proper SONAME); besides, it is easy to > patch in Debian packages and trivial to work around with "apt install > liblzfse-dev" for everyone else. > > I do have one remark, though: the idea behind SONAME/SOVERSION is that you > have a common name for all versions which are binary backwards compatible. > Using the full version liblzfse.so.1.0 instead of libltfse.so.1 (i.e., the > SONAME) in your patch defeats that purpose: it will only work with the exact > version 1.0, but not any (hypothetical) future, backwards-compatible > versions. I hope I understood you correctly and this now adresses your concerns: https://salsa.debian.org/bananas-team/asahi-fwextract/-/commit/bfbd6f53c2e8721b9457c3a37421280a8a86dbc8 Regards, Andreas Henriksson
Re: Bug#1055198: ITP: lzfse -- LZFSE Compression library
On Thu, Nov 02, 2023 at 01:04:03AM +0100, Tobias Heider wrote: > Package: wnpp > Severity: wishlist > Owner: Tobias Heider > X-Debbugs-Cc: debian-devel@lists.debian.org > > * Package name: lzfse > Version : 1.0 > Upstream Authors: > URL : https://github.com/lzfse/lzfse > * License : BSD-3-Clause > Description : LZFSE Compression library > > LZFSE is a Lempel-Ziv style data compression algorithm using Finite > State Entropy coding. It targets similar compression rates at higher > compression and decompression speed compared to deflate using zlib. > > I plan to maintain this as part of the bananas team. Calling all SO versioning experts! The upstream project does not have any shared object version set. A downstream patch was introduced to set one: https://salsa.debian.org/bananas-team/lzfse/-/blob/debian/unstable/debian/patches/0001-debian-set-library-SONAME.patch Upstream has seen no activity since 2017, so trying to interact is assumed to not generate much. Also the ABI is unlikely to change (since no changes are being made). I've previously suggested that maybe it would be better to set a debian-specific version (0d?), to avoid the theoretical situation that upstream one day ships a different ABI under the 1 so version. I would welcome peoples input here on what you think is best from the debian perspective. Obviously we're going to be incompatible with everyone else[1], unless you install/runtime-depend-on the -dev package for the unversioned so symlink. Please speak now before this is submitted for NEW. FWIW lzfse is needed to extract files compressed by Apple and shipped in macOS containing embedded firmwares. See asahi-fwextract ITP: #1055206 Regards, Andreas Henriksson [1]: https://salsa.debian.org/bananas-team/asahi-fwextract/-/blob/debian/unstable/debian/patches/0001-Use-versioned-library-name-for-liblzfse.patch
Re: Bug#1055206: ITP: asahi-fwextract -- Asahi Linux firmware extractor
Hello, Filling out some of the missed information below and also providing some random thoughts of my own on this. On Thu, Nov 02, 2023 at 09:49:51AM +0100, Tobias Heider wrote: > Package: wnpp > Severity: wishlist > Owner: Tobias Heider > X-Debbugs-Cc: debian-devel@lists.debian.org > > * Package name: asahi-fwextract > Version : 0.6.12 > Upstream Authors: Asahi Linux Contributors > URL : https://github.com/AsahiLinux/asahi-installer/tree/main/asahi_firmware > * License : MIT > Description : Asahi Linux firmware extractor > > Scripts to extract firmware blobs from an EFI partition set up by the > Asahi Linux installer. > > I am planning to maintain this as part of the bananas team. > The firmware extractor is part of upstreams (custom) installer-repository. It also depends on asahi-scripts[1] which contains the asahi-fwupdate utility, et.al. This also contains initramfs integration to make the firmwares available during early boot and then provided as a tmpfs under /lib/firmware/vendor in the running system. Preliminary packaging is available at: https://salsa.debian.org/bananas-team/asahi-fwextract https://salsa.debian.org/bananas-team/asahi-scripts Some random thoughts: AIUI currently only initramfs-tools integration is shipped, but maybe it would be good to also provide dracut integration (as provided by upstream, if possible to integrate with debians dracut packaging)?! I don't see any asahi-scripts ITP yet. Since asahi-scripts is a dependency of asahi-fwextract I would have expected one to be posted before this. Maybe the multiple-upstream-tarballs feature could be used to package them together? But it's possibly more problems then benefits. Maybe the asahi-scripts should have a less generic binary package name? and split into multiple packages? Regards, Andreas Henriksson [1]: https://github.com/AsahiLinux/asahi-scripts
Re: Policy consensus on transition when removing initscripts.
Hello Thomas Goirand, On Wed, Jun 28, 2023 at 10:01:13AM +0200, Thomas Goirand wrote: > On 6/27/23 17:45, Andreas Henriksson wrote: > > Dropping things and letting people pick them up if they > > think they are still useful seems to be the only practical way forward. > > It's not. As written by Russ in this thread, filling a bug against > orphan-sysvinit-scripts so it takes over the abandoned script is. I wouldn't > mind seeing this mandatory, and written in the policy. You seem to have missed this part of my message: https://bugs.debian.org/934463 Please note: Date: Sun, 11 Aug 2019 12:46:52 +0200 This soon turns 4 years old! (And my original message still contains my advice to put this in the initscripts package because as I understand it the orphan-* is supposed to be optional, but you do as you please.) As an absolute minimum here, I request that any kind of mandatory coordination comes with a specified official timeout (that's way less than 4 years obviously). Regards, Andreas Henriksson
Re: Policy consensus on transition when removing initscripts.
Hello all, On Sun, Jun 25, 2023 at 03:15:24PM +0100, Mark Hindley wrote: > Hello friends and colleagues, [...] > To avoid breakage of existing systems and facilitate ongoing support for > non-systemd inits, I would like to establish a consensus for > > - stating that initscripts remain useful. If you add '... for non-default init systems' I might agree, but for the default init system I consider init scripts harmful. > > - requiring a coordinated transition of any initscript a maintainer wishes to >drop to the orphan-sysvinit-scripts package and providing the relevant >copyright information. Consider my vote AGAINST anything that puts the burden on package maintainers to do any extra work at this point. "Policy is not a stick to beat people with", etc. If you want me to take suggestions like coordination seriously then please consider adressing https://bugs.debian.org/934463 soon or admit that sysvinit maintenance lacks the resources to do coordinated transitions. Dropping things and letting people pick them up if they think they are still useful seems to be the only practical way forward. Regards, Andreas Henriksson
Re: Please, minimize your build chroots
Hello, I've previously discussed this topic with Santiago Vila on a bug report but sharing my opinion here for the wider audience. On Sat, Jan 28, 2023 at 12:20:16AM +0100, Santiago Vila wrote: > El 27/1/23 a las 22:37, Adrian Bunk escribió: [...] > This is not the right time to change policy. This is the right time to question your interpretation of policy. Policy is not a religion. Policy has many bugs. Policy is very outdated. Doing something just because an outdated document says so is worse than not doing anything in my opinion. You need to understand if what you're actually doing is correct and then see if policy agrees with you to justify the severity. Or as the saying goes: Policy is not a stick to beat people with! Here's an example you could follow: https://lists.debian.org/debian-policy/2022/12/msg00023.html (I don't agree with the suggestion. It was however suggested on the correct list and since there was no traction to the suggestion it was not followed up with mass bug filing. Minimal disruption to the project. Updating the definition/description of the Priority levels would however be very useful. The description seem very outdated, to the point of being irrelevant, by now.) [...] > In general, disputing the severity because it does not happen in the buildds > misses completely the point of what should be the goal, namely, a distribution > which may be rebuilt by everybody following documented procedures, not > a distribution which may only be rebuilt in our buildds. > > The end user MUST be able to rebuild the packages. Otherwise our > free software licenses are meaningless in practice. Claiming there's no point to free software when the problem is simply that you are using an *unsupported* setup?!?! All debootstrap variants include Priority: required packages. As you can see they do so for a reason! The --exclude option of debootstrap works equally well even on Essential: yes packages. Being able to experiment like this is great! It is however still just an experiment which does not warrant filing release-critical bugs against various packages. > > It is not helpful if people try to force the few people who are doing > > QA work to spend their scarce QA time on fixing bugs that only happen > > when building on single-core machines or in non-UTF-8 locales or without > > packages that are in practice installed everywhere, by making such > > issues that are not a problem on our buildds release critical bugs. > > That's the wrong approach. If the end user wants to make a modification, > they can't use our buildd network. [...] There are alot of packages which does not properly build in an unclean environment. In practise you need a controlled build environment to properly build debian archive packages form source (which starts with deboostrap --variant=buildd ...). If you think people should be able to build on top of their regular install with various packages installed and various configurations it would be much better if you tried to fix the many packages who fails in this scenario. If you think every packages should list just about all of the archive in Build-Conflicts just to not pick up unwanted extra autodetected dependencies that make the package FTBFS then I think it would be a good idea to check if there's actually project consensus on that. If you think that every package must use configure flags to override autodetection of features, seek project consensus. Discuss it on the policy list, where they'll probably tell you to first fix the archive (without filing RC-bugs) and then come back. If you want to do mass bug filing of release-critical severity you better make sure there's project consensus on what you're doing and than you're not just wasting everybodys limited time. Multiple people have now raised their conserns with your approach. As I've said before I appreciate the bug reports being filed, even if it's just for "theoretical correctness", but a proper severity would be wishlist. If your only motivation for this is to be allowed to file release-critical bugs, then I think it's better if you just stop. Regards, Andreas Henriksson
Bug#1026275: ITP: mender-connect -- remote shell access add-on
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: mender-connect Version : 2.1.0-1 Upstream Author : Nothern.Tech * URL : https://github.com/mendersoftware/mender-connect * License : Apache-2.0 Programming Lang: Go Description : remote shell access add-on Mender: remote shell access add-on . Mender is an open source over-the-air (OTA) software updater for embedded Linux devices. Mender comprises a client running at the embedded device, as well as a server that manages deployments across many devices. See: https://tracker.debian.org/mender-client . This repository contains the remote shell access add-on. It enhances the Mender client (https://github.com/mendersoftware/mender), allowing to log in to the devices remotely and start a shell in a remote terminal session.
Bug#1026274: ITP: golang-github-vmihailenco-msgpack.v5 -- MessagePack (msgpack.org) encoding for Golang
Package: wnpp
Severity: wishlist
Owner: Andreas Henriksson
* Package name: golang-github-vmihailenco-msgpack.v5
Version : 5.3.5-1
Upstream Author : Vladimir Mihailenco
* URL : https://github.com/vmihailenco/msgpack
* License : BSD-2-clause
Programming Lang: Go
Description : MessagePack (msgpack.org) encoding for Golang
MessagePack encoding for Golang
.
Features
.
* Primitives, arrays, maps, structs, time.Time and interface{}.
* Appengine \*datastore.Key and datastore.Cursor.
* CustomEncoder/CustomDecoder interfaces for custom encoding.
* Extensions to encode type information.
* Renaming fields via msgpack:"my_field_name" and alias via
msgpack:"alias:another_name".
* Omitting individual empty fields via msgpack:",omitempty" tag or all
empty fields in a struct.
* Map keys sorting.
* Encoding/decoding all structs as arrays or individual structs.
* Encoder.SetCustomStructTag with Decoder.SetCustomStructTag
can turn msgpack into drop-in replacement for any tag.
* Simple but very fast and efficient queries.
This is a dependency for upcoming mender-connect packaging.
Note that .v2 of this package is already available, but this is .v5.
Bug#1026273: ITP: golang-github-vmihailenco-tagparser.v2 -- Opinionated Golang tag parser
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: golang-github-vmihailenco-tagparser.v2 Version : 2.0.0-1 Upstream Author : Vladimir Mihailenco * URL : https://github.com/vmihailenco/tagparser * License : BSD-2-clause Programming Lang: Go Description : Opinionated Golang tag parser Opinionated Golang tag parser This is a dependency for the upcoming mender-connect packaging. (Actually a dep of golang-github-vmihailenco-msgpack.v5 and not mender-connect directly.) Note that an non-API-versioned version of this is already available in the archive, but this is .v2.
Bug#1026272: ITP: golang-github-go-ozzo-ozzo-validation.v4 -- idiomatic Go (golang) validation package.
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: golang-github-go-ozzo-ozzo-validation.v4 Version : 4.3.0-1 Upstream Author : Ozzo Framework * URL : https://github.com/go-ozzo/ozzo-validation * License : Expat Programming Lang: Go Description : idiomatic Go (golang) validation package. ozzo-validation is a Go package that provides configurable and extensible data validation capabilities. It has the following features: . * use normal programming constructs rather than error-prone struct tags to specify how data should be validated. * can validate data of different types, e.g., structs, strings, byte slices, slices, maps, arrays. * can validate custom data types as long as they implement the Validatable interface. * can validate data types that implement the sql.Valuer interface (e.g. sql.NullString). * customizable and well-formatted validation errors. * error code and message translation support. * provide a rich set of validation rules right out of box. * extremely easy to create and use custom validation rules. This package is a dependency for the upcoming mender-connect packaging.
Re: epoch for tss2 package
Hello Debora Babb, On Wed, Oct 19, 2022 at 11:04:35PM -0700, Debora Velarde Babb wrote: > Greetings, > > The upstream package for tss2 has been renamed ibmtss. When the name > was changed upstream, the version number convention also changed. > Upstream tss2-1470 was updated to ibmtss-1.3.0. The current version of > ibmtss is now 1.6.0. I believe I need to use an epoch number to handle > the version change correctly. Upstream renaming their project is one of the very few chances you get to GET RID OF an epoch in a debian package! > > Initially I attempted to create the package with the new name ibmtss. > There was some discussion on debian-mentors list and the response was > that I should NOT change the name to ibmtss and instructed to instead > use an epoch number. This seems like very bad advice to me. IMHO you should: 1. package the new project under the new name. (i.e. rename both source and binary packages.) 2. Provide additional empty binary (transitional) packages under the old name which depends on the respective new binary packages, so old installations gets upgraded to the new package. 3. Use a debian/rules override to alter version number *only* for the empty transitional packages, so that they get a higher version number than was previously provided. eg. last-tss2-version+really1.3.0-1 eg. override_dh_gencontrol: # Make transitional packages have a higher version number # than the old binary packages built from src:tss2 (1045-1.2) dh_gencontrol --package=tss2 -- \ -v1045+really1.6.0-1 dh_gencontrol --package=libtss0 -- \ -v1045+really1.6.0-1 dh_gencontrol --package=libtss-dev -- \ -v1045+really1.6.0-1 # Use the correct version number for real binary packages dh_gencontrol --remaining-packages Once your transitional packages has shipped in a stable release, you can then remove them from debian/control and also drop the debian/rules override of dh_gencontrol in your next upload to unstable. > > I recently posted a packaging question to the debian-mentors list and > someone kindly explained that use of an epoch number needed to be > discussed on debian-devel first. That's correct and the reason is to avoid unneccesarily introducing epochs since they are so hard to get rid of (and confuse alot of users). > > Thank you, > Debora Babb Regards, Andreas Henriksson
Re: RFC: Additions to dpkg's Pre-Depends
On Wed, Jul 06, 2022 at 05:13:05AM +0200, Guillem Jover wrote: > Hi! [...] > * libaudit-dev > - Rationale: > This could allow to add Linux audit support to dpkg on package action > events. I've got a branch that might need minor polishing, but could > otherwise be merged. > > - Essential/Build-Essential: > On Linux it is already part of the pseudo-essential set. [...] > * libcap-dev > - Rationale: > This could allow to add support to start-stop-daemon (already code > available) to drop POSIX capabilities. And also in the future (either > later in 1.21.x or 1.22.x) to support fsys POSIX capabilities as part > of the fyss metadata tracking support that is upcoming. > > - Essential/Build-Essential: > On Linux it is already part of the pseudo-essential set. [...] IIRC there are several competing capability libraries already part of pseudo essential. I think it would be good if we could identify one and work towards having only that in pseudo essential (and in theory maybe the entire archive use it). Maybe it's out of scope for this discussion though... Unless I'm mistaken if dpkg dep on libcap(2) and libaudit, then dpkg would transitively dep on both libcap(2) and libcap-ng which seems suboptimal. https://tracker.debian.org/pkg/libcap2 https://tracker.debian.org/pkg/libcap-ng Regards, Andreas Henriksson
Bug#1000284: ITP: golang-github-ant0ine-go-json-rest -- A quick and easy way to setup a RESTful JSON API
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: golang-github-ant0ine-go-json-rest Version : 3.3.2-1 Upstream Author : Antoine Imbert * URL : https://github.com/ant0ine/go-json-rest * License : Expat Programming Lang: Go Description : A quick and easy way to setup a RESTful JSON API Go-Json-Rest is a thin layer on top of net/http that helps building RESTful JSON APIs easily. It provides fast and scalable request routing using a Trie based implementation, helpers to deal with JSON requests and responses, and middlewares for functionalities like CORS, Auth, Gzip, Status ... . https://godoc.org/github.com/ant0ine/go-json-rest/rest . This package will be maintained under the go-team umbrella and used as a build-dependency for golang-github-mendersoftware-go-lib-micro (once packaged, see ITP).
Bug#1000280: ITP: golang-github-mendersoftware-go-lib-micro -- Group of golang packages for developing microservices.
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: golang-github-mendersoftware-go-lib-micro Version : 0.0~git20211108.4e20429-1 Upstream Author : Mender * URL : https://github.com/mendersoftware/go-lib-micro * License : Apache-2.0 Programming Lang: Go Description : Group of golang packages for developing microservices. Mender: go-lib-micro Mender is an open source over-the-air (OTA) software updater for embedded Linux devices. Mender comprises a client running at the embedded device, as well as a server that manages deployments across many devices. . This repository contains the Mender go-lib-micro library, which is part of the Mender server. The Mender server is designed as a microservices architecture and comprises several repositories. . The go-lib-micro library is a collection of utilities and middlewares shared among microservices in the Mender ecosystem. . This package will be used as a build-dependency of mender-cli when updating to 1.7.0 (and possibly other mender components). The package will be team-maintained under the go-team umbrella.
Bug#992373: ITP: golang-github-mendersoftware-progressbar -- Minimal progressbar used in Mender projects
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: golang-github-mendersoftware-progressbar Version : 0.0.3-1 Upstream Author : Mender * URL : https://github.com/mendersoftware/progressbar * License : Apache-2.0 Programming Lang: Go Description : Minimal progressbar used in Mender projects Progressbar: A simple and minimalistic Golang progressbar for Mendersoftware projects. . This is a dependency for updating the mender-client package to new upstream release 3.0.0.
Re: Q: Number of RC bugs
Hello, On Mon, Feb 22, 2021 at 03:49:19PM +0900, Hideki Yamane wrote: > Hi, > > Now we're in soft freeze for bullseye, and sometimes I check RC bugs > to find the issues that I can tackle with. > > And, I wonder numbers at https://bugs.debian.org/release-critical/ and > http://deb.li/rcbugs are quite different. > > bugs.d.o says "Number concerning the next release: 262" > udd says "59 bugs found (and "119 bugs" without "key package" option) > > What's the difference between those two? and which number is more accurate? The answers can be found in the filtering done in the UDD query. First the "Suites" are set differently (the b.d.o/release-critical/ testing is similar to selecting Bullseye), then the "Filters" section has several things set to 'exclude'. (Note that release-team has been busy setting will-remove and can-defer tags on bug reports for bullseye already.) The deb.li/rcbugs (UDD) query gives a much better view on remaining work to be tackled by the general contributor. Things that are already solved in sid is hopefully just a matter of it migrating to testing for example (so including those bugs is not very useful for a non-release-team members point of view). IMHO it would be better if bugs.debian.org/release-critical/ linked to relevant UDD queries. Regards, Andreas Henriksson
Bug#970428: ITP: golang-gopkg-cheggaaa-pb.v3 -- Console progress bar for Golang
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: golang-gopkg-cheggaaa-pb.v3 Version : 1.0.29-1 Upstream Author : Sergey Cherepanov * URL : https://github.com/cheggaaa/pb * License : BSD-3-clause Programming Lang: Go Description : Console progress bar for Golang Terminal progress bar for Go. The v1 and v2 is already packaged in debian, but now projects are starting to port to v3 so it's needed as a dependency for other things I'm thus considering packaging it. If someone else wants to take it over, please go for it!
Bug#964857: ITP: libeconf -- parse and manage key=value configuration files
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: libeconf Version : 0.3.8 Upstream Author : Pascal Arlt * URL : https://github.com/openSUSE/libeconf * License : Expat Programming Lang: C Description : parse and manage key=value configuration files libeconf is a highly flexible and configureable library to parse and manage key=value configuration files. It reads configuration file snippets from different directories and builds the final configuration file for the application from it. The first file is the vendor provided configuration file. There are two methods of overriding this vendor settings: copy the file from /usr/vendordir to /etc and modify the settings. Alternatively, a directory named file.suffix.d/ within /etc can be created, with drop-in files in the form name.suffix. This files contain only the changes of the specific settings the user is interested in. There can be serveral such drop-in files, they are processed in lexicographic order of their filename. In other words, this implements the configuration file scheme made popular by systemd unit files. The libeconf project is gaining traction and is already supported upstream in many of our core components. Introducing this library now for people to hopefully play around with it before a potential future discussion if this is something that should be widely adopted in core components in debian. (I would be very happy if someone else took over the maintenance of this package going forward.) Regards, Andreas Henriksson
Re: Mass bug filing: dependencies on GTK 2
Hi Jeff, On Wed, Apr 29, 2020 at 11:58:53AM +0200, Jeff wrote: > Hi Simon, > > I don't understand why gscan2pdf is in the list, as the versions in > stable, testing and unstable are Perl packages which use libgtk3-perl. > > Can you explain? reverse-depends -r testing -b src:gtk+2.0 2>&1 | grep gscan2pdf * gscan2pdf (for libgail-common) * gscan2pdf (for libgail-common) Regards, Andreas Henriksson
Re: Is an init required to obey policy-rc.d during boot ?
Hello, FWIW I do not share Andrej Shaduras view on this. My interpretation is basically the opposite. The invoke-rc.d, policy-rc.d and update-rc.d policy mandated abstraction is solely for the use of maintainer scripts in debian packages (and should not be used by init systems or elsewhere). Note also that the 'service' utility abstraction, which is supposed to be for (interactive) administator usage also does not care about policy-rc.d (as designed). Regards, Andreas Henriksson
Re: Is there still a point in installing libgcrypt to /lib instead of /usr/lib
Hello, On Tue, Feb 18, 2020 at 10:10:05PM +0100, Marco d'Itri wrote: > On Feb 18, Simon McVittie wrote: > > > No. Sorry, I phrased that badly. The consensus that I think we have is: > > we are no longer attempting to support systems booting without /usr > > mounted, and therefore it is not a bug if programs and libraries on the > > rootfs have dependencies in /usr. (That's a less strong guarantee than > > the one you are probably hoping for.) > We do not just have a consensus, this has also been a fact for a long > time now: .. and is completely unrelated to merged-usr (?!). > > kmod (25-2) unstable; urgency=medium > > * Moved the libraries to /usr/lib/. (Closes: #894566) > > -- Marco d'Itri Sat, 17 Nov 2018 01:56:00 +0100 > > > However, it doesn't give us a solution for what should happen to things > > that are canonically on the root filesystem and *do* have their absolute > > paths hard-coded somewhere, most critically /lib*/ld*.so.* and /bin/sh. > This does not matter as long as we have to support un-merged-/usr > systems. > > > I think some people (perhaps including Guillem?) might be advocating > > including executables in the second mechanism described above by > > moving them, on a per-package basis, to the root filesystem, and > > creating compatibility symlinks on the root filesystem if it has not > > undergone the /usr merge, like /bin/plymouth -> /usr/bin/plymouth and > > /sbin/iptables -> /usr/sbin/iptables. However, so far, this is rare > > (plymouth and iptables are among only a few examples on my laptop) > > and if adopted, it seems likely to be a slow transition: most of the > Slow, and also a lot of work for no significant benefits. As I see it there are two possible ways forward: a/ make merged-usr mandatory in one stable release and in the next we can just install the files under /usr. No per-package symlinks needed. b/ someone volunteers to write a debhelper addon which runs after dh_install, detects files in /lib, /bin and /sbin, moves them into /usr and generates the needed postinst code doing the compat symlinks for non-merged systems. The third option that I see as a no-go is that each package maintainer implements this on their own because: 1. Getting this finished will take way too long. 2. Manually written maintainer scripts is well known source of bugs. 3. Broken maintainer scripts are a horrible user experience. 4. People will keep repeating the mistake of shipping the symlinks in the package (once they realize manually written maintainer scripts are horrible?!) and thus break their package on merged-usr systems. 5. Doing the work this way will consume too much resources for no gain. 6. People being fine with the current status quo will not like 5/ further contributing to 1/. I think it's time we either try to figure out if/how we can actually get a decision on doing a/ soon, or for those who can't live with one release making merged-usr mandatory then start working on that debhelper needed to do b/ now! (Also when/if doing b/ or the 'no-go' option someone might want to think about how per-package symlinks generated in postinst is going to play nice with Essential: yes packages which are supposed to work unconfigured.) Regards, Andreas Henriksson
Regressions in keeping minbase variant minimal since buster
Out of interest I've checked the state of sid vs buster debootstrap --variant=minbase chroots to see if it's been growing while nobody has been paying attention. Apparently we have a couple of regressions. Sharing this in case someone else is interested in the result (or atleast hoping to wake someones interest so they fix it so I can be lazy ;-P). First here's a diff between buster-minbase and sid-minbase package list: $ diff -u buster-minbase-pkg.list sid-minbase-pkg.list | grep '^[+-]' --- buster-minbase-pkg.list 2020-01-01 13:53:54.528579149 +0100 +++ sid-minbase-pkg.list2020-01-01 13:51:36.656253717 +0100 -gcc-8-base:amd64 install +gcc-9-base:amd64 install +libcrypt1:amd64install -libhogweed4:amd64 install +libhogweed5:amd64 install -libnettle6:amd64 install +libnettle7:amd64 install +libpcre2-8-0:amd64 install +logsaveinstall +lsb-base install My analysis of this follows: Replacements (diff noise): gcc-8-base -> gcc-9-base libhogweed4 -> libhogweed5 libnettle6 -> libnettle7 Package splits (not really regressions): libcrypt1 -> split from glibc (pulled in by libc6, login, passwd) logsave -> split from e2fsprogs (pulled in by e2fsprogs - which is, since buster, deinstallable!) New (regressions): libpcre2-8-0 pulled in by libselinux1 - several core packages have moved to pcre2, so this is basically an unfinished libpcre(3) -> libpcre2 replacement. - grep should also move over so libpcre3 is no longer needed. Already reported in #907652 - (outside minbase there are however many other packages that will also need porting, eg. glib. Thus it might be hard to avoid having both PCRE libraries installed for a long time ahead.) lsb-base pulled in by sysvinit-utils - Already reported in #946399 - it might however finally be time to tackle the bigger task of making sysvinit-utils non-essential, see #851747. I'm tempted but will post details in a separate mail if I get motivated enough. Please reach out if you're interested in helping out! I've given this plenty of thought over the years so have a pretty good idea about it. Regards, Andreas Henriksson
Re: MBF: make fdisk non-essential
Hello Helmut, Thanks for your interest in completing this task. On Tue, Dec 24, 2019 at 01:03:05AM +0100, Helmut Grohne wrote: > Hi, > > I want make fdisk removable from an essential base system. The details > are listed in #947134. Since fdisk currently is pseudo-essential, > packages do not need to declare a dependency on it. When fdisk becomes > non-essential, such dependencies become required. A lot of packages that > use fdisk have since added the relevant dependency (see `apt rdepends > fdisk`). To fix the remaining packages, I intend to perform a mass bug > filing. AIUI ubuntu will need to keep this dependency until they release 20.04 (their next LTS?) for proper upgrades between LTS->LTS which I've been told they support. I'm not sure about their release procedure, so this might already be a done deal and there's no chance your changes will be imported into ubuntu before then anyway. I just thought I'd mention it and say that you might want to reach out and make sure someone on their side is aware. > > I intend to use the following text as a mail template. [...] > Please find a dd-list of affected packages attached. There are only 33 > binary packages left. In the absence of a discussion, I intend to file > the bugs in early January. I'll review the list at that time for added > dependencies. FYI ganeti #872131 libguestfs #872101 opensvc #872208 partimage #872107 python-diskimage-builder #872128 qemu #872098 salt #872099 sosreport #872215 vmdebootstrap #872137 waagent #872113 weresync #872103 More reports have been filed and some might have been reassigned to a different package since, so please also see: https://bugs.debian.org/cgi-bin/pkgreport.cgi?submitter=andr...@fatal.se&include=subject%3Afdisk&archive=both Likely some new packages have appeared since I did my bug filing. I also skipped filing some bug reports where my analysis concluded it wasn't needed, but your analysis might have come up different (and might be better than mine). You might however give the remaining packages an extra look if they're really affected. > > I do not intend to change the "Priority: important" or "Important: yes" > attributes of fdisk. Dropping the (XB-)Important: yes might be nice to do at some point. I'm not sure how that will affect systems where fdisk got pulled in via the transitional dependency and I guess the package are there marked as auto-installed. If we drop 'Important: yes' and the fdisk package ends up as an 'apt autoremove' target I think that would be bad (but I'm not sure if that's what actually happens). > > Helmut [...] FWIW Given bugs where filed over 2 years ago and AFAIR the progress on getting the bugs reports closed stopped quite a while ago I think it would be fair to just go ahead and make fdisk non-pseudo-essential and then just bumping severity of the remaining bug reports. Regards, Andreas Henriksson PS. Who-ever does the next util-linux upload I'd recommend you also include the Merge-Request !8 available on salsa util-linux repo while at it.
Re: epoch bump request for protracker
Hello Gürkan Myczko, On Mon, Dec 23, 2019 at 06:32:15AM +0100, Gürkan Myczko wrote: > Emailing only debian-devel, replies with cc to me please. > > protracker [1], version 2.b37-1 now release a non-beta version called 1.01. > Instead of permanently using 2.b37+really1.01, I'd go for > 1:1.01, and renaming protracker to pt2-clone [2] (as upstream calls it) (the > source+bin > pkg rename at a later time) > > So is it appropriate to bump an epoch in Debian to fix the versioning of > protracker? Upstream renaming is a very rare (and AFAIK *only*) chance for you to actually get rid of epochs cleanly! I'd very much suggest you take this chance! Basically what you do is rename everything and use the new version number, then you add transitional packages and for those you override version number generation in debian/rules and add an epoch *only* to the transitional packages. Once your package has shipped in a stable release, you can drop the transitional packages and the debian/rules override for them. eg. include /usr/share/dpkg/pkg-info.mk override_dh_gencontrol: dh_gencontrol -pmy-transitional-package -- -v1:$(DEB_VERSION) dh_gencontrol --remaining-packages for more examples see: https://codesearch.debian.net/search?q=dh_gencontrol.*-p.*-v.*%3A&literal=0 > > Kind regards, > > [1] https://packages.debian.org/sid/protracker > [2] https://github.com/8bitbubsy/pt2-clone > Regards, Andreas Henriksson
Bug#945087: ITP: golang-github-tidwall-tinyqueue -- Binary heap priority queues in Go
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: golang-github-tidwall-tinyqueue Version : 0.0~git20180302.1e39f55-1 Upstream Author : Josh Baker * URL : https://github.com/tidwall/tinyqueue * License : ISC Programming Lang: Go Description : Binary heap priority queues in Go Tinyqueue is a Go package for binary heap priority queues. Ported from the tinyqueue (https://github.com/mourner/tinyqueue) Javascript library. This is a dependency of garagemq a.k.a. kubemq.io
Bug#945086: ITP: golang-github-tidwall-rtree -- RTree implementation for Go
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: golang-github-tidwall-rtree Version : 0.0~git20180113.6cd4270-1 Upstream Author : Josh Baker * URL : https://github.com/tidwall/rtree * License : TODO Programming Lang: Go Description : RTree implementation for Go This package provides an in-memory R-Tree implementation for Go, useful as a spatial data structure. It has support for 1-20 dimensions, and can store and search multidimensions interchangably in the same tree. This is a dependency of garagemq a.k.a. kubemq.io
Bug#945084: ITP: golang-github-tidwall-grect -- Get the outer rectangle from GeoJSON, WKT, WKB
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: golang-github-tidwall-grect Version : 0.0~git20161006.ba9a043-1 Upstream Author : Josh Baker * URL : https://github.com/tidwall/grect * License : TODO Programming Lang: Go Description : Get the outer rectangle from GeoJSON, WKT, WKB GRECT Quickly get the outer rectangle for GeoJSON, WKT, WKB. This is a dependency of garagemq a.k.a. kubemq.io
Bug#945085: ITP: golang-github-tidwall-pretty -- Efficient JSON beautifier and compactor for Go
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: golang-github-tidwall-pretty Version : 1.0.0-1 Upstream Author : Josh Baker * URL : https://github.com/tidwall/pretty * License : TODO Programming Lang: Go Description : Efficient JSON beautifier and compactor for Go Pretty is a Go package that provides fast methods for formatting JSON for human readability, or to compact JSON for smaller payloads. . * pretty.Pretty will reformat the JSON for readability. * pretty.Color will add color to the result for printing to the terminal. The second param is used for a customizing the style, and passing nil will use the default pretty.TerminalStyle. * pretty.Ugly will reformat the JSON to make it more compact. . There's a PrettyOptions(json, opts) function which allows for customizing the output. This is a dependency of garagemq a.k.a. kubemq.io
Bug#945083: ITP: golang-github-tidwall-buntdb -- BuntDB is an embeddable, in-memory key/value database for Go with custom indexing and geospatial support
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: golang-github-tidwall-buntdb Version : 1.1.0-1 Upstream Author : Josh Baker * URL : https://github.com/tidwall/buntdb * License : TODO Programming Lang: Go Description : embeddable, in-memory key/value database for Go BuntDB is a low-level, in-memory, key/value store in pure Go. It persists to disk, is ACID compliant, and uses locking for multiple readers and a single writer. It supports custom indexes and geospatial data. It's ideal for projects that need a dependable database and favor speed over data size. . Features: * In-memory database for fast reads and writes * Embeddable with a simple API * Spatial indexing for up to 20 dimensions; Useful for Geospatial data * Index fields inside JSON documents * Collate i18n Indexes using the optional collate package * Create custom indexes for any data type * Support for multi value indexes; Similar to a SQL multi column index * Built-in types that are easy to get up & running; String, Uint, Int, Float * Flexible iteration of data; ascending, descending, and ranges * Durable append-only file format for persistence * Option to evict old items with an expiration TTL * Tight codebase, under 2K loc using the cloc command * ACID semantics with locking transactions that support rollbacks This is a dependency of garagemq a.k.a. kubemq.io
Bug#945080: ITP: golang-github-dgraph-io-ristretto -- A high performance memory-bound Go cache
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: golang-github-dgraph-io-ristretto Version : 0.0~git20191108.8d6a8a7-1 Upstream Author : Dgraph * URL : https://github.com/dgraph-io/ristretto * License : Apache-2.0 Programming Lang: Go Description : A high performance memory-bound Go cache Ristretto is a fast, concurrent cache library built with a focus on performance and correctness. . The motivation to build Ristretto comes from the need for a contention-free cache in Dgraph (https://github.com/dgraph-io/dgraph). . Features: * High Hit Ratios - with our unique admission/eviction policy pairing, Ristretto's performance is best in class. * Eviction: SampledLFU - on par with exact LRU and better performance on Search and Database traces. * Admission: TinyLFU - extra performance with little memory overhead (12 bits per counter). * Fast Throughput - we use a variety of techniques for managing contention and the result is excellent throughput. * Cost-Based Eviction - any large new item deemed valuable can evict multiple smaller items (cost could be anything). * Fully Concurrent - you can use as many goroutines as you want with little throughput degradation. * Metrics - optional performance metrics for throughput, hit ratios, and other stats. * Simple API - just figure out your ideal Config values and you're off and running.Status Ristretto is usable but still under active development. We expect it to be production ready in the near future. This is a dependency of garagemq a.k.a. kubemq.io
Bug#945082: ITP: golang-github-tidwall-btree -- B-Tree implementation for Go
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: golang-github-tidwall-btree Version : 0.0~git20191029.400434d-1 Upstream Author : Josh Baker * URL : https://github.com/tidwall/btree * License : Apache-2.0 Programming Lang: Go Description : B-Tree implementation for Go This package provides an in-memory B-Tree implementation for Go, useful as an ordered, mutable data structure. . This is a fork of the wonderful google/btree package. It's has all the same great features and adds a few more. . * Descend* functions for iterating backwards. * Iteration performance boost. * User defined context. . User defined context is a great new feature that allows for entering the same item into multiple B-trees, and each B-tree have a different ordering formula. This is a dependency of garagemq a.k.a. kubemq.io
Bug#945081: ITP: golang-github-subosito-gotenv -- Load environment variables from `.env` or `io.Reader` in Go.
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: golang-github-subosito-gotenv Version : 1.2.0+git20190917.de67a66-1 Upstream Author : Alif Rachmawadi * URL : https://github.com/subosito/gotenv * License : TODO Programming Lang: Go Description : Load environment variables from `.env` or `io.Reader` in Go. To modify your app environment variables, gotenv expose 2 main functions: * gotenv.Load * gotenv.Apply By default, gotenv.Load will look for a file called .env in the current working directory. . Behind the scene, it will then load .env file and export the valid variables to the environment variables. Make sure you call the method as soon as possible to ensure it loads all variables, say, put it on init() function. . Once loaded you can use os.Getenv() to get the value of the variable. This is a dependency of garagemq a.k.a. kubemq.io
Bug#945078: ITP: garagemq -- AMQP message broker implemented with golang
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: garagemq Version : 0.0~git20190703.39811a5+ds-1 Upstream Author : Valinurov Alexander * URL : https://github.com/valinurovam/garagemq * License : TODO Programming Lang: Go Description : AMQP message broker implemented with golang GarageMQ is a message broker that implement the Advanced Message Queuing Protocol (AMQP). Compatible with any AMQP or RabbitMQ clients (tested streadway/amqp and php-amqp lib) . The GarageMQ project is also knowns an KubeMQ (https://kubemq.io). . This package does not contain the admin-frontend/build files since debian packaging npm modules is "complicated". You can, after installing this package, download the files from github and `cp -a $SRCDIR/admin-frontend/build /var/lib/garagemq/admin-frontend/` to be able to use the admin frontend as intended.
Bug#945079: ITP: badger -- Fast key-value DB in Go.
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: badger Version : 2.0.0-1 Upstream Author : Dgraph * URL : https://github.com/dgraph-io/badger * License : Apache-2.0 Programming Lang: Go Description : Fast key-value DB in Go. BadgerDB is an embeddable, persistent and fast key-value (KV) database written in pure Go. It is the underlying database for Dgraph (https://dgraph.io), a fast, distributed graph database. It's meant to be a performant alternative to non-Go-based key-value stores like RocksDB. Project Status [Jun 26, 2019] Badger is stable and is being used to serve data sets worth hundreds of terabytes. Badger supports concurrent ACID transactions with serializable snapshot isolation (SSI) guarantees. A Jepsen-style bank test runs nightly for 8h, with --race flag and ensures the maintenance of transactional guarantees. Badger has also been tested to work with filesystem level anomalies, to ensure persistence and consistency. . Badger v1.0 was released in Nov 2017, and the latest version that is data-compatible with v1.0 is v1.6.0. . Badger v2.0, use a new storage format which won't be compatible with all of the v1.x. This is a dependency of garagemq a.k.a. kubemq.io
Bug#920435: ITP: mender-cli -- A general-purpose CLI for the Mender backend
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: mender-cli Version : 1.1.0-1 Upstream Author : Mender * URL : https://github.com/mendersoftware/mender-cli * License : Apache-2.0 Programming Lang: Go Description : A general-purpose CLI for the Mender backend Mender is an open source over-the-air (OTA) software updater for embedded Linux devices. Mender comprises a client running at the embedded device, as well as a server that manages deployments across many devices. . This package contains a standalone tool that makes it much easier to work with the Mender server management APIs (https://docs.mender.io/apis/management-apis). . The goal with mender-cli is to simplify integration between the Mender server and cloud services like continuous integration (CI)/build automation.
Re: Policy and procedures issue: init package hijacked via hostile NMU (declined by maintainers)
Hi, (Not sure debian-devel is the right place for this discussion, but oh well...) On Sat, Dec 22, 2018 at 08:32:07PM +0100, Guillem Jover wrote: > On Sat, 2018-12-22 at 10:11:53 -0800, Josh Triplett wrote: [...] > I think the summary mischaracterizes the situation a bit TBH. [...] > > - Dmitry refused to cancel the NMU, which then went into the archive. > > Dimitry refused to cancel the NMU *himself*. [...] He also said the maintainers had to get the CTTE to overrule his decision if they did not want to accept his NMU. (which apart from refusing to listen to very qualified developers with decades of experience also IMO suggests he has gotten the constitution completely backwards.) I have only seen a limited amount of Dmitrys work, but my impression is that he's not someone who should be trusted with unrestricted uploading privileges. I think fast-tracking him through NM was a mistake and would suggest he should take the full tour. Regards, Andreas Henriksson
Re: usrmerge -- plan B?
On Thu, Nov 22, 2018 at 12:54:45AM +0100, Svante Signell wrote: > Unfortunately Simon writes too long mails. Who can even thake the time to read > all these verbalism. Things could be written more condensed. Please, can > somebody summarize his verbosity! Maybe he is a politcian? Here's a dumbed down narrative for you: You're all sadly uninformed, ignorant and clueless. Please let me spell it out for you: <... details people don't care about snipped...> Can y'all now please stop posting stupid shit about this topic? (And as if for nothing else this mail is proof of the answer is a sound "NO!" from the peanut gallery.) The only people who have time to read the full mail are the ones who actually want to learn. Regards, Andreas Henriksson PS. Thanks to smcv for being naive enough to think that providing knowledge is a useful thing to do in a food/shit-fight. Please keep up your useful work of trying raise the bar for discussions in debian. PPS. For gods sake do NOT even think about CCing me on this thread.
Bug#914119: ITP: mender-client -- Mender over-the-air software updater client.
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: mender-client Version : 1.6.0b1+git20181015.3032b74-1 Upstream Author : Mender * URL : https://github.com/mendersoftware/mender * License : Apache 2.0 Programming Lang: Go Description : Mender over-the-air software updater client. Mender: over-the-air updater for embedded Linux devices Mender is an open source over-the-air (OTA) software updater for embedded Linux devices. Mender comprises a client running at the embedded device, as well as a server that manages deployments across many devices. . Embedded product teams often end up creating homegrown updaters at the last minute due to the need to fix bugs in field-deployed devices. However, the most important requirement for an embedded update process is robustness, for example loss of power at any time should not brick a device. This creates a challenge given the time constraints to develop and maintain a homegrown updater. . Mender aims to address this challenge with a robust and easy to use updater for embedded Linux devices, which is open source and available to anyone. . Robustness is ensured with atomic image-based deployments using a dual A/B rootfs partition layout. This makes it always possible to roll back to a working state, even when losing power at any time during the update process. . Ease of use is addressed with an intuitive UI, comprehensive documentation (https://docs.mender.io/), a meta layer for the Yocto Project (https://github.com/mendersoftware/meta-mender) for easy integration into existing environments, and high quality software (see the test coverage badge). . This repository contains the Mender client updater, which can be run in standalone mode (manually triggered through its command line interface) or managed mode (connected to the Mender server). . Mender not only provides the client-side updater, but also the backend and UI for managing deployments as open source. The Mender server is designed as a microservices architecture and comprises several repositories. . Mender logo Getting started To start using Mender, we recommend that you begin with the Getting started section in the Mender documentation (https://docs.mender.io/). . In order to support rollback, the Mender client depends on integration with U-Boot and the partition layout. It is therefore most easily built as part of your Yocto Project image by using the meta layer for the Yocto Project (https://github.com/mendersoftware/meta-mender).
Bug#914117: ITP: golang-github-mendersoftware-scopestack --
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: golang-github-mendersoftware-scopestack Version : 0.0~git20180403.c2f5599-1 Upstream Author : Mender * URL : https://github.com/mendersoftware/scopestack * License : Apache 2.0 Programming Lang: Go Description : Scopestack package for Golang Build Status (https://travis-ci.org/mendersoftware/scopestack) Coverage Status (https://coveralls.io/github/mendersoftware/scopestack?branch=master) Godoc (https://godoc.org/github.com/mendersoftware/scopestack) This is a dependency needed by mender-client package.
Bug#914118: ITP: golang-github-mendersoftware-mender-artifact -- Library for managing Mender artifact files
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: golang-github-mendersoftware-mender-artifact Version : 2.3.0b1+git20181022.1bedfca-1 Upstream Author : Mender * URL : https://github.com/mendersoftware/mender-artifact * License : Apache 2.0 Programming Lang: Go Description : Library for managing Mender artifact files Build Status (https://travis-ci.org/mendersoftware/mender-artifact) codecov (https://codecov.io/gh/mendersoftware/mender-artifact) Go Report Card (https://goreportcard.com/report/github.com/mendersoftware/mender-artifact) Mender Artifacts Library Mender is an open source over-the-air (OTA) software updater for embedded Linux devices. Mender comprises a client running at the embedded device, as well as a server that manages deployments across many devices. . This repository contains the artifacts library, which is used by the Mender client, command line interface, server and for build integration with the Yocto Project. . The artifacts library makes it easy to programmatically work with a Mender artifact, which is a file that can be recognized by its .mender suffix. Mender artifacts can contain binaries, metadata, checksums, signatures and scripts that are used during a deployment. The artifact format acts as a wrapper, and uses the tar format to bundle several files into one. . In its simplest form, an artifact contains just a rootfs image, along with its checksum, id and device type compatibility. . The artifacts library might also be useful for other updaters or purposes. We are always happy to see other uses of it! . Mender logo Getting started To start using Mender, we recommend that you begin with the Getting started section in the Mender documentation (https://docs.mender.io/). Using the library You can use the parser and reader in go in the standard way: . . import ( "github.com/mendersoftware/mender-artifact/parser" "github.com/mendersoftware/mender-artifact/reader" ... ) . . For sample usage, please see the Mender client source code (https://github.com/mendersoftware/mender). Contributing We welcome and ask for your contribution. If you would like to contribute to Mender, please read our guide on how to best get started contributing code or documentation (https://github.com/mendersoftware/mender/blob/master/CONTRIBUTING.md). License Mender is licensed under the Apache License, Version 2.0. See LICENSE (https://github.com/mendersoftware/artifacts/blob/master/LICENSE) for the full license text. Security disclosure We take security very seriously. If you come across any issue regarding security, please disclose the information by sending an email to secur...@mender.io (secur...@mender.io). Please do not create a new public issue. We thank you in advance for your cooperation. Connect with us• Join our Google group (https://groups.google.com/a/lists.mender.io/forum/#!forum/mender)• Follow us on Twitter (https://twitter.com/mender_io?target=_blank). Please feel free to tweet us questions.• Fork us on Github (https://github.com/mendersoftware)• Email us at cont...@mender.io (mailto:cont...@mender.io) This is a dependency needed by mender-client package. It also provides the mender-artifact binary package which contains tools to build mender artifacts.
Bug#914116: ITP: golang-github-mendersoftware-mendertesting --
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: golang-github-mendersoftware-mendertesting Version : 0.0~git20180410.9e728b5-1 Upstream Author : Mender * URL : https://github.com/mendersoftware/mendertesting * License : Apache 2.0 Programming Lang: Go Description : Testing package for Golang Build Status (https://travis-ci.org/mendersoftware/mendertesting) codecov (https://codecov.io/gh/mendersoftware/mendertesting) Godoc (https://godoc.org/github.com/mendersoftware/mendertesting) Go Report Card (https://goreportcard.com/report/github.com/mendersoftware/mendertesting) This is a dependency needed by mender-client package.
Bug#914115: ITP: golang-github-mendersoftware-log -- Logging package
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: golang-github-mendersoftware-log Version : 0.0~git20180403.f608c95-1 Upstream Author : Mender * URL : https://github.com/mendersoftware/log * License : Apache 2.0 Programming Lang: Go Description : Logging package Log package for Golang Build Status (https://travis-ci.org/mendersoftware/log) Coverage Status (https://coveralls.io/github/mendersoftware/log?branch=master) Godoc (https://godoc.org/github.com/mendersoftware/log) This is a dependency needed by mender-client package.
Bug#914113: ITP: golang-github-ungerik-go-sysfs -- Go package for Linux sysfs
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: golang-github-ungerik-go-sysfs Version : 0.0~git20170424.9c991ee-1 Upstream Author : Erik Unger * URL : https://github.com/ungerik/go-sysfs * License : MIT Programming Lang: Go Description : Go package for Linux sysfs go-sysfs Go package for Linux sysfs This is a dependency needed by mender-client package.
Bug#914114: ITP: golang-github-bmatsuo-lmdb-go -- Bindings for the LMDB C library
Package: wnpp
Severity: wishlist
Owner: Andreas Henriksson
* Package name: golang-github-bmatsuo-lmdb-go
Version : 1.8.0+git20170215.a14b5a3-1
Upstream Author : Bryan Matsuo
* URL : https://github.com/bmatsuo/lmdb-go
* License : BSD-3-clause
Programming Lang: Go
Description : Bindings for the LMDB C library
lmdb-go releases/v1.8.0 (releases) C/v0.9.19
(https://github.com/LMDB/lmdb/blob/mdb.RE/0.9/libraries/liblmdb/CHANGES)
Build Status (https://travis-ci.org/bmatsuo/lmdb-go) Go bindings to the
OpenLDAP Lightning Memory-Mapped Database (LMDB). Packages Functionality
is logically divided into several packages. Applications will usually
need to import lmdb but may import other packages on an as needed basis.
.
Packages in the exp/ directory are not stable and may change without
warning. That said, they are generally usable if application dependencies
are managed and pinned by tag/commit.
.
Developers concerned with package stability
should consult the documentation. lmdb GoDoc
(https://godoc.org/github.com/bmatsuo/lmdb-go/lmdb)
stable (#user-content-versioning-and-stability) go import
"github.com/bmatsuo/lmdb-go/lmdb"
.
.
Core bindings allowing low-level access to LMDB. lmdbscan
GoDoc (https://godoc.org/github.com/bmatsuo/lmdb-go/lmdbscan)
stable (#user-content-versioning-and-stability) go import
"github.com/bmatsuo/lmdb-go/lmdbscan"
.
.
A utility package for scanning database
ranges. The API is inspired by bufio.Scanner
(https://godoc.org/bufio#Scanner) and the python cursor implementation
(https://lmdb.readthedocs.org/en/release/#cursor-class). exp/lmdbpool
GoDoc (https://godoc.org/github.com/bmatsuo/lmdb-go/exp/lmdbpool)
experimental (#user-content-versioning-and-stability) go import
"github.com/bmatsuo/lmdb-go/exp/lmdbpool"
.
.
A utility package which facilitates reuse of lmdb.Txn objects using
a sync.Pool. Naively storing lmdb.Txn objects in sync.Pool can
be troublesome. And the lmdbpool.TxnPool type has been defined as a
complete pooling solution and as reference for applications attempting
to write their own pooling implementation.
.
The lmdbpool package is relatively new. But it has a lot
of potential utility. And once the lmdbpool API has been
ironed out, and the implementation hardened through use by real
applications it can be integrated directly into the lmdb package
for more transparent integration. Please test this package and
provide feedback to speed this process up. exp/lmdbsync GoDoc
(https://godoc.org/github.com/bmatsuo/lmdb-go/exp/lmdbsync)
experimental (#user-content-versioning-and-stability) go import
"github.com/bmatsuo/lmdb-go/exp/lmdbsync"
.
.
An experimental utility package that provides synchronization necessary
to change an environment's map size after initialization. The package
provides error handlers to automatically manage database size and retry
failed transactions.
.
The lmdbsync package is usable but the implementation of Handlers
are unstable and may change in incompatible ways without notice.
The use cases of dynamic map sizes and multiprocessing are niche
and the package requires much more development driven by practical
feedback before the Handler API and the provided implementations can be
considered stable. Key FeaturesIdiomatic API API inspired by BoltDB
(https://github.com/boltdb/bolt) with automatic commit/rollback of
transactions. The goal of lmdb-go is to provide idiomatic database
interactions without compromising the flexibility of the C API.
.
NOTE: While the lmdb package tries hard to make LMDB as easy to
use as possible there are compromises, gotchas, and caveats that
application developers must be aware of when relying on LMDB to store
their data. All users are encouraged to fully read the documentation
(https://godoc.org/github.com/bmatsuo/lmdb-go/lmdb) so they are aware
of these caveats.
.
Where the lmdb package and its implementation decisions do not
meet the needs of application developers in terms of safety or
operational use the lmdbsync package has been designed to wrap lmdb and
safely fill in additional functionality. Consult the documentation
(https://godoc.org/github.com/bmatsuo/lmdb-go/exp/lmdbsync) for more
information about the lmdbsync package. API coverage The lmdb-go
project aims for complete coverage of the LMDB C API (within reason).
Some notable features and optimizations that are supported: • Idiomatic
subtransactions ("sub-updates") that allow the batching of updates.•
Batch IO on databases utilizing the MDB_DUPSORT and MDB_DUPFIXED flags.•
Reserved writes than can save in memory copies converting/buffering into
[]byte. For tracking purposes a list of unsupported features is kept in
an issue (https://github.com/bmatsuo/lmdb-go/issues/1). Zero-copy reads
Applications with high performance requirements can opt-in to fast,
zero-copy r
Re: Debian Buster release to partially drop non-systemd support
On Sun, Oct 14, 2018 at 10:17:11PM +0200, Thorsten Glaser wrote: > On Sun, 14 Oct 2018, Ben Hutchings wrote: > > > > > > sysvinit currently has two maintainers, but they've only > > > > > ever made one upload (over a year ago). > > > > Why would sysvinit need uploads? It’s largely working software > > > that needs few changes. > > > > That may be, but there are many open bugs with patches that have not > > been applied or answered. One of them was even RC and unanswered for > > over 18 months. (I downgraded it as it isn't really RC.) > > OK, that’s a good point. Please note that sysvinit dependencies still have open RC bugs which noone is caring for. Please also note that even if you don't consider things like systemd-shim to be essential for a sysvinit system, I think sysvinit is getting closer and closer to being removed. Usually the debian way is to say that whoever reaps the benefits gets to do the work. That hasn't been the case for sysvinit for atleast several years now. The only reason sysvinit is still around is because people who don't use it and largely don't care about it keeps doing the work to keep it afloat (while people who use it keep repeating "everyhing is fine, it's mature" and stick their heads in the sand). Multiple people have explained multiple different ways we could simply kick sysvinit out of the key packages set. That would mean a pretty imminent removal. So please! Don't wait until you one day wake up to that reality! By then it'll be to late to realize everything is actually NOT fine. Your complaints will go to deaf ears, because it's been a long time coming already. I would love to see someone with time and motivation to properly give sysvinit the maintenance it deserves, but at the same time if we stay at the current status quo I think it's better if sysvinit just gets removed the sooner the better. Regards, Andreas Henriksson
Re: epoch bump request for gnome-calculator
Hi Jeremy, My comments below for what it's worth. You should likely not take anything I say too seriously, but maybe I happen to mention something that can be food for thought. On Wed, Sep 26, 2018 at 09:47:38AM -0400, Jeremy Bicha wrote: > Emailing both debian-devel and the Debian GNOME mailing list. > > I am requesting project approval for me to upload gnome-calculator > with an epoch. > > Five years ago, gcalctool 6.4 was renamed to gnome-calculator and > renumbered to 3.8. This seemed like a clear case for an epoch since > this was a permanent change in the version numbering scheme. For me, wherever a (source and binary) package is removed it's a clear case that it's an opportunity to *get rid* of epochs. Upstream renaming things are a rare opportunity and should be utilized! > > I made this change in the Debian VCS and uploaded it to Ubuntu. At the > time I did not have upload rights to Debian and Ubuntu has deadlines. > > A month later, a Debian GNOME team member recognized that we could use > a dh_gencontrol hack [1] to only add the epoch to the gcalctool > transitional package and we didn't need an epoch for gnome-calculator. > Similarly, we could have used this hack for many of the gnome-games > packages when they were split into separate source packages but we > didn't because we uploaded them before we made this change. (The > version numbering didn't change but gnome-games had an epoch we didn't > need to carry to the new packages.) I feel like I was probably the guilty person here. Possibly having higher-than-average dislike for epochs and also being clueless on ubuntu deadlines. I feel like rushing an epoch bump in because of a deadline is a bad idea, which you are probably well aware of as of now. (And yes, there where probably more cases this should have been used but once uploaded the window of opportunity to eliminate the epochs are gone and we have to wait, pray and hope that upstream renames things again some time in the future.) Also Debhelper commands are overridable by design and their individual arguments are documented in their separate manual pages. This should be leveraged when ever it's the appropriate thing to do (and avoided when it's not). > > More recently, I have worked to reduce the difference between Debian > and Ubuntu packaging for many GNOME packages. It gets very tedious to > need to upload gnome-calculator in Debian and then do a separate > upload in Ubuntu (along with all the required Vcs merging, updating > and tagging) just to add the epoch in Ubuntu. It would be a lot nicer > if I could just sync the Debian package to Ubuntu. > > So is it appropriate to bump an epoch in Debian to match an important > downstream's epoch? I understand this is annoying for you to have to carry forever in ubuntu, so I'm willing to look the other way with one condition: You make sure to discuss policies on the ubuntu side to take extra care to not needlessly introduce epoch bumps which you then later come to debian to discuss because it's causing you pain in ubuntu. If you ever bump epoch in ubuntu without having done the full epoch-dance in debian and waited for it to actually be uploaded to the debian archive before you upload the epoch bump in ubuntu, then you agree to handle it for all eternity on the ubuntu side when needed. As an alternative suggestion, why isn't it possible to simply get rid of the annoying part by specifying a vendor-condition in debian/rules and apply "the hack" to all binary packages when building on ubuntu (and on transitional packages only when building on debian)? Carrying this ubuntu-specific lines in debian/rules even in debian would likely be something that people who only care for debian could more easily accept. eg. ifeq ($(DEB_VENDOR),Ubuntu) endif > > [1] Current example of the hack: > https://salsa.debian.org/fonts-team/fonts-ubuntu/blob/debian/unstable/debian/rules > > Thanks, > Jeremy Bicha > Regards, Andreas Henriksson (who hasn't mastered the art of writing short mails yet either)
Re: HELP WANTED: security review / pam experts for su transition
Hello again, My previous mail didn't result in any feedback, so let me try again with some more detailed questions that might be easier to discuss related to the PAM configuration of su (and su-l). As people are likely aware, the su takeover has now happened and login (src:shadow) no longer ships su in favour of it being shipped in util-linux (src:util-linux) instead. The /etc/pam.d/su configuration was carried over directly from the old src:shadow (login) su, and might be less then ideal for the util-linux su implementation. The new /etc/pam.d/su-l configuration didn't exist before, but mostly just includes the su pam config for now. Mainly mentioning su-l because we have the option to differentiate between what pam config we want for 'su -' vs 'su'. 1/ One new issue that has bitten some people is that shadow su used to, even when you ask for a new clean environment, still copy over DISPLAY and XAUTHORITY. Apparently some people relied on that even though X doesn't really give you any real privileges separation. On fedora the su pam configuration includes pam_xauth which I assume should solve the same problem. Should we add pam_xauth to /etc/pam.d/su as well? (For now it's just mentioned in util-linux.NEWS and left to the user to edit the pam configuration as they find suitable, but if we can't even figure out the right choice I doubt users will.) 2/ There are some longstanding issues with the pam configuration which existed before the switch, but seems reasonable to adress still. For example #711104 asks for 'su -' to reset umask. Should we include pam_umask? Maybe even in /etc/pam.d/su so both 'su' and 'su -' gets umask reset? cf. how the carried over /etc/pam.d/su already contains pam_limits. 3/ The fedora pam configuration seems to contain several more differences. Anyone interested in investigating and comparing them? Possibly our ancient su pam config should get a complete overhaul, rather than just poking at details one by one. Regards, Andreas Henriksson
Re: Browserified copy and DFSG
On Tue, Aug 07, 2018 at 12:14:05AM +0200, Bastien ROUCARIES wrote: > Hi, [...] > I can output a list of javascript module (or file installed in the > tree) but I lack the > debhelper skill needed to output automatically built-using. > > Can somebody help me ? You might find it useful to look at what gucharmap does related to unicode-data, see: https://sources.debian.org/src/gucharmap/1:11.0.1-1/debian/rules/#L26 https://sources.debian.org/src/gucharmap/1:11.0.1-1/debian/control.in/#L62 HTH Regards, Andreas Henriksson
HELP WANTED: security review / pam experts for su transition
Hello, as previously discussed it seems all stakeholders are pretty much in agreement that it would be better for debian to use the implementation of login tools from src:util-linux instead of from src:shadow. Investigations about implementation differences has been done and remaining work is basically to implement the switch. (Details in #833256) As a preparation step for larger login package switch (which I'm not comitting to at the moment!), I'd like to start with switching only 'su' and moving it from 'login' (binary package) to 'util-linux' (binary package). This should also pave the way for potentially making login non-essential in the future. WIP on util-linux side: https://salsa.debian.org/debian/util-linux/commit/a2449f1a1bf0f77a80aa1f71871fa32b4d14d6f5 I don't feel entirely comfortable doing this security-sensitive work entirely on my own without peer review. I'm thus looking for people willing to review the security critical aspects, preferably PAM experts. Are you willing to help? Please contact me. Regards, Andreas Henriksson
Re: Bug#899058: ITP: domoticz -- Home automation system
Hello Federico Ceratto, On Fri, May 18, 2018 at 07:33:21PM +0100, Federico Ceratto wrote: > Package: wnpp > Severity: wishlist > Owner: Federico Ceratto > > * Package name: domoticz [...] > The package will be maintained at https://salsa.debian.org/debian/domoticz [...] Thanks for packaging domoticz. I've not used it myself but I hear good things about it and think it'll be a great addition to the debian archive. I had a quick look at the packaging bits in your git repo and have some questions and comments. Maybe something can be useful for you, but maybe not. Anyway... I see you're using alot of the security features in your service file, great! I wish more packages where better at using these features. I can't help but wonder though if it's not possible for you to use DynamicUser=yes ? You seem to already use some of the strict limitations implied by DynamicUser=yes anyway. Using it would allow you to get away without creating a static system user for your service, but your service also won't be able to create any persistent files (which I don't know if you might need). You also added a 'default' file. Personally I think the only good usage for a default file is with init scripts. Unless I missed something you seem to not have any init script so I don't think that argument applies here. Thus I'd suggest you switch from EnvironmentFile to plainly setting the variables via Environment=. That way users can easily ports via 'systemctl edit ...' the same way they would override any other thing in the service. (Fwiw, I think splitting out the port numbers to an environment variable like you did can be useful even when not using a default file. If the ExecStart line is long and has many different arguments overriding the entire line completely for just a simple port change might be suboptimal for upgrades where you might add, remove or change another unrelated command line argument. Thus being able to just override the environment variable is safer.) Not really willing to take on any (co-)maintainership, but if there's a limited task you think I can help out with don't be shy to ask. (Ofcourse since I'm not a user myself, yet, I'll need help from someone who is to test whatever I implement though.) Regards, Andreas Henriksson PS. You already seem to be very well versed with systemd services but in case you're not already familiar with DynamicUser=yes information about it can be found, except from the systemd documentation ofcourse, at http://0pointer.net/blog/dynamic-users-with-systemd.html
Re: ITP: ell -- Embedded Linux library
Hello Nobuhiro Iwamatsu, On Fri, Apr 13, 2018 at 12:57:46PM +0900, Nobuhiro Iwamatsu wrote: [...] > * Package name: ell > Version : 0.4 [...] Out of interest (and since I'm not aware of any other users of ell than iwd), may I ask what your motivation is for packaging ell? FYI I've recently uploaded iwd which is currently in NEW (see also ITP #894537) which currently comes with a bundled version of ell. Any chance you're interested in iwd and would like to help out looking into building it against the system ell once your package is available in the archive? Regards, Andreas Henriksson
Bug#894537: ITP: iwd -- wireless daemon for Linux
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: iwd Version : 0.1 Upstream Author : See AUTHORS * URL : https://git.kernel.org/pub/scm/network/wireless/iwd.git/ * License : LGPL-2.1+ Programming Lang: C Description : wireless daemon for Linux I've prepared initial debian packaging of iwd which is available at: https://salsa.debian.org/debian/iwd Please see the debian/control file for full/official description. Help welcome with improving it! The unofficial one is that iwd is a minimalistic replacement for wpa_supplicant (suitable for embedded). It builds on top of modern linux interfaces (nl80211, cfg80211) and provides a D-Bus API. There are also iwctl and iwmon command line utilities included. This should likely still be considered experimental stage software. Latest upstream development release of NetworkManager provides experimental and disabled-by-default support for iwd. You should also be able to find (upstream) support for it in connman. (co-)maintainers welcome. Regards, Andreas Henriksson
sysvinit-utils essentialness (was: Re: Bug#886238: Please introduce official nosystemd build profile)
Hello all, Given I've poked a bit at what Simon mentions below in the past and don't really have any intention to follow this (and any other remaining item mentioned at [0]) through (and not aware of anyone else picking it up either), I thought I'd take this opportunity to share a bit about my view on it in the hope that it can help someone pick it up. On Sun, Jan 07, 2018 at 11:54:49AM +, Simon McVittie wrote: [...] > sysvinit-utils is still Essential: yes, because it contains binaries that > were historically part of the Essential set; *that* keeps src:sysvinit > in testing. There are plans to make sysvinit-utils non-Essential by > moving pidof to a new Essential package built from src:procps (lots > of packages blindly assume that pidof exists, so adding dependencies > doesn't seem feasible) and adding dependencies for the few uses of the > other sysvinit-utils binaries, which have been OK'd in principle by the > maintainer of src:sysvinit, but haven't happened yet. [...] First, what Simon says is in my view an accurate description. Using the pidof implementation provided by procps (upstream) would mean we atleast use the same implementation as other distros, but wouldn't gain us much else and could even give us new problems. By building an essential procps-pidof package would relieve src:sysvinit from bootstrapping, but instead introduce src:procps. I assume bootstrappers have sysvinit well under control already, but no idea if procps would cause issues for them (possibly it may need to introduce some build profiles atleast). In the best of worlds we would make pidof non-essential. So who are the users? Well unfortunately it's not very easy to codesearch[1] for pidof users, because there are lots of "false positives" (and I'm not as patient and thorough as Helmut has been while investigating e2fsprogs), but from glancing over the results the main users of pidof seems to be init scripts. One potential solution here could be to replace the pidof usage with the LSB function pidofproc[2] (but note how the optional last "unspecified method" in practise seems to be implemented by calling pidof[3] when available and I'm not what the impact would be if the first condition that today always is true starts becoming false most of the time instead). While looking at a selection of these init scripts they stand out as very old style. Likely updating them to be somewhat modern (by sysvinit standards) would likely mean totally rewriting them as LSB compatible init scripts. I personally doubt we'll see a major widespread effort within the Debian community to overhaul init scripts in our archive at this point. (Even the Debian LSB maintainer says LSB is basically dead at this point, but as a challenge to all potential sysvinit supporters out there please prove me wrong by makin Debians init scritps LSB compatible!) If anyone out there has ideas on how we could practically (iow, with a somewhat sane amount of work) accomplish this in a different way I'd be interested in hearing about it. The most practical thing to do at this point seems to be to just wait until sysvinit is eventually removed from Debian, add a lintian check that suggests people to also drop any init scripts they're shipping in their packages (cf. the upstart removal which happened surprisingly quickly in my view but may not be comparable), and then investigate after a while again where we have pidof users and if the package providing pidof can be demoted to non-Essential. Given that we're still having these threads like the one leading up to this message makes me think this in not happening any time soon though If anyone out there is interested in working on this (or any other item on [0], or anything similar/related to it) please contact me! HTH Regards, Andreas Henriksson PS. Don't assume I'm subscribed to this (or any other) list! [0]: https://wiki.debian.org/BusterPriorityRequalification [1]: https://codesearch.debian.net/search?q=pidof&perpkg=1 [2]: http://refspecs.linuxbase.org/LSB_3.0.0/LSB-PDA/LSB-PDA/iniscrptfunc.html [3]: https://sources.debian.org/src/lsb/9.20170808/init-functions/#L108
Re: Bug#601455: Steps towards a patch to document disabling a daemon upon installation
Hi, On Mon, Dec 25, 2017 at 06:27:21PM -0800, Russ Allbery wrote: > Ian Jackson writes: > > Sean Whitton writes: > > >> 2. Do we need to include any text saying *why* the /etc/default practice > >>is a bad idea? I couldn't come up with a succinct way to state it. > >>In general, I think we can err on the side of not including the text, > >>since we have policy bugs that document the reasons. > > > How about this text: > > > Setting a value in /etc/default/PACKAGE is nowadays troublesome > > because supporting that pattern is very hard due to inflexibility in > > systemd, which is usually the default init system. I don't find anything about the above text to be true. > > > This also makes it clear that this pattern is perfectly fine if for > > any reason the package does not support systemd. > > I don't really agree with this -- I've disliked this approach (and there > were debian-devel threads against it) from long before systemd was > written. The explanation I'd give is that: While I have several other things I find bad about the /etc/default/foo anti-pattern I think the below text is short and clear that it should serve well as one warning against it, thus... > > Setting a flag in /etc/default/PACKAGE hides from the init system > whether or not the daemon should actually be started, which leads to > inconsistent and confusing behavior: ``service start`` may > return success but not start the service, services with a dependency > on this service will be started even though the service isn't running, > and init system status commands may incorrectly claim that the service > was started. Seconded. Regards, Andreas Henriksson
Re: Anyone using stretch/buster/sid on ARMv4t ?
Hello, On Tue, Nov 07, 2017 at 11:10:27PM +0200, Adrian Bunk wrote: [...] > This whole "so many packages are broken on armel" narrative > is actually mostly FUD, and you are suggesting mitigations > for a nonexisting problem. > > The only major package where armel is the only release architecture > where it can no longer be built is Node.js, and not having the Node.js > ecosysyem on armel has already been sorted out for stretch. > > Every time the topic of armel-specific major problems comes up people > are either not nameing any specific problems, or they mention problems > that were fixed long ago. [...] Please fix #848190 kthxbye
Re: e2fsprogs as Essential: yes?
Hello Felipe, Helmut, On Mon, Oct 02, 2017 at 01:20:55PM +, Felipe Sateler wrote: > Hi, > > On Sun, 01 Oct 2017 00:45:39 +0200, Helmut Grohne wrote: [...] > Thanks for resuming this work. +1 > > To get us going, I have come up with a plan: [...] > > 2) File a bug against lintian to stop complaining about e2fsprogs > >dependencies. > > +1 For an example of a package (where I recently added e2fsprogs dependency) that currently triggers this lintian warning, see udisks2. https://lintian.debian.org/maintainer/pkg-utopia-maintain...@lists.alioth.debian.org.html#udisks2 > > > 3) MBF those packages that need an e2fsprogs dependency. > > 4) Drop Essential: yes from e2fsprogs. > > As Adam mentioned, we will need to wait one release to drop the > Essential: yes bit :( . Alternatively, e2fsck would have to gain Breaks: > against all unfixed rdeps. For such a core package I think this might be > problematic for upgrades, but I haven't tested. I disagree. I don't see any practical problem with dropping it since the Priority field will still have it as part of any (normal) installation. Potentially something with a Conflicts/Breaks could motivate apt into attempting uninstalling it during upgrades, but I don't see anyone having reported such an issue so no need to assume the worst yet. If people really think the theoretical is so important a stop-gap solution could be to use (XB-)Important: yes. Maybe it should even be used permanently. See the (new) fdisk package (src:util-linux) as an example. > > > > So I thought, "how hard can it be?" [...] Famous last words. ;) Thanks again for enduring through to the final end. Regards, Andreas Henriksson PS. I'd personally see it natural for e2fsprogs to be Priority: important and (XB-)Important: yes. ie. Part of a normal (but not minbase) install, plus safety guarded against deinstallation.
Re: e2fsprogs as Essential: yes?
On Mon, Oct 02, 2017 at 10:49:56AM +0200, Helmut Grohne wrote: > On Sun, Oct 01, 2017 at 10:45:20PM +0200, Simon Richter wrote: > > > lsattr, chattr > > > > These I'd expect to be present in a sane system, including inside > > containers. > > I argue that a minbase debootstrap is not a sane system. [...] I'm going to be more explicit here, but basically saying the same as Helmut: "sane system" == Priority: important (or higher) Anything with Priority >= important will be part of any (bare) default installation, as performed by debian-installer. (Also by a normal debootstrap, without custom arguments explicitly requesting minbase.) "Minimal system" (== Priority: required) != "sane system" Please note how Essential: yes is not part of any of the above definitions! In a system like Debian, we want dependency tracking. A package with Essential: yes prevents that. (It's explicitly forbidden in policy.) Thus packages should not use Essential: yes unless they have a very good reason for it (and sometimes that reason is that because of historical Essential: yes usage it's VERY hard to get rid of it). Regards, Andreas Henriksson
Re: Steps towards a patch to document disabling a daemon upon installation
Hello Sean Whitton, Thanks for your work on this. Hopefully you'll find something in my comments inlined below of any use... On Sat, Sep 09, 2017 at 01:40:18PM -0700, Sean Whitton wrote: > Hello, > > This is what I have so far; it is certainly inadequate. CCing -devel > for help answering my technical questions about this patch. > > > @@ -537,6 +537,21 @@ and in your ``postrm`` > > update-rc.d package remove > > fi > > > > +The default behaviour is to enable autostarting your package's daemon. > > +If the daemon should not be autostarted unless the local administrator > > +has explicitly requested this, use instead add to your ``postinst`` > > +script > > + > > +:: > > + > > +update-rc.d package defaults > > +update-rc.d package disable I can't help myself but repeat that I'd prefer seeing more passive wording eg. instead of "instead add to your postinst" use something like "the postinst should contain" + a footnote about this normally being added by dh_... Manually written maintainer scripts should be avoided and I've seen people being "fooled" by taking policy literally before. (Maybe this deserves a section of its own?) > > + > > +An older practice, which should not be used, was to include a line > > +like ``DISABLED=yes`` in the package's ``/etc/default`` file. The > > +package's init script would not start the service until the local > > +system administrator changed this to ``DISABLED=no``, or similar. > > + > > Note that if your package changes runlevels or priority, you may have to > > remove and recreate the links, since otherwise the old links may > > persist. Refer to the documentation of ``update-rc.d``. > > 1. Is the 'should not' for the /etc/default practice too strong? Not in my opinion, no. >I don't know an efficient way to find out how many packages this >would make buggy. But given that we have very strong reasons >against the old practice, we might want to use a 'should not' >regardless. Any maintainer being hit by policy extremists have two options: 1. Take the opportunity to fix the package to follow best pracises. 2. Postpone by saying "should not" is not "must not" (and lower severity), plus "patches welcome" ofcourse. I think that's good enough. > > 2. Do we need to include any text saying *why* the /etc/default practice >is a bad idea? I couldn't come up with a succinct way to state it. >In general, I think we can err on the side of not including the text, >since we have policy bugs that document the reasons. I don't think elaborating on all the ways something can be done incorrectly is nessessary. Should not be too hard for anyone interested in the reason to find out atleast one reason either by thinking it through by themselves or by googling for past discussions. If anything I'd rather see helpful suggestions (in footnotes?) on how a proper cleanup should be done. (Convert admin changes on upgrades, use debian/*.maintscript to rm_conffile) > > 3. The maintscript snippet I have added is not right because it will >disable the daemon every time the package is updated. Unfortunately, >the postinst doesn't know whether this is a new installation, or an >upgrade. > >An alternative is to require the package maintainer to set the >correct LSB headers and systemd unit file configuration values such >that the daemon is not autostarted (in the former case, setting the >daemon not to be started at any runlevel). But I think this would >prevent the local system administrator from enabling the service with >a simple `update-rc.d package enable`, which is the whole point of >all this. > >I looked at dh_installinit(8) and update-rc.d(8) and I couldn't get >them to generate a postinst that does what I want. It seems you're >expected to use all three of these: > >dh_systemd_enable --no-enable >dh_systemd_start --no-start >dh_installinit --no-start > >but then after a reboot, a sysvinit system will start the daemon, >AFAICT. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709384 Regards, Andreas Henriksson
Re: apt-get dist-upgrade uninstalled most of KDE
On Wed, Aug 16, 2017 at 12:56:07PM -0700, nob...@gmail.com wrote: > Hello, > > I just upgraded my system (Debian sid with main, contrib, non-free) to > the most recent unstable version, running "apt-get update" and > "apt-get dist-upgrade". [...] >From what I've been told you should basically only use 'dist-upgrade' when you upgrade between different releases, eg. wheezy -> jessie, jessie -> stretch, stretch -> testing/unstable. If you upgrade the same release (eg. sid -> sid) you should normally only use 'apt upgrade'. By using 'apt dist-upgrade' you're telling apt that it's ok to remove things. If you do use dist-upgrade in sid while transitions is still ongoing/unfinished you will end up with lots of things removed. At the same time you might need to use dist-upgrade to upgrade things in sid after a transition has been made. You're basically expected to be able to understand what apt is asking you and answer correctly. Also when running sid you should be able to unbreak your own system. Regards, Andreas Henriksson
Re: libgda with ui support.
Hello Pavlo Solntsev, On Mon, Aug 14, 2017 at 03:10:59PM -0500, Pavlo Solntsev wrote: > Hello, > I am not sure where I should direct my question. There is a bug #862251 for > libgda-5.0 package. UI modules are not compiled and not available. > Basically, I have to manually compile those. The bug is sitting for 90 days > without any comment. I understand, that people may be busy with other > duties, but can someone clarify why we don't have ui module available as a > separate package or part of *-dev. Is there any reason for that? You simply forgot to submit your patch to implement the requested changes. Please also note: Marked for autoremoval on 17 September: 870741 https://tracker.debian.org/pkg/libgda5 Feel free to stop by #debian-gnome on OFTC (irc.debian.org) to get your patches reviewed and find someone to sponsor your upload. Regards, Andreas Henriksson
Re: fdisk becoming non-essential, dependencies needed.
On Thu, Aug 10, 2017 at 05:11:53PM +0200, Andreas Henriksson wrote: > Hello, > > A new version 2.29.2-3 of src:util-linux was recently uploaded to > experimental[1]. The plan is to ship those changes in Buster. [...] Following up on my previous mail to debian-devel-announce An initial set of bug reports has now been filed while looking for sfdisk users using codesearch.debian.net as promised. See: https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=util-li...@packages.debian.org;tag=fdisk-dependency;dist=unstable https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=util-li...@packages.debian.org;tag=fdisk-build-dependency;dist=unstable https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=util-li...@packages.debian.org;tag=fdisk-recommends-suggests;dist=unstable Additional searches needed for fdisk and cfdisk, so further bug reports will likely be filed later (under same usertags). Help welcome in identifying users and filing bug reports. Please CC me so I'm aware of your helping efforts. Regards, Andreas Henriksson
Re: New package split of util-linux
Hello Adam Borowski, thanks for your feedback. On Wed, Jul 26, 2017 at 11:03:08AM +0200, Adam Borowski wrote: > But why should mount be Essential? It's useless in containers and chroots. I'm very open to making things non-essential if possible, not limited to only mount. (Why should bsdutils be essential for example? But how do we make it non-essential? Even if policy didn't forbid depending on essential packages, how would we even identify users that should add a dependency? See also #474540 for another example of this practical problem.) I aware of but have no practical experience with the Important: yes field. I can only guess and hope that if we use that for mount there won't be any weird upgrade problems. (Help welcome to verify it!) One thing to consider first though might be if the findmnt utility should be moved over to util-linux package (I likely put this tool in the wrong place to begin with since it didn't matter much back then). WDYT? [...] > What about making the split at different levels of essentialness? With the > new Important: yes (not be confused with priority: important), this makes > three levels, and thus three packages: > * stuff that's needed on every Debian system > * stuff needed on every bare-metal box / "real" VM > * things you can go without I would be very interested to see your resulting of this splitup! Also please consider it in the light of the previous criterias I posted. (Because suggesting something better which have doable upgrade path from the current state is problematic from a practical perspective. In theory I'm not really sure there's anything matching the "stuff that's needed on every Debian system" criteria in src:util-linux if considering less usual usecases.) Regards, Andreas Henriksson
New package split of util-linux
Hello! I'm looking for help with ideas about a new package split for the util-linux suite. Currently the main binary packages are: util-linux mount bsdutils (Then there are a bunch of other less important binary packages also built.) All of the three above packages have the Essential: yes control field set. This basically means when ever upstream writes a new tool and we decide to ship it, it instantly becomes part of the essential set. Additionally when one of these new or existing tools grows a new dependency that package (library?) instantly becomes pseudo-essential. The current package split being problematic has already resulted in setpriv currently being a separate package to avoid making it essential and it's new dependency pseudo-essential. I'd like to merge this tool into another package with a set of tools and make the setpriv a transitional package. Disclaimer: I'm not interested in (further) "micro-packaging". I also don't see any real reason for the mount package to be separate from the util-linux package. In short, I'm considering a new package split to be needed. If people have ideas or suggestions about this package split I'm interested to hear them. Things I'd like your to consider when suggesting a new package split: - how can we easily ship additional new tools from upstream in it? - how does it deal with new/existing dependencies to avoid making everything pseudo-essential? - how can we take over things currently shipped by other source pkgs? eg. eject[1], su/login[2], etc. - how can we make sure the essential set is as small as possible? - how can we make sure the dependencies being made pseudo-essential is kept as small as possible? - how do we transition to it from the current package split? Another possibly related issue I'd like to get feedback on is that I personally find it useful for these 'low-level utilities' packages like util-linux is to keep 'mechanism' (the tools) and 'policy' (how they are used, eg. init scripts, cron jobs, etc.) separate. The util-linux are currently pretty much mechanism only, with the notable exception of hwclock policy that *only* applies under sysvinit. I have thus considered moving this policy over to the sysvinit package but problems with moving conffiles between packages has made me spend my time elsewhere. There are though a number of different requests to introduce more policy in the util-linux package. Eg. use hwclock policy under systemd when rtc drivers are modules (rather than built in)[3], ship fstrim cron jobs[4], etc. As said I'd like to keep util-linux free from this kind of policy, so suggestions on where to put them instead or potentially how a new package split could deal with this is welcome. In case you've read this far I'll also throw in a general request for help with the util-linux package. All help is welcome and needed. If you're looking for specific issues I'll suggest looking at #869191 which currently blocks updating to a new upstream release. Also please send patches to the relevant util-linux bug report (or directly to upstream is even better if it's an upstream issue). General bug triaging also welcome, because I'm sure there are open bug reports than can likely just be closed after investigating them and their current status. [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737658 [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833256 [3]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855203 [4]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864806 Regards, Andreas Henriksson
Please drop Pre-Depends: multiarch-support
Hello!
I'd like to draw peoples attention to
https://lintian.debian.org/tags/pre-depends-directly-on-multiarch-support.html
In short, please drop "Pre-Depends: multiarch-support" from affected
packages!
(Lintian suggests using ${misc:Pre-Depends} but that expands to empty
since a long time already, so real no point. Your choice though.)
(My reason for bothering with this announcement is that I'm looking
into things that are currently pointlessly part of the /minimal/
debian installation, aka debootstrap --variant=minbase. I'd like to
see multiarch-support gone.)
dd-list:
A. Maitland Bottoms
dime
Andy Spencer
librsl (U)
Anibal Monsalve Salazar
liblockfile (U)
Bernd Zeimetz
liblqr
Bill Allombert
libjpeg6b
libjpeg8
Christophe Monniez
libewf (U)
libpff (U)
Debian Forensics
libewf
libpff
Debian KDE Extras Team
gtk2-engines-oxygen
Debian Multimedia Maintainers
taopm
Debian Science Maintainers
librsl
Debian Xfce Maintainers
garcon
Dmitry E. Oboukhov
lua-cjson (U)
Enrico Tassi
lua-curl
lua-cyrussasl
lua-ldap (U)
lua-lpty
lua-md5
lua-rings
lua-svn
lua-zip
lua-zlib
Fathi Boudra
gtk2-engines-oxygen (U)
Felix Geyer
gtk2-engines-oxygen (U)
Francesco Paolo Lovergine
xaw3d
Kai Wasserbäch
gtk2-engines-oxygen (U)
Koichi Akabe
htsengine
Laszlo Boszormenyi (GCS)
qpid-cpp
Lionel Le Folgoc
garcon (U)
Luca Capello
lua-ldap
Matthew Vernon
pcre3
Michael Stapelberg
xcb-util-cursor
Mickael Profeta
prelude-lml (U)
Miquel van Smoorenburg
liblockfile
Ola Lundqvist
vzctl
Pierre Chifflier
libee
libestr
libewf (U)
libpff (U)
prelude-lml
Shane Wegner
dotconf
Simon Richter
libopenusb
Stefanos Harhalakis
libnet
Steve M. Robbins
dime (U)
Steve McIntyre <93...@debian.org>
nas
SZALAY Attila
eventlog
The Debian Lua Team
lua-cjson
Tiago Bortoletto Vaz
taopm (U)
Vincent Fourmond
scalc
Yves-Alexis Perez
garcon (U)
Regards,
Andreas Henriksson
Re: Running Debian in the Web browser (JS VM)?
Hi, On Thu, Jan 26, 2017 at 04:25:53PM +0100, Olivier Berger wrote: > Hi. > > Is anyone working on a "port" of Debian for running in the browser, > over the JS VM, like what jor1k [0] does ? > > I'm not sure where to check, so any hints welcome. See Current Status on: https://wiki.debian.org/OpenRISC > > I'm not exactly sure our toolchains would allow to perform that easily > enough... Regards, Andreas Henriksson
Re: Can we kill net-tools, please?
Hello, On Mon, Dec 26, 2016 at 09:55:14PM +0100, Geert Stappers wrote: > Thing what Andreas Henriksson is doing > in https://lists.debian.org/debian-devel/2016/12/msg00619.html > providing patches how to get rit of net-tools, > is what will make the killing of net-tools more easy. I personally don't beleive in trying to patch us out of this mess because it's chasing a moving goal. New crap gets uploaded to the archive every day. What I was trying to show was that the existing reverse dependencies of net-tools are either not using it or are trivial to port, the real question is if it makes any sense to spend time porting them? Many things net-tool is used for is either useless or broken code. Getting rid of it would be a service to our users. Several times it's likely useful to get rid of the entire obsolete package (that the package uses net-tools is just one symptom of its outdatedness). A better way than chasing a moving goal is in my opinion to declare intent and then go in for the kill (taking all remaining rdeps with it). Given not even the net-tools maintainer seems to suggest you should not be using net-tools, I think we in this thread has declared that: If you want your package to be part of Buster then make sure it doesn't depend (solely) on net-tools!!! (Atleast we should consider downgrading the priority so it only gets installed when pulled in via dependency or manually installed.) Regards, Andreas Henriksson
Re: Can we kill net-tools, please?
Hello,
On Mon, Dec 26, 2016 at 06:57:26PM +0500, Andrey Rahmatullin wrote:
> For the record:
[...]
There's quite alot of cruft around still. I went through the
depends list and my notes/patches are attached.
(Can also be browsed at https://fatal.se/tmp/rm-net-tools/ for now.)
Help with filing bugs welcome. Some usertag to track them would
be nice.
I did not go through build-depends as you did not split them
between linux-any and !linux-any. I guess most of them falls
into either of these:
- build-depends on kfreebsd-any only
- used by testsuite that's unloved.
- leftover no longer needed.
I think we should consider downgrading the priority of net-tools
in Buster.
Potentially a lintian warning for anything that depends on
net-tools (on linux-any atleast) could be a useful motivator
to highlight that maintainers should move away from it.
On the BSD side it would be nice if something like
https://github.com/luigirizzo/netlink-freebsd
could happen so we can get if of the need to carry
net-tools codepaths to support bsd.
Regards,
Andreas Henriksson
From: Andreas Henriksson
Subject: drop obsolete net-tools dependency
The net-tools dependency was added because of usage in argus-server
config and postinst. That doesn't seem to be the case anymore, thus
the dependency is no longer needed.
diff -uriNp argus-3.0.8.2/debian/control argus-3.0.8.2.new/debian/control
--- argus-3.0.8.2/debian/control 2016-12-26 16:45:52.147637812 +0100
+++ argus-3.0.8.2.new/debian/control 2016-04-23 18:54:29.0 +0200
@@ -8,7 +8,7 @@ Build-Depends: libpcap-dev, libwrap0-dev
Package: argus-server
Architecture: any
Recommends: argus-client
-Depends: ${shlibs:Depends}, ${misc:Depends}, logrotate
+Depends: ${shlibs:Depends}, ${misc:Depends}, logrotate, net-tools
Description: IP network transaction auditing tool
argus is a network transaction auditing tool that allows the user
to easily classify connections using tcpdump(1) compliant expressions.
From: Andreas Henriksson
Subject: get rid of net-tools dependency
The dependency was added because ifconfig was used in init script.
The check_network function is likely mostly useless these days as
all systems will have the loopback interface set up atleast.
Only run the check if net-tools is installed
diff -uri bind9-9.10.3.dfsg.P4/debian/bind9.init bind9-9.10.3.dfsg.P4.new/debian/bind9.init
--- bind9-9.10.3.dfsg.P4/debian/bind9.init 2016-05-04 01:40:36.0 +0200
+++ bind9-9.10.3.dfsg.P4.new/debian/bind9.init 2016-12-26 16:38:27.153860242 +0100
@@ -33,7 +33,7 @@
else
IFCONFIG_OPTS=""
fi
-if [ -z "$(/sbin/ifconfig $IFCONFIG_OPTS)" ]; then
+if [ -x /sbin/ifconfig ] && [ -z "$(/sbin/ifconfig $IFCONFIG_OPTS)" ]; then
#log_action_msg "No networks configured."
return 1
fi
diff -uri bind9-9.10.3.dfsg.P4/debian/control bind9-9.10.3.dfsg.P4.new/debian/control
--- bind9-9.10.3.dfsg.P4/debian/control 2016-05-04 01:40:36.0 +0200
+++ bind9-9.10.3.dfsg.P4.new/debian/control 2016-12-26 16:42:00.028399482 +0100
@@ -36,8 +36,7 @@
lsb-base (>= 3.2-14),
bind9utils (=${binary:Version}),
liblwres141 (=${binary:Version}),
- libbind9-140 (=${binary:Version}),
- net-tools
+ libbind9-140 (=${binary:Version})
Conflicts: bind, apparmor-profiles (<< 2.1+1075-0ubuntu4)
Replaces: bind, dnsutils (<< 1:9.1.0-3),
apparmor-profiles (<< 2.1+1075-0ubuntu4),
bitlbee-common.config uses netstat.
Dependency is thus valid. Could be ported to 'ss' from iproute2.
chkrootkit (still) uses netstat from net-tools.
The net-tools dependency is valid.
(See also #224029 for background)
An alternative might be to port chkrootkit to use 'ss'
from iproute2 instead of or as an alternative for
netstat.
The net-tools dependency looks valid.
Uses netstat, ifconfig, etc. mostly in test-suite
(so should be a build-dependency instead?) but possibly
also elsewhere.
The dhcp-probe.postinst is (badly) screen-scraping ifconfig
(by for example grepping for interface rather than passing
it as argument to ifconfig).
Very possibly broken with the new format.
Some command suggestions for anyone interested in porting
it to iproute2:
interfaces="$(ip -o link show | cut -d: -f2)"
for i in $interfaces ; do
ether="$(ip link show dev $i | awk '/link.ether/{print $2}')"
primary_ip4="$(ip -4 addr show dev $i primary | awk '/inet /{print $2}')"
done
etc...
Regards,
Andreas Henriksson
No sign of any net-tools utilities used,
likely an outdated dependency.
No information on why it was added in the first place.
= ifconfig
./src/dtc-panel_autodeploy.sh:IP_ADDR=`ifconfig ${DEFAULT_IF} | grep 'inet
addr' | sed 's/.\+inet addr:\([0-9.]\+\).\+/\1/'`
= route
./debian/dtc-xen.config:GUESSED_GW=`LC_ALL=C route -n | tail -n 1 | awk
'{print $2}'`
./debian
Re: Auto-detecting -dev package dependences from pkg-config
Hello Josh Triplett, Manually handling the dependencies of -dev packages often leads to mistakes. Automating this similar to how you describe has multiple times surfaced where I'm involved (and I guess also in other places). Unfortunately noone has volunteered to actually implement it. Thanks for your interest in doing so! Please announce your progress so we can test if your work is generic enough for more people to use and possibly give you some other feedback. Please try to make everything as automated as possible (and able to override when needed for bonus points, but I guess that could possibly also be handled separately outside the substvar). Regards, Andreas Henriksson
Re: auto-removal and alternative dependencies
On Thu, Dec 08, 2016 at 01:41:38PM +0100, Daniel Pocock wrote: > > > On 08/12/16 13:35, Andrey Rahmatullin wrote: > > On Thu, Dec 08, 2016 at 01:02:20PM +0100, Daniel Pocock wrote: [...] > > I don't think that clearly addresses the case of alternative dependencies. > > My packages do not "require" nagios3, although they will work with it > if the user doesn't have Icinga. > > Maybe that clause could be extended to state that packages (may|may > not) include alternative dependencies that are not in main, as long as > at least one of the alternatives is in main. Not sure what Andrey is supposed to be quoting here, but see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681419#275 (Conclusion/ruling at the bottom of that post.) IOW follow Emilios previous advice and you should be fine both practically and policy wise. Regards, Andreas Henriksson
Re: Bug#824358: ITP: freerdp2 -- RDP client/server for Windows Terminal Services
Hello Mike Gabriel. Thanks for looking at packaging a newer freerdp snapshot! I have some questions and doubts below... On Sun, May 15, 2016 at 12:53:07AM +0200, Mike Gabriel wrote: [...] > * Package name: freerdp2 > Version : 2.x (Git snapshot) [...] > The new major upstream version (well, upstream is not tagging versions, > but we have one upstream dev on the packaging team who recommends Git > snapshots) provides new ABI/API. This new source will supercede the > currently available Debian source package "freerdp". With new API/ABI a transition is needed (and hopefully upstream properly handles SONAME despite not doing releases), but renaming the source package is not normally how you do a transition. > . > From now on, upstream will support parallel installations of multiple > major upstream releases. This bit is quite confusing as you just said upstream doesn't do releases. > So shipping both FreeRDP versions in Debian unstable for a while is > possible. Given the lack of followup on existing bug reports do you really think you have the resources to support multiple versions?! Please explain a bit more about how you intend to support multiple versions? For example how do you intend to handle the naming of pkg-config files, rename or make the -dev packages conflict? > However, only freerdp2 will be made available in Debian 9. Apparently not and you seem to underestimate the amount of work needed to get something removed from the archive! Are you sure you'll manage to get down to only one version again before the stretch release? How? As mentioned renaming the source package is not how you normally do a transtion (only when you want to support multiple versions which you apparently don't want). Please consider handling this like a normal transition. > . > Packages depending on FreeRDP shared libraries should start migrating > their packages to the new ABI/API for FreeRDP 2.x. Again, please share some information on how you intend to package to make it possible to prepare. Likely you're creating extra work here when not following the normal transition workflow. > . > A transition bug will be file for monitoring this change-over, > once the freerdp2 src:package has landed in unstable. An automatic tracker would be available on https://release.debian.org/transitions/ if you followed the normal transition workflow which would be even better. Looking forward to hearing more details about your plans to be able to prepare for the transition. Regards, Andreas Henriksson
RFA: storaged -- Disk Manager
Package: wnpp Severity: normal Hello! This is a borderline RFA/RFH. I've already packaged storaged, which is a fork of udisks2 but more targeted at supporting advanced "enterpricy" storage solutions. It's currently sitting in experimental, since I don't have time to properly maintain it myself and thus shouldn't upload it targeted at testing/stretch. Many backends are currently disabled since their dependencies are currently not available in Debian. I've also not properly tested that it's functional, but TTBOMK it is. Further information can be found at: https://tracker.debian.org/pkg/storaged Like the packaging vcs at: https://anonscm.debian.org/cgit/collab-maint/pkg-storaged.git There's also interest from upstream to see Debian support and their bug tracker has an issue for this, see: https://github.com/storaged-project/storaged/issues/41#issuecomment-205769607 Upstream has packaged the dependencies which are not available in Debian in separate Ubuntu PPAs and updated the storaged package in an Ubuntu PPA to enable the new backends, which should serve as a very good base for someone willing to maintain these in Debian! If you'd like to see storaged (which is an optional but quite central dependency of cockpit-project.org) in a future stable Debian release, then this is your chance to help out! Get in touch if you'd like to be the primary maintainer of storaged in Debian. I'm willing to assist as a co-maintainer and can also sponsor you if you're not already a Debian Developer. Regards, Andreas Henriksson
Bug#820107: RFP: cockpit -- makes it easy to administer your server via a web browser
Package: wnpp Severity: wishlist * Package name: cockpit Version : 0.99 Upstream Author : Stef Walter , et.al. * URL : http://cockpit-project.org/ * License : LGPL-2.1+ Programming Lang: C Description : makes it easy to administer your server via a web browser Hello! Cockpit is a framework for doing Administrator tasks via an interactive web based interface. The implementation sits on top of a websockets bridge over dbus. It communicate with standard system components over dbus to reuse their capabilities instead of reimplementing them. It also leverages dbus activating capabilities to avoid having things running when they're not used. I'm filing this borderline RFP, ITP, RFH, RFA. Packaging work has already been done and are available from: https://anonscm.debian.org/cgit/collab-maint/cockpit.git The initial packaging work was done by Michael Biebl and I've recently updated it. Neither of us have enough time to properly maintain this in Debian, so I'm posting this to hopefully find someone who has. While the current package when built from the above repo should be functional there's some remaining work to be done before it is ready to be uploaded for NEW review. Lintian helpfully detects some licensing issues w.r.t. for example javascript "evil" license as well as usage of bundled libraries. Suggesting solutions for this in cooperation with upstream is likely needed. Upstream is very interested in seeing cockpit included in Debian. Further work needed would also be for a designer to create a "branding" (theme) for cockpit suitable for Debian deployments. Please also see storaged RFA bug: #820099 If you're interested in working on and maintaining cockpit in Debian then please get in touch. I'm personally willing to act as a co-maintainer and I guess so is Michael. Initial focus would be to get the package ready for NEW review and once that milestone have been reached I'm willing to sponsor uploads if you're not already a Debian Developer. Regards, Andreas Henriksson
Re: [DH] Mass bug file for removal of deprecated features incl. compat 4
Hello. On Wed, Feb 24, 2015 at 06:39:25PM +, Niels Thykier wrote: > Hi, > > In continuation of [1], there is the next round of deprecated debhelper > features that I would like to remove from debhelper. > > * dh_desktop - 24 packages remaining > * No compat file - 119 packages remaining >- Due to #811059 and #805405 > * compat 4 - 402 packages remaining [...] > Utopia Maintenance Team >mdns-scan [...] I've team-uploaded a new mdns-scan which I hope should take this package off the list. Regards, Andreas Henriksson
Re: vlan support en* or br*?
Hello. On Thu, Jan 07, 2016 at 02:47:31AM +, Ben Hutchings wrote: [...] > The real problem is that vconfig (or rather the kernel interface it > used) imposed any scheme at all. Requiring a '.' is equally short- > sighted. Let me give an example: IMHO not equally, but yes... too shortsighted. [...] > But instead of letting the names depend on the underlying hardware > configuration, some time ago I started naming them 'ext0' (modem) and > 'wl0' (wireless AP) and it's pretty clear which of this is which. When > I changed the hardware and added VLANs there was very little need to > change configuration outside of /etc/network/interfaces. Seems like we're wandering into discussing best-practises and let me share my view for the potential benefit of mailing list readers... Obviously the below applies only to a "managed server", not to something which is basically unmanaged/autoconfigured/zeroconf system (like a roaming laptop or some embedded device). I fully agree with giving meaningful "functional" names to your interfaces. These should NOT be based on what hardware is used, protocol types, vlan, tunneled, or anything like that but instead on what they're used for, eg. wan, lan, dmz, ... (or if you prefer: ext, int, ...) (IMHO it's good to avoid numbers completely in these names, eg. if you provide separation of your internal network in zones with different "trust level" instead of int0 and int1, use eg. intwired and intwlan or whatever your separation/trust-level is based on.) Using functional names (hopefully/likely) means you've set up a reliable way to get the same interface named and you're not subject to hardware ordering, initialization ordering, someone enabling "predicable interface naming" schemes, etc. It also provides a good abstraction. - your firewall rules will be more functional and easier to read when you set them up as "... -i wan -o lan ..." rather than relying on some hardware name. - if you're ISP fscks their routing or similar partial outtakes you can simply set up a tunnel to somewhere, temporarily take down your "real" wan and name the tunnel wan and everything else on your system should be ready to go This has proven really useful when you provide a somewhat critical service in my experience. - ... many other reasons, zero cost abstractions are really useful. Let me also state that even if you can enable predictable interface naming using systemd, or whatever, these names are still not functional so you've still failed to follow best practises if you rely on them. (Let alone if you think eth* names are reliable you're simply wrong.) Following these best-practises means the discussions about if systemd enables predictable interface naming scheme or not is (for people managing servers) completely uninteresting. You'll simply treat anything which does not have a functional name as if it's an unused spare. You give it a functional name /before/ even considering bringing UP the interface. (I hope it's also obvious that in any zeroconf situation it's useful that an interface gets the same (initially random as far as I'm concerned) for each consecutive boot. But for your managed server usecase, this is completely uninteresting.) Regards, Andreas Henriksson
Re: vlan support en* or br*?
Hello again.
On Wed, Jan 06, 2016 at 07:27:00PM +, Ben Hutchings wrote:
> On Wed, 2016-01-06 at 19:40 +0100, Andreas Henriksson wrote:
> > Hello.
> >
> > Since this isn't the first time the vlan package with its deprecated
> > vconfig command causes discussions I've gone ahead and uploaded
> > a new version of the package to experimental. See vlan 2.0 also
> > available from https://people.debian.org/~ah/vlan-2.0/ for the
> > impatient who doesn't want to wait for archive updates and mirror syncs.
> [...]
>
> Nice, but you still kept vconfig's name restriction. Could you please
> also change the ifupdown scripts to work with any device name so long
> as vlan-id and vlan-raw-device are specified?
Thanks for having a look at this. Please let me elaborate
I personally don't see a point in the vlan package. I've already
suggested it should be removed. The only reason to keep it I can agree
with is that we still don't give users a better (automated) upgrade
path. For new installs I see absolutely no point in using it at all.
Obviously not everyone agrees on this and that's why I wanted to atleast
get rid of the ioctl based vconfig which noone argues is still needed.
The reason I don't think the ifupdown integration provided by vlan
package is needed is because ifupdown itself provides vlan configuration
possibilities these days. From what I can tell from the manual ifupdowns
vlan support should support whatever name you give your underlying
(real) interface ("foo"). It only forces you to use a period (.) in the
name (eg. "foo.123" for vlan id 123, while vconfig had several possible
naming schemes for no apparent reason).
Thus if you don't like the limitations of the vlan packages ifupdown
integration, just use the built-in functionality of ifupdown instead!
For anyone interested in this please see the interfaces(5) man page
and look at the "VLAN AND BRIDGE INTERFACES" chapter.
I'm not a user of either ifupdown nor vlan packages myself. I'm not
going to work on extending the vlan package features. I still maintain
that it would be better to remove it as my personal opinion, but given
that there are apparent people who still find it useful to install it I
think it's useful to atleast get rid of the worst parts of the vlan
package.
And as mentioned in the previous mail, the updated version retains all
limitations of the previous package. If someone finds it useful to
extend it feel free to do so, but I people to please investigate your
options before wasting your time.
Suggestions for what to put in the package description to make it
more obvious for users what to expect are welcome!
(Please make sure to atleast CC me. Mails that do not appear in my inbox
have a high chance of not being read by me.)
Regards,
Andreas Henriksson
(PS. Now if we could only replace net-tools with a similar wrapper
script and finally deprecate the ioctl based tools there as well. ;P)
Re: vlan support en* or br*?
Hello. Since this isn't the first time the vlan package with its deprecated vconfig command causes discussions I've gone ahead and uploaded a new version of the package to experimental. See vlan 2.0 also available from https://people.debian.org/~ah/vlan-2.0/ for the impatient who doesn't want to wait for archive updates and mirror syncs. It would be very welcome if brave souls would be so kind to test if this version of the package works (within the same limitations as the old) and report back. For background info see http://bugs.debian.org/501402 Regards, Andreas Henriksson
Re: support for merged /usr in Debian
Hello all. On Tue, Jan 05, 2016 at 01:23:06AM +0100, Michael Biebl wrote: > Am 05.01.2016 um 01:17 schrieb Adam Borowski: > > On Mon, Jan 04, 2016 at 08:43:02PM +0100, Michael Biebl wrote: > >> Am 04.01.2016 um 19:12 schrieb Eric Valette: > >>>> Remember that / and /usr don't have to reside on the same partition with > >>>> the usrmerge proposal: they only have to be both available > >>>> post-initramfs. The initramfs already takes care to mount /usr (for the > >>>> systemd case as initscripts needs updates for sysvinit as was said > >>>> elsewhere). So no repartitioning should be required on upgrades. > >>> As explained elsewhere in this thread, using initramfs is still not > >>> mandatory in debian > >> > >> an initramfs is not mandatory as long as you don't have /usr on a > >> separate partition. > >> No initramfs + split /usr is not supported and has been broken for a while. > > > > I guess you meant "with systemd". > > Nice try, but no. Those issues are not specific to systemd. > Though systemd might be the only init system where developers are actually nice enough to actually give you the warning, while in sysvinit "with a big fat warning added"[1] has only come as far as being discussed but not yet implemented. Here's how another sysvinit maintainer summarized the situation[1]: "/usr as a separate partition *and* no initramfs to mount it early is [unfortunately] a really bad idea on jessie/sid, [...] (but warning the user of the problem is likely to be a good idea)." (Note: this was when jessie was testing and still not frozen.) Unfortunately I think this is one of the last times the sysvinit maintainers where heard from Ignorance really seems to be bliss. I wonder how long people on debian-devel can go on pretending like everything is fine with sysvinit while bullying others into doing the work to keep sysvinit on life-support via reluctant NMUs. One day you might wake up to find that those NMUs have stopped Regards, Andreas Henriksson [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757083
Re: support for merged /usr in Debian
Hello Marco d'Itri. On Thu, Dec 31, 2015 at 01:51:45AM +0100, Marco d'Itri wrote: > We have a reasonably tested usrmerge package which can be used to [...] > I welcome your comments, but if you have any questions then please read > the FAQ first: > https://wiki.debian.org/UsrMerge > https://anonscm.debian.org/cgit/users/md/usrmerge.git/plain/debian/README.Debian > > If you want to help then please have a look at the open bugs linked on > wiki.d.o about lintian and policy work. Thanks for your work on this! (even though I'd personally would be happy if this went one step further with "TheOneAndOnlyTrueBin" from Arch Linux fame so I'd never have to waste time being involved in another discussion about where the right place to put an executable is. As I learned at debconf, "technical solution to social issues"...) I just found some time to read through the sources of usrmerge and ended up with a couple of comments that I'm not sure is worth implementing but mentioning them anyway in case anyone is interested... First, it would be nice to have a preinst check if the system has any running services that uses ProtectSystem and offer a choice to stop (and restart) them in case having them running is really a problem... (Similar to how glibc upgrades (used to?) offer restarting of services.) While codesearch tells me these seem to be pretty uncommon in the archive right now, AFAIK it's pretty much a recommended setting for services that works with it enabled and with the ever growing number of services in the archive I can only guess that also enabling this setting will become more common An easier way for the users to deal with this might be worth some developer time. Second, as you already noted in your TODO I think it's probably a good idea to turn the initramfs preinst check into a debconf prompt. And to answer your followup question in TODO, no I do not think you should always prompt on /usr on separate fs. Don't bother the user unless needed. This way the messages should properly show up in all package management frontends and can also be translated. Last but not least thanks for so clearly documenting the tradeoffs you have had to make and mark the XXX spot where to look closer. I don't feel like I'm in a position to give any recommendations on which side of the remaining tradeoffs to lean towards. (I'm also very curious that noone from the critical crowd has picked up on your documented issues, but OTOH it seems many didn't even read the FAQ) Regards, Andreas Henriksson
pro-active removals (was: Re: suggestion to add package vlan to default instalation DVD)
Hello all. On Wed, Sep 16, 2015 at 09:10:15PM +0200, Sven Hartge wrote: [...] > Why? The vlan package is not needed since at least Wheezy to configure > VLANs on devices since the program "ip" can do everything the same or > even better. > > Also ifupdown was changed to be able to configure VLANs using "ip" > directly without the need for the "vconfig" from the vlan package. I think this example is a good one to describe why we should be more pro-active with removals from the archive. I filed http://bugs.debian.org/501402 in 2008 when the vlan package had already been deprecated. This was to allow the package maintainer (or anyone else!) to implement a smooth transition to the new tools for anyone still using the vlan package This has obviously not happened (and I don't blame people for loosing interest in something that becomes deprecated but it'd ofcourse be nice if we could provide smooth upgrades for our users). As the years pass by it seems less likely that anyone will step up and do the work to implement a smooth migration. Given this, I think it would be a *service* to our users if we removed this (and many other packages in similar situation) from the archive so that we don't fool users into using (or wasting time even looking at) long-deprecated software. If the package is no longer available that means they'll find out the reason and discover the newer replacement that anyone should really be looking at for new deployments today. Unfortunately getting things removed from the archive is alot harder than adding to the archive. This is something that I think we should fix. Regards, Andreas Henriksson
Re: version format for git snapshot
Hello Thomas Koch! On Mon, Sep 14, 2015 at 07:51:09AM +0200, Thomas Koch wrote: > Hi, > > my upstream tagged 0.4 a year ago and I want to package the current master > commit a5e5f9e that is 24 commits after 0.4. Please assume that this makes > sense... > > How would you format the upstream part of the packages version number? How > about 0.4+24+git+a5e5f9e? > > The git describe output is v0.4-24-ga5e5f9e. > > Is there any established best practice? I see there are already multiple suggestions, so here's yet another color suggestion for the bikeshed... The below mentioned format is understood by /usr/share/gnome-pkg-tools/1/rules/gnome-get-source.mk which will download (or in this case generate) the orig tarball on fakeroot debian/rules get-orig-source for all pkg-gnome packages. (But ofcourse, even though there are alot of packages supporting this format we rarely do git snapshots so you won't find many of them in the archive currently.) # search for a GIT revision in the version of the changelog # accepted formats: foo+git20090430.42ad43 (or ~ instead of +) DEB_UPSTREAM_GIT_REV ?= $(shell echo $(DEB_UPSTREAM_VERSION) | sed -rn 's/^.*[\.~+\d]+git[0-9]+\.([0-9a-f]+)$$/\1/p') In my opinion this formatting is good, simple and reasonably short (compared to similar suggestions). Regards, Andreas Henriksson
Re: ok to ship vaporware in Debian?
Hello! I see this as a question about main vs contrib. Personally I'd put something like (libjs-)mediaelement in contrib as obviously the main intended purpose it to use it together with non-free software. But since it's not up to me Policy says this about contrib: "The contrib archive area contains supplemental packages intended to work with the Debian distribution, but which require software outside of the distribution to either build or function." >From https://www.debian.org/doc/debian-policy/ch-archive.html#s-contrib So I guess the question becomes: can something that by designed does nothing (without non-free software installed) be considered functioning? I guess your (Jonas) opinion is already clear on this by using the vapourware term. Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140909091124.ga4...@fatal.se
RFH: testing util-linux/experimental
Hello! I'd like to ask for help with testing the new util-linux package currently available in experimental. Note: If you're on a non-linux platform, please contact me *before* proceeding for special instructions! The rest of this mail is dedicated to those running Linux. The new package has gone through major changes since the one available in stable/testing/unstable. Hopefully you'll find that installing it will be quite uneventful, but there are some changes that certain people should be aware of before proceeding! First of all, do read the NEWS entries provided in the package! One of the notes there includes mentioning that losetup has completely dropped support for encryption. This also means that the Debian-specific patch to extend this functionality has been dropped[HASHPATCH]. This mean that the mount options "encryption", "nohashpass", "keybits", etc are no longer available for loop mounts. Please make sure that you are not using any of this, as for example having invalid settings in /etc/fstab could potentially lead to an unbootable system (as it seems common that people do not add "nofail" to their fstabs where appropriate). For the record, the recommendation is to use dm-crypt which you hopefully already are doing if you're interested in block layer encryption. If you're a user of storage encryption I urge you to be extra careful and I would also be very happy to get feedback from you on your experience and how we could possibly make your upgrade experience smoother. For anyone that tested this new version it would also be nice if you could send me your feedback! Positive or negative! Please include information what you're testing on (architecture? init system? etc.), if you have any special setup/configuration that could be relevant, if you've dived deeper into some specific features of util-linux, etc... [HASHPATCH]: http://anonscm.debian.org/gitweb/?p=collab-maint/pkg-util-linux.git;a=commitdiff;h=882e4f9d48309b3319c75c629219b6737ed76e22 Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140809193340.ga23...@fatal.se
Re: New project goal: Get rid of Berkeley DB (post jessie) -- iproute2/arpd
Hello! For the record, regarding iproute2 and berkeley db The berkeley db dependency is only used by (the black sheep) arpd in iproute2. If it where removed, building arpd would be disabled (without sheding a tear since I don't know of anyone using it) until someone offered to port it to something that's available which would make me consider possibly enabling arpd again. (Also consider the priority of possible new candidates for filling the vacancy. "Packages must not depend on packages with lower priority values") In other words, do not consider iproute2 a blocker for removal of berkeley db. (It would be interesting to know which practical problems staying with db 5.x forever would pose though...) Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140624220743.ga17...@fatal.se
RFH: filing bugs for packages still depending on iproute transitional package
Hello! It came up that people should move away from the transitional package iproute, and instead use iproute2 I guess it's time to remind everyone again that I intend to drop iproute transitional package post-jessie release. It would thus be very good if there are no reverse dependencies left before that. Read: act now! At the bottom is a list of reverse recommends, depends, suggests and build-dependencies. (Please note that packages doing things like iproute|iproute2, which is ok I guess, will be included here.) If someone is willing to take the time to report bugs against all of these, that would be appreciated. (I suggest usertagging it with user ah-ipro...@debian.org and usertag iproute-transitional.) $ cat <(reverse-depends -b -l iproute) <(reverse-depends -s -l iproute) | sort -u | dd-list --stdin Alexander Wirt keepalived Alkis Georgopoulos epoptes (U) Andreas B. Mundt debian-edu (U) Andreas Tille debian-edu (U) Andrew Lee (李健秋) debian-edu (U) Andrew Shadura ifupdown Anibal Monsalve Salazar cluster-glue (U) heartbeat (U) Apollon Oikonomopoulos ganeti (U) Bastian Blank redhat-cluster (U) Bastian Kleineidam fiaif Carlos Alberto Lopez Perez util-vserver Charles Plessy cloud-init Chrissie Caulfield dnprogs Christian Hammers quagga Daniel Baumann criu live-config (U) Daniel Kahn Gillmor vblade-persist David Paleino wicd Debian Edu Developers debian-edu sitesummary Debian Forensics rkhunter Debian Ganeti Team ganeti Debian HA Maintainers cluster-glue heartbeat redhat-cluster Debian Libvirt Maintainers libguestfs libvirt Debian QA Group oidentd Epoptes Developers epoptes Eric Evans ucarp Florian Schlichting vpnc Florian Weimer quagga (U) Fotis Tsamis epoptes (U) Frederik Schüler cluster-glue (U) heartbeat (U) redhat-cluster (U) Giuseppe Iuculano apf-firewall Gonéri Le bouder nova (U) Guido Günther libguestfs (U) libvirt (U) redhat-cluster (U) Guido Trotter ganeti (U) gustavo panizzo nova (U) Hilko Bengen libguestfs (U) Holger Levsen debian-edu (U) sitesummary (U) Jeffrey M. Ahrenholz core-network (U) Jerome Benoit sanewall Joao Eriberto Mota Filho core-network Jonathan Niehof pam-shield José L. Redrejo Rodríguez debian-edu (U) Juan Angulo Moreno lsat Julien Danjou cloud-init (U) nova (U) Julien Valroff rkhunter (U) Laurent Léonard libvirt (U) Live Systems Maintainers live-config Loic Minier avahi (U) LTSP Debian Maintainers ltsp Luis Uribe ipkungfu Marc Haber ifupdown-scripts-zg2 Mario Izquierdo (mariodebian) tcos Martin Loschwitz cluster-glue (U) heartbeat (U) redhat-cluster (U) Martín Ferrari python-nemu Matthew Grant netscript-2.4 Mehdi Abaakouk nova (U) Michael Biebl avahi (U) Michael Hanke arno-iptables-firewall Michael Prokop fai (U) Miguel Landaeta cloud-init (U) Mike Gabriel debian-edu (U) Mike Miller vpnc-scripts Ola Lundqvist vserver-debiantools vzctl Pascal Hofmann mysql-mmm Patrick Winnertz debian-edu (U) Petter Reinholdtsen debian-edu (U) sitesummary (U) Philipp Matthias Hahn netplug PKG OpenStack nova Reinier Haasjes aiccu Rene Mayrhofer strongswan (U) Richard Jones libguestfs (U) Roberto C. Sanchez shorewall shorewall-core shorewall-lite shorewall6 shorewall6-lite Rolf Leggewie wondershaper (U) Romain Francoise strongswan (U) Sebastian Dröge avahi (U) Sebastian Lohff servefile Simon Horman cluster-glue (U) heartbeat (U) Sjoerd Simons avahi (U) Steffen Joeris debian-edu (U) strongSwan Maintainers strongswan Thomas Goirand cloud-init (U) miniupnpd nova (U) Thomas Lange fai Tiago Bortoletto Vaz apticron Tomasz Buchert miredo Tássia Camões Araújo apticron (U) Utopia Maintenance Team avahi Vagrant Cascadian debian-edu (U) epoptes (U) ltsp (U) Vince Mulhollon wondershaper Yves-Alexis Perez strongswan (U) E: Unknown package: percona-xtradb-cluster-server-5.5 E: Unknown package: openswan E: Unknown package: ganeti-2.11 E: Unknown package: dsc-statistics-collector -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140618142923.ga26...@fatal.se
RFH: test your package(s) with new upower
Hello! In preparation for the upcoming upower transition maintainers (and other volunteers) will need to verify their packages still works. Why am I stating the obvious? The new upower version has been sitting in experimental for almost 4 months now for people to test. (On top of this I personally expect people to keep track on what's going on in their packages upstream and how upstream changes in packages they depend on are going to affect them, but that's just me I guess.) So far *noone* has raised a single word about how the updated version of upower will be a problem for them. How you can find out if you're affected? Thanks to the awesome codesearch service, you can simply visit the following url to find upower dbus api users: http://codesearch.debian.net/search?q=%28%3Fi%29org%5C.freedesktop%5C.upower Why don't I trust maintainers there will be no problems for them? The new UPower version has no replacement for some functionality provided in the old version. This functionality was a duplicate of things found in other places, for example consolekit, logind and others... If everyone tries several mechanism, instead of simply relying on upower, then we don't have a problem. The work done so far on trying to verify if maintainers are keeping a look out towards the future has proven that this is not something we can rely on. A simple rebuild test showed that several packages which used the upower C library client API didn't even build. Bugs has been filed for that and those are mostly done now, so what remains is to review the DBus API, which can't be done as easily as simply rebuilding. You actually have to test the package to see if it still works as well. (Or manually verify the dbus api calls used in the code is still available in the same shape and form.) What am I wishing for? I'm hoping this call for action will enlighten some people and hopefully make everyone test their personal favourite packages and verify they still works with the new upower. If they don't please file a bug and pretty please mark your bug report as a blocker for #751953 to keep track of any issues found. (Now lets see how quickly this turns in to a gigant trollfest like just about any other thread on debian-devel and make me regret I sent this mail.) Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140618093435.ga25...@fatal.se
iproute transitional package going away...
Hello! I intend to drop the iproute transitional packages in Jessie+1. This message is here to give all 68 packages depending/recommending/suggesting the old iproute package time to simply update their dependencies to use the new iproute2 package name. The fix is simple: sed -ie 's/iproute/iproute2/' debian/control I'm including this dd-list for your convenience: Alexander Wirt keepalived Alkis Georgopoulos epoptes (U) Andreas B. Mundt debian-edu (U) Andreas Tille debian-edu (U) Andrew Lee (李健秋) debian-edu (U) Andrew Pollock isc-dhcp (U) snort (U) Anibal Monsalve Salazar heartbeat (U) Apollon Oikonomopoulos ganeti (U) Ard van Breemen vlan Autopkgtest team autopkgtest Bastian Blank redhat-cluster (U) Bastian Kleineidam fiaif Chrissie Caulfield dnprogs Christian Hammers quagga Craig Small gogoc Daniel Baumann live-config (U) Daniel Baumann live-config (U) Daniel Kahn Gillmor vblade-persist David Paleino wicd Debian dsc Maintainer Team dsc-statistics Debian Edu Developers debian-edu sitesummary Debian Forensics rkhunter Debian Ganeti Team ganeti Debian HA Maintainers heartbeat redhat-cluster Debian ISC DHCP maintainers isc-dhcp Debian Libvirt Maintainers libguestfs libvirt Debian Live Project live-config Debian QA Group oidentd tcng Epoptes Developers epoptes Eric Evans ucarp Florian Schlichting vpnc Florian Weimer quagga (U) Fotis Tsamis epoptes (U) Frederik Schüler heartbeat (U) redhat-cluster (U) Ghe Rivero nova (U) Giuseppe Iuculano apf-firewall gregor herrmann iodine Guido Günther libguestfs (U) libvirt (U) redhat-cluster (U) Guido Trotter ganeti (U) Guus Sliepen ifenslave-2.6 Harald Jenny openswan (U) Hilko Bengen libguestfs (U) Holger Levsen debian-edu (U) sitesummary (U) Ian Jackson autopkgtest (U) Iustin Pop ganeti (U) Javier Fernandez-Sanguino Pen~a ifupdown-extra Javier Fernández-Sanguino Peña snort Jerome Benoit firehol sanewall Jon Ludlam xen-api (U) Jonathan Niehof pam-shield José L. Redrejo Rodríguez debian-edu (U) Juan Angulo Moreno lsat Julien Danjou nova (U) Julien Valroff rkhunter (U) Laurent Léonard libvirt (U) Live Systems Maintainers live-config Loic Dachary (OuoU) nova (U) Loic Minier avahi (U) vlan (U) LTSP Debian Maintainers ltsp Luis Uribe ipkungfu Marc Haber dsc-statistics (U) ifupdown-scripts-zg2 Mario Izquierdo (mariodebian) tcos Martin Loschwitz heartbeat (U) redhat-cluster (U) Martin Pitt autopkgtest (U) Martín Ferrari python-nemu Mateusz Kaduk pam-shield Mateusz Łukasik inxi (U) Matthew Grant netscript-2.4 Mehdi Abaakouk nova (U) Micah Anderson util-vserver Michael Biebl avahi (U) Michael Gilbert isc-dhcp (U) Michael Hanke arno-iptables-firewall Michael Prokop fai (U) Mike Gabriel debian-edu (U) Mike McClurg xen-api (U) Mike Miller vpnc-scripts Morten Werner Forsbring sitesummary (U) Ola Lundqvist util-vserver (U) vserver-debiantools vzctl Pascal Hofmann mysql-mmm Patrick Winnertz debian-edu (U) sitesummary (U) Petter Reinholdtsen debian-edu (U) sitesummary (U) Philipp Matthias Hahn netplug PKG OpenStack nova Pkg Xen xen-api Reinier Haasjes aiccu Rene Mayrhofer openswan strongswan Richard Jones libguestfs (U) Roberto C. Sanchez shorewall shorewall-core shorewall-lite shorewall6 shorewall6-lite Rolf Leggewie wondershaper (U) Sebastian Dröge avahi (U) Sebastian Laubscher dsc-statistics (U) Sebastian Lohff servefile Simon Horman heartbeat (U) Sjoerd Simons avahi (U) Steffen Joeris debian-edu (U) sitesummary (U) Thomas Goirand miniupnpd nova (U) xen-api (U) Thomas Lange fai Tiago Bortoletto Vaz apticron Tomasz Buchert miredo tony mancill iodine (U) Tássia Camões Araújo apticron (U) Unit 193 inxi Utopia Maintenance Team avahi Vagrant Cascadian debian-edu (U) epoptes (U) ltsp (U) Vince Mulhollon wondershaper Yves-Alexis Perez strongswan (U) -- Andreas Henriksson -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130925150258.ga12...@amd64.fatal.se
Re: Bug#705169: RFH: iproute2 -- networking and traffic control tools
Hello again! Given the very positive response on my RFH I'm following up with one more wish I forgot to mention. If you are interested in learning more about the advanced networking features provided by the linux kernel. Want to get into the gory details and learn stuff that not many other people (who aren't kernel hackers) know about. Why not take on the task to look at improving the manpages for iproute2? There are many bugs collected about pieces of information missing from manpages in the debian bug tracker at http://bugs.debian.org/src:iproute Start investigating, see what you find, try out stuff document your results in the manpage for everyone else to enjoy! -- Andreas Henriksson -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130411091421.ga28...@amd64.fatal.se
Re: Bug#705169: RFH: iproute2 -- networking and traffic control tools
Hello Thomas! On Wed, Apr 10, 2013 at 10:32:48PM +0200, Thomas Preud'homme wrote: > Le mercredi 10 avril 2013 21:33:32, Andreas Henriksson a écrit : [...] > > "Please perform a full source scan and document all licensing information." > > As requested by ftp-masters. > > I didn't find a bug report mentionning this request. Is there a place > mentionning it where progress to review the licensing could be posted? There's nothing public about this. The only feedback is by the recent reject of the later versions of the package from NEW (where it ended up because of the package rename). I've asked for additional details, but I wouldn't recommend holding your breath until more info appears. Please note the changes I've already done in the package git repo on alioth collab-maint. More improvements are probably needed until we reach a good enough state though. > > I'm willing to help on this point. I might have some time this WE to start > looking at it. Thank you very much for your interest in helping out! > > Best regards, > > Thomas -- Andreas Henriksson signature.asc Description: Digital signature
Bug#705169: RFH: iproute2 -- networking and traffic control tools
Package: wnpp Severity: normal I request assistance with maintaining the iproute2 package. Help is welcome in all areas, but following ones would be extra appreciated: "Please perform a full source scan and document all licensing information." As requested by ftp-masters. Triaging bugs listed at http://bugs.debian.org to find out if they are still valid, a fix can be found (and submitted upstream!), or confirmed to be in the kernel (and reassigned). Following up on new bug reports. Potentially review and forward patches upstream. The package description is: The iproute2 suite is a collection of utilities for networking and traffic control. . These tools communicate with the Linux kernel via the (rt)netlink interface, providing advanced features not available through the legacy net-tools commands 'ifconfig' and 'route'. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130410193332.20605.8061.report...@amd64.fatal.se
Bug#573738: ITP: rygel-grilo -- Grilo-based provider for Rygel
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: rygel-grilo Version : 0.0.0 Upstream Author : Juan A. Suarez Romero * URL : http://gitorious.com/grilo/rygel-grilo * License : LGPL Programming Lang: C Description : Grilo-based provider for Rygel rygel-grilo is a program that implements the "MediaServer specification" (http://live.gnome.org/Rygel/MediaServerSpec) and exposes content found by grilo backends over DBus to Rygel (and potential future implementions of the client part of the MediaServer specification). This means rygel-grilo makes all the grilo plugins content (read: youtube, jamendo, flickr, ...) accessible over UPnP/DLNA. rygel-grilo is still in very early development and I don't have any plans to package it until it atleast reaches basic maturity. Additionally grilo itself needs packaging first (see separate ITP). Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100313135826.5176.86731.report...@amd64.fatal.se
Bug#573737: ITP: grilo -- framework for media discovery and browsing
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: grilo Version : 0.1.3 Upstream Author : Iago Toral Quiroga , Juan A. Suarez Romero , Víctor Manuel Jáquez Leal * URL : http://live.gnome.org/Grilo * License : LGPL Programming Lang: C Description : ITP: grilo -- framework for media discovery and browsing Grilo is a framework focused on making media discovery and browsing easy for application developers. At the moment plugins exists to browse the following list of media providers: Youtube, Jamendo, Flickr, Podcasts, UPnP, # Last.FM album art Please see the URL above for more information. I do not intend to work on the packages immediately since upstream says the program is not ready to be officially shipped. Additionally upstream already has prepared debian packaging, so this ITP might become a "I'm willing to sponsor upstream". I'm mainly posting this as a flag to others interested in grilo, which might be interested in a collaboration. Feel free to contact me! Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100313134852.4735.17539.report...@amd64.fatal.se
Re: package deviates from standard mail-transport-agent dependency.
On Thu, Aug 21, 2008 at 12:37:38AM -0700, Steve Langasek wrote: > > Where did you discuss this mass filing of (useless) bugs before you > > submitted them? The previous discussions has lead nowhere. No use in discussing it yet again, instead it's time to act! > > In particular, these bugs are *contrary* to the developing consensus in the > thread at http://lists.debian.org/debian-devel/2008/05/msg00381.html ff. There where no consensus, since you where all just discussing overengineered solutions for solving the problem and all pointing out bugs in eachothers suggestions. Using exim4 | mail-transport-agent is the most straight-forward solution and will require minimal changes. When (or even if) the default mta changes, we can easily introduce the default-mta then (and maybe people would even have come up with a bug-free overengineered solution by then). I offer to fix up all packages to exim4 | mail-transport-agent *and* when there is a working default-mta proposal and a need for changing the actual default mta fix it up in every package. If people put as much effort into actually working on packages as they did on debating in useless threads that leads nowhere the distribution would be in a hell of alot better shape. Over and out. -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
Hi everybody! Although I guess there's no chance for it to make it in, Openswan is the one on my personal wishlist. Yes, the package is still buggy but AFAIK the bugs are eighter on the kernel-patches (I don't use KLIPS in favor of the in-kernel ipsec layer, and since they seem to be a real burden I'd suggest not packaging them at all.) or some long-standing well-known issues upstream that noone seem to care about... I'd suggest to write down "known problems" and lower the severity to wishlist. Thanks for all the hard work! Lets hope we'll see a release soon! :) Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
