Hi,
two packages[¹, ²] I uploaded are "Rejected due to piuparts
regression". I learned, that this is due to a bug in piuparts.
Any solution on its way? Would I need to re-upload later?
TIA & Cheers
PS: Many thanks for running piuparts anyway. Such bugs happen,
but the extra safety net it provide
Am 02.01.2020 um 12:03 schrieb W. Martin Borgert:
> Hi,
>
> two packages[¹, ²] I uploaded are "Rejected due to piuparts
> regression". I learned, that this is due to a bug in piuparts.
> Any solution on its way? Would I need to re-upload later?
>
> TIA & Cheers
>
> PS: Many thanks for running piu
On Thu, Jan 2, 2020 at 12:03:43 +0100, W. Martin Borgert wrote:
> Hi,
>
> two packages[¹, ²] I uploaded are "Rejected due to piuparts
> regression". I learned, that this is due to a bug in piuparts.
> Any solution on its way? Would I need to re-upload later?
>
No, it'll eventually get retried a
Package: wnpp
Severity: wishlist
Owner: Thomas Goirand
* Package name: opentmpfiles
Version : 0.2
Upstream Author : William Hubbs
* URL : https://github.com/OpenRC/opentmpfiles
* License : BSD-2-clause
Programming Lang: Shell
Description : standalone u
As I wrote, no need to complain, but act.
https://salsa.debian.org/debian/opentmpfiles
https://salsa.debian.org/debian/opensysusers
Both are now in the NEW queue, and both need some kind of init.d sysv-rc
script. Please anyone, contribute that init script.
My proposal is for Debian to standardiz
Hi Thomas,
Thank you for working on these!
On Thu, Jan 02, 2020 at 02:14:34PM +0100, Thomas Goirand wrote:
> As I wrote, no need to complain, but act.
>
> https://salsa.debian.org/debian/opentmpfiles
> https://salsa.debian.org/debian/opensysusers
>
> Both are now in the NEW queue, and both need
My understanding is that systemd's implementation of tmpfiles and
sysusers works even while systemd is not pid 1.
Why do we need multiple implementations for Debian ports where systemd
runs?
I understand why we might want alternatives for kfreebsd and hurd.
But if my understanding that the systemd
Hi!
El jue., 2 ene. 2020 08:28, Julien Cristau escribió:
> On Thu, Jan 2, 2020 at 12:03:43 +0100, W. Martin Borgert wrote:
>
> > Hi,
> >
> > two packages[ą, ˛] I uploaded are "Rejected due to piuparts
> > regression". I learned, that this is due to a bug in piuparts.
> > Any solution on its way
Hi everyone!
Sorry for the delayed reply, I was busy with traveling around during
the new year. For that matter: Happy new year! :-)
I am the upstream maintainer of AppStream as well as in Debian.
Am Mi., 1. Jan. 2020 um 13:17 Uhr schrieb Jeff :
>
> Firstly - apologies for sending this to -devel.
On Thu, Jan 2, 2020 at 9:22 PM Thomas Goirand wrote:
[...]
> My proposal is for Debian to standardize on:
> /bin/tmpfiles
>
> and:
> /usr/bin/sysusers
>
I don't understand why we need these.
The advantages of sysusers.d and tmpfiles.d are that you don't need to
call some magic scripts.
You only
Thomas Goirand writes:
> My proposal is for Debian to standardize on:
> /bin/tmpfiles
> and:
> /usr/bin/sysusers
Why rename things?
> I'm not sure why
> there's both /bin/systemd-sysusers and /usr/bin/systemd-sysusers, and
> which one should be used.
For the same reason there is /bin/bash and /u
Am Do., 2. Jan. 2020 um 17:28 Uhr schrieb Ansgar :
>
> Thomas Goirand writes:
> > [...]
> > I'm not sure why
> > there's both /bin/systemd-sysusers and /usr/bin/systemd-sysusers, and
> > which one should be used.
>
> For the same reason there is /bin/bash and /usr/bin/bash probably?
I don't have b
On Fri, 03 Jan 2020 at 00:05:10 +0800, Shengjing Zhu wrote:
> On Thu, Jan 2, 2020 at 9:22 PM Thomas Goirand wrote:
> [...]
> > My proposal is for Debian to standardize on:
> > /bin/tmpfiles
> >
> > and:
> > /usr/bin/sysusers
FWIW, the systemd versions of both tools are canonically in /bin (that's
On Thu, 02 Jan 2020 at 09:03:24 -0500, Sam Hartman wrote:
> My understanding is that systemd's implementation of tmpfiles and
> sysusers works even while systemd is not pid 1.
> Why do we need multiple implementations for Debian ports where systemd
> runs?
I think this is partly down to whether th
Am Do., 2. Jan. 2020 um 18:41 Uhr schrieb Simon McVittie :
> [...]
> I seem to remember a systemd upstream developer being asked during
> recent discussions whether they were willing to guarantee that
> systemd-tmpfiles and systemd-sysusers will continue to work when used on
> non-systemd-booted sy
> "Simon" == Simon McVittie writes:
Simon> I think this is partly down to whether the systemd maintainers (both
Simon> upstream and downstream) are willing to support this use, or whether
Simon> they would prefer non-systemd-booted systems to use a
reimplementation
Simon> wh
Matthias Klumpp writes:
> I find that statement quite encouraging. Of course they don't commit
> to not having those depend on systemd-as-PID1, but there really isn't
> a reason to create that dependency, and if for whatever reason there
> will be one at some point, we can switch away on systems
Simon McVittie writes:
> Using dpkg triggers to run the tmpfiles and sysusers tools automatically
> is probably not enough, because a package's postinst will often run
> system services (systemd unit, LSB init script, etc.), and those system
> services need to be run *after* creating at least thi
Package: wnpp
Severity: wishlist
Owner: Sascha Steinbiss
* Package name: vmatch
Version : 2.3.0
Upstream Author : Stefan Kurtz
* URL : http://vmatch.de
* License : ISC
Programming Lang: C
Description : large scale sequence analysis software
Vmatch is a
I've reviewed your proposal.
It seems sane, but is not something I'd contribute to this year.
I would potentially use a really good version of this as an uploader.
I'd ask you to consider how to minimize the debian/copyright.
Since you don't want to have wildcards for files in
debian/copyright.j
Package: general
Severity: normal
I have an external screen connected to my notebook computer (Dell XPS 13).
After waking the notebook from sleep mode, the windows that have been opened
before activating sleep mode are blurry. Newly opened windows are not affected.
The issue happens with windows f
Hello,
Matthias Brennwald, le jeu. 02 janv. 2020 20:06:27 +0100, a ecrit:
> the windows that have been opened before activating sleep mode are
> blurry. Newly opened windows are not affected.
> The issue happens with windows from all programs, not just a specific program.
> Moving or resizing the
Out of interest I've checked the state of sid vs buster debootstrap
--variant=minbase chroots to see if it's been growing while nobody has been
paying attention. Apparently we have a couple of regressions. Sharing this in
case someone else is interested in the result (or atleast hoping to wake
some
On Thu, 02 Jan 2020 at 20:15:29 +0100, Samuel Thibault wrote:
> Hello,
>
> Matthias Brennwald, le jeu. 02 janv. 2020 20:06:27 +0100, a ecrit:
> > the windows that have been opened before activating sleep mode are
> > blurry. Newly opened windows are not affected.
> > The issue happens with windows
On Jan 02, Thomas Goirand wrote:
> My proposal is for Debian to standardize on:
> /bin/tmpfiles
>
> and:
> /usr/bin/sysusers
We already have an interface used by many packages, hence I see no
reason to change it.
Actually it is still not obvious to me why Debian would need a second
implementa
Package: wnpp
Severity: wishlist
Owner: Raju Devidas
X-Debbugs-CC: debian-devel@lists.debian.org,
pkg-go-maintain...@lists.alioth.debian.org,
* Package name : aerc
Version : 0.3.0
Upstream Author : Drew Devault
* URL : https://git.sr.ht/~sircmpwn/aerc/
* License
On 2020-01-02 11:53, Lisandro Damián Nicanor Pérez Meyer wrote:
> El jue., 2 ene. 2020 08:28, Julien Cristau escribió:
> > No, it'll eventually get retried and (assuming it passes) the migration
> > block will lift.
>
> And "eventually" is normally how many days?
If I've learned one thing in Debi
On 02/01/2020 16:53, Matthias Klumpp wrote:
> @Jeff Did your changes include adding a launchable tag? If not, adding
> one may already fix this issue.
Yes, I had.
> When transitioning:
> 1) Make sure you add a launchable tag - it may not be essential, but
> it certainly is more explicit. Also, y
On 01/01/2020 21:34, Simon McVittie wrote:
> Again, any changes to the .desktop filename should happen upstream first.
In this case, I am also upstream. But your point is well made.
> If you're using GLib, check that g_get_prgname() (which defaults to the
> basename of the executable) is what you
Simon McVittie:
> [...]
>
> The opentmpfiles and opensysusers packaging will need to arrange to do
> something analogous, most likely in cooperation with dh_installsystemd
> or some other debhelper step for the first two points, and with LSB init
> scripts for the tasks where systemd uses one-shot
On Thu, 02 Jan 2020 at 22:07:04 +0100, Jeff wrote:
> On 01/01/2020 21:34, Simon McVittie wrote:
> > If you're using GLib, check that g_get_prgname() (which defaults to the
> > basename of the executable) is what you want it to be. When using a
> > reversed-domain-name app ID but not using GApplicat
Am Do., 2. Jan. 2020 um 21:58 Uhr schrieb Jeff :
>
> On 02/01/2020 16:53, Matthias Klumpp wrote:
> > @Jeff Did your changes include adding a launchable tag? If not, adding
> > one may already fix this issue.
>
> Yes, I had.
>
> > When transitioning:
> > 1) Make sure you add a launchable tag - it m
[ please keep me in CC, I'm not subscribed to this list]
Sam Hartman wrote:
> My understanding is that systemd's implementation of tmpfiles and
> sysusers works even while systemd is not pid 1.
> Why do we need multiple implementations for Debian ports where systemd
> runs?
> I understand why we
The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.
Total number of orphaned packages: 1247 (new: 17)
Total number of packages offered up for adoption: 236 (new: 0)
Total number of packages reque
> "Lorenz" == Lorenz writes:
Lorenz> Sam Hartman wrote:
>> My understanding is that systemd's implementation of tmpfiles and
>> sysusers works even while systemd is not pid 1.
>> Why do we need multiple implementations for Debian ports where systemd
>> runs?
>> I unde
Package: wnpp
Severity: wishlist
Owner: Sascha Steinbiss
* Package name: python-msoffcrypto-tool
Version : 4.10.1
Upstream Author : nolze
* URL : https://github.com/nolze/msoffcrypto-tool
* License : MIT
Programming Lang: Python
Description : Python too
36 matches
Mail list logo
