Re: archive.debian.org mirrors

[Paul Wise]

On Sun, 2024-04-28 at 07:04 +0200, Johannes Schauer Marin Rodrigues wrote:

> speaking of mirroring problematic debian.org services [1] by adding more 
> copies
> of terabytes of data [2]: is there an update of the situation regarding
> snapshot.d.o? I do not see any activity in bugs like #1050815 and #1029744.
> And bug #1031628 was just closed as wont-fix.

See the recent activity on debian-snapshot and join the IRC channel,
I expect there will be another meeting there at some point.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Permission to distribute

[Paul Wise]

On Thu, 2024-04-04 at 01:01 -0700, John Lee wrote:

> I just wondered if I can sell computers that I build with Debian
> Linux pre-installed. The computers may also include programs I
> create. I tried to find the answer to this question but still
> unsure. 

In addition to the other response you got already:

Please note that some of the licenses of software included in Debian
carry additional obligations, like the distribution of source code.

https://www.debian.org/intro/free

Please read and comply with the Debian trademark policy:

https://www.debian.org/trademark

Please consider getting yourself added to our list of preinstallers:

https://www.debian.org/distrib/pre-installed

> If you need more details please let me know.

Which additional programs are you planning on including?

Please consider contributing packages of those programs to Debian.

https://mentors.debian.net/intro-maintainers/
https://www.debian.org/intro/help#coding

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Debian testing/unstable users: beware of Firefox critical CVEs

[Paul Wise]

On Sun, 2024-03-24 at 22:45 +, Samuel Henrique wrote:

> I'm sending this to d-devel because there should be a lot of testing and
> unstable users on this list. If you're not running firefox 124.0.1 or
> firefox-esr 115.9.1esr-1, you should find a way of upgrading to those 
> versions.

firefox-esr from bookworm-security is currently installable on trixie,
but there is no solution from Debian for firefox 124.0.1 yet.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Any way to install packages+run autopkgtests on porterbox machines?

[Paul Wise]

On Sun, 2024-03-03 at 10:20 -0800, Ross Vandegrift wrote:

> Not exactly an answer, but an alternative - it's easy to get an ARM VM from
> many cloud providers.  For a buck or two, I've avoided hours of futzing with
> the porterboxes.  I've heard of providers with PPC, but haven't ever actually
> used one.

There is a list of gratis and paid hardware providers here:

https://wiki.debian.org/Hardware/Wanted#Available_hardware

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Editor extensions to help editing debian/* files?

[Paul Wise]

On Thu, 2024-01-25 at 22:22 -0800, Otto Kekäläinen wrote:

> Yeah, I remember looking into cats some years back as a place to learn
> what commands exist. Similarly I also occasionally browse
> https://pre-commit.com/hooks.html.

Yeah, there are lots of other tools similar to cats, many of them are
linked from the doc/TODO file but there are more I need to add there
and probably many more that I don't know about.

> The challenge with having all possible checkers is that they create a
> lot of noise and managing the false positives end up being a lot of
> work. Not suitable for daily use, but I will probably use cats for
> "annual checkups" on stuff I maintain.

One of the newer features added to cats in 2019 helps there, for some
commands it only enables the highest severity level, then if there is
no output it moves on to the next level, and so on. You can also
disable individual checks or groups of checks as desired. Probably
there are some other things we could add to improve the situation.

> It would be nice though if the version in Debian was newer :)

I probably won't update it until it is suitable for inclusion in a
stable release. This means at minimum being relatively safe to run in
an untrusted source tree, probably by using debvm to generate a VM
containing the relevant tools and running the tools in the VM.

> By the way, I submitted some small fixes at
> https://github.com/collab-qa/check-all-the-things/pulls.

Thanks, I will review them when I get time.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Proposal for how to deal with Go/Rust/etc security bugs

[Paul Wise]

On Thu, 2024-01-25 at 00:24 +, Wookey wrote:

> People keep telling us (@ARM) how marvellous Rust is, and we keep
> telling them that it's useless in the real world until it sorts out
> the stable ABI/dynamic linking problem.

IIRC that has been worked on for some years now, and IIRC
the static linking wiki page has some references about this.

https://wiki.debian.org/StaticLinking

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Editor extensions to help editing debian/* files?

[Paul Wise]

On Sat, 2024-01-20 at 23:43 -0800, Otto Kekäläinen wrote:

> PS. Related, these are commands I frequently run manually but don't
> have any editor integration for:

Thats beginning to look like the history of check-all-the-things.

Initially I maintained such a list of commands on the wiki:

   https://wiki.debian.org/HowToPackageForDebian#Check_points_for_any_package

Then later I worked on a tool to replace that to ease maintenance.

Jakub Wilk was in parallel working on a second implementation.

Eventually I found out and since his tool had a better design but mine
had a better name ;) then we joined forces to work on his together:

https://github.com/collab-qa/check-all-the-things

I haven't had the motivation to work on it for some years though, but I
keep adding TODO items/ideas to a local tree just in case that changes.

There are of course a ton of other tools with the same aim out there,
but almost all of them are aimed at web output or editor output etc,
while check-all-the-things is currently aimed at command-line users,
and most other tools have a more complex process to add new checkers.

I cannot recommend running it on a source tree you don't trust, because
it currently has no sandboxing mechanisms so the source tree could
contain exploits for the QA tools that it may run. Now that debvm and
bwrap etc exist, there is the potential for this to be fixed nicely.

If SARIF support were ever to be implemented, there is the potential
for it to produce machine-readable output and thus be useful for
editors and to become the basis of Debian-wide static/dynamic analysis,
perhaps as an integral part of Debusine when that happens.

https://github.com/collab-qa/check-all-the-things/issues/4

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Debtags: understanding the heuristics of "Checks and hints" in the online editor

[Paul Wise]

On Sat, 2024-01-20 at 09:40 +0100, Jonas Smedegaard wrote:

> I am (very) willing to act as service maintainer.

Please get in touch with the debtags team about this.

https://wiki.debian.org/Teams/DebTags
https://salsa.debian.org/groups/debtags-team/-/group_members

> I have interest myself in continued use of debtags, but don't have C++
> coding skills needed to work intimately on the programming parts of the
> project.

It does not seem to use C++, just Python/Shell/HTML/CSS/JavaScript:

https://salsa.debian.org/debtags-team/debtagsd/-/graphs/master/charts
https://salsa.debian.org/debtags-team/debtags-vocabulary/-/graphs/master/charts
https://salsa.debian.org/debtags-team/debtags-tagdb/-/graphs/master/charts
https://salsa.debian.org/debtags-team/debtags-tools/-/graphs/master/charts

You may be thinking of libept, which got adopted by the apt team.

In case you want collaborators, 5 people forked debtags git repos:

https://salsa.debian.org/search?search=debtag

Additionally apt-xapian-index needs a maintainer and the debtags
package needs to be updated from the debtags-tools git repository.

Some of the debtags related wiki pages may need to be updated:

https://wiki.debian.org/?action=fullsearch=180=debtag=Titles

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Debtags: understanding the heuristics of "Checks and hints" in the online editor

[Paul Wise]

On Fri, 2024-01-19 at 18:24 +0100, André Maroneze wrote:

> I want to use debtags metadata for a research project

The debtags service is planned to be shutdown and the data no longer
published, as there is no-one in Debian who wants to maintain it.

https://lists.debian.org/msgid-search/20231126160111.7nr56b7oje6uw...@enricozini.org

> I started contributing, by adding and removing some tags using the
> online tag editor, but the "Checks and hints" part seems wrong to me
> in several cases.

Sounds like there may be bugs that need fixing, but first there would
need to be a new maintainer who could take over the project. If you
were willing to be the primary code maintainer, perhaps you could find
some Debian member willing to be the service maintainers and review and
deploy all of the changes you could make, at least until you become a
Debian member on the basis of your debtags and other contributions.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Limited security support for Go/Rust? Re ssh3

[Paul Wise]

On Mon, 2024-01-15 at 10:17 +0100, Bastian Blank wrote:

> I asked for practical solutions, not theoretical ones.  We don't have a
> suitable way to rebuild all packages just because right now.

There are some ideas on the static linking wiki page:

https://wiki.debian.org/StaticLinking

Probably the most practical solution for today would be to use a build
info database to find out which builds had installed binary packages
containing insecure statically linkable files of any kind, then rebuild
the source packages that were affected. There is a 2019 demo here:

https://salsa.debian.org/bremner/builtin-pho/-/blob/master/demos/needs-rebuild.sh
https://www.cs.unb.ca/~bremner//blog/posts/builtin-pho/

This may mean rebuilding more packages than were really needed,
but a more exact method would require full tracing of input data to
output data during builds being added to all toolchains, which seems
like a much longer term project than buildinfo based rebuilds.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Running Lintian against a debian/ directory?

[Paul Wise]

On Fri, 2023-12-29 at 10:22 +0100, Niels Thykier wrote:

> Alternatively, for spell-checks, I think someone once wrote a 
> "spellintian" that could use lintian's dataset for spell checking 
> without running the full lintian program. Not sure what became of it.

In 2015 you added Jakub Wilk's spellintian to lintian at my request :)

   $ dpkg -S `which spellintian`
   lintian: /usr/bin/spellintian
   
   $ apt changelog lintian
   
   lintian (2.5.32) unstable; urgency=medium
   
     * commands/spellintian.pm:
       + [JW,NT] Import Jakub Wilk's spellintian tool with minor
     modifications.
   
     * debian/{lintian.links,manpages}:
       + [NT] Install spellintian in PATH and install its manpage.
         Thanks to Paul Wise for the suggestion.  (Closes: #767867)
   
    -- Niels Thykier   Sun, 28 Jun 2015 14:08:29 +0200

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Running Lintian against a debian/ directory?

[Paul Wise]

On Fri, 2023-12-22 at 16:43 +0800, Otto Kekäläinen wrote:

> Currently Lintian requires a (source or binary) package to check[1].

(and some checks require *both* source and binary packages available)

> Is anyone aware of a way to run lintian directly on a debian/
> directory contents as-is without doing a source build first?

I don't think this is supported yet, there is a bug open since 2004:

https://bugs.debian.org/262783

> I am exploring this in order to get my text editor to nag about
> findings immediately without separate source build steps.

This will miss the binary-only and source-and-binary checks,
but it would indeed be quite useful for the source-only checks.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: What would help the most?

[Paul Wise]

On Fri, 2023-10-27 at 14:00 -0500, Lukasz Szybalski wrote:

> What is the minimum most value thing that would
> help YOU accomplish your goals for Debian ?

Check out this page if no-one gives anything more specific:

https://www.debian.org/intro/help

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Hyphens in man pages

[Paul Wise]

On Tue, 2023-10-24 at 05:40 +, Tobias Frost wrote:
> Am 24. Oktober 2023 03:43:29 UTC schrieb Paul Wise:
> 
> > BTW: as a Debian member, you have access to a gratis subscription:
> > 
> > https://wiki.debian.org/MemberBenefits#LWN
> 
> AFAIK this is no longer available.

I am still using the Debian LWN subscription myself.

See these mails in debian-private archives for details:

<5410c39b-3a13-a4d8-ac12-145c1e584...@debian.org>


-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Hyphens in man pages

[Paul Wise]

On Mon, 2023-10-23 at 11:17 -0500, G. Branden Robinson wrote:

> https://lwn.net/Articles/947941/
> 
> Would someone be willing to send me a subscriber-sponsored link to it?

BTW: as a Debian member, you have access to a gratis subscription:

https://wiki.debian.org/MemberBenefits#LWN

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: QDMR on Raspberry Pi OS?

[Paul Wise]

On Tue, 2023-10-10 at 01:28 +, Dan Tallant wrote:

> curious about bringing the QDMR cps software for Linux to the
> Raspberry Pi os (specifically 64 bit running on the Pi4 w/8gb RAM)

As mentioned by Carsten on the list, qdmr is already available in
Debian for arm64 since the bookworm release, not sure about RPi OS.

PS: Debian isn't the place to ask for Raspberry Pi OS support
and debian-devel is not a user support mailing list anyway.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Is there a generic canonical way for a package script to check network connectivity?

[Paul Wise]

On Sun, 2023-10-08 at 22:49 -0400, Jonathan Kamens wrote:

> I need to be able to tell from one of my package scripts whether the
> host has networking connectivity.

Which package and why do the maintainer scripts need network?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: allow missing description fields and empty long descriptions for Rust/etc packages?

[Paul Wise]

On Fri, 2023-09-22 at 14:40 +0800, Paul Wise wrote:

> Personally I think this boilerplate has little to no value, cutting the
> long sentence down to something like just "Rust crate foo" would help

This change has now been merged and will reach Debian eventually:

https://salsa.debian.org/rust-team/debcargo/-/merge_requests/52
https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/545

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: lpr/lpd

[Paul Wise]

On Mon, 2023-09-25 at 12:08 +0900, Simon Richter wrote:

> What I'd like to see is something like
...
>  No installed packages are looking for a new maintainer.

That is what how-can-i-help does, except it doesn't print anything when
there have been no changes to the status of packages on the system, nor
when there are no packages installed that are known to need helpers.

> And ideally, that check would be quick and use information already on
> the system at this point, maybe a supplemental file under indices/ that 
> can be downloaded during an update.

The problem with that approach is that the help needed information
changes independently to packages, so the information will get very out
of date in between point releases, which is why how-can-i-help does
online checks. If desired, it would be easy to have an apt update hook
that would download the data from UDD so that how-can-i-help can work
offline when the network is available.

The main problem with how-can-i-help currently is that the maintainer
is not currently active in Debian and no-one else is working on it.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: lpr/lpd

[Paul Wise]

On Mon, 2023-09-25 at 12:08 +0900, Simon Richter wrote:

> What I'd like to see is something like
> 
>  No installed packages are looking for a new maintainer.

That is what how-can-i-help does, except it doesn't print anything when
there have been no changes to the status of packages on the system, nor
when there are no packages installed that are known to need work.

> And ideally, that check would be quick and use information already on
> the system at this point, maybe a supplemental file under indices/ that 
> can be downloaded during an update.

Currently how-can-i-help does online checks, but it should be possible
to have it add an apt hook to download the necessary files from UDD.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: lpr/lpd

[Paul Wise]

On Fri, 2023-09-22 at 23:07 +0900, Simon Richter wrote:

> One thing I'd think might help would be a tag in the package database
> that is derived from WNPP status, which would allow the summary output 
> at the end of installs also list packages that are installed that are
> currently in RFA or O state.
> 
> I believe we used to have a tool for that in Debian, but almost no one 
> had it installed because it had additional overhead, making it pointless.

You may be thinking of how-can-i-help, which is recommended to every
new person who asks about how to contribute to Debian.

There is also the older wnpp-alert in devscripts.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: lintian.debian.org off ?

[Paul Wise]

On Fri, 2023-09-22 at 09:27 +0200, Jérémy Lal wrote:

> Host lintian.debian.org not found: 3(NXDOMAIN)
> 
> is this expected ?

Yes, it is replaced by the UDD interface:

https://wiki.debian.org/Services/lintian.debian.org
https://udd.debian.org/lintian/

There is no web based location for the description of each tag yet.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: allow missing description fields and empty long descriptions for Rust/etc packages?

[Paul Wise]

On Thu, 2023-09-21 at 19:05 +0200, Fabian Grünbichler wrote:

> the structured metadata of crates only has a short description[0]

Would the Debian Rust team be willing to talk to the upstream
Rust community on adding the concept of crate long descriptions?

> which is often also not very meaningful

Seems like something to be addressed by sending patches upstream,
presumably the Rust team are already doing that though?

> our tooling adds additional boilerplate text that is automatically
> added (for example, which cargo features or binaries a given package
> enables/contains), which is often rather redundant (since the
> features for example are already contained in the package name and/or
> provided virtual package names).

Personally I think this boilerplate has little to no value, cutting the
long sentence down to something like just "Rust crate foo" would help,
until the other options have caused real long descriptions to be added.


> we could try harder in debcargo to extract from other sources
> (with less structure), such as the first paragraph of a readme or of the
> "main" documentation[1]. we have tooling in place that allows us to
> track overrides of auto-generated files (e.g., d/control for rust crates
> is usually completely autogenerated from upstream sources and a
> declarative packaging config file, but if it is overridden, we check in
> the auto-generated version so we notice any changes we might need to
> fold into the override file), which could also be used to track changes
> to the upstream "long descriptions" so that there is no unwanted
> deviation over time.
> 
> as a last resort, we could also make explictly setting and checking in
> an override for the generated (base) long description mandatory, if
> desired.

It sounds like the Debian community would like the long descriptions to
be real descriptions for Rust crate packages (and I would like minimal
boilerplate at minimum). If the Rust team is willing to update debcargo
and curate the long descriptions for new and existing rust-* packages,
that plan to achieve that sounds good.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

allow missing description fields and empty long descriptions for Rust/etc packages?

[Paul Wise]

Hi all,

I have noticed that almost all Rust packages in Debian have boilerplate
long descriptions that aren't very useful to Debian users. The only
useful info is the crate name, but that is also in the package name.

As far as I know they inherit this property from the upstream Rust
crates, which only have a synopsis or even no description at all.

Having the Rust team and other folks add non-upstream descriptions for
crates seems like not very useful work, since the Rust packages are
basically only used as build-deps and therefore have no human users.

So I would like to suggest Debian relax our requirements around binary
package descriptions, especially for Rust binary packages.

Does anyone object to this change?

Are apt/dpkg or the repo creation tools likely to need fixing?

Are there any other places that would need changes? (eg DDTP)

Are there any other ecosystems that this could apply to?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Default font: Transition from DejaVu to Noto

[Paul Wise]

On Wed, 2023-09-13 at 21:09 +0200, Gunnar Hjalmarsson wrote:

> So we have a conflict of goals here. The good news is that a user who
> speaks some latin language, and who thinks it's important to be able to 
> easily select font directly in various applications, can do:
> 
> apt purge fonts-noto-core

That won't work on some systems because various packages hard-depend
on the various fonts-noto packages and metapackages.

Personally I think Debian should use Recommends instead of Depends
for most deps on font packages (including for the Noto fonts), except
for things that don't fall back on other fonts, or require specific
fonts for aesthetic or other reasons, like games that need fancy fonts,
or code needing OCR-friendly fonts etc.

$ aptitude search fonts-noto -F %p | xargs pipetty apt rdepends | grep -v ': 
fonts-noto'
fonts-noto
Reverse Depends:
  Recommends: plasma-desktop
  Depends: libpixelif-common
  Depends: josm-installer
  Recommends: task-korean-desktop
  Recommends: task-chinese-t-desktop
  Recommends: task-chinese-s-desktop
  Recommends: plasma-desktop
  Depends: libpixelif-common
  Depends: josm
  Depends: cinnamon-desktop-environment
  Suggests: fonts-droid-fallback
fonts-noto-cjk
Reverse Depends:
  Depends: prusa-slicer
  Recommends: xml2rfc
  Recommends: task-korean-desktop
  Recommends: task-chinese-t-desktop
  Recommends: task-chinese-s-desktop
  Suggests: signing-party
  Depends: openstreetmap-carto-common
 |Suggests: mlterm
  Suggests: goby
  Depends: freeciv-client-sdl
  Recommends: ddnet-data
fonts-noto-cjk-extra
Reverse Depends:
  Suggests: texlive-lang-japanese
fonts-noto-color-emoji
Reverse Depends:
  Recommends: dino-im
  Depends: sxmo-utils
  Recommends: nheko
  Depends: texlive-fonts-extra-links
  Recommends: texlive-fonts-extra
  Depends: sxmo-utils
  Depends: supertuxkart-data
  Recommends: python3-sqt
  Depends: pango1.0-tests
  Recommends: gnome-characters
  Recommends: gajim
  Depends: fonts-recommended
  Recommends: emacs-pgtk
  Recommends: emacs-lucid
  Recommends: emacs-gtk
fonts-noto-core
Reverse Depends:
  Recommends: libreoffice
  Depends: prusa-slicer
  Recommends: phosh-osk-stub
  Recommends: freetype2-doc
  Recommends: xml2rfc
  Depends: texlive-fonts-extra-links
  Recommends: texlive-fonts-extra
  Recommends: task-sinhala-desktop
  Depends: supertuxkart-data
  Depends: request-tracker5
  Depends: pango1.0-tests
  Depends: odoo-16
  Depends: qml-module-lomiri-components-labs
  Depends: qml-module-lomiri-components
  Depends: lomiri-system-settings
  Recommends: libreoffice
  Recommends: freetype2-doc
  Depends: arctica-greeter
 |Depends: fontconfig-config
  Recommends: python3-fabulous
fonts-noto-extra
Reverse Depends:
  Recommends: libreoffice
  Depends: retroarch-assets
  Recommends: libreoffice
fonts-noto-hinted
Reverse Depends:
  Recommends: plasma-integration
  Depends: prusa-slicer
  Depends: request-tracker4
  Recommends: plasma-integration
  Depends: openstreetmap-carto-common
  Recommends: kodi-data
fonts-noto-mono
Reverse Depends:
  Depends: buskill
  Recommends: libreoffice
  Depends: libpixelif-common
  Depends: texlive-fonts-extra-links
  Recommends: texlive-fonts-extra
  Suggests: signing-party
  Depends: qml-module-lomiri-components-labs
  Depends: qml-module-lomiri-components
  Depends: lomiri-terminal-app
  Recommends: libreoffice
  Depends: libpixelif-common
  Recommends: kodi-data
  Recommends: fonts-droid-fallback
fonts-noto-ui-core
Reverse Depends:
  Recommends: libreoffice
  Recommends: task-sinhala-desktop
  Depends: supertuxkart-data
  Recommends: libreoffice
fonts-noto-ui-extra
Reverse Depends:
fonts-noto-unhinted
Reverse Depends:
  Recommends: xml2rfc
  Depends: openstreetmap-carto-common

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Default font: Transition from DejaVu to Noto

[Paul Wise]

On Sun, 2023-09-10 at 11:34 -0400, The Wanderer wrote:

> Rather than discussing only Noto vs. DejaVu, is there any possibility of
> reintroducing Bitstream Vera as a default-font option (even if with a
> low priority), for systems which have that installed?

IIRC DejaVu is a fork of and similar to Bitstream Vera, the latter is
unmaintained so it makes some sense to drop it in favour of DejaVu.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Default font: Transition from DejaVu to Noto

[Paul Wise]

On Sat, 2023-09-09 at 23:08 +0200, Gunnar Hjalmarsson wrote:

> My personal view is that it is a change in the right direction, and I
> have taken a couple of follow-up steps in Debian. There are still loose 
> ends and more work to be done to achieve a consistent configuration in 
> this respect. However, before taking further steps, I feel there is a
> need to reach out to a broader audience about the change. Hence this 
> message. Basically I'm asking if this move towards Noto is desirable 
> and, if so, I plea for relevant input for the completion of the transition.

Personally, I found Noto Mono to be very ugly in comparison to the
DejaVu fonts that I was used to, so my knee-jerk reaction was to
override the fontconfig settings to avoid all of the Noto fonts.
I haven't yet evaluated the non-monospace Noto fonts though.

Related discussion on the various IRC channels suggested that: 

Noto is meant to be a fallback font (something like unifont but
not using bitmaps) not the default font for all or any languages.

Noto makes the font selector useless because each alphabet shows up.
Apparently fixing this requires changing the OpenType file format.

Apparently the Noto meta package installs 700+ MB of font data,
which seems a bit excessive to some folks.

Some folks are setting explicit fonts in applications they use to avoid
relying on system defaults and also seeing changes to those defaults.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: debian/copyright format and SPDX

[Paul Wise]

On Fri, 2023-09-08 at 12:09 +0530, Hideki Yamane wrote:

> Making appropriate debian/copyright file is hard and boring task, IMHO

Using scancode-toolkit/etc can probably automate most of that work.

https://wiki.debian.org/CopyrightReviewTools

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: __pycache__ directories (Re: Potential MBF: packages failing to build twice in a row)

[Paul Wise]

On Mon, 2023-08-14 at 22:09 +0200, Michael Biebl wrote:

> I received a couple of bug reports against packages I (co) maintain 
> regarding this issue and having a quick look, quite a few fail due to
> python scripts being run during the build and creating a __pycache__ 
> directory.

I recommend asking upstream to delete those directories from their VCS.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Potential MBF: packages failing to build twice in a row

[Paul Wise]

On Sun, 2023-08-13 at 22:28 +0200, Johannes Schauer Marin Rodrigues wrote:
> > dpkg-source: info: local changes detected, the modified files are:
> >   plakativ-0.5.1/plakativ.egg-info/SOURCES.txt
> 
> since this issue seems to be affecting a few more packages than plakativ, I
> wanted to ask here what the canonical way is to fix this issue?

Personally, I would switch from the current orig.tar source (PyPI?) to
using the upstream VCS, which presumably does not have those files,
since they are usually generated by setup.py or something else and
hopefully haven't been committed to the upstream VCS. If they have
been committed to the upstream VCS, send upstream a removal.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Potential MBF: packages failing to build twice in a row

[Paul Wise]

On Sun, 2023-08-13 at 21:18 +, Jeremy Stanley wrote:

> Similarly, I got one for __pycache__/*.cpython-311.pyc file
> overwrites... is that something dh_python should clean?

Probably just send upstream a change removing them?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Potential MBF: packages failing to build twice in a row

[Paul Wise]

On Tue, 2023-08-15 at 09:21 -0400, Boyuan Yang wrote:

> --- ibus-array-0.2.2.orig/po/zh_TW.po
> +++ ibus-array-0.2.2/po/zh_TW.po
> @@ -6,7 +6,7 @@ msgid ""
>  msgstr ""
>  "Project-Id-Version: ibus-array 0.2.2\n"
>  "Report-Msgid-Bugs-To: https://github.com/lexical/ibus-array/issues\n;
> -"POT-Creation-Date: 2019-12-10 22:09+0800\n"
> +"POT-Creation-Date: 2023-08-15 09:07-0400\n"
>  "PO-Revision-Date: 2019-12-10 22:12+0800\n"
>  "Last-Translator: Anthony Fok \n"
>  "Language-Team: Chinese (traditional)\n"

I've long been annoyed by this behaviour as an upstream developer on
gettext based projects. I think the most correct upstream solution to
this is that the gettext tools need to be made deterministic. Probably
the POT creation date field should be removed and replaced with the
date of the last source file modification?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Potential MBF: packages failing to build twice in a row

[Paul Wise]

On Sat, 2023-08-05 at 17:29 +0100, Simon McVittie wrote:

> Devref §6.8.8.2 also says that "it is common for Debian users who
> need to build software for non-Debian platforms to fetch the source
> from a Debian mirror rather than trying to locate a canonical upstream
> distribution point", but I'm not convinced that's true any more. Our
> volunteers' time is our most limited resource, so if we can use that
> time more efficiently by no longer catering to possibly-hypothetical
> users who are building our source code on non-Debian platforms, then
> that might be a worthwhile tradeoff.

For Guix and nixOS at least there are several references to the Debian
mirrors, so at least some distros rely on us for their source tarballs.
I expect that other source based distros do this too.

Personally, if I were to use a non-Debian platform, I would much prefer
getting tarballs from Debian, since they will be DFSG-checked at least,
which I would still want when dealing with non-Debian platforms.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Potential MBF: packages failing to build twice in a row

[Paul Wise]

On Sat, 2023-08-05 at 17:06 +0200, Lucas Nussbaum wrote:

> I wonder what we should do, because 5000+ failing packages is a lot...

Add a message about this on tracker.debian.org for affected packages?

> Should we give up on requiring a 'clean' target that works? After all,
> when 17% of packages are failing, it means that many maintainers don't
> depend on it in their workflow.

We should keep requiring this, having the clean process work properly
it is very useful for when you are doing repeat builds inside a chroot
or VM while debugging a problem, since not having to repeat the build
dependency install step is a useful time-saver.

This also surfaces bugs in upstream clean rules and where upstreams
have accidentally or deliberately shipped prebuilt files in tarballs.
It is important that Debian give back fixes for these to upstreams.

We should also never drop the requirement to run the clean process
before the build, because that would lead to some files not being
built from source in Debian where upstreams ship prebuilt files in
git/tarballs but the clean rules still also remove those files.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: autodep8 test for C/C++ header

[Paul Wise]

On Tue, 2023-08-08 at 11:42 +0300, Adrian Bunk wrote:

> An additional check with some overlap would be whether
>    pkgconf --cflags .pc
> returns 0 for every pkgconfig file in a package.

piuparts runs adequate, which runs something similar:

   pkg-config --exists --print-errors .pc

It emits missing-pkgconfig-dependency when appropriate:

  https://piuparts.debian.org/sid/missing_pkgconfig-dependency_issue.html

There are 42 packages in sid failing this test.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: autodep8 test for C/C++ header

[Paul Wise]

On Tue, 2023-08-08 at 18:32 +0300, Adrian Bunk wrote:

> Manual opt-in for our > 11k -dev packages is a significant cost 
> that would have to be justified by the people who oppose opt-out.

You could use the Janitor to do automatic opt-in where it works,
IIRC the Janitor runs autopkgtests before filing merge requests,
so it could easily try the tests and enable them when they work.

Or the other way, enable them and have the Janitor submit merge
requests to turn them off where they don't work.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: The future of mipsel port

[Paul Wise]

On Sun, 2023-08-06 at 13:54 +0200, Florian Lohoff wrote:

> I am late to the party but as i mentioned a couple times on debian-mips
> already i'd like to keep mipsel as a debian-port - and i'd like to
> revert away from mips32r2 back to mips2/mips3 - That change (with
> stretch) basically dropped all of the supported platforms formerly
> supported without a good reason - mips32r2 cpus would have been 
> able to run mips2 code. The now supported platforms are
> basically non existent or available for the normal user.

That sounds like a new port would be needed, some docs:

https://wiki.debian.org/PortsDocs/New

> So with that change we basically killed 90% of the Debian/mipsel 
> users/community e.g. Siemens RM series, Cobalt Cube/RAQ, Decstation R4k
> and the like which are now all stuck with pre-Stretch Debian Releases.

The baseline bump of the mips port similarly lost MIPSr1 based routers,
some of which could run Debian in a chroot.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: HFS/HFS+ are insecure

[Paul Wise]

On Sat, 2023-07-22 at 12:11 +, Jeremy Stanley wrote:

> When the user has plugged in something that they don't realize
> contains a USB storage device, perhaps because it's attached to an
> internal hub within a device which has other purposes.

Probably it would be a good idea for Debian GNOME to install USB Guard
by default to mitigate this threat. I haven't evaluated how user
friendly the GNOME management of it is though, nor whether the
interface results in bad security decisions by users. With USB input
devices on desktop systems, usbguard makes it easy to get yourself
locked out and need to force a reboot, as I found out the hard way.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: HFS/HFS+ are insecure

[Paul Wise]

On Sat, 2023-07-22 at 08:54 +0100, Matthew Garrett wrote:

> When is a user going to plug in a USB stick and *not* click that button? 

When they found a USB stick in the parking lot, plugged it in, got the
error dialog & only then remembered their company security training :)

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: HFS/HFS+ are insecure

[Paul Wise]

On Fri, 2023-07-21 at 10:28 +, Bastien Roucariès wrote:

> Long term solution will be to push under fuse these filesystem.
> This a (short term)/(medium term band aid) solution.

That still potentially exposes insecure code to untrusted data, just in
a user context rather than a kernel context. The same goes for uml +
fuse + namespaces, and even guestfs VMs. You can move the data and code
to different contexts, but that doesn't change the fundamental issue.

Disabling auto-mounting and for manual GUI mounts, requesting users
confirm they trust the filesystem they are mounting would avoid that as
much as is reasonably possible without entirely deleting the code and
without breaking the use-cases of people who need the filesystem code. 

Of course sandboxing the code for those who need it is good too, so
probably we need both, along with ways to disable the mitigations.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: The future of mipsel port

[Paul Wise]

On Tue, 2023-07-18 at 12:45 +0800, YunQiang Su wrote:

> As CIP United, we do maintain an unofficial port of mipsel.
> So I wish that Debian can still accept our patch to support mipsel
> port (source only).
> https://repo.oss.cipunited.com/debian/

The closest Debian has to source-only ports are the ones that are
supported in rebootstrap but not on debian-ports. You could also
migrate mipsel to debian-ports instead of dropping it entirely.

https://wiki.debian.org/HelmutGrohne/rebootstrap
https://wiki.debian.org/PortsDocs/New

> (And let's keep mips64el port).

DSA would appreciate it if you could publicly document your plans for
trixie mips64el hardware qualification on the wiki, as riscv64 did:

https://dsa.debian.org/ports/hardware-requirements/
https://wiki.debian.org/HardwareQualification

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: usertagging file conflicts [Was: Re: /usr-merge: continuous archive analysis]

[Paul Wise]

On Mon, 2023-07-17 at 07:16 +0200, Helmut Grohne wrote:

> Then I found trei...@debian.org using edos-file-overwrite. That latter
> one seems like what I need here. Should we move it to the qa space and
> drop the edos part? I suggest debian...@lists.debian.org usertags
> file-overwrite.  Otherwise, Ralf are you ok with me reusing your tag?

I have scripts to automate usertags changes and watch weekly diffs.
The QA copy runs from cron fixing some typos and my fork is modified
and run when I notice any weird changes. The script can be used to
easily perform moving and or renaming of usertags as needed here.

https://salsa.debian.org/qa/qa/blob/master/data/cronjobs/usertags-fixes
https://salsa.debian.org/pabs/qa/blob/master/data/cronjobs/usertags-fixes

editor data/cronjobs/usertags-fixes
mkdir tmp
rsync --timeout=60 --recursive --delete 
rsync://bugs-mirror.debian.org/bts-spool-index/user/ tmp/all/
./data/cronjobs/usertags-fixes --debug tmp

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Re: systmd-analyze security as a release goal

[Paul Wise]

On Sun, 2023-07-09 at 18:02 +0100, Luca Boccassi wrote:

> Note that we already have such a package in the archive: dbus-broker.
> It has been the default in Fedora for a long time, and it will be the
> default in Ubuntu in the future. It has been available in Debian since
> Bullseye - please help out testing it by installing it. No
> configuration is required, just installing dbus-broker and rebooting.
> It comes with some sandboxing by default (ProtectSystem=full), and I'm
> sure it could use more.

I've been using this for a while, it seems to just work. It also has
the advantage that moving both system and user dbus services into
systemd means that you can restart them with systemctl etc.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Policy consensus on transition when removing initscripts.

[Paul Wise]

On Tue, 2023-06-27 at 09:36 +0100, Luca Boccassi wrote:

> That has been implemented a long time ago, services can set
> ProtectProc= so that processes run with hidepid:
> 
> https://freedesktop.org/software/systemd/man/systemd.exec.html#ProtectProc=

Thats opt-in and for services only, there are folks who want to run
their entire system with hidepid=2, including root/user command-line
and graphical sessions, systemd doesn't support this setup. 

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Policy consensus on transition when removing initscripts.

[Paul Wise]

On Mon, 2023-06-26 at 20:04 -0400, nick black wrote:

> furthermore, this is only true when procfs is mounted with a
> nonzero hidepid, right?

I note that systemd does not support non-zero hidepid, so
procfs hidepid will always be off on systemd based systems:

https://github.com/systemd/systemd/issues/12955

At least until Linux offers a way for systemd to have access
to /proc but other programs to not have access to it.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: MBF: packages shipping init scripts without corresponding systemd units

[Paul Wise]

On Sun, 2023-06-25 at 22:31 +0100, Luca Boccassi wrote:

> Now the generator is also on the way to be deprecated and removed.
...
> Therefore I filed a bug against all affected packages ...

Will the generator be available separately for people who have packages
not in Debian that still only have init scripts, or for people who have
local init scripts installed manually or with config management tools?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: [Pkg-opencl-devel] opencl-icd virtual package(s)?

[Paul Wise]

On Mon, 2023-06-19 at 11:04 +0100, Simon McVittie wrote:

> Older Intel integrated GPUs are not very fast anyway, so this might not
> be a particularly significant loss.

Plenty fast enough to run the FOSS 3D games in Debian like 0ad though.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Default network configuration system (was Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie)

[Paul Wise]

On Tue, 2023-06-20 at 11:19 +0200, Lukas Maerdian wrote:

> Netplan allows to configure both of those tools and is already being
> used across Ubuntu and in Debian cloud-images for this purpose. All
> while keeping full flexibility to use the underlying tool's native
> config files, should Netplan's simple YAML settings not be enough for
> a given complex usecase.

Is Netplan able to parse an existing native config for each of the
tools and then output either Netplan configs or native configs for each
of the other network config tools? For example could you use Netplan to
auto-migrate from ifupdown to systemd-networkd or NetworkManager etc?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: [Pkg-opencl-devel] opencl-icd virtual package(s)?

[Paul Wise]

On Sun, 2023-06-18 at 07:28 +0100, Rebecca N. Palmer wrote:

> Hence, such a package would need to Depend on or Recommend *all* the 
> ICDs, similar to xorg-xserver-video-all.

Ah. So considering what Vincent said, something like this?

   Package: some-opencl-using-package
   Recommends: opencl-icd-all | opencl-icd
   
   Package: opencl-icd-all
   Section: metapackages
   Depends:
    beignet-opencl-icd,
    intel-opencl-icd,
    mesa-opencl-icd,
    pocl-opencl-icd,
   
   Package: opencl-icd-all-non-free
   Section: non-free/metapackages
   Depends:
    opencl-icd-all-free,
    nvidia-legacy-340xx-opencl-icd,
    nvidia-legacy-390xx-opencl-icd,
    nvidia-opencl-icd,
    nvidia-tesla-418-opencl-icd,
    nvidia-tesla-450-opencl-icd,
    nvidia-tesla-460-opencl-icd,
    nvidia-tesla-470-opencl-icd,
    nvidia-tesla-510-opencl-icd,
    nvidia-tesla-opencl-icd,

> I have proposed this before (see 31-Jan-2015 pkg-opencl-devel), but 
> never actually did it, partly because there are applications that 
> implicitly assume that all the installed ICDs work, and may fail to find 
> the usable ICD if there are unusable ones installed.  (I consider this 
> to be a bug in the application, but finding and fixing these would take 
> time.)

Since we just opened trixie for development, maybe now is the time
to do this, so that the problems can be found via bug reports?

> intel-opencl-icd = Intel integrated GPUs (replacing beignet-opencl-icd, 
> which as you note, no longer builds)

Unfortunately intel-opencl-icd can't replace beignet-opencl-icd
because the former doesn't support old hardware. At least on my
system, clinfo says only pocl and beignet have supported devices.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

opencl-icd virtual package(s)?

[Paul Wise]

[BCCed to OpenCL ICD implementation package maintainers]

I noticed that some packages have a dep on specific OpenCL ICD
packages, but don't dep on the opencl-icd virtual package(s).
Presumably any of the OpenCL ICDs work for most packages?

$ grep-aptavail --no-field-names --show-field Package --field
Depends,Recommends,Suggests --whole-pkg '(' --pattern .*opencl-icd.* --
and --not --pattern '^opencl-icd(-1\.[1]2-1)?$' ')'

In addition, I noticed that hashcat-nvidia (which presumably doesn't
need to depend on the opencl-icd virtual package) only depends on two
of the nvidia OpenCL ICD packages, while there are lots of other nvidia
OpenCL ICD packages that presumably work too.

I have attached a package list and dd-list for these issues.

Perhaps there should be a default-opencl-icd virtual package?

Perhaps lintian should flag situations where the dep isn't just
default-opencl-icd | opencl-icd? or is missing opencl-icd?

Thoughts?

PS: I noticed this because beignet-opencl-icd is RC-buggy. This is the
only OpenCL ICD implementation package I can see that supports Intel
Ivy Bridge, but it is hard to tell which other packages support this,
because some descriptions don't mention which hardware is supported.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise
hashcat
leela-zero
libhmsbeagle1v5
libreoffice-calc
libpocl2
python3-pyopencl
boinc-client-opencl
hashcat-nvidia
nvidia-opencl-dev
nvidia-libopencl1
nvidia-opencl-common
beignet-dev
intel-opencl-icd-dbgsym
mesa-opencl-icd-dbgsym
beignet-opencl-icd-dbgsym
Andreas Beckmann 
   pyopencl (U)

Andreas Tille 
   libhmsbeagle (U)

Chris Halls 
   libreoffice (U)

Daniel Echeverry 
   hashcat (U)

Debian BOINC Maintainers 
   boinc

Debian LibreOffice Maintainers 
   libreoffice

Debian Med Packaging Team 
   libhmsbeagle

Debian OpenCL Maintainers 
   pyopencl

Debian Security Tools 
   hashcat
   hashcat-meta

Gianfranco Costamagna 
   boinc (U)

Guo Yixuan (郭溢譞) 
   boinc (U)

Raphaël Hertzog 
   hashcat-meta (U)

Rene Engelhard 
   libreoffice (U)

Steffen Moeller 
   boinc (U)

Tomasz Rybak 
   pyopencl (U)

Ximin Luo 
   leela-zero


signature.asc
Description: This is a digitally signed message part

Re: Mass bug filing / call for testing: dependencies on SDL 1.2

[Paul Wise]

On Mon, 2023-06-12 at 17:24 +0100, Simon McVittie wrote:

> SDL 1.2 was superseded by SDL 2 several years ago, and no longer receives
> upstream maintenance or releases. Maintained software that uses SDL 1.2
> should be ported to SDL 2.

It was pointed out to me on IRC that some SDL 1.2 extension libraries
might not have an SDL 2 equivalent yet, or they might not be in Debian.

For example hex-a-hop can use SDL_ttf or SDL_Pango. Pango is a more
featureful text renderer, so the Debian package uses it. There is an
SDL2_Pango project available on GitHub but it isn't in Debian yet.

   https://github.com/markuskimius/SDL2_Pango

Looking through the packages, these appear to be missing:

   console kitchensink pango sge sound

Perhaps there are better equivalents for these in SDL 2 though?

Will the SDL team be packaging available SDL 2 equivalents for
the SDL 1.2 extension libraries that are in Debian?

> For legacy software that cannot be ported, SDL upstream have produced a
> replacement library, sdl12-compat, which implements the SDL 1.2 API/ABI
> by dlopening SDL 2 (and correcting for API/ABI changes). In Debian, this
> is currently available as libsdl1.2-compat-shim.

I tested hex-a-hop under GNOME Wayland. It segfaults with SDL 1.2 and
SDL_VIDEODRIVER=wayland but does not with the SDL 1.2 compat lib via
LD_PRELOAD. When using the compat lib via LD_PRELOAD, the X11 mode has
a window title bar and border but those are missing in Wayland mode.

   dpkg-architecture -c sh -c 
'LD_PRELOAD=/usr/lib/${DEB_HOST_MULTIARCH}/sdl12-compat/libSDL-1.2.so.0 
hex-a-hop'

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Bug#1037250: ITP: fangfrisch -- Update and verify unofficial Clam Anti-Virus signatures

[Paul Wise]

On Sat, 2023-06-10 at 09:50 -0400, Scott Kitterman wrote:

> It does, but I think Fangfrisch is still a useful thing to have in Debian.

I wonder if there is any tool that generates and/or contains the
appropriate ClamAV configs for popular unofficial signatures,
rather than manually downloading those signatures themselves.

Perhaps Fangfrisch should become such a tool?

Or is ClamAV upstream interested in such a tool/config?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Bug#1037250: ITP: fangfrisch -- Update and verify unofficial Clam Anti-Virus signatures

[Paul Wise]

On Fri, 2023-06-09 at 12:46 +0200, Gürkan Myczko wrote:

>    Description : Update and verify unofficial Clam Anti-Virus signatures
>   This is a sibling of the Clam Anti-Virus freshclam utility. It allows
>   downloading virus definition files that are not official ClamAV canon,
>   e.g. from Sanesecurity, URLhaus and others.

I was under the impression that ClamAV itself now has options to
download unofficial signatures, is that the case or was that removed?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Paul Wise]

On Tue, 2023-06-06 at 11:45 +0100, Simon McVittie wrote:

> 2. i386 as a multiarch foreign architecture to run legacy binaries on
>    modern x86_64 systems
>    2a. legacy native Linux i386 binaries
>    2b. legacy Windows i386 binaries via Wine (which requires a somewhat
>    complete i386 Linux library stack)

Has anyone checked what percentage of these binaries will still run
adequately after 2038 with 32-bit time_t?

Presumably any network components will be dead or require modern
protocols by then, so this could only be offline programs?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Paul Wise]

On Thu, 2023-06-08 at 08:57 +, Holger Levsen wrote:

> You mean by somehow refreshing the signatures there?

Some ideas for that are here:

https://bugs.debian.org/763419
https://bugs.debian.org/820423

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Paul Wise]

On Tue, 2023-06-06 at 11:45 +0100, Simon McVittie wrote:

> 2. i386 as a multiarch foreign architecture to run legacy binaries on
>    modern x86_64 systems

Are these use-cases likely to work with future library ABIs, or
do they need old library ABIs from when the binaries were compiled?

>    2a. legacy native Linux i386 binaries

It seems like modern Debian library ABIs will be bumped away from what
the old i386 binaries were built against, so future Debian i386 won't
be useful for this use-case anyway, except for very stable libraries,
symbol versioned libraries or libraries with multiple ABIs. That sounds
like glibc, X11 and SDL with compat libs. Anything else?

>    2b. legacy Windows i386 binaries via Wine (which requires a somewhat
>    complete i386 Linux library stack)

I guess Wine provides a translation layer between legacy 32-bit Windows
APIs/ABIs and modern Debian library ABIs, so this should still work?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Paul Wise]

On Tue, 2023-06-06 at 11:45 +0100, Simon McVittie wrote:

> 2. i386 as a multiarch foreign architecture to run legacy binaries on
>    modern x86_64 systems
>    2a. legacy native Linux i386 binaries
>    2b. legacy Windows i386 binaries via Wine (which requires a somewhat
>    complete i386 Linux library stack)

Would it be feasible to drop i386 but still support this use-case by
requiring folks to use historical releases on archive.debian.org?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Paul Wise]

On Tue, 2023-06-06 at 12:45 -0700, Steve Langasek wrote:

> since we don't really have an "i386 porting team"

The release team have registered Adrian Bunk as an i386 porter:

https://release.debian.org/testing/arch_spec.yaml

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Paul Wise]

On Tue, 2023-06-06 at 09:33 +0200, Helmut Grohne wrote:

> I've been reading the discussion around i386 a bit and found the
> direction it has taken a little unproductive.

I note that there are a number of packages available on i386 but not
available on amd64, is anyone planning on an MBF about this issue?

$ grep -h arch=.*i386 /var/lib/apt/lists/*Sources | grpe -v amd64 | grep -v -- 
-modules- | grep -v  -- -image- | grep -v -- -headers- | grep -v -- -dbg  | 
grep -v lib64 | grep -v x86-64-linux-gnu
 fp-units-i386 deb devel optional arch=i386
 fp-units-i386-3.2.2 deb devel optional arch=i386
 libc0.3 deb libs optional arch=hurd-i386 profile=!stage1
 libc0.3-dev deb libdevel optional arch=hurd-i386
 libc0.3-udeb udeb debian-installer optional arch=hurd-i386 
profile=!noudeb,!stage1
 libc0.3 deb libs optional arch=hurd-i386 profile=!stage1
 libc0.3-dev deb libdevel optional arch=hurd-i386
 libc0.3-udeb udeb debian-installer optional arch=hurd-i386 
profile=!noudeb,!stage1
 libc0.3 deb libs optional arch=hurd-i386 profile=!stage1
 libc0.3-dev deb libdevel optional arch=hurd-i386
 libc0.3-udeb udeb debian-installer optional arch=hurd-i386 
profile=!noudeb,!stage1
 sse2-support deb misc optional arch=any-i386
 netdata-core-no-sse deb net optional arch=i386
 steam deb contrib/oldlibs optional arch=i386
 steam-libs-i386 deb metapackages optional arch=i386
 etqw deb contrib/games optional arch=i386
 etqw-server deb contrib/games optional arch=i386
 quake4 deb contrib/games optional arch=i386
 quake4-server deb contrib/games optional arch=i386
 speech-dispatcher-ibmtts deb contrib/sound optional arch=i386
 adlibtracker2 deb sound optional arch=i386
 atitvout deb misc optional arch=i386,ia64
 sb16ctrl-bochs deb otherosfs optional arch=any-i386
 cmucl deb lisp optional arch=i386
 cmucl-clm deb lisp optional arch=i386
 fenix deb devel optional 
arch=arm,armel,armhf,hppa,hurd-i386,i386,kfreebsd-i386,m68k,mips,mipsel,mipsn32,mipsn32el,powerpc,s390,sh4,sparc
 fenix-plugin-mpeg deb devel optional 
arch=arm,armel,armhf,hppa,i386,kfreebsd-i386,hurd-i386,m68k,mips,mipsel,sh4,powerpc,s390,sparc
 fenix-plugins deb devel optional 
arch=arm,armel,armhf,hppa,i386,kfreebsd-i386,hurd-i386,m68k,mips,mipsel,sh4,powerpc,s390,sparc
 fenix-plugins-system deb devel optional 
arch=arm,armel,armhf,hppa,i386,kfreebsd-i386,hurd-i386,m68k,mips,mipsel,sh4,powerpc,s390,sparc
 fnfx-client deb utils optional arch=i386
 fnfxd deb utils optional arch=i386
 fp-units-i386 deb devel optional arch=i386
 fp-units-i386-3.2.2 deb devel optional arch=i386
 fwupd-i386-signed-template deb admin optional arch=i386
 fwupd-i386-signed deb admin optional arch=i386
 gatos deb misc extra arch=i386
 libgatos-dev deb libdevel extra arch=i386
 libgatos0 deb libs extra arch=i386
 libc0.3 deb libs optional arch=hurd-i386 profile=!stage1
 libc0.3-dev deb libdevel optional arch=hurd-i386
 libc0.3-udeb udeb debian-installer optional arch=hurd-i386 
profile=!noudeb,!stage1
 libc0.3 deb libs optional arch=hurd-i386 profile=!stage1
 libc0.3-dev deb libdevel optional arch=hurd-i386
 libc0.3-udeb udeb debian-installer optional arch=hurd-i386 
profile=!noudeb,!stage1
 grub-efi-ia32-signed deb admin optional arch=i386
 grub-efi-ia32-signed-template deb admin optional arch=i386
 grub-efi-ia32-signed-template deb admin optional arch=i386
 sse2-support deb misc optional arch=any-i386
 lmms-vst-server deb sound optional arch=i386
 longrun deb utils optional arch=i386
 lphdisk deb admin optional arch=i386
 mig-i686-gnu deb devel optional arch=any-i386
 netdata-core-no-sse deb net optional arch=i386
 pcsx2 deb games optional arch=i386
 pixbros deb games optional 
arch=armel,armhf,hppa,hurd-i386,i386,kfreebsd-i386,m68k,mips,mipsel,powerpc,sh4
 pixfrogger deb games optional 
arch=armel,armhf,hppa,hurd-i386,i386,kfreebsd-i386,m68k,mips,mipsel,powerpc,sh4
 shim-helpers-i386-signed-template deb admin optional arch=i386
 shim-helpers-i386-signed deb admin optional arch=i386
 sqlite3-tools deb database optional arch=linux-any,hurd-i386
 steam deb contrib/oldlibs optional arch=i386
 steam-libs-i386 deb metapackages optional arch=i386
 strace64 deb utils optional arch=i386,powerpc,s390,sparc
 syslog-ng-mod-snmp deb admin optional arch=linux-any,hurd-i386
 wine32 deb otherosfs optional arch=i386,armel,armhf
 wine32-preloader deb otherosfs optional arch=i386,armel,armhf
 wine32-tools deb libdevel optional arch=i386,armel,armhf
 xserver-xorg-video-geode deb x11 optional arch=any-i386
 zsnes deb otherosfs optional arch=any-i386
 intel-mkl-linktool deb non-free/utils optional arch=i386
 libmkl-gf deb non-free/libs optional arch=i386
 libmkl-intel deb non-free/libs optional arch=i386
 libmkl-p4 deb non-free/libs optional arch=i386
 libmkl-p4m deb non-free/libs optional arch=i386
 libmkl-p4m3 deb non-free/libs optional arch=i386
 libmkl-vml-ia deb non-free/libs optional arch=i386
 libmkl-vml-p4 deb non-free/libs optional arch=i386
 libmkl-vml-p4m deb non-free/libs optional arch=i386
 

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Paul Wise]

On Tue, 2023-06-06 at 11:45 +0100, Simon McVittie wrote:

> When considering the future of i386, a factor that we need to bear in
> mind is that there are two major use-cases for i386, with requirements
> that sometimes conflict:

There was another option mentioned earlier in the thread that could
help resolve some aspects of these conflicts; make 32-bit arches
(or just i386) support both time_t ABIs, like glibc and Linux do.

The 64-bit time_t ABI would be the default but the 32-bit time_t ABI
would be present for running old binaries that still kind of work with
the 32-bit ABIs after 2038, or under faketime when they do not.

This would be more work for Debian and a lot more work for upstreams
but would be a better outcome for the diversity of uses for 32-bit.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Paul Wise]

On Wed, 2023-05-31 at 00:51 +0200, Diederik de Haas wrote:

> I would be VERY disappointed if Debian would abandon people who do NOT have 
> the means to just buy new equipment whenever they feel like it.

There are Debian contributors who are in this position (although
perhaps not with i386 hardware) and would likely appreciate hardware
donations to upgrade to more modern hardware. At the same time we have
contributors who regularly buy, stop using and discard old hardware.

It would be great if our more fortunate contributors would be willing
to donate hardware to less fortunate contributors and could register
their available hardware on the wiki page for this. Perhaps this could
be extended to users of i386 hardware too.

https://wiki.debian.org/Hardware/Wanted#Donations

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Future of GNU/kFreeBSD in the debian-ports archive

[Paul Wise]

On Mon, 2023-05-29 at 18:11 +0200, Aurelien Jarno wrote:

> I would like to emphasize that packages will still be available on
> snapshot.d.o for anyone interested in reviving the port.

And the new port docs mention the potential procedures involved:

https://wiki.debian.org/PortsDocs/New

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Bug#1035110: ITP: drminfo -- Small utility to dump info about DRM devices

[Paul Wise]

On Sat, 2023-04-29 at 15:13 -0600, Rodrigo Siqueira wrote:

> * Package name    : drminfo
> * URL : https://gitlab.freedesktop.org/emersion/drm_info

This is already packaged in Debian as drm-info.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Upgrade package from init script to Systemd, move config folder

[Paul Wise]

On Wed, 2023-04-26 at 22:44 +0300, Boian Bonev wrote:

> OTOH it is an un-favor to move or remove it
...
> It is better to keep the init script in place.

Another option is the orphan-sysvinit-scripts package:

Description: Orphaned System-V-like init scripts
 This package provides System-V init scripts for packages whose maintainers
 have chosen to drop them from the distribution in favour of only supplying
 a systemd service file.
 .
 It will only put files into /etc/init.d/ when the relevant package is
 installed on your system.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: RFC: More C errors by default in GCC 14 (no more implicit function declarations etc.)

[Paul Wise]

On Tue, 2023-04-18 at 16:07 +0200, Florian Weimer wrote:

> TL;DR: I want to propose a GCC 14 change which will impact
> distributions, so I'd like to gather some feedback from Debian.

Is this change being made the upstream defaults?

Or will it be a distro override like the hardening flags are?

> I would appreciate some discussion on the Debian impact.

Since most of the Debian archive can be reproducibly built, it seems
like the way to gauge the impact of this change on Debian would be to
do two archive rebuilds, once without the flags and once with the
flags, then compare the two builds for each package using diffoscope.

The reproducible builds fuzzing tests get 96.2% reproducible,
this would only go up when not varying most of the fuzzed things.

https://tests.reproducible-builds.org/debian/reproducible.html

The existing documentation for Debian archive rebuilds is outdated and
deleted, but Lucas Nusbaum and others have been doing them for a while.

https://wiki.debian.org/MassRebuilds
https://wiki.debian.org/qa.debian.org/ArchiveTesting?action=recall=23

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Best way to handle config overrides in packages

[Paul Wise]

On Wed, 2023-03-29 at 15:43 +0300, Олег Михайлов wrote:

> I have a case when I need to add multiple configuration files for
> another package into the system as parts of its split config. The
> thing is, I need to remove them when I remove my package because they
> include lines which are only valid when the package is installed.  

There are several ways to do this:

1) make the file in /etc not be a conffile (not policy compliant):

debian/rules:

execute_after_dh_installdeb:
sed -i '\=^/etc/foo/=d' debian/*/DEBIAN/conffiles

2) change the file in /etc so that it works when the package is removed

3) as undef says, move the default config files to /usr

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: An email address for drive-by bug reports?

[Paul Wise]

On Mon, 2023-03-06 at 16:56 -0800, Don Armstrong wrote:

> This is my viewpoint too, and why I don't plan on implementing or
> accepting a patch to do nosubmitter unless someone can convince me
> otherwise.

The use-case presented in the thread seems reasonable to me; when you
are submitting a bug that you noticed and definitely exists (and is
easy to reproduce) but that you don't really care about.

For example some folks mass-file FTBFS or other QA bugs but don't care
about or use the individual packages. Or I might notice a typo while
looking at newly available packages or downloaded things, but if the
package isn't one I will install, I don't really care about the bug.

These bugs don't have someone we *know* definitely cares about them,
but the are still likely to affect *unknown* persons, either Debian
users or users of the upstream package on other platforms and thus
it is still reasonable that they be filed as bug reports somewhere.

Personally, I've replied to moreinfo requests on bugs for packages I
no longer use so I wouldn't use this feature, but I can see its value.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: An email address for drive-by bug reports?

[Paul Wise]

On Tue, 2023-02-28 at 18:36 +0100, Gioele Barabucci wrote:

> Should there be a standard email address for "I'm reporting this because 
> I noticed it, but I'm not interested in it"-bug reports?

Similar to the BTS noowner command, perhaps add a nosubmitter command?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: debian support veeam

[Paul Wise]

On Wed, 2023-02-22 at 12:16 +0300, Nijam Deen wrote:

> debain os will support for veeam backup using network storage

Since Veeam is proprietary software, please ask their support team:

https://www.veeam.com/support.html

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Yearless copyrights: what do people think?

[Paul Wise]

On Wed, 2023-02-22 at 09:47 -0800, Russ Allbery wrote:

> People doing this should be aware that you're probably waiving certain
> damage provisions in US copyright law should you ever sue someone in the
> US for violating the license on the Debian packaging, at least so far as I
> understand US copyright law.  (I am not a lawyer and this is not legal
> advice for your specific situation.)

Could you give some more details about this? I hadn't heard of it yet.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Consensus on closing old bugs

[Paul Wise]

On Mon, 2023-02-06 at 10:07 -0700, Sam Hartman wrote:

> It's even appropriate to ask if the bug still happens.

I'd like to see people asking that to put a slight amount of effort
into reproducing the bug, especially if there are documented or obvious
steps towards that. I recently encountered a maintainer who just asked
if it still happens and said they would close it if there was no
response, even though there was a simple path to reproducing it. So I
did that even though I don't use the software any more and I found that
the issue (but not the exact error) was still easily reproducible and
replied documenting that it was and a more exact procedure for that.
Perhaps the maintainer didn't have time for that individual bug or for
the aggregate of bugs they were triaging though.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Request to add firmware to installation images/nonfree repo

[Paul Wise]

On Sat, 2023-01-21 at 09:38 -0800, Koohyar Hasani wrote:

> install Debian (i386 arch) on a touchscreen device (Dell Venue 8 Pro)

This device is likely 64-bit, so you should use amd64 instead.

https://i.dell.com/sites/csdocuments/Shared-Content_data-Sheets_Documents/en/uk/CSG-EN-XX-ALL-Venue-8-Pro-5830-Spec-Sheet.pdf
https://ark.intel.com/content/www/us/en/ark/products/78416/intel-atom-processor-z3740d-2m-cache-up-to-1-83-ghz.html

> needs an Atheros driver 
> (https://github.com/qca/ath6kl-firmware/tree/master/ath6k/AR6004/hw3.0)

This is firmware rather than a driver. I note that it is not present in
the upstream linux-firmware git repository, see below for more info.

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/ath6k/AR6004

> installer fails to recognize the file and displays the same prompt again

I would suggest filing an installation report, but it is going to be
hard for you to do that without a keyboard.

https://www.debian.org/releases/stable/amd64/ch05s04.en.html#problem-report

Probably the right workaround for you to get the install done would be
to download the non-free installer image and repack it to include the
relevant non-free firmware files in the right place. The wiki pages
below are likely outdated but might be helpful anyway.

https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/
https://wiki.debian.org/DebianInstaller/Modify
https://wiki.debian.org/DebianInstaller/Modify/CD
https://wiki.debian.org/RepackBootableISO

> Would like to request that this firmware be added to installation
> images and/or the appropriate repository.

The process for adding firmware to Debian is to get it included in the
upstream linux-firmware git repository and then request an update to
the Debian firmware-nonfree source package.

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/README
https://www.debian.org/Bugs/Reporting

Alternatively you could package ath6kl-firmware separately and search
for a sponsor, but that is a lot of overhead to workaround the fact
that the firmware should be contributed to the linux-firmware git repo,
so that the firmware is available to Debian and also other distros. 

https://mentors.debian.net/intro-maintainers/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: automated CI on salsa to prepare MR for new upstream version

[Paul Wise]

On Fri, 2023-01-20 at 11:01 -0500, Yaroslav Halchenko wrote:

> Is there any package/tool which already does something like that on CI?
> Or may be you see some issues with such a procedure?

The Debian Janitor is already doing some of that for all packages,
for both new upstreams and new upstream commits.

https://janitor.debian.net/fresh-releases/
https://janitor.debian.net/fresh-snapshots/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Does removal of global variables from a library break C ABI?

[Paul Wise]

On Wed, 2023-01-18 at 09:33 -0500, Scott Talbert wrote:

> Thanks Russ and Peter.  I didn't find any usage of these symbols, but I 
> did sadly find a lot of bundled copies of this library in the archive.  :(

It might be worth asking the upstreams to remove the copies and
registering the existing copies with the Debian security team.

https://wiki.debian.org/EmbeddedCopies

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Help patching files in dependency package

[Paul Wise]

On Tue, 2023-01-17 at 00:55 +0100, Tobias Wackenhut wrote:

> What would be the cleanest way to package the new version with the 
> mentioned patch?

Ask the extension author to get the patch included into the upstream
rt5 core, get a release of that, then get request-tracker-5 updated.

Alternatively, drop the patch from the extension upstream and work
around the issue within the extension upstream codebase instead.

If neither of these are viable, discuss with the request-tracker-5
maintainers in Debian about including the patch in that package.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: looking for debian friendly web app technology

[Paul Wise]

On Mon, 2022-12-12 at 18:01 +0100, Andreas Josef Heil wrote:

> I wan't a highly interactive web app, A desktop app is also possible.

What program are you intending to develop?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Is an autogenerated configure shell script non-editable source

[Paul Wise]

On Sun, 2022-12-11 at 16:47 +0100, Andreas Tille wrote:

> Could you give some arguents for your feeling.

See the posts I made in this and earlier threads:

https://lists.debian.org/msgid-search/4363a2435e61bf351c7d3605136c3652118eae2f.ca...@debian.org
https://lists.debian.org/msgid-search/50184a59271c953a3f9a3c99bb193dc05e61f2aa.ca...@debian.org

> what does this mean for other packages where configure.ac is missing?

That should be decided on a case-by-case basis, since not every
configure is generated from a configure.ac and not every instance of
configure.ac being missing is due to it being withheld from view,
some instances could be due to it genuinely no longer existing,
although that is very unlikely. In the case where it genuinely doesn't
exist, I would still regard that as an important bug, to fix upstream.

> I think the fact whether a fix is simple or not does not matter for the
> severity of a bug.  Unfortunately the solution is not as simple as
> described (as I wrote in response to the said mail).

Agreed in general, in this case it did turn out to be simple though.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Is an autogenerated configure shell script non-editable source

[Paul Wise]

On Sat, 2022-12-10 at 10:28 +0100, Andreas Tille wrote:

> So far for the actual case (bug report in CC).
> 
> For the general case I somehow understand the consensus here on the list
> that a missing configure.ac can be considered a bug but the severity
> serious is not really rectified.  If I understood this correctly I would
> reset the severity to important at the beginning of next week.

Personally I feel that severity serious is the correct one,
but it sounds like the fix for the bug is quite simple:

https://lists.debian.org/msgid-search/y5rir8qidvj4r...@argenau.bebt.de


-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Is an autogenerated configure shell script non-editable source (Was: Bug#1025739: hmmer2: missing source for configure)

[Paul Wise]

On Fri, 2022-12-09 at 13:14 +0100, Andreas Tille wrote:

> Is an autogenerated configure shell script non-editable source

[Short-winded way of saying something similar to Russ]

In general I don't think such a situation meets DFSG item 2 nor the
GPL "preferred form for modification", for the reasons outlined here:

https://lists.debian.org/msgid-search/50184a59271c953a3f9a3c99bb193dc05e61f2aa.ca...@debian.org

In this case, it does seem like a DFSG violation that the source file
(configure.ac) is not available in Debian but is available upstream.

Once the configure.ac is included, the current lack of ability to
rebuild configure from it would probably cause an FTBFS bug too,
since by default debhelper will automatically run autoreconf.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: looking for debian friendly web app technology

[Paul Wise]

On Fri, 2022-12-09 at 13:12 +0100, Andreas Josef Heil wrote:

> I'd like to develop a free software web app and I wanne be the debian
> maintainer for it. It should be fully integrated to debian und freedombox.
> 
> What web technology should I use?

Personally I would suggest to focus on static site generators,
that only produce web pages that utilise progressive enhancement.
This sort of web site is more performant for users, more flexible
for hosting and easier to archive at the end of life of the website.

https://en.wikipedia.org/wiki/Static_site_generator
http://en.wikipedia.org/wiki/Progressive_enhancement

If possible I would consider making it a Linux desktop app instead.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Misc Developer News (#58)

[Paul Wise]

On Thu, 2022-12-01 at 11:42 +0100, Bastian Venthur wrote:

> I wonder if there's an easy fix here, like a new version of anacron that 
> adds a check for this particular issue, offering to fix it during 
> upgrade of the package.

It is hard to tell the difference between an affected system and one
where the admin manually disabled anacron. The only solution I can
think of would be to add 2.3-36 that forcibly re-enables anacron on
systemd systems when upgrading from 2.3-33, 2.3-34 or 2.3-35. This
might be a reasonable compromise, since only systems with those
versions could be affected and hopefully not very many sid/bookworm
systems have anacron deliberately disabled anyway. A message from the
postinst in the upgrade log and or a NEWS.Debian item could notify
admins of the fix. The workaround can be dropped after some months.

PS: I don't intend to work on this myself.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: a two cent suggestion

[Paul Wise]

On Sat, 2022-11-26 at 19:42 +0100, Patrice Duroux wrote:

> 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.

The general idea of a safe way to allow users to manage system-wide
apt packages has come up before, here is another writeup about it:

https://wiki.debian.org/UntrustedDebs

The goal of allowing all users to manage installed software seems like
something better served by app sandboxing technologies like Flatpak.
It is probably possible to convert .deb packages to Flatpak packages.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Misc Developer News (#58)

[Paul Wise]

On Fri, 2022-11-25 at 12:46 +0100, Bastian Venthur wrote:
> On 21.11.22 00:18, Paul Wise wrote:
> > anacron might be disabled if 2.3-33 was ever installed
> [...]
> I'm having trouble assessing the severity of the situation. Is more or 
> less everyone affected who uses unstable? If yes, how do we mitigate?

Every system with task-laptop, parl-desktop, ipmiutil or octavia-agent
will have anacron. There are also recommends from task-desktop,
cinnamon-core, email-reminder. The other reverse deps are alternatives.

The problematic anacron version was in unstable from 2022-07-13 to 
2022-09-04 and in testing from 2022-07-20 to 2022-09-05, as that is
~1.5 months, probably most unstable/testing anacron installs are
affected, since they probably did an upgrade during that time.

https://tracker.debian.org/pkg/anacron

> Don't think the majority of users reads the announcement mails.

The maintainer has stated that they don't intend any further actions,
so I thought it important that the issue be announced more widely.
So this was also announced via debian-user and micronews, but I suspect
you are right that not all unstable/testing users will hear about it.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019554#175
https://lists.debian.org/msgid-search/1033e8644f1658da6c8526f15de58264d7ab441d.ca...@debian.org
https://micronews.debian.org/2022/1669045429.html
https://micronews.debian.org/2022/1669126914.html

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: [DEVEL] Enable support for Renesas platform

[Paul Wise]

On Sat, 2022-11-19 at 09:06 +0200, Josua Mayer wrote:

> However note I am not part of the Debian project. 
> I don't know if joining makes sense, I don't know if the Debian
> project would like to incorporate some developers who specifically
> would collaborate to support certain vendors in Debian. 
> Just - there are things outsiders cannot do - like maintaining a
> "Blend" e.g.

You don't need to be a Debian member to contribute to Debian nor to
maintain a Debian blend, everyone is welcome to do that. All package
uploads will need to go via a sponsor or the maintainers though.
Usually a "Blend" isn't needed to support specific hardware, as the
support just goes into the existing hardware support packages like
u-boot/linux/mesa. Blends are more for specific areas of use-cases like
gaming or medicine or astronomy.

https://mentors.debian.net/intro-maintainers/
https://wiki.debian.org/DebianPureBlends

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: [DEVEL] Enable support for Renesas platform

[Paul Wise]

On Fri, 2022-11-18 at 15:20 +0700, Huỳnh Thành Hưng wrote:

> I’m from Renesas Electronics Corporation,

Welcome to Debian! In case your company would like to help out Debian,
please review our suggestions for ways that companies can contribute:

https://www.debian.org/intro/help#organizations

> My group is developing to support running Debian OS on our devices,
> also for getting ARM System Ready IR certificate.

It would be great to see Renesas contribute to the Debian ARM ports,
some resources for the ports are at the links below.

https://wiki.debian.org/Arm64Port
https://www.debian.org/ports/arm/
https://lists.debian.org/debian-arm/

This document about creating new ports should also apply to
contributing to the existing Debian ports to ARM.

https://wiki.debian.org/PortsDocs/New

> I recognize that the latest Debian 11 (Bullseye) has the kernel which
> do not enable support for Renesas platform.

Please refer to the Debian Linux kernel team documentation for how to
submit patches enabling this support in Debian unstable. I don't know
what the policy is for enabling Linux kernel config options in stable,
but it should be documented somewhere in the documentation here:

https://kernel-team.pages.debian.net/kernel-handbook/

> Can you help me to enable those configs, also support the official
> release version of Debian Live Installer ISO which support Renesas
> platform?

Debian does not yet support the ARM architecture at all with our live
images, please contact the Debian Live Team about that. Currently the
live images for the future Debian bookworm release are not being built,
but that may change before the final release.

https://wiki.debian.org/Teams/Live


-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Q: How about versions/features in bookworm?

[Paul Wise]

On Sun, 2022-11-06 at 13:58 +0900, Hideki Yamane wrote:

>  Q1:  When dpkg will support zstd compression?

reportbug says this is #892664, please review it for the status.

>  Q2:  More default hardening options? (See 
> https://developers.redhat.com/blog/2018/03/21/compiler-and-linker-flags-gcc )

Latest hardening thread appears to be here:

https://lists.debian.org/msgid-search/20221025143425.gj27...@mail.wookware.org

#1020275 against dpkg seems to be relevant here too.

>  Q3:  Does OpenSSH9.1p go into bookworm?
>  Q4:  Will Ruby3.2 go into bookworm?
>  Q5:  Will PHP8.2 go into bookworm?
>  Q6:  Will Rust1.65 go into bookworm?
>  Q7:  Will python3.11 be default in bookworm?

These sound like questions for the respective teams.

reportbug says that:

OpenSSH 9.1 new upstream bug is #1021585.

Ruby 3.1 transition bug is #1023495, none for 3.2 yet.

PHP 8.2 transition bug is #1014460.

Rust 1.63 new upstream bug is #1018859, none for 1.65 yet.

Python 3.11 transition bug is #1021984.

>  And, some upstream major version will be released during Debian's
>  release freeze. Well, how we can save those "missed release train"
>  releases? Just "ignore and wait 2 years" is easy to say, but if we
>  can introduce those in point releases with "predictable" schedule,
>  it would be better, IMHO.

The release team does not allow new upstream releases in stable, unless
they are solely stability/security fixes without behaviour changes.

>  * KDE Plasma: 5.27 - 2023-02?
>  * GNOME : 44   - 2023-03
>  * etc...

So the only option for these would be to delay the freeze dates until
these major versions are in Debian testing. If the dates are delayed,
then some other major version will be nearby, we could delay for that
too and then another and so on, eventually we will never release,
which means that Debian becomes a solely rolling distro ;D

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: official Debian kernel-free images

[Paul Wise]

On Sat, 2022-11-05 at 20:20 +0100, Patrice Duroux wrote:

> There are many projects here and there (Termux, AnLinux, etc.) that are based 
> on
> some sorts of kernel-free images of a minimal Debian system to be used through
> chroot (other Linux) or PRoot (Android) or whatever environments.

Some examples of those linked from this page:

https://wiki.debian.org/ChrootOnAndroid

> Is there something already available at Debian?

Most Debian users are currently expected to create their own installs,
using either the official Debian installer or the tools it is based on
like debootstrap. One of the reasons for this is that packages often do
system-specific configuration in their maintainer scripts (like the
systemd machine identifier or OpenSSH creating private keys), so you
can't always expect an install to be able to be duplicated safely.
There are folks working on reproducible installs though.

https://wiki.debian.org/ReproducibleInstalls

There have been five types of pre-installed systems available from the
Debian community; live images, cloud images, RPi images, minimal docker
containers, and the WSL install. The first three of those are partition
images, but the WSL installer is basically a kernel-free rootfs tarball
wrapped in a PE executable and the docker containers are similarish.
All of these have to work around the issue mentioned above.

https://www.debian.org/CD/live/
https://cloud.debian.org/images/cloud/
https://raspi.debian.net/
https://docker.debian.net/
https://wiki.debian.org/InstallingDebianOn/Microsoft/Windows/SubsystemForLinux

> Something interesting to develop?

There are lots of potential artefacts Debian could create from our
binaries rather than expecting all users to install their systems.

There are lots of different types of installs being explored outside of
Debian, including system snapshots, server containers, app containers,
appliance images, chroots/VMs under other operating systems etc.

Debian could potentially be converting our binary packages to each of
these different types of installs.

Debian users could then be directed by default to the most appropriate
install type for their use-case.

PS: a list of system/package build tools is here:

https://wiki.debian.org/SystemBuildTools

PS: a recent article about some new image based installs:

https://lwn.net/SubscriberLink/912774/b95d0bf96ebb67ab/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Port to LoongArch architecture for Debian

[Paul Wise]

On Thu, 2022-11-03 at 20:11 +0800, 张丹丹 wrote:

> Port to LoongArch architecture for Debian, now in the "Downstreaming"
> section in the port life-cycle according to
> .

I initiated this document and wrote a fair bit of it, with help from
the rest of the Debian community. If it is in any way incorrect or
unclear, that is probably my fault. Feedback and edits are welcome.

>  3、#debian-loongarch64 IRC
>  Have joined the #debian-bootstrap, #debian-ports and other Debian
> IRC channels. And have created a new #debian-loongarch64 channel.

The IRC channel (and mailing list) should be named after the
architecture family, not the port itself. I have just clarified this
in the new port documentation. In addition it sounds like from the 
discussion on debian-dpkg that the port will be named loong64.

So I suggest deregistering #debian-loongarch64 and adding #debian-loong.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: rebootstrap status update for Loongarch

[Paul Wise]

On Thu, 2022-11-03 at 18:45 +0800, Zhang Ning wrote:

> 7, m4, diffutils: need help, I don't know where is correct
> upstream[1][2], the patch[3][4] is for generated files, but Debian
> source has these files, thus how can I submit these patch to Debian
> source? these two packages don't have VCS.

It is best not to patch generated files, instead they should be
regenerated from source (and probably removed from the upstream VCS).

It is best not to patch embedded code copies, instead they should be
removed from the upstream VCS and tarballs and the system version used.

In Debian, the dh-autoreconf package is used at build time to
automatically regenerate all files generated by autotools.

In Debian, the stack-direction.m4 file is provided by gnulib, but I am
not sure if that is the canonical place this file is maintained or if
it is just yet another copy of this file..

   $ apt-file search stack-direction.m4
   gnulib: /usr/share/gnulib/m4/stack-direction.m4

For m4, it seems Santiago Vila disabled dh-autoreconf in debian/rules,
but there is no indication of the reason for that. So I suggest you
test what happens when it is enabled and if the build succeeds and has
no warnings in the log, then open a bug asking for it to be enabled.
   
For diffutils, the same issue and solution applies.

Another solution would be to ask the upstream m4 and diffutils projects to
make new releases with updated configure and stack-direction.m4 files and
then file bugs in Debian asking for package updates to the new releases.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: cruft(-ng) and dh-cruft: handling and registering of dynamic files

[Paul Wise]

On Sun, 2022-10-23 at 01:08 +0200, Alexandre Detiste wrote:

> This DebHelper works this way:
> * the "debian/cruft" list merely register the glob patterns,
> * and "debian/purge" list also an "rm -rf" stanza in postrm/purge.
> 
> As a bonus there's now also a new "cpigs" command, working akin to
> "dpigs" from Debian Goodies to list the biggest volatile data producers.

Thank you for your work on this, being able to register files generated
at install time by maintainer scripts or even at runtime by system
maintainence tools to particular packages is a very useful feature for
keeping all the files on a system more easily managed.

Potentially it could also prompt users before removing packages that
have registered data that won't be removed on purge, for example if a
package creates at the sysadmin's request a dir in /srv to host a
website, removing the package could warn about the directory. Or
removing postgres with databases present could warn about those.

I do worry about users removing files that they don't understand, based
on feedback by cpigs/cruft-ng, but they do that already so... :)

> The plan now is to have a new option that dumps the whole
> matching result database as .json with individual file size
> for jq consumption or in my case Jupyter;
> this instead of implementing older requests (#291823 #487458 #527285).

An ncdu or mc style interface (or plugins for those) to view cruft on a
system sounds very useful in addition to the data export.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: RFH: Packaging Intel's userspace tools for Data Streaming Accelerator

[Paul Wise]

On Fri, 2022-10-21 at 12:48 -0500, Gunnar Wolf wrote:

> The purpose of this mail is to help find interested people in Debian
> that can help review and sponsor uploads of the userspace tools; the
> kernel-side modules have been enabled as of bug #1021337 (thanks for
> the quick reply!)

PS: once the userspace tools reach Debian, please add them here:

https://wiki.debian.org/DebianKernel/UserspaceTools

> It is quite probable Miguel and Jair can be the package maintainers,
> and I'd be more than happy to welcome them in Debian, but they will
> surely need some guidance to get the package (for which the work is
> already started¹) in a state that can be uploaded to Debian.

I think it is excellent that Intel employees are considering getting
involved in Debian. Our usual docs for new maintainers are here:

https://mentors.debian.net/intro-maintainers/

The basic procedure is to make a new package, polish it up with
lintian, piuparts, autopkgtest and other automated checking tools,
upload it to the mentors site and file a request for sponsor (RFS).

https://mentors.debian.net/sponsors/rfs-howto/

The Debian glossary may help with any unfamiliar jargon:

https://wiki.debian.org/Glossary

In case Intel are interested in supporting Debian more generally we
have some info on our website, inc about partnerships and sponsorship.

https://www.debian.org/intro/help#organizations
https://www.debconf.org/sponsors/
https://www.debian.org/partners/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Submitting Patches

[Paul Wise]

On Fri, 2022-10-21 at 16:28 +1100, Phillip Smith wrote:

> Where/How do I submit patches for Debian packages?

It completely depends on the preferences of the team or person who will
be reviewing the patches. Most teams and package maintainers accept
changes via Salsa merge requests, but, as mentioned by Julien, patches
attached to bug reports are usually also acceptable.

> I have a small improvement for the iptables-persistent package;
> I cloned the repo and made a patch (attached) on a branch, but it
> appears the public aren't welcome to create accounts on
> salsa.debian.org in order to create merge requests?

The public are welcome to create accounts on Salsa, but due to large
numbers of spammers signing up for accounts and due to the Salsa admins
being part-time volunteers, there may be some delay in the account
approval process, so patience is helpful.

> Are patches even welcome?

Debian always welcomes patches, although usually it is a better idea to
submit patches upstream first, so that they benefit all users instead
of just Debian users. When upstream isn't responsive the Debian
maintainer can be a patch recipient of last resort though.

Of course since iptables-persistent is a native Debian package,
the upstream in this case is the package Debian itself.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: epoch for tss2 package

[Paul Wise]

On Wed, 2022-10-19 at 23:04 -0700, Debora Velarde Babb wrote:

> Initially I attempted to create the package with the new name ibmtss.
> There was some discussion on debian-mentors list and the response was
> that I should NOT change the name to ibmtss and instructed to instead
> use an epoch number.

Personally I would rename the package to ibmtss. Renaming represents
one-time migration pain for yourself, the Debian ftp-masters and all of
the existing package users, but not renaming represents confusion for
every person looking for the new upstream name but not finding it in
Debian if we didn't follow the upstream renaming, potentially this
could even lead to someone packaging it as ibmtss too. 

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Sunsetting sso.debian.org

[Paul Wise]

On Mon, 2022-10-17 at 21:28 +0200, Joerg Jaspert wrote:

> Salsa should be there for git (related) things.
> NOT as an identity/login provider for Debian

There are already Debian services that do not offer any other option
for auth than Salsa.

Personally I do not like GitLab, Salsa nor OIDC/Oauth2, vastly prefer
TLS client certs and thus usually never use Salsa authed services.

Arguably it is probably a good thing to use Salsa, since it means
services can have an auth option for all of the Debian contributors,
including those who are not currently DDs or DMs.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Sunsetting sso.debian.org

[Paul Wise]

On Sun, 2022-10-16 at 16:21 -0700, Sean Whitton wrote:

> At the present time, I believe this will break DDs logging into
> tracker.debian.org.  I recently had to mess around with client
> certificates in order to login there and subscribe to a new package.

It will still be possible to manage DPT subscriptions via email:

https://www.debian.org/doc/manuals/developers-reference/resources.en.html#the-debian-package-tracker
https://qa.pages.debian.net/distro-tracker/usage/messages.html#subscribing-to-a-package

In addition it will still be possible to subscribe via the web using
the form at the bottom left of the pages on the old PTS, IIRC this will
send mail to modify the DPT subscriptions. 

https://packages.qa.debian.org/z/zlib.html

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Firmware GR result - what happens next?

[Paul Wise]

On Thu, 2022-10-13 at 17:35 +0200, Julien Cristau wrote:

> I'd prefer if we could make things work vs making things fail,
> however loudly.

There seem to be a few ways to deal with this transition:

1. Document it in the release notes and let users handle it. This means
lots of users won't get security updates for firmware (which are mostly
only issued for x86 CPU microcode), since lots of folks won't read the
release notes. This also means lots of support requests when users
can't find the firmware package they wanted.

2. Add some code somewhere to automatically modify the apt sources,
somehow ensure that code is run by all Debian users and hope that other
automated processes (like ansible/puppet) don't overwrite those changes
and hope that users aren't storing apt sources config in packages,
which would mean conffile prompts after the modification happens.

3. Add some code to apt to download non-free-firmware when non-free is
available in the sources and the downloaded Release files. This would
solve the issue for Debian and all other derivatives too, if they
decide to add a new non-free-firmware component too. This might not
be accepted by apt developers as it is kind of a hack to special-case
Debian component semantics in apt, although maybe a component mapping
config option would be accepted. This might result in extra Debian
support requests when users notice the new component in `apt update`. 
This might not work for users of tools not based on apt, like cupt?
This wouldn't result in users without non-free getting any non-free
firmware though, which maybe we want since it is the new default?

4. Keep all non-free-firmware packages in non-free too. This would be
backwards compatible, but may expose bugs in dak, debian-cd, apt and
other tools, so IIRC this has been vetoed by the archive and CD teams.
This also wouldn't result in users without non-free getting any of the
non-free firmware, which maybe we want since it is the new default?

Personally I would choose 4 first, I expect any potential issues could
be easily fixed before the freeze. Next I would choose 3. Next I would
choose 1 because I think /etc belongs to the sysadmin not packages.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Bug#903158: Multi-Arch: foreign and -dbgsym: too weak dependency

[Paul Wise]

On Sun, 2022-10-09 at 18:54 +0200, David Kalnischkies wrote:

> I suppose we could use 'foo-dbgsym Enhances foo:arch (= version)'.

That sounds interesting and would be nice generally, however...

> On a sidenote: What the Depends ensures which the Enhances doesn't is
> that they are upgraded in lockstep. As in, if for some reason foo (or
> foo-dbgsym) have their version appear at different points in the archive
> apt would hold back on a Depends while with Enhances this dependency
> would be broken and hence auto-remove kicks in.

For the rolling Debian suites, the main and dbgsym archives are often
out of sync, the dbgsym packages updates sometimes appear first and
sometimes second. Keeping foo/foo-dbgsym in sync is strongly needed
since old or new dbgsym has zero value for debugging and just because
the archives are currently not in sync, that doesn't mean one wants out
of sync dbgsyms to be removed.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Bug#903158: Multi-Arch: foreign and -dbgsym: too weak dependency

[Paul Wise]

On Sat, 2022-10-08 at 11:00 +0200, Niels Thykier wrote:

>   2) We now have a debuginfod service, so you do not even have to install
>  dbgsym packages anymore (if you configure gdb to use it).  For the
>  cases where you do install the dbgsym, you still have to manage
>  inter-source dbgsym dependencies manually.

The debuginfod service is not protected by the archive keys and it
isn't available offline, so I currently prefer to use debian-goodies'
`find-dbgsym-packages --install` command. Since I don't have any
foreign architectures enabled, I can't be affected by the issue with
not strict enough dependencies though. 

Removing all dependencies would mean that removing an obsolete library
package would no longer also remove the dbgsym package and a lot of
obsolete library packages would accumulate without manual action and
it could be time consuming to track down no longer used dbgsym packages.

Keeping the dependencies does also block some use-cases, some of that
can be worked around using debuginfod, with the usual downsides.

I have often wanted a different kind of relationship between packages
and their dbgsym packages than mere Depends. Currently when a dbgsym is
installed it keeps the library package installed even after it is no
longer used and both should be auto-removed. 

So I believe the optimal thing to do would be stricter depends for now
and later if apt adds some kind of special handling for dbgsym, then
all of the Depends could be dropped to enable more use-cases.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Q: uscan with GitHub

[Paul Wise]

On Mon, 2022-09-19 at 18:12 +0200, Samuel Thibault wrote:

> The problem is that the tags page only contains snapshots of the
> repository, and not an autoconf-ed tarball.

I think that is an advantage, because then you can be sure that you can
rebuild the autotools generated files from source during the build.

The only reason I would use the autotools tarball is when it is signed.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Q: uscan with GitHub

[Paul Wise]

On Mon, 2022-09-19 at 20:50 +0900, Hideki Yamane wrote:

> Recent changes in GitHub releases pages, I cannot check upstream
> version with uscan. How do you deal with it?

If you are using the automatically generated tarballs, then
just switching to the uscan git mode seems like the way to go.

For signed tarballs and other GitHub release artefacts, it sounds like
uscan will need to use the GitHub API or Debian QA fakeupstream.cgi
will need to add a redirector based on the GitHub API.

https://salsa.debian.org/qa/qa/-/blob/master/cgi-bin/fakeupstream.cgi
https://qa.debian.org/cgi-bin/fakeupstream.cgi

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part