Re: Google Summer of Code participation [Not Selected]

[Abhijith PA]

On 04/02/23 09:14 AM, Abhijith PA wrote:
> 
> Debian is applying as a mentoring organization for the Google Summer
> of Code 2023 [1] as we have done in previous years.

Unfortunately we are not selected for this year's program as our 
project idea list[1] was small. I should've announced adding project 
ideas to list quite early, sorry.

Keep adding ideas to the list for next year.


Regards
Abhijith
For outreach team.

[1] - https://wiki.debian.org/SummerOfCode2023/Projects

signature.asc
Description: PGP signature

Re: Updating python3-xlrd for pandas 1.5 compatibility

[Martin]

On 2023-02-22 23:12, Diane Trout wrote:
> | visidata | none | Build-Depends |

There seems to be no versioned depends or similar in the code.
Should be safe, but in doubt ask Anja (upstream).

Cheers

Re: Bug#1031634: ITP: gum -- A tool for glamourous shell scripts

[Antonio Terceiro]

On Wed, Feb 22, 2023 at 03:33:15PM -0700, Sam Hartman wrote:
> >>  A tool for glamorous shell scripts. Leverage the power of
> >> Bubbles  (https://github.com/charmbracelet/bubbles) and Lip Gloss
> >>  (https://github.com/charmbracelet/lipgloss) in your scripts and
> >> aliases  without writing any Go code!   .   Tutorial  .   Gum
> >> provides highly configurable, ready-to-use utilities to help you
> >> write  useful shell scripts and dotfiles aliases with just a few
> >> lines of code.
> 
> Antonio> This last paragraph above looks like a good enough package
> Antonio> description.  Save everything else for an upstream README
> Antonio> installed on /usr/share/doc/gum/, or some other type of
> Antonio> documentation.
> 
> I disagree.
> I should not have to chase down links to  websites to understand a
> description
> Please include a phrase or two describing each of bubbles and gloss.

I meant only the part that starts with "Gum provides highly-configurable
..."


signature.asc
Description: PGP signature

Re: Yearless copyrights: what do people think?

[Wouter Verhelst]

On Wed, Feb 22, 2023 at 08:20:27AM -0800, Russ Allbery wrote:
> Daniel Baumann  writes:
> > On 2/22/23 14:26, Peter Pentchev wrote:
> 
> >> Wait, I may have been unclear. I did not mean that I want to omit the
> >> upstream copyright years *when they are there*.
> 
> > I know you didn't mean that, nevertheless, it's imho good idea.
> 
> Unfortunately, it's often against the upstream license.
> 
> Redistribution and use in source and binary forms, with or without
> modification, are permitted provided that the following conditions
> are met:
> 1. Redistributions of source code must retain the above copyright
>notice, this list of conditions and the following disclaimer.
> 
> and:
> 
> The above copyright notice and this permission notice shall be
> included in all copies or substantial portions of the Software.

It says you need to do that, yes. It does not say *where* that copyrigh
statement must be.

debian/copyright is wholly a Debian-specific invention. We can often do
whatever we want there and still comply with the copyright license.

It's useful for our users that debian/copyright contains an accurate
copy of the license statement, but I don't see how it would be relevant
for an upstream license.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Re: Yearless copyrights: what do people think?

[Russ Allbery]

Wouter Verhelst  writes:
> On Wed, Feb 22, 2023 at 08:20:27AM -0800, Russ Allbery wrote:

>> Unfortunately, it's often against the upstream license.

>> Redistribution and use in source and binary forms, with or without
>> modification, are permitted provided that the following conditions
>> are met:
>> 1. Redistributions of source code must retain the above copyright
>>notice, this list of conditions and the following disclaimer.

>> and:

>> The above copyright notice and this permission notice shall be
>> included in all copies or substantial portions of the Software.

> It says you need to do that, yes. It does not say *where* that copyrigh
> statement must be.

While this is true, we don't put the copyright statements anywhere else in
binary packages.

I think arguing that having them in the source package is a stretch for
those licenses, since they don't give any special significance to source
distributions and the normal way of using the archive is to download the
binary package without the source.  The Expat license specifically says
"all copies"; it doesn't say that if you distribute a few different forms
of the software, you can leave the copyright notice out of some of them.

I agree that we would satisfy the license if we had a separate file in the
binary package that collected all the copyright notices, but we don't;
that's the copyright file.

All that said, I think the chances that anyone would care enough about
this to sue is fairly low.  But not zero -- there do exist bad-faith
copyright holders who are looking for excuses to sue (although they're
thankfully quite rare in free software).

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

MariaDB 10.11 in Bookworm - call for contributions

[Otto Kekäläinen]

Hello!

(Stop reading if you don't use MariaDB)

I am currently preparing the upload of MariaDB 10.11.2-2 to Debian
unstable and aim for the highest possible quality. I am currently
doing the bulk of the testing and packaging alone and to make sure
that the quality is top notch, I would be glad to see more people
contribute.

If you have time to help, please consider these (in order of importance):

1. Review current open MRs at
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests

2. Review items highlighted by Debian QA systems (Lintian, builds etc)
and submit a fix to improve the quality:
https://tracker.debian.org/pkg/mariadb

3. Review what testing we have at
https://salsa.debian.org/mariadb-team/mariadb-server/-/pipelines and
think about potential gaps - CI is very important as it is the only
way we can prevent regressions in a scalable way

4. Review/follow-up on existing bugs that currently need more
information: 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=mariadb&src=mariadb-10.6&src=mariadb-10.5&src=mariadb-10.3&src=mariadb-10.1

MariaDB and C++ skills are useful, but not required. For example
reviewing the NEWS for 10.11 requires no coding skills:
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/37

- Otto

Re: icc-profiles_2.2_source.changes REJECTED

[Jonas Smedegaard]

What to do when a package is blocked from getting updated due to it
being itself?

I have tried replying to FTPmasters as invited in the rejection message,
but have been met with silence.

I have tried filing bug#1030961 but have so far seen no response on that
either.

Will it make sense to reassing that bugreport to the technical
committee?  Or to the release team?  Or should I request removal of the
package, because security bugfixes (however unlikely for a package
containing purely static data files) is impossible?


 - Jonas

Quoting Debian FTP Masters (2023-02-09 04:19:39)
> 
> 
> icc-profiles source: lintian output: 'license-problem-md5sum-non-free-file 
> ECI-RGB.V1.0.icc usual name is ECI-RGB.V1.0.icc. Does not allow modification 
> See also https://packages.debian.org/sid/icc-profiles.', automatically 
> rejected package.
> icc-profiles source: lintian output: 'license-problem-md5sum-non-free-file 
> GRACoL2006_Coated1v2.icc usual name is GRACoL2006_Coated1v2.icc. Does not 
> allow modification See also https://packages.debian.org/sid/icc-profiles.', 
> automatically rejected package.
> icc-profiles source: lintian output: 'license-problem-md5sum-non-free-file 
> ISOcoated.icc usual name is ISOcoated.icc. Does not allow modification See 
> also https://packages.debian.org/sid/icc-profiles.', automatically rejected 
> package.
> icc-profiles source: lintian output: 'license-problem-md5sum-non-free-file 
> ISOcoated_v2_300_eci.icc usual name is ISOcoated_v2_300_eci.icc. Does not 
> allow modification See also https://packages.debian.org/sid/icc-profiles.', 
> automatically rejected package.
> icc-profiles source: lintian output: 'license-problem-md5sum-non-free-file 
> ISOcoated_v2_eci.icc usual name is ISOcoated_v2_eci.icc. Does not allow 
> modification See also https://packages.debian.org/sid/icc-profiles.', 
> automatically rejected package.
> icc-profiles source: lintian output: 'license-problem-md5sum-non-free-file 
> ISOnewspaper26v4.icc usual name is ISOnewspaper26v4.icc. Does not allow 
> modification See also https://packages.debian.org/sid/icc-profiles.', 
> automatically rejected package.
> icc-profiles source: lintian output: 'license-problem-md5sum-non-free-file 
> ISOnewspaper26v4_gr.icc usual name is ISOnewspaper26v4_gr.icc. Does not allow 
> modification See also https://packages.debian.org/sid/icc-profiles.', 
> automatically rejected package.
> icc-profiles source: lintian output: 'license-problem-md5sum-non-free-file 
> ISOuncoated.icc usual name is ISOuncoated.icc. Does not allow modification 
> See also https://packages.debian.org/sid/icc-profiles.', automatically 
> rejected package.
> icc-profiles source: lintian output: 'license-problem-md5sum-non-free-file 
> ISOuncoatedyellowish.icc usual name is ISOuncoatedyellowish.icc. Does not 
> allow modification See also https://packages.debian.org/sid/icc-profiles.', 
> automatically rejected package.
> icc-profiles source: lintian output: 'license-problem-md5sum-non-free-file 
> ISOwebcoated.icc usual name is ISOwebcoated.icc. Does not allow modification 
> See also https://packages.debian.org/sid/icc-profiles.', automatically 
> rejected package.
> icc-profiles source: lintian output: 'license-problem-md5sum-non-free-file 
> PSO_Coated_300_NPscreen_ISO12647_eci.icc usual name is 
> PSO_Coated_300_NPscreen_ISO12647_eci.icc. Does not allow modification See 
> also https://packages.debian.org/sid/icc-profiles.', automatically rejected 
> package.
> icc-profiles source: lintian output: 'license-problem-md5sum-non-free-file 
> PSO_Coated_NPscreen_ISO12647_eci.icc usual name is 
> PSO_Coated_NPscreen_ISO12647_eci.icc. Does not allow modification See also 
> https://packages.debian.org/sid/icc-profiles.', automatically rejected 
> package.
> icc-profiles source: lintian output: 'license-problem-md5sum-non-free-file 
> PSO_LWC_Improved_eci.icc usual name is PSO_LWC_Improved_eci.icc. Does not 
> allow modification See also https://packages.debian.org/sid/icc-profiles.', 
> automatically rejected package.
> icc-profiles source: lintian output: 'license-problem-md5sum-non-free-file 
> PSO_LWC_Standard_eci.icc usual name is PSO_LWC_Standard_eci.icc. Does not 
> allow modification See also https://packages.debian.org/sid/icc-profiles.', 
> automatically rejected package.
> icc-profiles source: lintian output: 'license-problem-md5sum-non-free-file 
> PSO_MFC_Paper_eci.icc usual name is PSO_MFC_Paper_eci.icc. Does not allow 
> modification See also https://packages.debian.org/sid/icc-profiles.', 
> automatically rejected package.
> icc-profiles source: lintian output: 'license-problem-md5sum-non-free-file 
> PSO_SNP_Paper_eci.icc usual name is PSO_SNP_Paper_eci.icc. Does not allow 
> modification See also https://packages.debian.org/sid/icc-profiles.', 
> automatically rejected package.
> icc-profiles source: lintian output: 'license-problem-md5sum-non-free-file 
> PSO_Uncoated_ISO12647_eci.icc usual name is PSO_Uncoated_ISO12647_eci.icc. 
> D

Work-needing packages report for Feb 24, 2023

[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: 1220 (new: 0)
Total number of packages offered up for adoption: 160 (new: 0)
Total number of packages requested help for: 60 (new: 0)

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



No new packages have been orphaned, but a total of 1220 packages are
orphaned.  See https://www.debian.org/devel/wnpp/orphaned
for a complete list.



No new packages have been given up for adoption, but a total of 160 packages
are awaiting adoption.  See https://www.debian.org/devel/wnpp/rfa_bypackage
for a complete list.



For the following packages help is requested:

   apache2 (#910917), requested 1594 days ago
 Description: Apache HTTP Server
 Reverse Depends: apache2 apache2-ssl-dev apache2-suexec-custom
   apache2-suexec-pristine backuppc bfh-container-server
   courier-webadmin cvsweb debbugs-web debian-edu-router-deployserver
   (125 more omitted)
 Installations reported by Popcon: 97917
 Bug Report URL: https://bugs.debian.org/910917

   apparmor (#1006872), requested 353 days ago
 Description: user-space parser utility for AppArmor
 Reverse Depends: apparmor-notify apparmor-profiles
   apparmor-profiles-extra apparmor-utils content-hub-testability
   dbus-broker dbus-daemon dbus-tests debian-cloud-images-packages
   dovecot-core (24 more omitted)
 Installations reported by Popcon: 192457
 Bug Report URL: https://bugs.debian.org/1006872

   aufs (#963191), requested 978 days ago
 Description: driver for a union mount for Linux filesystems
 Reverse Depends: fsprotect
 Installations reported by Popcon: 6476
 Bug Report URL: https://bugs.debian.org/963191

   autopkgtest (#846328), requested 2276 days ago
 Description: automatic as-installed testing for Debian packages
 Reverse Depends: debci-worker sbuild-qemu
 Installations reported by Popcon: 1173
 Bug Report URL: https://bugs.debian.org/846328

   balsa (#642906), requested 4169 days ago
 Description: An e-mail client for GNOME
 Reverse Depends: balsa
 Installations reported by Popcon: 596
 Bug Report URL: https://bugs.debian.org/642906

   cargo (#860116), requested 2144 days ago
 Description: Rust package manager
 Reverse Depends: dh-cargo python3-setuptools-rust rust-all
 Installations reported by Popcon: 2874
 Bug Report URL: https://bugs.debian.org/860116

   chromium (#1016047), requested 212 days ago
 Description: web browser
 Reverse Depends: chromium chromium-driver chromium-l10n
   chromium-shell node-puppeteer qunit-selenium
   x2gothinclient-minidesktop
 Installations reported by Popcon: 24689
 Bug Report URL: https://bugs.debian.org/1016047

   courier (#978755), requested 784 days ago
 Description: Courier mail server
 Reverse Depends: courier-faxmail courier-filter-perl courier-imap
   courier-ldap courier-mlm courier-mta courier-pcp courier-pop
   courier-webadmin couriergrey (3 more omitted)
 Installations reported by Popcon: 796
 Bug Report URL: https://bugs.debian.org/978755

   cron (#984736), requested 718 days ago
 Description: new maintainer need
 Reverse Depends: apticron autolog backintime-common bcron
   btrfsmaintenance buildd checksecurity clamtk cricket cron (25 more
   omitted)
 Installations reported by Popcon: 209389
 Bug Report URL: https://bugs.debian.org/984736

   crun (#1016183), requested 210 days ago
 Description: lightweight OCI runtime for running containers
 Reverse Depends: podman
 Installations reported by Popcon: 1758
 Bug Report URL: https://bugs.debian.org/1016183

   cyrus-imapd (#921717), requested 1476 days ago
 Description: Cyrus mail system - IMAP support
 Reverse Depends: cyrus-admin cyrus-caldav cyrus-clients cyrus-dev
   cyrus-imapd cyrus-murder cyrus-nntpd cyrus-pop3d cyrus-replication
 Installations reported by Popcon: 392
 Bug Report URL: https://bugs.debian.org/921717

   debtags (#962579), requested 988 days ago
 Description: Debian Package Tags support tools
 Reverse Depends: packagesearch
 Installations reported by Popcon: 1382
 Bug Report URL: https://bugs.debian.org/962579

   dee (#831388), requested 2414 days ago
 Description: model to synchronize multiple instances over DBus
 Reverse Depends: dee-tools gir1.2-dee-1.0 gir1.2-unity-7.0
   libdee-dev libunity-dev libunity-protocol-private0 libunity-tools
   libunity9 zeitgeist-core
 Installations reported by Popcon: 45243
 Bug Report URL: https://bugs.debian.org

Re: icc-profiles_2.2_source.changes REJECTED

[Shengjing Zhu]

Hi,

On Fri, Feb 24, 2023 at 7:38 AM Jonas Smedegaard  wrote:
>
> What to do when a package is blocked from getting updated due to it
> being itself?
>
> I have tried replying to FTPmasters as invited in the rejection message,
> but have been met with silence.
>
> I have tried filing bug#1030961 but have so far seen no response on that
> either.
>
> Will it make sense to reassing that bugreport to the technical
> committee?  Or to the release team?  Or should I request removal of the
> package, because security bugfixes (however unlikely for a package
> containing purely static data files) is impossible?
>
>
>  - Jonas
>
> Quoting Debian FTP Masters (2023-02-09 04:19:39)
> >
> > icc-profiles source: lintian output: 'license-problem-md5sum-non-free-file 
> > ECI-RGB.V1.0.icc usual name is ECI-RGB.V1.0.icc. Does not allow 
> > modification See also https://packages.debian.org/sid/icc-profiles.', 
> > automatically rejected package.
[snip]
> > icc-profiles source: lintian output: 
> > 'source-only-upload-to-non-free-without-autobuild ', automatically rejected 
> > package.
> > icc-profiles source: If you have a good reason, you may override this 
> > lintian tag.

It's auto rejected. So I think it can be technically solved.
For license-problem-md5sum-non-free-file, it's obviously a false
positive from lintian. It should not emit such if the source is the
non-free section. It should be reported as a bug for the lintian
package. And you can submit patches as well, backport to the version
that ftp-master server uses.
For source-only-upload-to-non-free-without-autobuild, it's really a
bug in your upload. You should fix it.

-- 
Shengjing Zhu

DEB_BUILD_OPTIONS=nowerror

[Helmut Grohne]

Hi,

I observe a pattern repeated at least twice and probably more often in
packages.

 * A package adds -Werror to the build. When a new toolchain version is
   uploaded, it triggers a new warning and that makes the package FTBFS.
 * A package runs shellcheck during build. When a new shellcheck is
   uploaded, it triggers a new warning and makes the package FTBFS.

In general, the vast majority of packages does not use -Werror (except
specifically, e.g. via dpkg-buildflags) or shellcheck during build, but
employs such techniques during e.g. salsa-ci and that seems generally
preferred. However, some packages do still use this pattern.

Examples:
 * glibc adds -Werror
 * nss adds -Werror

When building affected packages with more recent toolchains, such build
failures are annoying. In a bootstrap setting, they hide later problems.
For that reason, I would like to have a standard way to opt out of such
failures. I understand that some of the warnings may be pointing at real
bugs and that ignoring them certainly is a compromise. I also understand
that packages may fail to build for other reasons with new toolchains
(e.g. missing #includes). However, -Werror has proven to be quite
repetitive and seems worthwhile to address to me.

As such, I propose a generic DEB_BUILD_OPTIONS=nowerror modelled after
the original observation, but meant to also match other checkers such as
shellcheck. The general idea should be that a warning should that can be
non-fatal should be non-fatal if possible.

Does this proposal make sense? Is there sufficient use case to support
it as a generic distribution feature (for a niche number of packages)?

>From a process point of view, I think this mail serves as a possible
standardization point. Packages can add support for this and the
responsibility for providing patches for this generally resides with
those interested in having it (i.e. me sending patches). Once we have
some adoption of this, we can add it to Debian policy.

So let me know if you think this is a bad idea.

Helmut

Re: DEB_BUILD_OPTIONS=nowerror

[Ansgar]

On Fri, 2023-02-24 at 07:19 +0100, Helmut Grohne wrote:
> As such, I propose a generic DEB_BUILD_OPTIONS=nowerror modelled after
> the original observation, but meant to also match other checkers such as
> shellcheck. The general idea should be that a warning should that can be
> non-fatal should be non-fatal if possible.

The name is too specific and can be misread:

- It is specific to -Werror, but other similar systems exist.

- It can be easily read an "now error" (i.e., a warning
  should "now (be an) error").

Also I think it was recommended to *not* use -Werror by default as it
is too fragile. Maybe one should have a "developer mode" flag instead
that allows using -Werror?

Ansgar

Re: DEB_BUILD_OPTIONS=nowerror

[Johannes Schauer Marin Rodrigues]

Quoting Helmut Grohne (2023-02-24 07:19:41)
> As such, I propose a generic DEB_BUILD_OPTIONS=nowerror modelled after the
> original observation, but meant to also match other checkers such as
> shellcheck. The general idea should be that a warning should that can be
> non-fatal should be non-fatal if possible.

Are there packages that run shellcheck in other places than those disabled by
DEB_BUILD_OPTIONS=nocheck? If yes, should running shellcheck not be moved to
there? In contrast to -Werror, shellcheck is not involved in literally building
something.

Otherwise, other linter tools like black come to mind that also recently broke
my packages [1] when black got upgraded to 23.1.0-1 two weeks ago. But black
(like shellcheck I'd assume) is usually disabled with nocheck or by not running
autopkgtests.

In what places is shellcheck called such that it cannot or should not be moved
to a place where it could be disabled by DEB_BUILD_OPTIONS=nocheck?

Thanks!

cheers, josch

[1] Versions of mmdebstrap and diffoscope that work with the new black in their
autopkgtest have already been uploaded to unstable and are waiting to
transition to testing so that black can transition as well. Maybe the timing of
this upload of black was a bit unfortunate this late into the freeze because
other packages are using it as part of their build process and now FTBFS. Like
another package of mine (botch) which is also fixed now and waiting:
https://bugs.debian.org/1031469

Re: DEB_BUILD_OPTIONS=nowerror

[Helmut Grohne]

Hi Ansgar,

On Fri, Feb 24, 2023 at 08:02:35AM +0100, Ansgar wrote:
> The name is too specific and can be misread:
> 
> - It is specific to -Werror, but other similar systems exist.
> 
> - It can be easily read an "now error" (i.e., a warning
>   should "now (be an) error").

Fair point. I am unimagintaive about better terms at present.

> Also I think it was recommended to *not* use -Werror by default as it
> is too fragile. Maybe one should have a "developer mode" flag instead
> that allows using -Werror?

Well, if we were avoiding -Werror by default, we wouldn't have this
discussion. It certainly isn't consensus.

-Werror:
 * acpid
 * blktrace
 * bomstrip
 * breeze-plymouth
 * cbmc
 * cryptsetup
 * diagnostics
 * dumpet
 * glibc
 * golang-gvisor-gvisor
 * libgadu
 * libutempter
 * nss
 * quotatool
 * smcroute
 * spiped
 * switchsh
 * varnish

shellcheck:
 * grml-debootstrap
 * josm-installer
 * kdump-tools
 * python-sshoot
 * sshcommand
 * uwsgi

Admittedly, we also have a fair number of packages that explicitly
disable -Werror, so we also don't have consensus on applying -Werror.

Given this non-consistency, I'm asking for a way to opt out, but I'd
also be happy if this really was off by default and interested people
would opt in. This does have a precedent with DEB_BUILD_OPTIONS=terse
where we effectively settled on verbose by default.

Helmut