Bug#996973: Upload or ... Was: WIP

[Geert Stappers]

> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996973#30
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996973#35

I did recieve that as "Yeah, an upload is fine". So I did.
`msc-generator` is in the NEW queue[1].


Regards
Geert Stappers
DD

[1]: https://ftp-master.debian.org/new.html


signature.asc
Description: PGP signature

Bug#996973: Upload or ... Was: WIP

[Geert Stappers]

Hi Gabor,

You wrote:
> Working on build differences
> between upstream Git repo and tarball contents.

Those difference have resolved good enough for now.
I can now cleanly build from git.

The only lintian message I get is:
  W: msc-generator-dbgsym: elf-error In program
  headers: Unable to find program interpreter name
  [usr/lib/debug/.build-id/a0/a796cd48e923166adf698f10e5a484d7ea93a0.debug]

I agree with you that is bugreport #1000449
( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000449 )

Also is -doc package generated. Again good work.

You mentioned (outside of this bugreport) something about "examples".
Should that be included in the first upload?  I tend to "non blocking,
let's upload".  Also because "perfect is the enemy of good".
Express your thoughts about.

Idea/Proposal/Brainfart:
* Add what you want to add.
* Do another (and final?) upload to 
https://mentors.debian.net/package/msc-generator/
* Notify me


Groeten
Geert Stappers
DD
-- 
Silence is hard to parse

Bug#930306: New maintainer for teensy-loader-cli

[Geert Stappers]

control -1 pending
thanks


Hi,

Teensy-loader-cli will have a new uploader:  Me.
And for the better bus-factor will it be done
under the umbrella of the Debian Electronics Team.

The teensy-loader-cli.git.tar.xz fetch from 
https://alioth-archive.debian.org/git/collab-maint/
has been handled as documented at 
https://wiki.debian.org/Salsa/AliothMigration#By_hand
so now there is https://salsa.debian.org/electronics-team/teensy-loader-cli

Actual new upload will happen when I have seen version 2.2 been working.
Current version is 2.1 and have never used t.l.c. before.  :-/

 
Groeten
Geert Stappers
-- 
Silence is hard to parse


signature.asc
Description: PGP signature

Bug#1003157: mailman-suite | Mailman REST API not available. Please start Mailman core. (#22)

[Geert Stappers]

On Tue, Jan 04, 2022 at 11:13:54PM +, Mark Sapiro (@msapiro) wrote:
> Mark Sapiro commented:
> https://gitlab.com/mailman/mailman-suite/-/issues/22#note_801370201
> 
> I don't know what's responsible for the TLS request. What is your
> setting for `MAILMAN_REST_API_URL`? if it is `https`, you might try
> `http` instead

```
$ sudo grep REST_API_URL  /etc/mailman3/mailman-web.py
MAILMAN_REST_API_URL = 'http://localhost:8001'
```

And that `http` was there way before the network sniff was done.
( https://gitlab.com/mailman/mailman-suite/-/issues/22#note_801291946 )
 
> That said, issues with downstream packages should be reported to the
> downstream packager, Debian in this case, rather than here.

Done: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003157
And the Debian packagers are also recieving this email.


> Then if the problem is upstream, the packager can come here.

Current question:
What causes the "Mailman REST API not available."?
Is it mailman3-web not seeing the response to `GET 3.1/domains`?
Or is it the '400 Bad request' in response to TLS request?

Responses I hope to recieve are like
  * Enable extra logging of mailman-suite by ...
  * At  path/to/django/settings/file  somewhere line number ...
you find  foobar, comment that out to get  and try again.


Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#1003157: Mailman REST API not available. Please start Mailman core.

[Geert Stappers]

Package: mailman3-web
Version: 0+20180916-8
Severity: important
Justification: renders package unusable


Hello,


My installation of mailman3-web yields:

Mailman REST API not available. Please start Mailman core.


Further information will be provided in follow-up email.
(This submit message is for getting a bugreportnumber.)


Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#1002795: mailman3-web: libapache2-mod-proxy-uwsgi is empty

[Geert Stappers]

On Fri, Dec 31, 2021 at 11:43:39AM +0100, Geert Stappers wrote:
> On Wed, Dec 29, 2021 at 11:35:33AM +0100, Pierre-Elliott Bécue wrote:
> > Geert Stappers  wrote on 29/12/2021 at 00:18:38+0100:
> > >   ...
> > > For users of mailman3 with Apache it means that there is NO connection
> > > between the webserver and the Django app.
> > >
> > > Right now I don't know what the new 'recommends: ` should be.
> > > I'm only reporting "Apache webserver seems to mis a WSGI module".
> 
> The module is available  and needs to be enabled.
> 
> > > FWIW: I intent to report back when I have a working combination
> > > of mailman3-web and Apache2 webserver.
> 
> The module being enabled did bring progress,
> it bring me not yet to the wanted mile stone.

Meanwhile I reached wanted mile stone
by tuning other mailman3 configuration.

This bugreport now serves documentation purposes.  It tells that proxy
uwgsi module needs to be enabled on Apache2 webserver.

And for the long run should be considered that the 'Recommends: '
gets an improved content.  Current value 'libapache2-mod-proxy-uwsgi | nginx'
did both got me side tracked ( found empty package ) and to right
direction ( enabling the module ).
So maybe it doesn't need "improvement" ...


Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#1002795: [Pkg-mailman-hackers] Bug#1002795: mailman3-web: libapache2-mod-proxy-uwsgi is empty

[Geert Stappers]

On Wed, Dec 29, 2021 at 11:35:33AM +0100, Pierre-Elliott Bécue wrote:
> Geert Stappers  wrote on 29/12/2021 at 00:18:38+0100:
> >   ...
> > For users of mailman3 with Apache it means that there is NO connection
> > between the webserver and the Django app.
> >
> > Right now I don't know what the new 'recommends: ` should be.
> > I'm only reporting "Apache webserver seems to mis a WSGI module".

The module is available  and needs to be enabled.

> > FWIW: I intent to report back when I have a working combination
> > of mailman3-web and Apache2 webserver.

The module enabled did bring progress,
it bring me not yet to the wanted mile stone.

 
> Thanks, I admit initially I had no plan on supporting apache2 as I don't
> use it. Jonas did that part and therefore I did not follow at all.
> 
> Yet the changelogs you quote are back before buster release and I'm
> quite sure Jonas had a working thing at that point.

Please intake my ignorance on "mailman3" into account  ;-)

 
> I'm Cc-ing him, so that he can give an input.

Hopefully next year.

Enjoy new years eve  ("silvester")


Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#1002795: mailman3-web: libapache2-mod-proxy-uwsgi is empty

[Geert Stappers]

Package: mailman3-web
Version: 0+20180916-8


Hello pkg-mailman-hack...@lists.alioth.debian.org,


In debian/control is `recommends: libapache2-mod-proxy-uwsgi | nginx`,
but package `libapache2-mod-proxy-uwsgi` is empty. It became
a _transitional package_.
( 
https://salsa.debian.org/apache-team/apache2/-/blob/master/debian/changelog#L432
 )

For users of mailman3 with Apache it means that there is NO connection
between the webserver and the Django app.

Right now I don't know what the new 'recommends: ` should be.
I'm only reporting "Apache webserver seems to mis a WSGI module".


FWIW: I intent to report back when I have a working combination
of mailman3-web and Apache2 webserver.


Groeten
Geert Stappers
DD
-- 
Silence is hard to parse

Bug#1001779: Hello

[Geert Stappers]

Hello,

Allow me to add https://wiki.debian.org/Teams/RustPackaging
to this bugreport.


Regards
Geert Stappers
Aware of https://github.com/Orange-OpenSource/hurl/issues/366
-- 
Silence is hard to parse


signature.asc
Description: PGP signature

Bug#1001684: [Davmail-users] Davmail and the CVE-2021-44228-Log4j?

[Geert Stappers]

On Tue, Dec 14, 2021 at 06:23:29PM +0100, Mickaël Guessant wrote:
To: davmail-us...@lists.sourceforge.net
> Le 14/12/2021 à 08:52, Ole Holm Nielsen via Davmail-users a écrit :
> > Hi,
> > 
> > We have installed davmail 6.0.1 dated Dec. 3, 2021 as an RPM on CentOS
> > 7.9.  However, it's only a few days ago that the Vulnerability in Apache
> > Log4j (CVE-2021-44228-Log4j) was announced.  We note that Davmail
> > includes a log4j component:
> > 
> > $ rpm -ql davmail | grep log4j
> > /usr/share/davmail/lib/log4j-1.2.16.jar
> > /usr/share/davmail/lib/slf4j-log4j12-1.7.25.jar
> > 
> > Question: Is davmail vulnerable to log4j?  If so, when could we expect a
> > security fix?
> > 
> > Thanks,
> > Ole
> > 
> The good news is that DavMail is *not* vulnerable to latest Log4J 2 CVE as
> it depends on log4J version 1.

FWIW: That matches https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001684#38
 
> Regards,
> Mickaël Guessant


@Alexandre: FYI, your message didn't yet reach Davmail mailinglist subscribers.


Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#1001684: [Davmail-users] Davmail and the CVE-2021-44228-Log4j?

[Geert Stappers]

On Tue, Dec 14, 2021 at 08:52:50AM +0100, Ole Holm Nielsen via Davmail-users 
wrote:
> Hi,
> 
> We have installed davmail 6.0.1 dated Dec. 3, 2021 as an RPM on CentOS 7.9.
> However, it's only a few days ago that the Vulnerability in Apache Log4j
> (CVE-2021-44228-Log4j) was announced.  We note that Davmail includes a log4j
> component:
> 
> $ rpm -ql davmail | grep log4j
> /usr/share/davmail/lib/log4j-1.2.16.jar
> /usr/share/davmail/lib/slf4j-log4j12-1.7.25.jar
> 
> Question: Is davmail vulnerable to log4j?  If so, when could we expect a
> security fix?

Qouting https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001684#22
Debian maintainer of Davmail,  Alexandre Rossi:

  > Also, since a while already, Java now has its own internal logging
  > framework (java.util.logging.Logger), so there should be less and
  > less reason to use potentially unsafe third-party logging libraries
  > (but switching to java's internal logging might be more difficult
  > to do in the short run than just upgrading to a newer version).

  I'll try to report this upstream.




And I hope this helps

Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#996973: It is work in progress

[Geert Stappers]

Hello There,

Packaging of msc-generator is work in progress.
And what is packaged, is in review.

Interresting challenges are encountered.
I'm glad I volunteered for sponsoring. 


Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#1001523: Reported upstream

[Geert Stappers]

Control: tag -1 +upstream

Hello Debian Salt Team,

The request for section 7 salt-cloud manaul page  is reported
upstream as https://github.com/saltstack/salt/issues/61353


Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#1001523: missing man 7 salt-cloud

[Geert Stappers]

Package: salt-cloud
Version: 3004+dfsg1-4
Severity: normal


Hello,


Summary as in subject: I miss /usr/share/man/man7/salt-cloud.7.gz


$ man salt-cloud | tail -n 8
SEE ALSO
   salt-cloud(7) salt(7) salt-master(1) salt-minion(1)

AUTHOR
   Thomas  S.  Hatchand many others,
   please see the Authors file

3004  Nov 17, 2021 SALT-CLOUD(1)
$ man 7 salt-cloud | tail -n 8
No manual entry for salt-cloud in section 7
$ 


The manual page of salt-cloud says that I should also see salt-cloud(7).
Hoping to find there additional information, I did
   man 7 salt-cloud
but got as that there is no manual entry for salt-cloud in section 7.


If a man page section 7 entry for salt-cloud exists,
please add it to the package.

 
Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#685506: Reach out to www.debian.org

[Geert Stappers]

Hi,

For your information:

In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000771
is help requested from people of pseudo-package www.debian.org


Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#1000771: missing Files-Excluded in packaging-manuals/copyright-format

[Geert Stappers]

Package: www.debian.org

Hello www.debian.org care takers,


While searching for information about
field 'Files-Excluded: ' in debian/copyright
did I came across 
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
That document is not yet aware of the field.

Since https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685506#197
is there a patch for it.


Please advice how to add information
to https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

 
Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#810890: caddy in NEW queue

[Geert Stappers]

Hi,

For your information:

At https://ftp-master.debian.org/new.html is
currently visible that on 2021-11-21 an upload to the NEW queue was
done. Uploaded to expiremental, but uploaded.

Maintainer: Debian Go Packaging Team
Changed-By: Peymaneh Nejad
Sponsor: ge...@debian.org


Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#996973: ITP: msc-generator -- Draws signalling charts from textual description

[Geert Stappers]

On Thu, Oct 21, 2021 at 08:43:55PM +0200, Gábor Németh wrote:
> * Package name: msc-generator
>   ... I wish to bring it to Debian proper though.
> I can maintain the package myself, but need a sponsor.


Please ping me when there is something to review.


Regards
Geert Stappers
DD
-- 
Silence is hard to parse


signature.asc
Description: PGP signature

Bug#996569: Advice needed for a strange request about getmail vs. getmail6

[Geert Stappers]

On Tue, Oct 19, 2021 at 12:40:48AM +0500, Andrey Rahmatullin wrote:
> On Mon, Oct 18, 2021 at 08:27:51PM +0100, Sudip Mukherjee wrote:
> > Hi All,
> > 
> > To give a brief history, Debian had "getmail" which was based on
> > Python2 and was removed. Then there was a fork available named
> > "getmail6" which was based on Python3. A transitional package linked
> > them by #979060.
> > 
> > Now, the upstream of "getmail" has raised a bug in Debian asking
> > "getmail6" to be removed or renamed and he claims that users of
> > getmail6 are imposing a support burden on him as users are thinking it
> > to be getmail and mailing the getmail mailing list. #996569
> > 
> > I went through the getmail mailing list archive and could find only
> > one such mail. I am not sure what to reply to him, and need your
> > suggestions about what to do now please.
> Debian is a wrong place to do this.
> And if not for the trademark violation claims I'd suggest ignoring this.
> But the claims should be directed to the upstream first.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996569 IS opened
by the upstream author.

In https://marc.info/?l=getmail=163440038426857=2
is Charles Cazabon, upstream author, expressing that
the poorly named fork of getmail should get a name without
the string 'getmail'.

In thread https://marc.info/?t=16341197233=1=2 you find
also the author of the fork, Roland Puntaier.


Back to the core of the bugreport, getmail vs getmail6.


  getmail6 was a good idea.
  time did learn us it was too optimistic.




  the name getmail6



Solution would be a different name.

When no one comes with a different name,
is removal of getmail6 from the Debian archive the next best thing.


Groeten
Geert Stappers
DD
-- 
Silence is hard to parse


signature.asc
Description: PGP signature

Bug#991867: Lamobo_R1

[Geert Stappers]

On Wed, Aug 04, 2021 at 01:51:49PM +1200, Nevyn wrote:
> 
> U-Boot works but loading kernel results in a blank screen (with cursor in
> top left corner).

And what happens on the serial port?




Regards
Geert Stappers
Has a R1, never used the HDMI port

Bug#988516: uploaded

[Geert Stappers]

FYI

Packaging is done.
Upload did happen.

URL https://ftp-master.debian.org/new/kanjidraw_0.2.3-1.html is
a deep link to the NEW queue.

 
Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#989593: installation report Raspberry Pi 4 UEFI

[Geert Stappers]

On Tue, Jun 08, 2021 at 09:49:15PM +0200, Marc Haber wrote:
>
> The more pressing issue IMO is the deletion of /sbin/start-stop-daemon.
>

Repeating this:

If you were to retry the installation, saving /var/log/syslog manually
before rebooting into the installed system would be useful. Without it,
I fear much guessing would be needed to try and figure out what happened
on that system specifically. Unless someone else has better ideas of
course.


Cheers,
--
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant

Bug#987845: hardwired proxy settings by debian-installer with network-auto-config in proxy-auto-config network

[Geert Stappers]

On Fri, Apr 30, 2021 at 09:25:47PM +0200, Rado Q wrote:
> Installation network setup was auto-configured while the system was
> in a network with proxy-auto-config active.
> 
> Expectation:
> when choosing auto-configure-network during installation, the
> resulting system should be operative in every foreign environment.
> (think of notebook in roaming use)
> 
> Result:
> applications strictly following those hardwired configs can't operate
> outside the original installation network, where the given proxy exists,
> but nowhere else. PAC results during installation shouldn't be
> 'hardwired' into the system to last when moving to another network.
> 
> I tried to reproduce with WPAD or PAC in dhcp at home, but my knowledge
> of those technologies didn't suffice to set it up properly.
> If more info/details of the original network environment is required,
> then I must ask for permission to reproduce, can take time (school in 
> lockdown).
> 
> If the result is intentional for 'local use only', then this is no
> defect but feature-request to add another option to choose between
> 'automatic config for local use' and '... roaming use'.
> 

Acknowledge on the problem.

Which possible solutions do we see?


Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#987491: Fwd: Missing firmware not declared / kernel modules not included in initrd

[Geert Stappers]

Updating the issue with "previously missing information"

- Forwarded message from "Andrew M.A. Cater" -

Date: Sun, 25 Apr 2021 10:13:59 +
From: "Andrew M.A. Cater" 
To: debian-b...@lists.debian.org
Subject: Re: [AMD/ATI graphics] Missing firmware not declared / kernel modules 
not included in initrd

On Sun, Apr 25, 2021 at 10:26:42AM +0200, Holger Wansing wrote:
> Hi,
> 
> Holger Wansing  wrote (Sun, 25 Apr 2021 10:08:32 +0200):
> > >I don't understand:
> > >does this mean that the issue that you reported in
> > >https://lists.debian.org/debian-boot/2020/12/msg00026.html can be
> > >considered fixed? And that the situation improved between buster and
> > >bullseye?
> > 
> > For this (old) hardware: yes, seems so.
> > 
> > However, we have several user reports, that not installed firmware leads to 
> > problems 
> > like black or garbled screen.
> 
> To be more clear:
> 
> The main point of my report at
> https://lists.debian.org/debian-boot/2020/12/msg00026.html ist:
> the installer is - per design - unable to detect, that the hardware needs
> firmware to be installed.
> 
> And this situation did not change!
> 
> The bullseye installation yesterday did not install the firmware package.
> 
> What seems to have changed is:
> GNOME seems to work (at least on this hardware !!!), even without the 
> firmware 
> installed.
> 
> (Also: Look at the other reports I quoted in my mail above for more user 
> cases.)
> 
> 
> Holger
> 

Adding to this, if I may. 

I've got two machines which both turn out to need firmware-amd-graphics
rather than the more modern firmware-amdgpu.

Installing with Bullsye RC1 netinst for amd64 but NOT the unofficial firmware 
version. debian-bullseye-DI-rc1-amd64-netinst.iso 

Even on an expert text mode install.the installer does not prompt for the 
firmware-amd-graphics package to be installed - it does complain about 
Realtek ethernet drivers and a Ralink WiFi card suggesting that you install 
the firmware for these. Booting the install medium does show, in passing,
in text that you need Radeon firmware R600 for modesetting.

If you _do not_ install the firmware, then on these two machines at least
there is a fallback mode to 800x600x16 so graphics remains (just) usable.
GNOME and Wayland work but it's not really practicable.

AT that point, you can install firmware-amd-graphics and it just works.
The meta-package which does this is firmware-linux-nonfree which also includes 
amd64-microcode

Once the firmwre is installed, these machines will drive a 2k monitor

This is explicitly NOT amdgpu which is where people are reporting black 
screens and no output whatsoever, I think.

Hope this helps,

Andy C.
> 
> 
> -- 
> Holger Wansing 
> PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
> 


- End forwarded message -


Those who feel more comformatable to close this issue than me,
should close this issue.


Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#987491: installation-reports: Successful install AMD A6 - nonfree AMD Radeon firmware needed

[Geert Stappers]

Moin moin,

On Sun, Apr 25, 2021 at 10:31:00AM +0200, Holger Wansing wrote:
> Hi,
> 
> "Andrew M.A. Cater"  wrote (Sat, 24 Apr 2021 15:26:00 
> +):
> > Initial boot:   [O ]
> > Detect network card:[O ]
> > Configure network:  [O ]
> > Detect media:   [O ]
> > Load installer modules: [O ]
> > Clock/timezone setup:   [O ]
> > User/password setup:[O ]
> > Detect hard drives: [O ]
> > Partition hard drives:  [O ]
> > Install base system:[O ]
> > Install tasks:  [O ]
> > Install boot loader:[O ]
> > Overall install:[O ]
> > 
> > Comments/Problems:
> > 
> > Requires non-free Radeon drivers for r600 - firmware-amd-graphics
> 
> please be more specific:
> What happened, when no firmware is installed?
> Did the system work so far (graphical UI is visible and usable)?
> Or was it suffering from problems like "black screen" or "garbled screen" as 
> other users reported?
> 

I think this installation report  now waits for one of these options

 * Reporter reports "It is okay, consider 'Requires non-free' as comment"
 * Reporter provides information which special install care
   the special hardware needs. Info that will help others.
 * Closed due "Time out"



Groeten
Geert Stappers
-- 
Silence is hard to parse


signature.asc
Description: PGP signature

Bug#961337: Bug#986737: RFS: deno/1.8.3-1 [ITP] -- A secure JavaScript and TypeScript runtime

[Geert Stappers]

On Sat, Apr 10, 2021 at 09:17:12PM +0300, Sergey Abroskin wrote:
> Dear mentors,
> 
> I am looking for a sponsor for my package "deno":
> 
>  * Package name: deno
>Version : 1.8.3-1
>Upstream Author : The Deno Authors
>  * URL : https://deno.land
> 
> 
>   https://mentors.debian.net/package/deno/
> 
>   dget -x https://mentors.debian.net/debian/pool/main/d/deno/deno_1.8.3-1.dsc
> 
>* Initial release (Closes: 961337)
> 


stappers@paddy:/usr/src/debian/deno
$ grep ^name Cargo.lock  | head
name = "Inflector"
name = "adler"
name = "ahash"
name = "ahash"
name = "aho-corasick"
name = "alloc-no-stdlib"
name = "alloc-stdlib"
name = "ansi_term"
name = "anyhow"
name = "anymap"
stappers@paddy:/usr/src/debian/deno
$ grep --after=1 ^Build-Depends debian/control 
Build-Depends: debhelper (>= 11), rustc, cargo
Standards-Version: 4.1.3
stappers@paddy:/usr/src/debian/deno
$ 


What cargo needs doesn't match the Build-Depends.
If uploaded, it would fail to build due missing build dependencies.


Yes, consider packaging deno for Debian (and it's derivatives)
a very interresting challenge.


Regards
Geert Stappers
-- 
If it was easy, everybody would do it.

Bug#970796: Bug and the error message

[Geert Stappers]

On Thu, Apr 08, 2021 at 04:32:37PM +, Jarosław Wygoda wrote:
> cloudinit.util.ProcessExecutionError: Unexpected error while running command.
> Command: ['apt-key', 'add', '-']
> Stderr: E: gnupg, gnupg2 and gnupg1 do not seem to be installed,
>   but one of them is required for this operation

It says "Have gnupg or gnupg installed"

Bug#985189: ITP: et -- Eternal Terminal (ET) is a remote shell that automatically reconnects without interrupting the session.

[Geert Stappers]

On Sun, Mar 14, 2021 at 04:38:27AM +, Jason Gauci wrote:
> ITP 
>   Package name: et
>   URL : https://eternalterminal.dev/

(further context:
   I have seen debian/control in the debian branch
   https://github.com/MisterTea/EternalTerminal/blob/debian/debian/control
)

I think that `Section: universe/net` is an Ubuntu thing.
Debian version would probably be "main", not "universe"
( https://github.com/MisterTea/EternalTerminal/blob/debian/debian/control#L2 )





Groeten
Geert Stappers


P.S.

Nice to see that you also have a ubuntu branch.
https://dep-team.pages.debian.net/deps/dep14/ didn't tell _me_ it
clearly, but you figured out that it does support multiple vendors.
-- 
Silence is hard to parse

Bug#810890: Cross references

[Geert Stappers]

Hi,

This email is for both caddy packaging related reports
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810890
and
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954793
having a link to each other.

Plus a link
to https://wiki.debian.org/SummerOfCode2021/Projects/PackagingCaddy


Because I think it is good to be aware of the various efforts.


 
Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#984497: another fast-moving project

[Geert Stappers]

On Mon, Mar 08, 2021 at 07:59:37AM -0800, Dima Kogan wrote:
> This particular project is fast-moving, so users of the package would at
> best have a functional-yet-old version, and may think the software
> sucks. *I* don't agree, and *I* think working with and using a distro is
> still worth it. But this upstream made their preferences clear, and I
> think we should respect them.

so like https://tracker.debian.org/pkg/firefox
unlike https://tracker.debian.org/pkg/firefox-esr



Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#973922: new signing key known

[Geert Stappers]

In 
https://github.com/archlinux/svntogit-community/commit/33ee8cb5215ab425e21c5911af8b895529d5b88ao
and 
https://github.com/archlinux/svntogit-community/commit/6f3dbf5530f046f0fba08f467796c42aa94ef800
is said that '7D0B3CEBE9B85B1F825BCECFEE05E6F6A48F6136' # Robin Hugh Johnson
is the new signing key.

This is the plan:
* Update the Debian directory with the new information
* Check it with 2.19
* Upload the 2.19 release to expiremental
* Be ready for the next upstream release



Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#984497: weasels and doves

[Geert Stappers]

Preamble:
   Do know that having own priorities
   and working together IS possible.


On Sat, Mar 06, 2021 at 10:17:03AM +0800, Paul Wise wrote:
> On Fri, 2021-03-05 at 16:52 +0100, Andreas Tille wrote:
> 
> > Finally the license statement is all about redistribution ... and
> > than upstream says:  Do not redistribute. 
> 
> They appear to be fine with redistribution,

OK


> just not with wide distribution by a popular Linux distribution,
> which has a stable release that is guaranteed to get out of date with
> documentation.

Rendering that to FUD does allow me to add more FUD.
Less agressive:
  The _possible_ burden on upstream
  should NOT block our wish to package it.

 
> Possibly they could be convinced by having the package only available
> in Debian unstable or experimental and guaranteeing to keep it up to
> date with the latest available upstream version.
 
Good relation with upstream is indeed preferred.
That relation will only exist when packaging is going on.
We are dealing with libre software.  It implies that
upstream is libre to express "we don't want that it happens",
we are libre to do packaging.
Restricting ourselfs to only unstable feels wrong.


> On the other hand they probably also don't want to deal with bug
> reports about a build that they did not produce.

Double you tee ef.
Please keep Fear Uncertainty and Doubt to yourself.
Now breaking that rule:

  Shady generated binaries are plain evil.



(Back to more reasonable)

It is not to us, Debian, to come with possible reasons
why upstream is "right" in blocking us.

We, Debian, are fully aware that packaging comes
with responsebilities to quality.


 
> Perhaps the right way is for Debian to distribute ExplosionAI software
> under different names with all documentation pointing at Debian to
> avoid upstream having to deal with bug reports from Debian users.


Same as was done with Iceweasel and Icedove.

Future history will tell which lessons were learnt.



Groeten
Geert Stappers
DD
-- 
Silence is hard to parse


signature.asc
Description: PGP signature

Bug#983690: Fwd: Setting JAVA_HOME

[Geert Stappers]

Information about   JAVA_HOME

- Forwarded message from Thorsten Glaser -

Date: Sun, 28 Feb 2021 14:43:34 +0100 (CET)
From: Thorsten Glaser
To: Geert Stappers
cc: debian-j...@lists.debian.org
Subject: Re: Setting  JAVA_HOME

On Sun, 28 Feb 2021, Geert Stappers wrote:

> To what should JAVA_HOME be set?

It should be unset. Also ideally, you have only ever one JRE installed.

Everything else is a nightmare.

To make this work with Java >8 and Maven, you’ll need¹…


jre-not-below-jdk


${java.home}/bin/javadoc






org.apache.maven.plugins

maven-javadoc-plugin


${java.home}/bin/javadoc






… or the Debian-patched version of the maven-javadoc-plugin.

bye,
//mirabilos
① see 
https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=tartools/mvnparent.git
  or use…

org.evolvis.tartools
maven-parent
2.1

-- 
Infrastrukturexperte • tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

*

Mit dem tarent-Newsletter nichts mehr verpassen: www.tarent.de/newsletter

*

- End forwarded message -

Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#983690: Care for FAQ

[Geert Stappers]

Package: java-common
Severity: wish


Hi,

Debian java FAQ has currently no information on setting JAVA_HOME

https://www.debian.org/doc/manuals/debian-java-faq/index.en.html
is from 2014


Please give the Debian Java FAQ  some tender, love and care.


 
Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#981176: RFP: doas -- minimal replacement for sudo

[Geert Stappers]

On Wed, Jan 27, 2021 at 10:59:58AM +0100, Bernd Zeimetz wrote:
> * Package name: doas
> * URL : https://github.com/Duncaen/OpenDoas
>   Description : minimal replacement for sudo
> 
> 
> OpenDoas: a portable version of OpenBSD's doas command
> 
> With the regular security issues in sudo it would make sense
> to have an alternative tools with a much smaller codebase.

Qouting https://packages.debian.org/bullseye/pleaser

  please, a polite, regex-first sudo clone

  Delegate accurate least privilege access with ease. There are times
  when what is intended to be executed can be expressed easily with a
  regex to expose only what is needed and nothing more.



Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#981153: cargo: Please package new upstream (blocks Firefox 85)

[Geert Stappers]

On Fri, Feb 05, 2021 at 09:53:52PM +0100, Leo "Costela" Antunes wrote:
> On Fri, 5 Feb 2021 17:17:25 +0100 Geert Stappers  wrote:
> > Where can I find more information about "relax-cargo-deb.patch"?
> 
> https://bazaar.launchpad.net/~mozillateam/firefox/firefox.groovy/view/head:/debian/patches/relax-cargo-dep.patch

Closes thing to a "commit message" I could find about it is

  * Make cargo 0.47 aka 1.46.0 sufficient
  - debian/patches/relax-cargo-dep.patch


Hope this Helps


Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#981153: [Pkg-rust-maintainers] Bug#981153: cargo: Please package new upstream (blocks Firefox 85)

[Geert Stappers]

On Fri, Feb 05, 2021 at 03:38:37PM +0100, Norbert Brondeau wrote:
> I propose to use the ubuntu patch (relax-cargo-dep.patch)
> that is the best compromise.
> 
> Sincerely yours.
> 
> --- a/build/moz.configure/rust.configure
> +++ b/build/moz.configure/rust.configure
> @@ -168,7 +168,7 @@
>  rustc_min_version = Version("1.47.0")
>  else:
>  rustc_min_version = Version(MINIMUM_RUST_VERSION)
> -cargo_min_version = rustc_min_version
> +cargo_min_version = Version("1.46.0")
> 
>  version = rustc_info.version
>  is_nightly = "nightly" in version.version
> 

Thanks for reporting.  Yes, that is a compliment.

Where can I find more information about "relax-cargo-deb.patch"?
I did get the clue 'ubuntu', can I get a deep link?



Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#981077: ITP: request-tracker5 -- extensible trouble-ticket tracking system

[Geert Stappers]

On Tue, Jan 26, 2021 at 01:17:46AM +, Dominic Hargreaves wrote:
> * Package name: request-tracker5
>   Upstream Author : Best Practical Solutions, LLC >
> * URL : https://bestpractical.com/rt/
> * License : GPL-2
>  .
>  This package supports three database types out of the box: MySQL,
>  PostgreSQL and SQLite. In order to support a zero-configuration install,
>  SQLite will be used by default, but is not recommended for production
>  use. Please see /usr/share/doc/request-tracker5/NOTES.Debian for more
>  details and consider installing rt5-db-postgresql or rt5-db-mysql at
>  the same time as this package.

How I would write those last three lines

}  use. Please see /usr/share/doc/request-tracker5/NOTES.Debian for more
}  details. Consider to install rt5-db-postgresql or rt5-db-mysql when
}  installing this package.


It is the  'at the same time as this'  that I'm wanting to loose.

Please feel free to ignore this non-native English speaker.


Regards
Geert Stappers
-- 
Silence is hard to parse

Bug#980528: debian-installer: net-install impossible because link is always reset

[Geert Stappers]

Not noticing humor, is no proof for the absence of humor.


On Thu, Jan 21, 2021 at 04:40:14PM +, etkaar wrote:
> Good evening,
> 
> after some testing it seems that I am just a very stupid person.

Mmm,  one of my motivators for working on libre software projects
is collaborating with smart people.
I'm willing to lower the bar to "people who can think for themselfs"
After all is the idea of "I could be stupid" just brilant.

 
> The reason, why the interface is always down is - after I had a look
> into the source code of netcfg - that is simply fails *and*, before
> it fails, netcfg would always reset the link, remove any routes and
> ip addresses. At least that is what I assume.
> 
> But why can I manually configure the network? Because I used the onlink flag:
> 
> # ip link set ens1 up
> # ip addr add 255.255.8.243/29 dev ens1
> # ip route add default via 255.255.8.1 dev ens1 >>>onlink<<<
> 
> "onlink: pretend that the nexthop is directly attached to this link,
> even if it does not match any interface prefix."
> https://linux.die.net/man/8/ip
> 
> The /29 subnet actually does not exist on the host; in reality,
> it is a /24 subnet. While /etc/network/interfaces in the installed
> Debian system itself would be aware of whatever it is aware of - I
> just don't know - and automatically will configure the route using the
> onlink tag, in the debian installer that is not possible. It seems the
> only correct way would have been to configure the network with the /24
> notation and the according 255.255.255.0 netmask, which makes sense,
> because working with a /29 notation using MacVTap and VEPA does not
> make much sense for me if the subnet is configured as /24 on the host.

"netmask" is a layer 3 thingy.  My gutfeeling says the problem is
at layer 2, where "link" happens.
 
> However, I am not well-educated when it comes to networking at all. I
> think my assumptions are right, but if the debian installer should
> be aware of that (like the final Debian installation is), we should
> leave that issue open.

Message for those who encounter simular problem:
  Please express your observations.


My observation:
  An address like _._.8.1 is never in same network as _._.8.243/29


Regards
Geert Stappers
-- 
Silence is hard to parse

Bug#980723: [Pkg-rust-maintainers] Bug#980723: autopkgtests aren't being run for rust-sequoia-sqv or rust-sequoia-keyring-linter or rust-sequoia-sop

[Geert Stappers]

On Wed, Jan 20, 2021 at 08:14:45PM -0500, Daniel Kahn Gillmor wrote:
> Package: rust-sequoia-sqv
> Version: 1.0.0-1
> 
> Looks like the autopkgtests are not being run for rust-sequoia-sqv (or
> for sq-keyring-linter or sqop).  I think this is because some rust
> packages needed specifically for testing are not available in the
> archive.
> 
> We should add them to the archive so that the autopkgtest suites get
> run.  (they do not appear to be run during the build)

That starts with identifing those missing packages.



Regards
Geert Stappers
Moral support on this issue.
-- 
Silence is hard to parse

Bug#980528: debian-installer: net-install impossible because link is always reset

[Geert Stappers]

On Wed, Jan 20, 2021 at 04:18:52PM +, etkaar wrote:
> Moin Geert,

 :-)

 
> thanks for helping!
> 
> > ???
> > (the triple question marks are for expressing my "Realy?",
> > please elaborate what is going on.
> > Yes, my request could be recieved as "vague",
> > do know that is being transmitted as "open")
> 
> Do you refer to the IPv4 addresses starting with two 255 groups?

Yes

> It was only an example, not the actual notation I used.

And the example introduced confusion.

 
> > And after configuring is actual traffic possible? 
> Yes. And once I go back to the installer, the link is down again and
> I am impossible to use the network.
> 
> > If so, provide some proof.
> Here is a proof, I made a video: https://youtu.be/9NOQAf6LOdo

I have seen the video.  I have the succesfull ping.

Also seen that installer menu is used.
Thing I would have done, is switch to another terminal

As far as I know does have QEMU support for sending ALT-F2
and ALT-F1.  But there is no ALT-F2 on serial line connections.


Anyway, there is some networking possible.
(my conclusion follows)


 
> > > #
> > > # libvirt VM configuration
> > > #
> > > 
> > >   
> > >   
> >
> >  I'm not sure if that is correct.
> 
> Why do you think that?

Mostly for keeping options on what to explore open.


> I use it with all my VMs.
 
Acknowledge on that.

Do know that we should avoid comparing apples and oranges.

Thing I slightly want to warn about, is that debian-installer
not the very same thing as a full blown system.



> > > #
> > > # Preseed (which also does not work)
> > > #
> > > d-i netcfg/choose_interface select ens1
> > > d-i netcfg/disable_autoconfig boolean true
> > > 
> > > d-i netcfg/get_ipaddress string 255.255.8.243
> > > d-i netcfg/get_netmask string 255.255.255.248
> > > d-i netcfg/get_gateway string 255.255.8.1
> > > d-i netcfg/get_nameservers string 8.8.8.8
> > > d-i netcfg/confirm_static boolean true
> > > 
> >
> > The "preseed stuff" is for later.
> 
> What do you mean by later?

For getting focus on the network problem.
d-i without any preseed stuff should be able to do DHCP


> I would think that the network configuration also (and at least)
> applies for the installer.
> 
> Please find also attached the virt-install command I use at the bottom
> (if I use a preseed or not, makes no difference).
> 
> Kind Regards,
> --etkaar
> 
> #
> # virt-install command
> #
> VM_NAME="vps2"
> 
> virt-install \
> --virt-type kvm \
> --name $VM_NAME \
> --ram 2048 \
> --vcpus 2 \
> --disk path=/var/lib/libvirt/images/$VM_NAME.qcow2,size=24 \
> --os-type linux \
> --os-variant debian10 \
> --graphics none \
> --console pty,target_type=serial \
> --location /var/lib/libvirt/images/.os/debian-10.7.0-amd64-netinst.iso \
> --network type=direct,source=eth0,source_mode=vepa,model=e1000 \
> --initrd-inject=/home/kvm/conf/preseed.cfg \
> --extra-args 'console=ttyS0,115200n8'

I can't spot any holes it  (due lack of indepth knowlegde)



My conclusion: Some how doesn't detect d-i link on the NIC


Advice:  Further debugging


My approach would be:

 * Temporary drop on the wish of a serial console
 * no preseed stuff yet
 * `virt-install` with having multiple VT [1]
 * install in VT-1, watch logs in other VT
 * have in another VT a shell for the `ip` commands


You probably want the syslog of d-i outside the VM
for more convinend analysis (pardon my english)



Regards
Geert Stappers
[1] https://en.wikipedia.org/wiki/Virtual_console
-- 
Silence is hard to parse

Bug#980528: debian-installer: net-install impossible because link is always reset

[Geert Stappers]

Control: tag -1 moreinfo

On Wed, Jan 20, 2021 at 08:08:24AM +, etkaar wrote:
> Package: debian-installer
> Severity: important
> Tags: d-i
> 
> Good Morning!

Moin

 
> I noticed a strange bug with the debian installer when I wanted to
> install a virtual machine (KVM) using virt-install. I use MacVTap in
> VEPA mode for networking. While the host would create an interface
> such like "macvtap[n]@eth0", the VM gets an interface such like "ens1"
> when using the e1000 NIC.
> 
> The fact, which lets me think that it is actually a bug of the installer,is,

I think it is an interresting problem, not convinced about a "bug".


> that a) the network works without any problem in all VMs which are installed
> and b) that I can configure the network manually, but *only* using the shell,
> for instance:
> 
> > ip link set ens1 up
> > ip addr add 255.255.8.243/29 dev ens1
> > ip route add default via 255.255.8.1 dev ens1 onlink

???
(the triple question marks are for expressing my "Realy?",
 please elaborate what is going on.
 Yes, my request could be recieved as "vague",
 do know that is being transmitted as "open")

 
> The bug is, that the installer - e.g. even if I, after DHCP has failed, try 
> to manually configure it
> using the installer (not the shell) - always resets the link "ens1" to a 
> state where the link is not up:
> 
> > ~ # ip link show
> > ...
> > 2: ens1:  mtu 1500 qdisc pfifo_fast qlen 1000
> > link/ether 52:54:00:fb:a1:98 brd ff:ff:ff:ff:ff:ff
> 
> Expected is "", but the interface is always 
> set to down by the installer.
> If I enable it by typing "ip link set ens1 up" it gets up and I can configure 
> the network in the shell.

And after configuring is actual traffic possible? 
If so, provide some proof.


> I even tried it with a preseed file, but whatever I try, the interface is 
> always down and so it is
> impossible to configure it within the installation.
> 
> 
> #
> # libvirt VM configuration
> #
> 
>   
>   

I'm not sure if that is correct.


>   
>function='0x0'/>
> 
> 
> #
> # Preseed (which also does not work)
> #
> d-i netcfg/choose_interface select ens1
> d-i netcfg/disable_autoconfig boolean true
> 
> d-i netcfg/get_ipaddress string 255.255.8.243
> d-i netcfg/get_netmask string 255.255.255.248
> d-i netcfg/get_gateway string 255.255.8.1
> d-i netcfg/get_nameservers string 8.8.8.8
> d-i netcfg/confirm_static boolean true
> 

The "preseed stuff" is for later.



Regards
Geert Stappers
-- 
Silence is hard to parse

Bug#966088: It would be great to have debian-rust@l.d.o.

[Geert Stappers]

Summary:  Gentle reminder


Hello Listmasters,


Today there was this on IRC in #debian-rust

14:31 < metreo> is there some reason the rust team mailing list isn't shown 
here:
https://lists.debian.org/completeindex.html
14:38 < capitol> not that i know of
14:39 < metreo> k
14:58 < nikos> 'The lists.d.o list hasn't been created yet AFAIK


Me did it trigger to write this email.


What is blocking creation mailing  debian-rust@l.d.o.?
 
In other words: Please say what is needed to make it possible.


Regards
Geert Stappers
-- 
Silence is hard to parse

Bug#979712: Cannot compile qemu, missing a builddep

[Geert Stappers]

On Sun, Jan 10, 2021 at 04:45:03PM +, Debian Bug Tracking System wrote:
Date: Sun, 10 Jan 2021 19:41:03 +0300
From: Michael Tokarev 
> 10.01.2021 19:16, Kamil Jońca wrote:
> > "Debian Bug Tracking System"  writes:
> > 
> > 
> > Attached full compilation message :
> 
> Ok, this is better. From your log, from the beginning of it:
> 
>  ERROR: User requested feature smartcard
> configure was not able to find it.
> Install libcacard devel
> 
> debuild does not install build-time dependencies. If you want to
> build it this way, please take a look at debian/control file and
> install everything listed in Build-Depends and Build-Depends-Indep
> fields.

FWIW there is a command for checking build dependencies.

   dpkg-checkbuilddeps


It reports missing builddeps.


> Closing this bugreport.
> 
> Thanks,
> /mjt

Thank you for keeping  the qemu package  in good shape.


Regards
Geert Stappers
-- 
Silence is hard to parse

Bug#978556: [ftpmas...@ftp-master.debian.org: Processing of rust-netr_0.1.4-1_amd64.changes]

[Geert Stappers]

Upload did happen

- Forwarded message from Debian FTP Masters 
 -

Date: Thu, 07 Jan 2021 22:20:32 +
From: Debian FTP Masters 
To: stapp...@debian.org
Subject: Processing of rust-netr_0.1.4-1_amd64.changes

rust-netr_0.1.4-1_amd64.changes uploaded successfully to localhost
along with the files:
  netr-dbgsym_0.1.4-1_amd64.deb
  netr_0.1.4-1_amd64.deb
  rust-netr_0.1.4-1_amd64.buildinfo
  rust-netr_0.1.4-1.dsc
  rust-netr_0.1.4.orig.tar.gz
  rust-netr_0.1.4-1.debian.tar.xz

Greetings,

Your Debian queue daemon (running on host usper.debian.org)

- End forwarded message -


Regards
Geert Stappers
-- 
Silence is hard to parse

Bug#973922: New upstream (2.19)

[Geert Stappers]

On Thu, Jan 07, 2021 at 08:19:21PM +0100, Geert Stappers wrote:
> On Thu, Jan 07, 2021 at 07:00:42PM +0100, Fabio Pedretti wrote:
> > 2.18 was uploaded to Debian
> > while 2.19 is already available upstream?
> 
> Something between  yes and no.
> 
> 
> The 2.19 version lacks a signature from upstream.
> 2.18 has a signature from upstream.
> 
> In other words: radvd 2.18 is complete in Debian,
> v2.19 of radvd waits on signature from upstream ...
 
At https://github.com/reubenhwk/radvd/issues/129#issuecomment-728848196
is expressed what we are waiting on.

 
Regards
Geert Stappers
Maintainer of radvd in Debian
-- 
Silence is hard to parse

Bug#973922: New upstream (2.19)

[Geert Stappers]

On Thu, Jan 07, 2021 at 07:00:42PM +0100, Fabio Pedretti wrote:
> 2.18 was uploaded to Debian
> while 2.19 is already available upstream?

Something between  yes and no.


The 2.19 version lacks a signature from upstream.
2.18 has a signature from upstream.

In other words: radvd 2.18 is complete in Debian,
v2.19 of radvd waits on signature from upstream ...


Regards
Geert Stappers
DD,  maintainer of radvd
-- 
Silence is hard to parse

Bug#978556: intermediate status report

[Geert Stappers]

The recieving end said

Source-only uploads to NEW are not allowed



My next attempt will be thursday (evening (CET))

Bug#978556: Chips

[Geert Stappers]

On Sun, Jan 03, 2021 at 09:55:35PM +0100, Geert Stappers wrote:
>   
> 
> It means that what I have signed for uploading is not accepted.
> 
> Follow actions are up to me.  ( to be continued )
> 


stappers@trancilo:/usr/src/debian/rust/debcargo-conf/build
$ man dput
stappers@trancilo:/usr/src/debian/rust/debcargo-conf/build
$ dput --unchecked rust-netr_0.1.4-1_source.changes
Trying to upload package to ftp-master (ftp.upload.debian.org)
Uploading to ftp-master (via ftp to ftp.upload.debian.org):
  Uploading rust-netr_0.1.4-1.dsc: done.
  Uploading rust-netr_0.1.4.orig.tar.gz: done.
  Uploading rust-netr_0.1.4-1.debian.tar.xz: done.
  Uploading rust-netr_0.1.4-1_source.buildinfo: done.
  Uploading rust-netr_0.1.4-1_source.changes: done.
Successfully uploaded packages.
stappers@trancilo:/usr/src/debian/rust/debcargo-conf/build
$ 


Addition information:
Signing was done at a different machine as the `dput` machine.

It looks like `dput` is happy.  We now wait what the recieving end
says.


Regards
Geert Stappers
-- 
Silence is hard to parse

Bug#978556: Chips

[Geert Stappers]

stappers@trancilo:/usr/src/debian/rust/debcargo-conf/build
$ dput rust-netr_0.1.4-1_source.changes
Trying to upload package to ftp-master (ftp.upload.debian.org)
Checking signature on .changes
Traceback (most recent call last):
  File "/usr/bin/dput", line 11, in 
load_entry_point('dput==1.0.3', 'console_scripts', 'execute-dput')()
  File "/usr/share/dput/dput/dput.py", line 1012, in main
files_to_upload = verify_files(
  File "/usr/share/dput/dput/dput.py", line 374, in verify_files
verify_signature(
  File "/usr/share/dput/dput/dput.py", line 274, in verify_signature
assert_good_signature_or_exit(changes_file_path)
  File "/usr/share/dput/dput/dput.py", line 258, in 
assert_good_signature_or_exit
crypto.check_file_signature(infile)
  File "/usr/share/dput/dput/crypto.py", line 93, in check_file_signature
(_, verify_result) = context.verify(infile)
  File "/usr/lib/python3/dist-packages/gpg/core.py", line 541, in verify
raise errors.BadSignatures(results[1], results=results)
gpg.errors.BadSignatures: 8A7F208C6D9E73291657414D2135D123D8C19BEC: Key expired
stappers@trancilo:/usr/src/debian/rust/debcargo-conf/build
$ 


So my action from november ( 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892058#110 )
was not effective and the reminder I got in december was very valid.


It means that what I have signed for uploading is not accepted.

Follow actions are up to me.  ( to be continued )


Regards
Geert Stappers
-- 
Silence is hard to parse

Bug#978556: ITP: netr -- Display network interface throughput in terminal

[Geert Stappers]

On Mon, Dec 28, 2020 at 03:21:34PM +, Edward Neville wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Edward Neville 
> 
> * Package name: netr
>   Version : 0.1.3
>   Upstream Author : Ed Neville 
> * URL : http://www.usenix.org.uk/content/net.html
> * License : GPL
>   Programming Lang: Rust
>   Description : Display network interface throughput in terminal
> 
> Display network interface throughput by second and by minute along with
> a graph. This is quick and easy to use via a mobile handset or similar
> device where typing is cumbersome.
> 
> A sponsor is required, but check with stappers as he may be looking at
> this.

Unlikely that I look this week (so also this year) into it.

 
> I plan to maintain this within the rust team.

Good work in progress at 
https://salsa.debian.org/rust-team/debcargo-conf/-/tree/master/src/netr/debian
 

Regards
Geert Stappers
-- 
Silence is hard to parse

Bug#977907:

[Geert Stappers]

Control: retitle -1 ITP: CLBlast,  OpenCL BLAS library
Thanks

On Tue, Dec 22, 2020 at 06:28:49PM +0100, Gard Spreemann wrote:
> Package: wnpp
> Severity: wishlist
> 
> * Package name: CLBlast
>   Upstream Author : Cedric Nugteren and others
> * URL : https://cnugteren.github.io/clblast/clblast.html
>   Description : Tuned OpenCL BLAS library
> 
> CLBlast is an OpenCL BLAS library that often can sometimes offer better
> performance than the clblas that's already in the archive.
> 
> I will maintain the package, although I might also reach out to the
> science team.
 


Regards
Geert Stappers
-- 
Silence is hard to parse

Bug#810890: caddy in Debian, git repo at Salsa created

[Geert Stappers]

On Sun, Dec 20, 2020 at 10:33:26PM -0600, Stephen Gelman wrote:
> On Dec 20, 2020, at 8:48 PM, Geert Stappers  wrote:
> > 
> > Hello Debian Go  People,
> > Hello Debian Go  People with create privilege at Salsa,
> > 
> > 
> > Please create git repo 
> > https://salsa.debian.org/go-team/packages/golang-github-caddyserver
> > in addition to 
> > https://salsa.debian.org/go-team/packages/golang-github-caddyserver-certmagic
> > 
> > It is for packaging Caddy.
> > ( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810890 )
> > 
> Geert,
> 
> You should be able to create the repos with “dh-make-golang 
> create-salsa-project”
> 
> Stephen
 

Challenge accepted  :-)


stappers@trancilo:~
$ which dh-make-golang
stappers@trancilo:~
$ sudo apt install dh-make-golang
 ...
Bezig met uitpakken van dh-make-golang (0.4.0-1) ...
Instellen van dh-make-golang (0.4.0-1) ...
Bezig met afhandelen van triggers voor man-db (2.9.3-2) ...
 ...
stappers@trancilo:~
$ which dh-make-golang
/usr/bin/dh-make-golang
stappers@trancilo:~
$ 

# reading manual page

stappers@trancilo:~
$ dh-make-golang create-salsa-project golang-github-caddyserver-caddy
stappers@trancilo:~
$ echo $?
0
stappers@trancilo:~
$ 



Yes, there is now 
https://salsa.debian.org/go-team/packages/golang-github-caddyserver-caddy



Regards
Geert Stappers
-- 
What was the last time you did something for the first time?


signature.asc
Description: PGP signature

Bug#810890: caddy in Debian, git repo at Salsa

[Geert Stappers]

On Sun, 25 Dec 2016 15:41:37 +0100 Andrew Shadura  wrote:
> (I have done base for cloudflare package but didn't check any new
> version in some time nor did I track if there is any other dependency
> packaged and they were quite a bit of them). I can send you the
> cloudflare work if you're interested in it or wait for me to finish
> it.
> 
> 
> I think it'd be great if you uploaded what you've done somewhere. Or
> at least mailed me a tarball :)


Hello Debian Go  People,
Hello Debian Go  People with create privilege at Salsa,


Please create git repo 
https://salsa.debian.org/go-team/packages/golang-github-caddyserver
in addition to 
https://salsa.debian.org/go-team/packages/golang-github-caddyserver-certmagic

It is for packaging Caddy.
( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810890 )


Thanks

Geert Stappers


P.S.
The extra copy of this you might got, is due Bcc


signature.asc
Description: PGP signature

Bug#977194: installation-reports: Installation stalls on network devices search when wifi key plugged in

[Geert Stappers]

Control: tag -1 moreinfo

Hello Mathieu,


On Sat, Dec 12, 2020 at 12:02:31PM +0100, Mathieu Van Nieuwenhuyse wrote:
> Package: installation-reports

Thanks for the report


> Severity: normal
> Tags: d-i
> X-Debbugs-Cc: mathieu.van.nieuwenhu...@gmail.com
> 
> Dear Maintainer,
> 
> 
>* What led up to the situation?
> I launched the installation (via usb key) with both a wifi stick plugged in
> (TP-link Archer T2U) and an ethernet connexion
> the search for network devices stalled : no error message, nothing to do.
> 
> I restarted the installation without the wifi stick.
> 
> Everything worked fine then.

Acknowledge.


There are now two options:

A: Closing this bugreport
B: Keep this bugreport open for "fix bug"


Option A is a clear path.

What do you expect from option B?



Regards
Geert Stappers
-- 
Silence is hard to parse

Bug#976694: radvd systemd unit installed in subdirectory -> invalid

[Geert Stappers]

On Sun, Dec 06, 2020 at 10:20:10PM -0300, Adilson dos Santos Dantas wrote:
> I can confirm this bug and I have fixed it  with a little change on the
> file radvd.install and rebuild the package. I'm attaching this file below

Thanks


> so you can copy into the debian folder.

Done
( 
https://salsa.debian.org/debian/radvd/-/commit/4e762f020101bb407e755b12ad83c284bf1d94ad
 )
 

> Best regards,
> Adilson dos Santos Dantas


Regards
Geert Stappers
-- 
Silence is hard to parse

Bug#976694: radvd systemd unit installed in subdirectory -> invalid

[Geert Stappers]

Control: tags -1 pending

On Mon, Dec 07, 2020 at 01:55:17AM +0100, Mara Sophie Grosch wrote:
> 
> radvd version 1:2.18-2 installs the systemd unit file at
> /lib/systemd/system/radvd.service/radvd.service
> 
> As you can see, there is a subdirectory named like the unit file in
> between. This prevents radvd from starting.

Oops.

Fix is work in progress.


Thanks for the report.


Regards
Geert Stappers
-- 
Silence is hard to parse

Bug#976484: unsigned values cannot be negated

[Geert Stappers]

Control: retitle -1 rust-mach-o-sys: unsigned values cannot be negated

On Sat, Dec 05, 2020 at 02:28:20PM +0100, Lucas Nussbaum wrote:
> Source: rust-mach-o-sys
> Version: 0.1.1-3
> 
> 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).
> 
> Relevant part (hopefully):
> > 
> > 
> >  -C link-arg=-Wl,-z,relro --remap-path-prefix
> >  /<>=/usr/share/cargo/registry/mach-o-sys-0.1.1`
> > error[E0600]: cannot apply unary operator `-` to type `u8`
> >   --> src/arch.rs:35:46
> >|
> > 35 | pub const INT8_MIN: ::std::os::raw::c_char = -128;
> >|   cannot apply unary 
> > operator `-`
> >|
> >= note: unsigned values cannot be negated
> > 
> > error[E0600]: cannot apply unary operator `-` to type `u8`
> >   --> src/arch.rs:42:48
> >|
> > 42 | pub const UINT64_MAX: ::std::os::raw::c_char = -1;
> >|^^ cannot apply unary 
> > operator `-`
> >|
> >= note: unsigned values cannot be negated


Yes, that should also fail on amd64 ...

Bug#976532: [Pkg-rust-maintainers] Bug#976532: marked as done (rust-cpuid-bool: FTBFS: compile_error!("This crate works only on my computer"); )

[Geert Stappers]

On Sat, Dec 05, 2020 at 07:45:29PM +, Debian Bug Tracking System wrote:
> Date: Sat, 5 Dec 2020 14:28:14 +0100
> From: Lucas Nussbaum 
> To: sub...@bugs.debian.org
> Subject: rust-cpuid-bool: FTBFS: dh_auto_test: error: 
> /usr/share/cargo/bin/cargo test --all returned exit code 101
> Source: rust-cpuid-bool
> Version: 0.1.2-2
> Severity: serious
> Justification: FTBFS on arm64
> 
> Hi,
> 
> Relevant part (hopefully):
> > 20 | compile_error!("This crate works only on x86 and x86-64 targets.");
> >| ^^^
> > 
> > error: aborting due to previous error

> Date: Sat, 5 Dec 2020 20:42:02 +0100
> From: Lucas Nussbaum 
> To: 976532-d...@bugs.debian.org
> Subject: Re: Bug#976532: rust-cpuid-bool: FTBFS: dh_auto_test: error: 
> /usr/share/cargo/bin/cargo test --all returned exit code 101
> User-Agent: Mutt/1.10.1 (2018-07-13)
> 
> Version: 0.1.2-3
> 
> Actually, this was fixed in 0.1.2-3 (by disabling tests) before I filed the 
> bug.
 

It allows us to find a better  fix



Regards
Geert Stappers
-- 
Silence is hard to parse

Bug#976472: Bug#976467 is simular

[Geert Stappers]

> > 
> > error[E0635]: unknown feature `mmx_target_feature`
> >--> src/lib.rs:213:5
> > |
> > 213 | mmx_target_feature,
> > | ^^
> > 

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976467
is also error E0635: unknown feature `mmx_target_feature`

Bug#976467: rust-core-arch: FTBFS: error[E0635]: unknown feature `mmx_target_feature`

[Geert Stappers]

Control: retitle -1 rust-core-arch FTBFS error[E0635]: unknown feature 
`mmx_target_feature`

On Sat, Dec 05, 2020 at 02:28:10PM +0100, Lucas Nussbaum wrote:
> Version: 0.1.5-4
> Severity: serious
> Justification: FTBFS on arm64

Yes, severity serious  is  justified.
 

> 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).
> 
> Relevant part (hopefully):
> > 
> > error[E0635]: unknown feature `mmx_target_feature`
> >   --> src/lib.rs:23:5
> >|
> > 23 | mmx_target_feature,
> >| ^^
> > 

MMX as in https://en.wikipedia.org/wiki/MMX_(instruction_set)


Bugreport https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976532
is also "there are no other instruction set architectures as mine"

Bug#976532: rust-cpuid-bool: FTBFS: compile_error!("This crate works only on my computer");

[Geert Stappers]

Control: retitle -1 rust-cpuid-bool: FTBFS: compile_error!("This crate works 
only on my computer");


On Sat, Dec 05, 2020 at 02:28:14PM +0100, Lucas Nussbaum wrote:
> Source: rust-cpuid-bool
> Severity: serious
> Justification: FTBFS on arm64

Yes, severity  serious   is justified.

 
> Hi,
> 
> During a rebuild of all packages in sid,
> your package failed to build on arm64
> 
> > error: This crate works only on x86 and x86-64 targets.
> >   --> src/lib.rs:20:1
> >|
> > 20 | compile_error!("This crate works only on x86 and x86-64 targets.");
> >| ^^^
> > 
> > error: This crate works only on x86 and x86-64 targets.
> >   --> src/lib.rs:20:1
> >|
> > 20 | compile_error!("This crate works only on x86 and x86-64 targets.");
> >| ^^^
> > 
> > error: aborting due to previous error
> > 
> > error: could not compile `cpuid-bool`.
> > 

Qouting https://crates.io/crates/cpuid-bool
 lightweight and efficient no-std compatible alternative to the
 is_x86_feature_detected macro


Reality says there are instruction set architectures others than x86.



In other words:
 This bugreport is about enabling other architectures
 than a currently dominant architecture.



Regards
Geert Stappers
-- 
Silence is hard to parse

Bug#975833: The FTBFS is reproducable by me.

[Geert Stappers]

Control: tags -1 confirmed


Now reproducable by me


Regards
Geert Stappers
No time to find out why my build was succesfull.
-- 
Silence is hard to parse

Bug#976369: timestamp too far in the past

[Geert Stappers]

Control: retitle -1 timestamp too far in the past

On Fri, Dec 04, 2020 at 08:54:48AM +0100, Aurelien Jarno wrote:
> - Forwarded message from Debian FTP Masters 
>  -
> To: mips64el Build Daemon 

Good forward.   Yes, that is a compliment


> Date: Fri, 04 Dec 2020 01:51:38 +
> Subject: rust-csv_1.1.5-1_mips64el-buildd.changes REJECTED
> Message-Id: 
> 
> librust-csv-dev_1.1.5-1_mips64el.deb: has 66 file(s) with a timestamp too far 
> in the past:
> usr/share/cargo/registry/csv-1.1.5/.gitignore (Thu Jan  1 00:00:00 1970)
> usr/share/cargo/registry/csv-1.1.5/COPYING (Thu Jan  1 00:00:00 1970)
> usr/share/cargo/registry/csv-1.1.5/ISSUE_TEMPLATE.md (Thu Jan  1 00:00:00 
> 1970)
  ...
> usr/share/cargo/registry/csv-1.1.5/src/tutorial.rs (Thu Jan  1 00:00:00 1970)
> usr/share/cargo/registry/csv-1.1.5/src/writer.rs (Thu Jan  1 00:00:00 1970)
> usr/share/cargo/registry/csv-1.1.5/tests/tests.rs (Thu Jan  1 00:00:00 1970)
> - End forwarded message -

In the build for  arm64,
 
https://buildd.debian.org/status/fetch.php?pkg=rust-csv=arm64=1.1.5-1=1607044951=0
lots of the same "1970-01-01 00:00"


FWIW  I agree with the mips64el buildd to report this
too far in the past in the past time stamp.
 


Regards
Geert Stappers
-- 
Silence is hard to parse

Bug#976255: Minimun hardware requirements innaccurate as documented

[Geert Stappers]

On Wed, Dec 02, 2020 at 10:23:05AM +0100, Samuel Thibault wrote:
> Hello,
> 
> Jim, le mar. 01 déc. 2020 17:29:52 -0800, a ecrit:
> > https://www.debian.org/releases/stable/i386/ch03s04.en.html 
> > 
> > it states 512M RAM is the minimum required for gui desktop.  However in
> > installing the 10.6 32bit livecd on a 32bit system with 784M RAM,
> 
> This link does not document the livecd image, but the installer only.
> 
> I added a note about this.
> 
> > I even tried this straight from the installer boot menu without
> > loading the desktop into RAM first, with the same results.
> 
> Even that will not be the same installer image, only the pure installer
> is documented there.
> 
> I just tried with qemu with 512M, it does install fine. With the
> installer image and not the livecd, that is.
> 

Does it mean that #976255: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976255  
can be closed?



Regards
Geert Stappers
Who created #976255 to prevent that the feedback might have got lost
-- 
Silence is hard to parse

Bug#976255: Minimun hardware requirements innaccurate as documented

[Geert Stappers]

Package: debian-installer

- Forwarded message from Jim  -

Date: Tue, 01 Dec 2020 17:29:52 -0800
From: Jim 
To: debian-b...@lists.debian.org
Subject: Minimun hardware requirements innaccurate as documented

According to this link:  
https://www.debian.org/releases/stable/i386/ch03s04.en.html 
it states 512M RAM is the minimum required for gui desktop.  However
in installing the 10.6 32bit livecd on a 32bit system with 784M RAM,
the installer refuses to install stating the minimum required RAM is
1G. I even tried this straight from the installer boot menu without
loading the desktop into RAM first, with the same results.
Please update your documentation.
Thanks-:)
Jim

- End forwarded message -

Regards
Geert Stappers
-- 
Silence is hard to parse

Bug#913864: Pinning

[Geert Stappers]

On Mon, Nov 30, 2020 at 04:03:25PM +0100, Karsten wrote:
> It seems new that the pinning does not automatically update to a newer 
> version when it exists.

Yes, that is the idea of pinning.

https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_tweaking_candidate_version

Bug#892058: Your Debian key is expiring

[Geert Stappers]

On Wed, Nov 18, 2020 at 11:02:06AM -0800, Felix Lechner wrote:
> Dear Geert,

Hi Felix,


> This is a courtesy reminder that your Debian key is expiring on 2020-12-27.

Thanks for sending out that reminder.

I have extended the expire date of my PGP-key
and did send it to keyring.debian.org.


Regards
Geert Stappers
-- 
Silence is hard to parse


signature.asc
Description: PGP signature

Bug#973481: status ITP: please -- Please, a sudo clone with regex support, done

[Geert Stappers]

Packaged by Ed Neville
Uploaded by sylves...@debian.org

The package is now in NEW

Bug#868729: Use IPv6 tools on an IPv6 enabled system.

[Geert Stappers]

Control: tag -1 wontfix


I do understand the wish for radvdump as highly optimized network
sniffer for router advertisements.
But I wouldn't be spending any resouces on the request.


Bugreport now marked as  won't be fixed.


Regards
Geert Stappers
-- 
Silence is hard to parse

Bug#954433: radvd: PIDFile in /lib/systemd/system/radvd.service must be moved from /var/run/ to /run/

[Geert Stappers]

On Sun, Nov 15, 2020 at 10:01:21PM +0100, Geert Stappers wrote:
> 
> --- a/configure.ac
> +++ b/configure.ac
> @@ -117,9 +117,9 @@ AC_MSG_RESULT($PATH_RADVD_LOG)
>  dnl Check where to put the pidfile
>  AC_MSG_CHECKING(where to put pidfile)
>  AC_ARG_WITH(pidfile,
> -[  --with-pidfile  Path to the radvd pidfile [/var/run/radvd.pid]],
> +[  --with-pidfile  Path to the radvd pidfile [/run/radvd.pid]],
> PATH_RADVD_PID=$withval,
> -   PATH_RADVD_PID=/var/run/radvd.pid)
> +   PATH_RADVD_PID=/run/radvd.pid)
>  AC_MSG_RESULT($PATH_RADVD_PID)
>  
>  dnl Check where to put the configfile
> 

Upstream has a simular fix.



Regards
Geert Stappers
-- 
Silence is hard to parse

Bug#954433: radvd: PIDFile in /lib/systemd/system/radvd.service must be moved from /var/run/ to /run/

[Geert Stappers]

Control: tags + confirmed  pending

On Sat, Mar 21, 2020 at 03:16:07PM +, Michael Berg wrote:
> Package: radvd
> Version: 1:2.17-2+b1
> 
> As part of the migration away from /var/run/ to /run/, systemd produces
> log events containing the following. These log events are generated
> every 5 minutes (cluttering the logs and consuming log space).
> 
> "/lib/systemd/system/radvd.service:13: PIDFile= references a path below 
> legacy directory /var/run/, updating /var/run/radvd.pid → /run/radvd.pid; 
> please update the unit file accordingly."
> 
> Attached is a patch for /lib/systemd/system/radvd.service that moves the
> PIDFile from /var/run/radvd.pid to /run/radvd.pid
> 
> 
> --- radvd.service.old 2020-03-21 14:46:14.507449211 +
> +++ radvd.service.new 2020-03-21 14:47:30.668715976 +
> @@ -13,7 +13,7 @@
>  ExecStart=/usr/sbin/radvd --logmethod stderr_clean
>  ExecReload=/usr/sbin/radvd --logmethod stderr_clean --configtest
>  ExecReload=/bin/kill -HUP $MAINPID
> -PIDFile=/var/run/radvd.pid
> +PIDFile=/run/radvd.pid
>  
>  # Set the CPU scheduling policy to idle which is for running very low 
> priority background jobs
>  CPUSchedulingPolicy=idle


--- a/configure.ac
+++ b/configure.ac
@@ -117,9 +117,9 @@ AC_MSG_RESULT($PATH_RADVD_LOG)
 dnl Check where to put the pidfile
 AC_MSG_CHECKING(where to put pidfile)
 AC_ARG_WITH(pidfile,
-[  --with-pidfile  Path to the radvd pidfile [/var/run/radvd.pid]],
+[  --with-pidfile  Path to the radvd pidfile [/run/radvd.pid]],
PATH_RADVD_PID=$withval,
-   PATH_RADVD_PID=/var/run/radvd.pid)
+   PATH_RADVD_PID=/run/radvd.pid)
 AC_MSG_RESULT($PATH_RADVD_PID)
 
 dnl Check where to put the configfile


Regards
Geert Stappers
-- 
Silence is hard to parse

Bug#974122: email formatting thingy Was: Bug#974122: No network at Banana Pi M2 Ultra

[Geert Stappers]

On Tue, Nov 10, 2020 at 04:23:25PM +0100, William Bonnet wrote:
> I would like to know please if you did it "by hand" or used a tool to do
> the check ?

https://salsa.debian.org/installer-team/installation-report/-/blob/master/install-report.template

Bug#973922: New upstream (2.19)

[Geert Stappers]

Control: tag -1 + confirmed


On Sat, Nov 07, 2020 at 03:52:24PM +0100, Daniel Baumann wrote:
> Package: radvd
> 
> Hi Geert,
 

;-)



> thank you for maintaining radvd. Unfortunately I'm hit by a bug that got
> fixed in radvd which makes it unable for me to use it with my provider.
> 
> It would be super nice if you could upgrade to version 2.19.


Acknowledge




> Regards,
> Daniel

Regards
Geert Stappers

Working on it

Bug#973862: Crosslinking

[Geert Stappers]

Subject says all  :-)
https://bugs.debian.org/973862
https://bugs.debian.org/973865

Bug#973862: RFS: dhcpdump/1.8-2.2 [ITA] -- Parse DHCP packets from tcpdump

[Geert Stappers]

On Fri, Nov 06, 2020 at 04:16:12PM +0800, Peter Ji wrote:
> I am looking for a sponsor for package "dhcpdump":
> 
>  * URL : https://github.com/huiji12321/dhcpdump
> 
> Changes since the last upload:
> 
>  dhcpdump (1.8-3) unstable; urgency=low
>  .
>* New-maintainer upload. (Closes: #934419)
>* Fix the manpage,dhcpdump does not parse the output of tcpdump
>  but analyze and display it. (Closes:647228)
> 


In case it remains silence, contact me upcoming thursday.


Regards
Geert Stappers
Has another RFS queued
-- 
Silence is hard to parse


signature.asc
Description: PGP signature

Bug#973481: Packaging is done

[Geert Stappers]

Hi,

Ed told me that the packaging is done.

So the next is that I will be reviewing that.



Regards
Geert Stappers
New to rust in debian
-- 
Silence is hard to parse


signature.asc
Description: PGP signature

Bug#972802: rust-webpki-roots is marked for autoremoval from testing

[Geert Stappers]

On Sun, Nov 01, 2020 at 04:39:36AM +, Debian testing autoremoval watch 
wrote:
> rust-webpki-roots 0.20.0-1 is marked for autoremoval from testing on 
> 2020-11-22
> 
> It is affected by these RC bugs:
> 972802: rust-webpki-roots: duplicates ca-certificates, remove from Debian?
>  https://bugs.debian.org/972802
> 

BR is now aware of the deadline of 2020-11-22


Previously in this bug report:
> However, rustls is a common package in Rust world and the Rust team might 
> want to keep it.


Would splitting off  Rust source code and  CA certificates   make sense?

Bug#973481: ITP: please -- Please, a sudo clone with regex support

[Geert Stappers]

On Sat, Oct 31, 2020 at 01:59:49PM +, Edward Neville wrote:
> 
> * Package name: please
>   Upstream Author : Ed Neville 
> * URL : https://gitlab.com/edneville/please
> * License : GPL
>   Programming Lang: Rust
>   Description : Please, a sudo clone with regex support
> 
...
> 
> A sponsor is required.
> 

Sponsor reporting for duty;-)


Regards
Geert Stappers
DD
-- 
Silence is hard to parse


signature.asc
Description: PGP signature

Bug#972579: [Pkg-rust-maintainers] Comments regarding rust-kmon_1.3.0-1_amd64.changes

[Geert Stappers]

On Sun, Oct 18, 2020 at 08:27:30PM +, Joerg Jaspert wrote:
> Hi Maintainer,
> 
>  c002350518c0bbe87a18994ec6869411 10347 FIXME-(source.section) optional 
> rust-kmon_1.3.0-1_amd64.buildinfo
>  f6f32a721903d3c2fa78fc2e6b095695 2391 FIXME-(source.section) optional 
> rust-kmon_1.3.0-1.dsc
> 
> Uh yeah, one should fixup all FIXMEs before uploading. :)
> 

Point taken.

And thanks for the reminder
22:35 < Ganneff> W: zoxide: unknown-section FIXME-(source.section)
22:36 < Ganneff> not the first time i see that in a package. does debcargo
 sometimes fail there (and maintainer obviously not checking 
lintian)?
22:52 < dkg> Ganneff: debcargo should be noticing that and warning, but
 of course it can't fix it itself.  maybe Sylvestre overlooked the 
FIXME somehow?
22:52 < dkg> i can try to take a look at it
22:53 < Ganneff> just the second time i saw that.
22:53 < stappers> Acknowledge on that
22:53 < Ganneff> i sure can (and did) overwrite it for the archive, thats no 
problem,
 but package should be fixed.


Regards
Geert Stappers
Adding this to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972579
-- 
Silence is hard to parse

Bug#972470: RFS: ipqalc/1.5.3+git20200816.523b207-1 -- graphical utility for IPv4 subnet calculation

[Geert Stappers]

On Sun, Oct 18, 2020 at 06:39:03PM -0300, Fabio Augusto De Muzio Tobich wrote:
> Package: sponsorship-requests
>  * Package name: ipqalc
>Upstream Author : https://bitbucket.org/admsasha/ipqalc/issues/new

Strange name


>  ipqalc (1.5.3+git20200816.523b207-1) unstable; urgency=medium
>  .
>* New upstream release.
>* Upload to unstable.
>* debian/control: added 'qt5-qmake:native' in Build-Depends field to 
> prevent
>  FTCBFS.

What is FTCBFS?


>* debian/tests/control: changed last test to run a script instead a
>  Test-Command and marked as superficial.
>* debian/tests/run: added to run a simple test.
> 


Regards
Geert Stappers
-- 
Silence is hard to parse

Bug#894429: danling mailinglist request

[Geert Stappers]

Hello pkg-deepin-de...@lists.alioth.debian.org

For which reason
is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894429
still open?

Please express why the mailinglist is desired/wanted
or close the dangling request.


Regards
Geert Stappers
DD
-- 
Silence is hard to parse

Bug#971984: installation-reports: installation report

[Geert Stappers]

Control: tag -1 moreinfo


On Sun, Oct 11, 2020 at 01:42:17AM -0400, WK Burke wrote:
> Package: installation-reports
> 
> Boot method: usb
> Image version: debian 10.0 iso
> 
> Machine: Dell Inspiron 15-3567
> 
> 
> Base System Installation Checklist:
> [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
> 
> Initial boot:   [ ]
> Detect network card:[ ]
> Configure network:  [ ]
> Detect CD:  [ ]
> Load installer modules: [ ]
> Clock/timezone setup:   [ ]
> User/password setup:[ ]
> Detect hard drives: [ ]
> Partition hard drives:  [ ]
> Install base system:[ ]
> Install tasks:  [ ]
> Install boot loader:[ ]
> Overall install:[ ]
> 
> Comments/Problems:
> 
>and ideas you had during the initial install.>
> 
> 
> 
> 
> 
> ==
> Installer lsb-release:
> ==
> DISTRIB_ID=Debian
> DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
> DISTRIB_RELEASE="10 (buster) - installer build 20190702"
> X_INSTALLATION_MEDIUM=cdrom
> 
> uname -a: Linux zues 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5 (2019-06-19) 
> x86_64 GNU/Linux



Please tell more about the installation success.

And that includes a message like "the install went just fine"   :-)




Regards
Geert Stappers
-- 
Silence is hard to parse

Bug#971606: installation-reports cubieboard 5

[Geert Stappers]

On Sun, Oct 04, 2020 at 01:03:00AM +0300, Валериан Пережигин wrote:
> 03.10.2020, 22:53, Geert Stappers
> > Please rerun the installer, find a shell, do `lsblk`
> > and pretty please report back.
> 
> BusyBox v1.30.1 (Debian 1:1.30.1-4) built-in shell (ash)
> Enter 'help' for a list of built-in commands.
> 
> ~ # lsblk
> /bin/sh: lsblk: not found
> ~ # ls
> ls lsmod lspci lsscsi
> ~ # blk
> blkdiscard blkid

Ah, yes that command


> ~ # blkid
> /dev/sda1: LABEL="cb5-boot" UUID="a3d6a5a1-9796-4605-a317-8bdc94af219e" 
> TYPE="ext2" PARTUUID="fdb06b7f-01"
> /dev/sda2: UUID="87c9e46c-1293-474e-801d-3a0f5ee3569d" TYPE="swap" 
> PARTUUID="fdb06b7f-02"
> /dev/sda3: LABEL="cb5" UUID="adb31049-edbb-4d50-b4a2-0aca6a82159b" 
> TYPE="ext4" PARTUUID="fdb06b7f-03"
> /dev/sda4: LABEL="cb5-home" UUID="29c228f9-6541-4ff7-bf5c-44ebb8eebe6d" 
> TYPE="ext4" PARTUUID="fdb06b7f-04"
> /dev/sdb1: LABEL_FATBOOT="BLACK16G" LABEL="BLACK16G" UUID="6088-862B" 
> TYPE="vfat" PARTUUID="b7bb8d8a-01"
> /dev/sdb2: LABEL="DebTry" UUID="e95a4f9e-e1fb-4679-9d1d-63a516e76a8a" 
> TYPE="ext4" PARTUUID="b7bb8d8a-02"
> /dev/sdb3: UUID="3ee578b5-a253-459e-810d-34885848b8b5" TYPE="swap" 
> PARTUUID="b7bb8d8a-03"
> /dev/sdb4: LABEL="DebTry-home" UUID="221e7afe-a030-40e5-8bdf-79bea0e0fcaa" 
> TYPE="ext4" PARTUUID="b7bb8d8a-04"
> /dev/loop0: UUID="2020-09-26-15-00-29-00" LABEL="Debian 10.6.0 armhf 1" 
> TYPE="iso9660" PTTYPE="dos"
> ~ #

/dev/sda, /dev/sdb  and /dev/loop0.

No /dev/mmcblk

 

> That's all. Usb storage device new, because old one already reused.

I'm not sure about that. I don't know what is attached to the
cubieboard. But /dev/sdb1, labelled BLACK16G, is something I would
inspect closer.

> The installer worked ok. I have no routine to install debian using uart.
> Normal questions, answer. Ui was uncomfortable, but worked fine.
> Excluding the fact that no sdcard (or mmc) showed up.
> 
> Then, when i tried to boot: system booted from mmc (to debian installer or
> android if ejected).
> 
> Expected behavior, since no processing to cards was made.
> 
> > > System worked
> >
> > "System worked" as: The installer came alive and showed behaviour as
> > seen at other installs ???
>
> "System worked" mean that cb5 (with debian just installed) showed login prompt
>_(after additional steps (3 described)).
> 

Mmm, chips.  So a working Debian system,
but getting that far was NOT that easy as expected.


Regards
Geert Stappers

P.S.
Please keep the BTS, the Bug Tracking System, in the loop.
-- 
Silence is hard to parse

Bug#971606: installation-reports cubieboard 5

[Geert Stappers]

Control: tag -1 moreinfo

On Sat, Oct 03, 2020 at 12:17:51AM +0300, Валериан Пережигин wrote:
> Package: installation-reports
> 
> Boot method: hd-media/sd-card-images + usb (fat32) with
> 
> debian-cd debian-10.6.0-armhf-xfce-CD-1.iso.
> 
> I was using uart (pl2303).
> Image version: 
> https://mirror.yandex.ru/debian-cd/10.6.0/armhf/bt-cd/debian-10.6.0-armhf-xfce-CD-1.iso.torrent
> Date: 2020-10-01 20:12 MSK
> 
> Machine: cubietech cubietrick plus (cubieboard 5)
> Processor: soc A83t (2GHz ?)
> Memory: 2GiB (DDR3 at 672MHz)
> 
> Comments/Problems:
> 
> No sdcard demonstrated, only usb and sata.
> No dp or hdmi.
> Installation to sata (manually prepared dos partitioning, just select 
> filesystems) sucsessed.
> Installation of u-boot climed sucsess yet failed (system was not bootable).
> 
> By main pc:
> 1. copyed boot partition (from sata) to sdcard.
> 2. installed by dd u-boot (from u-boot-sunxi_2020.10~rc5+dfsg-1_armhf.deb) to 
> sdcard.

Acknowledge


> 3. insertied sdcard to cb5.
> 
> System worked.

"System worked" as:   The installer came alive and showed behaviour as
seen at other installs ???


> But no video, no network, no sdcard.
> Uart work fine.
> Usb came up after long delay (with some errors).
> 
> Kernel update yet again claim no errors, but bootloader is stil to be 
> installed.
> 
> I regret sdcard not showed up.

Please rerun the installer, find a shell,  do  `lsblk`
and pretty please report back.



Regards
Geert Stappers
-- 
Silence is hard to parse

Bug#971633: [Pkg-rust-maintainers] Bug#971633: debcargo: Debcargo should provide a man page

[Geert Stappers]

Control: severity -1 normal
Thanks

On Sat, Oct 03, 2020 at 10:49:43AM -0700, Diane Trout wrote:
> Package: debcargo
> Severity: wishlist
> 
> 
> Debian policy encourages all packages to provide a manpage.
> 
> §12.1 "If no manual page is available, this is considered as a bug and should
> be reported to the Debian Bug Tracking System (the maintainer of the package 
> is
> allowed to write this bug report themselves, if they so desire). Do not close
> the bug report until a proper man page is available"
> 
> It would be nice to have some included instructions about how to use debcargo.


It is normal to have instructions how to use a program.



My offer in this:

Write the usage text of debcargo, I'll convert it to manual page.



Regards
Geert Stappers

P.S.
If the usage text already exists, please say so.


signature.asc
Description: PGP signature

Bug#966088: mailinglist debian-r...@lists.debian.org create as open list

[Geert Stappers]

On Thu, Sep 10, 2020 at 10:52:20PM +0200, Geert Stappers wrote:
> 
> Basic purpose: 
>   Email discussion channel for Rust in Debian.
> 
> (Secundaire purpose:
>   Preventing that humans get flooded
>   by all the automatic emails from builds and such)
> 
> Interested audience:
>   People interested in Rust and Debian
>   plus the overlap they both have.
> 
> 
> > Unless you come up with at least 3 moderators we will create the list
> > as on open list (which we prefer anyhow).
> 
> Reporting myself for moderator duty.   :-)
> E-mail address:  stapp...@stappers.nl
> so others wanting to help with this
> don't feel the hurdle of having a   @debian.org address.
> 
> Wednesday september 23th is a meeting in #debian-rust
> there I want get consensus for open list versus moderated list
> 
> So accept next contact after that monthly meeting.

That meeting did happen 30th  september.

 
> Meanwhile we, debian-rust team, will check for apetide
> on moderation or open list.

Yes, create as  OPEN  list.


> Thank you for making it possible.

+1;-)


Regards
Geert Stappers
DD
-- 
Silence is hard to parse

Bug#963171: Reverting Bug#963171 marked as done (ITP: golang-github-liamhaworth-go-tproxy -- Linux Transparent Proxy library for Golang)

[Geert Stappers]

Control: reopen -1

On Sun, Sep 27, 2020 at 08:36:03AM +, Debian Bug Tracking System wrote:
> Your message dated Sun, 27 Sep 2020 08:33:23 +
> with message-id 
> and subject line Bug#963171: fixed in due 2.0.0-2
> has caused the Debian Bug report #963171,
> regarding ITP: golang-github-liamhaworth-go-tproxy -- Linux Transparent Proxy 
> library for Golang
> to be marked as done.
> 
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.

Sorry for my mistaken on closing the wrong ITP.


Regards
Geert Stappers
DD
-- 
Silence is hard to parse


signature.asc
Description: PGP signature

Bug#961371: Migrating to testing

[Geert Stappers]

At https://tracker.debian.org/pkg/due is currently this:
--
testing migrations

excuses:
* Migration status for due (- to 2.0.0-1): BLOCKED: Rejected/violates migration 
policy/introduces a regression
* Issues preventing migration:
* Not built on buildd: arch all binaries uploaded by stappers, a new 
source-only upload is needed to allow migration
* Too young, only 3 of 5 days old
* Additional info:
* Piuparts tested OK - https://piuparts.debian.org/sid/source/d/due.html
* Not considered
--

I don't yet know what the
  "a new source-only upload is needed to allow migration"
does mean.  So I wait for "5 days old" to happen.


Regards
Geert Stappers
-- 
Silence is hard to parse

Bug#962102: Fwd: ltunify_0.3-1 in NEW

[Geert Stappers]

- Forwarded message from Debian FTP Masters 
 -

Date: Tue, 22 Sep 2020 17:34:00 +
From: Debian FTP Masters 
To: Anthony Perkins , stapp...@debian.org
Subject: ltunify_0.3-1_amd64.changes is NEW

binary:ltunify is NEW.
binary:ltunify is NEW.
source:ltunify is NEW.

Your package has been put into the NEW queue, which requires manual action
from the ftpteam to process. The upload was otherwise valid (it had a good
OpenPGP signature and file hashes are valid), so please be patient.

Packages are routinely processed through to the archive, and do feel
free to browse the NEW queue[1].

If there is an issue with the upload, you will receive an email from a
member of the ftpteam.

If you have any questions, you may reply to this email.

[1]: https://ftp-master.debian.org/new.html
 or https://ftp-master.debian.org/backports-new.html for *-backports

- End forwarded message -

Regards
Geert Stappers
-- 
Silence is hard to parse

Bug#961371: due_2.0.0-1_amd64.changes ACCEPTED into unstable

[Geert Stappers]

On Tue, Sep 22, 2020 at 07:39:23AM -0700, Alex Doyle wrote:
> Hi Geert,
>  That's excellent! Thanks so much for your help with this.
> 
> I expect it will be a while ( like, months ) until I have a new version
> ready to release. From reading the mentor's faq, it looks like I should
> contact you?

Yes, feel free to contact me.

FWIW  Incase "upstream" releases v2.0.1 ( git tag v2.0.1 ; git push --tags )
or whatever the next version number might be.  I'm happy to sponsor the upload.

 
> I'd imagine that from here on out it would be a  lot less work involved to
> approve new versions since there is a known good baseline to compare
> against.
> 
> And thanks again - if we're ever at the same DebConf, I definitely owe you
> a beverage of your choice :)

:-)   We will find a way to celebrate what did together.


> -Alex
> 
> On Tue, Sep 22, 2020 at 5:57 AM Geert Stappers wrote:
> 
> > - Forwarded message from Debian FTP Masters <
> > ftpmas...@ftp-master.debian.org> -
> >
> > Date: Tue, 22 Sep 2020 12:00:09 +
> > From: Debian FTP Masters 
> > To: Alex Doyle , stapp...@debian.org
> > Subject: due_2.0.0-1_amd64.changes ACCEPTED into unstable, unstable
> >
> >
> >
> > Accepted:
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > Format: 1.8
> > Date: Sat, 19 Sep 2020 22:39:58 +0200
> > Source: due
> > Binary: due
> > Architecture: source all
> > Version: 2.0.0-1
> > Distribution: unstable
> > Urgency: medium
> > Maintainer: Alex Doyle 
> > Changed-By: Alex Doyle 
> > Description:
> >  due- Dedicated User Environment: manage build environments in 
> > Docker c
> > Closes: 931617
} }  ^
> > Changes:
> >  due (2.0.0-1) unstable; urgency=medium
> >  .
> >[ Alex Doyle ]
> >* Initial upload. Closes: #931617
> >  .
> >[ Geert Stappers ]
> >* Uploader
> > Checksums-Sha1:
> >  88e1e57205188ce920e74d13a00025ba94aef04a 1852 due_2.0.0-1.dsc
> >  b37ff0b79c5e26760c5bc170c70889570e127d14 105376 due_2.0.0.orig.tar.gz
> >  2ff9c89b48952cf4dc36b1089d50b48160f3fcc7 2996 due_2.0.0-1.debian.tar.xz
> >  fbcab6e758a3c4c3436dc27006cfd7b0d690dcdb 74120 due_2.0.0-1_all.deb
> >  739d14896bed173ac0e728f21505bd897bc10ef3 6428 due_2.0.0-1_amd64.buildinfo
> > Files:
> >  4fb5cff6346482839b5fbc6b4a18dc3b 1852 devel optional due_2.0.0-1.dsc
> >  2475a84a68ff837854caa1c607eab862 105376 devel optional 
> > due_2.0.0.orig.tar.gz
> >  4ae14448019b16133ff25009a56d1a61 2996 devel optional 
> > due_2.0.0-1.debian.tar.xz
> >  27b8b03bc1bc88215bf834b268e7b2fd 74120 devel optional due_2.0.0-1_all.deb
> >  620d5bea2ced8f41fa3923a594784bf7 6428 devel optional 
> > due_2.0.0-1_amd64.buildinfo
> >
> >
> > Thank you for your contribution to Debian.
> >
> > - End forwarded message -

Regards
Geert Stappers
-- 
Silence is hard to parse

Bug#961371: [ftpmas...@ftp-master.debian.org: due_2.0.0-1_amd64.changes ACCEPTED into unstable, unstable]

[Geert Stappers]

- Forwarded message from Debian FTP Masters 
 -

Date: Tue, 22 Sep 2020 12:00:09 +
From: Debian FTP Masters 
To: Alex Doyle , stapp...@debian.org
Subject: due_2.0.0-1_amd64.changes ACCEPTED into unstable, unstable



Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 19 Sep 2020 22:39:58 +0200
Source: due
Binary: due
Architecture: source all
Version: 2.0.0-1
Distribution: unstable
Urgency: medium
Maintainer: Alex Doyle 
Changed-By: Alex Doyle 
Description:
 due- Dedicated User Environment: manage build environments in Docker c
Closes: 931617
Changes:
 due (2.0.0-1) unstable; urgency=medium
 .
   [ Alex Doyle ]
   * Initial upload. Closes: #931617
 .
   [ Geert Stappers ]
   * Uploader
Checksums-Sha1:
 88e1e57205188ce920e74d13a00025ba94aef04a 1852 due_2.0.0-1.dsc
 b37ff0b79c5e26760c5bc170c70889570e127d14 105376 due_2.0.0.orig.tar.gz
 2ff9c89b48952cf4dc36b1089d50b48160f3fcc7 2996 due_2.0.0-1.debian.tar.xz
 fbcab6e758a3c4c3436dc27006cfd7b0d690dcdb 74120 due_2.0.0-1_all.deb
 739d14896bed173ac0e728f21505bd897bc10ef3 6428 due_2.0.0-1_amd64.buildinfo
Checksums-Sha256:
 bc2c85160464733d11ae6701e3a178d7f1a137ab22b9ef0724eba0affc8d7a88 1852 
due_2.0.0-1.dsc
 5a19ff71aaef037ec4b82bc925387065976e721ec08b488ffd597dfebde97780 105376 
due_2.0.0.orig.tar.gz
 066fc8861f0ac05b90e01b8bc7f6e239e1c326e9d842852d345f295a8775210a 2996 
due_2.0.0-1.debian.tar.xz
 619982dccb9589f15de424a557ec75d0fcd56644b6083ae5de8be31695994b4c 74120 
due_2.0.0-1_all.deb
 9827e5c697f81e2200a7af1ddfc89e3a0bf777c2a21606f7bc7f8acc38858527 6428 
due_2.0.0-1_amd64.buildinfo
Files:
 4fb5cff6346482839b5fbc6b4a18dc3b 1852 devel optional due_2.0.0-1.dsc
 2475a84a68ff837854caa1c607eab862 105376 devel optional due_2.0.0.orig.tar.gz
 4ae14448019b16133ff25009a56d1a61 2996 devel optional due_2.0.0-1.debian.tar.xz
 27b8b03bc1bc88215bf834b268e7b2fd 74120 devel optional due_2.0.0-1_all.deb
 620d5bea2ced8f41fa3923a594784bf7 6428 devel optional 
due_2.0.0-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEin8gjG2ecykWV0FNITXRI9jBm+wFAl9mckwACgkQITXRI9jB
m+xoNQ/9GLNX2pu3ivT6pnraXR0R6LyOdROv2qx0/7q22sYgsI4j3Arj8xtASNSK
7pO3HpMOmjdd3hRweO1EWrpQ6T+avqJBxirPSzFez673/P9xvNQRhhh/2ntqFQhu
lxqom+iK48vyKFbUpE/2l1eoRzSHslTzBJP01IslfUj3zq+4HgXXzDy9Uv89xHL7
B6L2aTaIFcME/mUayTHV/Sy8LPsaJmyGXNcV70ibXNklLMRww4VDUP1BvLzkGjl9
Z54e85EzgwQokeQRwceA7hRTYLjZGFSRPH4lFkO81oeetv4TyQbfMRvLNb0UGvUy
Lka6UvjU1vmjoQB/zCM8xJKDvWjuJofEXDVeJl8H3l7/vNZlq2A27TfkbEy5TrGZ
Wblf9ga1XjiEokfFMo8jgbSQpaCLOOkof27Ac6FT/7AyviQzU1U+zULlPdtbP3jI
a9epABkge/fnGRW0wTRklZjl0RyLnv7BWit+S0aRWunWBHueC0uzSRBVf/aUr6iX
KrSeyotMVl8ZBkimc4Rb7M5Usu/vYXoQxA04CIZ7uPW3pFd1TmTxW6FipcieAn0j
31zkM+4KriDPuV4i9DtuZb+ePZ0YRYHPVCxY4ghG2ZaltN7KnRqyTSWBdPIA5YtD
pVpD77tswBM/97GAoN5nDv3uuW6XYtBBhGv3A2rGQOPwp5XCbbw=
=t2dI
-END PGP SIGNATURE-


Thank you for your contribution to Debian.

- End forwarded message -

-- 
Regards
Geert Stappers
-- 
Silence is hard to parse

Bug#970678: Forwarding debian-boot posting

[Geert Stappers]

- Partly forwarded message from Bjørn Mork -

Date: Tue, 22 Sep 2020 12:17:38 +0200
From: Bjørn Mork
To: debian-b...@lists.debian.org
Subject: Re: Bug#970678: Network preseeding using http is broken

Ben Hutchings  writes:
>
> It's a udev regression, bug #967546.

Looks like that's deliberate, so probably Not A Bug.  Quoting from
https://github.com/systemd/systemd/commit/6b2229c6c60d0486 :

 "if people want to use udev from other init systems
  they should do this on their own,"

You might want to just fork udev while it still sort of works outside
systemd.


Bjørn

- End partly forwarded message -

I hope this helps both bugreports.


Regards
Geert Stappers
-- 
Silence is hard to parse

Bug#970678: Network preseeding using http is broken

[Geert Stappers]

On Mon, Sep 21, 2020 at 03:30:27PM +0200, Philip Hands wrote:
> Martin Samuelsson  writes:
> 
> > Booting the installer with DEBCONF_DEBUG=5 and debuging /bin/preseed_fetch, 
> > /bin/fetch-url and /usr/lib/fetch_url/http shows that wget404() in the 
> > latter is what's failing. It seems the pipeline fails since /dev/fd/4 does 
> > not exist.
> 
> Just to be clear on this point, are you saying that /dev/fd/4 does not
> exist when you look for it in a shell, or rather specifically when doing
> so in a context where it is in use?
> 
> If you noticed that it's not there when e.g. simply listing the contents
> of /dev/fd then that's normal AFAIK.
> 
> To illustrate this, here's some output from busybox shell, running on my
> laptop:
> 
> =-=-=-=-
> ~ $ echo /dev/fd/*
> /dev/fd/0 /dev/fd/1 /dev/fd/10 /dev/fd/2 /dev/fd/3
> ~ $ ( echo /dev/fd/* ) 4>&1
> /dev/fd/0 /dev/fd/1 /dev/fd/10 /dev/fd/2 /dev/fd/3 /dev/fd/4
> ~ $ ( echo /dev/fd/* ) 4>&1 5>&1
> /dev/fd/0 /dev/fd/1 /dev/fd/10 /dev/fd/2 /dev/fd/3 /dev/fd/4 /dev/fd/5
> ~ $  ( echo /dev/fd/* ) 6>&1
> /dev/fd/0 /dev/fd/1 /dev/fd/10 /dev/fd/2 /dev/fd/3 /dev/fd/6
> ~ $
> =-=-=-=-
> 


On Mon, Sep 21, 2020 at 02:58:36PM +0200, Philip Hands wrote:
 ...
> 
> The fact that /dev/fd/4 is missing does seem to be a separate bug, but a
> quick grep -lr suggests that this is the only place it's used in d-i, so
> perhaps a bug we need not worry about too much.
> 


Under which circumstance does the bug shows itself?



Regards
Geert Stappers
-- 
Silence is hard to parse

Bug#961371: Oops

[Geert Stappers]

Ai, uploaded with wrong  bugnumber to close

https://ftp-master.debian.org/new/due_2.0.0-1.html


Sorry
Geert Stappers
-- 
Silence is hard to parse

Bug#914813: Some additional informations

[Geert Stappers]

On Fri, Sep 18, 2020 at 10:42:05PM +0200, Bernhard wrote:
> Is it possible, that the RSB kernel module is missing (drivers/bus/)?
> Or, is it possible, that the AXP kernel module is missing?

The file /boot/config-$( uname -r )  can tell.


Regards
Geert Stappers
-- 
stappers@paddy:~
$ cd /boot/
stappers@paddy:/boot
$ ls
config-5.7.0-2-amd64  initrd.img-5.7.0-2-amd64  System.map-5.7.0-2-amd64
vmlinuz-5.8.0-1-amd64
config-5.8.0-1-amd64  initrd.img-5.8.0-1-amd64  System.map-5.8.0-1-amd64
grub  lost+foundvmlinuz-5.7.0-2-amd64
stappers@paddy:/boot
$ uname -r
5.8.0-1-amd64
stappers@paddy:/boot
$ ls -l /boot/config-$( uname -r )
-rw-r--r-- 1 root root 233667  5 sep 16:52 /boot/config-5.8.0-1-amd64
stappers@paddy:/boot
$ 

Bug#966088: mailinglist debian-r...@lists.debian.org

[Geert Stappers]

Hello Listmasters,


And hello pkg-rust-maintainers mailinglist subscribers,

On Thu, Sep 10, 2020 at 09:58:51PM +0200, Alexander Wirt wrote:
> Please provide us with the information described in
> https://www.debian.org/MailingLists/HOWTO_start_list (Description,
> Category and so on).

Basic purpose: 
  Email discussion channel for Rust in Debian.

(Secundaire purpose:
  Preventing that humans get flooded
  by all the automatic emails from builds and such)

Interested audience:
  People interested in Rust and Debian
  plus the overlap they both have.


> Unless you come up with at least 3 moderators we will create the list
> as on open list (which we prefer anyhow).

Reporting myself for moderator duty.   :-)
E-mail address:  stapp...@stappers.nl
so others wanting to help with this
don't feel the hurdle of having a   @debian.org address.

Wednesday september 23th is a meeting in #debian-rust
there I want get consensus for open list versus moderated list

So accept next contact after that monthly meeting.

Meanwhile we, debian-rust team, will check for apetide
on moderation or open list.


Thank you for making it possible.



Regards
Geert Stappers
Debian Developer

P.S.
The Cc: to pkg-rust-maintain...@alioth-lists.debian.net
is for asking more moderators.
And a way for voting   "open list"  versus "moderated list"
-- 
Silence is hard to parse


signature.asc
Description: PGP signature

Bug#969402: installation-reports: does not start with -q option specified

[Geert Stappers]

Control: tag 969402 +moreinfo

On Tue, Sep 01, 2020 at 11:56:41PM -0300, LILIAN wrote:
}  ... only the empty template ...

Pleaes tell more,
such as where your added the  -qand what you expect from it.


Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#969381: Viva espanol

[Geert Stappers]

On Tue, Sep 01, 2020 at 08:03:46PM +0200, Camaleón wrote:
> Hello,
> 
> I have to disagree.

I see content for a conflict.
Please proof me wrong and show the world that there is common ground.


Regards
Geert Stappers
DD
-- 
Silence is hard to parse

Bug#961371: Progress report 2020-08-23

[Geert Stappers]

(Previous message to this issue is about 7 weeks old.)

Work is in progress.  The "blocking" part is me, stappers@d.o., lobbying
for separation between "upstream" of DUE and the packaging of DUE.
We are getting there.

Plug 
https://debconf20.debconf.org/talks/7-due-a-container-manager-for-building-things-that-arent-debianized-and-things-that-are/