Re: About i386 support

[Tomas Pospisek]

Hi Maite, hi Rhys,


don't top-post. That breaks the flow of the arguments being argued about.


*From:* Johannes Schauer Marin Rodrigues 
*Sent:* Friday, May 17, 2024 15:48
*To:* Victor Gamper; debian-devel@lists.debian.org
*Subject:* Re: About i386 support

Quoting Victor Gamper (2024-05-17 21:58:58)
> Is there a reason to do this? If so, what would be required to keep 
the i386

> version, seeing as it still is important and used?

anything can be done if there are enough contributors who care.

For i386 there is a severe lack of person-power. Do you want to start
contributing your free-time for several years to come to d-i and other 
areas

which are needed to keep i386 more alive for longer?


> On 18.05.24 03:15, r...@neoquasar.org wrote:
>> That depends. What would be required of such a person? I also have
>> several i386-class machines that run Debian (though only one that can
>> run Debian 12).

On 18.05.24 15:16, Maite Gamper wrote:

> Whilst I can't for sure say how much free time I'll have, I'd like
> to try and contribute. How would you get started with that?

There's somewhere a page that is showing how much of the archive is 
built by architecture. A search engine should help you finding that 
page. Pick the package that is furthest down the stack of package 
dependencies that is not building on i386. Find out why. Fix the bug. 
Check if there's a bug report about the problem. Send a patch. If the 
maintainer doesn't have time then become a Debian Maintainer oder 
Developer yourself consult with the package's maintainers and upload 
fixed packages.

*t

Bug#1036077: please reassign to xserver

[Tomas Pospisek]

Since this seems to be a xserver problem, could you please reassign the 
ticket to the correct xserver package?

*t

Re: add make-4.4.1 to experimental

[Tomas Pospisek]

Hi Ilari

On 18.03.23 04:00, Ilari Jääskeläinen wrote:


There is a new upstream release available.


Please report your issue as a wishlist ticket. To do that do as root:


apt install reportbug

Then do as non-root:

reportbug --severity=wishlist make

Greetings,
*t

Re: Consensus on closing old bugs

[Tomas Pospisek]

On 06.02.23 11:51, Santiago Vila wrote:

El 6/2/23 a las 11:26, Brian Thompson escribió:

I understand that the usual way to close out bug reports is having the
original author do it themselves.  What's the policy on closing bug 
reports

that haven't had activity in over 6 months?


Let the maintainers handle their bugs.
Old bugs should not be closed just because they are "old".

For example, I have an open bug which is 26 years old:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=5898

and I don't see any reason to close it.


However I'd like to put Santiago's reply into perspective (I am not 
contradicting him!):


There's *a lot* of Debian packages that are not maintained very 
actively. Often when I report bugs against some package I will do a bit 
of triage as a "recompensation" for being allowed to report it and for 
the time the maintainer will have to invest in reading my bug report.


So when I see f.ex. reports against versions of the package against old 
Debian releases, that are no longer supported where the last entry in 
the bug report is the maintainer asking a question that hasn't been 
replied to in years, then I go and close that bug report.


I do explain why I am closing it (version not supported any more, there 
are more recent package versions where probably the bug was fixed (if 
that's really the case!), no reply from reporter, thus it's not expected 
that anything will ever come out of the report any more). And I am also 
explaining that closing the bug might be in error, and excusing myself 
if that would be the case and asking the reporter to please reopen the 
bug or to tell me then I will. That is because I can never fully know 
the context of the reporter and thus that bug might be important to the 
reporter (or the maintainer).


All that said, I have never received negative feedback to these bug 
triages that I am occassionaly doing and am under the impression that 
the maintainers *do* appreciate someone going over their packages bugs 
from time to time and closing bugs that to the best of one's judgement 
will not be taken care of any more.


I have to emphasize that the place that I am coming from is that I 
absolutely despise all the robots (f.ex. on github or in launchpad) that 
are roaming around and automatically closing (my!) old bugreports, since 
I have put effort in them and I feel my efforts get shat on when this 
occurs. So that's the angle I'm working from: I absolutely want to 
respect the bug reporter and his effort and possibly the importance 
she's attaching to to some problem that she is eperiencing or has 
experienced. Same for the maintainer that possibly wants to keep his 
package clean and bug-less and puts effort into the reports against his 
packages and cares even about old stuff that *still* doesn't work.


In short, my advice:

* please *do* triage other maintainer's bugs - after all Debian is a 
*collaborative* effort. It is very much appreciated (at least by me).
* please put respect for the reporter and the maintainer and their 
efforts first before any other concerns such as efficiency


Thanks for caring!
*t

PS: Dear reader please correct me or add to if what I'm arguing above is 
wrong.

Re: loong64: dpkg modification patch

[Tomas Pospisek]

Hello Han Gao,

I *think* it's better if you work "the standard Debian way". I.e. file a 
bug against dpkg with the reportbug tool, and attach the patch to the 
bug report.


Thanks for the effort to support the loong architecture,
*t

On 20.12.22 01:26, Han Gao wrote:

Hi, Guillem:
refer the documentation[0]
    added loong64f32, loong64sf Debian arch name
    fixed toolchain tuple

test result:
debian@debian-builder-3:~/oss/gcc-12-12.2.0/debian$ dpkg-architecture -f 
-aloong64sf | grep "DEB_HOST_"
dpkg-architecture: warning: specified GNU system type 
loongarch64-linux-gnusf does not match CC system type 
loongarch64-linux-gnu, try setting a correct CC environment variable

DEB_HOST_ARCH=loong64sf
DEB_HOST_ARCH_ABI=sf
DEB_HOST_ARCH_BITS=64
DEB_HOST_ARCH_CPU=loong64
DEB_HOST_ARCH_ENDIAN=little
DEB_HOST_ARCH_LIBC=gnu
DEB_HOST_ARCH_OS=linux
DEB_HOST_GNU_CPU=loongarch64
DEB_HOST_GNU_SYSTEM=linux-gnusf
DEB_HOST_GNU_TYPE=loongarch64-linux-gnusf
DEB_HOST_MULTIARCH=loongarch64-linux-gnusf
debian@debian-builder-3:~/oss/gcc-12-12.2.0/debian$ dpkg-architecture -f 
-aloong64f32 | grep "DEB_HOST_"
dpkg-architecture: warning: specified GNU system type 
loongarch64-linux-gnuf32 does not match CC system type 
loongarch64-linux-gnu, try setting a correct CC environment variable

DEB_HOST_ARCH=loong64f32
DEB_HOST_ARCH_ABI=f32
DEB_HOST_ARCH_BITS=64
DEB_HOST_ARCH_CPU=loong64
DEB_HOST_ARCH_ENDIAN=little
DEB_HOST_ARCH_LIBC=gnu
DEB_HOST_ARCH_OS=linux
DEB_HOST_GNU_CPU=loongarch64
DEB_HOST_GNU_SYSTEM=linux-gnuf32
DEB_HOST_GNU_TYPE=loongarch64-linux-gnuf32
DEB_HOST_MULTIARCH=loongarch64-linux-gnuf32
debian@debian-builder-3:~/oss/gcc-12-12.2.0/debian$ dpkg-architecture -f 
-aloong64 | grep "DEB_HOST_"
dpkg-architecture: warning: specified GNU system type 
loongarch64-linux-gnuf64 does not match CC system type 
loongarch64-linux-gnu, try setting a correct CC environment variable

DEB_HOST_ARCH=loong64
DEB_HOST_ARCH_ABI=f64
DEB_HOST_ARCH_BITS=64
DEB_HOST_ARCH_CPU=loong64
DEB_HOST_ARCH_ENDIAN=little
DEB_HOST_ARCH_LIBC=gnu
DEB_HOST_ARCH_OS=linux
DEB_HOST_GNU_CPU=loongarch64
DEB_HOST_GNU_SYSTEM=linux-gnuf64
DEB_HOST_GNU_TYPE=loongarch64-linux-gnuf64
DEB_HOST_MULTIARCH=loongarch64-linux-gnuf64

[0] 
https://loongson.github.io/LoongArch-Documentation/LoongArch-toolchain-conventions-EN.html 

allow users to install packages [was: Re: a two cent suggestion]

[Tomas Pospisek]

On 26.11.22 19:42, Patrice Duroux wrote:

Dear Debian people,

Already possible or not, I would like to have a Debian system for
which packages can be installed either by a specific user
(root/sysadmin as usual) only or by any other (or a group of) users.
But this would also depend on the class of the requested packages:
1. packages providing mainly commands or library facility (large
majority packages?),
2. packages providing modifying system runtime like (root) services,
new kernel modules, ... (very few packages?).

Any (or a specific group of) users could be able to install any
package of the first class by their own without asking a sysadmin (or
explicitly acquiring privilege of) user.

With this goal (dream?) in mind, I tried to cluster all the packages
between the one that wouldn't change the system runtime (and therefore
even after a reboot) and whatever would be the sign of that.Those
package installation should insure a sort of system default runtime
reproducibility in fact.

If needed in the future, any build process could help to class/tag a
package regarding this purpose (as it could also read any debian/*
packaging file).

Finally the best would be for apt to handle such a scenario, allowing
those users to run the apt command which may fail or not regarding
each package class.

To cluster packages, my first material is to look at the file contents
of a package (having content related to sbin or a systemd service or
init.d or ...)

Opinions or ideas are welcome.

Could this clustering by it-self be interesting fin any case (for
Debian QA, metrics...)?


A few thoughts -

* You should not crosspost. There's various reasons for that f.ex.
  discussion will split because - as in my case - I am not subscribed to
  debian-users...
* You haven't received any feedback yet on debian-devel. A reason
  for that might be that the idea is good, but the devil is in
  implementing it. So unless you come up with code and solutions,
  the idea for itself is maybe not that interesting to discuss
  (because everybody would like to have user installable packages...)
* Debian has "Tags" for packages. Have a look whether there's not
  already a classification like you suggest (or something very
  similar). Maybe you can contribute there (note that last I've
  heard the tag DB and system was unmaintained).

Greets,
*t

Re: The future of src:ntp

[Tomas Pospisek]

On 17.01.22 17:01, Bernhard Schmidt wrote:

a couple of years ago (in 2017) I stepped up to help bring src:ntp back 
in shape because I needed it for work. All uploads since that time have 
been made by me. An RFH bug had been open the whole time and just 
recently got the first message for five years, which made me remember my 
plan.


Back then cleaning up the official ntp.org package in Debian was without 
alternatives, because ntpsec was not born yet and chrony did not have 
any traction in the Debian world (as far as I could tell).


However, development for ntp.org is slow, upstream still using BitKeeper 
is cumbersome, and even the testsuite needs to be fixes on some 
architectures for new releases. Both ntpsec and chrony are (from my POV) 
the better alternatives now. To a point where I would rather use chrony 
for new deployments, but I'm shying away from not using my own work 
anymore for the lack of real-life testing.


I could just step down as a maintainer/uploader and have the ntp 
packaging bitrot, but this would be a large disservice to our users 
(unless someone else continues to maintain it). I think another option 
would be to migrate to one of the alternatives for Bookworm.


ntpsec and ntp should be largely configuration compatible, so even a 
takeover of the binary package names might be practical.


What do you think?


Sounds good to me.

Without your useful email I wouldn't even have been aware of the 
situation, so your email has already the useful effect of me planing 
migrating to ntpsec.


Thank you!
*t

Re: Touchpad driver on Lenovo X13 Yoga has major use-stopping bugs

[Tomas Pospisek]

Hi G.W.,

I don't think the debian-devel mailing list is the right place to debug 
this. Debugging this will need going back and forth over logs etc. The 
best place to advance on this problem is to go the debian IRC channel 
https://wiki.debian.org/IRC and do the diagnosing interactively there.


Greetings,
*t

On 16.01.22 21:03, G.W. wrote:

Are the developers aware of a major bug in the "ELAN0674:00 04F3:3193 Touchpad" 
touchpad driver?

I tried getting help for the problem of the touchpad suddenly requiring 2 fingers to move 
the cursor around (on USER list) but no help was offered. The touchpad situation 
deteriorates to get worse with more things going wrong without regular restarts. Having 
gone a few days without restarting the computer the touchpad settings have no failed to 
work at all. For example, even though I have "tap to click" disabled, tapping 
still results in a click. Even though I have the setting enabled to disable touchpad 
while typing, touchpad is not disable while typing.

these problems prevent any work from getting done cause typing results in the 
cursor moving position on its own resulting in my typing into a place above or 
below where I'm actually typing, among other problems.

Can anything be done to fix this situation? Or is my only fix to move to a 
different distro? The main reason I chose Debian is to not have to deal with 
crippling use bugs like this one. Are the devs doing anything to fix this bug 
ASAP? Can you offer any help?

I am running Debian 11 fully up to date on a Lenovo X13 Yoga Gen 2.

‐‐‐ Original Message ‐‐‐

On Friday, January 14th, 2022 at 10:41 AM, G.W.  wrote:


I was hoping someone could help me solve a problem on Debian 11 (bullseye) with 
GNOME 3.38.5. I am fully up to date.

I very much want to restore single finger function on touchpad without having 
to reboot. After using touchpad on Lenovo laptop for a while it often starts 
requiring 2 fingers on the touchpad to move the cursor and actions that would 
require 2 fingers then start requiring 3. Single finger is ignored entirely.

My touchpad driver appears to be: ELAN0674:00 04F3:3193 Touchpad

Rebooting always corrects the issue. but executing the following command does NOT correct the issue: xinput 
disable "ELAN0674:00 04F3:3193 Touchpad" && xinput enable "ELAN0674:00 04F3:3193 
Touchpad"

Perhaps this is not a good medium for trying to solve this problem. Is there something 
akin to "Ask Ubuntu" that serves the Debian community? If this is not a good 
medium for solving this problem, can you please direct me an appropriate medium? I posted 
this question on the Debian forums but have received zero replies.

Re: ungoogled-chromium?

[Tomas Pospisek]

On 08.12.21 08:27, Vincent Bernat wrote:

  ❦  7 December 2021 23:35 GMT, Simon McVittie:


I believe what Vincent meant is that the generic non-Flatpak binaries
provided by the "Ungoogled Chromium" project are compiled on unknown
machines and require trusting their submitters, whereas the Flatpak
binaries provided by Flathub are compiled from the same source
code provided by the "Ungoogled Chromium" project, but compiled on
Flathub infrastructure.


Yes.


The Debian packages get built by the open build service [1] though as 
far as I can see?

*t

[1] https://github.com/ungoogled-software/ungoogled-chromium-debian

ungoogled-chromium? [was: Re: Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)]

[Tomas Pospisek]

On 06.12.21 20:43, Noah Meyerhans wrote:

On Sun, Dec 05, 2021 at 07:58:17PM +0300, Dmitry Alexandrov wrote:

So what's happening with chromium in both sid and stable? I saw on d-release 
that it was removed from testing (#998676 and #998732), with a  discussion 
about ending security support for it in stable.


The problem really is lack of maintenance. In my opinion, chromium deserves an active 
*team* to support it in Debian.  <...>  The security team doesn't have the 
bandwidth to do it themselves, they need a team to help them.


Sorry for a silly question, but whatʼs so wrong with the build done by 
linuxmint.com [1], so Debian needs a whole team to duplicate their effort?  
Itʼs for Debian 10 (i. e. oldstable) as of now, but works fine at Sid in my 
(limited) experience.



Well, you can start with the fact that the Mint chromium source packages
don't even include the chromium source, let alone the sources for all
the other things they build (NodeJS, and more).

The biggest difficulty, as far as I can tell from my look at Chromium
from several months ago, is that our patch set [1] needs a lot of
attention with every chromium release.  Mint doesn't apply any patches
at all to the source, at least none of any real complexity.

One lesson we may take from Mint, though, is that it's not worth trying
to patch Chromium as much as we'd like.  Anything that we can do to
simplify the Chromium packaging will help us keep the package
up-to-date, which in turn will help us keep our users safer.  In my
opinion, we should be pretty aggressive about dropping as many of the
Chromium patches as possible, even if that means we link against
bundled/vendored dependencies.

Legal/licensing considerations are still important and I don't know if
we actually *can* ship builds based on the bundled stuff.  But based on
the number of patches we have to disable various things [2] or build
against system dependencies [3], I can't help but think we'd have an
easier time keeping this package fresh if we could drop some of those.

noah

1. 
https://salsa.debian.org/chromium-team/chromium/-/blob/master/debian/patches/series
2. 
https://salsa.debian.org/chromium-team/chromium/-/tree/master/debian/patches/disable
3. 
https://salsa.debian.org/chromium-team/chromium/-/tree/master/debian/patches/system


I'd also like to point out, that the ungoogled-chromium project has some 
overlap in goals with Debian and it'd possibly be interessing to join 
forces:


https://github.com/ungoogled-software/ungoogled-chromium-debian

(I have been running an ungoogled-chromium for a while (ca. a year 
ago?), however at that time their chrome wasn't extremely stable so I 
gave up again. Does anybody have experience using it recently?)

*t

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

[Tomas Pospisek]

On 07.12.21 19:14, Steinar H. Gunderson wrote:

On Tue, Dec 07, 2021 at 07:05:29PM +0100, Tomas Pospisek wrote:

So you being a DD and soon at work on Chromium the hope was that maybe you
could conduct some of upstream love to care about the world outside of
Google (?), here in particular Debian's effort to provide Chromium to its
users... to help that effort.


Obviously I cannot promise anything here; I'm currently even more in the dark
than you. :-) But if there's a list of relevant bugs somewhere, I at least
have a place to try to understand the issues at hand.


I think it'd be best if Debian's chromium maintainers (see the 
recipients of this email) would reply to this question, however if you 
go to chromium's BTS page [1] then all the bug reports that have a "↝" 
(a wavy arrow) have been forwarded upstream and - judging by the fact 
that the bugs are still open in the BTS - have probably not been dealt 
with upstream.

*t

[1] https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=chromium;dist=unstable

PS: I have included Mattia Rizzolo, Michael Gilbert and the Debian 
Chromium Team directly in the recipients, to be sure they see this 
email. I do hope you all do not mind.

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

[Tomas Pospisek]

Hi Steinar,


On 07.12.21 10:07, Steinar H. Gunderson wrote:

On Tue, Dec 07, 2021 at 08:55:00AM +0100, Tomas Pospisek wrote:

I note that Steinar Gunderson [1] is now employed by Google to work on
Chrome, so maybe there could be hope talking to him?


It's right that I'm just joining the Chromium team, although probably not in
an area that is interesting to you (Style & Font). (And of course, I don't
really have a say in anything yet, and I don't know anyone yet :-) )
I don't have the context here; what specifically is it that you're interested
in getting fixed?


problem explanation starts at [1]. Let me try to summarize (those in the 
known please correct me):


* chromium in Debian is *way* behind upstream
  * many security issues that are fixed upstream but not in Debian
  * chromium maintenance team is too small wrt to maintenance load
  * Debian is carrying many patches
* Debian has reported bugs and patches upstream in the bug tracker
  * at least some build/build-options related
  * no feedback at all from upstream, issues persist
* upstream's perception and attention seems to be limited to
  internal bug tracker

So you being a DD and soon at work on Chromium the hope was that maybe 
you could conduct some of upstream love to care about the world outside 
of Google (?), here in particular Debian's effort to provide Chromium to 
its users... to help that effort.

*t

[1] https://lists.debian.org/debian-devel/2021/12/msg00079.html

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

[Tomas Pospisek]

On 06.12.21 22:53, Mattia Rizzolo wrote:

On Mon, Dec 06, 2021 at 08:53:37PM +0100, Paul Gevers wrote:

I have good experience with some of my upstreams where they supported me by
adapting their build system to enable building without the bundled/vendored
dependencies. Has this been tried? Would it be worth pursuing?


It has been, yes.

I was looking when Micheal reported a few bugs (after my prodding) to
get a few build issues solved (actual FTBFS when building with specific
build flags).  Even those bug reports were completely ignored with no
answer whatsoever; the patches also ignored.

I'm led to believe the chromium team is not really playing with the
community at all, rather they are just following their internal bug
tracker instead.
Likewise, they are obviously not interested in supporting anything that
is not the official Google Chrome build (if it can even said they are
"supoprting" that).


I note that Steinar Gunderson [1] is now employed by Google to work on 
Chrome, so maybe there could be hope talking to him?

*t

[1] http://blog.sesse.net/blog/tech/2021-12-05-16-41_leaving_mysql.html

Re: uscan roadmap

[Tomas Pospisek]

On 01.12.21 12:50, Mattia Rizzolo wrote:


Likewise, I would love if uscan could just learn how github, gitlab,
launchpad, etc are made so prople won't have to bother with sticking
urls into watchfiles, such as:

   Source: GitHub
   Source-Options:
namespace: trendmicro
project: tlsh
match-on: tags|releases


Excellent idea: +1

However at the very moment that abstractions get introduced (which is 
+1), please, please, please do keep the poor users in mind when stuff 
*does not* work. I.e. please make uscan trivially debuggable.


Something like:

$ uscan --verbose
... found GitHub source definition:
Source: GitHub
Source-Options:
  namespace: trendmicro
  project: tlsh
  match-on: tags|releases
... using that GitHub source definition to find new release under 
https://github.com/foo/bar/releases/bar-1.2.3.tar (uscan.py:line 3498)


One of the regularly recurring frustrations I am encountering is that 
I'm using some SW that has abstracted something and I know in principle 
how the thing it has abstracted works, but am completely unable to find 
out where the abstraction gets all wired up and falls on its face. (Hi 
k8s!). The famous "computer says no" moment.


OK, this is just me whining and not contributing any code at all, so 
please take it as just that: a wishlist item.

*t

Re: Debian 11 Bullseye Setup Problems Error Report

[Tomas Pospisek]

G'day admin4,

I suggest you take this to the #debian IRC channel where you can 
hopefully drill down to the root cause of the problem. A mailing list 
like debian-devel is not really well suited to do back-and-forth 
debugging...

*t

On 23.09.21 12:08, admin4 wrote:

GoodDay Mates,

network connectivity dropping during package download is still there, it 
is a major problem, sometimes it works, sometimes not, this used to work 
very well.


it will especially annoy new users, so this issue need to be debugged & 
fixed!


will also write to SpaceX about it (if it has anything to do with their 
setup)


the free version iso seems to have have a network problem during package 
download: (after software selection)


https://forums.debian.net/viewtopic.php?f=17=149974=743218#p743218 



trying non-free now.

tried yesterday and today installing

https://cdimage.debian.org/debian-cd/cu ... 64/iso-cd/ 



on Lenovo t440

and the problem is still there... this time it downloaded 1388 packages 
of 1491 before grinding to a halt...


  * after software selection (wanted to try the KDE Desktop, being big
MATE fan for it's simplicity) from the default debian package mirror
https://ftp.de.debian.org/debian/ 

it just stops downloading packages after ~100 packages (loses 
connectivity) and stays there until timeout[/list]


  * downloading isos via wget from just works fine

best regards

On 8/19/21 5:25 AM, Paul Wise wrote:

On Wed, Aug 18, 2021 at 10:42 AM admin4  wrote:


is there a Debian "testing" team?

That is composed of everyone who uses Debian and especially those who
decide to report an issue they found.


that does test setups of Debian ISOs on a bunch of different hardware with 
priority on the most used CPUs like amd64 and i386, (free and non-free 
versions)),

The Debian CD team do installation testing of each new Debian release
and each new Debian point release. They don't do things like download
RSS feeds or try to use less/vi in the installer though, they just
follow the installer prompts.

https://wiki.debian.org/Teams/DebianCD/ReleaseTesting


1) ask the user if everything works fine (rating from 1 to 5 stars)

and user can add a comment ( send some praise or comments what does/did not 
work )

I don't think that Debian has enough people to monitor these, we have
enough bug reports and mailing list/forum posts to keep up with as it
is.


2) scan the hardware specs of the system

There is a shared cross-distro hardware database:

https://wiki.debian.org/Hardware/Database
https://linux-hardware.org/
https://bsd-hardware.org/

Unfortunately the script used to upload to the database, called
hw-probe, isn't yet integrated into the Debian installer nor the
Debian live installer (calamares).

https://bugs.debian.org/964853
https://github.com/calamares/calamares/issues/1454


anonymized! without any serials and mac addresses or ip addresses or screen 
resolutions!, before uploading it to debian.org/hardware-compatibility-list

The above hardware database uses truncated salted hashes of some
hardware identifiers, in order to aggregate repeat uploads of hardware
probes of the same computer.

https://wiki.debian.org/PrivacyIssues#Data_sharing
https://github.com/linuxhw/hw-probe#privacy


where the hardware is marked in green (works) orange (can be made to work with 
this (link) workaround) or red (fails, no fix available currently)

There isn't any way to automatically check if hardware works, you
would need the user to check each item of hardware, make sure they did
the check correctly and only then report it working correctly. We
could create a Debian Live distro for hardware
testing/compatibility/reporting/certification, but no-one has done
that yet, although there was an idea and discussion at DebConf to do
something similar some years ago.

http://wiki.debian.org/Hardware/Certification

There is a corner of our wiki where Debian users can report their
experience with installing Debian, as well as the option to file
installation reports, which feed back to the installer team.

https://wiki.debian.org/InstallingDebianOn


--

mit freundlichem Gruß / best regards

https://www.dwaves.de  - enact the web
connect the people

Bug#993488: maybe reason for wontfix?

[Tomas Pospisek]

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993488#16 contains a 
"wontfix + close" but no rationale. Which leaves the original reporter 
with a large "?" I guess.


I am guessing that the reason for the "wontfix" is "that's just how Unix 
works unfortunately" aka "that's a Unix design bug"? Is my guess correct?


One other question - any idea on a way forward here? I would guess that 
behaviour (changing group membership won't change group membership of 
running processes) is rooted somewhere quite low in the stack, maybe in 
the kernel itself (or in posix :-#)? So if the original reporter would 
want to go ahead and look to that problem beeing fixed would he need to go 
talk to the kernel mailing list or do you have idea where he could go 
to?

*t

Re: Package name misspelled in binNMU changelogs

[Tomas Pospisek]

On 25.08.21 15:23, Andrey Rahmatullin wrote:
> On Wed, Aug 25, 2021 at 09:19:34AM -0400, The Wanderer wrote:
>> Is there any reasonable way to get this spelling error corrected in the
>> changelogs across all these packages?
> As those are specifically binNMU changelogs, I don't think so.

You still can do a NMU or send a patch to the maintainer...

>> Or is this too minor to be worth bothering with, and something that
>> should be just left to lie as it stands?
> Definitely yes and yes.
That's in the eye of the beholder I'd say. I'd rather have package 
spellings cleaned up.


*t

Re: inconsistent mailgraph settings

[Tomas Pospisek]

On 23.08.21 07:24, Tomas Pospisek wrote:

On 23.08.21 02:35, Vincent Lefevre wrote:

On 2021-08-21 10:36:04 +0200, Tomas Pospisek wrote:
In particular it *seems* to work for him and he doesn't have access 
to your
system where things apparently went wrong so it could be really hard 
for him
to know. So what you can do is to try to debug *yourself* why the 
upgrade
went wrong and come forth with some analysis that shows to root cause 
of the
breakage. And then you can also propose a fix. I am sure that would 
make it

a lot easier for the maintainer to do "the right thing".


Unfortunately, that's too late, because the issue (at least one part
of it) occurred during the upgrade, and unfortunately, I can't install
the previous version (due to unsatisfied dependencies) to try to
reproduce the bug.


While mailgraph was started on boot in the past, this stopped
working with the upgrade to Debian 10, and I had to enable it
again. So issues with the upgrade to Debian 11, but the mailgraph
package has not changed. And who knows what will happend with
the next upgrade...

I can see in the debian/default.conf file:

# Should Mailgraph start on boot (true|false) (default: true)
BOOT_START="true"

So I don't understand what is the intent for the default settings.
To run it on boot or not???


Evidently the package is offering a choice on whether to start or not to
start mailgraph on boot. By virtue of that option existing it seems 
that not

everybody wants mailgraph to be started on boot.


Yes, but this option was honored in the previous version and
is no longer honored (note that there wasn't an announce of
any change).


Note that I was already using systemd in Debian 9, so that it is
not normal that mailgraph stopped working after the upgrade to
Debian 10.


Don't be all up in arms about the problem. Try to find out why it's 
broken

and try to propose a fix and to work with the maintainer.


I no longer have any Debian 9 machine.


     # apt-get install docker
     # docker pull debian:buster
     # docker run -ti debian:bullseye bash
     root@e6cbe6c64846:/# apt-get update && apt-get install mailgraph


Sorry, correction:

  # apt-get install docker
  # docker pull debian:stretch
  # docker run -ti debian:stretch bash
  root@e6cbe6c64846:/# apt-get update && apt-get install mailgraph
  root@e6cbe6c64846:/# sed --in-place 's/stretch/buster/' 
/etc/apt/source.list

  root@e6cbe6c64846:/# apt-get update && apt-get dist-upgrade

Rebooting that docker container will throw away the changes I guess so 
you'll need to put the commands above that you'd execute inside the 
container in a Dockerfile:


$ cat Dockerfile
FROM debian:stretch
RUN  apt-get update && apt-get install mailgraph
RUN sed --in-place 's/stretch/buster/' /etc/apt/source.list
RUN apt-get update && apt-get dist-upgrade

and create a new, dist-upgraded container:

$ docker build -t debian:stretch2buster Dockerfile
$ docker run -ti debian:stretch2buster bash

?
*t

Re: inconsistent mailgraph settings

[Tomas Pospisek]

On 23.08.21 02:35, Vincent Lefevre wrote:

On 2021-08-21 10:36:04 +0200, Tomas Pospisek wrote:

In particular it *seems* to work for him and he doesn't have access to your
system where things apparently went wrong so it could be really hard for him
to know. So what you can do is to try to debug *yourself* why the upgrade
went wrong and come forth with some analysis that shows to root cause of the
breakage. And then you can also propose a fix. I am sure that would make it
a lot easier for the maintainer to do "the right thing".


Unfortunately, that's too late, because the issue (at least one part
of it) occurred during the upgrade, and unfortunately, I can't install
the previous version (due to unsatisfied dependencies) to try to
reproduce the bug.


While mailgraph was started on boot in the past, this stopped
working with the upgrade to Debian 10, and I had to enable it
again. So issues with the upgrade to Debian 11, but the mailgraph
package has not changed. And who knows what will happend with
the next upgrade...

I can see in the debian/default.conf file:

# Should Mailgraph start on boot (true|false) (default: true)
BOOT_START="true"

So I don't understand what is the intent for the default settings.
To run it on boot or not???


Evidently the package is offering a choice on whether to start or not to
start mailgraph on boot. By virtue of that option existing it seems that not
everybody wants mailgraph to be started on boot.


Yes, but this option was honored in the previous version and
is no longer honored (note that there wasn't an announce of
any change).


Note that I was already using systemd in Debian 9, so that it is
not normal that mailgraph stopped working after the upgrade to
Debian 10.


Don't be all up in arms about the problem. Try to find out why it's broken
and try to propose a fix and to work with the maintainer.


I no longer have any Debian 9 machine.


# apt-get install docker
# docker pull debian:buster
# docker run -ti debian:bullseye bash
root@e6cbe6c64846:/# apt-get update && apt-get install mailgraph

?
*t

Re: BTS not archiving Bcc: mails? [was: Re: inconsistent mailgraph settings]

[Tomas Pospisek]

On 23.08.21 02:21, Vincent Lefevre wrote:

On 2021-08-22 23:32:15 +0500, Andrey Rahmatullin wrote:

On Sun, Aug 22, 2021 at 08:25:41PM +0200, Tomas Pospisek wrote:

Wouldn't the Bcc'ed email that arrived to the BTS be visible in the bug's
log/archive (on the bug's page (https://bugs.debian.org/989734))?

It's visible: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989734;msg=27


Where? I don't see any "close" or "done".

Note that the "Done:" in the metadata at the top just reflects the
*current* status of the bug; it is currently also present at

   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989734;msg=5

where the bug was obviously open.


The thing is, if you close a bug report via `Bcc: 
-cl...@bugs.debian.org` then the mail that arrives at the 
BTS does *not* have the -cl...@bugs.debian.org address in 
the email header but only in the mail envelope - that is, when 
connecting the sending MTA will tell the BTS MTA "RCPT TO: 
-cl...@bugs.debian.org"
and that's it. This will close the bug, but the address 
-cl...@bugs.debian.org will not be visible in the email 
that's archived...


Not sure why people are using `Bcc: -cl...@bugs.debian.org` 
in the first place. To hide that -cl...@bugs.debian.org 
address from spammers? But then all the other addresses are visible...?

:-/
*t

Re: merged /usr vs. symlink farms

[Tomas Pospisek]

On 22.08.21 00:11, Guillem Jover wrote:


I'm personally just not seeing such consensus, despite the attempts of
some to make it pass as so. My perception is that this topic has become
such a black hole of despair, that people that take issue with it, are
simply stepping away.


Possibly. But for me as one datapoint of N the amount and level of 
tricky technical detail is way beyond me, so I am standing on the 
sideline and watching the discussion and leaving the arguments to the 
experts. And I do not really care which solution will be chosen. I hope 
it will be one that doesn't break my system(s) too hard so I'll be able 
to ask a search engine and follow the hints and instructions.


Wrt not caring much about which solution will be chosen: Debian has now 
passed through transitions where people were extremely (emotionally) 
involved. I wasn't consistently on the winning side: my preference would 
have been to keep it simple and to be able to fire up `vim` to debug 
some aspect of the boot system or services failing to start, but here we 
are, we've got systemd instead. So I had to adapt, to learn new stuff 
and the world did not end in fact I am OK with it.


Could be that I am that single one DD with this perspective, or maybe not.

In the end I think Debian is a do-o-cracy: we can decide whatever we 
want via TC or GR but unless there's someone willing to do the work all 
decisions won't matter. So it is my hope - in fact my conviction - that 
whoever does the work for the merged /usr will find a solution that 
won't trash my system(s) too badly and I'll find a way to fix'em. And if 
the scratch will itch too badly I might eventually even file a patch 
that will give others relief as well.


From this same perspective:


Exhausted,
Guillem


seeing you exhausted is sad. You do not need to carry the weight 
of this problem, of dpkg or of Debian. I believe Debian *will* find a 
way. Some way. Debian *does* have many capable and interested people. 
*Do* take care of yourself. Do make sure that working on dpkg is still 
enjoyable for you or whatever your motivation is. There's strictly no 
need you burning yourself out on this. You *can* take a step back an 
deinvest *yourself* from this. It is a technical and maybe a social 
problem but it is *not* *your* problem unless you let it be so.


Huge respect and thanks for all your work this far!
*t

BTS not archiving Bcc: mails? [was: Re: inconsistent mailgraph settings]

[Tomas Pospisek]

Hi Mattia,

On 21.08.21 12:06, Mattia Rizzolo wrote:

On Sat, Aug 21, 2021 at 10:36:04AM +0200, Tomas Pospisek wrote:

Hi Vincent,

On 20.08.21 16:50, Vincent Lefevre wrote:

My bug report https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989734
has been closed again, with no explanations.


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989734;msg=12 claims that
the bug was closed via
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989734;msg=10 . However I
can't see why the latter mentioned message would close the bugreport. Can
anybody shed some light on this?


Likely Jörg Frings-Fürst BCCed the -close@ address.  There are some
people who do that…


Wouldn't the Bcc'ed email that arrived to the BTS be visible in the 
bug's log/archive (on the bug's page (https://bugs.debian.org/989734))? 
Or will BTS filter out Bcc emails?


Why would the BTS behave in such a way or even allow that? ?8-o ?

Stumped,
*t

Re: inconsistent mailgraph settings

[Tomas Pospisek]

Hi Vincent,

On 20.08.21 16:50, Vincent Lefevre wrote:

My bug report https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989734
has been closed again, with no explanations.


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989734;msg=12 claims 
that the bug was closed via 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989734;msg=10 . 
However I can't see why the latter mentioned message would close the 
bugreport. Can anybody shed some light on this?


Either way: try to stay calm, try keeping a *cooperative* conversation 
with the maintainer. Your argument being right or not right won't 
guarantee you that you'll have your way. You need to work with the 
maintainer to get your issue resolved in a way that's acceptable for 
both of you. So try not to escalate things, try to keep your urges in check.


I can't see the maintainer refusing to work with you: it just seems that 
it is unclear why mailgraph wouldn't start automatically after the 
upgrade. Remember that the maintainer doesn't own anything to you. He 
doesn't *have* to fix anything.


In particular it *seems* to work for him and he doesn't have access to 
your system where things apparently went wrong so it could be really 
hard for him to know. So what you can do is to try to debug *yourself* 
why the upgrade went wrong and come forth with some analysis that shows 
to root cause of the breakage. And then you can also propose a fix. I am 
sure that would make it a lot easier for the maintainer to do "the right 
thing".



While mailgraph was started on boot in the past, this stopped
working with the upgrade to Debian 10, and I had to enable it
again. So issues with the upgrade to Debian 11, but the mailgraph
package has not changed. And who knows what will happend with
the next upgrade...

I can see in the debian/default.conf file:

# Should Mailgraph start on boot (true|false) (default: true)
BOOT_START="true"

So I don't understand what is the intent for the default settings.
To run it on boot or not???


Evidently the package is offering a choice on whether to start or not to 
start mailgraph on boot. By virtue of that option existing it seems that 
not everybody wants mailgraph to be started on boot.



Note that I was already using systemd in Debian 9, so that it is
not normal that mailgraph stopped working after the upgrade to
Debian 10.


Don't be all up in arms about the problem. Try to find out why it's 
broken and try to propose a fix and to work with the maintainer.


Note that not only you might get frustrated but the maintainer might too 
in which case he might decide to give up on the package and then you'll 
be left with less than when you started. So try to keep the conversation 
friendly, supportive and cooperative.


All the best!
*t

Re: Q: Use https for {deb,security}.debian.org by default

[Tomas Pospisek]

On 21.08.21 09:14, Philipp Kern wrote:

On 20.08.21 21:11, Russ Allbery wrote:

The way I would put it is that the security benefit of using TLS for apt
updates is primarily that it makes certain classes of attempts to mess
with the update channel more noisy and more likely to produce immediate
errors.
One thing of note is that it introduces a time dependency on the client. 
Now we seem to gravitate towards a world where you'd also fail DNS 
resolution if your time is wrong (because you cannot get at the 
DNS-over-TLS/HTTPS server), so this is probably accepted as not making 
things worse overall. I guess we could have some (somewhat insecure) 
defense in depth if we wanted to, but maybe the world just agreed that 
you need to get your clock roughly correct. ;-)


I remember seeing apt-get refusing to update packages or the index 
because of them "having timestamps in the future" or in other words 
system time being out of sync in direction of the past.


So we already have the situation that system time **must not** be off 
into the past by some delta in order to be able to do updates **at all**.


This is out of my memory so if anybody cares about this argument it 
should maybe be confirmed more thoroughly.

*t

Re: debhelper upstream should correct the perl from "use v5.24;" into "use v5.28;".

[Tomas Pospisek]

Hi Sérgio,

On 27.05.21 13:14, Sérgio Basto wrote:

On Wed, 2021-05-26 at 20:05 +0100, Sérgio Basto wrote:

Hi,
debhelper-devel ML doesn't exist anymore, please let me know if I
should report this in other place .

I can't build debhelper on Centos epel 8, which have Perl 5.26.3



I forgot to mention from changelog of debhelper-13.1 "Dh_Lib.pm:
Require perl v5.24 (available in Debian oldstable) to enable more
modern features. "
But seems this is not correct, it needs Perl 5.28.0


fedpkg clone debhelper
cd debhelper
fedpkg srpm && mock -r epel-8-x86_64  --no-clean --rebuild debhelper-
13.3.4-1.fc35.src.rpm

and in epel8 build ends with
"Initialization of state variables in list context currently forbidden
at /builddir/build/BUILD/debhelper-
13.3.4/lib/Debian/Debhelper/Dh_Lib.pm line 2021, near");" "

Petr wrote :
perl has a "splain" tool which explains the compiler errors and
warnings:

$ splain
/usr/bin/splain: Reading from STDIN
Initialization of state variables in list context currently forbidden
at /home/test/fedora/debhelper/debhelper-
13.3.4/lib/Debian/Debhelper/Dh_Lib.pm line 2021, near ");"
Initialization of state variables in list context currently forbidden
at
     /home/test/fedora/debhelper/debhelper-
13.3.4/lib/Debian/Debhelper/Dh_Lib.pm line 2021, near ");" (#1)
     (F) state only permits initializing a single scalar variable, in
scalar
     context.  So state $a = 42 is allowed, but not state ($a) = 42.  To
apply
     state semantics to a hash or array, store a hash or array reference
in a
     scalar variable.

What do we have at the line 2021?:

     state %rrr = map { $_ => 1 } split(' ', $rrr_env);

That's it. perl 5.26.3 does not support "state" declaration for hashes
(%err).
Here is a one-line reproducer:

$ perl -e 'use v5.24; sub foo {state %rrr = map { $_ => 1 } split(q{ },
q{});}'
Initialization of state variables in list context currently forbidden
at -e line 1, near ");"
Execution of -e aborted due to compilation errors.

Which can be reduced to:

$ perl -e 'use v5.24; state %rrr = ();'
Initialization of state variables in list context currently forbidden
at -e line 1, near ");"
Execution of -e aborted due to compilation errors.

Please note that the "use v5.24;" statement is taken from debhelper
code.
It's obviously an upstream bug. The code is not valid syntax for perl
5.24.

The state support for non-scalar types was implemented in Perl 5.28.0
(see
"perldoc perl5280delta" command output):

   Initialisation of aggregate state variables
     A persistent lexical array or hash variable can now be initialized,
by
     an expression such as "state @a = qw(x y z)". Initialization of a
list
     of persistent lexical variables is still not possible.

You should reach out debhelper upstream to correct the "use v5.24;"
into "use
v5.28;". Or you can ask them to refactor the code to support perl 5.26.


since - as it seems - you haven't received any feedback from the 
debhelper developers/maintainers here on list, I suggest you use 
Debian's bugtracker to report this problem.


You can find instructions on how to use the bugtracker here:

https://www.debian.org/Bugs/Reporting.en.html

If you submit the bug by email then please set the pseudo-headers:

Package: debhelper
Version: the version of debhelper you found the bug in

I'm not a debhelper maintainer/developer, but if you encounter problems 
with the bug submission above, then please come back and ask on the list 
and I (or maybe someone else) will try to help.


Thanks,
*t

Re: Request for Pricing

[Tomas Pospisek]

On 07.05.21 17:29, Gunnar Wolf wrote:

Hello Tony,

I don't know where you got this mail address as a source for providing
the goods you need, but it's not correct -- Debian is a volunteer
organization that produces a distribution of the free "Linux"
operating system. We cannot provide what you require.

Andrej Shadura dijo [Fri, May 07, 2021 at 03:59:56PM +0200]:

I would like to get pricing on the following:

525 meters x 2.0m High

Qty : 350 pieces


I can sell you 350 pieces of 525 metres of Debian each for €1234567,- total.

Plz send moneys.


Hi Andrej,

Please don't answer like this to messages that arribe wrongly to
Debian mailing lists. It makes a bad, childish image to the project.

... And also, we don't want to create the reinforcement that, once
upon a time, led Debian to become wrongly associated with sheet music
for the "Dueling Banjos":

 http://pigeonsnest.co.uk/stuff/debian-dueling-banjos.html


Please don't take it that seriously Gunnar. Andrej made me laugh, which 
I'm thankful for. I doubt Tony will end up poor anytime soon for having 
paid the horrendous sum of 350*€1234567 to Andrej or be mislead or very 
sad over Andrej's joke... :-)


And I think the Dueling Banjos were kind of a weird and funny practical 
joke too...


Best greetings,
*t

Re: Expectation of constructive interaction

[Tomas Pospisek]

On 10.04.21 19:39, Joerg Jaspert wrote:

Dear fellow Debian community members,

We have been having two weeks of difficult and heated discussion. The 
level of conflict has escalated out of proportion, both within the 
project and outside.
We remind everyone that you are expected to interact constructively with 
our community. That goes not only for Debian Members, but also everybody 
who uses our mailing lists and other infrastructure.


This is true especially at a time when some in our community have 
received threats and others are expecting them, just because they took 
part in discussions or voted as our constitution allows them to.


This is entirely unacceptable.

We remind you that if you repeatedly send messages which raise the level 
of conflict; if you often behave confrontationally towards people; if 
you tend to disregard cries for help or requests to take a step back: 
you are not meeting our community standards.


We expect people not to justify themselves using the bad behaviour of 
others. As long as you use the unacceptable behaviour of others to 
justify your own unacceptable behaviour, you are not meeting our 
community standards.


Consider this a general warning to everyone / all sides. Different 
opinions are normal, and we have ways to resolve conflicts. But some of 
the behaviour we have witnessed recently is not, ever, tolerable.


Please think about the message you're about to send and whether it 
genuinely furthers discussion or simply antagonises others. For help, do 
reach out to your close circle of friends, and the Community Team.


Joerg, Enrico, Jonathan - thanks a lot for this! +1

Re: IBus emoji glitch

[Tomas Pospisek]

Hi Devops PK Carlisle LLC,

please install the `reportbug` package and then open a terminal and type 
`reportbug ibus` and describe the problem there. That will make sure the 
problem can be seen and properly tracked by the `ibus` maintainers which 
might not be reading this list.

*t

On 20.01.21 18:04, Devops PK Carlisle LLC wrote:



This is seen with

Debian GNU/Linux 10 (buster)
IBus 1.5.19


When you select the emoji function, it comes up as expected, can select
an emoji as expected from the graphical window...but...

When I mouse over a given emoji (call it Smiley 1) Smiley 1 may have
three lines of technical or category data which appears at the top of
the window, above the graphical emoji set. Smiley 2, right next to
Smiley 1 may have four lines of technical or category data, Smiley 3 may
have three lines of technical or category data, etc.

Because these lines of technical or category data are *above* the
emojis, *and* the entire window literally shrinks or expands, that is,
resizes, to accommodate the number of lines of technical or category
data, the entire emoji window literally shifts up or down a line
depending on how many lines of technical or category data that emoji has.

So, as I navigate with a mouse from Smiley 1 to Smiley 2 to Smiley 3,
the window is literally resizing on the fly (and the entire block of
emojis shifts up or down), making it difficult if not impossible to use
the mouse to select some emojis.

In the best world either the technical and category data would be
underneath the graphical emoji block OR the number of lines of technical
or category data would be static so the graphical emoji block did not
resize and shift up or down as the user rolls from one emoji to the next.

Re: Package dependency versions and consistency

[Tomas Pospisek]

On 19.12.20 01:25, Josh Triplett wrote:

Jonas Smedegaard wrote:

Quoting Raphael Hertzog (2020-12-17 13:16:14)

Even if you package everything, you will never ever have the right
combination of version of the various packages.


What is possible to auto-compute is a coarse view of the work needed.

In reality, most Nodejs modules declare too tight versioning for their
dependencies, and in many cases it is adequate that a module is packaged
even if not at the version declared as required.  A concrete example is
"ansi-styles" which is most likely working just fine in version 4.x.


This is not at all as simple as it sounds, even on a small scale, let
alone when multiplied by a few hundred dependencies.

(Let's please not go on the standard tangent into complaints about
the number of dependencies, because at the end of that tangent, people
will still use fine-grained packages and dependencies per the standard
best-practices of those communities, no matter the number or content of
mails in this thread suggesting otherwise. The extremes of "package for
a one-line function" are not the primary issue here; not every
fine-grained dependency is that small, and the issues raised in this
mail still apply whether you have 200 dependencies or 600. So let's take
it as a given that packages *will* have hundreds of library
dependencies, and try to make that more feasible.)

Figuring out whether those dependencies are actually too specific or if
they're required is a substantial amount of work by itself; the
packaging metadata and dependency versions recorded upstream exist to
declare the required version of dependencies, and there isn't typically
a *second* way that upstream records "no, really, there's a reason for
this dependency version requirement". This is hard enough in a
statically typed language, where you can at least have the verification
of seeing if it compiles with the older version (though the package
might be relying on new semantics); with a dynamically typed language,
you might not know that the older version of the dependency has caused a
problem until runtime. As an upstream developer, the safest assumption
when preparing your own dependencies is "well, it works with the version
of the dependency I tested with, and assuming that component correctly
follows semver, it should work with newer semver-compatible versions".

To clarify something: I *don't* believe Debian should compromise on
network access at build time. Debian package dependencies should be
completely self-contained within the Debian archive. The aspect I'm
concerned about here is that Debian pushes hard to force every single
package to use *the same version* of a given dependency, even if the
dependency has multiple incompatible versions (properly declared with
different semver major numbers, equivalent to libraries with different
SONAMEs). I'm not suggesting there should be 50 versions of a given
library in the archive, but allowing 2-4 versions would greatly simplify
packaging, and would allow such unification efforts to take place
incrementally, via transitions *in the archive* and *in collaboration
with upstream*, rather than *all at once before a new package can be
uploaded*.

(I also *completely* understand pushing back on having 2-4 versions of
something like OpenSSL; that'd be a huge maintenance and security
burden. That doesn't mean we couldn't have 2-4 semver-major versions of
a library to emit ANSI color codes, and handle reducing that number via
incremental porting in the archive rather than via prohibition in
advance.)

I think much of our resistance to allowing 2-4 distinct semver-major
versions of a given library comes down to ELF shared libraries making it
painful to have two versions of a library with distinct SONAMEs loaded
at once, and while that can be worked around with symbol versioning,
we've collectively experienced enough pain in such cases that we're
hesitant to encourage it. Our policies have done a fair bit to mitigate
that pain. But much of that pain is specific to ELF shared libraries and
similar. And some of our packaging limitations are built around this
(e.g. "one version of a given package at a time"), which in turn forces
some of those same limitations onto ecosystems that don't share the
problems that motivated those limitations in the first place. The
dependency and library mechanisms of some other ecosystems, are designed
to support having multiple distinct versions of libraries in the same
address space, with fully automatic equivalents of symbol versioning.

In Debian packaging, this issue typically results in one of three
scenarios for every dependency (recursively):

- Trying to port the package to work with older versions of
   dependencies. This incurs all of the burden mentioned above for
   determining if the older dependency actually suffices. On top of that,
   this may involve actual porting of code to not rely on the
   functionality of newer versions, which is very much wasted effort
   

Re: Sample Small Organisation Server now has email

[Tomas Pospisek]

On 12.12.20 21:53, Jonas Smedegaard wrote:


It was good that you introduced your project here on the d-devel@ list,
but I suspect no all 2500 subscribers want to follow closely your
detailed progress going forward.


I'd prefer if the conversation stayed here. It's not like you are 
literaly spamflooding the mailing list. But the project is interesting 
enough and you are keeping it under the same thread/subject, so I (and 
many others) can ignore it if we want...


My 2 cents,
*t

Re: crypto policy for Debian?

[Tomas Pospisek]

On 11.12.20 10:08, Timo Aaltonen wrote:

I noticed that crypto-policies is packaged, but not really used 
anywhere. Would it be worthwhile to make it the official way to 
configure the system-wide crypto policy as it was implemented in Fedora 
[1]? This has been briefly mentioned before at least in bug 765512 [2], 
but nothing came out of it. I think it would benefit Debian if support 
for crypto-policies was added to packages, and make it a release goal 
for Bookworm. Or is it just a matter of JFDI and filing bugs & MR's 
against the affected packages?



[1] https://fedoraproject.org/wiki/Changes/CryptoPolicy
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765512


I think it's indeed just a matter of filing bugs & MR's.

On the topic of actually *having* a system wide crypto policy: 
(Attention: opinion/point of view coming...): from time to time I wish 
having a system wide crypto policy switch. Needing to get aquainted with 
nginx' way to configure SSL, then apache's, then postgres', then 
dovecot's, then ... is really senseless busywork. It'd be nice if Debian 
just kept on updating those automatically to latest best practice and 
I'd be done with it. But with that comes *additional* complexity. So now 
I have to *additionaly* learn the crypto-policy machine: what happens 
when crypto policies get updated? Will it automatically reload the 
daemons involved? Or even *restart* those that need it? What happens if 
I have a cluster, will the policy update break it (I had this happen 
regularily on a cluster on package updates)? How can I override system 
wide policies? What's the hierarchy of the chain of different crypto 
policy settings if they override or contradict each other etc.?


So I think:
- it's valuable to have a system wide crypto policy
- it's substantially increasing complexity with a yet unknown win
- this actually is a Debian wide policy change so ideally it *should* be 
discussed more widely than to creep it slowly in. However:
- optimally nothing will change for anybody if the crypto-policy package 
doesn't get installed (wishful thinking)
- ideally the involved people would know about Fedora's experience with 
that new infrastructure: did it break working systems (I have a feeling 
that Fedora is not a major server OS?)? Did the Fedora users love the 
new crypto-policy system? Did the Fedora users hate it? Does it get 
installed by default there?
- power to those that do things: just go ahead and we'll see what comes 
out and we can iterate to improve the system (wishful thinking + experience)


Thanks for taking the initiative Timo,
*t

Re: Bug#975111: ITP: webpackage -- WebPackage is a revolutionary way of distributing web apps.

[Tomas Pospisek]

On 20.11.20 14:41, Tomas Pospisek wrote:

(same as ITP 975110)

Does anybody know why recently there have been so many duplicate WNPP 
bugreports? It seems like a trend, however I have no clue why? Why have 
recently so many WNPP reports been submitted twice?


The submitter has followed up and told me the duplicate submitting was a 
mistake on his part.

*t


On 19.11.20 07:25, Witherking25 wrote:

Package: wnpp
Severity: wishlist
Owner: Witherking25 

* Package name    : webpackage
   Version : 1.5.2
   Upstream Author : Witherking25 
* URL : https://github.com/WebPackage/WebPackage
* License : GPL3
   Programming Lang: C++
   Description : WebPackage is a revolutionary way of distributing 
web apps.


WebPackage is a revolutionary new way of distributing web apps on any 
platform.
It works by packaging the web app in a .webpkg file, a special kind of 
zip file

designed for distributing web apps.

Re: Bug#975111: ITP: webpackage -- WebPackage is a revolutionary way of distributing web apps.

[Tomas Pospisek]

(same as ITP 975110)

Does anybody know why recently there have been so many duplicate WNPP 
bugreports? It seems like a trend, however I have no clue why? Why have 
recently so many WNPP reports been submitted twice?

*t

On 19.11.20 07:25, Witherking25 wrote:

Package: wnpp
Severity: wishlist
Owner: Witherking25 

* Package name: webpackage
   Version : 1.5.2
   Upstream Author : Witherking25 
* URL : https://github.com/WebPackage/WebPackage
* License : GPL3
   Programming Lang: C++
   Description : WebPackage is a revolutionary way of distributing web apps.

WebPackage is a revolutionary new way of distributing web apps on any platform.
It works by packaging the web app in a .webpkg file, a special kind of zip file
designed for distributing web apps.

Re: Split Packages files based on new section "buildlibs"

[Tomas Pospisek]

On 13.11.20 20:51, Wolfgang Silbermayr wrote:

[...detailed explanation of why the buildlibs proposal for Rust is 
necessary...]


Thanks a lot for the explanation Wolfgang!
*t

Re: Split Packages files based on new section "buildlibs"

[Tomas Pospisek]

Hi Antonio (and anybody else that understands the technical problem 
involved here),


I've been reading the whole thread and it seems to me that the reason, 
why Rust/Go build-time "libraries" need to be handled differently from 
all the other existing stuff in the world and that "no user ever wants 
to use" the Debian-provided build-time Rust/Go libraries has not been 
spelled out in plain, comprehensible english yet.


So since you seem to understand a bit about the technical problem 
involved here and I'd very much appreciate if you could spell it out. I 
think it would benefit the project as then everybody would be able to 
understand what this new section is about.


So let me ask a question that could maybe clear things up:

On 11.11.20 14:39, Antonio Terceiro wrote:


In the Rust world there is no such thing as installing a library
globably. A crate that provides a library can only be used to build
other stuff, and is never made available globally. "cargo install" only
applies to creates that provide binaries:

https://doc.rust-lang.org/cargo/commands/cargo-install.html


[I've read the cargo-install.html document in the past but not re-read 
it now]


So let's say user joe wants to code Go software that depends on Go's 
third party github.com/tazjin/kontemplate/templater package ("package" 
in Go's taxonomy not in Debian's!).


Then he'd `export GOPATH=~/src/go` and `go get 
github.com/tazjin/kontemplate`. Go would then `git clone` everything 
under  `~/src/go/src/github.com/tazjin/kontemplate/`.


So far so good and I think Rust has a similar mechanisms with cargo, right?

Now given that alice wants to package joe's software. She'll do the 
above plus `go get github.com/joe/joes_app`. All will be under 
`~/src/go/src/github`.


The naive thing to do now would be to move `~/src/go/src/` to 
`/usr/lib/go` and package that as `go-tazjin-kontemplate-dev_0.1.deb` or 
similar.


Debian's automatic build process for "joes_app" would first install 
`go-tazjin-kontemplate-dev_0.1.deb`, then make a symlink from 
`~/src/go/src/github.com/tazjin` (or `~/.local/go` or whereever Go 
expects its stuff by default) to `/usr/lib/go/src/github.com/tazjin` and 
build and be done.


A user wanting to develop software based on tazjin's stuff would do the 
same: `apt-get install go-tazjin-kontemplate-dev`, symlink, done.


This solution seems to be too trivial that nobody would have though of 
it, so what is it that I (and I guess many Debianers) are missing?

*t

Re: Lenovo and forced labor [was: Re: Lenovo discount portal update (and a few other things)]

[Tomas Pospisek]

On 03.09.20 11:05, Andrey Rahmatullin wrote:
> On Thu, Sep 03, 2020 at 10:47:06AM +0200, Tomas Pospisek wrote:
>> I think before jumping on this offer, one should consider this:
>> https://www.aspi.org.au/report/uyghurs-sale
> The list of brands from the article: Abercrombie & Fitch, Acer, Adidas,
> Alstom, Amazon, Apple, ASUS, BAIC Motor, BMW, Bombardier, Bosch, BYD,
> Calvin Klein, Candy, Carter’s, Cerruti 1881, Changan Automobile, Cisco,
> CRRC, Dell, Electrolux, Fila, Founder Group, GAC Group (automobiles), Gap,
> Geely Auto, General Motors, Google, Goertek, H, Haier, Hart Schaffner
> Marx, Hisense, Hitachi, HP, HTC, Huawei, iFlyTek, Jack & Jones, Jaguar,
> Japan Display Inc., L.L.Bean, Lacoste, Land Rover, Lenovo, LG, Li-Ning,
> Mayor, Meizu, Mercedes-Benz, MG, Microsoft, Mitsubishi, Mitsumi, Nike,
> Nintendo, Nokia, Oculus, Oppo, Panasonic, Polo Ralph Lauren, Puma, Roewe,
> SAIC Motor, Samsung, SGMW, Sharp, Siemens, Skechers, Sony, TDK, Tommy
> Hilfiger, Toshiba, Tsinghua Tongfang, Uniqlo, Victoria’s Secret, Vivo,
> Volkswagen, Xiaomi, Zara, Zegna, ZTE.
> 
> So it looks like this is not specific to Lenovo or laptops (just like the
> "I'm not sure there are alternatives" part).

A bit more (although not a lot more) info specific to Lenovo:

https://theintercept.com/2020/08/21/school-laptops-lenovo-chromebooks-china-uyghur/

Lenovo and forced labor [was: Re: Lenovo discount portal update (and a few other things)]

[Tomas Pospisek]

On 02.09.20 15:08, Mark Pearson wrote:
> Hi Debian developers,
> 
> Following on from DebConf 2020 (which I thoroughly enjoyed - thank you!)
> the Lenovo portal that was announced is now available:
> 
> US: http://www.lenovo.com/us/en/Linux
> Canada: http://www.lenovo.com/ca/en/linuxca

I think before jumping on this offer, one should consider this:
https://www.aspi.org.au/report/uyghurs-sale

Lenovo is by far not the only company producing laptops with forced
labor involved, however they have not - as of today - as far as I can
see - cared to comment on those report at all:

* they have neither denied nor ack'ed it
* and they haven't said either that they'd no longer use forced labor to
produce their wares

I'd conclude from that, that Lenovo still is, will be, and is not
planing to stop using forced labor to produce those laptops.

I'm not sure there are alternatives: I have not researched them
intensively yet - I am currently in need of a new laptop too, so I'll
have to look around whether there are other brands that do not rely on
companies that employ forced labor. Pointers welcome.
*t

Re: Accepted firefox-esr 68.10.0esr-1~deb9u1 (source) into oldstable-proposed-updates->oldstable-new, oldstable-proposed-updates

[Tomas Pospisek]

Could you please send the original email *including* the headers (!!!)
so that we know where your emails are coming from?
*t

On 06.08.20 17:31, arc...@tutanota.com wrote:
> Could I please unsubscribe? Its filling up this mailbox there is no sort
> function.
>
> --
> Securely sent with Tutanota. Get your own encrypted, ad-free mailbox:
> https://tutanota.com
>
>
> Jul 3, 2020, 13:17 by ftpmas...@ftp-master.debian.org:
>
> Format: 1.8
> Date: Wed, 01 Jul 2020 09:08:58 +0900
> Source: firefox-esr
> Architecture: source
> Version: 68.10.0esr-1~deb9u1
> Distribution: stretch-security
> Urgency: medium
> Maintainer: Maintainers of Mozilla-related packages
> 
> Changed-By: Mike Hommey 
> Changes:
> firefox-esr (68.10.0esr-1~deb9u1) stretch-security; urgency=medium
> .
> * New upstream release
> * Fixes for mfsa2020-25, also known as:
> CVE-2020-12417, CVE-2020-12418, CVE-2020-12419, CVE-2020-12420,
> CVE-2020-12421.
> Checksums-Sha1:
> eb3c8bbab7584b158d83edbb38a4a70d010c206d 43699
> firefox-esr_68.10.0esr-1~deb9u1.dsc
> 61fd39b5e1103dd21e2b5d4dbe40de0fcb7e9a8f 263962
> firefox-esr_68.10.0esr.orig-l10n-ach.tar.bz2
> bba754b7040b84be5ab7cc3c698ee5d5920ee184 282479
> firefox-esr_68.10.0esr.orig-l10n-af.tar.bz2
> ce6ae024cd7e27f55613d89a40f2bd54c2650588 638621
> firefox-esr_68.10.0esr.orig-l10n-an.tar.bz2
> 8fde1557fbb1238b6b14cb499ff1f8651a1f3303 450676
> firefox-esr_68.10.0esr.orig-l10n-ar.tar.bz2
> 2e26686dd54f72f2d9c27173841a4554d757ed2b 370612
> firefox-esr_68.10.0esr.orig-l10n-ast.tar.bz2
> 4181c45be6e47c4871b37ff25c9d6d46730b66f5 310106
> firefox-esr_68.10.0esr.orig-l10n-az.tar.bz2
> d56bbbc0ed52e24801e63c9875d251ee37a2df8a 791631
> firefox-esr_68.10.0esr.orig-l10n-be.tar.bz2
> fb6cafacc6ba7e646001910992bcacb0490e0741 1695539
> firefox-esr_68.10.0esr.orig-l10n-bg.tar.bz2
> b78c2d67dd032c5292dbf6f4632769eb90e55998 393646
> firefox-esr_68.10.0esr.orig-l10n-bn.tar.bz2
> 3d9bcf95759817b2115c29582534dcff628b62fa 1868689
> firefox-esr_68.10.0esr.orig-l10n-br.tar.bz2
> be44c561ef95f2f49672ae4c79c06c9a861e7e03 562171
> firefox-esr_68.10.0esr.orig-l10n-bs.tar.bz2
> 3028c43bc4130782073ee9e0b56402bcf8dee9b5 1295317
> firefox-esr_68.10.0esr.orig-l10n-ca.tar.bz2
> 65cb838eeda1a2cf763302ac93ce2eaea89104d6 457930
> firefox-esr_68.10.0esr.orig-l10n-cak.tar.bz2
> 28611986d6667ea8ca3bef524d4b91ece125f3a7 937672
> firefox-esr_68.10.0esr.orig-l10n-cs.tar.bz2
> 7003766196ee8e427cebe65b8bdb616f97a1c447 499004
> firefox-esr_68.10.0esr.orig-l10n-cy.tar.bz2
> 23ee835066981816e4edf989631fd092d3b18bd9 1139988
> firefox-esr_68.10.0esr.orig-l10n-da.tar.bz2
> 4124a9771c66129571bb6e061795781eb3c5e0bb 906081
> firefox-esr_68.10.0esr.orig-l10n-de.tar.bz2
> fe4393a5f799b16b2f45a09dea5d52aeace7f6db 505386
> firefox-esr_68.10.0esr.orig-l10n-dsb.tar.bz2
> 3b66c57b5a8261520a87c8d43d4765143624f23d 2320412
> firefox-esr_68.10.0esr.orig-l10n-el.tar.bz2
> e92f6ba037cd9dfd655fe4c6260bb0494bc56aa1 1069264
> firefox-esr_68.10.0esr.orig-l10n-en-CA.tar.bz2
> e8c6e4e580a30d7102957ed6f549503238e40210 850080
> firefox-esr_68.10.0esr.orig-l10n-en-GB.tar.bz2
> cb4e5b16b7b8c93f33b3b7d820a50b548230648f 475444
> firefox-esr_68.10.0esr.orig-l10n-eo.tar.bz2
> c8f176e8ebc32ad07079954ece9ef615e565dd44 857313
> firefox-esr_68.10.0esr.orig-l10n-es-AR.tar.bz2
> cb433b60446d0806cd866d87d082d355add75cf9 596060
> firefox-esr_68.10.0esr.orig-l10n-es-CL.tar.bz2
> c3fca8dbd8d3727acc06f4c4d84a41b9ae33af79 837078
> firefox-esr_68.10.0esr.orig-l10n-es-ES.tar.bz2
> af88a1d9fbafc7670c87058465b10b8dd06a8c30 752375
> firefox-esr_68.10.0esr.orig-l10n-es-MX.tar.bz2
> 9031f402b7e8733ed38e580574d9af4257bcaad4 1360355
> firefox-esr_68.10.0esr.orig-l10n-et.tar.bz2
> 28ca3b4070fe4552bf56d5dbb6d9660bcfd6dc8f 491515
> firefox-esr_68.10.0esr.orig-l10n-eu.tar.bz2
> 71cc0fed8af8313a85c86c78c57a2e04d859244e 392873
> firefox-esr_68.10.0esr.orig-l10n-fa.tar.bz2
> 3d04d0687d721424c9977e77c02d0602fbff6d90 285947
> firefox-esr_68.10.0esr.orig-l10n-ff.tar.bz2
> 1c93f97426401dc8f7484a9b2cfb9f5c2b179d5b 847166
> firefox-esr_68.10.0esr.orig-l10n-fi.tar.bz2
> b747ac4921c158238b342a89a559f1f21f40939e 1337802
> firefox-esr_68.10.0esr.orig-l10n-fr.tar.bz2
> 524c39aeaa1f3ecff0c424a2d00293a005ade135 2558296
> firefox-esr_68.10.0esr.orig-l10n-fy-NL.tar.bz2
> 109a650caed4a1c9b90452a26df7b838f5cea905 436057
> firefox-esr_68.10.0esr.orig-l10n-ga-IE.tar.bz2
> fec14e1a69bebc5f5ffd1cf9d6b0f1dfeada4c6e 503870
> firefox-esr_68.10.0esr.orig-l10n-gd.tar.bz2
> cd793ccf677266e5f51ac92e2186c0fc1656cf4d 772710
> firefox-esr_68.10.0esr.orig-l10n-gl.tar.bz2
> dd5796473a0233f6fc33f5bceafed62e3d1146ce 308789
> firefox-esr_68.10.0esr.orig-l10n-gn.tar.bz2
> 98b2636780019f2561b02a778bcc714871806b2a 383263
> firefox-esr_68.10.0esr.orig-l10n-gu-IN.tar.bz2
> 90e1b69ad24282d3ced9bf7510b6094050b1ab38 442754
> firefox-esr_68.10.0esr.orig-l10n-he.tar.bz2
> 6ab4da0f188ffd578509ac84149fa8fb277b305e 389699
> firefox-esr_68.10.0esr.orig-l10n-hi-IN.tar.bz2
> ad1461e3a87d3d712a92b1d3162c9d19b91aa6cf 468508
> 

Bug#967029: take the bug to irc/support channel?

[Tomas Pospisek]

Hello bebyx,

could you please take this bug to a Debian support channel [1] (I 
suggest IRC!) and find out, what package this needs to be reassigned 
to? And maybe collect more info along the way?


Thanks,
*t

[1] https://www.debian.org/support

Bug#962579: RFH: debtags -- Debian Package Tags support tools

[Tomas Pospisek]

Package: wnpp
Severity: normal

I request assistance with maintaining the debtags package.

The package description is:
 debtags extracts tag information from the apt database and makes it available
 to the system, either in /var/lib/debtags/debtags or via apt-xapian-index.
 .
 Package tags are categories for Debian packages.
 .
 debtags also provides some handy command to query tag information.

After discussing with Enrico Zini on IRC is seems to be evident that
the [debtags package](https://bugs.debian.org/debtags),
the [debtags web site](https://debtags.debian.org) and
the [debtags tag DB](https://salsa.debian.org/debtags-team/debtags-tagdb)
need help.

>From IRC:

```
 Maybe you want to give other people commit access to the
   detabgs-tagsdb project? A lot of categorization/tag
   assignment merges should be only busy-work, so
   potentially a lot of people can take care of that instead
   of you personally?
 tpo2: currently the tagdb project is fed by the site,
 I'm not sure what happens with the site if changes start
 appearing on it that the site doesn't know
 tpo2: I'd be very happy to give other people commit
 access to the site.
```

Re: Running autopkgtest on porter boxes: dd-autopkgtest

[Tomas Pospisek]

On 31.05.20 22:40, Michael Banck wrote:

> it's possible for DDs to build/test packages on porter boxes via
> dd-schroot-cmd, see https://dsa.debian.org/doc/schroot/.
> 
> However, e.g. arm64 autopkgtest failures are RC bugs and so far, it was
> difficult to reproduce and debug those on the porter boxes, at least I
> was not aware of an easy way to run autopkgtest on those.
> 
> During the Online MiniDebConf today I hacked a bit around, and (with
> some help from Antonio Terceiro) came up with the following
> proof-of-concept script:
> https://salsa.debian.org/mbanck/dd-autopkgtest/-/blob/master/dd-autopkgtest
> 
> You can run this with a source package name on one of the porter boxes,
> like: 
> 
> ./dd-autopkgtest foo
> 
> It will then (i) create a working directory with the name of the source
> package, (ii) bootstrap a schroot, (iii) install autopkgtest, the test
> dependencies and the binaries in the schroot and (iv) run autopkgtest.
> It will drop you in a shell if autopkgtest fails.
> 
> The primary limitation is that you can only test binary packages that
> are in unstable already, because dd-schroot-cmd does not allow to
> install local packages. I have not extended the script for other
> distributions than unstable, but that should be possible.
> 
> Bugs, merge requests, suggestions and comments welcome!

It'd be good if this was documented in a "canonical place" besides a few
levels deep in a Salsa repo and in a mail to dd.
*t

Re: Upload of package (Closes: #952788) in bug reports

[Tomas Pospisek]

On 28.05.20 18:44, Leandro Cunha wrote:
> Close https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952788 
> With several changes in the package.
> 
> Em qui., 28 de mai. de 2020 às 12:52, Leandro Cunha
> mailto:leandrocunha...@gmail.com>> escreveu:
> 
> Can I help with uploading a package? I'm starting now with packaging
> and everything went well. It just needs a review and have a maintainer.

I think your best option is to coordinate directly with the package
maintainer, Andrej Shadura . Write to him. He's
active but maybe busy so you might want to be patient in communications
with him.
*t

Re: Packaging devel-only C++ library

[Tomas Pospisek]

On 27.05.20 21:16, Enrico Zini wrote:
> Hello,
> 
> I'd like to package a new version of https://github.com/ARPA-SIMC/meteosatlib,
> for which I'm upstram, which depends on the recently freed
> https://gitlab.eumetsat.int/open-source/PublicDecompWT
> 
> PublicDecompWT is a C++ development-only library released by Eumetsat,
> with functions needed to decompress MeteoSat images. Historically it has
> had a relatively stable API, but no guarantees are made about an ABI as
> far as I know, and to make matters worse ABI-wise, it's C++.
> 
> These options come to my mind:
> 
>  - use git submodules and pull PublicDecompWT into meteosatlib, in a way
>slightly more convenient to the current instructions of obtaining the
>zipfile from eumetsat and putting it there
>  - package PublicDecompWT as a devel-only library in Debian, and
>build-depend on it for meteosatlib.
> 
> Suggestions? Other ideas? Special things to keep in mind in cases like
> this (Built-Using?) ?

I'm not sure why you wouldn't want to package it as a separate library,
apart from maybe this being more work. I think it doesn't hurt Debian to
have one more package. OTOH clean modularization usually has very strong
benefits, which would be an argument for packaging it separately.

My 2 cents,
*t

Re: Salsa update: no more "-guest" and more

[Tomas Pospisek]

On 30.04.20 01:15, Bernd Zeimetz wrote:
> 
> On 4/28/20 3:20 PM, Thomas Goirand wrote:
> 
>> That's not the case. An MITM attack could gain a session and maintain it
>> open, while the end user would just notice "oh shit, I miss-typed the
>> 2FA numbers, let's try again". Then the only thing the attacker needs to
>> do is keep the session open to not loose access...
> 
> I hope you realize that no session is open forever.

Just for giggles: [longest TCP
connection](https://ask.slashdot.org/comments.pl?sid=1462=1673396)

Re: What to do when DD considers policy to be optional? [kubernetes]

[Tomas Pospisek]

On 09.04.20 08:47, Thomas Goirand wrote:

> As a user, I'd prefer Kubernets to be in Stable if possible. I'd be one
> of these users who don't care about the latest shiny feature, and prefer
> something stable, supported for YEARS to come, not just 3 months.

To give a datapoint:

Kubernetes as a Service offerings on the market are often already one,
two or three major releases behind. Which IMHO serves as a useful
datapoint of the "needs of the users"...

Once you have a cluster running, there is very little incentive to take
it down (which is the exact contrary of why you'd run a cluster in the
first place) and upgrade it... so one can expect Kubernetes **in
particular** to remain on the same major version once it's running and
in production.

Note that Kubernetes had major breakages between major releases
(deprecated old APIs were removed), which means that upgrading your
cluster has high potential to break your deployment. One more reason to
stay put with whatever release you're running on.

I'm saying all this not as an opinion for or against anything, but just
to present datapoints and arguments.
*t

Re: What to do when DD considers policy to be optional? [kubernetes]

[Tomas Pospisek]

On 25.03.20 15:19, Andrey Rahmatullin wrote:
> On Wed, Mar 25, 2020 at 03:14:41PM +0100, Tomas Pospisek wrote:
>> On 25.03.20 14:43, Christian Kastner wrote:
>>
>>> This is not to say that licensing is an unimportant issue -- it clearly
>>> is. But our analyze-and-document down-to-the-file approach is on the
>>> other extreme end of the spectrum, and it causes lots of tiresome work
>>> that nobody apart from us seems to care about.
>>
>> I'd contest this. Whenever Open Source standards come up in a
>> discussion, Debian is always the gold reference. You know it can be done
>> right and it is: in Debian.
> Or you can look at the Redhat approach as a minimal working one.
> You know it can be done much easier and still work: in Redhat.

(in case it hasn't already been discussed in this thread, but don't
bother rehashing...): What are they doing differently?

Re: What to do when DD considers policy to be optional? [kubernetes]

[Tomas Pospisek]

On 25.03.20 14:43, Christian Kastner wrote:

> This is not to say that licensing is an unimportant issue -- it clearly
> is. But our analyze-and-document down-to-the-file approach is on the
> other extreme end of the spectrum, and it causes lots of tiresome work
> that nobody apart from us seems to care about.

I'd contest this. Whenever Open Source standards come up in a
discussion, Debian is always the gold reference. You know it can be done
right and it is: in Debian.

Having the possibility to look up to that standard and being able to
compare to it is a value and valuable in it self.

That said, Debian doesn't have to hold up that standard if it doesn't
deem it useful of course. Me personally I deem it very valuable. I can
be sure that if stuff lands in Debian then I won't get screwed by weird,
dirty, missleading, underhanded licensing rules, which seems to be the
standard outside the Open Source world and even on its fringes.
*t

Re: Repeated Debian WiFi problem

[Tomas Pospisek]

On 22.03.20 10:47, Marc Haber wrote:
> On Sun, 22 Mar 2020 02:20:18 -0700, Peter Pynchon 
> wrote:
> 
>> *In future Debian versions, could you please include the ASUS driver in the
>> standard package?*  *The model number is the ASUS N53 USB WiFi adapter with
>> the rt3572 chip.*  I see on your website that ASUS N53 USB adapters with
>> different chips have similar problems.
> 
> Does the driver need non-free firmware? If yes, the card will probably
> never work out of the box in Debian proper, and you might need to
> install the firmware manually. Doing this will most probably solve
> your issue with current Debian as well.

There is install media that include non-free Wifi/Network card drivers
AFAIK (you'll need to search around). Also if you include the non-free
section in your /etc/apt/sources.list then you'll get a non-free
firmware package that you can install. Again please search
packages.debian.org for a corresponding firmware package.

This belongs to a Debian support channel though and not to debian-devel.
*t

Re: trimming changelogs

[Tomas Pospisek]

On 20.03.20 00:50, Adam Borowski wrote:

> In the rush for cutting away small bits of minbase [...]
> [trim changelogs]

I don't know man minbase is, so I don't know what you are
talking about.

On a normal desktop/server I'd expect
/usr/share/doc/$PKG/changelog.Debian* to contain the whole history until the
beginning of the universe, since the used disk volume for
that info we're speaking about is not "large" IMO.

I could live with only a part of the changelog being
present there, with a link on the bottom of the file telling
me where to find the rest. This would be less userfriendly
to me but workable.

On whatever kind of "minimal" system I'd expect /usr/share/doc
to contain a README that explains where on the internet to find
the respective doc/$PKG/*.

I'm using the changelog "often". Often in the sense that my
Sysadmin work leads me there time and again to look research
changes.

*t

rereadmin the ln manpage

[Tomas Pospisek]

On 17.03.20 15:48, Wouter Verhelst wrote:

> Yes. I keep messing that up in production (ln is one of those commands
> that I continually need to read the man page of)

I suggest the `tldr` command for that...
*t

Re: RFC: Replacing vim-tiny with nano in essential packages

[Tomas Pospisek]

On 16.03.20 12:29, Marco d'Itri wrote:
> On Mar 16, Simon McVittie  wrote:
> 
>> `busybox vi` is rather limited, but is reasonable as an editor of last
>> resort; busybox is smaller than either nano or vim-tiny; full systems
> Agreed: this is a very good idea since I really think that every default 
> install must provide something enough vi-compatible.

I'd disagree. vi is very newbie unfriendly. OTOH I expect people that
know how to navigate vi to be able to `apt install vi` without any problem.
*t

Re: RFC: Replacing vim-tiny with nano in essential packages

[Tomas Pospisek]

On 16.03.20 11:06, John Paul Adrian Glaubitz wrote:

> I would like to suggest to replace vim-tiny with nano as the default minimal
> editor installed with debootstrap and therefore debian-installer.

+1

Re: FTP Team -- call for volunteers

[Tomas Pospisek]

On 14.03.20 22:41, Roberto C. Sánchez wrote:
> On Sat, Mar 14, 2020 at 09:18:48PM +, Neil McGovern wrote:
>> Hi debian-project and ftpmaster folks,
>>
>> On Sat, Mar 14, 2020 at 01:37:59PM -0700, Sean Whitton wrote:
>>>   - cope well with flames in response to your decisions
>>
>>>   - after training, comfortable with being on the other end of the
>>> ftpmaster@ alias, which receives a huge volume of
>>> not-always-pleasant messages daily.
>>
>> I hope I am not the only one to be deeply concerned that this should be
>> a requirement on volunteers. For me, it is absolutely unacceptable that
>> people should put up with unplesentness or flames that come from doing a
>> difficult job. Putting this in the requirements is, for me, a failure of
>> the project.
>>
>> Sean: do you have any ideas on how we can reduce this aspect of the
>> valuable work that ftpmasters do? Do you have some (anonymised) examples
>> of the areas of abuse that you receive perhaps?
>>
> The fact is that given the length of time packages can wait for NEW
> processing and the amount of effort package maintainers put into
> packaging, it is understandable that they would be frustrated at the
> rejection of a package.  That said, it does not make flaming the FTP an
> acceptable response and is certainly not going to produce any positive
> result.  But it is not clear that it would be possible to prevent such a
> thing.
> 
> It seems like if NEW processing only took a short time (perhaps 1 or 2
> weeks), then a rejection would be less frustrating.  However, a
> rejection after waiting 11 or 12 months (or longer) and no response to
> requests for additional guidance when something is unclear are difficult
> to deal with from the package maintainer side.
> 
> The delays may be unavoidable, but any measures to minimize them would
> go a long way to reducing the likelihood of flame responses to rejection
> mails.

In theory, "given enough eyeballs, all bugs are shallow", making the
*packaging process* more visible would alleviate this problem. Not
having a package accepted can be interpreted as a bug on the packagers
side, so if the culture of Debian packaging would be amended so that
packagers do the packaging in public, f.ex. on Salsa, then those
"packaging bugs" could be spotted and fixed earlier, relieving the ftp
masters.

The packagers can then invite the public to have a look and to
criticize, making the packaging more fit for the strict judgement of the
ftp masters...

*t
*t

documenting on how not starting a daemon upon installation

[Tomas Pospisek]

> On Sun, 8 Mar 2020, Marc Haber wrote:
>
> On Sat, 7 Mar 2020 21:30:33 +0100, Tomas Pospisek 
>
> >When I duckduckgo "dpkg do not start service on install" first hit is
> >[1] which contains /absurdly involved/ suggestions to achieve "not
> >starting a daemon upon installation".
> >
> >[1]
>
>https://askubuntu.com/questions/74061/install-packages-without-starting-background-processes-and-services#
>
> This is indeed bordering between incredibly funny and disturbing.
> Alas, it's a golden example for the quality of answers one gets in the
> Ubuntu universe.

Not commenting on Askubuntu: it is also an indication, that the "right
way" to do this is "way too badly documented".

In my logic, finding out how "not to start services on install" should
be documented in `man dpkg` or referenced from that man page. As far as
I could see there is absolutely no trace of any hint on how to do that
in that man page.

It might also be me not having read that man page closely enough to
discern the microbial hint to where to find that info.

So I think it would be proper to improve the documentation here. I as an
"advanced user" should not need to rely on second hand information via
StackOverflow but find it naturally through `man dpkg` and `man apt-get`
IMHO.

Currently I don't have any idea on how to go about this, i.e. where how
to document this and similar things. Suggestions, hints welcome.
*t

PS: sorry for not replying correctly to Marc's message (and thus
breaking threading), I have deleted that message already :-(

Re: not starting a daemon upon installation

[Tomas Pospisek]

On 07.03.20 21:30, Tomas Pospisek wrote:

> tldr: why is not having a daemon started on install so involved? Can't
> there be a better way?

to which Jonas, Marco & jnqnfe replied (see thread). Thanks a lot Jonas,
Marco & jnqnfe!
*t

Re: apt 2.0 release notes

[Tomas Pospisek]

On 08.03.20 19:10, Jonas Smedegaard wrote:
> Quoting Matthias Klose (2020-03-08 18:40:34)
>> On 3/7/20 9:41 PM, Julian Andres Klode wrote:
>>> # APT 2.0
>>>
>>> After brewing in experimental for a while, and getting a first outing in
>>> the Ubuntu 19.10 release; both as 1.9, APT 2.0 is now landing in unstable.
>>> 1.10 would be a boring, weird number, eh?
>>>
>>> Compared to the 1.8 series, the APT 2.0 series features several new 
>>> features,
>>> as well as improvements in performance, hardening. A lot of code has been
>>> removed as well, reducing the size of the library.
>>
>> $ apt show  >/dev/null | cat
>>
>> WARNING: apt does not have a stable CLI interface. Use with caution in 
>> scripts.
>>
>> Is there a roadmap when the CLI interface will become stable?
> 
> I would not expect apt to ever get a stable interface for scripting.
> 
> "man apt" says this in first paragraph of section DESCRIPTION:
> 
>> apt provides a high-level commandline interface for the package 
>> management system. It is intended as an end user interface and enables 
>> some options better suited for interactive usage by default compared 
>> to more specialized APT tools like apt-get(8) and apt-cache(8).
> 
> I.e. for scripting, use apt-get instead.

If that last paragraph wants to say "use apt-get for scripting" then it
should say it clearly and explicitly and not leave it up to sufficiently
astute interpretation skills of the reader...
*t

not starting a daemon upon installation

[Tomas Pospisek]

Hi all,

tldr: why is not having a daemon started on install so involved? Can't
there be a better way?

I'm hacking around an ansible playbook that needs to configure an etcd
cluster.

The problem is that installing the package will automatically start the
daemon cluster in a "default" configuration.

That's a problem for me because etcd differentiates between starting the
cluster for the first time and starting it subsequentially. The first
time is special as it generates some internal state.

So I would like to control whether etcd - or for the matter any service
- is started upon package installation.

I imagine that this would be quite a standard requirement for
devops/configuration tools aka "please do not run and configure the
service for me because I want to do it precisely **this way**" (which is
kinda the point of configration automation).

Nota bene: that requirement does not criticise Debian packagers nicely
integrating all things - which is of huge value for the task.

When I duckduckgo "dpkg do not start service on install" first hit is
[1] which contains /absurdly involved/ suggestions to achieve "not
starting a daemon upon installation".

It /seems/ that the "official" way to achieve "not starting a daemon
upon installation" is to use `dpkg-divert` to overwrite `policy-rc.d`
with a script that exits with 101.

This to me seems again like a awkward, byzantine and brittle way to
achieve that goal. Also, the only canonical documentation of policy-rc.d
seems to be
/usr/share/doc/init-system-helpers/README.policy-rc.d.gz, which is quite
cryptic, contains no examples and contains "rc.d" in its name in a world
where systemd is the default, which makes me doubt whether all packages
using systemd will respect policy-rc.d...

So I'm wondering:

* is this really the official (twisted ?8-o) way to solve the problem of
not starting a daemon automatically upon installation?
* why was such an involved method chosen, instead of say setting an
environment variable DPKG_DONT_START_DAEMON or such?

I'm writing to d-d because I think this is a fundamental distro problem
that's worth a thought/discussion/improvement.

?

Waves-
*t

[1]
https://askubuntu.com/questions/74061/install-packages-without-starting-background-processes-and-services#

Re: spammer closing bug report

[Tomas Pospisek]

On 02.03.20 21:34, Alexis Murzeau wrote:
> Hi,
> 
>> Most likely it has been BCC'ed, that's what spammers like to do when
>> they send the same mail to thousands of recipients.
>>
> 
> Indeed, this can be seen by clicking on "full text" here in the bug report:
> ---
> Reply sent to nore...@no.com:
> You have taken responsibility. (Mon, 02 Mar 2020 14:00:05 GMT) (full
> text, mbox, link).
> ---
> 
> Then on Message part 3 here (which is the original message sent by the
> spammer):
> ---
> [Message part 3 (message/rfc822, inline)]
> ---
> 
> The first line contains 492400-done, so it was in Bcc:
> ---
> Received: (at 492400-done) by bugs.debian.org; 2 Mar 2020 13:56:49 +
> ---

Ah, thanks for shining the light on this Alexis and Sven!
*t

Re: spammer closing bug report

[Tomas Pospisek]

On 02.03.20 18:06, Sven Joachim wrote:
> On 2020-03-02 17:20 +0100, Tomas Pospisek wrote:
> 
>> I just got a mail from the BTS, that this spam mail [1] has closed the
>> bug report. I can't spot why that spam mail would close the report. Can you?
> 
> Without even looking at the bug in question: because it had been closed
> (and reopened) before, and spammers have noticed and harvested the
> nn-d...@bugs.debian.org address.

With looking at the bug in question: no, I don't think so. There's no
-done address in that mail as far as I can see. That is why I am asking.


>> Possibly other bugreports have been closed by similar spams, I don't
>> know (this - BTS cleaning - would still be an area I'd like to get
>> involved in... if BTS maintainers are listening, interested and would do
>> some handholding then please tell).
> 
> This issue has been discussed for at least 16 years[1], so don't hold
> your breath.
> 
> Cheers,
>Sven
> 
> 1. https://lists.debian.org/debian-devel/2004/03/thrd2.html#00847

I'm offering my help and breathing on as usual.
*t

spammer closing bug report

[Tomas Pospisek]

Hi all,

I just got a mail from the BTS, that this spam mail [1] has closed the
bug report. I can't spot why that spam mail would close the report. Can you?

Possibly other bugreports have been closed by similar spams, I don't
know (this - BTS cleaning - would still be an area I'd like to get
involved in... if BTS maintainers are listening, interested and would do
some handholding then please tell).
*t


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=492400#39

Re: requirements and regulations concerning upgrade checks/statistics callback on program start

[Tomas Pospisek]

On 26.12.19 06:42, Norbert Preining wrote:

> (please Cc)
> 
> are there any requirements or restriction what a program packaged in
> Debian is allowed to do when starting up? Calibre is normally doing the
> following checks:
> - check for updates of itself
> - check for updates of plugins
> - send UID, OS, program version, and the icon theme selected in the
>   program to the statistic site [1]
> 
> Which of the above actions are acceptable for Debian/main?
> 
> [1] https://calibre-ebook.com/dynamic/calibre-usage

The last point seems inacceptable to me if the user hasn't explicitly
consented to it. Checking for updates might be annoying but is "OK" to me.
*t

Re: Summary: Git Packaging Round 2 [comments by 11/05/2019]

[Tomas Pospisek]

Hi Sam & Debianistas,

this is far TLDR for me. That is not meant as a critique, but as a
feedback so you have a data point from some random Debianer's available
CPU resources.

(in general I'm fine to declare best practices for whatever issue so
that people can orient themselves on where to head to, provided that
those "best practices" aren't "too far out")

Am 08.10.19 um 03:22 schrieb Sam Hartman:
> 
> [...]

Re: Init systems and docker

[Tomas Pospisek]

Hi Debianistas!

Am 12.10.19 um 01:06 schrieb Ben Hutchings:
> On Fri, 2019-10-11 at 18:49 -0400, Scott Kitterman wrote:
>> I have had bugs filed against more than one package I maintain regarding 
>> issues 
>> with sysv init scripts when used in docker.
>>
>> I have been told by docker users (I'm not one) that systemd as provided on 
>> Debian can't be used in docker.  I have no idea if that's true or not.  I 
>> try 
>> really hard to know as little about init systems as possible and trust our 
>> maintainers who work on such things.
>>
>> If it is true, then to the extent we want Debian to be useful for docker 
>> does 
>> that mean we ought to maintain sysv init scripts?  If it's not true, can 
>> someone point me to documentation that explains using systemd on Debian in 
>> docker?
> [...]
> 
> As I understand it, Docker is meant for application containers, and
> application containers should have a trivial init process that directly
> launches a single application process.  No init script, or indeed any
> shell script, should be used at all.

I have to say that I disagree with you and many others on this thread.
Maybe Docker was *meant* for single application containers, I do not know.

However running a service ("a single application") often implies
surrounding services. F.ex. you want logs to be saved? Maybe you need to
run cron or at? Maybe you want to get notified about problems, stats,
whatever via email?

Now you can start re-implementing all the existing "surrounding" service
solutions on the outside of the container. Which is a *lot* of complex
work in my experience. The quick fix to those "surrounding" problems is
often enough to stand onto proven-to-work shoulders and to install the
"surrounding services" *inside* the container:

apt-get install cron at rsyslogd etc. etc.

Now the next problem is how to start those. Easiest way is to hook the
provided Debian init scripts into whatever mini-init system one chooses.
And so forth.

So I imagine people that want to run stuff in containers are usually
very glad if init scripts are available, work and can be re-used.

John Goerzen is maintaining Debian docker images (thanks!) that contain
a useful set of the mentioned "surrounding" services, that are quite
popular AFAIK.

Being you, I'd ask for patches. I think running stuff in
Docker/Kubernetes is a good solution for a lot of problems. I think
Debian should grow to accommodate those architectures. And I think
Debian *will* accommodate them (see John's work and a lot of other nice
efforts in that direction not least by Ubuntu), it just takes time to
find the sweet spot solutions, to spread the knowledge and knowhow etc.
A lot of container loads are Debian based, not the least a lot of
Kubernetes' own people's.

This is my view of course, which *might* be herethic to the narrower
Docker and Kubernetes orthodoxies.

Re: help

[Tomas Pospisek]

Am 15.08.19 um 21:09 schrieb seydi mouhamadou moustapha ndiaye:

> I'm a student in computer engineering field from africa and I look for a
> mentor who can  help me to accurate my computer skills mainly on coding.

Learn by doing. Install Debian on your laptop. Then pick a package you
like or that you think could use improvement. Improve it. Send a bug
report with a patch.
*t

Re: Please stop hating on sysvinit (was Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?)

[Tomas Pospisek]

Am 07.08.19 um 19:00 schrieb Marc Haber:
> On Wed, 7 Aug 2019 14:44:01 +0100, Ian Jackson
>  wrote:
>> Marc Haber writes ("Re: do packages depend on lexical order or 
>> {daily,weekly,monthly} cron jobs?"):
>>> We have already thrown sysvinit away.
>>
>> No, we have not.
> 
> We have given up on so many ideas that sysvinit has come with that it
> doesn't make sense to stick to Tradition on this count.

FWIW (I mean it, this is just anecdotical evidence): I have been
recently upgrading a lot of containers and host and I have been unable
to make lxc guest with systemd inits even start.

Also, I have been having problems with ssh sessions taking 25 seconds to
start on the remote side because of systemd and pam trying to initialize
some systemd user session.

I gave up on understanding both of those problems after an hour or two
of research on each. After all, machines were down, automation was not
working I had to get the stuff running again.

So at this instant I can't see sysv going away because there's too many
things not working in practice on my systems with systemd.
*t

Bug#932769: [moreinfo] DoS via DHCP request

[Tomas Pospisek]

So my interpretation of your initial bug report, that the VM would DoS the 
host on which it was running via fast changing of IP addresses on its 
interface was completely off the track?


So what you wanted in fact wanted to say by "DoS'ing the server" was that 
the VM sends huge amounts of DHCP requests to the DHCP server (possibly 
also in addition depleting IP addresses from the DHCP server's IP address 
pool) and *that* amounts to a DoS? Is my interpretation correct?


If that's the case, then I'm reassinging this bug report to 
isc-dhcp-client and merging it with the mentioned bug report #888209.


*t

On Tue, 23 Jul 2019, Mark Hutchison wrote:


Hi fellas,
Apologies for the brevity in the initial bug report.  I was using the reportbug 
tool directly from the console of the VM I was working on, small resolution.  
Allow me to elaborate...

We initially discovered this bug testing our storage product, we had a Debian 
10 VM running in a typical ESXi 6.7 environment with iSCSI backed storage.  The 
VM ran in a VMDK file on a VMFS datastore volume.  While the
VM was running in memory, we removed the storage initiators from ESXi 
purposefully to test something unrelated, to simulate a storage outage.  After 
a couple of minutes the OS will go into R/O mode without its disk,
and at that time dhclient will rapidly request IP's from our ISC DHCP server.  
dhclient will take the IP, consume it from the DHCP pool and then request 
another.  After some period of time this depletes the DHCP pool,
several hours to days depending on the scopes size.  This could also be 
replicated by deleting the hard disk from a running VM in a virtual environment.

When I look at systemctl for the dhclient service, I can see that there's an error, "can't 
create /var/lib/dhcp/dhclient.intname.leases Read Only file system", and then the 
DHCPREQUEST > DHCPACK > DHCPDECLINE sequence
starts every few seconds, and occasionally the service will show "RTNETLINK answers: 
File Exists."

I'm guessing from the error that dhclient has a problem with not being able to 
read / write to the client leases file, declines the IP and requests another, 
but secretly holds on to the IP.

The DHCP server logs will show a final DHCPDECLINE after the ACK, and mark the 
address as abandoned.  The VM will still have the address leased however.  
After a period of time VMware's guest tools will show all the
consumed IP's belonging to that MAC address and virtual interface.  Network 
gear ARP shows the IP's belonging to the same MAC as well.

We've consistently reproduced this bug in our lab, and performed the test 
simultaneously with a Debian 9, Centos and Ubuntu 16 instance to make sure it 
wasn't some kind of NetworkManager thing, or a broader Linux
issue.  

I see that someone reported this similar bug back in 2018 as well, I think they 
may be the same thing.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888209

Thanks, just let me know if you have any questions.



On Tue, Jul 23, 2019 at 4:23 PM Tomáš Pospíšek  wrote:
  Am 23.07.19 um 17:57 schrieb Ben Hutchings:
  > On Tue, 2019-07-23 at 16:51 -0400, Tomas Pospisek wrote:
  >> Package: general
  >> Followup-For: Bug #932769
  >>
  >> Could you privide a recipe on how to reproduce this? There's a lot of
  >> very special setup below, that someone wwould need large amounts of 
time
  >> to reporoduce I feel.
  >>
  >> Is it possible to reduce the problem to something easily 
demonstratable?
  >>
  >> This seems to be an important issue to me.
  >>
  >> I think the problem here *might* be a kernel problem? Re-assign this to
  >> kernel package?
  > [...]
  >
  > So far as I know, the kernel only ever does DHCP if you net-boot
  > without an initramfs.

  My focus was more on this issue here - aparenty:

  Mark Hutchison wrote:

  >> This DoS's the server [due to DHCP changing IPs rapidly
  >> - my interpretation] and the interface attempts to take and discard
  >> IP's in a rapid fashion.

  -> changing IPs of an interface of a *VM* can DoS the server. Which I
  think is not expected, and not terribly funny. It takes a bit of not so
  straightforward circumstances (as far as I can understand the bug
  report), but then an attacker can DoS the server via DHCP. Which is uh,
  I mean ah, um.

  Information is a bit sparse here, though.

  If I may shoot completely off topic for a second: Woah, many thanks
  for your terrific kernel maintenance work Ben. Truly amazing :-o!!!
  Thanks so may times a lot! Woah :-) Thank you! (this doesn't exclude
  the rest of the kernel team - my thanks extend to you all - it's just
  that I have the honor to say thanks to a participating party in this
  email exchange 8v)!
  *t

Bug#931296: general: Camera flash drive mount does not show up on desktop

[Tomas Pospisek]

Package: general
Followup-For: Bug #931296

Hi Roger,

Roger wrote:

> Plugging in camera in Buster does not show flash storage on desktop as
> it did in previous versions with Xfce DE.

There was no reply to this bug report. The problem is, that debugging
this involves some work, which you need to do. Such as going through
the logs on your machine and trying to see whether there's some
interesting info there related to the problem you are seeing.

Also googling around if you find some reports about this problem on the
net might be useful.

Without that info this bug report will have to be closed, since
there's not much we can do.
*t

Re: Comparing/Using Conda with Debian

[Tomas Pospisek]

Am 11.07.19 um 06:53 schrieb Steffen Möller:

> On an project-internal mailing list the thread "Conda vs Debian"
> [etc.]

What's Conda?
*t

Re: Notes on packaging PCYNLITX

[Tomas Pospisek]

Hi,

I have a few rather higher level questions about PCYNLITX.

* are there any known users of PCYNLITX, in the sense of, does
  there exist an application, that actually uses PCYNLITX?

* I have read through the web page of PCYNLITX. I can not
  make up my mind. The web page is talking about how well
  documented PCYNLITX is, but there's no code examples of
  how PCYNLITX is used, as far as I could find. Without
  that it's too hard for me to make up my mind about it.
  I find the concept interesting, but without seeing
  code - hmmm...

?
*t

Am 12.07.19 um 08:52 schrieb Bagas Sanjaya:
> Hello,
> 
> I've filed RFP for PCYNLITX sometimes ago [1]:
> 
> In PCYNLITX download page [2], it can be installed by using installation 
> script. However, after examining install
> script, I noticed following:
> - PCYNLITX doesn't employ version numbering like any other project/packages. 
> It would be difficult to identify
> which is the latest version. So I use version number 0.0~git20190606 in RFP 
> report.
> - The script install wxWidgets library from third-party repository, not from 
> Debian. It use codelite repo (for Stretch):
>> apt-add-repository 'deb http://repos.codelite.org/wx3.0.4/debian/
>> stretch libs'
> - Evince will be installed as runtime dependency, possibly for documentation. 
> For non-GNOME users (KDE, XFCE, etc.)
> which use different readers (like Okular and Atril) this can bloat their 
> system and become unnecessary.
> - All steps are performed using sudo. If the script is run by root user, this 
> will be redundant, since the installation
> is done by root privileges.
> 
> If I will packaging PCYNLITX for Debian, any suggestions, assuming that I 
> have read New Maintainers Guideline and
> related Debian packaging documentation?
> 
> Cheers, Bagas
> 
> [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931400
> [2]: http://www.pcynlitx.tech/the-installation-of-pcynlitx/
> 
> -- 
> An old man doll... just what I always wanted! - Clara
> 

Bug#932769: [moreinfo] DoS via DHCP request

[Tomas Pospisek]

One more question. When you say VNWare integrated product. AFAIK vmware 
have their own networking module in the kernel? Can you reproduce this 
with some other virtualisation technology like kvm, qemu?


And one more question: do depending on who does the DHCP receival in the 
VM (systemd? isc-dhcp-client? [...]?): shouldn't there be some rate 
limiting sanity check in the DHCP client?

*t

On Tue, 23 Jul 2019, Tomas Pospisek wrote:


Package: general
Followup-For: Bug #932769

Could you privide a recipe on how to reproduce this? There's a lot of
very special setup below, that someone wwould need large amounts of time
to reporoduce I feel.

Is it possible to reduce the problem to something easily demonstratable?

This seems to be an important issue to me.

I think the problem here *might* be a kernel problem? Re-assign this to
kernel package?

When you say that it DoS'es the server then what does "top" say? What is
being DoS'ed? Is it the CPU?
*t

It would be truly cool, if you could provide more infos.
*t


To: Debian Bug Tracking System 
Subject: general: DHCP request bug when storage lost
Date: Mon, 22 Jul 2019 14:48:00 -0600

Package: general
Severity: important
Tags: l10n

Dear Maintainer,

While doing unrelated storage testing for our VMware integrated product, we 
purposefully recreated
a storage outage by removing the iSCSI initiators from the backing array 
hosting the vmdk disk
images for the virtual machine.

Upon removal of uplinks to storage, the VM goes into a R/O file system state 
after 5-10 minutes.
When storage initiators are brought back up and the LUNs are rescanned, the VM 
begins to
rapidly request DHCP leases from an ISC DHCP server.  This DoS's the server in 
a way due
to the number of DHCPDECLINE errors, and the interface attempts to take and 
discard IP's in a
rapid fashion.

This only seems to appear on this distribution, and I can't replicate the 
behavior on Debian 9
or in a desktop environment.



-- System Information:
Debian Release: 10.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled






-- System Information:
Debian Release: 10.0
 APT prefers stable
 APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_CH.utf8, LC_CTYPE=de_CH.utf8 (charmap=UTF-8), LANGUAGE=de_CH:de 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#932769: [moreinfo] DoS via DHCP request

[Tomas Pospisek]

Package: general
Followup-For: Bug #932769

Could you privide a recipe on how to reproduce this? There's a lot of
very special setup below, that someone wwould need large amounts of time
to reporoduce I feel.

Is it possible to reduce the problem to something easily demonstratable?

This seems to be an important issue to me.

I think the problem here *might* be a kernel problem? Re-assign this to
kernel package?

When you say that it DoS'es the server then what does "top" say? What is
being DoS'ed? Is it the CPU?
*t

It would be truly cool, if you could provide more infos.
*t

> To: Debian Bug Tracking System 
> Subject: general: DHCP request bug when storage lost
> Date: Mon, 22 Jul 2019 14:48:00 -0600
> 
> Package: general
> Severity: important
> Tags: l10n
> 
> Dear Maintainer,
> 
> While doing unrelated storage testing for our VMware integrated product, we 
> purposefully recreated
> a storage outage by removing the iSCSI initiators from the backing array 
> hosting the vmdk disk 
> images for the virtual machine.
> 
> Upon removal of uplinks to storage, the VM goes into a R/O file system state 
> after 5-10 minutes.
> When storage initiators are brought back up and the LUNs are rescanned, the 
> VM begins to 
> rapidly request DHCP leases from an ISC DHCP server.  This DoS's the server 
> in a way due
> to the number of DHCPDECLINE errors, and the interface attempts to take and 
> discard IP's in a
> rapid fashion. 
> 
> This only seems to appear on this distribution, and I can't replicate the 
> behavior on Debian 9
> or in a desktop environment.
> 
> 
> 
> -- System Information:
> Debian Release: 10.0
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.19.0-5-amd64 (SMP w/1 CPU core)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled





-- System Information:
Debian Release: 10.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_CH.utf8, LC_CTYPE=de_CH.utf8 (charmap=UTF-8), LANGUAGE=de_CH:de 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Re: Let's consider using year based release identifiers [was: Re: getting rid of "testing"]

[Tomas Pospisek]

Hi,

Am 29.06.19 um 23:32 schrieb Thomas Goirand:
> On 6/29/19 3:33 PM, Tomas Pospisek wrote:
>> Am 29.06.19 um 15:28 schrieb Andrey Rahmatullin:
>>> On Sat, Jun 29, 2019 at 01:53:35PM +0200, Tomas Pospisek wrote:
>>>> TLDR; year based release identifiers should be prefered since they are
>>>> much more intuitive to reason about than codenames and sequentialy
>>>> numbered release identifiers.
>>>>
>>>> If Debian should improve/change release identifiers, then I'd suggest to
>>>> ponder a year based versioning scheme (as Ubuntu is using).
>>> This only works with Ubuntu because they set the release date in advance.
>>
>> You assign the year to the release identifier when the release is ready:
>> release_id = now().year(). There's certainly some infrastructure stuff
>> that needs that release_id that needs to be prepared in advance, but I
>> think that can be done pragmatically, when the release is "99%" ready.
>> Am I missing something?
>> *t
[...]
> 
> In some software we have in buster, they already have hard-wired the
> names of the 2 next Debian releases. How would you do this with years if
> we don't know the release dates in advance?

Allow me to start with the inverse question: should the fact that
software makes assumptions about the future preclude humans from shaping
that future as they deem best?

Now what if there was a way to have both: a better naming scheme *and*
compatibility with software that hard codes the future?

Lets see - one possibility would be to have both year based release
identifiers and code name based ones. That could possibly solve both
issues (better naming + compatibility).

Or maybe there are yet other ways to solve the supposed contradiction?
F.ex. updating the hard-coded SW comes to my mind.

> Besides this, I very much dislike the way it sounds. :)

The way what sounds?
*t

Re: Let's consider using year based release identifiers [was: Re: getting rid of "testing"]

[Tomas Pospisek]

Am 29.06.19 um 15:28 schrieb Andrey Rahmatullin:
> On Sat, Jun 29, 2019 at 01:53:35PM +0200, Tomas Pospisek wrote:
>> TLDR; year based release identifiers should be prefered since they are
>> much more intuitive to reason about than codenames and sequentialy
>> numbered release identifiers.
>>
>> If Debian should improve/change release identifiers, then I'd suggest to
>> ponder a year based versioning scheme (as Ubuntu is using).
> This only works with Ubuntu because they set the release date in advance.

You assign the year to the release identifier when the release is ready:
release_id = now().year(). There's certainly some infrastructure stuff
that needs that release_id that needs to be prepared in advance, but I
think that can be done pragmatically, when the release is "99%" ready.
Am I missing something?
*t

Re: Let's consider using year based release identifiers [was: Re: getting rid of "testing"]

[Tomas Pospisek]

Am 29.06.19 um 14:41 schrieb Jeremy Stanley:
> On 2019-06-29 13:53:35 +0200 (+0200), Tomas Pospisek wrote:
> [...]
>> As others here I am starting to get confused by the release code
>> names, as are my peers that are not that much into Debian. And
>> sequential release numbers are devoid of any semantics except for
>> their monotonically increasing character.
> [...]
> 
> And yet you *wouldn't* be confused when Debian 2019.7 is released in
> 2021?

That's right, I don't think that'd confuse me. The reason it wouldn't
confuse me, is that I expect releases to be updated eventually and that
can happen at any time in the future - f.ex. in 2021.
*t

Let's consider using year based release identifiers [was: Re: getting rid of "testing"]

[Tomas Pospisek]

Am 25.06.19 um 08:08 schrieb Ansgar:

> what do people think about getting rid of current suite names ("stable",
> "testing", "unstable") for most purposes?  We already recommend using
> codenames instead as those don't change their meaning when a new release
> happens.
> 
> Related to that I would like to be able to write something like
> 
>   deb http://deb.debian.org/debian debian11 main
>   deb http://security.debian.org/debian-security debian11-security main
> 
> in sources.list as codenames confuse people.
> 
> Ubuntu already has no suite names, only codenames, but having to map
> "Ubuntu 18.04" to "bionic" instead of just writing the version in
> sources.list is annoying (I always have to look up the codename to be
> sure as I don't use Ubuntu that much).

TLDR; year based release identifiers should be prefered since they are
much more intuitive to reason about than codenames and sequentialy
numbered release identifiers.

If Debian should improve/change release identifiers, then I'd suggest to
ponder a year based versioning scheme (as Ubuntu is using).

As others here I am starting to get confused by the release code names,
as are my peers that are not that much into Debian. And sequential
release numbers are devoid of any semantics except for their
monotonically increasing character.

On the other hand, using year numbers as release identifiers has the
advantage of:

* getting rid of the need to remember arbitrary names and their sequence
* being linked to and rooted in everyday human experience, which makes
it intuitive and easy to reason about releases

When reasoning about an installation of Ubuntu "14.04" one can easily
come to the conclusion, that it's probably wise to upgrade, that release
being 5 years old, whereas an "16.04" might still smell reasonably fresh
and is probalby still OK to run.

Let's seriously consider using year based release identifiers.
*t

Bug#922712: general: Freezing on log-in screen when booting laptop on battery power

[Tomas Pospisek]

Hi,

the main problem here is that you are reporting the problem against 
"general", since that will probably not lead to the bug being acted upon.



"Hewlett Packard Pavilion g6 2239-sr reffered as "laptop" later
after clean Debian stable install (with Xfce DE, but i assume it's not 
important as it has problems with most if not all DEs)

and instalation of "firmware-linux" metapackage and tlp


What does "tlp" mean?

The outcome was that it rendered system unusable when booting on battery 
power, as it freezed system on Log-in screen with slight graphical 
glitches appearing on screen like broken mouse cursor/pointer/arrow as a 
mess of ASCII characters (not letters but symbols rather) and the part 
of input field(s) becomes a little bigger than another making a slight 
aliasing effect


* does the problem not happen when connected to power?
* when you switch back to CTRL-ALT-F1, do you get to the login prompt?

I assume that the problem is with the graphics system. Can you please find 
out what graphics driver is being used? Have a look at 
/var/log/Xorg.0.log.


Do you see any problems reported there?

Once you have determined what graphics driver is being used, then can you 
please find out to which package that driver belongs and reassign this bug 
report to the relevant package? Better yet, make a new bug report against 
the respective graphics driver package, since that should collect a lot more 
informations and add them to the report. Once you have created the new bug 
report, then please merge this bug report with the newly created bug 
report.


Did you google around for the type of your laptop and the graphics chip 
whether there are maybe other bug reports and or solutions?

*t

Re: Limiting the power of packages

[Tomas Pospisek]

On 3 Oct 2018 Lars Wirzenius wrote:

> A suggestion: we restrict where packages can install files and what
maintainer scripts can do.

On 4 Oct 2018 Enrico Weigelt wrote:

> Finally, I'd really like to reduce complexity, not introduce even more.

+1

I think Linux systems per se, Debian as a runtime, the (social)
processes required from DDs/DMs, the whole technical Debian packaging
ecosystem are each plenty complex enough already. So adding more
complexity will:

* increase friction and dissipative heat production, which means less
software in Debian, less DMs/DDs, less fun, pushing mean temperatures on
earth further up

* increase the number of edge cases, increase the number of possible
interactions between different parts of the whole system, reduce the
ability of us users/DDs/DMs to reason about/understand/cope with our systems

These points above do not imply that Lars' idea is bad and should not be
pursued. Instead they IMHO should serve as a dimension to measure
Debian's/Linux' progress against and as a yard stick to measure our
solutions against:

* did the added constraint or tech reduce or increase complexity and our
ability to reason about the system?

* did the new tech enable us to throw away part of older tech that was
badly defined, complex, broken?

* did the new solution advance us toward a model that is easier to
understand?

*t

Accepted dia 0.97.3+git20160930-8 (source) into unstable

[Tomas Pospisek]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 14 Feb 2018 11:15:39 -0200
Source: dia
Binary: dia-common dia
Architecture: source
Version: 0.97.3+git20160930-8
Distribution: unstable
Urgency: medium
Maintainer: Tomas Pospisek <tpo_...@sourcepole.ch>
Changed-By: Tomas Pospisek <tpo_...@sourcepole.ch>
Description:
 dia- Diagram editor
 dia-common - Diagram editor (common files)
Closes: 838537
Changes:
 dia (0.97.3+git20160930-8) unstable; urgency=medium
 .
   * New maintainer (closes: #838537)
   * debian/control: Bumped Standards-Version to 4.1.3
   * debian/control: Bumped debhelper to 10
   * debian/patches: Added a patch to fix typos
   * debian/rules: Remove empty directories
   * debian/rules: Added extra flags
Checksums-Sha1:
 6d584765642a1bec9f6fd9b08fed5e53ee324fef 2343 dia_0.97.3+git20160930-8.dsc
 b775a2b45be9d9e093621e639c742aa48386dc9d 24420 
dia_0.97.3+git20160930-8.debian.tar.xz
 0b2bc4c7204abf60d31c96c3a19904482f44e314 14560 
dia_0.97.3+git20160930-8_amd64.buildinfo
Checksums-Sha256:
 2b9469ca81ce3ac01e64ef3aaec48bf69dd777515cef93a9ae273a239171888f 2343 
dia_0.97.3+git20160930-8.dsc
 2566dbdd8d706e4a07bc23910ee104431f85833bd76ec27b2b5d85b3a81fb231 24420 
dia_0.97.3+git20160930-8.debian.tar.xz
 ffb83d815483c7955ddb6d2e63e781db7ff8ddedbadf209106f516c0f07ae68a 14560 
dia_0.97.3+git20160930-8_amd64.buildinfo
Files:
 0390bfd1cf981e3b7cd06dbf1026eead 2343 graphics optional 
dia_0.97.3+git20160930-8.dsc
 e248eb8c2accf770bb495d9b44b264c2 24420 graphics optional 
dia_0.97.3+git20160930-8.debian.tar.xz
 60258dd959a8232c59df2e307012d184 14560 graphics optional 
dia_0.97.3+git20160930-8_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEFIKTfq3v+7kjJpqM7roVDCl3SzkFAlqKhicACgkQ7roVDCl3
SznczQ//endgeRxc4gjEzf81q1DA8aqcgo0gsY7TySgnp3pNlazSMNPywGoevU4o
0x5OrrHjPGNmkhiE5NDHAJzXCVQJdJLBkfx/Q2wWVm2mgpaVSsrv5SbxxjlUjxJ1
p+CI0yJH6+LWBR0ZN2rB8gtpFA0le6epSzJshofo/SjcPCPDn5HcyXI5JEVtI1ko
ioGtyhNnh8L5ULl/GfPJqhJC5w/AGwTb1m6yV911PHUCNg4bfsf17TWUmVKbrEkJ
3KDXUPZ4Siy5JTeF1LfG/5meSLsxD/b0N1Nk4Iwhr61vkK/VwM7gYb48k4HBpQ8Z
XxeGTS5xQtLKvkP5UkUihX9P6dv0brR/9rgbHZtwagihZkDRrPxvCTVmW8DQEONi
N4kjbCx2jGbaGV7yrXEVUTRLLo2Wt5DTUmN66NvSQkWxO0Yx11Tbr0IIz5Ubf6Xf
zgkmrvbQx2Xh2jn9LG4EPyALMjKgAWGKeAA3WNDK+zcGaT2VMHjkv5Vqwjdc4xP8
S0hfqUAkgupJlDITnoi/DGYqcC1oabzSeVxfTpZJNcVNt6W4yX4PeRKW9PvqrJQW
jyAZD1YMJS/gjr6c5s/uDiyN7IqlqBiqbguEsfevnCj+EFgO8ikmoNana/cMhYXL
CVYGYqpEVEAeV6x4Df7VJaRl+nE8FV7dVGbsH8xiSwq+lqI5SvE=
=J14V
-END PGP SIGNATURE-

Re: Q: How to get build depends package from debian/control

[Tomas Pospisek]

Am 12.02.2018 um 05:41 schrieb Yao Wei:
> [...] I'd prefer mk-build-deps from devscripts since this
> produces pseudo-package that depends on the build dependencies, and the
> dependencies can be removed by removing the pseudo-package. 

Whoa, what a gem, I did not know existed! Just what I was looking for
for years. Thanks for mentioning it! (and thanks to Vincent Fourmond and
Adam D. Barratt for creating mk-build-deps).
*t

Re: Bug#875545: ITP: cpdf -- The tool provide a wide range of professional, robust tools to modify PDF files.

[Tomas Pospisek]

Am 15.09.2017 um 04:22 schrieb Francisco Vilmar Cardoso Ruviaro:

>> If this is your first package to Debian, for a variety of reasons I
>> don't recommend packaging something that will go to non-free.
>
> Yes, this would be my first package, I understood that it is
> inappropriate to initially send something like this, I will close the bug.

I suggest not to be afraid.

If you feel that it's a useful package (I do), and want to accept
critique learn and improve as you do the packaging, then I suggest do go
boldly forward.

Greets,
*t

Re: Improvement of sensible-utils

[Tomas Pospisek]

Am 11.08.2017 um 18:37 schrieb Bastien ROUCARIES:
> Hi,
> 
> I have done some work for sensible-utils but I am a little stuck due
> to lack of documentation/policy.
> 
> I want first to create desktop file for
> sensible-editor/sensible-pager/sensible-browser in order to open from
> firefox text file (fixing #780742).
> 
> The main problem is to exec this in a terminal or not depending of the 
> context.
> 
> I propose first to solve #594942 and to implement sensible-x-terminal
> first. This program will
> exec $XTERMINAL if set, then if configured $SENSIBLE_XTERMINAL and
> lastly choose the terminal according to desktop running (maybe using
> xdg-open /proc/self/1 < sensible-x-terminal
> 
> Then nano for instance will provide sensible-editor-nano that will use
> library provided by sensible-utils in order to run nano under a
> terminal if run under X.
> 
> What do you think ?

Sounds good to me.
*t

Re: Qupzilla Deb-stretch x86_64

[Tomas Pospisek]

Please install the package reportbug and use reportbug to report the bug.
*t

Am 28.04.2017 um 11:06 schrieb Fungi4All:
> --- Please fill out the fields below. ---
> 
>Package name: qupzilla
> Version: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/538.1
> (KHTML, like$
> Upstream Author: [NAME >]
> URL: [http://example.com]
> License: [GPL, LGPL, BSD, MIT/X, etc.]
> Description: It crashes when accepting-exempting expired certificates
> This is amd64 Stretch
> 

Re: convention on listen port local or all network interfaces etc.

[Tomas Pospisek]

Am 23.02.2017 um 03:26 schrieb Patrick Schleizer:
> Tomas Pospisek:
>> Am 21.02.2017 um 01:55 schrieb Patrick Schleizer:
>>
>>> for file_name in /usr/lib/server-config.d/*.conf ; do
>>>file_list="$file_list $file_name"
>>> done
>>>
>>> for file_name in /etc/server-config.d/*.conf ; do
>>>file_list="$file_list $file_name"
>>> done
>>>
>>> for file_name in /home/.config/server-config.d/*.conf ; do
>>>file_list="$file_list $file_name"
>>> done
>>>
>>> for item in $file_list ; do
>>>source "$item"
>>> done
>>
>> I like this in principle. However, I'd rather make stuff explicit than
>> implicit. Implicit means you need to have a priory knowledge, explicit
>> means you see stuff. So for the above that would be:
>>
>> $ cat /etc/server/main.config
>> ...
>> # predefined
>> include /usr/lib/server/config.d/*.conf
>> # system config
>> include /etc/server/config.d/*.conf
>>
>> *t
> 
> That is a great idea! Will try to keep explicit vs implicit in mind.
> Explicit is great. I'll be updating this convention proposal when no
> more comments come in.
> 
> Would you suggest just a single file /etc/server/main.config?
> 
> Or should there be also:
> 
> - /usr/lib/server/main.config
> - /etc/server/main.config
> - /home/.config/server/main.config
> 
> ?
> 
> Should main.config file[s] only contain `include` statements and
> comments and nothing else?

I'd suggest to use principles as orientation lights, but not as dogmas.

So f.ex. if you have some config file that is not expected to be
modified much (see /etc/* - most of the files there I never touch but,
in good Debian tradition, it's good *to be able* to customize stuff, if
need arises). So the configs that should work in most environments out
of the box could be in one piece - and contain the includes and maybe a
few other things.

On the other hand if you have configs that are pages and pages long
(which converges towards unreadable), or are expected to be extended or
customized heavily - apache comes to mind for both characteristics -
then you probably want to split the config into as orthogonal and
topical pieces as useful. Again, you can see the evolution of this
principle f.ex. with apache which started as a single config file and
today has quite a nice separation of concerns into different subdir.d's.

There are other examples of the latter principle f.ex. in Debian's
nginx' layout, which I consider very well done, or Debian's exim config,
which I consider non-understandable without a nuclear physics degree and
multiple years of study. (I am also the kind of person who thinks that
maybe systemd has surpassed exim in that regard and entered a whole new
dimension, maybe of a string theory quality, a place that only sendmail
enlighteneds are reported to have seen before. I have not much studied
selinux yet though, which has been created by some of the brightest
cryptographers of our time I hear).

Have a look around in /etc on desktop machines and on servers and have a
look at those configs that are ugly, uncomprehensible or beautiful and
intuitive and try to determine what the reasons for the beauty or
ugliness are.

*t

Re: convention on listen port local or all network interfaces etc.

[Tomas Pospisek]

Am 21.02.2017 um 01:55 schrieb Patrick Schleizer:

> for file_name in /usr/lib/server-config.d/*.conf ; do
>file_list="$file_list $file_name"
> done
> 
> for file_name in /etc/server-config.d/*.conf ; do
>file_list="$file_list $file_name"
> done
> 
> for file_name in /home/.config/server-config.d/*.conf ; do
>file_list="$file_list $file_name"
> done
> 
> for item in $file_list ; do
>source "$item"
> done

I like this in principle. However, I'd rather make stuff explicit than
implicit. Implicit means you need to have a priory knowledge, explicit
means you see stuff. So for the above that would be:

$ cat /etc/server/main.config
...
# predefined
include /usr/lib/server/config.d/*.conf
# system config
include /etc/server/config.d/*.conf

*t

"Dear Customer" spam in the BTS

[Tomas Pospisek]

Hello all,

I've recently received "Dear Customer" spam on a bug of mine. I've
searched the BTS [1], and there are many, many, many of these spam
postings in the BTS, see f.ex. [2].

I think it doesn't make sense to press "this bug log contains spam" on
each of those pages. Better would be to go directly to the archive and
delete such posts directly from there.

I know I have once tried to do that - I think with a bit of advice from
Don Armstrong but it never went anywhere.

Has anyone tried to do such a thing yet (methodically clean the bug
archive of spam)? Where and how could I start such an effort? How would
I get read/write access to the BTS archive?

?
Thanks,
*t

[1]
https://www.startpage.com/do/metasearch.pl?query=site%3Abugs.debian.org%20%22Dear%20Customer%22
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754505

Bug#799057: general: After my laptop hung and reset KDE4 doesn't start

[Tomas Pospisek]

Hello Vitaly,

Am 15.09.2015 um 12:43 schrieb root:
> Package: general
> Severity: important
> 
> [long Xsession dump without any further info]

I'm closing your report. The "general" pseudo package is not a support
channel to help debug and sort problems out.

Please use one of the available support channels for that:

https://www.debian.org/support
https://lists.debian.org/debian-user/
http://forums.debian.net/
irc://irc.oftc.net/debian

Thanks,
*t

Re: Bug#798202: ITP: fonts-leckerli-one -- Leckerli One font

[Tomas Pospisek]

The URL entry below is broken.
*t

Am 06.09.2015 um 20:05 schrieb Gioele Barabucci:
> Package: wnpp
> Severity: wishlist
> Owner: Gioele Barabucci 
> 
> * Package name: fonts-leckerli-one
>   Version : 2011
>   Upstream Author : Gesine Todt
> * URL : 
> http://www.example.org://www.google.com/fonts/specimen/Leckerli+One
> * License : OFL-1.1
>   Description : Leckerli One font
> 
> Leckerli One is a free Open Type font designed by Gesine Todt.
> It is a fat display typeface with irregular brush shapes and a
> handwritten feeling.
> 

Re: BUG: Debian Jessie as KVM guest on GlusterFS backend

[Tomas Pospisek]

Hello Roman,

debian-devel is not the right place to ask support questions. Please try
any of Debian's official support channls:


https://www.debian.org/support
https://lists.debian.org/debian-user/
http://forums.debian.net/
irc://irc.oftc.net/debian

*t

Am 14.07.2015 um 11:16 schrieb Roman:
 Hi,
 
 I'm having problems with installing D8 as KVM guest on GlusterFS storage
 backend.
 I run 4 different proxmox (debian based with RH kernel) nodes and got
 this problem on every of them.
 
 Versions:
 
 qemu-server: 3.4-6
 pve-qemu-kvm: 2.2-10
 glusterfs-client: 3.6.4-1
 
 No matter what I do, I'm not even able to complete the installation
 process, it stops on random step:
 
 1. on mirror select (just suddenly says, that mirror is not accessible
 or there is no right version of Debian located)
 2. on package installation step (just says that it is not able to solve
 deps as some pkg was not configured, usually it is python-gtk2 or smt
 like that).
 
 Once I was lucky enough to install the base system, but ended up with
 unstable system: apache did't run due to missing modules, while they
 were at their places, seemed to me like corrupted. Also it seems to me,
 that files are getting corrupted while installed on glusterfs storage
 backend.
 
 I can install D8 on local storage without problems. 
 
 There are no error logs on glusterfs side.
 
 Debian 7 installs and runs fine. Ubuntu 14.04 LTS installs and runs
 fine. Centos 6 installs an runs fine.
 
 Any ideas? This has to be solved somehow. I'm also in contact with
 GlusterFS users list and wrote to devel list, but was not able to solve it.
 
 I used glusterfs 3.5.4 before, was the same problem.
 
 Where should I report this issue to get it solved? 
 
 -- 
 Best regards,
 Roman.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55a60010.5070...@sourcepole.ch

Re: Bug#790933: ITP: drive - Google Drive tool

[Tomas Pospisek]

Am 05.07.2015 um 09:15 schrieb Jackson Doak:
 It might be possible to rename the binary and symlink drive to it,
 which would allow you to give the binary name over easier


Top-posting in a thread breaks the flow of the messages - as you can see
here.

The way to go here would be the alternatives mechanism, which serves
this purpose.
*t

 On 5 Jul 2015 9:11 am, Clint Byrum spam...@debian.org
 mailto:spam...@debian.org wrote:
 
 Excerpts from Joachim Breitner's message of 2015-07-04 13:45:40 -0700:
  Hi,
 
  Am Samstag, den 04.07.2015, 17:16 +0200 schrieb Sophie Brun:
   Le 03/07/2015 21:46, Guillem Jover a écrit :
drive is an extremely generic name in tech, please use something
else
when packaging this, both for the source/binary packages and the
executables and other related files. Prefixing it with «google-»
could
be an option, perhaps. Doing this upstream would be preferable.
  
   I followed your suggestion and opened this issue:
   https://github.com/odeke-em/drive/issues/271
   But upstream doesn't seem to be agreed. What do you suggest?
 
  you are free to choose your source and binary package name independent
  from upstream’s choice. For example, all Haskell packages are named
  haskell-foo, where upstream calls it just foo. So let upstream do what
  he likes and do what you think is best within Debian with the Debian
  package.
 
 
 Indeed. However, they've selected 'drive' as their binary command name..
 so following upstream's rather unfortunate namespace grab might actually
 be the right way to go, to make sure it's clear 'this is the package
 that owns drive in the execution path'.
 
 
 --
 To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
 mailto:debian-devel-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact
 listmas...@lists.debian.org mailto:listmas...@lists.debian.org
 Archive: https://lists.debian.org/1436050805-sup-4...@fewbar.com
 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/559997c1.7090...@sourcepole.ch

Re: Status on ddeb support in Debian

[Tomas Pospisek]

May I suggest you add:

What is it?
===

* ddeb's are Debian packages with the extenstion .ddeb that
  contain debugging symbols and are built implicitly.
  - A package foo_1.23.deb will receive a corresponding
foo_1.23-dbgsym.ddeb package.
  - ddebs are built automatically by dh_strip.

Or such. The above info is deduced from random bits. I haven't
really read the whole thread closely, so my blurp above might
be wrong.
*t

Am 29.06.2015 um 18:17 schrieb Niels Thykier:
 Here is another short update on ddeb support in Debian.
 
 What is missing?
 
 
  * Only known blocker is missing archive/dak support.
 
  * Once DAK support is implemented, I intend to enable ddebs
unconditionally in debhelper.
 
 Where are we?
 =
 
  * debhelper in unstable can now build ddebs - disabled by default.
- Test with env DH_BUILD_DDEBS=1, but please don't upload ddebs to
  any Debian archive.
 
  * lintian gives no remarks to the new ddebs.
 
  * dh_strip can now be asked to /not/ build ddebs, if your package for
some reason cannot use them.
- Known cases are: linux (build-id based debug symbols not supported)
  and possibly other kernels
 
 
 How can I help?
 ===
 
  * Please review the documentation in dh_strip(1) and help me improve it
where needed.
 
  * [Toolchain maintainers] If you maintain that might need to handle
ddebs /differently/ than a regular ddeb (e.g. reprepro), please
look into implementing that.
 
  * [Derivatives] Please consider upgrading your infrastructure /
tooling if/where needed.
 
 FAQ
 ===
 
  Q: What if my distribution/use-case is ready to build ddebs?
  A: Please import debhelper 9.20150628 with the attached patch
 cherry-picked.
 - Note, if your developers/users moonlight as DDs, please remind
   them to build their Debian packages in a clean unstable chroot
   with the regular debhelper! They should be doing that already,
   but a reminder cannot hurt.
 
  Q: What happens if I upload a ddeb to unstable?
  A: Either dak unconditionally rejects your upload (if you are lucky)
 OR it ends up in NEW (if you are unlucky).  Note that once your
 package is in NEW, subsequent upload will /also/ end up in NEW.
 Even if they do /not/ include the ddeb package.
 
 Thanks,
 ~Niels
 
 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5592270f.7080...@sourcepole.ch

Re: Xen PVUSB - Debian 8

[Tomas Pospisek]

Am 16.06.2015 um 11:19 schrieb pietrop:
 Hi all,
 
 I am trying to setup a Debian 8 machine running XEN, which I've
 installed from the package manager, to use the USB passthrough.
 
 It looks like I need to use the module xen-usbfront and xen-usbback,
 which I can't find in the /lib/modules/(my kern)/*
 
 
 Are there ways to get around this ?

This is possibly not the right list to ask this question. You could try on:

https://www.debian.org/support
https://lists.debian.org/debian-user/
http://forums.debian.net/
http://ask.debian.net/
irc://irc.oftc.net/debian

But probably it's better to go to an even more specialized list f.ex.
for sysadmins or for Xen itself.
*t


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5581d694.3060...@sourcepole.ch

Re: Bug#765953: Wifi issues. Firmware package not fixed in testing release

[Tomas Pospisek]

Am 10.06.2015 um 19:10 schrieb Acommon LinuxUser:
 Hi,
 I submitted a bug about 8 months ago, but I didn't receive any reply. I
 updated my Debian system to the testing release (stretch) because a
 new version of the firmware-realtek package has been released for it,
 but it didn't solve the issues.
 This is the link to the reported bug:
 
 https://lists.debian.org/debian-kernel/2014/10/msg00413.html
 
 Since I didn't receive any response I would know if I made some mistake
 in the bug report or if the bug is not related to the firmware package,
 and so I ask to you for a suggestion about the Debian team to which
 forward the bug.

The problem with your bug report is, that it does not contain any
actionable information. It says it doesn't work, but doesn't say what
the circumstances are, what work would look like, what exactly you are
doing etc.

Some informations that would be useful:

- what does the wireless interface fails mean? You can't ping an
  IP address? You can't ping your router? If you look at interface
  statistics, then you see they are not changing? The interface is
  physically off? And so on.

- what brand and type is your wifi *exactly*

- how do you shutdown and restart your wifi interface?

- what do the relevant logs say (kernel log, system log)

And so on.

I think it would be best if you'd contact some Debian support
channel where people can potentially guide you along. I suggest:


https://www.debian.org/support
https://lists.debian.org/debian-user/
http://forums.debian.net/
http://ask.debian.net/
irc://irc.oftc.net/debian

*t



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55796de2.3010...@sourcepole.ch

Re: Regarding text display issues

[Tomas Pospisek]

Hello Himanshu Shekar,

Am 05.06.2015 um 11:33 schrieb Himanshu Shekhar:
 Hello
 I am a Linux enthusiast and have started using Debian a few days back
 after using Ubuntu for 2 years. Debian is really awesome and doesn't crash.
 Well, right now I have two major issues :
 1. Debian cannot display languages as Hindi, not even Google Hindi in
 Chromium.
 2. I just get confused in app names in Synaptic and want to install apps
 without using DVD easily.
 It would be great for this newbie to be properly guided.

For user support you have the following options:

https://www.debian.org/support
https://lists.debian.org/debian-user/
http://forums.debian.net/
http://ask.debian.net/
irc://irc.oftc.net/debian

I hope this will help you on,
*t


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55717269.6020...@sourcepole.ch

Bug#787239: Too little specific information in bug report

[Tomas Pospisek]

reassing 787239 systemd
thanks

This email is going Bcc: to control@b.d.o - now on to further feedback:

Hello Shaman,

On Thu, 4 Jun 2015, Shaman wrote:


what init system are you using? - carefully look above: Init: systemd (via 
/run/systemd/system)


Ah, sorry, I didn't look carefully before...


After hang PC I can reboot only through press Reset button. After boot I see 
in log only last boot info.

I noticed that if before start GDM Manager I login to Console mode and 
enter 'reboot' command, then reboot success, but if GDM Manager start 
and press CTRL+ALT+F1 and login to Console mode and enter 'reboot' 
command then reboot process hang ;(


I don't know how to diagnose this problem...


This looks like a systemd problem so I am reassigning it to the systemd 
package.


What you can do is to look at the allready existing reboot bug reports 
against systemd (search for reboot on those pages):


  https://bugs.debian.org/systemd
  https://bugs.debian.org/systemd-sysv

In particular the following bug reports:

  https://bugs.debian.org/776171
  https://bugs.debian.org/780636
  https://bugs.debian.org/756725
  https://bugs.debian.org/763028

Are they similar to yours?

Is it maybe the same problem and thus this bug report can be merged with 
an existing one?


The bug reports contain some infos about how the reporters should go about 
(or went about) debugging their problems. Can you use that knowledge to 
further analyse your problem?


Greets,
*t


--

Hello Shaman,

I'd suggest you go to a debian support channel to discuss/solve your
problem:


  https://www.debian.org/support
  https://lists.debian.org/debian-user/
  http://forums.debian.net/
  http://ask.debian.net/
  irc://irc.oftc.net/debian

As is your bug report contains far too little specific information (for
example - what init system are you using?) to be able to meaningfully act
on it.

If you are able to make some progress on your problem then please report
back to this bug report and/or close it.

Thanks,
*t




--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/alpine.DEB.2.11.1506041225070.7922@hier

Bug#787239: Too little specific information in bug report

[Tomas Pospisek]

Hello Shaman,

I'd suggest you go to a debian support channel to discuss/solve your 
problem:



  https://www.debian.org/support
  https://lists.debian.org/debian-user/
  http://forums.debian.net/
  http://ask.debian.net/
  irc://irc.oftc.net/debian

As is your bug report contains far too little specific information (for 
example - what init system are you using?) to be able to meaningfully act 
on it.


If you are able to make some progress on your problem then please report 
back to this bug report and/or close it.


Thanks,
*t


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/alpine.DEB.2.11.1506040931280.5760@hier

Re: setlocale doesn't change the language. Why?

[Tomas Pospisek]

Am 12.03.2015 um 06:50 schrieb Joerg Desch:
 Am Wed, 11 Mar 2015 21:16:20 +0500 schrieb Andrey Rahmatullin:
 
 On Wed, Mar 11, 2015 at 01:27:21PM +, Joerg Desch wrote:
 Switch to 'en'
 New LOCALE: 'C'
 Hello World Switch to 'de'
 New LOCALE: 'C'
 Hello World
 So these cases are expected to you?
 
 No. I expect the same output as shown by the other example. I expected 
 that either de_DE or de_DE.UTF8 should fit.
 
 
 You don't have 'de.utf8' locale on this system.
 
 How can I check which locales are available?

/etc/locale.gen

Also 'man locale'
*t


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55014e4d.8030...@sourcepole.ch

Re: Should we mark #388141 as jessie-ignore?

[Tomas Pospisek]

Am 13.02.2015 um 21:15 schrieb Riley Baird:
 On Thu, 12 Feb 2015 21:16:39 +0100
 Tomas Pospisek t...@sourcepole.ch wrote:
 Am 12.02.2015 um 20:59 schrieb Riley Baird:

 Bug #388141 [RC] refers to the relicensing of the debian www pages.
 After contacting debian-www, it seems that there isn't much interest in
 fixing it.

 I interpret the relative silence in #388141 differently then you. I'd
 say that everybody is busy with doing other stuff. So if you want the
 state of affairs to change, just go after it, bit by bit. As you
 describe here:

 The next step would involve compiling a list of website
 lines which are still active yet which relicensing permission has not
 been received.

 And then just ask for permission, line by line.
 
 Surprisingly not! Everyone who has been contacted has already been contacted. 
 The reason for collecting these lines is that we need to determine whether 
 the lines in question are copyrightable, and whether they are still in use.
 
 In the end I think it's work and if it should be accomplished then
 someone has to do that work. Since you are interested, just go and hit
 the work, it may well be that people will join or help you along the way.
 
 I've always been happy to do the work, but I thought that access to the wiki 
 databases was necessary to compile such a list. Or is it possible to compile 
 such a list with just a user account on the wiki?

I'm not sure I really understand what you want to do.

Is something like this:

  https://wiki.debian.org/LXC?action=info

not what you need?
*t


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54e22944.2030...@sourcepole.ch

Bug#777700: (no subject)

[Tomas Pospisek]

reassign 00 linux-image-3.2.0-4-amd64
thanks

Since Debian is preparing to release the next version of its distribution 
I guess that the linux-image-3.2.0-4-amd64 from the Debian wheezy 
distribution will very probably not ever backport support for and thus 
autodetect your RTL8723AE wireless lan card.


As such I think this bugreport could be closed as is, since there's 
nothing else to do.


What you, perihana, could however do, is to test the coming Debian 
jessie release whether it works with your card.


You can find installation and live media for that purpose here:

https://www.debian.org/CD/

Please report back on whether you had success with your card with jessie

Alternatively you could try a backports kernel and respective realtek 
firmware, which *does* support your card:


https://packages.debian.org/wheezy-backports/firmware-realtek

Please let us know, thanks,
*t

perih...@openmail.cc wrote on 2015-02-11:


Package: general
Severity: important

i have a laptop toshiba sattelite pro C850 - 1HG with the
RTL8723AE wireless lan card. Problem: Wireless Lan card not detected by 
kernel


-- System Information:
Debian Release: 7.8
 APT prefers stable-updates
 APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_AT.utf8, LC_CTYPE=de_AT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


*t


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/alpine.DEB.2.11.1502111734420.5972@hier

Re: jessie not mounting all filesystems

[Tomas Pospisek]

Am 29.01.2015 um 20:52 schrieb Daniel Pocock:

 I just upgraded a system with many filesystems to jessie
 
 On many occasions when I boot this system it is failing to mount one of
 the filesystems and systemd gives the emergency login prompt
 
 It is not always the same filesystem though, it seems to be random.
 Most are ext4 on LVM, there are a couple of BtrFS.
 
 In every case I've been able to log in, fsck the filesystem and mount it
 manually.
 
 Is there any problem that anybody is already aware of?
 
 Looking at journalctl output I couldn't see any reason why the mount
 failed, do I have to enable something else to get more helpful log data
 about the problem?

Hearing this, the first thought that came to my mind is: timeouts.

Maybe systemd is trying to mount the FS's in parallel or maybe you get
contention on IO buffers and stuff takes too long for systemd's taste
and it switches into the sky is falling mode? (As can be seen from the
wording I have no solid knowledge of the real workings of that system).

*t



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54cb4a3c.2040...@sourcepole.ch

Re: Who gets an email when with bugreports [was: Re: Unauthorised activity surrounding tbb package]

[Tomas Pospisek]

Am 19.01.2015 um 02:03 schrieb Ben Hutchings:
 On Mon, 2015-01-19 at 08:37 +0800, Paul Wise wrote:
 On Mon, Jan 19, 2015 at 8:06 AM, Don Armstrong wrote:

 I'm going to put together a bit more firm of a proposal in the next few
 weeks, but I think that basically everything but nnn-done@ and
 nnn-submitter@ should be no different from mailing nnn@, and until I
 allow submitters to opt out of e-mail, mailing nnn-submitter@ should be
 no different from e-mailing nnn@ either.

 I'd very much appreciate the ability to not be auto-subscribed to
 every bug so please do implement the opt-out thing, preferably before
 this change is rolled out.

 Personally, I think subscriptions should work like this:

 The default should be to auto-subscribe submitters and contributors to bugs.
 [...]
 
 No, this would turn the BTS into a (worse) spam vector.
 
 But the acknowledgement mail should tell you how to subscribe, if you
 aren't already subscribed.

But isn't subscribing participants natural? Posting to a bug report
means participation and thus you'd get the follow-ups. Why would you
post to a bug report if you aren't interested in what happens with it,
how things proceed/evolve?

I can understand your point of view and I think also the why but isn't
that position the exception from the rule? That is shouldn't the process
be optimized for the common case and allow the exception?

Technically the exception could be implemented by adding a further
pseudo header to the message body:

  Subscribe: false

Another technical solution could be as noted in a different mail in this
thread to allow submitters to set a global flag that says don't
automatically subscribe me on participation.

?

Thanks
*t


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54bcc865.4090...@sourcepole.ch