Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Peter Pentchev]

On Thu, May 30, 2024 at 08:35:47AM +0200, Johannes Schauer Marin Rodrigues 
wrote:
> Hi,
> 
> Quoting Luca Boccassi (2024-05-28 01:54:08)
> > Thanks for the useful input, the following has been done:
> > 
> > - existing installations pre-trixie will get an orphaned tmpfiles.d in
> > /etc/ that keeps the existing behaviour unchanged (no cleanup of
> > /var/tmp)
> > - openssh and tmux have been fixed to provide a tmpfiles.d exception
> > to retain their respective files
> > - the /tmp/ description in debian-installer has been updated to note
> > it is a tmpfs by default (via a commit in partman-basicfilesystems,
> > will upload if nobody gets around to it before Trixie's freeze)
> > - two paragraphs have been provided for the release notes ticket
> > - the changes are also noted in NEWS, with instructions on how to
> > override locally
> > - as mentioned, the latest upload to unstable makes /tmp/ a tmpfs by
> > default and for new installations 10+ days old files in /tmp/ and 30+ days
> > old files in /var/tmp/ are cleaned up daily
> 
> thank you for having discussed this change on d-devel and for adding
> documentation to NEWS and release notes to announce this change. I also think
> it is sensible to roll this only out on new installations and to keep the
> behaviour on existing setups. Thank you for implementing that as well.
> 
> That being said, maybe some Perl wizard knows how to do a flock on a directory
> in Perl?

I wouldn't call myself a Perl wizard by a long stretch, but I can give it a try 
:)

>  I tried this:
> 
> use Fcntl qw(LOCK_EX);
> opendir(my $handle, ".") or die "opendir: $!";
[snip]

Here lies your problem. The flock(2) syscall works on file descriptors,
the things returned by open(2), not on the dirent structures returned by
opendir(3). So you need something like this:

use v5.10;  # I really should switch to at least 5.16 if not 5.24
use strict;
use warnings;

use Fcntl qw(O_RDONLY O_DIRECTORY LOCK_EX);

my $dirname = "/tmp/to-be-locked";
sysopen(my $handle, "/tmp/to-be-locked", O_RDONLY | O_DIRECTORY) or
die "Could not open $dirname: $!\n";
flock($handle, LOCK_EX) or
die "Could not lock $dirname: $!\n";

say "locked, it seems";
sleep(3600);'

I only put the sleep() part so I could check using lsof that
the directory was indeed locked. And yeah, the v5.10 part is a leftover
from the days (...until a month or two ago...) when I still had to
support stock CentOS 7 systems; I really should train my fingers to
put 5.24 there.

Hope that helps!

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org pe...@morpheusly.com
PGP key:https://www.ringlet.net/roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Bug#1072208: ITP: python-coriolisclient -- client bindings and cli to the Coriolis migration API

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: python-coriolisclient
  Version : 1.0.9
  Upstream Contact: Cloudbase Solutions Srl 
* URL : https://github.com/cloudbase/python-coriolisclient
* License : Apache-2.0
  Programming Lang: Python
  Description : client bindings and cli to the Coriolis migration API

 The Coriolis command-line API offers an interface over the REST API provided
 by the Coriolis migration service.
 .
 This package contains the a client for the Coriolis API. There's a Python API
 (the "coriolisclient" module), and a command-line script ("coriolis").

Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Hakan Bayındır]

> On 30 May 2024, at 09:15, Marc Haber  wrote:
> 
> On Wed, 29 May 2024 14:35:27 +0300, Hakan Bay?nd?r
>  wrote:
>> I'll kindly disagree here. I'd rather not have to go back to every 
>> system and make sure that they all behave the way I want after doing a 
>> periodic, completely boring "apt-get upgrade".
> 
> This change is likely to come to the majority of our installations
> ("stable") with a release upgrade, which is never boring, but one of
> the most exciting things that can happen to a Debian stable system.

You’re right, new Debian releases always brings me joy too. I used “completely 
boring” in a positive way, to underline how uneventful a Debian release upgrade 
is in 99.999% of the time. In other words, I wanted to underline that I prefer 
the next release would be what I expect from Debian. Upgrade, reboot, continue 
drinking coffee and do productive things.

If a new installation comes with different defaults, as I said before, I’m OK 
with that. Software evolves, and should evolve. What I don’t prefer is forcing 
on this evolution on me, on an established system. I work with a lot of 
servers. I don’t want to worry about uncontrolled configuration changes 
happening on updates.

> 
> People doing this responsibly read the release notes before beginning,
> and those release notes have in the past contained things that needed
> doing manually in the process such as the well-known "please upgrade
> kernel first and reboot" during one udev/systemd upgrade.

I also read the release notes and any caveats and warnings before starting, 
however what I don’t expect is to reconfigure a fleet of servers to restore 
some settings which I customized for the particular role and software on that 
server. I know configuration changes are negotiated during upgrades, but when 
partition changes and automated deletion schedules are “inflicted”, that’s 
something bigger than “we upgraded this daemon/tool and brought better 
defaults, wanna look?” Which happens during upgrades.

> Ubuntu seems to have put the release notes in an automatism disguise
> called do-release-upgrade which probably changes from release to
> release regarding what specialty is in the store for this update. We
> don't have that, we ask our users to read the release notes.

I’m not a big fan of Ubuntu and how they do things, and I don’t use it. I 
prefer Debian to be Debian and to need some RTFM process to administer 
correctly. I’m an old school person and sysadmin. I prefer a more direct, “this 
machine has no brain, use yours” approach. :)

> Greetings
> Marc

Hope I managed to express myself in an understandable way this time. :)

Cheers,

H.

> -- 
> 
> Marc Haber |   " Questions are the | Mailadresse im Header
> Rhein-Neckar, DE   | Beginning of Wisdom " | 
> Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Re: Y2038-safe replacements for utmp/wtmp and lastlog

[Vincent Lefevre]

On 2024-05-08 16:53:53 +0800, Jun MO wrote:
> For last(1) my concern is that it will be helped to keep the original
> last(1) for back-compatibility to read old wtmp files.

I agree, this may be useful. Unfortunately, the current status is
that one cannot have both: installing wtmpdb forces the upgrade of
util-linux to 2.40.1-3 (at least), where "last" is no longer installed.

However, I think that it is better to archive human-readable text files
(generated by "last" in the past) rather than the wtmp files.

I've used the attached script to get both the IP addresses and the
host names with "last" (I don't know whether there's a better way to
get full information).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
#!/usr/bin/env perl

# Output wtmp logs, based on command 'last' from util-linux.
# This command is called twice:
#   1. without the -d option;
#   2. with the -d option to get the host names.

use strict;

my ($proc) = '$Id: lastf 103313 2017-11-06 01:47:30Z vinc17/joooj $'
  =~ /^.Id: (\S+) \d+ / or die;

@ARGV == 1 or $! = 1, die "Usage: $proc \n";
-f $ARGV[0] or $! = 1, die "$proc: $ARGV[0] is not a regular file\n";
-r $ARGV[0] or $! = 1, die "$proc: $ARGV[0] is not a readable file\n";

sub rdlog ($@)
  {
my $file = shift;
open LAST, '-|', 'last', @_, '-axf', $file
  or die "$proc: can't exec 'last': $!";
my @t = ;
close LAST, or die "$proc: 'last' failed: $!";
$t[-1] =~ / begins / && $t[-2] eq "\n"
  or $! = 2, die "$proc: bad format";
return @t;
  }

my @t1 = rdlog $ARGV[0];
my @t2 = rdlog $ARGV[0], '-d';
$#t1 == $#t2 or $! = 1, die "$proc: bad length ($#t1 vs $#t2)\n";
$t1[-1] eq $t2[-1] or die $! = 1, die "$proc: inconsistent last line\n";

foreach my $i (0..$#t1-2)
  {
$_ = $t1[$i];
chomp;
my ($u1) = /^(.){60}/
  or $! = 2, die "$proc: bad format";
my ($u2,$v2) = $t2[$i] =~ /^(.){60}(.*)$/
  or $! = 2, die "$proc: bad format";
$u1 eq $u2 or $! = 2, die "$proc: bad format";
$v2 eq '0.0.0.0' or $_ .= " ($v2)";
print "$_\n";
  }

print "\n$t1[-1]";

Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Peter Pentchev (2024-05-30 10:33:08)
> > thank you for having discussed this change on d-devel and for adding
> > documentation to NEWS and release notes to announce this change. I also
> > think it is sensible to roll this only out on new installations and to keep
> > the behaviour on existing setups. Thank you for implementing that as well.
> > 
> > That being said, maybe some Perl wizard knows how to do a flock on a 
> > directory
> > in Perl?
> 
> I wouldn't call myself a Perl wizard by a long stretch, but I can give it a 
> try :)
> 
> >  I tried this:
> > 
> > use Fcntl qw(LOCK_EX);
> > opendir(my $handle, ".") or die "opendir: $!";
> [snip]
> 
> Here lies your problem. The flock(2) syscall works on file descriptors,
> the things returned by open(2), not on the dirent structures returned by
> opendir(3). So you need something like this:
> 
> use v5.10;  # I really should switch to at least 5.16 if not 5.24
> use strict;
> use warnings;
> 
> use Fcntl qw(O_RDONLY O_DIRECTORY LOCK_EX);
> 
> my $dirname = "/tmp/to-be-locked";
> sysopen(my $handle, "/tmp/to-be-locked", O_RDONLY | O_DIRECTORY) or
> die "Could not open $dirname: $!\n";
> flock($handle, LOCK_EX) or
> die "Could not lock $dirname: $!\n";
> 
> say "locked, it seems";
> sleep(3600);'
> 
> I only put the sleep() part so I could check using lsof that
> the directory was indeed locked. And yeah, the v5.10 part is a leftover
> from the days (...until a month or two ago...) when I still had to
> support stock CentOS 7 systems; I really should train my fingers to
> put 5.24 there.
> 
> Hope that helps!

it absolutely does! Thank you! I was misled by `perldoc -f flock` which states
that it works on filehandles. I'll add your name to the git commit message
unless you object.  :)

I also found another issue with this change in systemd. After the upload to
unstable, 76 out of 264 mmdebstrap tests on jenkins.debian.net started to fail:

https://jenkins.debian.net/job/mmdebstrap-jenkins-worker/692/consoleText

The problem is, that debootstrap wants to mknod which will not work on a tmpfs
mounted with nodev:

+ debootstrap --no-merged-usr --variant=buildd oldstable /tmp/tmp.nWmx8YeAh3 
http://127.0.0.1/debian
/usr/sbin/debootstrap: 1840: cannot create /tmp/tmp.nWmx8YeAh3/test-dev-null: 
Permission denied
E: Cannot install into target '/tmp/tmp.nWmx8YeAh3' mounted with noexec or nodev

Maybe this affects more CI scripts and test setups which attempt to create a
temporary chroot with debootstrap in /tmp.

The fix which is documented in systemd NEWS makes everything work again:

--customize-hook='touch "$1/etc/systemd/system/tmp.mount"'

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1072217: ITP: senpai -- Modern terminal IRC client

[Guilherme Puida Moreira]

Package: wnpp
Severity: wishlist
Owner: Guilherme Puida Moreira 

* Package name: senpai
  Version : 0.3.0-1
  Upstream Author : delthas
* URL : https://git.sr.ht/~delthas/senpai
* License : ISC
  Programming Lang: Go
  Description : Modern terminal IRC client

 senpai is an IRC client that works best with bouncers:
  - no logs are kept,
  - history is fetched from the server via CHATHISTORY,
  - networks are fetched from the server via bouncer-networks,
  - messages can be searched in logs via SEACH.

senpai will be maintained under the go teams' umbrella.

--puida

Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Simon McVittie]

On Thu, 30 May 2024 at 15:41:50 +0200, Johannes Schauer Marin Rodrigues wrote:
> I also found another issue with this change in systemd. After the upload to
> unstable, 76 out of 264 mmdebstrap tests on jenkins.debian.net started to 
> fail:
> 
> https://jenkins.debian.net/job/mmdebstrap-jenkins-worker/692/consoleText
> 
> The problem is, that debootstrap wants to mknod which will not work on a tmpfs
> mounted with nodev:
> 
> + debootstrap --no-merged-usr --variant=buildd oldstable /tmp/tmp.nWmx8YeAh3 
> http://127.0.0.1/debian
> /usr/sbin/debootstrap: 1840: cannot create /tmp/tmp.nWmx8YeAh3/test-dev-null: 
> Permission denied
> E: Cannot install into target '/tmp/tmp.nWmx8YeAh3' mounted with noexec or 
> nodev
> 
> Maybe this affects more CI scripts and test setups which attempt to create a
> temporary chroot with debootstrap in /tmp.

I believe this arrangement would also fail if a separate on-disk /tmp
was mounted nodev (which is somewhat common security hardening advice,
although I don't know whether d-i sets this up if asked for a separate
/tmp).

In principle, even the root filesystem could probably be mounted nodev
these days, since /dev is typically a devtmpfs; but I've never tried it,
and I don't know whether anyone really does that.

> The fix which is documented in systemd NEWS makes everything work again:
> 
> --customize-hook='touch "$1/etc/systemd/system/tmp.mount"'

Alternatively, you could consider using somewhere like /var/tmp or
/var/cache/mmdebstrap that is less likely to be mounted nodev?

(As a bonus, those locations are normally on-disk and therefore less
likely to run out of space for chroots/filesystem images/etc. than /tmp.)

smcv

Re: Bug#1068017: Y2038-safe replacements for utmp/wtmp and lastlog

[Chris Hofstaedtler]

* Vincent Lefevre  [240530 13:21]:
> On 2024-05-08 16:53:53 +0800, Jun MO wrote:
> > For last(1) my concern is that it will be helped to keep the original
> > last(1) for back-compatibility to read old wtmp files.
> 
> I agree, this may be useful. Unfortunately, the current status is
> that one cannot have both: installing wtmpdb forces the upgrade of
> util-linux to 2.40.1-3 (at least), where "last" is no longer installed.

wtmpdb takes over the "last" name. Unfortunately without support for
reading the old files. Nobody wrote tooling to import them or so.

Chris

Re: Y2038-safe replacements for utmp/wtmp and lastlog

[Jun MO]

On Thu, 30 May 2024 13:18:17 +0200, Vincent Lefevre wrote:
> I agree, this may be useful. Unfortunately, the current status is
> that one cannot have both: installing wtmpdb forces the upgrade of
> util-linux to 2.40.1-3 (at least), where "last" is no longer installed.

Thanks for the change about version 2.40.1-3 of the util-linux package.
This is indeed mentioned in the NEWS.Debian from the 2.40.1-3 util-linux
package, and the NEWS.Debian also suggests installing wtmpdb. But
the last(1) from wtmpdb can not read /var/log/wtmp:

$ last -f /var/log/wtmp
wtmpdb_read_all: SQL error: file is not a database

And if I understood correctly, wtmpdb require program use PAM to update
wtmpdb, thus program not use PAM will still write /var/log/wtmp. For
example, tmux write /var/log/wtmp via libutempter0 and I do not see tmux
depends on pam. But now one can not read /var/log/wtmp neither from
util-linux or wtmpdb. Fortunately, last(1) only links to linux-vdso.so.1,
libc.so.6 and ld-linux-x86-64.so.2. One can extract the /usr/bin/last
binary from old util-linux .deb which can be downloaded from
snapshot.debian.org.

> However, I think that it is better to archive human-readable text files
> (generated by "last" in the past) rather than the wtmp files.
>
> I've used the attached script to get both the IP addresses and the
> host names with "last" (I don't know whether there's a better way to
> get full information).

I agree that human-readable text files are better than the wtmp binary
format files, if the text files provide all information or at least
information one wanted to keep. I find that last(1) may not print all
information, and you need some option to let it print something fully;
so I personally still prefer to keep those wtmp files. For example,
I have noted that the IPv6 address in the output of `last' is truncated
long time ago, and find just a couple of months ago that the -a option
will put the full address in the last column(I see you use that option
in your script). And the output from rotated files(e.g wtmp.1) may have
something like "gone - no logout". Provided the wtmp files are just
many "records" of raw data of C struct of "utmp"(defined in utmp.h, or
see `man 5 utmp'), one record for login, one record for logout,
one record for boot, etc, one can do something like:

$ cat /var/log/wtmp.1 /var/log/wtmp >> wtmp-combined
$ last -f wtmp-combined

The output will show when a user logout for those previously
"gone - no logout" lines. I just realize this about a month ago.

I know there is a utmpdump(1) in the util-linux package, that is still
available in 2.40.1-3 version. The command will dump more information
than last(1); but it is for every single records, one may need to
manually match login with logout, boot with shutdown, etc. Still it
seems to me some information, e.g. exit_status, are still missing.
For archive season, one may write a program that read the wtmp files
and dump all variables of the struct utmp.

And something "off topic". I find there is a char __glibc_reserved[20]
variable in the struct utmp, which is commented as "Reserved for
future use". Just a brainstorm, if this variable is not currently used,
maybe it can be used to solve the Y2038 problem for wtmp?

Regards,
Jun MO

Re: Bug#1068017: Y2038-safe replacements for utmp/wtmp and lastlog

[Chris Hofstaedtler]

* Jun MO  [240530 19:09]:
> On Thu, 30 May 2024 13:18:17 +0200, Vincent Lefevre wrote:
> > I agree, this may be useful. Unfortunately, the current status is
> > that one cannot have both: installing wtmpdb forces the upgrade of
> > util-linux to 2.40.1-3 (at least), where "last" is no longer installed.
> 
> Thanks for the change about version 2.40.1-3 of the util-linux package.
> This is indeed mentioned in the NEWS.Debian from the 2.40.1-3 util-linux
> package, and the NEWS.Debian also suggests installing wtmpdb. But
> the last(1) from wtmpdb can not read /var/log/wtmp:
> 
> $ last -f /var/log/wtmp
> wtmpdb_read_all: SQL error: file is not a database
> 
> And if I understood correctly, wtmpdb require program use PAM to update
> wtmpdb, thus program not use PAM will still write /var/log/wtmp.

Yes. It appears it is unclear if programs that are not
login-equivalents should write to wtmp in the first place.

wtmpdb upstream leans - in my vague reading - towards "no".
 
Chris

Bug#1072247: ITP: qorganizer-eds -- QtOrganizer engine for EDS calendar

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: qorganizer-eds
  Version : 0.2.0
  Upstream Contact: UBports developers 
* URL : https://gitlab.com/ubports/development/core/qorganizer-eds

https://gitlab.com/ubports/development/core/qtorganizer5-eds (obsolete URL)
* License : GPL-3
  Programming Lang: C++
  Description : QtOrganizer engine for EDS calendar

 Qt Organizer provides clients with the ability to access calendar,
 schedule, and personal data in a platform-independent and
 datastore-agnostic manner. This is achieved by defining generic personal
 information data abstractions which can sufficiently describe calendar
 and scheduling data stored in the native calendaring system of a
 platform. Through the plugin architecture, Qt Organizer can be used as a
 front-end API for any calendaring system, such as an online calendar.
 .
 This package provides a QOrganizerEngine implementation using Evolution
 Data Server as storage backend.
 .
 This package will be maintained by the Debian UBports Packaging Team.

Nagrody

[Lysy Myc]

Wysłane ze smartfona w T-Mobile, sieci największych możliwości.
Wysłano z programu Outlook dla systemu Android

Bug#1072252: ITP: evolution-data-server-lomiri -- EDS extension used by Lomiri Apps

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: evolution-data-server-lomiri
  Version : 0.2.0
  Upstream Contact: UBports developers 
* URL : 
https://gitlab.com/ubports/development/core/evolution-data-server-lomiri/
* License : LGPL-3
  Programming Lang: C
  Description : EDS extension used by Lomiri Apps

 An EDS extension used by Lomiri apps to store extra metadata into EDS
 sources, directly required for qorganizer-eds.
 .
 This package will be maintained by the Debian UBports Packaging Team.

Re: Y2038-safe replacements for utmp/wtmp and lastlog

[Jakub Wilk]

* Jun MO , 2024-05-31 01:05:
And something "off topic". I find there is a char __glibc_reserved[20] 
variable in the struct utmp, which is commented as "Reserved for future 
use". Just a brainstorm, if this variable is not currently used, maybe 
it can be used to solve the Y2038 problem for wtmp?


Or, more easily, you could treat the timestamp as unsigned int:
https://sourceware.org/cgit/glibc/commit/?id=5361ad3910c257bc

"Architectures which use a 32-bit seconds-since-epoch field in struct 
lastlog, struct utmp, struct utmpx (such as i386, powerpc64le, rv32, 
rv64, x86-64) switched from a signed to an unsigned type for that field. 
This allows these fields to store timestamps beyond the year 2038, until 
the year 2106. Please note that applications are still expected to 
migrate off the interfaces declared in  and  (except 
for login_tty) due to locking and session management problems."


--
Jakub Wilk

Re: pandoc-filter-diagram_0.2.1-1_amd64.changes REJECTED

[Jonas Smedegaard]

Quoting Shengjing Zhu (2024-05-16 12:14:57)
> On Thu, May 16, 2024 at 4:35 PM Jonas Smedegaard  wrote:
> >
> > Hi FTP-masters (cc d-devel list),
> >
> > A package, that I had initially introduced to Debian some months ago and
> > had been pending in NEW queue since, was rejected few days ago, like
> > this:
> >
> > Quoting Debian FTP Masters (2024-05-14 12:00:12)
> > >
> > > An exception was raised while processing the package:
> > > Traceback (most recent call last):
> > >   File "/srv/ftp-master.debian.org/dak/dak/process_policy.py", line 121, 
> > > in wrapper
> > > function(upload, srcqueue, comments, transaction)
> > >   File "/srv/ftp-master.debian.org/dak/dak/process_policy.py", line 248, 
> > > in comment_accept
> > > transaction.copy_binary(
> > >   File "/srv/ftp-master.debian.org/dak/daklib/archive.py", line 390, in 
> > > copy_binary
> > > self._ensure_extra_source_exists(filename, db_source, archive, 
> > > extra_archives=extra_archives)
> > >   File "/srv/ftp-master.debian.org/dak/daklib/archive.py", line 214, in 
> > > _ensure_extra_source_exists
> > > raise ArchiveException('{0}: Built-Using refers to package {1} (= 
> > > {2}) not in target archive {3}.'.format(filename, source.source, 
> > > source.version, archive.archive_name))
> > > daklib.archive.ArchiveException: 
> > > p/pandoc-filter-diagram/pandoc-filter-diagram_0.2.1-1_amd64.deb: 
> > > Built-Using refers to package rust-ahash (= 0.8.9-2) not in target 
> > > archive ftp-master.
> >
> > I it correct to derive from the above, that packages in NEW queue must
> > be freshly built, and that I (and we, generally) therefore should
> > routinely rebuild packages pending in NEW queue to ensure that they are
> > acceptably?
> 
> Not a ftp-master, but if you see such a message, it means that your
> package has already been accepted, and you can continue uploading
> without going through the NEW queue again.

Thanks, Shengjing Zhu - you are right, althought the concrete *release*
of the package was rejected, the package was nonetheless approved.

Confusing.  I learned something new that day.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature