it? Unless perhaps creating
a new key?
* Are measures in place newly generated keys will not suffer from
these problems?
# appears as big_question_marks
Christoph
signature.asc
Description: PGP signature
tions, things are a lot clearer now.
Christoph
signature.asc
Description: PGP signature
t
> outside of a GR.
So, you've joined Debian a mere half a year ago, and now instead of
talking to people about changing something, you are starting a GR just
to make sure everyone gets to know an idea that will go nowhere
anyway?
Please get a life.
https://xkcd.com/793/
Christoph
elieve. And it would all have to be developed
and maintained. Overall, extending the BTS with "extra services" might be a
worthwhile goal.
Best wishes and still hoping my thoughts are relevant,
Christoph
PS: Thanks to Fabio for making me aware, I had accidentally sent this mail only
to h
On Fri, 2025-01-24 at 13:05 +0100, Jonas Smedegaard wrote:
> Hi Christoph,
>
> Quoting Christoph J. Scherr (2025-01-24 12:13:16)
> > Hello,
> >
> > As someone just starting out with Debian, I'd like to share my perspective
> > on
> > this discus
his is my first email to the lists. I hope these thoughts are relevant and
helpful to the discussion.
Best regards,
--
* Christoph J. Scherr - Student
* Website: https://www.cscherr.de
signature.asc
Description: This is a digitally signed message part
e get in touch with me, or just push and upload the new
version(s) if you have the salsa permissions.
Thanks,
Christoph
ird
places that upstream doesn't see because they aren't on 32-bit, and
wasting maintainer time here doesn't pay off because there are no
users on 32-bit.
It's likely just a 1-line fix, but finding that one line would take at
least 30min.
Christoph
| ^
64-bit builds are fine.
So we'll definitely proceed with removing 32-bit extensions.
Christoph
e trick:
Build-Depends: architecture-is-64-bit ,
That way, people could still build extension packages manually if
they really wanted (dpkg-buildpackage -Ppkg.postgresql.32-bit).
* Remove postgresql-16 from unstable
Comments?
Christoph
[*] On a side note, 32-bit powerpc did actua
2, I am collecting the debian-ports mirror,
four times a day, and this ought to be merged into the regular snapshots
after that date. So end of July 2023 until end of January 2024 is likely
lost, unfortunately, everything after should become visible some day.
Christoph
signature.asc
Description: PGP signature
Hey.
Seems some of the reverse engineers may have found some more
interesting stuff[0].
As far as I understand it, that would still require a running an
reachable sshd (so we'd still be mostly safe).
But he also thinks[1] that it may allow an interactive session.
(Not that this would change a l
On Fri, 2024-04-05 at 20:47 +0200, Sirius:
> > If there is a final result, can we as a project share the results on a
> > prominent place? Or at least under d-devel-announce and/or d-security-
> > announce? I was also wondering about what could have been compromised,
> > what data might have been s
Hey.
On Tue, 2024-04-02 at 01:30 +0100, Colin Watson wrote:
> All the same, I'm aware that some people now depend on having this
> facility in Debian's main openssh package: I get enough occasional
> bug
> reports to convince me that it's still in use.
Being one of those people, and having even a
On Thu, 2024-02-29 at 06:53 +0100, Paul Gevers wrote:
> Well, officially downgrading isn't supported (although it typically
> works) *and* losing files is one of the problems of our merged-/usr
> solution (see [1]). I *suspect* this might be the cause. We're
> working
> hard (well, helmut is) to
On Wed, 2024-02-28 at 21:57 -0800, Steve Langasek wrote:
> Furthermore, this is a downgrade from a replacing package to a
> replaced
> package. Unless you also --reinstall the package at the end, missing
> files
> are quite to be expected.
Shouldn't that case be something that DPKG could detect an
Package: libglib2.0-0t64
Version: 2.78.4-2
Severity: critical
Justification: breaks unrelated software
X-Debbugs-Cc: debian-devel@lists.debian.org
Hey.
CCing d-d since there seems some further deeper problem with the t64
transition (namely lib files getting lost, when "downgrading" i.e.
revertin
Package: wnpp
Severity: wishlist
Owner: Christoph Biedl
X-Debbugs-Cc: debian-devel@lists.debian.org, debian.a...@manchmal.in-ulm.de
* Package name: tftp-proxy
Version : 1.0.0
Upstream Contact: Arnoud Vermeer
* URL : https://github.com/openfibernet/tftp-proxy
> In business, such things are confirmed (often badly) by independent
> audit. For a volunteer-driven community effort, we have to rely on
> everyone to exercise their best judgement in these sorts of matters.
Debian could also get independent, professional audits. I think it would be a
good
Simon Josefsson:
Hans-Christoph Steiner writes:
Thanks for digging in here, its very important work! I'd be happy to
contribute where I can. I'm a DD and a core contributor to F-Droid,
where we wrestle with basically the same issues. So we've thought a
lot about these
Re: Steve Langasek
> Christoph Berg
>postgresql-16 (U)
Please do not upload postgresql-16 before I ack the diff.
I'll also note that *ALL* nmu diffs I've seen so far are using the
wrong version number in debian/changelog, missing the "~exp1" upload
from the actual
Thanks for digging in here, its very important work! I'd be happy to contribute
where I can. I'm a DD and a core contributor to F-Droid, where we wrestle with
basically the same issues. So we've thought a lot about these kinds of things,
but definitely do not have all the answers. Since F
Package: wnpp
Severity: wishlist
Owner: 'Christoph Hueffelmann'
X-Debbugs-CC: debian-devel@lists.debian.org, textsh...@uchuujin.de
*Package Name : chr
Version : 0.1.75
Upstream Author : Christoph Hueffelmann , Martin
Hostettler
*URL : https://github.com/istoph/editor
*License
unsupported.
I think we should only deal with problems that can reasonably happen
in practice. If an extra hammer is required to hit the problem, we
should not spend extra effort on it.
Christoph
refore, my answer to "How can Debian deal with this [schism]?" is
basically: Debian needs to change things in that area anyway, let's
first find an implementation that provides what we need and has a sane
implementation. If that means turning away from GnuPG, so be it. The
transition will
Russ Allbery wrote...
> Since I wrote my original message, I noticed that rlpr is orphaned.
If only rlpr were the only one :-|
When looking into the reverse dependencies of lpr/lprng at the beginning
of this thread, I found several orphaned packages, some for already for
more than ten years. To
asking you for
help with their packaging.
Just from the above website, perhaps something like
python-feedback-control-systems or a bit shorter variant would be more
appropriate. I might be wrong.
Christoph
signature.asc
Description: PGP signature
r changes: In case you've missed that, lzip is not a
mine field in Debian, it's completely burnt ground. It's better to never
mention it.
Christoph
signature.asc
Description: PGP signature
rng, I
have no idea. And there's little chance to know.
Christoph
signature.asc
Description: PGP signature
point pre-2038, hook the write operations, inspect
all data for four-octect sequences that resemble the time (with some
offset) but lack adjacent four octets of value zero that would make it a
64bit time. Repeat for various times and for both endianesses to improve
precision.
And of course, set it
goals are a bit too big for the moment. So at first
I'd like to gather more input on this and would appreciate suggestions
where to head for next. In the quest for final truth.
Christoph
signature.asc
Description: PGP signature
report? I just don't want to put some
pressure on the maintainer if there is some rough consensus such
"managed section" markers are good enough.
Fixing this then is none of by business. Still, having some ucf instead
of just writing the modified file should be enough.
Christoph
signature.asc
Description: PGP signature
Hello,
these days, I found a package in Debian (four-digit popcon count) that
in an upgrade happily removed some some changes I had made to a
configuration file of that package, in /etc/.
My immediate reaction was to consider this a gross violation of the
Debian Policy (10.7.3 "Behaviour"). Upon
X-Debbugs-Cc: debian-devel@lists.debian.org, textsh...@uchuujin.de
Subject: ITP: posixsignalmanager -- posix signal handling for qt
Package: wnpp
Owner: Christoph Hueffelmann
Severity: wishlist
* Package name: posixsignalmanager
Version : 0.3
Upstream Author : Martin Hostettler
X-Debbugs-Cc: debian-devel@lists.debian.org, textsh...@uchuujin.de
Subject: ITP: tuiwidgets -- QtCore based terminal widget toolkit
Package: wnpp
Owner: Christoph Hueffelmann
Severity: wishlist
* Package name: tuiwidgets
Version : 0.2.0
Upstream Author : Martin Hostettler
* URL
take some precautions. This includes wearing
a mask indoors, doing a test, and most important: Stay home in case of
symptoms. And, as stated earlier, if the legal situation forbids or
common sense advises aginst doing such an event, it will not happen.
See you soon,
Christoph
[1] https://wiki.
Christoph Biedl wrote...
> In the future, names must match the following regular expression:
>
> ^[a-zA-Z0-9][a-zA-Z0-9_.@%+-]*$
Some last-minute inspection revealed [@%+] can *not* be considered safe,
so they'll have to be disallowed as well, at least for the time being.
ome holes open that would require another urgent upload.
Special thanks to Julian Gilbey who reported the
underlying issue and helped discussing a fix.
Christoph
signature.asc
Description: PGP signature
and I triggered a re-run of
all 800 affected packages. There are now no "no space left on device"
errors left in vcswatch.
Thanks for spotting,
Christoph
immediately after ITP signalizes "I am 100% sure this
package and my packages will certainly not create objections of any
kind". Which I find somewhere between highly optimistic and plain
arrogant.
So, in my opintion, as a rule of thumb, have a time of three days
between these two actions.
Christoph
signature.asc
Description: PGP signature
replication daemon and the administration tools are in the
package slony1-2-bin. This package is useless without slony1-2-bin installed
somewhere in the network.
Christoph
There is also discussion about making the official Debian Docker images use
HTTPS:
https://github.com/debuerreotype/docker-debian-artifacts/issues/15
Another step towards this goal: the official Debian Vagrant images will default
to HTTPS:
https://salsa.debian.org/cloud-team/debian-vagrant-images/-/merge_requests/15
There are already many Debian mirrors that support HTTPS, not just CDNs. Here's
a script to find HTTPS mirrors
https://gis
Package: general
Severity: wishlist
Since the beginning of F-Droid, we have required that official package repos and
mirrors use HTTPS. We have encouraged all of them to have HTTPS. I think
Debian should do the same. There are already very many Debian mirrors that do
support HTTPS, here's
X-Debbugs-Cc: debian-devel@lists.debian.org, textsh...@uchuujin.de
Subject: ITP: termpaint -- low level terminal access
Package: wnpp
Owner: Christoph Hueffelmann
Severity: wishlist
* Package name: termpaint
Version : 0.3.0
Upstream Author : Martin Hostettler
* URL
t
shouldn't be a big burden.
Christoph
signature.asc
Description: PGP signature
I fully support the idea that HTTPS should become the default for apt repos.
From what I gather, the open question is how best to handle auto-apt-proxy
configuration. There seems to be a number of reasonable proposals:
* Make auto-apt-proxy set "Acquire::https::Verify-Peer false;"
* automat
Hi,
You want either debuginfod or debian-debug, see
https://wiki.debian.org/HowToGetABacktrace.
Marc Haber wrote...
> On Sat, 5 Jun 2021 10:50:20 +0200, Christoph Biedl
> wrote:
> >For me, the biggest downside of the RPi4 is the need for an extra power
> >plug as they take up to three amps - while for example a BananaPi can be
> >powered using some unused USB (&l
. For arm64 will can expect to have support after
that date, for armhf there's at least hope.
Christoph
signature.asc
Description: PGP signature
heck however revealed it's very common the key(s) in d/u/s-k
had expired by the time the last upload to Debian was made. In in ideal
world, upstream would already have refreshed the key, and the Debian
maintainer updated d/u/s-k accordingly - which is the reason why I'd
like to see a lintian check for expired keys.
Christoph
signature.asc
Description: PGP signature
Christoph Biedl wrote...
> PS: Those who want to argue lintian should for check for such expired
> key, I couldn't agree more. Please read the discussion in #985793 first.
Sorry, that should have been #964971.
signature.asc
Description: PGP signature
really like it when uscan also validates signatures. But it seems that
enthusiasm isn't quite shared among all contributors.
Christoph
PS: Those who want to argue lintian should for check for such expired
key, I couldn't agree more. Please read the discussion in #985793 firs
d like to see.)
> For now, debuginfod.debian.net is serving debug information symbols for
> the following Debian distributions:
>
> - unstable
Can you add experimental?
Christoph
a terrible choice of package name.
At least. Even "root-system" is not very distict, I'd rather choose
something like "root-analysis-framework", assuming that name is a good
description for what the package does.
Christoph
signature.asc
Description: PGP signature
ry to have it removed before 12. If anyone
wishes to package the designated successor "llhttp", that would make
quite a few people happy. RFP is #977716.
Christoph
signature.asc
Description: PGP signature
while the
buildds are appearently pre-, and with my local build chroots already
migrated I hadn't noticed beforehand. And now I can only hope the
resulting binaries will run everywhere. The sooner we get out of this
mess the better.
Christoph
signature.asc
Description: PGP signature
later upstream moved it into a separate package.
By request of a user I wish to bring it back to Debian.
Cheers,
Christoph
¹ http://snapshot.debian.org/binary/tang-nagios/
signature.asc
Description: PGP signature
"dpkg-source -b"?), whether this is acceptable, and
how to sanely deal with it.
And I wouldn't care if that hadn't been an impediment when preparing a
NMU for that package since debdiff showed the top-level .gitignore was
removed. Something that certainly should not happen in a N
Package: wnpp
Severity: wishlist
Owner: Christoph Groth
* Package name: qsymm
Version : 1.2.7
Upstream Author : Qsymm authors
* URL : https://gitlab.kwant-project.org/qt/qsymm
* License : BSD
Programming Lang: Python
Description : Symmetry finder and
Hi. Any progress here?
Or any way to help?
Am 01.09.20 um 19:17 schrieb Moritz Muehlenhoff:
>> It may be more future-proof, in case we need it for a future
>> rustc for the next ESR bump.
>
> My gut feeling is the next ESR thing will need LLVM 11 or so, but happy to
> be proven wrong :-) So mayb
Package: wnpp
Severity: wishlist
Owner: Hans-Christoph Steiner
* Package name: pyasn
Version : 1.6.1
Upstream Author : Hadi Asghari and Arman Noroozian
* URL : https://github.com/hadiasghari/pyasn
* License : MIT and BSD
Programming Lang: Python, C
Package: wnpp
Severity: wishlist
Owner: Hans-Christoph Steiner
* Package name: python-javaobj
Version : 0.4.1
Upstream Author : Thomas Calmant
* URL : https://github.com/tcalmant/python-javaobj
* License : Apache-2.0
Programming Lang: Python
Description
Hi,
I am not shure if I can help, but I can try and have a look at it.
Yes please upload your LLVM9 and wasi-libc backports.
Regards
Christoph
Am 31.08.20 um 20:26 schrieb Moritz Mühlenhoff:
>
>> I think we can reuse the same approach as before, by staging uploads
>> in -propo
least not to build the stable
> suites on these IPv6-only buildds. I'm not sure what the plan is there.
Also I am somewhat concerned what will happen when removing the e
AI_ADDRCONFIG hint flag usaged. But I will have to find out.
Christoph
signature.asc
Description: PGP signature
Package: wnpp
Severity: wishlist
Owner: Hans-Christoph Steiner
* Package name: droidlysis
Version : 3.1.0
Upstream Author : Axelle Apvrille
* URL : https://github.com/cryptax/droidlysis
* License : MIT
Programming Lang: Python
Description : Property
Package: wnpp
Severity: wishlist
Owner: Hans-Christoph Steiner
* Package name: ruby-jekyll-polyglot
Version : 1.3.2
Upstream Author : Samuel Volin @untra
* URL : https://polyglot.untra.io/
* License : MIT
Programming Lang: Ruby
Description
Package: wnpp
Severity: wishlist
Owner: Hans-Christoph Steiner
* Package name: golang-github-avast-apkverifier
Version : 0.0~git20200217.aa28c80-1
Upstream Author : Avast
* URL : https://github.com/avast/apkverifier
* License : LGPL-3.0
Programming Lang: Go
Package: wnpp
Severity: wishlist
Owner: Hans-Christoph Steiner
* Package name: apkparser
Version : 0.0~git20200402.9fd46d5-1
Upstream Author : Avast
* URL : https://github.com/avast/apkparser
* License : LGPL-3.0
Programming Lang: Go
Description : APK
Package: wnpp
Severity: wishlist
Owner: Christoph Berg
* Package name: js8call
Version : 2.0.1
* URL : http://js8call.com/
* License : GPL, LGPL, BSD, MIT/X, etc.)
Programming Lang: C++, Fortran
Description : Amateur Radio Digital Mode providing weak
, but upstream has
split them, and has recently picked up development again, so there are
new upstream versions to package.
Christoph
already working on this, for precisely that reason. There a
question releated I haven't worded yet, stay tuned.
Christoph
signature.asc
Description: PGP signature
th and only seccomps that one rather than its
> main process. But it's also not doing the environment cleanup AFAICS.
Yeah, but as I already wrote here, this requires some sorts of IPC and
of lot of joys come with it.
> Kind regards and thanks for making all of us more secure! :)
Trying
Vincas Dargis wrote...
> On 2019-07-26 18:59, Christoph Biedl wrote:
> > > tl;dr: The file program in unstable is now built with seccomp support
> > > enabled, expect breakage in some rather uncommon use cases.
>
> Interesting, what are these uncommon use cases? Maybe
Christoph Biedl wrote...
> tl;dr: The file program in unstable is now built with seccomp support
> enabled, expect breakage in some rather uncommon use cases.
Several issues popped up in the last days as a result of that change,
and in spite of some band-aiding to current implementat
Russ Allbery wrote...
> Christoph Biedl writes:
>
> > tl;dr: The file program in unstable is now built with seccomp support
> > enabled, expect breakage in some rather uncommon use cases.
>
> Thank you very much for doing this! Here's hoping this sets a trend. It
&
Paul Gevers wrote...
> Hi Christoph,
>
> On 19-07-2019 17:18, Christoph Biedl wrote:
> > tl;dr: The file program in unstable is now built with seccomp support
> > enabled, expect breakage in some rather uncommon use cases.
>
> This probably warrants an entry in
via
the BTS.
Finally, a clarification: Applications that link libmagic instead of
calling the file executable are not affected by any of this. But the
respective program authors might consider enabling seccomp on their
own, for the above reason.
Cheers,
Christoph
signature.asc
Description: PGP signature
curity-support in addition to the line
> Details: Not covered by security support
It took me some time find the remark in debian-devel.
Christoph
signature.asc
Description: OpenPGP digital signature
rouble while running a
platform that is providing user-generated content. Because that's what
all the EU law fuss is currently about.
I would welcome your thoughts on that. Thanks.
…Christoph
Jakub Wilk wrote...
> * Christoph Biedl , 2018-11-03, 12:41:
Thanks for proof-reading. Both issues you've reported are upstream, of
course I'll bring them there.
> > It handles the * and ? jokers,
>
> s/joker/wildcard/ ?
Not sure here. Seems in English "joker"
Package: wnpp
Severity: wishlist
Owner: Christoph Biedl
* Package name: libregexp-wildcards-perl
Version : 1.05
Upstream Author : Vincent Pit
* URL : https://metacpan.org/pod/Regexp::Wildcards
* License : Artistic or GPL-1+
Programming Lang: Perl
uld rather be handled inside
Debian.
And I subscribe to that position.
Christoph
signature.asc
Description: PGP signature
e list is public.
Still, all this is an issue, and it should be resolved at freeze time.
Christoph
signature.asc
Description: PGP signature
Emilio Pozuelo Monfort wrote...
> On 05/05/18 17:34, Christoph Biedl wrote:
> > A lot of now defunct alioth addresses are used in the Maintainer:
> > field. This makes the packages rc-buggy for an invalid address.
>
> Before doing the MBF, can you send an email with all th
elow, as created by dd-list. The total count is 711
>
> Since the number of bugs is pretty large, I think it would be best to
> file these in batches.
Probably the right thing. I'll start with the "uploaders" batch, just
some twelve packages left, in an hour or so. The
% count %].
The second option is available for a limited time only, by end of
May 2018 the most. So if you're interested in going this way, start the
process as soon as possible.
Regards,
Christoph and some alioth-lists maintainers
---
y, start the
process as soon as possible.
Note, as mails to the maintainer address will not get through, this
bugreport is Cc'ed to all uploaders of the package.
Regards,
Christoph and some alioth-lists maintainers
--
Affec
Hello everybody,
as discussed more than two weeks ago (time passes too fast), I intend
to do a mass bug filing (MBF) against packages that use any of those
alioth list addresses in debian/control that were *not* migrated to the
alioth-lists service, and hence are now invalid.
Statistic bit: Of 10
here's another option, ask the alioth-list administrators to create an
according forward. For you, this should take less time than writing an
answer to this message, for them hopefully not much longer.
> So please don't file bugs for those.
Noted. But anybody could do this as well.
Christoph
signature.asc
Description: PGP signature
r numbers, even if it's just for
aesthetic reason - "buster" is just more comfortable than "debian10".
However, above all is the rule "do not confuse". Starting two
consecutive releases with the same letter does. Adding a third one makes
it worse.
Christoph
signature.asc
Description: PGP signature
Christoph Biedl wrote...
> Also, @lists.alioth.debian.org addresses that were *not* migrated now
> result in bounces as expected. Are there already plans for a MBF
> severity RC against all packages with a now-failing maintainer address?
Following the rule a social ecosystem can wor
Holger Levsen wrote...
> please file bugs, so that autoremovals can kick in. Thanks.
Sheesh, it's not about removing package but keeping them. By making sure
they are in good shape which, among many other things, means there is a
working well-defined maintainer contact address.
ces as expected. Are there already plans for a MBF
severity RC against all packages with a now-failing maintainer address?
This might become rather messy, I've counted some 1450 packages.
Christoph
signature.asc
Description: PGP signature
not necessary in my opintion. And yes,
sid is a problem then. It would hit us in around the year 2055. I expect
to be stable by then. Stable six feet under.
Christoph
signature.asc
Description: PGP signature
e data at hand, I figured it would be
> easy to generate a dd-list of packages named after their module that
> lack the tag. You find that list attached.
> Christoph Biedl
>file
The src:file package doesn't ship python{,3}-magic any longer, the
change was two months ago.
Package: wnpp
Severity: wishlist
Owner: Christoph Biedl
* Package name: libtext-wagnerfischer-perl
Version : 0.04
Upstream Author : Dree Mistrut
* URL : https://metacpan.org/release/Text-WagnerFischer
* License : Artistic or GPL-1+
Programming Lang: Perl
Package: wnpp
Severity: wishlist
Owner: Christoph Biedl
* Package name: libdigest-ssdeep-perl
Version : 0.9.3
Upstream Author : Reinoso Guzman
* URL : https://metacpan.org/pod/Digest::ssdeep
* License : Artistic or GPL-1+
Programming Lang: Perl
hanks for your test and feedback.
Christoph
signature.asc
Description: PGP signature
glad if RMs had to follow a certain procedure
which boils down to notifying more places and giving a grace period of,
say, two weeks. Which is what in my understanding an ITR would do. If
you just don't want to introduce a new name for this augmented RM, be my
guest.
Christoph
signature.asc
Description: PGP signature
1 - 100 of 1214 matches
Mail list logo
