Re: Making Debian available

[Emanuele Rocca]

On 15/01 03:30, Jeremy Stanley wrote:
> This boils down to a debate over whether the Debian community values
> convenience over ideals.

This is not about convenience, it's about being able to install Debian
on real hardware or not. Without firmware, the installer does not do the
only thing it is supposed to do, namely installing the OS.

Also, this is not in any way a trade-off between installing Debian and
Free Firmware. In a trade-off between A and B, if you decrease A then B
increases. If you want an ice cream and you have a coin in your pocket,
you must choose whether you want to give away the coin to get the
ice cream, or keep the coin and walk away without ice cream.

Here we are making the installer useless without getting Free Firmware,
ie: we don't get the ice cream, and throw away the coin.

Re: Making Debian available

[SDA]

On Thu, Jan 21, 2021 at 03:12:58PM -0500, Calum McConnell wrote:
> Any way you can give us more info about that error? some log files, or the
> exact torrent file you're seeding with (ie, upload the file itself)?
> Calum

It appears to be on my end - I tried the same torrent files on a workstation 
with transmission and they worked as expected. I'll have to troubleshoot on 
my end.

Excuse the noise, deluged doesn't seem to log much information, so as of yet 
still unsure what has changed on the seedbox. Strange that the other 
torrents are working fine. Seems to something specific to Debian tracker 
file that this version of deluged doesn't like. Not that its the file, but 
more than likely the older version of deluged and/or rasterbar that I'm 
using.

Cheers.

Re: About lintian

[Norbert Preining]

Hi Felix,

thanks for your email, and no worry about sending it late, we are all
volunteers.

> Due to the number of messages already posted in this thread, I will
> respond—with the best of ability—to each message separately.

Thanks, I will only go into answer those items that I find here.

> Thank you also for being cautious about people's emotions. I endure a
> fair amount of abuse for working on Lintian and am likewise reluctant
> to discuss it in such a broad forum, but here we are.

Well, because lintian is such a core part of Debian (think auto-reject
on ftp-master ..) that many people have strong feelings about it.

> While we often change tag names (or combine tags etc.), the majority
> of the renames people talk about seems to stem from two bug reports by

I cannot quantify it now, but I have been working on Qt/KDE which is a
huge set of packages, and in the last months we had to change/update
lintian overrides quite often. If you want, I can check our git repos
for the respective commits and summarize the changes we had.

> I am totally open to suggestions, although I think that being
> "Lintian-clean" is overrated. My goal is not to point out faults like

Might be that *you* think it is overrated, but at least in our group we
are striving for making packages lintian clean, and putting the
necessary tags into lintian.overrides. I think this is good practice,
because putting relevant stuff into lintian.overrides allows us to
document *why* we override it, and not simply ignore it.

> I am also not sure that a tag rename by itself could ever trigger new
> tags, i.e taint a package that was previously "Lintian-clean".

It can, due to the lintian override tag not matching anymore. Some of
the tags don't have their old names accepted, too, and some have changed
the format of the lintian message, that means that suddently there are
- warning about unmatched overrides
- new warnings/errors

That is what I personally would like *not* to see at least till after
release.

> With tongue in cheek, I may one day add a voting system for the
> funniest, or perhaps the most bogus, override comment.

All for it!

> In any event, the Lintian job on Salsa broke when the (privileged)

Honestly, I don't use the lintian on Salsa, and the whole Salsa CI seems
currently broken at least in Qt/KDE Team packages. I always get failure
messages, but don't have the time nor energy to investigate this.

So for me, lintian is what is run:
- after gbp buildpackage (automatically)
- after building binary packages in clean chroot
- before signing and uploading a package
So all *my* usage is on my computer, and I care far less on web
interface, CI integration, etc. But I am more than happy to see all the
features for those who want to use them.

Again, thanks for your detailed answers and all the best

Norbert

--
PREINING Norbert  https://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Re: About lintian

[Pierre-Elliott Bécue]

Le 21 janvier 2021 23:51:55 GMT+01:00, Felix Lechner 
 a écrit :
>Hi Pierre-Elliott,
>
>On Mon, Jan 18, 2021 at 5:00 AM Pierre-Elliott Bécue  wrote:
>>
>> As I said on that time, I'd be glad to provide help and
>> support should Felix feel the need for some.
>
>I do not recall our most recent exchanges as quite so positive, but I
>would be happy to read you into some of the new software (off-list,
>please).
>
>Kind regards
>Felix Lechner
>

I think some of our misunderstanding were due to language barrier issues, AKA 
my not-so-good english.

In any case my motivation remains that Lintian is a great tool for QA and I 
enjoy QA.

Feel free to poke me via IRC or mail at your preference. Maybe I'll have some 
ideas to offer for you DB ingestion time issue, or useful contributions on 
other parts. (excpet node, I'm quite bad at JS) 

Cheers !
--
Pierre-Elliott Bécue
From my phone

Work-needing packages report for Jan 22, 2021

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 1189 (new: 9)
Total number of packages offered up for adoption: 217 (new: 11)
Total number of packages requested help for: 63 (new: 0)

Please refer to https://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   dacs (#980163), orphaned 6 days ago
 Description: Distributed Access Control System (DACS)
 Reverse Depends: dacs libapache2-mod-dacs libdacs-dev
 Installations reported by Popcon: 18
 Bug Report URL: https://bugs.debian.org/980163

   dh-linktree (#980413), orphaned 3 days ago
 Description: Create symlink trees within a Debian package
 Installations reported by Popcon: 111
 Bug Report URL: https://bugs.debian.org/980413

   giflib (#980412), orphaned 3 days ago
 Description: library for GIF images (utilities)
 Reverse Depends: boats driftnet ecere-dev emacs-gtk emacs-lucid
   exactimage fbi fenix fim fuzzyocr (61 more omitted)
 Installations reported by Popcon: 97910
 Bug Report URL: https://bugs.debian.org/980412

   glbsp (#980411), orphaned 3 days ago
 Description: node builder library for OpenGL-based Doom-style games
   (headers)
 Reverse Depends: glbsp libglbsp-dev
 Installations reported by Popcon: 29
 Bug Report URL: https://bugs.debian.org/980411

   mercurial-crecord (#980409), orphaned 3 days ago
 Description: Mercurial crecord extension (transitional package)
 Installations reported by Popcon: 21
 Bug Report URL: https://bugs.debian.org/980409

   oxygencursors (#980410), orphaned 3 days ago
 Description: Oxygen mouse cursor theme
 Installations reported by Popcon: 3052
 Bug Report URL: https://bugs.debian.org/980410

   python-chameleon (#980408), orphaned 3 days ago
 Description: XML-based template compiler
 Reverse Depends: python3-pyramid-chameleon
 Installations reported by Popcon: 60
 Bug Report URL: https://bugs.debian.org/980408

   transaction (#980407), orphaned 3 days ago
 Description: Transaction management for Python
 Reverse Depends: python3-pyramid-tm python3-repoze.tm2
 Installations reported by Popcon: 18
 Bug Report URL: https://bugs.debian.org/980407

   zc.buildout (#980405), orphaned 3 days ago
 Description: system for managing development buildouts
 Installations reported by Popcon: 1
 Bug Report URL: https://bugs.debian.org/980405

1180 older packages have been omitted from this listing, see
https://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   cyrus-imspd (#980150), offered 6 days ago
 Description: Internet Message Support Protocol daemon
 Installations reported by Popcon: 11
 Bug Report URL: https://bugs.debian.org/980150

   ddccontrol (#980404), offered 3 days ago
 Description: program to control monitor parameters
 Reverse Depends: ddccontrol gddccontrol libddccontrol-dev
 Installations reported by Popcon: 557
 Bug Report URL: https://bugs.debian.org/980404

   ddccontrol-db (#980399), offered 3 days ago
 Description: monitor database for ddccontrol
 Reverse Depends: ddccontrol
 Installations reported by Popcon: 560
 Bug Report URL: https://bugs.debian.org/980399

   flask-babelex (#980142), offered 6 days ago
 Description: Adds i18n/l10n support to Flask applications
 Reverse Depends: python3-flask-security
 Installations reported by Popcon: 977
 Bug Report URL: https://bugs.debian.org/980142

   flask-paranoid (#980141), offered 6 days ago
 Installations reported by Popcon: 939
 Bug Report URL: https://bugs.debian.org/980141

   libcddb2 (#980305), offered 4 days ago
 Reverse Depends: asunder audacious-plugins cantata cmus
   gmerlin-plugins-base libcddb2-dev pragha qmmp simpleburn
   vlc-plugin-base
 Bug Report URL: https://bugs.debian.org/980305

   libzstd1 (#980477), offered 2 days ago
 Description: fast lossless compression algorithm
 Reverse Depends: avfs badger bcachefs-tools borgbackup btrfs-progs
   burrow cadvisor casync ccache clickhouse-common (94 more omitted)
 Bug Report URL: https://bugs.debian.org/980477

   peframe (#980159), offered 6 days ago
 Description: open source tool to perform static analysis on PE
   malware
 Installations reported by Popcon: 6
 Bug Report URL: https://bugs.debian.org/980159

   restrictedpython (#980149), offered 6 days ago
 Description: Restricted execution environment for Python 3
 Reverse Depends: omnidb-common
 Installations reported by Popcon: 21
 Bug Report URL: https://bugs.debian.org/980149

   

Re: About lintian

[Felix Lechner]

Hi Antonio,

On Tue, Jan 19, 2021 at 4:43 AM Antonio Terceiro  wrote:
>
> My hope is that this, and other use cases, could be enabled by
> collaborating on existing infrastructure, instead of creating yet
> another one.

I totally agree with you. I would like to spend some time looking at
your code, if you have time to point me in the right direction.
Perhaps planned improvements to the Lintian runner are better
implemented in your code base. Thanks!

Kind regards
Felix Lechner

Re: About lintian

[Felix Lechner]

Hi Raphaël,

On Tue, Jan 19, 2021 at 3:27 AM Raphael Hertzog  wrote:
>
> From my (relatively remote) point of view, ci.debian.net seems really
> very basic in terms of features related to scheduling of jobs.

Inspired by an early peek into your own ideas of a codenamed piece of
vaporware I wrote what I think is a generalized runner. I do not know
how it compares to the CI infrastructure, although it is probably even
simpler.

Kind regards
Felix Lechner

Re: About lintian

[Felix Lechner]

Hi Pierre-Elliott,

On Mon, Jan 18, 2021 at 5:00 AM Pierre-Elliott Bécue  wrote:
>
> As I said on that time, I'd be glad to provide help and
> support should Felix feel the need for some.

I do not recall our most recent exchanges as quite so positive, but I
would be happy to read you into some of the new software (off-list,
please).

Kind regards
Felix Lechner

Re: About lintian

[Felix Lechner]

Hi Lucas,

On Mon, Jan 18, 2021 at 2:31 AM Lucas Nussbaum  wrote:
>
> I agree that a service that provides an overview of the status regarding
> lintian for the whole archive would be useful (for example, to identify
> packages that need some area of work inside a team).

This functionality is not going away. I had to address a series of
issues to make the runners stable. Lintian itself no longer crashes or
stalls for any package in unstable or experimental. (I did not try
other "releases".)

The runners, which allocate and manage resources while tags are
generated, also no longer crash and can now operate without blacklists
(although some packages like Firefox with 300,000 source files consume
extraordinary resources to generate tags that are unlikely to be
fixed).

For tag reporting, I had to address a series of encoding issues.
Lintian now emits JSON.

The website is actually relatively simple when it comes to replacing
the old lintian.d.o. The use of dynamic Javascript backed by a
database, however, opens up the use of many more features than the old
website, which used Perl to generate static HTML for about 40,000
pages. The new website also deals automatically with incremental
changes in the database, which I think is a huge advantage.

> If there's a lack of interest/motivation to redesign lintian.d.o as a
> standalone service, maybe a simpler architecture to explore would be to
> build it on top of UDD

Having just designed a Postgres database for this purpose, I do not
believe UDD has the proper table layout but you are welcome to try.

Kind regards
Felix Lechner

Re: About lintian

[Felix Lechner]

Hi Norbert,

First of all, please accept my apologies for responding late. I
subscribe to d-d but filter lists for later perusal. Thanks to Lucas
Nussbaum for pointing me here!

Due to the number of messages already posted in this thread, I will
respond—with the best of ability—to each message separately.

Thank you also for being cautious about people's emotions. I endure a
fair amount of abuse for working on Lintian and am likewise reluctant
to discuss it in such a broad forum, but here we are.

David Bremner once said that people should remember Lintian isn't
their boss. (David, please correct me if I fumbled that.) My goal is
for Lintian to provide friendly packaging advice for the benefit of
maintainers. Nothing more and nothing less.

On Sun, Jan 17, 2021 at 5:02 AM Norbert Preining  wrote:
>
> In the past year, many changes in lintian tag names occurred, along with some
> tag removals.

While we often change tag names (or combine tags etc.), the majority
of the renames people talk about seems to stem from two bug reports by
third parties asking that we make tag names more consistent (bug
numbers are available, if needed). As I remember, I studied the
related checks—some of which were quite dense or antique—for ten days
before settling on new names. Alas, that effort earned mostly anger
and, in one case, even disapproval from a bug filer.

> While it seems quite normal for lintian as a tool to evolve a
> lot, with the upcoming freeze, do you see a reasonable time frame during which
> these kind of changes could be postponed to help people having lintian-clean
> packages remain lintian-clean till after release?

I am totally open to suggestions, although I think that being
"Lintian-clean" is overrated. My goal is not to point out faults like
a heavenly prosecutor but to help people avoid common problems. Tag
names do not make a difference in that regard.

I am also not sure that a tag rename by itself could ever trigger new
tags, i.e taint a package that was previously "Lintian-clean".

> On the infrastructure side, you mentioned on #debian-qa that in your
> opinion, lintian is best run in a CI pipeline instead of on the
> lintian.d.o service. While this is certainly true, do you plan to keep
> the functionality on your rework of lintian.d.o?

Yes, in fact the goal for the new lintian.d.o is much broader (and
hopefully not too ambitious). The website should ultimately allow
detailed research into which packages trigger particular tags
(including various filtering functions and automatic notifications).
The website should also offer ways to flag ineffective tags, i.e.
those with a high proportion of false positives based on the
prevalence of overrides.

With tongue in cheek, I may one day add a voting system for the
funniest, or perhaps the most bogus, override comment.

People should also be able to flag false positives with a few clicks
(perhaps triggering a bug report) or generate overrides for their
packages for download.

My remark about Salsa CI probably applied more to maintainers of
single packages, and less to people concerned with quality assurance
of large package families such as yourself.

In any event, the Lintian job on Salsa broke when the (privileged)
runners were upgraded to Debian 10. Something in Lintian triggers
apparmor. Despite the prominence of the failures I have been reluctant
to explore them. I am not sure that the Salsa and the Salsa CI teams,
at whose juncture the apparmor process resides, have the best
relationship. On top of that, my principal collaborator on Salsa CI,
Iñaki Malerba, is busy with a new job.

> As part of this rework and the ongoing development, you said you have plans
> to set up a test version of the Lintian web application on non-Debian
> infrastructure.

I have a Node.js version that almost replaces the old lintian.d.o. My
primary challenge is the amount of data Lintian now generates.
Uploading results to Postgres via bulk JSON takes several hours.

The domain lintian.debian.net resolves to a non-Debian server with my
experimental version, but it's a work-in-progress and the data is not
current. I could probably finish it in a week if I had the time.

> The
> intention of this mail is to understand the current Lintian's maintainers POV
> on what Lintian is and should be

I do not think I answered that question except for my favorite
tagline: "Lintian provides friendly packaging advice for the benefit
of maintainers."

Thank you for your interest in Lintian!

Kind regards,
Felix Lechner

Bug#980771: ITP: luma.led-matrix -- library interfacing LED matrix displays

[Anton Gladky]

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

* Package name: luma.led-matrix
  Version : 1.5.0
  Upstream Author : Richard Hull and contributors
* URL : https://github.com/rm-hull/luma.led_matrix
* License : MIT
  Programming Lang: Python
  Description : library interfacing LED matrix displays

Library interfacing LED matrix displays with the MAX7219 driver
(using SPI), WS2812 (NeoPixels, inc Pimoroni Unicorn pHat/Hat
and Unicorn Hat HD) and APA102 (DotStar) on the Raspberry Pi
and other Linux-based single board computers - it providesxi
a Pillow-compatible drawing canvas, and other functionality to support:
 * multiple cascaded devices
 * LED matrix, seven-segment and NeoPixel variants
 * scrolling/panning capability,
 * terminal-style printing,
 * state management,
 * dithering to monochrome,
 * pygame emulator

Re: Making Debian available

[Calum McConnell]

On Thu, 2021-01-21 at 11:18 -0700, Lou Poppler wrote:
> On Thu, 2021-01-21 at 11:06 -0500, SDA wrote:
> > On Thu, Jan 21, 2021 at 08:55:10AM -0700, Lou Poppler wrote:
> > > > 
> > > > Got them from this url: 
> > > >  
> > > > https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/10.7.0-live+nonfree/amd64/bt-hybrid/
> > > > 
> > > > I'm using a VPN, surely that wouldn't make a difference?
> > > > 
> > > > > Please keep the discussion in the mailing list -- other list
> > > > > members may offer
> > > > > answers that do not occur to me.  Other list members will be the
> > > > > ones with the
> > > > > power to fix any problem that is found with the tracker or home
> > > > > seeders.
> > > > 
> > > > I would have keep it on the list if your reply-to-list was
> > > > functioning. Mutt 
> > > > said no list found when I attempted to respond to list from your
> > > > email. Not 
> > > > my 1st rodeo with using mutt on Debian Lists.
> > > > 
> > > > Again, everything else in my torrent client/server works, just
> > > > this tracker 
> > > > aint.
> > > 
> > > I can tell you that this machine I type on is seeding one of those
> > > right now.
> > > 
> > > debian-live-10.7.0-amd64-gnome+nonfree.iso
> > > 
> > > The status summary tells me this:
> > > http://bttracker.debian.org:6969
> > > Got a list of 38 peers 1 minute ago
> > > Asking for more peers in 13 minutes
> > > Tracker had 45 seeders and one leechers 59 seconds ago
> > > Asking for peer counts in 29 minutes.
> > > 
> > > Can you tell us more about your software?  What BT client/server are
> > > you using?
> > > What does your software tell you about debian's tracker and/or
> > > torrents --
> > > is there some message or status, or just "doesn't work" ?  It is not
> > > correct
> > > that there is not one seeder, at least on the one I am personally
> > > seeding.
> > 
> > Sure, I was seeding the i386 torrents for some time, and I just
> > noticed they 
> > aren't seeding either. I have over several hundred that are seeding
> > just 
> > fine on a deluged server. What I get is an error for this tracker
> > only: 
> > 'Error: Invalid argument'. This is the current version of deluged, it
> > runs 
> > 24/7

Any way you can give us more info about that error? some log files, or the
exact torrent file you're seeding with (ie, upload the file itself)?
Calum


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

Re: Making Debian available

[Lou Poppler]

On Thu, 2021-01-21 at 11:06 -0500, SDA wrote:
> On Thu, Jan 21, 2021 at 08:55:10AM -0700, Lou Poppler wrote:
> > > 
> > > Got them from this url: 
> > > https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/10.7.0-live+nonfree/amd64/bt-hybrid/
> > > 
> > > I'm using a VPN, surely that wouldn't make a difference?
> > > 
> > > > Please keep the discussion in the mailing list -- other list members 
> > > > may offer
> > > > answers that do not occur to me.  Other list members will be the ones 
> > > > with the
> > > > power to fix any problem that is found with the tracker or home seeders.
> > > 
> > > I would have keep it on the list if your reply-to-list was functioning. 
> > > Mutt 
> > > said no list found when I attempted to respond to list from your email. 
> > > Not 
> > > my 1st rodeo with using mutt on Debian Lists.
> > > 
> > > Again, everything else in my torrent client/server works, just this 
> > > tracker 
> > > aint.
> > 
> > I can tell you that this machine I type on is seeding one of those right 
> > now.
> > 
> > debian-live-10.7.0-amd64-gnome+nonfree.iso
> > 
> > The status summary tells me this:
> > http://bttracker.debian.org:6969
> > Got a list of 38 peers 1 minute ago
> > Asking for more peers in 13 minutes
> > Tracker had 45 seeders and one leechers 59 seconds ago
> > Asking for peer counts in 29 minutes.
> > 
> > Can you tell us more about your software?  What BT client/server are you 
> > using?
> > What does your software tell you about debian's tracker and/or torrents --
> > is there some message or status, or just "doesn't work" ?  It is not correct
> > that there is not one seeder, at least on the one I am personally seeding.
> 
> Sure, I was seeding the i386 torrents for some time, and I just noticed they 
> aren't seeding either. I have over several hundred that are seeding just 
> fine on a deluged server. What I get is an error for this tracker only: 
> 'Error: Invalid argument'. This is the current version of deluged, it runs 
> 24/7

I don't know what to tell you.
I am [again, like every time] also copying this reply to the list, so they can
see your latest answer.  Maybe someone there can guess what you should do.
Good luck.

Bug#980753: ITP: pampi -- Presentations with Markdown, Pandoc, Impress

[Georges Khaznadar]

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

* Package name: pampi
  Version : 1.0
  Upstream Author : pascal.pe...@free.fr
* URL : https://gitlab.com/edleh/pampi
* License : GPL-3+
  Programming Lang: Python
  Description : Presentations with Markdown, Pandoc, Impress

 PAMPI is a free software to create presentations easily.
 .
 presentations are written in text files,
   - so they can be modified easily
   - the files syntax (Markdown) is easily learnt
   - many examples of usable Markdown are available at
 https://enacit1.epfl.ch/markdown-pandoc
  They are converted to web pages (HTML files)
   - one can view them with a browser
   - one can publish them online, grab them on a USB stick, etc.
 In PAMPI's interface, the Markdown file is displaied in the left
 side and on can view the result in the right side.
 .
 Every step of a presentation can be located in any position in a 3D
 space
   - one provides its coordinates
   - one can specify its zoom factor
   - one can specify rotations
 Maths can be authored with KaTeX.
 .
 Here are many examples: https://en.wikibooks.org/wiki/LaTeX/Mathematics.

Re: RFC: raising ca-certificates package Priority to standard or important

[Antonio Terceiro]

On Thu, Jan 21, 2021 at 03:10:47PM +0100, Julien Cristau wrote:
> And which of standard or important made most sense (AIUI, standard
> means "installed by default in d-i" and important means "installed by
> default in debootstrap").

wget is already Priority: standard and recommends ca-certificates, so it
seems to me that making it standard would be a noop in practice for most
of the systems installed by d-i.

On the other hand, all cases that I remember seeing a problem caused by
missing ca-certificates was in systems not installed by d-i, such as
containers, vm images, etc. Based on that, I would make it important.


signature.asc
Description: PGP signature

Re: RFC: raising ca-certificates package Priority to standard or important

[Russ Allbery]

Marco d'Itri  writes:
> On Jan 21, Julien Cristau  wrote:

>> So I'd like to raise the priority of ca-certificates from optional to
>> at least standard, as a signal that it should be installed on

> Good idea: I think that "standard" is appropriate.

I agree.

-- 
Russ Allbery (r...@debian.org)  

Re: Release status of i386 for Bullseye and long term support for 3 years?

[Henrique de Moraes Holschuh]

On Sat, Dec 12, 2020, at 13:09, Adrian Bunk wrote:
> 3. Computers that do support MMX and SSE2, but do not support 64bit.

The "Centrino" Pentium-M that you can find on a reasonably lot of still-working 
ThinkPads (the T4x series and similar X/R series of the time), for example.  
Note that this is "family 6" Pentium-M processors, not "family 15" Pentium4-M.

I wouldn't mind the "i386" port baseline bumped up to i686-with-SSE2 (and MMX), 
with gcc configured accordingly: I recall some reports that telling gcc to use 
SSE2 really improved several workloads.  But I am fine keeping the status-quo 
of current i686 baseline as well: requiring SSE2 would kick out a non-trivial 
number of non-Intel processor models, I think we went over this the last time a 
"i386" baseline bump was considered.

-- 
  Henrique de Moraes Holschuh 

Re: Making Debian available

[Lou Poppler]

On Thu, 2021-01-21 at 09:40 -0500, SDA wrote:
> On Thu, Jan 21, 2021 at 04:14:20AM -0700, Lou Poppler wrote:
> > On Wed, 2021-01-20 at 23:46 -0500, SDA wrote:
> > > On Wed, Jan 20, 2021 at 08:42:02AM -0700, Lou Poppler wrote:
> > > > SDA wrote:
> > > > > Incidently now that this is under discussion - whomever is supplying 
> > > > > the 
> > > > > non-free live images should know that the torrents of the stable 
> > > > > version 
> > > > > aren't seeded. I was attempting to download them all to help with 
> > > > > seeding, 
> > > > > and there isn't one seeder. Could somebody pass the word along? 
> > > > > Thanks!
> > > > 
> > > > They are working from here -- I am even seeding a couple of them.
> > > > I see the tracker is alive, and approx 24 seeders these:
> > > > debian-live-10.7.0-i386-standard+nonfree.iso
> > > > debian-live-10.7.0-amd64-gnome+nonfree.iso
> > > > 
> > > > Which ones are you having trouble with?
> > > 
> > > All of them. Are you using this tracker? 
> > > http://bttracker.debian.org:6969/announce
> > > 
> > 
> > Yes I am.  Please answer my question.  What are the URLs from which you took
> > your x.torrent files?   What are the filenames?  Did you verify any of 
> > the
> > checksums?
> 
> Checksums on the torrent files? No ...
> 
> Got them from this url: 
> https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/10.7.0-live+nonfree/amd64/bt-hybrid/
> 
> I'm using a VPN, surely that wouldn't make a difference?
> 
> > Please keep the discussion in the mailing list -- other list members may 
> > offer
> > answers that do not occur to me.  Other list members will be the ones with 
> > the
> > power to fix any problem that is found with the tracker or home seeders.
> 
> I would have keep it on the list if your reply-to-list was functioning. Mutt 
> said no list found when I attempted to respond to list from your email. Not 
> my 1st rodeo with using mutt on Debian Lists.
> 
> Again, everything else in my torrent client/server works, just this tracker 
> aint.

I can tell you that this machine I type on is seeding one of those right now.

debian-live-10.7.0-amd64-gnome+nonfree.iso

The status summary tells me this:
http://bttracker.debian.org:6969
Got a list of 38 peers 1 minute ago
Asking for more peers in 13 minutes
Tracker had 45 seeders and one leechers 59 seconds ago
Asking for peer counts in 29 minutes.

Can you tell us more about your software?  What BT client/server are you using?
What does your software tell you about debian's tracker and/or torrents --
is there some message or status, or just "doesn't work" ?  It is not correct
that there is not one seeder, at least on the one I am personally seeding.

Re: RFC: raising ca-certificates package Priority to standard or important

[Marco d'Itri]

On Jan 21, Julien Cristau  wrote:

> So I'd like to raise the priority of ca-certificates from optional to
> at least standard, as a signal that it should be installed on
Good idea: I think that "standard" is appropriate.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

RFC: raising ca-certificates package Priority to standard or important

[Julien Cristau]

[bcc: {openssl,ca-certificates}@packages.d.o]

Hi,

the ca-certificates package is currently "Priority: optional", like most
of the archive.  It's Recommended by a bunch of packages, Depended on by
an equivalent number, but I'm not sure if this is optimal.  I suspect
most packages can be configured to use a different trust store; and that
in many deployments you may want to use a private PKI, or limit trust to
a specific subset of the global public CAs, so in that sense `Depends'
on ca-certificates is not quite correct.  On the other hand it's less
likely to run into "user disabled Recommends, and run into unexpected TLS
server auth failures" kind of situations.

So I'd like to raise the priority of ca-certificates from optional to
at least standard, as a signal that it should be installed on
non-minimal Debian systems.  I'll note that ca-certificates depends on
the openssl binary package which would thus effectively also become
standard (or important, if we go that route), if it isn't already.

Before asking ftpmasters to make that change I wanted to ask this group
if there were downsides to it that I haven't considered.  And which of
standard or important made most sense (AIUI, standard means "installed
by default in d-i" and important means "installed by default in
debootstrap").

Thanks,
Julien

Re: Making Debian available

[Lou Poppler]

On Wed, 2021-01-20 at 23:46 -0500, SDA wrote:
> On Wed, Jan 20, 2021 at 08:42:02AM -0700, Lou Poppler wrote:
> > SDA wrote:
> > > Incidently now that this is under discussion - whomever is supplying the 
> > > non-free live images should know that the torrents of the stable version 
> > > aren't seeded. I was attempting to download them all to help with 
> > > seeding, 
> > > and there isn't one seeder. Could somebody pass the word along? Thanks!
> > 
> > They are working from here -- I am even seeding a couple of them.
> > I see the tracker is alive, and approx 24 seeders these:
> > debian-live-10.7.0-i386-standard+nonfree.iso
> > debian-live-10.7.0-amd64-gnome+nonfree.iso
> > 
> > Which ones are you having trouble with?
> 
> All of them. Are you using this tracker? 
> http://bttracker.debian.org:6969/announce
> 
Yes I am.  Please answer my question.  What are the URLs from which you took
your x.torrent files?   What are the filenames?  Did you verify any of the
checksums?
Please keep the discussion in the mailing list -- other list members may offer
answers that do not occur to me.  Other list members will be the ones with the
power to fix any problem that is found with the tracker or home seeders.

Thanks,
Lou

Re: move to merged-usr-only?

[Simon McVittie]

On Thu, 21 Jan 2021 at 06:03:52 +0100, Guillem Jover wrote:
> I mentioned this before, this does not look specific to whatever
> method to do merged-/usr, instead this seems like a general dpkg
> problem related to missing fsync() on the directories during unpacks

It's great news that someone has a theory on this. I opened
 for this
a while ago, but since I have no idea how to reproduce it, I wasn't able
to get anywhere.

> I don't see why this could not affect also merged-/usr-via-aliased-dirs
> systems when moving other pathnames around.

I expect it could affect any move between directories, but it's usually
only going to have a serious impact when: a file was previously in
a higher-precedence member of a search path, it is being moved to a
lower-precedence member of the same search path, and the higher-precedence
member of the search path is still searched by the loader, causing the
old file to be loaded. In other situations, the old file wastes some disk
space but usually won't be actively harmful.

Moving shared libraries from /lib/MULTIARCH to /usr/lib/MULTIARCH happens
to be a relatively frequently-done move that fits that description.
Most of our other search paths either have length 1 (so the more serious
impact won't occur because no move can take place), or add new entries
with higher precedence than old entries, for example when GTK started to
load /usr/lib/x86_64-linux-gnu/gtk-*/modules at a higher precedence than
/usr/lib/gtk-*/modules (so the more serious impact won't occur because
there is no reason why we would want to move modules from the multiarch
location to the pre-multiarch location).

I think the semantics of ldconfig make this worse for shared libraries
specifically, because even if dpkg correctly removes the SONAME
symlink in /lib for a library that has moved into /usr/lib, ldconfig
will helpfully re-create it as long as the real file exists.
(For example in the GLib case, as long as /lib/MA/libglib-2.0.so.0.4200.0
continues to exist, ldconfig will re-create /lib/MA/libglib-2.0.so.0,
with the unwanted effect of shadowing /usr/lib/MA/libglib-2.0.so.0.)

Moving executables between directories in PATH could maybe run into a
similar problem, part of which would be avoided by merged /usr (because
moving between /bin and /usr/bin, or /sbin and /usr/sbin, becomes a no-op)
but part of which is not (moving between [/usr]/bin and [/usr]/sbin could
still trigger something similar, which merged /usr would not address).

smcv

Re: Making Debian available

[Marc Haber]

On Thu, 21 Jan 2021 00:28:42 +0100, Ben Hutchings
 wrote:
>On Sun, 2021-01-17 at 11:31 +0100, Marc Haber wrote:
>> On Sat, 16 Jan 2021 10:58:33 +, "Andrew M.A. Cater"
>>  wrote:
>> > Video drivers: we have some basic video modes that work for text mode on 
>> > nearly all cards / embedded chipsets. Other than that, almost everything 
>> > requires a non-free driver. AMD/Intel/Nvidia are all, in their own ways, 
>> > equally bad. Video chipsets change fairly frequently: invariably, newest 
>> > laptops are always a pain.  
>> 
>> I have not needed a single non-free video driver since I ditched the
>> nVidia Accident that I bought in 2008 to have dual DVI output.
>> 
>> The only non-free thing I _need_ is network/wifi firmware and
>> microcode. I do not even know whethre my video cards require firmware
>> downloads to work.
>
>Any recent GPU from AMD, Intel, or Nvidia wants non-free firmware.  For
>AMD hardware the amdgpu driver absolutely requires it; the others might
>be semi-functional without.

Ah, yes, right. That one came in invisibly because I had to enable
non-free anyway for the Network.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Bug#980737: ITP: python-prison -- Python encoder/decoder for Rison

[Sophie Brun]

Package: wnpp
Severity: wishlist
Owner: Sophie Brun 
X-Debbugs-Cc: debian-devel@lists.debian.org, sop...@freexian.com

* Package name: python-prison
  Version : 0.1.3
  Upstream Author : 2019 Beto Dealmeida 
* URL : https://github.com/betodealmeida/python-rison
* License : Expat
  Programming Lang: Python
  Description : Python encoder/decoder for Rison

The package is a Python encoder/decoder for Rison, a data serialization
format optimized for compactness in URIs. Rison is a slight variation of
JSON that looks vastly superior after URI encoding. Rison still expresses
exactly the same set of data structures as JSON, so data can be translated
back and forth without loss or guesswork.

This package is required for elastalert version 0.2.4

I will maintain it within the Debian Python Team.