Bug#977562: systemd: Incorrect order of agetty arguments in serial-getty@ttyS0.service definition file
Control: tags -1 + moreinfo On Wed, Dec 16, 2020 at 11:39:06PM +0100, Michael Biebl wrote: > Am 16.12.20 um 20:49 schrieb MK: > > Package: systemd > > Version: 241-7~deb10u5 > > Severity: normal [...] > > Incorrect order of arguments to agetty in the serial-getty@ttyS0.service > > unit file. > > > > It is: > > > > ExecStart=/sbin/agetty --autologin root -8 --keep-baud 115200,38400,9600 > > ttyS0 xterm-256color > > > > > > While it should be like: > > > > ExecStart=/sbin/agetty --autologin root -8 --keep-baud ttyS0 115200 > > xterm-256color [...] > According to the examples in man agetty, both should work. > > Andreas, can you comment here? > If what MK is saying, should the "EXAMPLE" section in man agetty be updated? > I don't really have much prior knowledge about *getty, but in my past experience with other util-linux tools it is often the case that (likely for historical reasons/compatibility) the arguments that doesn't come in a dash-form is attempted to be accepted in either order based on guessing which one was specified. In my past experience something that was guessable in the past might in later years become sometimes impossible to correctly guess right, so sticking with what synopsis describes is usually the safest as far as I'm concerned. In the agetty case, the guessing is done here: https://sources.debian.org/src/util-linux/2.36.1-2/term-utils/agetty.c/#L897 is_speed basically checks if the current argument only consists of either 0-9 or ','. It is not obvious to me how it could go wrong in the example originally described in this bug report. Please also note that for example sysvinit's inittab also uses getty with arguments in both orders. Simply it should work either way. Please also note that the argument order is not the only thing changed. It was also changed from specifying 3 speeds to only 1. Maybe the real issue here is that line speed detection isn't working? I'd appreciate if the bug reporter could dive a bit deeper into the problem. Regards, Andreas Henriksson
Bug#976926: golang-github-coreos-bbolt: FTBFS on ppc64el (arch:all-only src pkg): dh_auto_test: error: cd obj-powerpc64le-linux-gnu && go test -vet=off -v -p 160 -short go.etcd.io/bbolt returned exit
Hello! On Wed, Dec 09, 2020 at 10:03:39AM +0100, Lucas Nussbaum wrote: > Source: golang-github-coreos-bbolt > Version: 1.3.5-1 > Severity: serious > Justification: FTBFS on ppc64el > Tags: bullseye sid ftbfs > Usertags: ftbfs-20201209 ftbfs-bullseye ftbfs-ppc64el > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on ppc64el. At the same time, it did not fail on amd64. [...] > > === RUN TestBucket_Stats > > bucket_test.go:1222: unexpected BranchPageN: 0 > > --- FAIL: TestBucket_Stats (9.56s) [...] Apparently bbolt is a fork of boltdb, so please see my comments on the equivalent bug report againt boltdb: https://bugs.debian.org/976907 Relevant part: It seems the test-suite makes assumptions related to calculations that involve os.Getpagesize() (which gives 4096 on amd64 and 65536 on ppc64el, which is 16 times larger). Changing the 500 number to 8000 (16 times larger) in TestBucket_Stats(...) (in bucket_test.go:1143) gives the expected BranchPageN == 1 (however after that it then says "unexpected LeafPageN: 6" with this modification). In my opinion it's pretty clear that these are test-suite only issues and not issues in the actual product. I would thus personally just disable the test-suite on !amd64 if no porter is interested in fixing the testsuite (unless we agree this issue simply can be downgraded to non-RC). Regards, Andreas Henriksson
Bug#976907: golang-github-boltdb-bolt: FTBFS on ppc64el (arch:all-only src pkg): dh_auto_test: error: cd obj-powerpc64le-linux-gnu && go test -vet=off -v -p 160 -short github.com/boltdb/bolt github.co
Hello again, So after wasting my time here I finally realized that apparently boltdb is archived upstream. It will not receive any fixes. Apparently golang-github-coreos-bbolt is a maintained feature-extended fork. We should likely encurage moving to that and get boltdb removed from debian. The timeout waiting for db.mmaplock that occurred in boltdb is apparently already fixed in bbolt, see: https://github.com/etcd-io/bbolt/commit/e06ec0a754bc30c2e17ad871962e71635bf94d45 The pagesize issue seems to plague them both still though. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976926 for the bug report against bbolt. Regards, Andreas Henriksson
Bug#976907: golang-github-boltdb-bolt: FTBFS on ppc64el (arch:all-only src pkg): dh_auto_test: error: cd obj-powerpc64le-linux-gnu && go test -vet=off -v -p 160 -short github.com/boltdb/bolt github.co
Hello again, On Sat, Dec 12, 2020 at 05:59:37PM +0100, Andreas Henriksson wrote: > Hello all, > > 1 down, 1 to go info below. > > On Wed, Dec 09, 2020 at 10:03:31AM +0100, Lucas Nussbaum wrote: > [...] > > > === RUN TestBucket_Stats > > > bucket_test.go:1172: unexpected BranchPageN: 0 > > > --- FAIL: TestBucket_Stats (6.41s) [...] Now also quickly looked into this one. It seems the test-suite makes assumptions related to calculations that involve os.Getpagesize() (which gives 4096 on amd64 and 65536 on ppc64el, which is 16 times larger). Changing the 500 number to 8000 (16 times larger) in TestBucket_Stats(...) (in bucket_test.go:1143) gives the expected BranchPageN == 1 (however after that it then says "unexpected LeafPageN: 6" with this modification). Anyway, this makes me loose interest in pursuing this further. In my opinion it's pretty clear that these are test-suite only issues and not issues in the actual product. Unless someone else wants to pursue fixing up the test-suite for ppc64le needs, my offer to "fix" this will be to simply disable it on !amd64 architectures (unless we agree on simply downgrading this issue to non-RC). Regards, Andreas Henriksson
Bug#976907: golang-github-boltdb-bolt: FTBFS on ppc64el (arch:all-only src pkg): dh_auto_test: error: cd obj-powerpc64le-linux-gnu && go test -vet=off -v -p 160 -short github.com/boltdb/bolt github.co
Hello all, 1 down, 1 to go info below. On Wed, Dec 09, 2020 at 10:03:31AM +0100, Lucas Nussbaum wrote: > Source: golang-github-boltdb-bolt > Version: 1.3.1-7 > Severity: serious > Justification: FTBFS on ppc64el > Tags: bullseye sid ftbfs > Usertags: ftbfs-20201209 ftbfs-bullseye ftbfs-ppc64el > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on ppc64el. At the same time, it did not fail on amd64. [...] > > === RUN TestBucket_Stats > > bucket_test.go:1172: unexpected BranchPageN: 0 > > --- FAIL: TestBucket_Stats (6.41s) ^--- I've not looked into this one yet. [...] > > === RUN TestTx_Commit_ErrTxNotWritable > > panic: test timed out after 10m0s [...] ^-- this one is solved by adding `tx.Rollback()` last in TestTx_Commit_ErrTxNotWritable function (in tx_test.go:65). In other words, this is a test-suite bug (not a bug in the actual product code). The reasoning goes that tx.Commit() is expected to return error bolt.ErrTxNotWritable, which it does -- but this means it's holding a reader lock on db.mmaplock. After the test function finishes the deferred function db.MustClose() runs and calls into things that tries to take a read-write lock of db.mmaplock which times out. The added tx.Rollback() on a read-only tx basically only removes the transaction and releases the db.mmaplock. I have no idea why this would not also trigger on any other arch. Regards, Andreas Henriksson
Bug#976509: golang-github-shirou-gopsutil: FTBFS: dh_auto_test: error: cd obj-aarch64-linux-gnu && go test -vet=off -v -p 4 github.com/shirou/gopsutil github.com/shirou/gopsutil/cpu github.com/shirou/
On Sat, Dec 12, 2020 at 10:32:15AM +0100, Lucas Nussbaum wrote: > Hi Andreas, > > Is the above problem going to be a problem at runtime as well? It depends on which part of /proc you use and how it deviates on your architecture, but yes... eventually you'll hit something that errors out in parsing or worse returns an answer that's just wildly wrong/unexpected. > If so, I wonder if you should make this package "Architecture: amd64" > instead of "Architecture: all". [...] In theory, the right question is probably what anyone is willing to support. Debian usually takes the naive approach of assuming porters will fix up any issues once they're found, but that's not really how things turn out in practise. (Also if we limit the archs, what is the correct subset? The ones where the testsuite succeeds? The ones where it actually works? The ones which someone is actually promising to support?) The practical problem is that if the arch field is changed what happens to the entire reverse dependency tree that has accumulated? Getting one thing removed from the archive is hard and painful enough Regards, Andreas Henriksson
Bug#976509: golang-github-shirou-gopsutil: FTBFS: dh_auto_test: error: cd obj-aarch64-linux-gnu && go test -vet=off -v -p 4 github.com/shirou/gopsutil github.com/shirou/gopsutil/cpu github.com/shirou/
Hello Lucas Nussbaum,
On Sat, Dec 05, 2020 at 02:23:54PM +0100, Lucas Nussbaum wrote:
> Source: golang-github-shirou-gopsutil
> Version: 2.19.11-3
> Severity: serious
> Justification: FTBFS on arm64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201205 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on arm64 (I don't know if it also fails on amd64).
[...]
> > === RUN TestCpuInfo
> > cpu_test.go:90: could not get CPU Info:
> > {"cpu":0,"vendorId":"","family":"","model":"","stepping":0,"physicalId":"","coreId":"0","cores":1,"modelName":"","mhz":0,"cacheSize":0,"flags":["fp","asimd","evtstrm","aes","pmull","sha1","sha2","crc32","atomics","fphp","asimdhp","cpuid","asimdrdm","lrcpc","dcpop","asimddp","ssbs"],"microcode":""}
> > cpu_test.go:90: could not get CPU Info:
> > {"cpu":1,"vendorId":"","family":"","model":"","stepping":0,"physicalId":"","coreId":"1","cores":1,"modelName":"","mhz":0,"cacheSize":0,"flags":["fp","asimd","evtstrm","aes","pmull","sha1","sha2","crc32","atomics","fphp","asimdhp","cpuid","asimdrdm","lrcpc","dcpop","asimddp","ssbs"],"microcode":""}
> > cpu_test.go:90: could not get CPU Info:
> > {"cpu":2,"vendorId":"","family":"","model":"","stepping":0,"physicalId":"","coreId":"2","cores":1,"modelName":"","mhz":0,"cacheSize":0,"flags":["fp","asimd","evtstrm","aes","pmull","sha1","sha2","crc32","atomics","fphp","asimdhp","cpuid","asimdrdm","lrcpc","dcpop","asimddp","ssbs"],"microcode":""}
> > cpu_test.go:90: could not get CPU Info:
> > {"cpu":3,"vendorId":"","family":"","model":"","stepping":0,"physicalId":"","coreId":"3","cores":1,"modelName":"","mhz":0,"cacheSize":0,"flags":["fp","asimd","evtstrm","aes","pmull","sha1","sha2","crc32","atomics","fphp","asimdhp","cpuid","asimdrdm","lrcpc","dcpop","asimddp","ssbs"],"microcode":""}
> > --- FAIL: TestCpuInfo (0.00s)
[...]
> > FAIL
> > FAILgithub.com/shirou/gopsutil/cpu 0.047s
[...]
> > FAIL
> > dh_auto_test: error: cd obj-aarch64-linux-gnu && go test -vet=off -v -p 4
> > github.com/shirou/gopsutil github.com/shirou/gopsutil/cpu
> > github.com/shirou/gopsutil/disk github.com/shirou/gopsutil/docker
> > github.com/shirou/gopsutil/host github.com/shirou/gopsutil/internal/common
> > github.com/shirou/gopsutil/load github.com/shirou/gopsutil/mem
> > github.com/shirou/gopsutil/net github.com/shirou/gopsutil/process returned
> > exit code 1
>
> The full build log is available from:
>
> http://qa-logs.debian.net/2020/12/05/golang-github-shirou-gopsutil_2.19.11-3_unstable.log
[...]
With the above log I will, without ever looking deeper at the problem,
claim that gopsutil parsing of /proc/cpuinfo does not work on your
architecture of choice.
I've briefly dug into this package in the past[1] and unless my memory
serves me wrong my conclusion was that gopsutil's assumptions about
/proc is not intended to be portable between architectures at all.
On the other hand /proc looking wildly different between architectures
on linux is kind of a problem that each architecture that is not the
most popular one is setting themselves up for problems with. Not even
using the same syntax in /proc/cpuinfo (or even using same keywords
as used on mainstream archs, but give them a different meaning!).
I would personally expect that porters steps up if they want a
particular piece of software ported to their arch, but I doubt that will
happen. I also very much doubt anyone else will port to a wide range of
architectures, or even a single one - plus maintain it.
I can thus suggest one "solution":
Disable the testsuite on !amd64 and just let it build without actually
ever having a chance of working except possibly by chance.
(We all did this for so many years while kfreebsd was still a testing
migration blocker, so it's not like my suggestion is a new idea.)
HTH.
Regards,
Andreas Henriksson
[1]: https://github.com/shirou/gopsutil/pull/269
Bug#948188: Please package a newer PAM snapshot
Hello! On Mon, Dec 07, 2020 at 11:52:32AM +0100, Laurent Bigonville wrote: > Hello all, [...] > Strong password hashing is one thing, but src:pam now FTBFS [] should > be fixed in 1.4.0 > > So IMVHO, we need to update to at least 1.4.0 at least before the release. Thanks for your input. I wasn't aware that there's now a FTBFS to consider as well. I just want to be clear that *I* will most likely not pursue the actual upload of my previously proposed NMU (before the release, and possibly never) even though I think *someone* should! (This is purely based on my lack of motivation and time to dedicate to handle the possible fallout. Additionally we're getting very close to freeze which adds to me not not being able to muster the needed energy.) At this stage it might be useful to reach out and get an ACK from the release team before uploading. For the record: It's been a while since I looked into things but to my knowledge there are no issues with the NMU I prepared in my forked git repo[1]. (Things might have changed in related components in debian since, so possible additional tweaks might be needed.) A second pair of eyes reviewing the changes would be great though. Upstream has released even newer releases, 1.5.0 etc, but there modules that where deprecated in 1.4.0 (which my NMU just reenabled again) has now actually been removed. I thus suggest that whoever pursues updating pam in Debian starts with getting 1.4.0 in, then at a later point try to work out a long-term plan for the deprecated modules with who-ever is motivated to do the long-term maintenance of pam in Debian. Regards, Andreas Henriksson [1]: https://salsa.debian.org/ah/pam
Bug#976651: protobuf-compiler-grpc: Multi-arch protobuf-compiler-grpc
Package: protobuf-compiler-grpc Version: 1.16.1-1 Severity: normal Dear Maintainer, I'm having a problem with grpc_cpp_plugin in my cross-build environment. ``` $ apt-get build-dep -aarmhf . -y Note, using directory '.' to get the build dependencies Reading package lists... Building dependency tree... Reading state information... The following packages were automatically installed and are no longer required: libc-ares2 libgoogle-perftools4 libtcmalloc-minimal4 libunwind8 Use 'apt autoremove' to remove them. The following packages will be REMOVED: protobuf-compiler-grpc The following NEW packages will be installed: [...] protobuf-compiler-grpc:armhf [...] ``` If I'm not mistaken the protobuf-compiler-grpc package should be marked `Multi-Arch: foreign` just like for example protobuf-compiler package is. This would allow me to keep my hosts native protobuf-compiler-grpc package installed while installing the packages build-dependencies if I'm not mistaken. (Reported against the buster/stable version which is affected, but also verified that the situtation still seems to be the same with the testing/unstable version of the package.) Regards, Andreas Henriksson PS. Please don't take my word for anything about multi-arch stuff. If you're not qualified to know the correct solution I can probably help get someone else in the loop who can give us guidance.
Bug#970428: Prepared new packages for cheggaaa/pb (v1 + v3)
Hello, As already discussed in ITP #970428 I've been pondering packaging v3 of what was initially called github.com/cheggaaa/pb later replaced by gopkg.in/cheggaaa/pb.v1 (and v2) and is now again back under the initial github.com/cheggaaa/pb import path again as both v1 and v3. I've prepared an updated package in git[1] under the original name again now including both v1 and the new v3. The new package Provides, Replaces and Conflicts with golang-gopkg-chegga-pb.v1. I've also added both import paths to debian/control and symlinked the gopkg one to the new/original path. I would be really happy if someone could review this and tell me if/what I messed up. I've personally only (so far) tested building the new upstream release of mender-cli (v1.5.0) which needs cheggaaa/pb v3 as well as the currently shipped debian package of mender-cli (v1.4.0) which uses cheggaaa/pb v1 (with the original github.com/cheggaaa/pb import path). (I will likely need to test another package which uses the gopkg.in import path for v1 for full coverage.) Your review comments about this would be greatly appreciated! ITP: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970428 [1]: https://salsa.debian.org/go-team/packages/golang-github-cheggaaa-pb Regards,, Andreas Henriksson
Bug#969965: [Pkg-kbd-devel] Bug#969965: text installer: unable to switch keyboard layouts - libkeymap.so.1 missing
Hello Holger, On Tue, Oct 06, 2020 at 11:25:06PM +, Holger Wansing wrote: > Hi, > > Am Dienstag, 6. Oktober 2020 schrieb Andreas Henriksson: > > Could you please test rebuilding kbd with --enable-libkeymap to > > --disable-libkeymap in debian/rules? > > sbuild fails when I try it like that. > A build log is attached. > Debugging this is somewhat out of my skills, sorry. I've uploaded a new version that implements the above suggestion and would very much appreciate if you could test and give feedback on where we ended up when you have chance to do so. Regards, Andreas Henriksson
Bug#969965: [Pkg-kbd-devel] Bug#969965: text installer: unable to switch keyboard layouts - libkeymap.so.1 missing
Hello Holger Wansing, On Tue, Oct 06, 2020 at 04:49:14PM +0200, Holger Wansing wrote: > Control: reopen -1 > > Switching keyboard in the text installer still fails! [...] Thanks for testing and giving useful feedback on the kbd udebs. > loadkeys: error while loading shared libraries: libkeymap.so.1: cannot open > shared object file. No such file or directory > > Thus keymap is not set. Please fix loadkeys in udeb. [...] (... and once libkeymap.so.1 is available, libkbdfile.so.1 will be needed next I presume.) Could you please test rebuilding kbd with --enable-libkeymap to --disable-libkeymap in debian/rules? That should as I understand it make sure everything is linked statically and the shared libraries are not shipped at all (which if we want to should really happen in a separare properly named binary package anyway). (Another future TODO would also be to refactor debian/rules to do two separate flavoured builds with complete configure/build/install passes for each flavour, to replace the current brittle hack that duplicates the upstream build system as manual steps in debian/rules udeb build. Help welcome here as well ofcourse.) Regards, Andreas Henriksson
Bug#969319: wifi cannot connect after combined suspend & gateway reboot
Hi all, On Tue, Sep 08, 2020 at 11:35:27PM +0200, Michael Biebl wrote: [...] > I'm bringing Andreas, the maintainer iwd into the loop here. [...] (Seems you forgot to CC me but I stumbled upon this, so giving my 5c) FYI I lost interest and orphaned iwd. I'm can't tell if this is an iwd or NM bug. My best recommendation is to try without NM, connecting via iwctl and see if the problem can be reproduced standalone to help finding that out. Please also contact iwd upstream directly, either via their mailing list or irc channel. Make sure to include iwmon traces and debug output for them to be able to properly analyze what's going on. In my own experience there are many issues lingering in the NM iwd backend before it can be expected to be production quality. A very good way of triggering NM iwd backend problems is by using a hidden SSID for unknown reason. Please note that NM actively refused to connect to a hidden SSID using the iwd backend until recently (and I only fixed up the very basic things so that it is not actively refused, there should be comments on the upstream issue/merge-request about several remaining problems that needs to be adressed still if you're interested). Please note: - iwd upstream actively discurages usage of hidden SSIDs simply because there's no upside and many downsides to using it. - NM upstream actively discurages using the iwd backend (likely because they are tired of noone contributing to fixing it up). For a data point you can compare against, I'm using NM with iwd backend myself against a hidden SSID quite often. I only quickly glanced over your description, but I don't feel like I can relate to your problem description. I can however say that I do have to apply different hacks to get things going more often then I'd want to. Usually doing (a) below solves hickups when NM doesn't get along anymore with iwd, but rarely I also need to do (b) when NM decides there are no usable interfaces available. a/ systemctl stop iwd ; systemctl restart NetworkManager ; poke the GNOME ui to "select [wifi] network" so that NM dbus activates iwd again. b/ systemctl stop iwd; systemctl stop NetworkManager; rmmod ; modprobe ; systemctl start NetworkManager ; ... Regards, Andreas Henriksson
Bug#970428: ITP: golang-gopkg-cheggaaa-pb.v3 -- Console progress bar for Golang
Hello Shengjing Zhu, Thanks for your feedback. On Wed, Sep 16, 2020 at 10:56:08PM +0800, Shengjing Zhu wrote: > On Wed, Sep 16, 2020 at 5:33 PM Andreas Henriksson wrote: [...] > > * Package name: golang-gopkg-cheggaaa-pb.v3 [...] > This package uses a very strange version approach. > > In short, v3 is not really v3. > > The master branch contains both v1 and v3 code. Right now that's true, but I wonder for how long. My guess is that it's set up like this so that both the old gopkg.in/cheggaaa/pb.v1 import path and then new github.com/cheggaaa/pb/v3 import paths both works. (Leaving v2 in the cold.) I assume at some point upstream don't want to deal with v1 anymore and will just drop it from the master branch. > v3 code is lived in a directory called v3, see > https://github.com/cheggaaa/pb/tree/master/v3 > > So basically, we can reuse the v1 source package, v1 and v3 can live > together... I'm a bit worried what will happen if we do this and then upstream drops v1 Also what version number to use for it? There are 1.x and 3.x releases being done in parallell. Also what about the different import paths? github vs gopkg? > And maybe we can add a transitional package to avoid confusion. An alternative might be to just do v3 completely separate and if we really want to avoid it containing a duplicate v1 we could just do `Files-Excluded: ./*.go` on whatever. I however don't see any real issue with just leaving it in (possibly without installing the files in the binary -dev package). The copyright review for it all is trivial. Would very much appreciate help with creating a package for it however that person wants to set it up. :) Regards, Andreas Henriksson
Bug#970428: ITP: golang-gopkg-cheggaaa-pb.v3 -- Console progress bar for Golang
On Wed, Sep 16, 2020 at 11:28:03AM +0200, Andreas Henriksson wrote: > * Package name: golang-gopkg-cheggaaa-pb.v3 > Version : 1.0.29-1 [...] Actually 'version' is 3.0.7 this confusion seems to be related to what I'm about to mention next. (Can I call it the 'go import path circus'?) First see https://github.com/cheggaaa/pb/issues/155 So apparently now all code has moved into a v3 subdirectory (unlike v1 and v2), for the potential benefit of the go mod tool I guess. Also note that the root directory of the git repo still contains some pre-v3 implementation of cheggaaa's pb (with a different API). This possibly means that using gopkg(.in) in the package name as well as the pb.v3 naming should be abandoned in the debian package name? Possibly it should now instead become: - golang-github-cheggaaa-pb(-dev) unlike previous versions in the debian archive which are named: - golang-gopkg-cheggaaa-pb.v1(-dev) - golang-gopkg-cheggaaa-pb.v2(-dev) I've asked for advice on the #debian-golang channel. Feedback welcome if anyone knows the best way to handle this problem. Sigh. As mentioned, If anyone else wants to do this package... - please! 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#969612: pipewire 0.3 now in experimental, please prep for transition
Hello, The new version 0.3 of pipewire has now landed in experimental. Please prepare your package for the new version and upload it to experimental once ready so we can make progress on #966535. Thanks! Regards, Andreas Henriksson
Bug#969586: O: iwd -- wireless daemon for Linux
Package: wnpp Severity: normal I intend to orphan the iwd package in the next upload. The package description is: Minimalistic wireless daemon that uses modern Linux interfaces like cfg80211 and nl80211 (netlink). The daemon provides a D-Bus API. . The daemon can be controlled from the command line with the included iwctl client utility. . The included iwmon utility can be used to monitor the 802.11 subsystem generic netlink commands and events. It uses the nlmon kernel driver from Linux 3.10 and later. Regards, Andreas Henriksson
Bug#968956: kbd: fails to build on big endian (s390x)
Package: kbd Version: 2.2.0-1 Severity: serious Tags: upstream Justification: FTBFS on release arch Forwarded: https://github.com/legionus/kbd/issues/40 Hello, The new kbd release recently uploaded to unstable (2.2.0) which includes fixes to build with gcc-10 has a regression on big-endian architectures successfully caught by the test-suite. More information is already available in the upstream issue tracker where someone has done the initial investigations. (See forwarded url above.) Would be great if someone from the debian s390 porters team would follow up with which path to go down and propose a patch that implements the solution. Alternatively we could disable the test-suite on s390 in debian if you think this issue is not important enough to hold up the other fixes from entering testing/bullseye. Regards, Andreas Henriksson
Bug#968343: RM: golang-github-mendersoftware-mendertesting-dev -- ROM; deprecated and unused
Control: tags -1 - moreinfo Hello Sean, On Sat, Aug 22, 2020 at 08:26:53AM -0700, Sean Whitton wrote: > control: tag -1 + moreinfo > > Hello, > > On Thu 13 Aug 2020 at 01:02PM +02, lluis.cam...@northern.tech wrote: > > > This dependency is now deprecated after latest update of packages > > mender-cli and golang-github-mendersoftware-mender-artifact following > > upstream Mender project release. > > > > Unused both in testing and unstable, so please remove: > > > > golang-github-mendersoftware-mendertesting-dev > > > > See also #960398 for related previously RM bug report. > > Could the maintainer confirm this, please? Not sure who the question is directed at but hopefully I can help clear out some confusion here. This is a ROM. Lluis is both debian (co-)maintainer as well as upstream for all the mender related components (unlike myself who only tries to help out on the debian side). Lluis has been driving the work to clean out dependencies of these deprecated components both upstream and in debian. Would be great if we can put the final nail in the coffin and get them removed. Since Lluis doesn't have the access I've now tried dak rm test run which seems to confirm there should be no blockers for the removal of golang-github-mendersoftware-mendertesting (Lluis: please note to give ftp-masters the name of the source-package, not the binary package unless you're asking for only a specific binary package to be removed. Normally we want source removals and that will also get all binaries removed.) Hope this helps. Regards, Andreas Henriksson
Bug#966518: build: hook up traditional dbus activation
On systems using systemd dbus will use the SystemdServices= directive, but on non-systemd systems the so called "traditional dbus activation" method involves reading the Exec= directive. Setting that to /bin/false means this service is not relevant on non-systemd systems, but apparently there's an interest from users of such systems to use iwd (and possibly ead). Thus hook up the expansion of the paths in the Exec= directive of the dbus service files to allow the traditional dbus activation to start respective daemon. Signed-off-by: Andreas Henriksson --- Makefile.am | 11 ++- src/net.connman.iwd.service | 5 - src/net.connman.iwd.service.in | 5 + wired/net.connman.ead.service| 5 - wired/net.connman.ead.service.in | 5 + 5 files changed, 16 insertions(+), 15 deletions(-) delete mode 100644 src/net.connman.iwd.service create mode 100644 src/net.connman.iwd.service.in delete mode 100644 wired/net.connman.ead.service create mode 100644 wired/net.connman.ead.service.in diff --git a/Makefile.am b/Makefile.am index 57c694d..006d1d1 100644 --- a/Makefile.am +++ b/Makefile.am @@ -250,7 +250,7 @@ dist_dbus_data_DATA += src/iwd-dbus.conf endif if SYSTEMD_SERVICE -src_iwd_DEPENDENCIES += src/iwd.service +src_iwd_DEPENDENCIES += src/iwd.service src/net.connman.iwd.service systemd_unit_DATA += src/iwd.service dbus_bus_DATA += src/net.connman.iwd.service @@ -328,7 +328,7 @@ dist_dbus_data_DATA += wired/ead-dbus.conf endif if SYSTEMD_SERVICE -wired_ead_DEPENDENCIES += wired/ead.service +wired_ead_DEPENDENCIES += wired/ead.service wired/net.connman.ead.service systemd_unit_DATA += wired/ead.service dbus_bus_DATA += wired/net.connman.ead.service @@ -524,8 +524,8 @@ unit_test_p2p_LDADD = $(ell_ldadd) TESTS = $(unit_tests) -EXTRA_DIST = src/genbuiltin src/iwd.service.in src/net.connman.iwd.service \ - wired/ead.service.in wired/net.connman.ead.service \ +EXTRA_DIST = src/genbuiltin src/iwd.service.in src/net.connman.iwd.service.in \ + wired/ead.service.in wired/net.connman.ead.service.in \ src/80-iwd.link src/pkcs8.conf unit/gencerts.cnf \ $(manual_pages) $(patsubst %.1,%.rst, \ $(patsubst %.5,%.rst, \ @@ -539,7 +539,8 @@ if MAINTAINER_MODE AM_CFLAGS += -DHAVE_PKCS8_SUPPORT endif -CLEANFILES = src/iwd.service wired/ead.service +CLEANFILES = src/iwd.service wired/ead.service \ +src/net.connman.iwd.service wired/net.connman.ead.service DISTCHECK_CONFIGURE_FLAGS = --disable-dbus-policy --disable-systemd-service \ --enable-sim-hardcoded \ diff --git a/src/net.connman.iwd.service b/src/net.connman.iwd.service deleted file mode 100644 index d8ece4c..000 --- a/src/net.connman.iwd.service +++ /dev/null @@ -1,5 +0,0 @@ -[D-BUS Service] -Name=net.connman.iwd -Exec=/bin/false -User=root -SystemdService=iwd.service diff --git a/src/net.connman.iwd.service.in b/src/net.connman.iwd.service.in new file mode 100644 index 000..a7cb7ed --- /dev/null +++ b/src/net.connman.iwd.service.in @@ -0,0 +1,5 @@ +[D-BUS Service] +Name=net.connman.iwd +Exec=@libexecdir@/iwd +User=root +SystemdService=iwd.service diff --git a/wired/net.connman.ead.service b/wired/net.connman.ead.service deleted file mode 100644 index 24af96b..000 --- a/wired/net.connman.ead.service +++ /dev/null @@ -1,5 +0,0 @@ -[D-BUS Service] -Name=net.connman.ead -Exec=/bin/false -User=root -SystemdService=ead.service diff --git a/wired/net.connman.ead.service.in b/wired/net.connman.ead.service.in new file mode 100644 index 000..63e5011 --- /dev/null +++ b/wired/net.connman.ead.service.in @@ -0,0 +1,5 @@ +[D-BUS Service] +Name=net.connman.ead +Exec=@libexecdir@/ead +User=root +SystemdService=ead.service
Bug#966518: iwd: Fails to autostart for sysvinit users
Control: tags -1 - patch Control: tags -1 + upstream Control: severity -1 wishlist On Thu, Jul 30, 2020 at 03:37:14AM +, Job Bautista wrote: > Package: iwd > Version: 1.8-1 > Severity: grave > Tags: patch > Justification: renders package unusable > > Dear Maintainer, > > When I install iwd on a Debian-based system which uses sysvinit instead of > systemd, iwd doesn't start at boot. [...] 1. There's no patch attached. Try `man diff`. PLEASE NOTE: One of debians primary objectives is free software, so adding autogenerated cruft without the preferable form of modification being available is not going to happen. (Which would actually be a severity serious bug.) 2. Have you heard about dbus activation? 3. Stop over-inflating the severity of your bug reports which is just counter-productive. Better yet, please stop filing debian bug reports when you're not even using debian! (If you intend to make upstream contributions, then seek up the actual upstream of iwd.) PLEASE NOTE: It is *not* *my* responsibility to educate you. PS. I will happily assist in having the package removed from the *debian* archive rather than spending more time on discussing with clueless people if that makes you happy. I've certainly had enough. Regards, Andreas Henriksson
Bug#948188: Debian pam 1.4.0 NMU - RFC pam_umask usergroups + Request for testing
Hello all, This is a final request for comment and request for testing. I'll be NMUing this very soon unless I get some feedback. On Fri, Jun 12, 2020 at 08:35:39PM +0200, Andreas Henriksson wrote: > Control: forwarded -1 https://salsa.debian.org/ah/pam/-/commits/master-1.4.0 [...] I've now done some basic testing of my previous packaging work of pam 1.4.0 including pam_umask and usergroups enabled by default. (As well as updating debian/NEWS and debian/changelog accordingly.) There has been some previous discussion and apparent opposition towards extending the common-* configuration, eg. in #207394 and #583958 -> https://bugs.launchpad.net/ubuntu/+source/pam/+bug/253096 I personally don't see it viable that all applications reimplement the same thing and think umask is generic enough that it should be globally enforced to avoid opening up any loopholes. If there's still disagreement around this then please speak up now or forever hold your breath! See: https://salsa.debian.org/ah/pam/-/commit/4b44d93dbb8c435e0ff314e4289e168cdfc9824e I would be very happy if people who have more complex pam configurations would test this! Do you have a need for a particular module being loaded before pam_umask for example? (Someone claimed pam_group needs to be loaded before pam_umask somewhere) In general I would also be very happy if someone could review the rebasing of the debian/patches. If you're busy but interested in helping out with testing, please shoot me a mail so I'm aware of your interest and can give you some more time. If the result is plain silence I'll likely go ahead with NMU very soon. Regards, Andreas Henriksson
Bug#919619: [Pkg-utopia-maintainers] Bug#919619: NM 1.24.0 now has basic support for hidden networks with iwd backend
Hello, On Sun, Jul 12, 2020 at 05:39:19PM +0200, Jonas Smedegaard wrote: > I understand that neither you nor Andreas consider current release of > IWD a _recommended_ alternative for wpa-supplicant. That is a good > reason to not depend on or recommend iwd. I think iwd itself (since >= 1.2, so not the version in buster) has reached production quality. The problem here is the iwd backend in *NM* which is not production quality and actively discuraged by NM upstream! Please note that the iwd backend is not even *compiled* by default! (This is a debian deviation and I'm sure if you give Michael enough grief about this he'll reconsider and go back to upstream recommendations of not even building the IWD backend.) > > I do not understand, however, why you will not relax relationship on > wpa-supplicant to recommend it instead of depending on it. Because there's no benefit in doing it, while there's a massive support burden. There's a massive amount of clueless users who blatantly configure recommends to not be installed and any application that has as many users as NM will be hit with a floodwave of support requests over it. From being involved in the GNOME team we know it's simply not possible. You haven't offered to do the work, but if you're willing then start out by triaging the existing bug reports! Talk is cheap, etc, etc. > > There are use-cases of network-manager without wpa-supplicant, when > either wifi is not used, or when IWD is used instead. Nothing prevents you from using iwd (while having wpasupplicant installed). If you feel you must get rid of wpasupplicant (why?), then here are a few options: * use equivs to create a dummy replacement * recompile NM packaging with wpasupplicant dependency changed (You could even contribute a patch which does this using build-profiles so you can rebuild without any changes to the source package!) * use dpkg exclude features to get wpasupplicant packages files not unpacked on your system while the package gets installed. * realize that wpasupplicant is small and useful to have as a fallback if something ever goes wrong. You seem to just argue over a theoretical supremacy idea, while not even trying to describe which practical problem you're trying to solve. > > Again, I do understand that such use-cases are not _recommended_ but > they are still _possible_ and _wanted_ for some unusual situations. Yes, it's still possible. So go do it! FFS I'm using it myself right now! It is certainly possible. Better yet start improving the NM iwd backend so that it becomes better. Maybe some day NM upstream will even reconsider and have it compiled by default (it comes with zero new build-time dependencies after all). After that they might even automatically fall back on using iwd without requiring manual configuration. > Debian Policy says to use Recommends: not Depends: for such relations. This is your interpretation. Please understand that the Debian project still has not managed to produce a way to turn mailinglist discussions into working code. The way to reach your goal is to improve the code by debugging current bugs (which there are quite a bunch of in the iwd backend of NM) and submitting patches upstream. As already mentioned, the debian packaging of NM is already ahead of the game on being cutting edge w.r.t. iwd. The ball is really in your court! If you want to support widespread iwd usage, then improve the code! This is the last time I'm repeating myself on this topic I've tried to keep this bug report up to date with latest information of progress, but I'm not sure if I find the motivation for even that. I will however repeat what I said last time: There are no progress being made anymore on the iwd backend in NM! Noone is working on improving it! Thus don't expect progress to be made, unless you contribute! You should likely expect the next step to be that the code is removed upstream given the current state of things unless someone (this means YOU!) steps up and starts improving it! Regards, Andreas Henriksson
Bug#913308: Updated ddclient packaging mid-air collision
Hello Richard Hansen, I started working on updating the ddclient packaging to non-ancient standards today, thinking it's still sitting in it usual abandoned state. When I was about ready to upload I noticed you'd already claimed https://salsa.debian.org/debian/ddclient ... Would have been nice to not waste my time, but oh well.. Some suggestions: - please mention somewhere (like in the "new upstream release" bug report - CCed) that you're working on things. - please start small, eg. by just updating the Vcs-* fields and setting yourself as maintainer in an initial upload. Just to get the basic information updated in the package tracker ASAP. - consider actually using alioth archived git repo plus the changes already in the debian archive(!) as the base for your work. While you still have the chance, since your work is not yet uploaded (AFAICT), you probably don't fancy to start over again. (And likewise, on top of my last point above, there's too much changes in the repo for me to find energy to wade through them all right now.) Anyway, I've pushed my work here in case there's something you can/want to salvage: https://salsa.debian.org/ah/ddclient/-/tree/master Regards, Andreas Henriksson
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
Bug#919619: [Pkg-utopia-maintainers] Bug#919619: NM 1.24.0 now has basic support for hidden networks with iwd backend
On Sat, Jul 04, 2020 at 12:42:57AM +0200, Michael Biebl wrote: > Am 04.07.20 um 00:16 schrieb Jonas Smedegaard: > > Then how about _not_ recommend iwd but just lower from depending on > > wpasupplicant to only recommending it. Because that's what it is: > > Recommended for all except special situations. For now... Right? > > Hm, no. That's exactly the situation I want to avoid. The user > installing iwd, removing wpasupplicant in the process, network not > working anymore. A Recommends makes that even worse. Either iwd works as > a drop-in replacement (without requiring explicit configuration) or not. > That's basically my question. > If it does, I'm happy to add an alternative Depends assuming Andreas is > fine with that. I can confirm there's still no automatic fallback to use iwd. It has to be manually configured to even be attempted to be used. This is something I'd personally consider a blocker if I where NM Debian maintainer. I quickly asked upstream a while ago if we couldn't atleast automatically fall back on iwd if we detect that wpasupplicant isn't even *installed*, but their responses where negative. They don't seem to like or support iwd usage at all Additionally as previously mentioned the iwd backend in NM still needs more work to be production quality. Current state is that it's fully usable as far as I can tell, but you'll likely occationally need to restart NetworkManager.service when NM and iwd gets state out of sync. (I've experienced this alot, but have not debugged it in detail. There are likely many small issues to be found and ironed out here.) At this point I don't think it's safe to allow the general public of NM users to be able to uninstall wpasupplicant and people who really want to use iwd with NM and really want to uninstall wpasupplicant to use an equivs. I however would suggest keeping wpasupplicant around still in case of emergency, if you're not in a situtation that forces you to not have wpasupplicant installed for whatever reason (which should be rare enough that using equivs to solve it seems suitable). This is the situation as I see it for now. I've also previously mentioned that I don't see anyone putting work into the situation improving so I guess it'll remain the same for a forseeable future. Regards, Andreas Henriksson
Bug#953227: garagemq: autopkgtest failure: github.com/valinurovam/garagemq/srvstorage [no test files]
Hi, On Thu, Jun 25, 2020 at 03:16:25AM +0800, Shengjing Zhu wrote: > Control: reopen -1 > Control: notfixed -1 0.0~git20200204.15e6a9d+ds-2 > Control: tags -1 + ftbfs > > Hi Andreas, > > You just disabled the autopkgtest. But the test is not only running in > autopkgtest, but also during package building. > It FTBFS with sbuild too. Log is attached. I've personally never been able to trigger test issues during a normal package build, but if this is a problem for you then I've just now uploaded a new version which disable the build time tests as well. HTH. Regards, Andreas Henriksson
Bug#962174: Fwd: Bug#962174: Acknowledgement (iwd: Failed to load trusted user certificate)
Control: tags -1 + upstream Hello Martin Tesar, Thanks for your bug report. This is obviously not a debian packaging bug so could you please discuss this directly with upstream? Either on their mailing list and/or their irc channel. See https://sources.debian.org/src/iwd/1.8-1/debian/upstream/metadata/ Regards, Andreas Henriksson On Thu, Jun 04, 2020 at 06:29:22PM +0200, Martin Tesar wrote: > Hello, > > I am not sure who can change it. Would you, please? > > Thanks in advance! > > BR > Martin > > -- Forwarded message - > Od: Martin Tesar > Date: čt 4. 6. 2020 v 14:51 > Subject: Re: Bug#962174: Acknowledgement (iwd: Failed to load trusted user > certificate) > To: > > > Hello, > > would you please change an email address of a submitter (me) from > tesar...@gmail.com to my other email address martin.te...@yourwifi.cz? > > Thanks a lot! > > Regards, > Martin Tesar > > čt 4. 6. 2020 v 10:33 odesílatel Debian Bug Tracking System > napsal: > > > > Thank you for filing a new Bug report with Debian. > > > > You can follow progress on this Bug here: 962174: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962174. > > > > This is an automatically generated reply to let you know your message > > has been received. > > > > Your message is being forwarded to the package maintainers and other > > interested parties for their attention; they will reply in due course. > > > > Your message has been sent to the package maintainer(s): > > Andreas Henriksson > > > > If you wish to submit further information on this problem, please > > send it to 962...@bugs.debian.org. > > > > Please do not send mail to ow...@bugs.debian.org unless you wish > > to report a problem with the Bug-tracking system. > > > > -- > > 962174: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962174 > > Debian Bug Tracking System > > Contact ow...@bugs.debian.org with problems
Bug#948188: New upstream release 1.4.0
Control: forwarded -1 https://salsa.debian.org/ah/pam/-/commits/master-1.4.0 Hello again, I've now pushed my initial work on updating the packaging to 1.4.0 here: https://salsa.debian.org/ah/pam/ See master-1.4.0 and upstream-1.4.0 branches. Current status is that it builds. I'll continue working on making it ready for upload when I find time. Please also note that there's a bunch of things related to deprecations that I expect maintainers to eventually step up and clean up, which I'm just avoiding to touch as much as I can (eg. I'm reenabling deprecated modules, also updating patches which likely doesn't make sense to keep around anymore since /etc/securetty doesn't exist, etc). Regards, Andreas Henriksson
Bug#948188: New upstream release 1.4.0
Control: retitle -1 New upstream release 1.4.0 Hi, There's now a new upstream release available, 1.4.0. This release includes changes related to several of the outstanding debian bts requests, among them: - libxcrypt support (as discussed in this bug report) - configurable default setting for usergroups https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583958#103 https://salsa.debian.org/vorlon/pam/-/merge_requests/3 - etc. I'm interested in seeing atleast the usergroups issue fixed once and for all. This is IMO best done by uploading the new upstream release and adding the necessary debian integration work on top of that. There's so far not been any input from maintainers on the discussion here. If maintainers intend to work on the new upstream release or have any objections towards it being done as a NMU then PLEASE SPEAK UP NOW! (I have limited time available so don't want to waste it on preparing the new upstream release if we won't actually upload it.) If someone else has more time and is interested in working on preparing the new upstream release, please do so and also please me/us that you're doing so (by posting to this bug report and CC everyone involved?!). Regards, Andreas Henriksson
Bug#958668: u-boot: Please consider enabling rpi4 support
Control: forwarded -1 https://salsa.debian.org/debian/u-boot/-/merge_requests/11 Hello, I've updated the patch and sent it as a merge-request on salsa instead. I listed both me and Lucas as contacts for the rpi_4 target. Regards, Andreas Henriksson
Bug#919619: NM 1.24.0 now has basic support for hidden networks with iwd backend
Hi, Just wanted to drop a comment about the iwd status in NM. NM has since 1.24.0, which is now in testing/unstable, basic support for connecting to a hidden network using the iwd backend. There are still many minor bugs remaining in the NM iwd backend both for hidden and any other network. Examples that comes to mind: - Removing a connection in NM doesn't seem to propagate to iwd known-network list. - NM and iwd sometimes gets out of sync for unknown reasons, stopping iwd and restarting NetworkManager then browsing menues to trigger dbus activation of iwd again can be used as a workaround. - nmcli errors out on trying to scan (for a hidden network!) even when specifying 'hidden yes' on the command line. (Working method to provision a hidden network includes using the "Connect to hidden network..." menu entry in gnome-control-center Wi-Fi pane.) - and more... Many minor workaroundable issues that needs more polish. Unfortunately it doesn't seem like anyone is working on improving the NM iwd backend since quite a while now (except for my basic hidden network contribution, which was a one-off for personal needs). Regards, Andreas Henriksson
Bug#936625: gnome-doc-utils: Python2 removal in sid/bullseye
Control: tags -1 + wontfix Hello all, On Thu, Apr 30, 2020 at 08:41:47AM +0200, Christoph Reiter wrote: > Fedora has ported it to Python 3: > https://src.fedoraproject.org/rpms/gnome-doc-utils/blob/master/f/gnome-doc-utils-0.20.10-python3.patch Thanks for providing this information. You don't happen to know the underlying reason for why they did this? Unrelated to python(3), gnome-doc-utils is deprecated after all. We currently have no reverse dependencies in testing on the Debian side, thus I think we're in a good position to remove it rather than fix any outstanding bugs in it (and autoremoval should kick in soon as the targeted date was apparently yesterday). I'm thus tagging this wontfix for the potential benefit of anyone trying to get the overview of remaining python3 porting work. Regards, Andreas Henriksson
Bug#960398: RM: golang-github-mendersoftware-log -- ROM; deprecated and unused
Package: ftp.debian.org Severity: normal Hello ftp team, The upstream mender project is working on deprecating a couple of components which was previously used by mender-client, et.al. One of the two are now unused both in testing and unstable, so please remove: golang-github-mendersoftware-log (Another report will be filed once golang-github-mendersoftware-mendertesting is ready for removal.) Regards, Andreas Henriksson
Bug#960079: Acknowledgement (undefined symbol: _PyNautilusInfoProvider_Type)
Hello again,
Sorry for trying to be lazy. Attached new patch. Could you please
test it?
Regards,
Andreas Henriksson
From: Andreas Henriksson
Subject: Fix build with gcc 10
Bug-Debian: https://bugs.debian.org/957578
Forwarded: https://gitlab.gnome.org/GNOME/nautilus-python/-/merge_requests/7
Last-Update: 2020-05-11
--- nautilus-python-1.2.3.orig/src/nautilus-python-object.c
+++ nautilus-python-1.2.3/src/nautilus-python-object.c
@@ -40,7 +40,7 @@ int __PyString_Check(PyObject *obj) {
#endif
}
-char* __PyString_AsString(PyObject *obj) {
+const char* __PyString_AsString(PyObject *obj) {
#if PY_MAJOR_VERSION >= 3
return PyUnicode_AsUTF8(obj);
#else
@@ -389,7 +389,7 @@ beach:
#define METHOD_NAME "update_file_info"
static NautilusOperationResult
nautilus_python_object_update_file_info (NautilusInfoProvider *provider,
- NautilusFile *file,
+ NautilusFileInfo *file_info,
GClosure *update_complete,
NautilusOperationHandle **handle) {
NautilusPythonObject *object = (NautilusPythonObject*)provider;
@@ -408,12 +408,12 @@ nautilus_python_object_update_file_info
pygobject_new((GObject*)provider),
py_handle,
pyg_boxed_new(G_TYPE_CLOSURE, update_complete, TRUE, TRUE),
- pygobject_new((GObject*)file));
+ pygobject_new((GObject*)file_info));
}
else if (PyObject_HasAttrString(object->instance, "update_file_info")) {
py_ret = PyObject_CallMethod(object->instance,
METHOD_PREFIX METHOD_NAME, "(N)",
- pygobject_new((GObject*)file));
+ pygobject_new((GObject*)file_info));
}
else {
goto beach;
@@ -434,7 +434,7 @@ nautilus_python_object_update_file_info
#endif
beach:
-free_pygobject_data(file, NULL);
+free_pygobject_data(file_info, NULL);
Py_XDECREF(py_ret);
pyg_gil_state_release(state);
return ret;
--- nautilus-python-1.2.3.orig/src/nautilus-python.c
+++ nautilus-python-1.2.3/src/nautilus-python.c
@@ -22,6 +22,7 @@
#endif
#include
+#define NO_IMPORT_PYGOBJECT //To avoid a multiple definition, nautilus-python-object.c also includes and does the import.
#include
#include
#include
@@ -42,6 +43,18 @@ static gboolean nautilus_python_init_pyt
static GArray *all_types = NULL;
+PyTypeObject *_PyGtkWidget_Type;
+PyTypeObject *_PyNautilusColumn_Type;
+PyTypeObject *_PyNautilusColumnProvider_Type;
+PyTypeObject *_PyNautilusInfoProvider_Type;
+PyTypeObject *_PyNautilusLocationWidgetProvider_Type;
+PyTypeObject *_PyNautilusMenu_Type;
+PyTypeObject *_PyNautilusMenuItem_Type;
+PyTypeObject *_PyNautilusMenuProvider_Type;
+PyTypeObject *_PyNautilusPropertyPage_Type;
+PyTypeObject *_PyNautilusPropertyPageProvider_Type;
+PyTypeObject *_PyNautilusOperationHandle_Type;
+
static inline gboolean
np_init_pygobject(void) {
PyObject *gobject = pygobject_init (PYGOBJECT_MAJOR_VERSION, PYGOBJECT_MINOR_VERSION, PYGOBJECT_MICRO_VERSION);
--- nautilus-python-1.2.3.orig/src/nautilus-python.h
+++ nautilus-python-1.2.3/src/nautilus-python.h
@@ -43,37 +43,37 @@ extern NautilusPythonDebug nautilus_pyth
#define debug_enter_args(x, y) { if (nautilus_python_debug & NAUTILUS_PYTHON_DEBUG_MISC) \
g_printf("%s: entered " x "\n", __FUNCTION__, y); }
-PyTypeObject *_PyGtkWidget_Type;
+extern PyTypeObject *_PyGtkWidget_Type;
#define PyGtkWidget_Type (*_PyGtkWidget_Type)
-PyTypeObject *_PyNautilusColumn_Type;
+extern PyTypeObject *_PyNautilusColumn_Type;
#define PyNautilusColumn_Type (*_PyNautilusColumn_Type)
-PyTypeObject *_PyNautilusColumnProvider_Type;
+extern PyTypeObject *_PyNautilusColumnProvider_Type;
#define PyNautilusColumnProvider_Type (*_PyNautilusColumnProvider_Type)
-PyTypeObject *_PyNautilusInfoProvider_Type;
+extern PyTypeObject *_PyNautilusInfoProvider_Type;
#define PyNautilusInfoProvider_Type (*_PyNautilusInfoProvider_Type)
-PyTypeObject *_PyNautilusLocationWidgetProvider_Type;
+extern PyTypeObject *_PyNautilusLocationWidgetProvider_Type;
#define PyNautilusLocationWidgetProvider_Type (*_PyNautilusLocationWidgetProvider_Type)
-PyTypeObject *_PyNautilusMenu_Type;
+extern PyTypeObject *_PyNautilusMenu_Type;
#define PyNautilusMenu_Type (*_PyNautilusMenu_Type)
-PyTypeObject *_PyNautilusMenuItem_Type;
+extern PyTypeObject *_PyNautilusMenuItem_Type;
#define PyNautilusMenuItem_Type (*_PyNautilusMenuItem_Type)
-PyTypeObject *_PyNautilusMenuProvider_Type;
+extern PyTypeObject *_PyNautilusMenuProvider_Type;
#define PyNautilusMe
Bug#960079: Acknowledgement (undefined symbol: _PyNautilusInfoProvider_Type)
Hi Michael,
On Sat, May 09, 2020 at 08:32:24AM +0200, Michael Biebl wrote:
> This was broken by debian/patches/gcc10.patch
>
> Bringing Andreas into the loop here.
>
Thanks for notifying me and sorry for causing the breakage.
I'm not actually using nautilus-python myself which might be obvious by
now. Do you think you could test the attached patch instead?
(The use of static is basically a workaround because I'm to lazy. The
better fix would likely be to declare it extern in the header, which is
included twice, and then actually declare the variable in one of the
c source files.)
Maybe I'm still not really understanding the code though It's not
obvious to me what it's trying to do.
Regards,
Andreas Henriksson
--- nautilus-python-1.2.3.orig/src/nautilus-python-object.c
+++ nautilus-python-1.2.3/src/nautilus-python-object.c
@@ -40,7 +40,7 @@ int __PyString_Check(PyObject *obj) {
#endif
}
-char* __PyString_AsString(PyObject *obj) {
+const char* __PyString_AsString(PyObject *obj) {
#if PY_MAJOR_VERSION >= 3
return PyUnicode_AsUTF8(obj);
#else
@@ -389,7 +389,7 @@ beach:
#define METHOD_NAME "update_file_info"
static NautilusOperationResult
nautilus_python_object_update_file_info (NautilusInfoProvider *provider,
- NautilusFile *file,
+ NautilusFileInfo *file_info,
GClosure *update_complete,
NautilusOperationHandle **handle) {
NautilusPythonObject *object = (NautilusPythonObject*)provider;
@@ -408,12 +408,12 @@ nautilus_python_object_update_file_info
pygobject_new((GObject*)provider),
py_handle,
pyg_boxed_new(G_TYPE_CLOSURE, update_complete, TRUE, TRUE),
- pygobject_new((GObject*)file));
+ pygobject_new((GObject*)file_info));
}
else if (PyObject_HasAttrString(object->instance, "update_file_info")) {
py_ret = PyObject_CallMethod(object->instance,
METHOD_PREFIX METHOD_NAME, "(N)",
- pygobject_new((GObject*)file));
+ pygobject_new((GObject*)file_info));
}
else {
goto beach;
@@ -434,7 +434,7 @@ nautilus_python_object_update_file_info
#endif
beach:
-free_pygobject_data(file, NULL);
+free_pygobject_data(file_info, NULL);
Py_XDECREF(py_ret);
pyg_gil_state_release(state);
return ret;
--- nautilus-python-1.2.3.orig/src/nautilus-python.c
+++ nautilus-python-1.2.3/src/nautilus-python.c
@@ -22,6 +22,7 @@
#endif
#include
+#define NO_IMPORT_PYGOBJECT //To avoid a multiple definition, nautilus-python-object.c also includes and does the import.
#include
#include
#include
--- nautilus-python-1.2.3.orig/src/nautilus-python.h
+++ nautilus-python-1.2.3/src/nautilus-python.h
@@ -43,37 +43,37 @@ extern NautilusPythonDebug nautilus_pyth
#define debug_enter_args(x, y) { if (nautilus_python_debug & NAUTILUS_PYTHON_DEBUG_MISC) \
g_printf("%s: entered " x "\n", __FUNCTION__, y); }
-PyTypeObject *_PyGtkWidget_Type;
+static PyTypeObject *_PyGtkWidget_Type;
#define PyGtkWidget_Type (*_PyGtkWidget_Type)
-PyTypeObject *_PyNautilusColumn_Type;
+static PyTypeObject *_PyNautilusColumn_Type;
#define PyNautilusColumn_Type (*_PyNautilusColumn_Type)
-PyTypeObject *_PyNautilusColumnProvider_Type;
+static PyTypeObject *_PyNautilusColumnProvider_Type;
#define PyNautilusColumnProvider_Type (*_PyNautilusColumnProvider_Type)
-PyTypeObject *_PyNautilusInfoProvider_Type;
+static PyTypeObject *_PyNautilusInfoProvider_Type;
#define PyNautilusInfoProvider_Type (*_PyNautilusInfoProvider_Type)
-PyTypeObject *_PyNautilusLocationWidgetProvider_Type;
+static PyTypeObject *_PyNautilusLocationWidgetProvider_Type;
#define PyNautilusLocationWidgetProvider_Type (*_PyNautilusLocationWidgetProvider_Type)
-PyTypeObject *_PyNautilusMenu_Type;
+static PyTypeObject *_PyNautilusMenu_Type;
#define PyNautilusMenu_Type (*_PyNautilusMenu_Type)
-PyTypeObject *_PyNautilusMenuItem_Type;
+static PyTypeObject *_PyNautilusMenuItem_Type;
#define PyNautilusMenuItem_Type (*_PyNautilusMenuItem_Type)
-PyTypeObject *_PyNautilusMenuProvider_Type;
+static PyTypeObject *_PyNautilusMenuProvider_Type;
#define PyNautilusMenuProvider_Type (*_PyNautilusMenuProvider_Type)
-PyTypeObject *_PyNautilusPropertyPage_Type;
+static PyTypeObject *_PyNautilusPropertyPage_Type;
#define PyNautilusPropertyPage_Type (*_PyNautilusPropertyPage_Type)
-PyTypeObject *_PyNautilusPropertyPageProvider_Type;
+static PyTypeObject *_PyNaut
Bug#737658: some notes on util-linux takeover of eject
Control: affects -1 eject Hi, On Mon, May 04, 2020 at 12:08:10PM +0200, Chris Hofstaedtler wrote: > Hi everyone, > > (Adding CC: mpitt@, as the dmcrypt-get-device author.) > > * atzlinux 肖盛文 [200504 05:16]: > > Hi Chris, > > > > 在 2020/5/4 上午6:09, Chris Hofstaedtler 写道: > > > Hi xiao sheng wen, > > > > > > I've noticed you've recently taken over maintenance of the eject > > > package, after it was unmaintained for years. > > > > > > Probably unbeknownst to you, plans were made to replace the eject > > > (and eject-udeb) packages with code from util-linux. > > > > I didn't know this plan before,I can't get this info from the RFA > > bugreport of eject(#92). > > Yeah. Sorry about that. FWIW this bug report was originally assigned to the eject package, but someone reassigned it over to util-linux when they thought it was up to util-linux to implement the solution. Unfortunately there was no "affects" set up which would have made it show up on both sides. Thus my (too late) attempt at doing so at the top of this message now to make the bug report show up in the bug tracker for both packages. (I guess at the time noone thought it would take this long to get this issue fixed and that anyone else would need to be brought into the loop before we had this issue squashed.) > > > > I understand that it must be somewhat soul-crushing when this > > > happens, so I wanted to loop you in. > > > > Never mind! Thanks for loop me in. > > > > I'm just learning packaging .I hope contribute to Debian,let Debian > > become more better. > > > > > Do you think it's alright if we move forward with replacing the old, > > > dead-upstream eject with the code from util-linux? > > > > The eject upstream git repo is [1],from the log ,I know the lasted > > commit[2] is on Aug 21 21:42:30 2019. > > > > Is this a dead-upstream? > > Doesn't look dead now, no, but it certainly was for a long time. > See below for a bit more. No matter if its dead or not, other (well known) distributions use the util-linux implementation. The questions I think we need to ask ourselves are: Whats the purpose of deviating from other distros? Why can't we have a single upstream source and work together? What's the value-add in using different implementations? The value in everyone using the same implementation is quite easy to answer: Scripts and other users of the program automatically is (more) portable between different distributions. > > > > My plan would be to take over the eject, eject-udeb packages sometime > > > next week (obviously going through NEW, so maybe a bit later). > > > > I'd read the bug #737658,from this bugreport,I learned more info about > > udeb,d-i,etc. :-) > > > > IMHO,I had a little worry about commands: volname and > > dmcrypt-get-device(suid). > > > > volname is still used by dkopp[3]. > > Right. So: > > 1) who is using dmcrypt-get-device, and why does it exist in the > first place? Martin, can you shed some light on this? > I can't find anything using it (via codesearch.debian.net); I'm > guessing this was used for/by udev a long time ago, but that can use > any of the libraries directly? I don't know the original user for this either, but AIUI it's definitely deprecated now and should be safe to get rid of. > > 2) volname apparently uses knowledge about ISO9660 directly, and > personally I'd rather see users use blkid instead, like so: > /usr/sbin/blkid -s LABEL ./debian-10.3.0-amd64-netinst.iso > ./debian-10.3.0-amd64-netinst.iso: LABEL="Debian 10.3.0 amd64 n" > (This works for anything that's got a label, not just ISO9660 > files/devices.) > I can try a minimal patch to dkopp. (Also dkopp doesn't depend on > eject -- how did you find this?) ... and as soon as someone brings up blkid I can't help but mention that lsblk is the modern replacement (although not available in udeb). > > > After the replace plan finished,Are these two commands will disappear in > > Debian 11 ? > > > > If has one shell scripts used these two commands in Debian 10,when the > > OS update to Debian 11, > > > > Do the shell scripts need to modify?How to modify? > > blkid can be used to replace volname; not sure if a replacement for > crypt-dev-device is actually needed? > > I'd really like to see us move away from Debian-specific tools, > especially if they're undocumented and/or have security impact. > While the tools shipped in util-linux are sometimes not great, I > think util-linux's upstream is in a way better situation, with a lot > more willing helping hands (and eyes, too). Agreed. And more eyes/help is welcome. Atleast the upstream util-linux project is quite nice to get involved with if you're interested. > > Best, > Chris > Regards, Andreas Henriksson
Bug#826328: util-linux: losetup -d disfunctional for cloop and similar loop-compatible block devices
Hi, On Sun, May 03, 2020 at 11:23:45PM +0200, Prof. Dipl.-Ing. Klaus Knopper wrote: > Hello Chris, > > /me of little patience gave up (maybe too early), and continue to use [...] FWIW my suggestion for you to contact upstream was not simply a way to push this away from being my problem, but I honestly think this is the best way to get the issue solved. The util-linux upstream developers are good at being solution focused and happy to implement things. It should help that you have a good description of both the use-case and example commands. So if you have any motivation to ever see this solved on the util-linux side I would again warmly recommend that you directly contact upstream in case they have any followup questions for you (and because using any middle man as a messenger will just be extra annoyance for all involved parties). Someone else could have the discussion with upstream but then there's always the possibility that it solves one issue without fulfilling all your needs. It's better to take up any additional issues directly while the discussion is already ongoing to get your use-case fully covered. Any way I'm happy to know that you have a usable work-around in the meantime. Regards, Andreas Henriksson
Bug#583958: pam_umask --enable-usergroups compile-time option
Hi Chris, On Sun, May 03, 2020 at 10:10:48PM +0200, Chris Hofstaedtler wrote: > * Andreas Henriksson : > > Given almost 2 months has passed without a comment I assume it's > > up to me to NMU the changes, which I'll be doing if I don't > > hear anything in the next couple of weeks. > > Subtle ping? (No need to be subtle towards me atleast.) I should probably get this done, but apart from lacking motivation there are possibly some other things to consider for a NMU. - there are several open issues that each by themselves possibly motivaties a NMU. How many of them should be bulked together? How many should be left out? See eg. #948188 (xcrypt support), #674857 (securetty warnings in default configuration), etc, etc - Should we bother backporting patches, upload a snapshot, or wait for a new release? Up until recently I would have claimed waiting for a new release is pointless, but recently there has actually been some signs that upstream is willing to do a release - apparently they are now (only?) waiting for translation updates to happen. [1] Hopefully the release actually happens before bullseye freeze, but maybe I'm just being too optimistic about ever seeing a new upstream release of pam. - I guess I should also mention the possibility for different interpretation of this bug report. I personally only care about "sane defaults" (as I doubt anyone really cares to override the distro-default setting). Others however might more strongly care about how the setting is configured, which IMNSHO is what this bug report derailed and was misinterpretted into being discussed (and subsequentially caused it to linger for a decade). Finally all above discussion points are IMO just symptoms of the lack of maintenance. There has previously been discussion with someone who had been willing to maintain pam outside of debian for years who I thought would be good to recruit instead of push away like this, but there where no input and when we finally discussed starting the salvaging process there where strong objections from current maintainers.[2] I'm not sure how to proceed or if I even want to dig up the motivation for it, so if someone feels they want to go ahead then don't hold your breath waiting for me. Just do it! I would love to see this (and possibly other) issues finally fixed before bullseye freeze. Some feedback to the above mentioned points from anyone who has the time to consider the overall picture could possibly also go a long way for motivating me into proceeding myself. Regards, Andreas Henriksson [1]: https://github.com/linux-pam/linux-pam/issues/141#issuecomment-595121614 [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=821408#37
Bug#958668: u-boot: Please consider enabling rpi4 support
Hello Vagrant and Lucas, On Fri, Apr 24, 2020 at 04:21:01PM -0700, Vagrant Cascadian wrote: > On 2020-04-24, Andreas Henriksson wrote: > > Please consider building the rpi4 (32 and 64bit) version of u-boot > > for the u-boot-rpi package. Patch attached for your convenience (which > > was only build-tested for arm64 target so far). > > If you or someone else can commit to testing updates semi-regularly: > > https://wiki.debian.org/U-boot/ > https://wiki.debian.org/U-boot/Status > > Then list the person in the debian/targets files with name and contact > info in an updated patch. I personally can't commit to it at this moment because I simply haven't got the hardware (yet). It seems Lucas Nussbaum has already been working on building debian images[1][2] for rpi4, so maybe he can volunteer for now? It seems from comments he has already done exactly as the previously proposed patch and tested it. (I also assume that any rpi will be common enough that once available bug reports will be coming if it breaks.) Regards, Andreas Henriksson [1]: https://salsa.debian.org/raspi-team/image-specs/-/compare/master...rpi4 [2]: https://wiki.debian.org/RaspberryPi4
Bug#958668: u-boot: Please consider enabling rpi4 support
Source: u-boot Version: 2020.04+dfsg-2 Severity: wishlist Dear Maintainer, Please consider building the rpi4 (32 and 64bit) version of u-boot for the u-boot-rpi package. Patch attached for your convenience (which was only build-tested for arm64 target so far). Regards, Andreas Henriksson diff --git a/debian/targets b/debian/targets index b703fb3239..f83bb63685 100644 --- a/debian/targets +++ b/debian/targets @@ -90,6 +90,8 @@ armhf rpi rpi_2 u-boot.bin # Ryan Finnie armhf rpi rpi_3_32b u-boot.bin +armhf rpi rpi_4_32b u-boot.bin + # Christian Kastner armhf sunxi A10-OLinuXino-Lime u-boot-sunxi-with-spl.bin @@ -213,6 +215,8 @@ arm64 rockchiprock-pi-4-rk3399 /usr/lib/arm-trusted-firmware/rk3399/bl3 # Ryan Finnie arm64 rpi rpi_3 u-boot.bin +arm64 rpi rpi_4 u-boot.bin + # Rodrigo Exterckötter Tjäder arm64 sunxi a64-olinuxino /usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin u-boot.bin spl/sunxi-spl.bin u-boot-nodtb.bin arch/arm/dts/sun50i-a64-olinuxino.dtb u-boot.itb
Bug#947454: util-linux: su man page is confusing wih regard to - -l and --login
Control: tags -1 + wontfix upstream Hello anna, Thanks for your bug report. On Fri, Dec 27, 2019 at 01:02:41AM -0500, anna wrote: [...] > The man page for su says the following: "It is recommended to always > use the --login option (instead of its shortcut -)". > To me that doesn't make sense, they should be equivalent, and this is > confirmed (and adds to the confusion) when I scroll down and the > options -, -l, and --login are all listed as doing the exact same > things. They are equivalent. A different wording might be: "using GNU style command line options are recommended", without also saying "non-GNU style command line options are deprecated and might be removed at some point" ... because 'su -' is just to widespread both among users, scripts and online writings so that even though parsing would be greatly simplified without the legacy alternative it's likely not practically possible to drop it, fix everything and retrain users. Many people doesn't even know about the GNU style alternative to the legacy '-' option that exists for compatibility with legacy UNIX, which I guess is why the man-page makes an attempt to start educating people even though it seems quite a futile task. I'm marking this as wonfix, because I don't really see a problem with the current writing and even if there was this something which should be discussed and changed upstream if it should be changed. IOW it's not a debian-specific problem. Regards, Andreas Henriksson
Bug#948915: util-linux: su -s bash completion broken
Control: retitle -1 util-linux: su -s bash completion broken with chsh from src:shadow Control: tags -1 + confirmed Hello Gabriel Paradzik, Thanks for your bug report. On Tue, Jan 14, 2020 at 04:46:16PM +0100, Gabriel Paradzik wrote: > Package: util-linux > Version: 2.33.1-0.1 > Severity: normal > > Dear Maintainer, > > using the bash completion on "su -s" shows the following: > > # su -s chsh: invalid option -- 'l' > Usage: chsh [options] [LOGIN] > > Options: > -h, --helpdisplay this help message and exit > -R, --root CHROOT_DIR directory to chroot into > -s, --shell SHELL new login shell for the user account > > It seems the chsh utility doesn't have a -l option any more. [...] Actually it's the other way around. We switched su and the su bash completion from src:shadow to src:util-linux implementation. We still use the chsh implementation from src:shadow (see #833256 ) and apparently the -l option only exists in the src:util-linux implementation of chsh. Switching to util-linux implementation of chsh et.al. will fix this issue, but unfortunately the work on that is lacking momentum at the moment. If someone cares enough about this issue they might want to change the bash completion to detect src:shadow chsh and work correctly with it if detected, but I would not be completely surprised if upstream is not super keen on carrying this change (even though they normally accept most patches submitted). Regards, Andreas Henriksson
Bug#948166: blkid -t treats UUIDs as case-sensitive
Control: tags -1 + upstream Hello Josh Triplett, Thanks for your bug report. On Sat, Jan 04, 2020 at 12:44:51PM -0800, Josh Triplett wrote: > Just spent a while debugging a boot issue caused by blkid treating UUIDs > as case-sensitive: > > Gave up waiting for root file system device. Common problems: > - Boot args (cat /proc/cmdline) >- Check rootdelay= (did the system wait long enough?) > - Missing modules (cat /proc/modules; ls /dev) > ALERT! PARTUUID=5D75BD2D-6C59-4F73-9762-F4025CA97033 does not exist. > Dropping to a shell! > (initramfs) blkid -l -t PARTUUID=5D75BD2D-6C59-4F73-9762-F4025CA97033 -o > device > (initramfs) blkid > /dev/vda1: UUID="83d14a86-02e0-4d48-abda-53b4ed66c8e0" TYPE="ext4" > PARTUUID="5d75bd2d-6c59-4f73-9762-f4025ca97033" > (initramfs) blkid -l -t PARTUUID=5d75bd2d-6c59-4f73-9762-f4025ca97033 -o > device > /dev/vda1 > > I would normally expect a string of hexadecimal to not care about the > case of the a-f digits. Either this needs documenting somewhere, or it > needs fixing in blkid. Please feel free to report this as an issue to upstream[1]. However you might also want to note that blkid is in deep maintenance mode as it has been superseeded by the more easily extendable lsblk utility. Maybe it would thus be better to consider reporting this as a wishlist bug against initramfs-tools (and consider its current usage of blkid as an implementation detail that possibly could be changed to fix this). Regards, Andreas Henriksson [1]: https://github.com/karelzak/util-linux/issues or mailinglist on vger.kernel.org
Bug#957398: kbd gcc-10 / version.h fixed upstream
Control: tags -1 + fixed-upstream Hi, This problem should be fixed upstream in commit 12c4be5d (which apart from renaming the header file also adds include guards to avoid including the same code multiple times). In other words simply updating to >= v2.0.90 should solve this problem. Regards, Andreas Henriksson
Bug#956457: Enable wired authentication service
Hello Lars Beckers, Thanks for your bug report. On Sat, Apr 11, 2020 at 04:58:08PM +0200, Lars Beckers wrote: > Package: iwd > Version: 1.6-1 > Severity: wishlist > > Dear Maintainer, > > `iwd' provides a separate daemon, called `ead', for authentication on > wired interfaces. One can use it e.g. with FreeRADIUS to secure access > to a LAN. `wpa_supplicant' offers similar functionality. FWIW I'm personally well aware of ead and its functionality. > > Due to the software maintainer's primary focus on wireless, > this feature was not yet declared a standard part and thus needs a > special build-time switch to be set. My request is that you enable it. I personally have no need/use for ead. I expect someone who does to take care of it. Not only by sending an initial patch, but also offer to take on the maintenance (as co-maintainer of the package?). > > Because `ead' is a separate daemon, enabling this feature won't affect > the stability of the wireless daemon for current users of this package. > The README file of the project advises that the configuration option > `--enable-wired' enables this feature. It does not advise against > enabling it, but calls it "optional". Whoever looks into this should also want to consider the pros and cons of splitting iwd and ead in separate binary packages or not. Regards, Andreas Henriksson
Bug#956200: gimp: remove old-style config script `libwmf-config'
Control: tags -1 + patch upstream I quickly looked into the gimp/libwmf-config issue and it should be easy to solve. Attaching a completely untested patch, than simply copy-pastes a couple of lines from a different conditional-path a few lines above. (Previously the pkg-config file would only be used if libwmf-config exists and expr to evaluate version returned by script being new enough failed.) If someone could verify the patch actually works, it would be good if this patch is also forwarded upstream. Regards, Andreas Henriksson From: Andreas Henriksson Subject: Also attempt pkg-config if libwmf-config doesn't exist at all. Possibly things should be refactored to *first* try pkg-config and then fall back on looking for the libwmf-config script, but this is the minimal change to fix the case when we only have libwmf.pc without libwmf-config. See semi-related https://gitlab.gnome.org/GNOME/gimp/-/issues/2454 See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956183 See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956200 --- a/configure.ac +++ b/configure.ac @@ -2058,7 +2058,10 @@ have_libwmf="no (libwmf not found)") fi else -have_libwmf="no (libwmf not found)" +have_libwmf=yes +PKG_CHECK_MODULES(WMF, libwmf >= wmf_required_version, + FILE_WMF='file-wmf$(EXEEXT)', + have_libwmf="no (libwmf not found)") fi fi
Bug#851747: sysvinit_2.96-2.2_source.changes ACCEPTED into unstable
On Fri, Mar 20, 2020 at 01:33:49AM +0100, Adam Borowski wrote: > On Fri, Mar 20, 2020 at 01:24:31AM +0100, Andreas Henriksson wrote: > > I expect you to take care of this bug and others if you're now going to > > pretent to maintain this package! > > You demand a change that requires a lot of work all around the archive, I've already proven this is a bullshit excuse. Read the actual bug report content. > without providing any reason _why_. Section 3.8 can be read here: https://www.debian.org/doc/debian-policy/ch-binary.html#essential-packages See also third paragraph of 3.5. Regards, Andreas Henriksson
Bug#851747: sysvinit_2.96-2.2_source.changes ACCEPTED into unstable
On Thu, Mar 19, 2020 at 11:58:37PM +0100, Adam Borowski wrote:
> On Thu, Mar 19, 2020 at 10:24:53PM +, Debian FTP Masters wrote:
> > Accepted:
>
> > sysvinit (2.96-2.2) unstable; urgency=medium
> > .
> >* Non-maintainer upload.
> >* Drop 'Essential: yes' from sysvinit-utils (Closes: #851747)
>
> WTF.
Indeed!
>
> Could you please re-read the Developer's Reference, the section on doing
> NMUs? While there are cases when small, helpful changes are not worth the
> full machinery, one that introduces (rather than fixes) a severity:critical
> bug ("breaks unrelated packages") is definitely not there.
Where's the breakage?! Please read the bug report feedback I've sent
extensive information about every possible case even for lowering
Priority to important, which was not done.
>
> And, both Thorsten and me just told you to not rush.
Date: Wed, 18 Jan 2017 12:48:33 +
This has now been extensively discussed for over 3 years! Where's the
rush? Where's the useful input from the so called maintainers?
>
> Fortunately, there was an upload race (one of the things that the NMU rules
> prevent) and -3 wins over -2.2 thus we won't have to revert. But still...
I expect you to take care of this bug and others if you're now going to
pretent to maintain this package! The NMU was annouces weeks in advance
so there's nothing 'fortunate' about mid air collisions and
force-pushing to the public git repo.
Regards,
Andreas Henriksson
Bug#872118: mdadm: fdisk build-dependency needed (for tests)
Hi, I've quickly looked at this again and I'm not unsure if an fdisk build-dependency really is needed (for tests). The tests/07autodetect file uses sfdisk, this file seems to potentially get executed from ./test The Makefile has a test target, but that only echos out to run ./test as root and doesn't actually run it. It thus doesn't look to me like the 07autodetect test is actually run during a normal build. Invoking the ./test suite seems to be something (only) manually done, so maybe there's no need for a (build-)dependency after all Regards, Andreas Henriksson
Bug#954306: sysvinit-utils: consider lowering the Priority of sysvinit-utils to important or even optional
On Thu, Mar 19, 2020 at 10:40:03PM +0100, Andreas Henriksson wrote: [...] > Note that (some of the) bug reports that should possibly be marked as > blockers for this has been filed, see: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851747#126 [...] > pidof should be moved to procps package (which is Priority: important). > This is the only widely used tool which probably deserves to stay in the > 'important' set. [...] > Someone might have to figure out if entangling the pidof transition with > the Priority lowering is beneficial or if it's better to keep these > issues separate. Please note that sysvinit-utils doesn't qualify in the Priority required set as defined by policy[1] and previously demonstrated[2]. The previously mentioned potential blockers for this are as I see it mainly for "theoretical correctness", even if pidof stays in sysvinit-utils package. So someone might have to make the call on which theoreticall correctness is more impontant. While ofcourse it would be ultimate if someone volunteered to fix every theoretical issue, I think people likely have better things to spend their time on and thus someone will have to decide which is worse: - sysvinit-utils not being lowered to Priority: important and thus technically violating Policy. vs - a few packages missing dependencies (or better solution). Any "normal" installation will have all Priority: important packages installed anyway (and those with special-case debootstraps likely can be expected to figure things out on their own). I'd think lowering to Priority: optional (while still keeping pidof in sysvinit-utils package) would be more "interesting" though, thus my previous recommendation to move pidof to procps keeping it important while moving the rest of sysvinit-utils package to Priority: optional. My opinion is thus that moving to Priority: important should happen ASAP (while moving to Priority: optional would need a bit more thought), but others might disagree? Input welcome. Regards, Andreas Henriksson [1]: Chapter 2.5 Priorities - https://www.debian.org/doc/debian-policy/ch-archive.html#priorities [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851747#76
Bug#851747: sysvinit-utils: drop Essential flag
FYI I've filed https://bugs.debian.org/954306 to track the potential adjustment of the Priority: field, which seems to be the majority of the discussion in this bug report. I'm about to upload an NMU of sysvinit which drops the 'Essential: yes' from sysvinit-utils - but still keeps 'Priority: required' unchanged (and closing this bug report while doing so) for now. Regards, Andreas Henriksson
Bug#954306: sysvinit-utils: consider lowering the Priority of sysvinit-utils to important or even optional
Package: sysvinit-utils Version: 2.96-2 Severity: wishlist Dear Maintainer, Please consider lowering the 'Priority: required' on the sysvinit-utils to something lower, eg. important or even optional. To be able to lower to important without breakage there are likely a number of issues that has to be resolved first. These has previously been discussed in the bug report that was opened about making sysvinit-utils non-Essential (#851747) which has alot of discussion also related to a potential future priority decrease which I'm now opening this bug report about. A summary of the discussion: * Packages which ships an init scripts not masked by a systemd unit that uses /lib/init/init-d-script or /lib/init/vars.sh - preferable solution would be to ship a masking native systemd unit - Note: watch out for service files wrapping the init script! (lintian tag 'systemd-service-file-wraps-init-script') * Users of /sbin/fstab-decode (if any) * Users of /bin/pidof - consider potentially moving/using the procps pidof implementation. See #810018 * Users of killall5 (if any) Note that (some of the) bug reports that should possibly be marked as blockers for this has been filed, see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851747#126 I think to be able to accomplish lowering to Priority: optional likely pidof should be moved to procps package (which is Priority: important). This is the only widely used tool which probably deserves to stay in the 'important' set. (Also using the procps implementation of pidof would mean we get rid of a pointless difference, as it seems basically every other major linux distribution is using the procps implementation.) I think if users of pidof start adding dependencies on sysvinit-utils and it later gets moved to a different package there will be much useless churn. A possible workaround for this could be to add a virtual package 'pidof' that is provided by sysvinit-utils until pidof is actually moved to procps and then procps provides the virtual pidof package, while asking users to depend on pidof virtual package. This might be overkill though. Someone might have to figure out if entangling the pidof transition with the Priority lowering is beneficial or if it's better to keep these issues separate. Regards, Andreas Henriksson
Bug#885813: bumping severity of xfce4-notes-plugin's use of libunique to Serious
Hi, On Wed, Oct 09, 2019 at 05:34:16PM +0200, Yves-Alexis Perez wrote: > Hi, thanks for the update. It seems that the GTK3 port isn't really complete. > And it seems notes isn't really maintained upstream anymore. I'm adding Mike > to the CC but we might end up completely dropping xfce4-notes-plugin from > Debian in the end. There doesn't seem to have been any movement since your comment on the upstream bug report. The xfce4-notes-plugin is now the only remaining package in unstable that still depends on libunique, so it looks to me like it might be time to make the final call on this. What do you think? I'd really like to finally be able to remove libunique. If your decision is we need to drop xfce4-notes-plugin then it seems xfce4-goodies metapackage will need its dependency removed, then we can request the other removals! I'm happy to send salsa merge-request and/or do NMU if you are busy. Regards, Andreas Henriksson
Bug#948895: neomutt: FTBFS: test failure
Hello, On Thu, Mar 12, 2020 at 05:25:50PM -0700, Stefano Rivera wrote: > Control: reopen -1 > Control: notfixed -1 20191207+dfsg.1-1 [...] If you're going to claim neomutt still FTBFS despite what https://buildd.debian.org/status/package.php?p=neomutt says, then I think you could atleast provide a build log backing up your claim. (And even with that I'd personally likely not agree with your claim that FTBFS on anything but official buildd is RC severity, but that's up to the neomutt maintainers to finally decide on I guess.) (IOW Please don't repurpose old bug reports when new ones are free.) Regards, Andreas Henriksson
Bug#950990: neomutt: New upstream release (20191207)
Hello, On Thu, Mar 12, 2020 at 05:46:00PM -0700, Stefano Rivera wrote: [...] > Err, why don't you have the original repo? My original repo, where I did this work originally. As described in my original mail. Where some dude refered to having successfully built from (despite I never pushed anything publicly)! > It's public: https://salsa.debian.org/mutt-team/neomutt > > I'd suggest rebasing your changes onto that. You're confused. There's nothing that needs rebasing. Neomutt maintainers can fast-forward merge my repo if they desire. Regards, Andreas Henriksson
Bug#851747: sysvinit-utils: drop Essential flag
On Sat, Feb 08, 2020 at 07:23:32PM +0100, Andreas Henriksson wrote:
> Hello,
>
> Regarding the previous discussion about packages with init scripts
> that source /lib/init/vars.sh
[...]
As a followup on this I've now also (re)checked all users of
init-d-script for the current status. (I consider both the vars.sh and
init-d-script usage issues mostly relevant to potentially adjusting
Priority of sysvinit-utils package, rather than being Essential: yes.)
TL;DR very few relevant packages, specially if only considering ones
relevant for bullseye/testing.
Method:
I used codesearch.debian.net searching for init-d-script
and got 73 total source packages matching.
I excluded src:sysvinit and src:systemd as they should not be relevant
for this examination, so 71 source packages remaining.
I downloaded all those source packages, checked their debian/control
for binary packages and downloaded those from unstable.
I then examined the binary packages for existance of etc/init.d/*
content and checked if etc/init.d/foo has a matching
systemd/system/foo.service.
Here's my annotated results for the ones that did not have
a masking systemd service (according to my naive search):
=== axfrdns_1%3a1.05-10_amd64.deb.txt
# NOTE: src:djbdns (never in testing, migration blocked)
axfrdns
=== bcron_0.11-8_amd64.deb.txt
bcron-sched
bcron-spool
bcron-update
=== courier-imap_5.0.6+1.0.6-1+b2_amd64.deb.txt
courier-imap-ssl
=== courier-mta_1.0.6-1+b2_amd64.deb.txt
courier
courier-msa
courier-mta-ssl
courierfilter
=== courier-pop_1.0.6-1+b2_amd64.deb.txt
courier-pop-ssl
=== dnscache_1%3a1.05-10_amd64.deb.txt
# NOTE: src:djbdns (never in testing, migration blocked)
dnscache
=== jitterentropy-rngd_1.1.0-1_amd64.deb.txt
# NOTE: false-positive -- jittenentropy.service has Also=
jitterentropy-rngd
=== mtail_3.0.0~rc24.1-1_amd64.deb.txt
# See #886894
mtail
=== netplan_1.10.1-6_amd64.deb.txt
# NOTE: not in testing, orphaned
netplan
=== opentmpfiles_0.2+2019.05.21.git.44a55796ba-2_all.deb.txt
# NOTE: Not relevant for systemd (and others?)?
opentmpfiles-clean
opentmpfiles-setup
opentmpfiles-setup-dev
=== procps_2%3a3.3.16-4_amd64.deb.txt
# NOTE: false-positive -- actually masked
procps
=== rbldns_1%3a1.05-10_amd64.deb.txt
# NOTE: src:djbdns (never in testing, migration blocked)
rbldns
=== shishi-kdc_1.0.2-7_amd64.deb.txt
shishi-kdc
=== tinydns_1%3a1.05-10_amd64.deb.txt
# NOTE: src:djbdns (never in testing, migration blocked)
tinydns
=== uwsgi-emperor_2.0.18-8_amd64.deb.txt
uwsgi-emperor
=== uwsgi_2.0.18-8_amd64.deb.txt
# See #833067
uwsgi
=== walldns_1%3a1.05-10_amd64.deb.txt
# NOTE: src:djbdns (never in testing, migration blocked)
walldns
Relevant popcon link:
https://qa.debian.org/popcon-graph.php?packages=shishi-kdc%2Cbcron%2Ccourier-imap%2Ccourier-mta%2Ccourier-pop%2Cjitterentropy-rngd%2Cmtail%2Cuwsgi-emperor%2Cuwsgi%2Copentmpfiles_installed=on_legend=on_ticks=on_date=_date=_date=_fmt=%25Y-%25m=1
(Relevant packages according to popcon: courier-{imap,pop} and uwsgi)
Regards,
Andreas Henriksson
Bug#953738: RM: plan -- RoQA; orphaned and former maintainer want security committment
Package: ftp.debian.org Severity: normal Hello, See #916508 for the situation where former maintainer filed and RC bug against his own package before orphaning it to request that someone commits to do security support for this package if it should be included in buster, bullseye, Noone has stepped up so far (and I bet noone will), so why not file a proper RM request for it If anyone is willing to take on this package they can always revive it from snapshot.debian.org. Regards, Andreas Henriksson
Bug#936191: python2 rm in bcron
Hi, Happened to stumble upon this one and it looked easy to fix so I did that based on the source tarball. Figured I should redo it based on the packaging git repo and was confused that there apparently already exists a new version that never made it into the archive that already had this issue fixed. I'll proceed to actually upload the version already marked as released in git. Regards, Andreas Henriksson
Bug#953392: lintian-brush: Fixer 'missing-build-dependency-for-dh_-command' failed to run.
Package: lintian-brush
Version: 0.58
Severity: normal
Dear Maintainer,
Just thought I'd report FYI that while running lintian-brush on the
mender-artifact package I got this (verbose) output:
Fixer 'missing-build-dependency-for-dh_-command' failed to run.
Script
/usr/share/lintian-brush/fixers/missing-build-dependency-for-dh_-command.py
failed with exit code: 1
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/lintian_brush/__init__.py", line 269, in
run
exec(code, global_vars)
File
"/usr/share/lintian-brush/fixers/missing-build-dependency-for-dh_-command.py",
line 37, in
executable = shlex.split(command.decode('utf-8', 'replace'))[0]
IndexError: list index out of range
Regards,
Andreas Henriksson
Bug#953391: lintian-brush: support converting dh --with foo (addon) to dh-sequence-foo
Package: lintian-brush
Version: 0.59
Severity: wishlist
Dear Maintainer,
Please consider adding a fixer that can convert old-style (WET)
'dh $@ --with foo' to new-style dh-sequence-foo for the addons
that support the new (DRY) style of hooking in addons to the
dh sequencer[1] (when using debhelper >= 12).
Please also make sure to drop the old build-dependency that is no longer
needed when using the dh-sequence-* virtual package as build-dependency.
(This might be difficult to do correctly as there might be other reasons
why keeping the build-dep around is the correct thing to do sometimes?)
For example in the Debian Gnome Team the gir and gnome addons are
commonly used and both of them support dh-sequence-{gir,gnome}
virtual package style nowadays provided by gobject-introspection
and gnome-pkg-tools binary packages respectively.
eg. a package that still needs this conversion is gnome-autoar.
(And while looking at this packages debian/rules it might be nice to
have simple cleanups that detects when some of the overrides can be
dropped once they've become the default in future debhelper compat
levels, like 'dh_missing --fail-missing' and 'dh_makeshlibs -- -c4'
will at some point in the future.)
Regards,
Andreas Henriksson
[1]:
https://nthykier.wordpress.com/2019/01/04/debhelper-compat-12-is-now-released/
Bug#953370: RM: badger [armel armhf i386] -- ROM; 32bit archs not supported
Package: ftp.debian.org Severity: normal Hello! Please remove the binaries built from src:badger for all 32bit archs. The binary package names are: badge golang-github-dgraph-io-badger-dev The (release) archs that should get targeted for removal are: armel armhf i386 Extended removal reason: In 2.0.1-4 I included a bunch of patches that made badger not only build but also pass its own testsuite on 32bit architectures. This was a mistake on my side, because I later realized that the trivial patches I created doesn't actually make badger practically usable on 32bit archs - as badger is usually built into another application and if that application does any memory allocations then badger will not work. A non-trivial amount of work is needed to accomplish that and I just don't have the time needed to invest in that work and it seems upstream doesn't currently have interest in this either at the moment (either internally or from external contributors). Regards, Andreas Henriksson
Bug#953227: garagemq: autopkgtest failure: github.com/valinurovam/garagemq/srvstorage [no test files]
Control: tags -1 + help Hello Paul Gevers, Thanks for your bug report. On Fri, Mar 06, 2020 at 09:25:22AM +0100, Paul Gevers wrote: > Source: garagemq > Version: 0.0~git20200204.15e6a9d+ds-1 > X-Debbugs-CC: debian...@lists.debian.org > Severity: serious > User: debian...@lists.debian.org > Usertags: fails-always > > Dear maintainers, > > Your new pacakge garagemq has an autopkgtest, great. However, it fails > on amd64 (but passes on arm64). I copied some of the output at the > bottom of this report. > > Currently this regression is blocking the migration to testing [1]. Can > you please investigate the situation and fix it? Sorry, but I have no idea what's going on here. Some reflections: a/ I can't spot any test that's actually failing! (They all seem to report PASS.) Yet somehow the exit code is 1. b/ I can *sometimes* reproduce the problem locally, but need a few things to trigger it: - test cache must be disabled - output must be to terminal (not redirected to file or piped) When running the tests like this I can trigger the problem 50% of the time: go test -count=1 -vet=off -v -p 2 github.com/valinurovam/garagemq/server (Note the '-count=1' to disable test cache.) Somehow something seems racy, but I don't know at all where to look (as I can't see one particular test actually fail). (I also have no particular knowledge about the go debhelper that hooks up the go tests to autopkgtest.) > > More information about this bug and the reason for filing it can be found on > https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation > > Paul > > [1] https://qa.debian.org/excuses.php?package=garagemq > > https://ci.debian.net/data/autopkgtest/testing/amd64/g/garagemq/4442139/log.gz > > === RUN Test_QueueDelete_Failed_QueueNotExists > badger 2020/03/03 04:17:38 INFO: All 0 tables opened in 0s > badger 2020/03/03 04:18:07 INFO: All 0 tables opened in 0s > FAIL github.com/valinurovam/garagemq/server 182.668s > ? github.com/valinurovam/garagemq/srvstorage [no test files] > ? github.com/valinurovam/garagemq/storage [no test files] > FAIL > dh_auto_test: error: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 2 > github.com/valinurovam/garagemq github.com/valinurovam/garagemq/admin > github.com/valinurovam/garagemq/amqp > github.com/valinurovam/garagemq/auth > github.com/valinurovam/garagemq/binding > github.com/valinurovam/garagemq/config > github.com/valinurovam/garagemq/consumer > github.com/valinurovam/garagemq/exchange > github.com/valinurovam/garagemq/interfaces > github.com/valinurovam/garagemq/metrics > github.com/valinurovam/garagemq/msgstorage > github.com/valinurovam/garagemq/pool > github.com/valinurovam/garagemq/protocol > github.com/valinurovam/garagemq/qos > github.com/valinurovam/garagemq/queue > github.com/valinurovam/garagemq/safequeue > github.com/valinurovam/garagemq/server > github.com/valinurovam/garagemq/srvstorage > github.com/valinurovam/garagemq/storage returned exit code 1 > make: *** [debian/rules:4: build] Error 25 > autopkgtest [04:18:31]: test dh-golang-autopkgtest: ---] > Regards, Andreas Henriksson
Bug#952199: golang-github-boltdb-bolt: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 4 -short github.com/boltdb/bolt github.com/boltdb/bolt/cmd/bolt returned exit code
See [1]: https://github.com/etcd-io/bbolt/commit/72c1660c13cb8cf0d590d91fb03625a68e53900f#diff-bc342dd6b7441ea82ac0a6367f21263a [2]: https://golang.org/doc/go1.13#testing Note for [1] that it should possibly be os.Exit(m.Run()) instead to exit with proper return code if a test fails. Regards, Andreas Henriksson
Bug#952188: golang-github-mendersoftware-scopestack: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 4 github.com/mendersoftware/scopestack returned exit code 1
On Mon, Mar 02, 2020 at 09:38:00AM +0100, Lluis Campos wrote: > Hello, > > The patch looks good to us. Thanks Andreas for following up! > > Side note. We have discussed internally and decided that we will remove > both scopestack and log[1] dependencies from the mender-client code. > This will ease maintenance of the Debian package :) Thanks for the feedback on the patch and the future roadmap! I'll upload the patched scopestack for now and will be looking forward to being able to request package removal later once new releases are out and we have everything updated. Regards, Andreas Henriksson
Bug#945442: Possible to backspace past beginning of string, which appears to be identical to having pressed Enter immediately, without any backspace
On Mon, Mar 02, 2020 at 02:57:02PM +0100, Andras Korn wrote: > > https://github.com/neomutt/neomutt/issues/2002 Thanks for the feedback. [...] > Your rationale for downgrading the severity of an issue like this is that it > doesn't bother you personally? My rationale, if you must know, is that if this is an important issue, then the people who consider it an important issue will ofcourse work on getting it fixed. There's nothing in debian policy (the document who defines the severity levels for the bug tracking system) that says 'If you raise the severity of a bug report then "someone else" has to do the work for you'. Scratch your own itch. The previously provided suggestion that this might lead to data loss is a bit far fetched if you ask me. Let a monkey hammer on your keyboard long enough and he'll eventually manage to do 'rm -rf ~' which doesn't necessarily imply that all terminal emulators must be removed from Debian. In other words, anything can be described as 'data loss' if your imagination is good enough. Regards, Andreas Henriksson
Bug#945442: Possible to backspace past beginning of string, which appears to be identical to having pressed Enter immediately, without any backspace
Control: found -1 20191207+dfsg.1-1 Hello, On Sun, Nov 24, 2019 at 11:10:33PM +0100, Andras Korn wrote: > Package: neomutt > Version: 2019+dfsg.1-1 > Severity: normal > > Hi, > > when mutt prompts for something (e.g. To: address, Subject etc.) it > previously was possibly to just keep pressing backspace until whatever > default text was there disappeared. > > As of this version, it's possible to keep erasing back beyond the first > character of the string; [...] On Fri, Feb 14, 2020 at 11:31:53AM -0500, Marvin Renich wrote: > Control: -1 severity grave > > I'm increasing the severity of this bug, as it can cause unintended [...] I just NMUed a new upstream version of neomutt, 20191207+dfsg.1-1, which fixes the two other outstanding RC bugs. It seems I can still reproduce this issue however (with the first prompt I get which is the imap password prompt for me). This seems somewhat like a possible UX design fail. This is done upstream and not in debian. Do you know if there's already been any discussion regarding this upstream? If not could you please file an upstream bug report about this? The behaviour hasn't really bothered me and I probably wouldn't even have noticed it if it wasn't for this bug showing up on the RC bug radar while doing my NMU, so I'm quite tempted to downgrade severity again. Please work this out with upstream if this issue is important to you. Please give feedback on this bug report about upstream discussions or relevant commits and I'm happy to look into cherry-picking and NMUing those as needed. Regards, Andreas Henriksson
Bug#950990: neomutt: New upstream release (20191207)
Hello, On Sun, Feb 09, 2020 at 11:48:58AM +0100, Andreas Henriksson wrote: > Package: neomutt > Version: 2019+dfsg.1-1 > Severity: wishlist > > Dear Maintainer, > > I've prepared an updated package for the new upstream release > (that fixes both of the open RC bugs) available at: > https://salsa.debian.org/ah/neomutt It seems the master branch is missing somehow. Maybe I screwed up pushing it. I don't have the original repo, but recretaded the changes from the old source package I had lying around here. I've now pushed my newly (re)created changes. > > Given that the neomutt package is soon about to be removed from > testing because of the RC bugs not being handled, I'm about to > NMU this very soon! I'm uploading this now. However there's an additional RC bug open now that will still block testing migration -> #945442 > > Your acknowledgement of the NMU or any other comments you might > have would be welcome. If you have any objections please speak > up *NOW*. Regards, Andreas Henriksson
Bug#952188: golang-github-mendersoftware-scopestack: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 4 github.com/mendersoftware/scopestack returned exit code 1
Hello,
On Sun, Feb 23, 2020 at 02:08:07PM +0100, Lucas Nussbaum wrote:
> Source: golang-github-mendersoftware-scopestack
> Version: 0.0~git20180403.c2f5599-2
[...]
> > === RUN TestPushPopNotInSameFunction
> > --- FAIL: TestPushPopNotInSameFunction (0.00s)
> > scope_stack_test.go:57: Should never get here
> > scope_stack_test.go:52: Pop() should have panicked when used in a
> > different function than Push()
> > === RUN TestDifferentScopeDistance
> > --- FAIL: TestDifferentScopeDistance (0.00s)
> > scope_stack_test.go:95: Should never get here
> > scope_stack_test.go:89: Should have panicked because scope stack
> > distance should point to this function
[...]
I assume the problem is caused by newer golang. It appears that atleast
nowadays (with go1.13.8) an inlined (anonymous) function will have
the same Func(tion) Entry(point) as the parent function it was inlined
into, eg. as used in the TestPushPopNotInSameFunction testcase.
The two Func(tions) however will have different Name()s, so simply
adding those to the Entry() comparisons will make the test-suite pass
again. See attached patch.
I'm not quite sure if this is the most robust fix, so would be great to
have some feedback from upstream (hopefully via Lluis in CC).
Some semi-relevant discussion is available at:
https://github.com/golang/go/issues/29582
... where it's discussed that rather than runtime.Caller and FuncForPC
it's better to use runtime.Callers and runtime.CallersFrames which is
supposed to deal properly with inlining, whatever that means.
Regards,
Andreas Henriksson
>From fd8f4d2fcd0ee6e541d7e7dd3e66a94b570a93ad Mon Sep 17 00:00:00 2001
From: Andreas Henriksson
Date: Mon, 2 Mar 2020 02:21:35 +0100
Subject: [PATCH] Also compare function names to catch inlined funcs
Inlined Func will have the same Entry value as the parent
Func it was inlined into. It will however have a different
Name(), so compare that as well.
---
scope_stack.go | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/scope_stack.go b/scope_stack.go
index bf68c81..f900752 100644
--- a/scope_stack.go
+++ b/scope_stack.go
@@ -17,6 +17,7 @@ package scopestack
import "fmt"
import "container/list"
import "runtime"
+import "strings"
// A stack type that tries to verify that each push and pop happens in the same
// function.
@@ -82,7 +83,7 @@ func (self *ScopeStack) Pop() interface{} {
oldFunc := runtime.FuncForPC(*oldFrame)
newFunc := runtime.FuncForPC(newFrame)
- if oldFunc.Entry() != newFunc.Entry() {
+ if oldFunc.Entry() != newFunc.Entry() || strings.Compare(oldFunc.Name(), newFunc.Name()) != 0 {
oldFile, oldLine := oldFunc.FileLine(*oldFrame)
newFile, newLine := newFunc.FileLine(newFrame)
msg := fmt.Sprintf("Unbalanced ScopeStack.Pop(). "+
--
2.20.1
Bug#583958: pam_umask --enable-usergroups compile-time option
Hello, On Fri, Jan 10, 2020 at 01:34:20PM +0100, Andreas Henriksson wrote: [...] > Please let me know if the above is satisfactory and if you'd like me to > send a merge-request for an updated packaging! I assume you've already noticed, but for the record https://salsa.debian.org/vorlon/pam/-/merge_requests/3 was opened shortly after sending the above quoted mail. > If you happen to see any other outstanding issues you think are blockers > for this please also let me know about those! Given almost 2 months has passed without a comment I assume it's up to me to NMU the changes, which I'll be doing if I don't hear anything in the next couple of weeks. Regards, Andreas Henriksson
Bug#947784: gegl: FTBFS on hurd-i386
On Sun, Feb 23, 2020 at 10:24:17AM +0100, Andreas Henriksson wrote: [...] > In meson_options.txt libv4l has the default value of 'auto' > (and the option is not explicitly specified/overriden in > debian/rules invocation of dh_auto_configure). [...] The thing I was apparently missing is that debian/rules specifies this option: -Dauto_features=enabled ... which is apparently a way to tell meson to globally change the behaviour of how auto is dealt with. This was likely added to avoid surprises that could happen with automatically detected features and mistakenly missed build-dependencies (eg. when someone updates to a new upstream version but forgets to bump the minimum required version of a build-dependency and suddenly the feature is disabled without anyone noticing). Mystery solved... I'll check something into git (without testing it) and hopefully next upload will get further on hurd. Please feel free to test it (and suggest additional fixes). See: https://salsa.debian.org/gnome-team/gegl/commit/4a655fa5240d0347d16261edab0e9b0b54d2fb0a Regards, Andreas Henriksson
Bug#947784: gegl: FTBFS on hurd-i386
Hello Samuel, On Mon, Dec 30, 2019 at 07:29:45PM +0100, Samuel Thibault wrote: > Source: gegl > Version: 0.4.18-2 > Severity: important > Tags: patch > User: debian-h...@lists.debian.org > Usertags: hurd > > Hello, > > gegl currently can't build on hurd-i386 because it build-depends on > libv4l-any, which is not built on hurd-i386. Could you apply the > attached patch to fix that? I uploaded your patch yesterday but apparently the build still fails (for a reason I don't quite understand) as can be seen in: https://buildd.debian.org/status/fetch.php?pkg=gegl=hurd-i386=0.4.22-1=1582423475=0 If I'm not mistaken this is the culprit: [...] Run-time dependency libv4l1 found: NO (tried pkgconfig) meson.build:223:0: ERROR: Dependency "libv4l1" not found, tried pkgconfig A full log can be found at /<>/obj-i686-gnu/meson-logs/meson-log.txt cd obj-i686-gnu && tail -v -n \+0 meson-logs/meson-log.txt [...] In meson_options.txt libv4l has the default value of 'auto' (and the option is not explicitly specified/overriden in debian/rules invocation of dh_auto_configure). According to the 'Features' section at https://mesonbuild.com/Build-options.html it is documented that: > auto is the same as passing required : false. ... but that doesn't seem to match what we're seeing in the hurd build log. I'm confused. Either I'm missing something obvious or some debugging is needed to figure this one out. Regards, Andreas Henriksson PS. Is #892238 still relevant? Maybe it should just be closed now.
Bug#951821: gegl: FTBFS on arm*/mips* architectures; testing migration blocked
On Sat, Feb 22, 2020 at 06:23:36PM +0100, Andreas Henriksson wrote: > On Sat, Feb 22, 2020 at 05:21:08PM +0100, Andreas Henriksson wrote: > > Hello Boyuan Yang, > > > > Thanks for your bug report. > > > > On Sat, Feb 22, 2020 at 12:23:13AM -0500, Boyuan Yang wrote: > > > Source: gegl > > > Version: 0.4.18-2 > > > Severity: serious > > > Justification: out-of-sync unstable-to-testing > > > X-Debbugs-CC: jbi...@debian.org > > [...] > > FWIW I might have noticed that the problem is possibly related > to building on a single core machine rather than an arch- or > machinespeed-specific problem. > > Atleast using MESON_TESTTHREADS=1 when running the test-suite makes > the gegl:simple / backend-file timeout for me. Oh, SORRY! Actually it's the opposite. When running the tests in parallel the backend-file test times out. I'm disabling parallel tests via 'dh_auto_test --no-parallel' now but it seems there are more test failures on the archs where the build failed previously. Also see the previously filed bug #888769 for more (mips-specific?) investigations. Regards, Andreas Henriksson
Bug#951821: gegl: FTBFS on arm*/mips* architectures; testing migration blocked
On Sat, Feb 22, 2020 at 05:21:08PM +0100, Andreas Henriksson wrote: > Hello Boyuan Yang, > > Thanks for your bug report. > > On Sat, Feb 22, 2020 at 12:23:13AM -0500, Boyuan Yang wrote: > > Source: gegl > > Version: 0.4.18-2 > > Severity: serious > > Justification: out-of-sync unstable-to-testing > > X-Debbugs-CC: jbi...@debian.org > [...] FWIW I might have noticed that the problem is possibly related to building on a single core machine rather than an arch- or machinespeed-specific problem. Atleast using MESON_TESTTHREADS=1 when running the test-suite makes the gegl:simple / backend-file timeout for me. Regards, Andreas Henriksson
Bug#951821: gegl: FTBFS on arm*/mips* architectures; testing migration blocked
Hello Boyuan Yang, Thanks for your bug report. On Sat, Feb 22, 2020 at 12:23:13AM -0500, Boyuan Yang wrote: > Source: gegl > Version: 0.4.18-2 > Severity: serious > Justification: out-of-sync unstable-to-testing > X-Debbugs-CC: jbi...@debian.org [...] > Looking into the current status, it fails to build on all ARM and MIPS [...] Please inform the architecture porters for the affected architectures. I don't think the more or less defunct Debian GNOME Team to have resources to handle this or atleast not make it high enough in priority to do arch porting work. Preferably the arch porters will work this out with upstream (and for extra bonus keep making sure there are people working in collaboration with upstream to make sure arch specific problems doesn't arise again). Ping the Debian GNOME Team again with which commits should be cherry-picked once they're merged upstream. Another option would be to have the (likely massive) reverse dependency tree of packages removed on these architectures, but I guess you'll have a hard time convincing the ftp-team of going through that and removing everything so I guess that's only a theoretical option. Regards, Andreas Henriksson
Bug#951516: gvfs: gvfs-daemons fails to install on non-linux boxes
Hello, On Mon, Feb 17, 2020 at 07:07:00PM +0100, Svante Signell wrote: > Source: gvfs > Severity: important > Version: 1.42.2-1 > Tags: patch > User: debian-h...@lists.debian.org > Usertags: hurd > X-Debbugs-CC: debian-h...@lists.debian.org > > Hello, > > The latest version of gvfs fails to install on non-linux boxes due to the > dependency on lsof for gvfs-daemons, [...] > Attached are two patches, one for control and one for control.in. [...] Please send a merge-request on salsa.debian.org or this will easily get lost in all the noise in the BTS. Regards, Andreas Henriksson
Bug#951619: avahi: New upstream release (0.8)
Source: avahi Version: 0.7-5 Severity: wishlist Hello, There's a new upstream release of avahi available now, see: https://alioth-lists.debian.net/pipermail/pkg-utopia-maintainers/2020-February/027450.html I've updated my previous work on python3 conversion of avahi from the previous upstream snapshot to the new 0.8 release (and rebased it on top of the 0.7-5 changes that has gone into the official packaging repo since). My work is available at: https://salsa.debian.org/ah/avahi Please note that this is only build-tested. I've likely done some mistake somewhere so would be great if someone could review this before merging it into the utopia-team repo. Regards, Andreas Henriksson
Bug#951422: iwd: /usr/libexec is not the right place for iwd
Control: tags -1 + upstream wontfix Hello Anton Khirnov, Thanks for your bug report. On Sun, Feb 16, 2020 at 12:31:09PM +0100, Anton Khirnov wrote: > Package: iwd > Version: 1.4-1 > Severity: normal > > Dear Maintainer, > the iwd binary is currently installed into /usr/libexec. IIUC > /usr/libexec is supposed to contain "internal" helper binaries that > are used by the package and are not supposed to be executed directly by > the user or binaries from other packages. > > However, that is not the case for iwd. It is supposed to be executed by > the init system or can be run by the user directly. Therefore > /usr/libexec is the wrong place for it and it should live in /sbin or > /usr/sbin. Feel free to argue your case upstream. I don't have any intention to play games with moving files to different locations than upstream installs them (and cause grave bugs like the ones in eg. neomutt!). Fwiw, I don't agree that the init system is a user. (Neither is dbus.) Also, any binary /can/ be executed by a user - the difference is how useful it is to do so. I don't see why anyone would or should ever execute the iwd binary directly. Regards, Andreas Henriksson
Bug#888670: gnome-system-tools: has been unmaintained upstream for a long time
Control: reopen -1 Control: severity -1 important Hello, The new repository[1] that was supposedly fixing this bug report doesn't even include the upstream sources (or their git history). It's a plain packaging repo with only the debian/ directory. I don't see how that's supposed to fulfil the need for you to become your own uptream. You most likely want to create a fork from the archived gnome repo[2]. Also please pick a (new) name for your fork as it's *not* THE gnome-system-tools (anymore), unless you actually talk to the gnome project to officially pick up as the gnome maintainer (but I suspect at this point there's absolutely no interest from the gnome project to have gnome-system-tools revived). (Once a proper upstream fork exists, packaging that under the new name and providing a transitional gnome-system-tools meta-package will give current users a seemless upgrade experience.) (Please also make sure to look into all the deprecated notices that is being spit out during build. Those will likely become an issue in the not too distant future. But first you might want to reconsider if you really have the resources for taking on the task of becoming your own upstream.) Regards, Andreas Henriksson [1]: https://github.com/LStranger/gnome-system-tools-debian [2]: https://gitlab.gnome.org/Archive/gnome-system-tools
Bug#947530: gnome-system-tools: build-depends on deprecated gnome-doc-utils
Control: reopen -1
On Sat, Feb 01, 2020 at 03:25:11PM +0200, Andriy Grytsenko wrote:
> Hello Andreas!
>
> Thank you very much for the patch. It appears you've done all the
> work and it worked like a charm. All porting guide steps are handled,
> I've rechecked that. Thank you very much.
Apparently you forgot to actually run the application, click the help
button and see what happens.
I've attached a patch which makes a few additional changes that avoids
completely breaking the help system.
To switch away from ghelp: URIs to help: URIs I've found out that it's
apparently needed to do a full docbook to mallard conversion. The URI
scheme is also different where ghelp: is followed by a full path to
an xml file while help: is followed by id, e.g.
help:users-admin or help:users-admin/chapter.
Regards,
Andreas Henriksson
PS. nitpick: The package also ships help for alot more applications than
it installs executables for.
diff -Nru gnome-system-tools-3.0.0/debian/changelog
gnome-system-tools-3.0.0/debian/changelog
--- gnome-system-tools-3.0.0/debian/changelog 2020-02-01 14:10:47.0
+0100
+++ gnome-system-tools-3.0.0/debian/changelog 2020-02-14 20:11:18.0
+0100
@@ -1,3 +1,13 @@
+gnome-system-tools (3.0.0-9.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix up debian/patches/70_gst-yelp.patch to not completely break help.
+- revert to using ghelp: URIs.
+- fix up help file available detection logic for new file location.
+ * Recommend yelp instead of xdg-utils (use gnome-help, not xdg-open).
+
+ -- Andreas Henriksson Fri, 14 Feb 2020 20:11:18 +0100
+
gnome-system-tools (3.0.0-9) unstable; urgency=medium
* Bump Standards-Version to 4.5.0.
diff -Nru gnome-system-tools-3.0.0/debian/control
gnome-system-tools-3.0.0/debian/control
--- gnome-system-tools-3.0.0/debian/control 2020-02-01 14:02:37.0
+0100
+++ gnome-system-tools-3.0.0/debian/control 2020-02-14 20:11:18.0
+0100
@@ -14,7 +14,6 @@
gettext,
libxml-parser-perl,
gnome-pkg-tools,
- yelp,
yelp-tools,
pkg-config
Standards-Version: 4.5.0
@@ -27,7 +26,7 @@
Depends: ${misc:Depends},
${shlibs:Depends},
policykit-1-gnome | mate-polkit
-Recommends: xdg-utils
+Recommends: yelp
Suggests: ntp
Replaces: ximian-setup-tools, gnome-network-admin
Conflicts: gnome-network-admin
diff -Nru gnome-system-tools-3.0.0/debian/patches/70_gst-yelp.patch
gnome-system-tools-3.0.0/debian/patches/70_gst-yelp.patch
--- gnome-system-tools-3.0.0/debian/patches/70_gst-yelp.patch 2020-02-01
14:00:24.0 +0100
+++ gnome-system-tools-3.0.0/debian/patches/70_gst-yelp.patch 2020-02-14
20:11:18.0 +0100
@@ -43,7 +43,7 @@
-DOC_INCLUDES =
-DOC_FIGURES = figures/network-tool.png
+HELP_ID = network-admin
-+HELP_FILES = legal.xml
++HELP_FILES = network-admin.xml legal.xml
+HELP_MEDIA = figures/network-tool.png
-DOC_LINGUAS = ca cs de el en_GB es fr oc pt_BR sl sv it zh_CN
@@ -63,7 +63,7 @@
-DOC_INCLUDES =
-DOC_FIGURES = \
+HELP_ID = services-admin
-+HELP_FILES = legal.xml
++HELP_FILES = services-admin.xml legal.xml
+HELP_MEDIA = \
figures/services-tool.png
@@ -84,7 +84,7 @@
-DOC_FIGURES = figures/shares-tool.png
-DOC_LINGUAS = ca cs de el en_GB es fr gl it oc pt_BR sl sv zh_CN
+HELP_ID = shares-admin
-+HELP_FILES = legal.xml
++HELP_FILES = shares-admin.xml legal.xml
+HELP_MEDIA = figures/shares-tool.png
+HELP_LINGUAS = ca cs de el en_GB es fr gl it oc pt_BR sl sv zh_CN
@@ -101,7 +101,7 @@
-DOC_INCLUDES =
-DOC_FIGURES = \
+HELP_ID = time-admin
-+HELP_FILES = legal.xml
++HELP_FILES = time-admin.xml legal.xml
+HELP_MEDIA = \
figures/time-map.png\
figures/time-servers.png\
@@ -124,7 +124,7 @@
-DOC_INCLUDES =
-DOC_FIGURES = figures/users-tool.png \
+HELP_ID = users-admin
-+HELP_FILES = legal.xml
++HELP_FILES = users-admin.xml legal.xml
+HELP_MEDIA = figures/users-tool.png \
figures/groups.png
@@ -792,15 +792,15 @@
- done
--- a/src/common/gst-tool.c
+++ b/src/common/gst-tool.c
-@@ -412,9 +412,9 @@
- }
-
- if (section) {
-- command = g_strconcat ("gnome-help ghelp://", uri, "?",
section, NULL);
-+ command = g_strconcat ("xdg-open help://", uri, "?", section,
NULL);
- } else {
-- command = g_strconcat ("gnome-help ghelp://", uri, NULL);
-+ command = g_strconcat ("xdg-open help://", uri, NULL);
- }
+@@ -400,9 +400,9 @@
+ }
+ uri = g_build_filename(DATADIR,
+- "/gnome/help/",
+- help_file,
++ "/help/",
+ lang,
++
Bug#951337: lintian-brush: dh_clideps fails when debian/compat is removed
Control: retitle -1 lintian-brush: dh_clideps fails with compat bumped On Fri, Feb 14, 2020 at 06:23:53PM +0100, Andreas Henriksson wrote: > Package: lintian-brush > Version: 0.57 > Severity: wishlist > > Dear Maintainer, > > It seems running lintian-brush on a .NET package (like pdfmod) will > cause it to FTBFS. AFAICT this is caused by the switching of > debian/compat -> debhelper-compat (= ...) change, as the dh_clideps > helper has not been updated to support the new syntax. And with some more testing, even with debian/compat restored the same failure still happens. Apparently bumping compat to 12 (or even 10) will cause the same problem to happen. > > Please consider detecting .NET packages and skipping the > debhelper-compat change for now (until someone volunteers to > fix up dh_clideps). ... and the debhelper compat bump. BTW. If this turns out to be a pdfmod specific problem (and not a generic .Net packaging problem) feel free to just close this issue. Regards, Andreas Henriksson
Bug#951337: lintian-brush: dh_clideps fails when debian/compat is removed
Package: lintian-brush Version: 0.57 Severity: wishlist Dear Maintainer, It seems running lintian-brush on a .NET package (like pdfmod) will cause it to FTBFS. AFAICT this is caused by the switching of debian/compat -> debhelper-compat (= ...) change, as the dh_clideps helper has not been updated to support the new syntax. Please consider detecting .NET packages and skipping the debhelper-compat change for now (until someone volunteers to fix up dh_clideps). Regards, Andreas Henriksson
Bug#951257: udevadm: please exit nonzero with "Running in chroot, ignoring request." when /proc is not mounted
Hello, On Thu, Feb 13, 2020 at 02:21:00PM +0100, Michael Biebl wrote: > Am 13.02.20 um 14:03 schrieb Trent W. Buck: [...] > > 78root@DESKTOP-P00TKMM:/# udevadm trigger > > Failed to scan devices: No such file or directory > > You should only get this error message if /sys is not mounted. > I assume your chroot has neither /sys nor /proc mounted. > > > systemd-udevd.service has > ConditionPathIsReadWrite=/sys > > You could try to convince upstream to add a similar check to "udevadm > trigger" > Just wanted to chime in here and say that another way at looking at this is to say that calling udevadm (and expecting it to exit with success) when udev is not running could possibly be considered the bug. (Or in other words, it feels wrong to me to expect udevadm to exit with success when it's failing to do the job it was asked to do.) From a simple codesearch.debian.net search I can see there are atleast some packages which tries to only conditionally run udevadm, eg. via 'pidof udevd && udevadm ...' and similar in their maintainer scripts. (Note: this particular check might not be considered perfect, just one example. This check will still fail if udevd is running in the host and you're working in a chroot. That might be considered your fault for not using a separate namespace though, ie. via systemd-nspawn.) Regards, Andreas Henriksson
Bug#906026: Switch to Ayatana Indicators
Control: severity -1 serious Hello XFCE Maintainers, I'm bumping the severity of this bug report because the libindicators package in RC buggy and likely not going to make it for bullseye, plus the fact that this bug report has been open with patch for >1.5 years now! Apparently it needs some extra visibility or likely an NMU. Regards, Andreas Henriksson
Bug#948780: yelp: FTBFS: Validation of files failed
Hi, A possible workaround for yelp FTBFS could be to add the --disable-appstream-util configure flag. This disables the validation and hopefully the parser is more relaxed during runtime and properly handles the missing field (as they where not required in the past). (Ofcourse a proper fix of adding them would be better though...) Regards, Andreas Henriksson
Bug#940199: pluma: python2 and new upstream stable release 1.24.0
Control: tags -1 + patch Hello, I've prepared an update for the pluma package to the recently released new upstream stable release 1.24.0. The merge-request is available at: https://salsa.debian.org/debian-mate-team/pluma/merge_requests/1 (Please note that this has only been compile tested.) I've kind of lost patience waiting for a followup from pluma maintainers on the python2 loader issue, so expect me to drop the python2 loader from libpeas any second now! Please speak up if you want me to NMU the fixed up pluma package! Regards, Andreas Henriksson
Bug#942625: src:gbrainy: Uploader email address no working
Control: tags -1 + moreinfo Hello, On Sat, Oct 19, 2019 at 12:33:00AM -0400, Scott Kitterman wrote: > Package: src:gbrainy > Severity: normal > > Mail for Siegfried-Angel Gevatter Pujals has been failing for some time: > > This message was created automatically by mail delivery software. > > A message that you sent could not be delivered to one or more of its > recipients. This is a permanent error. The following address(es) failed: > > rai...@ubuntu.com [...] I'm confused... You filed this bug report in 2019... However according to git history Siegfried changed his own mail address in 2017. commit 5a8150bb9dc5063305e3902d8b1894dc2382a9e2 Author: Siegfried-Angel Gevatter Pujals Date: Sun Jun 18 09:33:03 2017 + -Maintainer: Siegfried-Angel Gevatter Pujals +Maintainer: Siegfried-Angel Gevatter Pujals Is there a problem with the current gevatter.com mail adress or should this bug report be considered done? (Note: I've 's/@/ at /' to obfuscate the adresses above to avoid feeding the spam bots with all his mail adresses.) Regards, Andreas Henriksson
Bug#950990: neomutt: New upstream release (20191207)
Package: neomutt Version: 2019+dfsg.1-1 Severity: wishlist Dear Maintainer, I've prepared an updated package for the new upstream release (that fixes both of the open RC bugs) available at: https://salsa.debian.org/ah/neomutt Given that the neomutt package is soon about to be removed from testing because of the RC bugs not being handled, I'm about to NMU this very soon! Your acknowledgement of the NMU or any other comments you might have would be welcome. If you have any objections please speak up *NOW*. Regards, Andreas Henriksson
Bug#948895: neomutt: FTBFS: test failure
Control: tags -1 + fixed-upstream Hello, This is fixed by: https://github.com/neomutt/neomutt/commit/6a98d598bf0443516146c6a856b965f5e0fb35a1#diff-80e4b64ac703024c17f04c3d0d014e40 In other words updating to the latest release (20191207) would fix this issue. Regards, Andreas Henriksson
Bug#949847: syslog-ng FTBFS: configure: error: syslog-ng requires bison 3.4 or later
Hi, On Sat, Jan 25, 2020 at 09:25:45PM +0100, Helmut Grohne wrote: > Source: syslog-ng > Version: 3.25.1-1 > Severity: serious > Tags: ftbfs > > syslog-ng fails to build from source in unstable. A build log contains: > > | configure: error: syslog-ng requires bison 3.4 or later (traditional yacc > is not enough). Your source tree seems to be from git, which doesn't have > lib/cfg-grammar.c. Please install bison or use a distribution tarball. > > This seems a bit strange since it earlier finds: > > | checking for bison... bison -y [...] It seems the sed expression in configure.ac doesn't do anything at: https://sources.debian.org/src/syslog-ng/3.25.1-1/configure.ac/#L425 This means bison_version will contain eg.: $ bison --version | head -n 1 bison (GNU Bison) 3.3.2 And since 'cut -d .' is used, then bison_version_major becomes: bison (GNU Bison) 3 And since it's expected to be an integer it won't evaluate to -ge 3. Personally I'm not familiar with exprission like '@<:@^0-9.@:>@*' and where they are documented. Using codesearch.debian.net[1] they show up in many places not only for sed, but also passed to grep, tr, etc. If someone knows where these expressions are documented please tell me. Maybe the problem is in some underlying component rather than syslog-ng. Regards, Andreas Henriksson [1]: https://codesearch.debian.net/search?q=%2F%40%3C%3A=1=1
Bug#851747: sysvinit-utils: drop Essential flag
Hello, Regarding the previous discussion about packages with init scripts that source /lib/init/vars.sh I've now submitted bug reports including an attempt at a service file for packages with popcon install count above 100 (and some below), except for a few that I didn't find motivation for: sasl2-bin sendmail-bin xen-utils-common lprng webfs heimdal-kcm The bug reports in question are: https://bugs.debian.org/950236 https://bugs.debian.org/950240 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738548 https://bugs.debian.org/950427 https://bugs.debian.org/950241 http://bugs.debian.org/950952 https://bugs.debian.org/950432 https://bugs.debian.org/950694 https://bugs.debian.org/950246 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950263 https://bugs.debian.org/950696 https://bugs.debian.org/950697 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849955 https://bugs.debian.org/950270 http://bugs.debian.org/950948 https://bugs.debian.org/950949 https://bugs.debian.org/950945 https://bugs.debian.org/950943 https://bugs.debian.org/950951 https://bugs.debian.org/950442 https://bugs.debian.org/950320 https://bugs.debian.org/793854 https://bugs.debian.org/950441 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833067 https://bugs.debian.org/950388 https://bugs.debian.org/950386 My impression is that adding service files for most of the affected init scripts should be pretty straight forward and hasn't been done simply because the maintainer hasn't cared enough to do so. In case there are any complex cases those could ofcourse always resort to depending on sysvinit-utils. Several of the init scripts I've looked at already use commands and assume packages with Priority >= important are always installed and don't specify dependencies for them (and it'll likely be quite a while before sysvinit-utils drops its priority below that, which is certainly not the scope for this bug report). Regards, Andreas Henriksson
Bug#950952: aprx: missing-systemd-service-for-init.d-script
Package: aprx Version: 2.9.0+dfsg-2 Severity: normal Tags: bullseye sid Dear Maintainer, Please consider adding a native systemd service masking the already shipped init script (fixes lintian tag[1] in subject). I've attached my own attempt at writing a service file, based off looking at what the init script does. Note that it is completely untested (as I don't use aprx myself). You can install the aprx.service file by simple dropping it into the debian/ directory and debhelper will handle it for you (however note that the current compat level 11 is discuraged, so you might want to move to either 10 or 12). Please note that the service file could be simplified. By adding the aprx -i flag the program will run in the foreground and you could use Type=simple. It is also recommended *not* to use EnvironmentFile and setting options via /etc/default files, but instead use 'systemctl edit aprx.service' so that systemd-delta will be able to show any customizations. I however opted for the attached way as the user might already have some important settings in DAEMON_OPTS that I'm not aware of. Additional improvements eg. using security hardening[2] could also be added. Regards, Andreas Henriksson [1]: https://lintian.debian.org/tags/missing-systemd-service-for-init.d-script.html [2]: https://lintian.debian.org/tags/systemd-service-file-missing-hardening-features.html [Unit] Description=Monitor and gateway radio amateur APRS radio network datagrams After=network.target [Service] Type=forking PIDFile=/run/aprx.pid EnvironmentFile=-/etc/default/aprx ExecStart=/usr/sbin/aprx $DAEMON_OPTS #TODO: security hardening [Install] WantedBy=multi-user.target
Bug#950951: ptunnel: missing-systemd-service-for-init.d-script
Package: ptunnel Version: 0.72-3 Severity: normal Tags: bullseye sid Dear Maintainer, Please consider adding a native systemd service masking the already shipped init script (fixes lintian tag[1] in subject). I've attached my own attempt at writing a service file, based off looking at what the init script does. Note that it is completely untested (as I don't use ptunnel myself). The ptunnel.service could simply be dropped into the debian/ directory and debhelper should do the right thing with the service file (although note that the current compat 11 is now discuraged!). Please also note that the magic expansions as done to $password is a shell feature and is not supported inside a service file. Also passing a password on the command line to a process is a local security hole as anyone could see it by simply running 'ps aux' or similar. I would recommend that ptunnel implements reading the password from the environment variable directly itself. The service could also be simplified by dropping the -daemon argument running ptunnel in the foreground and set Type=simple. It is recommended that user changes to settings are done via 'systemctl edit ptunnel.service' rather than using /etc/default files, which will allow 'systemd-delta' to show customizations. I however did not go this route as users current setup might contain important settings already in their $OPTIONS variable that I'm not aware of. Additional improvements eg. using security hardening[2] could also be added. Finally please get rid of the homebrew enable/disable[3] service implementation $run_daemon. Ship the service disabled and let the user simply run 'service ptunnel enable' when they have configured it. Regards, Andreas Henriksson [1]: https://lintian.debian.org/tags/missing-systemd-service-for-init.d-script.html [2]: https://lintian.debian.org/tags/systemd-service-file-missing-hardening-features.html [3]: https://lintian.debian.org/tags/init.d-script-should-always-start-service.html [Unit] Description=TCP over ICMP tunnelling daemon After=network.target [Service] Type=forking PIDFile=/run/ptunnel.pid Environment="OPTIONS=-daemon /run/ptunnel.pid" #Environment=run_daemon=false EnvironmentFile=-/etc/default/ptunnel # Note: https://lintian.debian.org/tags/init.d-script-should-always-start-service.html #ExecStartPre=/bin/bash -c 'if [ "$run_daemon" != true ]; then echo "To run the ptunnel daemon, please set run_daemon to 'true' in /etc/default/ptunnel "; exit 1 ; fi' ExecStart=/usr/sbin/ptunnel # TODO: security hardening [Install] WantedBy=multi-user.target
Bug#950949: ndpmon: missing-systemd-service-for-init.d-script
Package: ndpmon Version: 1.4.0-2.1 Severity: normal Tags: bullseye sid Dear Maintainer, Please consider adding a native systemd service masking the already shipped init script (fixes lintian tag[1] in subject). I've attached my own attempt at writing a service file, based off looking at what the init script does. Note that it is completely untested (as I don't use ndpmon myself). You should be able to use the ndpmon.service file by dropping it into the debian/ directory and then bumping debhelper compat to >= 10 which will get the service file automatically handled (also debhelper compat <= 9 is deprecated). Additional improvements eg. using security hardening[2] could also be added. Regards, Andreas Henriksson [1]: https://lintian.debian.org/tags/missing-systemd-service-for-init.d-script.html [2]: https://lintian.debian.org/tags/systemd-service-file-missing-hardening-features.html [Unit] Description=IPv6 Neighbor Discovery Protocol Monitor After=network.target ConditionPathExists=/etc/ndpmon/config_ndpmon.xml [Service] Type=simple #Environment=DAEMON_ARGS= EnvironmentFile=-/etc/default/ndpmon ExecStart=/usr/sbin/ndpmon $DAEMON_ARGS [Install] WantedBy=multi-user.target
Bug#950948: n2n: missing-systemd-service-for-init.d-script
Package: n2n Version: 1.3.1~svn3789-7 Severity: normal Dear Maintainer, Please consider adding a native systemd service masking the already shipped init script (fixes lintian tag[1] in subject). I've attached my own attempt at writing a service file, based off looking at what the init script does. Note that it is completely untested (as I don't use n2n myself). You should be able to use it just by dropping the n2n.service file in the debian/ directory and then bump debhelper compat to >= 10 which will get the service file automatically handled (also compat 9 in now deprecated). Please note that the service could be a Type=simple if you drop the -f flag in ExecStart. (Even better would be if the service implemented support for sd_notify READY=1 so you could use Type=notify.) Given the comment in the long description of the init script I however imagine you really want to create a template service instance instead (and just mask n2n.service -> /dev/null) using n2n@.service. Additional improvements eg. using security hardening[2] could also be added. While at it please also get rid of the home-brew enable/disable[3] and instead ship the service disabled by default and let the user do 'service n2n enable' once they've configured it. Regards, Andreas Henriksson PS. the init script uses $DAEMON_ARGS but the default file contains an (empty) example variable N2N_DAEMON_OPTS (which is ignored). [1]: https://lintian.debian.org/tags/missing-systemd-service-for-init.d-script.html [2]: https://lintian.debian.org/tags/systemd-service-file-missing-hardening-features.html [3]: https://lintian.debian.org/tags/init.d-script-should-always-start-service.html [Unit] Description=n2n P2P VPN After=network.target [Service] Type=forking #PIDFile=/run/$NAME-edge.pid #Environment=DAEMON_ARGS= EnvironmentFile=-/etc/default/n2n # Note: https://lintian.debian.org/tags/init.d-script-should-always-start-service.html # ExecStartPre=/bin/bash -c '[ ! -z "$N2N_EDGE_CONFIG_DONE" ] || echo "Warning: n2n VPN client is not configured, edit config file in /etc/default/$NAME."; exit 1' ExecStart=/usr/sbin/edge -f -a $N2N_IP -c $N2N_COMMUNITY -l $N2N_SUPERNODE $DAEMON_ARGS User=nobody Group=nobody [Install] WantedBy=multi-user.target
Bug#950945: orthanc: missing-systemd-service-for-init.d-script
Source: orthanc
Version: 1.5.8+dfsg-2
Severity: normal
Dear Maintainer,
Please consider adding a native systemd service masking the already
shipped init script (fixes lintian tag[1] in subject).
I've attached my own attempt at writing a service file, based off
looking at what the init script does. Note that it is completely
untested (as I don't use orthanc myself).
You should be able to just drop the orthanc.service in the debian/
directory and then debhelper will do the right thing as you're
already using compat 10.
Additional improvements eg. using security hardening[2] could also be
added.
Regards,
Andreas Henriksson
[1]:
https://lintian.debian.org/tags/missing-systemd-service-for-init.d-script.html
[2]:
https://lintian.debian.org/tags/systemd-service-file-missing-hardening-features.html
[Unit]
Description=Orthanc - Lightweight, RESTful Vendor Neutral Archive
After=network.target
Wants=postgresql.service mysql.service
[Service]
Type=simple
Environment=LOGDIR=/var/log/orthanc
Environment="DAEMON_ARGS=--logdir=${LOGDIR} /etc/orthanc/"
ExecStart=/usr/sbin/Orthanc $DAEMON_ARGS
# Note: Signals are async but the ExecReload command should block
# until reload finished.
#ExecReload=/bin/kill -HUP $MAINPID
#ExecReload=/bin/sleep 2
User=orthanc
Group=orthanc
[Install]
WantedBy=multi-user.target
Bug#950943: psad: missing-systemd-service-for-init.d-script
Package: psad Version: 2.4.3-1.2 Severity: normal Tags: bullseye sid Dear Maintainer, Please consider adding a native systemd service masking the already shipped init script (fixes lintian tag[1] in subject). I've attached my own attempt at writing a service file, based off looking at what the init script does. Note that it is completely untested (as I don't use psad myself). You should be able to just drop the psad.service in the debian/ directory and then I would recommend bumping debhelper compat to >= 10 which will give you automatic handling of the service file (and also note that debhelper 9 is now deprecated). Additional improvements eg. using security hardening[2] could also be added. Regards, Andreas Henriksson [1]: https://lintian.debian.org/tags/missing-systemd-service-for-init.d-script.html [2]: https://lintian.debian.org/tags/systemd-service-file-missing-hardening-features.html [Unit] Description=Port Scan Attack Detector (psad) After=network.target ConditionPathExists=/etc/psad/psad.conf Wants=netfilter-persistent.service [Service] Type=forking PIDFile=/run/psad/psad.pid #Environment=DAEMON_ARGS= EnvironmentFile=-/etc/default/psad RuntimeDirectory=psad ExecStart=/usr/sbin/psad $DAEMON_ARGS # TODO: security hardening [Install] WantedBy=multi-user.target
Bug#949887: munin autopkgtest failure for sysvinit based tests
Hello,
While I don't know enough about how all of this works I think
I'd like to claim that this is a bug in munin (testsuite).
More details below.
On Sun, Jan 26, 2020 at 06:26:14PM +0100, Michael Biebl wrote:
> Package: munin,sysvinit-core
> Severity: serious
>
> Hi,
>
> the autopkgtest of munin currently fails, the
> master-cron autopkgtest using sysvinit-core fails with:
[...]
> autopkgtest [04:57:05]: test process requested reboot with marker into-sysv
> Failed to create rundir (/var/run/munin): Permission denied at
> /usr/share/munin/munin-update line 39.
[...]
Apparently the munin package is designed so that there's:
- a tmpfile(s) snippet that creates directories, including /run/munin
- an init script that exits on systemd but otherwise creates the
directories that the tmpfile(s) snippet was supposed to create.
(This feels quite WET, a more DRY solution would just be to hook up
running systemd-tmpfiles which should work on sysvinit[0] as well.)
AFAIK on systemd tmpfiles are processed early and are guaranteed
to be handled by the time (normal) services are started.
When the autopkgtest is booted into sysvinit I assume there's a
race between the munin init script starting and the actual
tests running.
The crash quoted above, as far as I can tell, comes from:
[...]
> debian/tests/munin-master/01.master-components.t ..
> expecting success:
> setuidgid munin /usr/share/munin/munin-update
>
> not ok 1 - munin-update
> #
> # setuidgid munin /usr/share/munin/munin-update
> #
[...]
The munin-update[1] program contains:
sub main {
exit_if_run_by_super_user();
[...]
my $update = Munin::Master::Update->new();
$update->run();
return 0;
}
The crash happens at the `$update->run();`[2] function call which
checks if /run/munin exists (which it apparently doesn't) and then
tries to create it[3].
As obvious by both the testsuite and the code, the program is *not*
being executed as root (but as munin user/group) and thus does not
have permission to create anything in (/var)/run.
I guess the problem can be fixed by adding as the first step in the
testsuite (running as root):
systemd-tmpfiles /usr/lib/tmpfiles.d/munin.conf
This should work on both systemd and sysvinit testbeds. It will
already have happened before on the systemd testbed but repeating
it should be harmless. (This however requires the systemd package
to be installed in the sysvinit testbed, so alternatively somehow
invoke the munin "service".)
(An alternative aproach which I don't know if it's possible would be
to investigate if you can somehow specify that the test-suite depends
on a particular init script to make sure things are started in the
right order on sysvinit testbed.)
Regards,
Andreas Henriksson
[0]: https://lists.debian.org/debian-devel/2020/01/msg00233.html
[1]:
https://sources.debian.org/src/munin/2.0.54-1/master/_bin/munin-update.in/#L30
[2]:
https://sources.debian.org/src/munin/2.0.54-1/master/lib/Munin/Master/Update.pm/#L45
[3]:
https://sources.debian.org/src/munin/2.0.54-1/master/lib/Munin/Master/Update.pm/#L98
Bug#940426: RFA: golang-github-streadway-amqp
Control: tags -1 + pending Hello, On Sun, Sep 15, 2019 at 06:59:07PM -0400, Alexandre Viau wrote: > Package: wnpp > Severity: normal > > Hello! > > I'd like to find new maintainers for some of my packages because I have > had less time for Debian. I'd like to focus the small amount of time > that I have for Debian on other things. I'm willing to help out (or take over) this package under the Debian Go Team umbrella, given that I've just introduced a new reverse dependency: garagemq (Others willing to help out could also join in under the team umbrella.) > > For now, I intend to do my best to keep maintaining this package. > However, I will probably retitle this bug with the 'O:' prefix at some > point, indicating that I have orphaned it. > > Feel free to upload a new version of the package and remove me from the > uploaders in debian/control. As you intend to still keep trying to do your best, I'll not remove you and expect you to eventually remove yourself (or explicitly ask me to do it). At the point you would consider changing this bug to O:, please consider if the package at that point is well enough maintained that you can just close this bug instead. > > Feel free to contact me with any questions. Also note that I always > willing to sponsor uploads! Thanks for your previous work. I'll get back to you with any questions that might pop up once I actually start looking into (updating) the package. Regards, Andreas Henriksson
