Re: Q: uscan with GitHub

2022-09-19 Thread Paul Wise
On Mon, 2022-09-19 at 18:12 +0200, Samuel Thibault wrote: > The problem is that the tags page only contains snapshots of the > repository, and not an autoconf-ed tarball. I think that is an advantage, because then you can be sure that you can rebuild the autotools generated files from source

Re: Q: uscan with GitHub

2022-09-19 Thread Paul Wise
On Mon, 2022-09-19 at 20:50 +0900, Hideki Yamane wrote: > Recent changes in GitHub releases pages, I cannot check upstream > version with uscan. How do you deal with it? If you are using the automatically generated tarballs, then just switching to the uscan git mode seems like the way to go.

Re: Q: uscan with GitHub

2022-09-19 Thread Paul Wise
On Mon, 2022-09-19 at 18:54 +0200, Andrea Pappacoda wrote: > Hi, what I usually do with GitHub is to use its API, since it has the > advantage of not breaking uscan when they do changes to the web UI. Since the API uses pagination, this has the minor downside of making it harder to use the uscan

Re: Bug#1019721: libopenmpi-dev: Cannot uninstall rmdir: failed to remove '/usr/lib/x86_64-linux-gnu/fortran/gfortran': No such file or directory

2022-09-14 Thread Paul Wise
On Wed, 2022-09-14 at 07:41 +0200, Andreas Metzler wrote: > Is there a way to find all packages built against broken dh-fortran- > mod so all affected packages can be rebuilt? I am not sure of the correct regex, but the binary package control search should work, if it doesn't then you need a

Re: packages expected to fail on some archs

2022-09-11 Thread Paul Wise
On Sun, 2022-09-11 at 23:07 +0300, Adrian Bunk wrote: > Architecture lists containing all 64bit ports or all little endian > ports create much extra work for anyone adding support for a new > 64bit little endian architecture. Since dpkg already knows about the bits and endianness of ports,

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

2022-09-09 Thread Paul Wise
On Fri, 2022-09-09 at 15:06 +0200, Vincent Bernat wrote: > I also had this issue. This was greatly improved since May and I am > now using it instead of PulseAudio. Check that you have rtkit-daemon > installed. It helps. I have rtkit installed, running and working for my UID according to the

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

2022-09-08 Thread Paul Wise
On Thu, 2022-09-08 at 17:58 +0200, Dylan Aïssi wrote: > I have been asked several times regarding when Debian will switch its default > sound server from PulseAudio to PipeWire without having an official answer. > Thus, I suppose it's the right time to start a discussion about that. I switched

Re: Intel CET Support?

2022-09-06 Thread Paul Wise
On Mon, 2022-09-05 at 22:44 +0200, Felix Potthast wrote: > i just stumbled upon the fact that debian doesn't yet make use of the > Intel CET security feature, while many other distributions > (Ubuntu, Fedora, Suse, Arch Linux) do. Allegedly Intel CET provides weak protection, although perhaps it

Re: Automatic trimming of changelogs in binary packages

2022-09-06 Thread Paul Wise
On Tue, 2022-09-06 at 07:13 +0200, Gioele Barabucci wrote: > * Packages not meant to be included in Debian (and without access to a > changelog server): Creators that want to preserve the full history can > use the `--no-trim` option to disable the trimming. Most derivatives aren't going to

Re: isa-support -- exit strategy?

2022-09-05 Thread Paul Wise
On Fri, 2022-03-25 at 23:34 +0100, Adam Borowski wrote: > Suggestions? FYI, as a result of this coming up on IRC again, I have summarised various suggestions on this wiki page for future reference: https://wiki.debian.org/InstructionSelection Please feel free to update/fix the page as needed.

Re: isa-support -- exit strategy?

2022-09-05 Thread Paul Wise
On Sun, 2022-04-03 at 14:17 +0300, Adrian Bunk wrote: > For binaries, I have seen packages in the Debian Med (?) team that build > several variants of a program and have a tiny wrapper program that chooses > the correct one at startup. It appears this is called simd-dispatch and the script is

Re: Re: Need a buildd build after trip through NEW -- best practice?

2022-09-01 Thread Paul Wise
On Thu, 2022-09-01 at 08:45 -0500, Steven Robbins wrote: > OK, so let's call it "bin nmu", then.  And add the "+bN" version > suffix. As others said, binNMUs exist, but not for arch:all packages. Debian doesn't yet have sourceful no-change rebuilds, so you have to manually do a sourceful

Re: Current NEW review process saps developer motivation

2022-08-29 Thread Paul Wise
On Mon, 2022-08-29 at 11:58 +0100, Wookey wrote: > Something of an aside from the current debate, but GObject > introspection introduced significant problems with cross-compiling > because the introspection process produces different results when done > on different architectures so you couldn't

Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation

2022-08-29 Thread Paul Wise
On Mon, 2022-08-29 at 12:33 +0530, Pirate Praveen wrote: > May be we should be able to tag packages with in NEW into categories > like this (similar to how a DD can give back a failed build via web > interface). This may need to go through a GR. If we prioritize packages > in NEW required for

Re: Need a buildd build after trip through NEW -- best practice?

2022-08-28 Thread Paul Wise
On Sun, 2022-08-28 at 17:54 -0500, Steven Robbins wrote: > Specficially: in the case of a NEW binary upload, could a manual request be > implemented (pick a different name if "give back" is not suitable) such that > it > is thrown away and replaced by a buildd build? The dak software already

Re: Converting Debian OpenStack images to btrfs

2022-08-26 Thread Paul Wise
On Fri, 2022-08-26 at 11:05 +0200, John Paul Adrian Glaubitz wrote: > To workaround a longstanding qemu/glibc compatibility issue [2], I need > the images to use btrfs instead of ext4 and I was wondering whether anyone > can give me some hints on how to convert the images provided at [1] from >

Re: Current NEW review process saps developer motivation

2022-08-26 Thread Paul Wise
On Fri, 2022-08-26 at 11:58 +0100, Simon McVittie wrote: > I don't think it's always useful to talk about "the" source or "the" > preferred form for modification, as though there is only one. I see both the licensing and source aspects of the Free Software movement as aspiring to providing a

Re: Current NEW review process saps developer motivation

2022-08-26 Thread Paul Wise
On Fri, 2022-08-26 at 11:58 +0100, Simon McVittie wrote: > I don't think building from the least-derived form is always the > right thing to do. Personally, I believe that instances of that represent bugs in how the upstream source trees and build processes are organised. > For instance, take

Re: Need a buildd build after trip through NEW -- best practice?

2022-08-25 Thread Paul Wise
On Thu, 2022-08-25 at 11:04 +0200, Paul Gevers wrote: > In testing and on release architectures, I'm only aware [1] of one that > can't build arch:all+arch:any binaries on amd64 (cmucl), but even that > one builds its arch:all binaries on amd64. I'm wondering if there are > packages where this

Re: Need a buildd build after trip through NEW -- best practice?

2022-08-24 Thread Paul Wise
On Wed, 2022-08-24 at 23:19 +0200, Sebastian Ramacher wrote: > I run > > $ drt-tools process-excuses > > once a day (except during VAC or when I am not in front of a box with my > Debian keys). That schedules binNMUs for all packages that only require > a rebuild and have no other issues

Re: Need a buildd build after trip through NEW -- best practice?

2022-08-23 Thread Paul Wise
On Tue, 2022-08-23 at 16:59 -0500, Steven Robbins wrote: > The binary upload cannot transition to testing -- a buildd binary build is > required.  So far as I know -- assuming [1] is still up-to-date, this means a > nuisance upload just bumping the debian revision from -1 to -2.  Is this >

Re: Suggestion for db.debian.org/machines.cgi page

2022-08-22 Thread Paul Wise
On Mon, 2022-08-22 at 07:12 -0500, Steven Robbins wrote: > NOTE for whoever is maintaining the very nice > db.debian.org/machines.cgi page: https://salsa.debian.org/dsa-team/mirror/userdir-ldap-cgi/ > I guess that one should really be searching in the Description field > rather than

Re: Automatic trimming of changelogs in binary packages

2022-08-19 Thread Paul Wise
On Fri, 2022-08-19 at 09:06 +0200, Michael Biebl wrote: > If we turn on changelog trimming by default, we should probably also > turn on apt downloading the changelogs by default. I think the default apt behaviour should be as it is now, show the installed changelog (with the footer suggested

Re: Automatic trimming of changelogs in binary packages

2022-08-18 Thread Paul Wise
On Thu, 2022-08-18 at 21:18 +0200, Gioele Barabucci wrote: > Does anybody have objective objections against activating automatic > changelog trimming in binary packages? Before we consider enabling this by default, first we need a way for `apt changelog` to download the full changelog rather

Re: Clarification regarding zlib1g-dev package for buster-slim s390x

2022-08-11 Thread Paul Wise
On Thu, 2022-08-11 at 15:14 +, Yasir Ashfaq1 wrote: > To: debian-devel@lists.debian.org > Subject:Clarification regarding zlib1g-dev package for buster-slim > s390x In future, please ask for help using Debian on our support channels, the debian-devel mailing list is for

Re: questionable massive auto-removal: buggy deps nvidia-graphics-drivers-tesla-470

2022-06-28 Thread Paul Wise
On Tue, 2022-06-28 at 22:23 +0200, Paul Gevers wrote: > There are patches to support throw away binaries, but as far as I'm > aware they haven't been merged and I don't know the status of the > patches. That won't remove the need for binary uploads, but it would > remove the need for a

Re: how to convey package porting details?

2022-06-06 Thread Paul Wise
On Mon, 2022-06-06 at 16:52 +0200, Marco d'Itri wrote: > Maybe the usual suspects which require significant porting work could > start documenting instructions for porters in debian/README.source. Thats a good start, but doesn't provide a standard way to find out which packages contain such

Re: how to convey package porting details?

2022-06-06 Thread Paul Wise
On Mon, 2022-06-06 at 10:47 +0200, Marco d'Itri wrote: > Is this really worth the effort, considering that probably RISC-V is > going to be our last port for a very long time? There are at least two or three new architectures in the pipeline already. loongarch64 from Loongson was already

how to convey package porting details?

2022-06-05 Thread Paul Wise
Hi all, There are lots of packages that need porting to every new architecture that comes along. There are others that don't require porting but benefit in some way from porting to some aspect of the architecture. In order to help porters to prioritise those packages and quickly add support for

Bug#1012289: O: lintian -- Debian package checker

2022-06-02 Thread Paul Wise
Package: wnpp Severity: normal X-Debbugs-Cc: debian-devel@lists.debian.org, debian-lint-ma...@lists.debian.org Control: affects -1 src:lintian The lintian package is now orphaned as both of the people who were actively working on lintian have stopped that work:

Bug#1012227: general: CPU usage is 50% or higher with WebKitWebProcess

2022-06-01 Thread Paul Wise
Control: reassign -1 libwebkit2gtk-4.0-37 Control: retitle -1 webkitgtk: CPU usage is 50% or higher with WebKitWebProcess On Wed, 2022-06-01 at 14:57 -0500, Tim McConnell wrote: > WebKitWebProcess will use 50% of CPU by itself and will often take > the CPU usage to 100% Bugs in WebKit should

Re: How to install kdump in debian11?

2022-05-31 Thread Paul Wise
On Tue, 2022-05-31 at 18:15 +0800, starcold14 wrote: > How to install kdump in debian11? Looks like this will work:    sudo apt install kdump-tools    https://packages.debian.org/search?keywords=kdump In future, please send questions like this to Debian support:   

Re: maven doc

2022-05-30 Thread Paul Wise
On Mon, 2022-05-30 at 14:50 +0200, Yadd wrote: > I'd like to package a Java software built with maven. Is there an up- > to-date documentation on how to use maven in Debian packages ? The Java team have some docs on this and would know more about this:

Re: use of Recommends by vlc to force users to use pipewire

2022-05-30 Thread Paul Wise
On Mon, 2022-05-30 at 14:30 +0200, Dylan Aïssi wrote: > libpipewire recommends pipewire for a reason [1], do you mean this is > not a good reason? > > [1] https://salsa.debian.org/utopia-team/pipewire/-/merge_requests/1 In the patch Philip Withnall wrote: > libpipewire dlopens modules from

Re: Firmware: Scope of non-free-firmware

2022-05-15 Thread Paul Wise
On Sun, 2022-05-15 at 20:53 +0200, Bastian Blank wrote: > I see what you mean.  But nothing of that actually enables the use of a > particular hardware. Enabling the use of particular hardware is a subset of the actual goal; enabling more people to use Debian at all, which the non-firmware items

Re: Firmware: Scope of non-free-firmware

2022-05-13 Thread Paul Wise
On Fri, 2022-05-13 at 17:48 +0200, Thomas Goirand wrote: > Yeah, of course, but this is because you know what you're doing. If > you do, then you also probably read the release notes, don't you? :) I haven't actually read the full release notes in recent years. I expect a lot of experienced

Re: Firmware: Scope of non-free-firmware

2022-05-12 Thread Paul Wise
On Thu, 2022-05-12 at 16:56 +0200, Thomas Goirand wrote: > If protected by a debconf prompt (by default, doing nothing...), all > of your remarks are going away. That means that people who only ever upgrade via unattended-upgrades or other mechanisms that disable debconf/dpkg prompts etc aren't

Re: Firmware: Scope of non-free-firmware

2022-05-11 Thread Paul Wise
On Wed, 2022-05-11 at 19:38 +0200, Adam Borowski wrote: > You may want to talk to people responsible for that firmware, reproducible > builds sounds like an attainable goal to me. I don't have any of the hardware that supports SOF, so I'll leave that up to the firmware-sof-signed maintainer etc.

Re: Firmware: Scope of non-free-firmware

2022-05-11 Thread Paul Wise
On Wed, 2022-05-11 at 17:14 +0200, Thomas Goirand wrote: > A work around would be to have some automation to check if non-free is > activated, and (propose to) update the sources.list automatically to add > non-free-firmware. That isn't feasible, since apt sources are managed external to

Re: Firmware: Scope of non-free-firmware

2022-05-10 Thread Paul Wise
On Tue, 2022-05-10 at 14:30 -0600, Sam Hartman wrote: > So let's assume that at least all those packages can move to > non-free-firmware. For backwards compatibility, I think that the firmware component is going to need to be a subset of non-free; i.e. packages are going to need to be *copied*

Re: bullseye-updates does not have a Release file

2022-05-07 Thread Paul Wise
In future, please ask for help using Debian on our support channels: https://www.debian.org/support On Sat, 2022-05-07 at 21:53 -0400, Timothy M Butterworth wrote: > deb http://security.debian.org/debian-security/ bullseye-updates main > deb-src http://security.debian.org/debian-security/ 

Re: feedback for NEW packages: switch to using the BTS?

2022-04-30 Thread Paul Wise
On Sat, 2022-04-30 at 22:47 -0400, nick black wrote: > i understand. i suppose that what i'm saying is it will probably > be worthwhile to convey in Mentors etc. documentation that > "resolving the bugs filed thus far [regarding the package in > NEW] does not imply that no further bugs will be

Re: feedback for NEW packages: switch to using the BTS?

2022-04-30 Thread Paul Wise
On Sat, 2022-04-30 at 14:20 -0700, Sean Whitton wrote: > This would really slow things down; > I don't think we could work that way. Using separate bug reports or not would of course be up to the person filing them, but I expect the process could be automated well enough that it wouldn't be much

Re: feedback for NEW packages: switch to using the BTS?

2022-04-30 Thread Paul Wise
On Sat, 2022-04-30 at 03:09 -0400, nick black wrote: > currently, as far as i understand things, a REJECT can be issued > for the first REJECT-worthy problem. The same would occur under the proposal, except that there would presumably be separate bug reports for separate issues. > if resolving

Re: feedback for NEW packages: switch to using the BTS?

2022-04-29 Thread Paul Wise
On Sat, 2022-04-30 at 00:13 +, Scott Kitterman wrote: > I'm still not understanding how any of that needs to have a package > we've decided not to accept sitting in New? My thinking is that debbugs would require a package (imported from new.822) to exist for maintainer addresses. If you file

Re: feedback for NEW packages: switch to using the BTS?

2022-04-29 Thread Paul Wise
On Fri, 2022-04-29 at 23:32 +, Scott Kitterman wrote: > I don't understand why this is any better than just rejecting the > package?  Once it's been determined that the upload won't be > accepted, I don't see a benefit to having it remain in New. The initial upload might not get an ACCEPT,

Re: feedback for NEW packages: switch to using the BTS?

2022-04-29 Thread Paul Wise
On Fri, 2022-04-29 at 18:08 +0200, Andreas Tille wrote: > To give some actual examples that IMHO are candidates for accept + bug > report: Packages with incomplete or incorrect debian/copyright information currently would recieve a REJECT rather than acceptance. The proposal would not change

Re: feedback for NEW packages: switch to using the BTS?

2022-04-29 Thread Paul Wise
On Fri, 2022-04-29 at 11:26 -0400, Scott Kitterman wrote: > 1.  Making reject/prod emails more public: > > There are actually two different types of messages we can send while > reviewing > packages in DAK: > > a.  Reject: As indicated by the name, this is an email that accompanies the >

Re: feedback for NEW packages: switch to using the BTS?

2022-04-29 Thread Paul Wise
On Fri, 2022-04-29 at 13:36 +0100, Steve McIntyre wrote: > Just to clarify: is this suggesting that packages from NEW would end > up in the archive even with serious bugs? If not, what's the point of > the "eventual removal" above? I'm not following you here... No, the bugs I propose to be filed

Re: autopkgtest/sbuild environment variables: LC_ALL, HOME, XDG_RUNTIME_DIR etc

2022-04-28 Thread Paul Wise
On Thu, 2022-04-28 at 14:32 +0100, Simon McVittie wrote: > Making the test script set up a mock XDG_RUNTIME_DIR and a mock > session bus would be a less useful test, because that only proves that > gnome-keyring can work if you set up a mock environment by hand, and says > nothing about whether

Re: feedback for NEW packages: switch to using the BTS?

2022-04-28 Thread Paul Wise
On Thu, 2022-04-28 at 20:24 +0200, Andreas Tille wrote: > But filing an ITP bug is cheap.  The R-pkg team has a script > itp_from_debian_dir[1] which creates this bug automatically once the > packaging work is done. The packaging work is supposed to start *after* the ITP is filed, so this is a

Re: feedback for NEW packages: switch to using the BTS?

2022-04-28 Thread Paul Wise
On Thu, 2022-04-28 at 13:48 +0200, Marco d'Itri wrote: > This looks like a good idea to me, but I think that the big problem > which needs to be solved is not discussing REJECTs but the packages > which stay in NEW for many months with no feedback. Thanks. The idea is narrowly aimed at

Re: feedback for NEW packages: switch to using the BTS?

2022-04-28 Thread Paul Wise
> person should look.) That seems reasonable if the ftpmasters are fine with that. If the BTS for NEW proposal gets implemented it would no longer be needed. Am Thu, Apr 28, 2022 at 08:54:05AM +0800 schrieb Paul Wise: > > The changes that are needed to make this happen include: I gue

Re: Advice for package needing stuff installed in /srv (node-shiny-server)

2022-04-28 Thread Paul Wise
On Wed, 2022-04-27 at 21:40 +0530, Nilesh Patra wrote: > The default/expected behaviour just after package install is that as > soon as the user starts it and visits (talking about local setup here) > localhost: they should be seeing a welcome page. Since the package manager cannot know at what

feedback for NEW packages: switch to using the BTS?

2022-04-27 Thread Paul Wise
Hi all, During the discussions about NEW on debian-devel in recent times, I had the idea that instead of the current mechanism of sending REJECT mails, Debian could switch to using the BTS for most feedback on NEW packages. This means that most discussion about NEW packages would become public,

Re: shim-signed (was: Firmware - what are we going to do about it?)

2022-04-26 Thread Paul Wise
On Tue, 2022-04-26 at 20:41 +0200, Bastian Blank wrote: > secure boot signing process at Microsoft is a review-sign process What kind of review are Microsoft doing of the Debian shim? Are they reviewing the source and checking for a reproducible build? -- bye, pabs

Re: shim-signed (was: Firmware - what are we going to do about it?)

2022-04-23 Thread Paul Wise
On Sat, 2022-04-23 at 18:21 +0100, Steve McIntyre wrote: > If you don't like the fact that Microsoft's keys are involved, > it's possible on a lot of machines to enrol your own keys On machines where this isn't possible in the UEFI firmware interface, IIRC shim-signed is designed to allow you to

Re: Firmware - what are we going to do about it?

2022-04-21 Thread Paul Wise
On Thu, 2022-04-21 at 11:12 +0200, Mattias Wadenstein wrote: > For free software reasons, I believe that Debian should encourage this > method of distribution too, because it opens up the option for free > firmware to be developed as replacement for the non-free ones (or > encouraging vendors

Re: Firmware - what are we going to do about it?

2022-04-21 Thread Paul Wise
On Wed, 2022-04-20 at 15:32 +0800, Paul Wise wrote: > what other support Debian could give to libre/open firmware projects. Some ideas for this: We could package the libre/open firmware projects that are missing. We could lobby hardware vendors to release their existing proprietary firmw

Re: Firmware - what are we going to do about it?

2022-04-20 Thread Paul Wise
On Tue, 2022-04-19 at 01:27 +0100, Steve McIntyre wrote: > TL;DR: firmware support in Debian sucks, and we need to change this. After some discussion on #debian-www with sney (author of the current auto-download page) and larjona (web team), my preferred solution to this issue looks somewhat

Re: Firmware - what are we going to do about it?

2022-04-20 Thread Paul Wise
On Tue, 2022-04-19 at 01:27 +0100, Steve McIntyre wrote: > There are a number of issues here that make developers and users unhappy: There are a couple more issues related to unredistributable firmware: Some firmware is only available in the operating system preinstalled on the device and needs

Re: Firmware - what are we going to do about it?

2022-04-20 Thread Paul Wise
On Tue, 2022-04-19 at 01:27 +0100, Steve McIntyre wrote: > We have a small set of Free firmware binaries included in Debian main, and > these are included on our installation and live media. This is great - we all > love Free Software and this works. There is a list of libre firmware projects on

Re: Firmware - what are we going to do about it?

2022-04-20 Thread Paul Wise
On Tue, 2022-04-19 at 11:33 +0200, Christian Kastner wrote: > Here's a somewhat radical idea: I propose that we make option (1) and > (2) conditional on all Debian infra switching to hardware entirely free > of binary firmware/microcode blobs. > > Because if *we* can't do it, then imposing this

Re: writing REJECTED messages publicly on the ITP bugs (was: secnet_0.6.2_multi.changes REJECTED)

2022-04-11 Thread Paul Wise
On Mon, 2022-04-11 at 23:34 +0200, Thomas Goirand wrote: > Any idea how we could automate the Reply-To: thingy in a REJECTED > action, depending on uploader's preference? (not: I'm not > volunteering, just trowing a piece of idea... :) Here is an idea I posted on IRC a while back that should

Re: debian-faq in NEW - or: remove documentation from the archive at all

2022-04-04 Thread Paul Wise
On Mon, 2022-04-04 at 20:52 +0200, Joost van Baal-Ilić wrote: > Maybe in a next upload of debian-faq, we could get rid of this by-hand stuff. > Afaik it's only used to get the FAQ content published at > https://ftp.debian.org/debian/doc/ I think it would be better to send a dak patch turning the

Re: isa-support -- exit strategy?

2022-03-25 Thread Paul Wise
Adam Borowski wrote: > * new installs fail quite late into installation process, leaving you >   with a bunch of packages unpacked but unconfigured; some apt >   frontends don't take this situation gracefully. Maybe install isa-support by default and add an apt hook similar to the apt-listbugs

Re: on debomatic-*.debian.net unable to build bullseye and bullseye-backports

2022-03-23 Thread Paul Wise
On Wed, 2022-03-23 at 11:13 +0100, Fabio Fantoni wrote: > Is there someone else who has access to those servers and can please fix? AFAIK Luca Falavigna is the only one with access. There are alternatives to the debomatic hardware listed here:

Re: funding salsa runners for planning transitions with lots of reverse build deps

2022-03-22 Thread Paul Wise
Jérémy Lal wrote: > I asked, and got that answer: > "The shared runners are definitely not for such kind of rebuilds." > https://salsa.debian.org/salsa/support/-/issues/291#note_301386 Perhaps the existing infra for archive-wide rebuilds could be used?

Re: Q: systemd-timer vs cron

2022-03-15 Thread Paul Wise
On Tue, 2022-03-15 at 13:28 +, Luca Boccassi wrote: > Yes indeed, logs can be filtered by invocation id, eg: > > journalctl INVOCATION_ID=abcdefg That sounds useful. > Also to make a unit's log "private" (not stored in the system journal) > LogNamespace= can be used, see: > >

Re: Q: systemd-timer vs cron

2022-03-14 Thread Paul Wise
On Mon, 2022-03-14 at 11:47 +0100, Marco d'Itri wrote: > Yes, this is true. These are the unit and script that I use, and I think > that Debian would benefit from having something like this available in > some common package. ... > $(systemctl status "$FAILED_UNIT" --full --lines=100)

Re: Q: systemd-timer vs cron

2022-03-14 Thread Paul Wise
On Mon, 2022-03-14 at 07:11 +0100, Michael Biebl wrote: > See https://lists.debian.org/debian-devel/2020/01/msg00205.html AFAICT OnSuccess/OnFailure services don't recieve the output of the succeeding/failing service. So the mail sending service needs to dig around in the systemd journal. Or

Re: Q: systemd-timer vs cron

2022-03-13 Thread Paul Wise
On Sun, 2022-03-13 at 18:02 +0100, Christian Kastner wrote: > I don't think that's a very constructive line of argument. As a former > maintainer, it was evident that user crontabs (crontab -e) are still > very popular, as are some other perhaps niche features, and I've never > had the impression

Re: Q: systemd-timer vs cron

2022-03-11 Thread Paul Wise
Hideki Yamane wrote: > Is there any suggestion or guideline for pacakges that contain > both systemd-timer unit setting and cronjob? Don't they conflict > or not Do what apt does; make the cron job exit successfully without doing anything when run on systemd, move most of what is being run into

Re: Bug#1005858: gh,gitsome: File conflict, both ship /usr/bin/gh

2022-02-26 Thread Paul Wise
Control: forwarded -1 https://github.com/donnemartin/gitsome/issues/177 On Sat, 26 Feb 2022 23:43:14 +0800 SZ Lin (林上智) wrote: > The "gitsome" has used "gh" since 2017, and thus would you mind renaming > the "gh" in your package to avoid the conflict issue? Since gh is the official GitHub

Re: MBF: valgrind-if-available

2022-02-20 Thread Paul Wise
On Sun, 2022-02-20 at 19:45 +0100, Adam Borowski wrote: > A lot of packages Build-Depend on valgrind, in order to run checks for > memory leaks, data races and what not during the testsuite.  Alas, valgrind > is not available on some architectures, even release (armel) or want-to-be- > release

Re: Including build metadata in packages

2022-02-16 Thread Paul Wise
On Wed, 2022-02-16 at 16:51 +, Simon McVittie wrote: > If the maintainers of dak (our eternally overworked ftp team) want to > pick up build logs as first-class artifacts produced by both failed > and successful builds, they're welcome to do so (and then handling my > prototype of test

Re: Including build metadata in packages

2022-02-16 Thread Paul Wise
Simon McVittie wrote: > Relatedly, I would like to be able to capture some information about > builds even if (perhaps especially if) the build fails. That is a good point that I hadn't considered. > so that failing builds can also produce artifacts, to help the > maintainer and/or porters to

Re: Including build metadata in packages

2022-02-14 Thread Paul Wise
On Sun, 2022-02-13 at 14:13 -0800, Vagrant Cascadian wrote: > * Split build metadata into a separate file or archive > > Some of the debian-installer packages generate tarballs that are not > .deb files and are included in the .changes files when uploading to > the archive; making a similar

Re: We should trim the base system to be more container friendly

2022-02-11 Thread Paul Wise
On Tue, 2022-02-08 at 15:57 +0100, Raphael Hertzog wrote: > We should trim the base system to be more container friendly IIRC Helmut Grohne etc have already been working on this for years: https://wiki.debian.org/Proposals/EssentialOnDiet -- bye, pabs https://wiki.debian.org/PaulWise

Re: Embedded buildpath via rpath using cmake

2022-02-03 Thread Paul Wise
Vagrant Cascadian wrote: > Over the last several months, I and others have found quite a few > packages that embed build paths via rpath when building with cmake. This seems like the sort of thing that will be an ongoing problem, so if it is detectable statically then a lintian warning might be

Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not

2022-01-23 Thread Paul Wise
On Sun, 2022-01-23 at 17:43 -0500, Theodore Y. Ts'o wrote: > That only works if there are no other packages depending on those > shared libraries which are coming from other source packages. I don't think that is true, I believe you can put multiple things in the depends section of an shlibs

Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not

2022-01-21 Thread Paul Wise
On Fri, 2022-01-21 at 13:55 -0500, Theodore Ts'o wrote: > Can we have better automated tooling, either in Lintian, or in when > source packages are rebuilt, that can take care of this? > > The other thing that's perhaps considering here is that unfortunately, > there are some upstreams that are

Re: build-depend on autoconf-archive and rm convenience copy in orig.tar.gz?

2022-01-19 Thread Paul Wise
On Wed, 2022-01-19 at 18:43 +0200, Thomas Koch wrote: > My package ships two convenience copies from autoconf-archive in it's > m4 folder. Should I In my experience with libpst, it had embedded copies of Python/boost macros from autoconf-archive that were modified and the modifications hadn't

Bug#1003714: ITP: oci-cli -- Command Line Interface for Oracle Cloud Infrastructure

2022-01-13 Thread Paul Wise
Package: wnpp Severity: wishlist Owner: Paul Wise X-Debbugs-Cc: debian-devel@lists.debian.org, debian-cl...@lists.debian.org Control: block -1 by 1003372 * Package name: oci-cli Version : 3.4.1 Upstream Author : Mike Ross and others at Oracle * URL :  https

Bug#1003376: ITP: python-circuitbreaker -- Python "Circuit Breaker" implementation

2022-01-08 Thread Paul Wise
Package: wnpp Severity: wishlist Owner: Paul Wise X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org Control: block 1003372 by -1 * Package name: python-circuitbreaker Version : 1.3.2 Upstream Author : Fabian Fuelling * URL : https

Bug#1003372: ITP: oci-python-sdk -- Oracle Cloud Infrastructure Python SDK

2022-01-08 Thread Paul Wise
Package: wnpp Severity: wishlist Owner: Paul Wise X-Debbugs-Cc: debian-devel@lists.debian.org, debian-cl...@lists.debian.org * Package name: oci-python-sdk Version : 2.53.1 Upstream Author : Vyas Bhagwat and others * URL : https://github.com/oracle/oci-python-sdk

Re: Evolution

2022-01-04 Thread Paul Wise
On Fri, 2021-12-31 at 09:10 -0500, Devops PK Carlisle LLC wrote: > Just a quick question as to whether Evolution Mail is still > supported/updated? You have already gotten an answer, but for future reference, this sort of question should be asked on Debian support channels not debian-devel.

Re: Bug#1001903: ITP: loki-database -- Like Prometheus, but for logs.

2021-12-18 Thread Paul Wise
On Sat, 2021-12-18 at 12:20 -0500, Sean Anderson wrote: > The upstream package name conflicts with the existing package loki > ("MCMC linkage analysis on general pedigrees"). However, that package is > "dead upstream" (according to debian/watch), so perhaps this package can > get the name

Bug#1001876: ITP: mpv-mpris -- MPRIS plugin for mpv

2021-12-17 Thread Paul Wise
Package: wnpp Severity: wishlist Owner: Paul Wise X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: mpv-mpris Version : 0.6 Upstream Author : Ho-Yon Mak * URL : https://github.com/hoyon/mpv-mpris * License : MIT Programming Lang: C Description

Re: chromium: Update to version 94.0.4606.61 (security-fixes)

2021-12-17 Thread Paul Wise
On Fri, 2021-12-17 at 11:28 +0100, Moritz Mühlenhoff wrote: > Could anyone who's using Chromium on Debian please create a page on > wiki.debian.org which lists the alternative options to use a current > Chromium (Flatpak, ungoogled Chromium from elsewhere, snap, whatever > else there is)? The

Re: facility to access the NEWS content

2021-12-13 Thread Paul Wise
On Mon, 2021-12-13 at 19:55 +0100, Patrice Duroux wrote: > Packages may provide a NEWS (or any other name, compressed or not, etc.) file Since that is an upstream file, it is not standard across all Debian package upstreams, including the name, file type and contents. Different subsets of

Re: Using release-monitoring.org [was: uscan roadmap]

2021-12-04 Thread Paul Wise
On Sat, 2021-12-04 at 02:43 +, Scott Kitterman wrote: > I think that there's a security consideration associated with all these > proposals for externalizing finding upstream updates.  Good point. > If one of these services were ever compromised it would provide a > vector for offering

Re: Using release-monitoring.org [was: uscan roadmap]

2021-12-03 Thread Paul Wise
On Fri, 2021-12-03 at 13:12 +0100, Stephan Lachnit wrote: > I mean it looks rather easy to do, just a couple of mouse clicks. > Compare that to writing a watch file at the moment (assuming one has > to do more than copy and paste the github example). Repology gets you mappings for all the source

Re: /usr/bin/ld.so as a symbolic link for the dynamic loader

2021-12-02 Thread Paul Wise
Florian Weimer wrote: > I'd like to provide an ld.so command as part of glibc. Will this happen in glibc upstream or just in Debian? > Today, ld.so can be used to activate preloading, for example. > Compared to LD_PRELOAD, the difference is that it's specific to one > process, and won't be

Re: Using release-monitoring.org [was: uscan roadmap]

2021-12-02 Thread Paul Wise
On Thu, 2021-12-02 at 23:36 +0100, Stephan Lachnit wrote: > If I understand correctly, release-monitoring already offers such a > mapping [1]. It seems like the Ayanita distro mapping needs to be done manually once per package, while using the Repology data would automatically get us the mapping

Re: uscan roadmap

2021-12-02 Thread Paul Wise
On Thu, 2021-12-02 at 10:16 +0100, Yadd wrote: > Yes but the redirector often responded with 500 codes 500 codes probably just mean bugs in the redirector, which should be easy to fix for anyone with access to the redirector source code. -- bye, pabs https://wiki.debian.org/PaulWise

Re: Using release-monitoring.org [was: uscan roadmap]

2021-12-02 Thread Paul Wise
On Thu, 2021-12-02 at 15:57 +0100, Stephan Lachnit wrote: > I think this would be the best path forward - it would probably be not > easy given that it changes entirely how the current system works, but > it might be well worth the effort. Working together with another > distribution would share

Re: uscan roadmap

2021-12-01 Thread Paul Wise
On Wed, 2021-12-01 at 09:11 +0100, Yadd wrote: > after few discussions with some devscripts maintainers, we decided to > build a new "version=5" format for debian/watch. It might be a idea to look at how other distributions do checking for new upstream releases and adopt some of their

Re: uscan roadmap

2021-12-01 Thread Paul Wise
On Wed, 2021-12-01 at 12:53 +0100, Yadd wrote: > sf.net because it needs JS interpretation The sf.net redirector uses the RSS feed of the files. This is documented at the top of the redirector HTML: $ curl -s https://qa.debian.org/watch/sf.php/NSIS/ | grep -i rss

Re: uscan roadmap

2021-12-01 Thread Paul Wise
On Wed, 2021-12-01 at 12:53 +0100, Yadd wrote: > Personally I dislike redirectors. A redirector service is superior to including the redirector code within uscan itself or within a debian/watch file, since when the upstream website breaks the existing code, a service can be updated in one place

  1   2   3   4   5   6   7   8   9   10   >