Re: getting pinta updated in Debian

[Mike Gabriel]

On  Fr 04 Mär 2022 01:39:31 CET, Mirco Bauer wrote:


I am not sure if you can build dotnet from source at this point, maybe it
is possible by now. I could never find time to follow-up on this as I
started to work for demanding startups that leave little to no spare time.
If you are interested to get dotnet into Debian I am still available for
mentoring and going in the right direction, I would like to see dotnet
packaged still, it is a fantastic software development platform. The
#debian-cli IRC channel on OFTC is the place where the Mono and .NET
friends hang out, so feel invited to join us.


Thanks for your info and the mentoring offer. I will wait some more  
time if and what others contribute to this thread and then decide on  
how much effort I can spend on this. It is an effort that definitely  
goes beyond the customer request. (Sigh...).


Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpPPyKYZleCo.pgp
Description: Digitale PGP-Signatur

Re: getting pinta updated in Debian

[Mike Gabriel]

Hi Jo,

On  Fr 04 Mär 2022 02:16:05 CET, Jo Shields wrote:

I know that team has been engaging with someone at Canonical about  
Ubuntu packaging, I can reach out to find out who that is, and see  
whether that work could be uploaded to Debian first as a matter of  
course


yes, please do. It would be awesome if someone has already worked on  
packaging that is +/- suitable for Debian. Plus: thanks for the  
overall info.


Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpNEma2M9yYt.pgp
Description: Digitale PGP-Signatur

RE: getting pinta updated in Debian

[Jo Shields]

“source-build” is the project within Microsoft which aims to produce “upstream 
tarballs” in a sufficiently from-source form to satisfy FOSS distributions. 
Fedora has had dotnet for a while as a result, a collaboration between the 
source-build team in Utah and a distributed set of folks at Red Hat (Fedora’s 
from-source requirements are slightly different from the DFSG, but not 
meaningfully so). Roughly speaking, source-build has to reconcile about 30 
separate dotnet repos, in order to produce an upstream-equivalent dotnet SDK.

I know that team has been engaging with someone at Canonical about Ubuntu 
packaging, I can reach out to find out who that is, and see whether that work 
could be uploaded to Debian first as a matter of course

Sent from Mail for Windows

From: Mirco Bauer
Sent: Thursday, March 3, 2022 7:57 PM
To: Mike Gabriel
Cc: debian-devel@lists.debian.org; debian-...@lists.debian.org; 
979...@bugs.debian.org
Subject: Re: getting pinta updated in Debian

Hello Mike,

thanks for your interest in getting pinta updated in Debian. The other day I 
noticed as well that pinta is outdated in Debian and it does not look like 
there is a simple way forward, unfortunately.

Pinta has moved to the dotnet runtime which is not packaged in Debian.

Many years ago I worked on getting the dotnet core runtime into Debian (just as 
I did to get Mono into Debian back then) but I hit hard problems that prevented 
it.
The dotnet runtime could not be build from source which is not compliant with 
the DFSG. Microsoft had shown interest and I have advised them on how to make 
dotnet DFSG compliant so it could be included in Debian and Ubuntu, but it was 
clear it won't happen overnight as building cleanly from source (bootstrapping 
a runtime) isn't trivial and needed a major effort on the upstream side. Later 
this effort deepened between Microsoft and Redhat to make dotnet buildable from 
source, which is great.

I am not sure if you can build dotnet from source at this point, maybe it is 
possible by now. I could never find time to follow-up on this as I started to 
work for demanding startups that leave little to no spare time. If you are 
interested to get dotnet into Debian I am still available for mentoring and 
going in the right direction, I would like to see dotnet packaged still, it is 
a fantastic software development platform. The #debian-cli IRC channel on OFTC 
is the place where the Mono and .NET friends hang out, so feel invited to join 
us.

Best regards,

Mirco Bauer

Chief InfoSec Officer   mirco.ba...@eqonex.com https://group.eqonex.com/
FOSS Hacker             mee...@meebey.net      https://www.meebey.net/
Debian Developer        mee...@debian.org      https://www.debian.org/
GNOME Foundation Member mmmba...@gnome.org     https://www.gnome.org/
.NET Foundation Advisory Council Member        https://www.dotnetfoundation.org/
PGP-Key ID              0x7127E5ABEEF946C8     https://meebey.net/pubkey.asc



On Thu, Mar 3, 2022 at 4:05 AM Mike Gabriel  
wrote:
Hi all,

I am currently looking into requirements of getting pinta in Debian  
updated to the latest upstream version.

My problem: I am not at all a .NET developer or maintainer, so this is  
a piece of work with a steep learning curve for me.

What I found now are AUR packages for pinta (and its dependency  
dotnet-runtime) that are quite up-to-date:

https://archlinux.org/packages/community/any/pinta/
https://archlinux.org/packages/community/x86_64/dotnet-core/

It basically looks like we need to get dotnet-core into Debian and  
then update pinta to latest 2.0.2 upstream release and we are done.

However, dotnet-core seems to be massive and I wonder if that can be  
avoided as its API is provided by something else in Debian. I am  
asking this possibly stupid question because I am astounded that noone  
has ever packaged dotnet-core, filed an RFP or ITP for it, etc.

Furthermore, it seems that dotnet-core has been licensed under a  
DFSG-compliant MIT license variant [1].

Do I miss anything here? Is there a hidden blocker? Or is it just that  
noone has been interested in dotnet-core (and/or a pinta version  
bump), so far / recently?

Thanks for feedback!
Mike

[1] https://github.com/dotnet/core/blob/main/LICENSE.TXT
-- 

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

Re: getting pinta updated in Debian

[Mirco Bauer]

Hello Stephen, Hello Jo!

thanks for sharing your thoughts on the tricky dotnet package ecosystem
which I can fully relate to. In the Debian Mono Group we discussed these
many times on the available options how we can overcome these new packaging
challenges.

The problem indeed starts with a shift of how code is distributed.
Developers no longer publish source archives (.zip, .tar.gz, etc) but they
publish binary packages into a language specific package format and
ecosystem (e.g. nuget, pip, etc). Where the users of their code then use
nuget to consume these.

The best solution we could find is an approach that Debian Perl has taken
with CPAN.
So you would basically assist creating debian packages from nuget packages
with Debian tools (to be developed).
For Perl there is dh-make-perl [0] doing exactly this. So this shift in the
ecosystem is solvable but it will take some weeks of work to get there.

[0]: https://packages.debian.org/sid/dh-make-perl

Best regards,

Mirco Bauer

Chief InfoSec Officer   mirco.ba...@eqonex.com https://group.eqonex.com/
FOSS Hacker mee...@meebey.net  https://www.meebey.net/
Debian Developermee...@debian.org  https://www.debian.org/
GNOME Foundation Member mmmba...@gnome.org https://www.gnome.org/
.NET Foundation Advisory Council Member
https://www.dotnetfoundation.org/
PGP-Key ID  0x7127E5ABEEF946C8 https://meebey.net/pubkey.asc



On Fri, Mar 4, 2022 at 5:24 AM Stephen Shaw  wrote:

> On Thu, Mar 3, 2022 at 12:47 PM Gunnar Wolf  wrote:
> >
> > Timotheus Pokorra dijo [Wed, Mar 02, 2022 at 10:35:36PM +0100]:
> > > Hello Mike,
> > >
> > > I have some experience with Mono packaging in Fedora.
> > > I know of the dotnet SIG in Fedora. They made a massive effort,
> involving
> > > Microsoft employees, to get dotnet core built according to the Fedora
> rules
> > > (build from source, not using external files, etc).
> > > (...)
> > > It is really difficult to package dotnet packages, because of all the
> nuget
> > > dependancies. We have not figured that out for Fedora. Or did not have
> the
> > > volunteers yet to do that.
> > >
> > > Alternatives to dotnet: Mono, dotgnu
> > > https://www.gnu.org/software/dotgnu/
> > > "As of December 2012, the DotGNU project has been decommissioned."
> > >
> > > Mono: it is the alternative to .NET Framework, which Microsoft will
> support
> > > for many years to come. But the new stuff is happening in dotnet, so
> > > projects like Pinta are moving from Mono to dotnet.
> >
> > Uff... .NET -- A reimplementation of the "write once, debug
> > everywhere" fiasco :-(
>^^ Seems like a horribly useless and uninformed clickbait comment
>
>
> Warning: I'm going to brain dump a bunch of random thoughts :)
>
> Mono is actually now part of dotnet:
> https://github.com/dotnet/runtime/tree/main/src/mono
> dotnet provides two different runtimes. coreclr and monovm both of
> which are largely xplat.
> The traditional .NET Framework and Mono are going away in favor of
> dotnet. Still largely the same runtime, base class libraries, etc that
> .NET developers are used to + all the new features and it's continued
> evolution, etc
>
> tl;dr; from my perspective
> I've felt like this has been a growing problem with how Linux does
> packaging, right or wrong doesn't matter. The fact still remains that
> this'll continually become more challenging and/or impossible problem
> at some point. Most, if not all, of the current popular programming
> languages have some sort of packaging system:
> C#, nuget
> java, maven
> ruby, rubygems
> python, pip
> node.js, npm
> php, pakcagist
> js, bower
>
> to name a few.
>
> The current approach is to rebuild ever language from source, but most
> devs don't want to re-implement a whole bunch of functionality they
> can get with the push of a button by adding some "package". As
> programs get more complex there are more libraries being written,
> shared, and included. Unless you can completely automate the building
> of every package this breaks down really fast.
>
> Maybe its time to re-evaluate this system?
> Could we provide some kind of sandbox that builds these projects and
> allows for an internet connection to import all of the "packages"? Is
> it possible to ensure that the packages are exclusively pulled from
> "authorized" sources?
>
> Cheers,
> Stephen
>
>

Re: getting pinta updated in Debian

[Mirco Bauer]

Hello Mike,

thanks for your interest in getting pinta updated in Debian. The other day
I noticed as well that pinta is outdated in Debian and it does not look
like there is a simple way forward, unfortunately.

Pinta has moved to the dotnet runtime which is not packaged in Debian.

Many years ago I worked on getting the dotnet core runtime into Debian
(just as I did to get Mono into Debian back then) but I hit hard problems
that prevented it.
The dotnet runtime could not be build from source which is not compliant
with the DFSG .
Microsoft had shown interest and I have advised them on how to make dotnet
DFSG compliant so it could be included in Debian and Ubuntu, but it was
clear it won't happen overnight as building cleanly from source
(bootstrapping a runtime) isn't trivial and needed a major effort on the
upstream side. Later this effort deepened between Microsoft and Redhat to
make dotnet buildable from source, which is great.

I am not sure if you can build dotnet from source at this point, maybe it
is possible by now. I could never find time to follow-up on this as I
started to work for demanding startups that leave little to no spare time.
If you are interested to get dotnet into Debian I am still available for
mentoring and going in the right direction, I would like to see dotnet
packaged still, it is a fantastic software development platform. The
#debian-cli IRC channel on OFTC is the place where the Mono and .NET
friends hang out, so feel invited to join us.

Best regards,

Mirco Bauer

Chief InfoSec Officer   mirco.ba...@eqonex.com https://group.eqonex.com/
FOSS Hacker mee...@meebey.net  https://www.meebey.net/
Debian Developermee...@debian.org  https://www.debian.org/
GNOME Foundation Member mmmba...@gnome.org https://www.gnome.org/
.NET Foundation Advisory Council Member
https://www.dotnetfoundation.org/
PGP-Key ID  0x7127E5ABEEF946C8 https://meebey.net/pubkey.asc



On Thu, Mar 3, 2022 at 4:05 AM Mike Gabriel <
mike.gabr...@das-netzwerkteam.de> wrote:

> Hi all,
>
> I am currently looking into requirements of getting pinta in Debian
> updated to the latest upstream version.
>
> My problem: I am not at all a .NET developer or maintainer, so this is
> a piece of work with a steep learning curve for me.
>
> What I found now are AUR packages for pinta (and its dependency
> dotnet-runtime) that are quite up-to-date:
>
> https://archlinux.org/packages/community/any/pinta/
> https://archlinux.org/packages/community/x86_64/dotnet-core/
>
> It basically looks like we need to get dotnet-core into Debian and
> then update pinta to latest 2.0.2 upstream release and we are done.
>
> However, dotnet-core seems to be massive and I wonder if that can be
> avoided as its API is provided by something else in Debian. I am
> asking this possibly stupid question because I am astounded that noone
> has ever packaged dotnet-core, filed an RFP or ITP for it, etc.
>
> Furthermore, it seems that dotnet-core has been licensed under a
> DFSG-compliant MIT license variant [1].
>
> Do I miss anything here? Is there a hidden blocker? Or is it just that
> noone has been interested in dotnet-core (and/or a pinta version
> bump), so far / recently?
>
> Thanks for feedback!
> Mike
>
> [1] https://github.com/dotnet/core/blob/main/LICENSE.TXT
> --
>
> DAS-NETZWERKTEAM
> c\o Technik- und Ökologiezentrum Eckernförde
> Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
> mobile: +49 (1520) 1976 148
> landline: +49 (4351) 850 8940
>
> GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
> mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de
>
>

Work-needing packages report for Mar 4, 2022

[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: 1213 (new: 1)
Total number of packages offered up for adoption: 192 (new: 2)
Total number of packages requested help for: 61 (new: 0)

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



The following packages have been orphaned:

   libcec (#1006619), orphaned 3 days ago
 Description: USB CEC Adaptor communication Library
 Reverse Depends: cec-utils kodi-bin libcec-dev python3-cec
   xineliboutput-fbfe xineliboutput-sxfe xineliboutput-wlfe
 Installations reported by Popcon: 2348
 Bug Report URL: https://bugs.debian.org/1006619

1212 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:

   dvidvi (#1006644), offered 2 days ago
 Description: Manipulate .dvi files
 Reverse Depends: texlive-full
 Installations reported by Popcon: 4186
 Bug Report URL: https://bugs.debian.org/1006644

   ifrench-gut (#1006643), offered 2 days ago
 Description: French dictionary for ispell (GUTenberg version)
 Installations reported by Popcon: 21312
 Bug Report URL: https://bugs.debian.org/1006643

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



For the following packages help is requested:

   apache2 (#910917), requested 1237 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 doc-central (132 more omitted)
 Installations reported by Popcon: 99006
 Bug Report URL: https://bugs.debian.org/910917

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

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

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

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

   courier (#978755), requested 427 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: 887
 Bug Report URL: https://bugs.debian.org/978755

   cron (#984736), requested 361 days ago
 Description: new maintainer need
 Reverse Depends: apticron autolog backintime-common btrfsmaintenance
   buildd checksecurity clamtk cricket email-reminder exim4-base (20
   more omitted)
 Installations reported by Popcon: 208718
 Bug Report URL: https://bugs.debian.org/984736

   cyrus-imapd (#921717), requested 1119 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: 417
 Bug Report URL: https://bugs.debian.org/921717

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

   dee (#831388), requested 2057 days ago
 Description: model to synchronize mutiple 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: 42734
 Bug Report URL: https://bugs.debian.org/831388

   developers-reference (#759995), requested 2742 days ago
 Description: guidelines and information for Debian developers
 Installations reported by Popcon: 3534
 Bug Report URL: https://bugs.debian.org/759995

   devscripts (#80

Re: NEW processing friction

[Sean Whitton]

Hello,

On Thu 03 Mar 2022 at 08:44PM +01, Andreas Tille wrote:

> Am Thu, Mar 03, 2022 at 09:57:26AM -0700 schrieb Sean Whitton:
>> > PS: I'm currently considering writing up some summary of the bunch
>> > of threads that was born out of my initial mail.
>> >
>> > [1] https://lists.debian.org/debian-devel/2022/01/msg00226.html
>>
>> Assuming I'm not misreading, the ftpteam currently thinks (B).
>
> What do you mean be "misreading"?  My mail I linked above or some
> ftpmaster statements I'm not aware about (or which I was misreading)?

Your mail -- assuming I'm not misinterpreting anything about (B) in a
way that means I misstate the team's view.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: getting pinta updated in Debian

[Stephen Shaw]

On Thu, Mar 3, 2022 at 12:47 PM Gunnar Wolf  wrote:
>
> Timotheus Pokorra dijo [Wed, Mar 02, 2022 at 10:35:36PM +0100]:
> > Hello Mike,
> >
> > I have some experience with Mono packaging in Fedora.
> > I know of the dotnet SIG in Fedora. They made a massive effort, involving
> > Microsoft employees, to get dotnet core built according to the Fedora rules
> > (build from source, not using external files, etc).
> > (...)
> > It is really difficult to package dotnet packages, because of all the nuget
> > dependancies. We have not figured that out for Fedora. Or did not have the
> > volunteers yet to do that.
> >
> > Alternatives to dotnet: Mono, dotgnu
> > https://www.gnu.org/software/dotgnu/
> > "As of December 2012, the DotGNU project has been decommissioned."
> >
> > Mono: it is the alternative to .NET Framework, which Microsoft will support
> > for many years to come. But the new stuff is happening in dotnet, so
> > projects like Pinta are moving from Mono to dotnet.
>
> Uff... .NET -- A reimplementation of the "write once, debug
> everywhere" fiasco :-(
   ^^ Seems like a horribly useless and uninformed clickbait comment


Warning: I'm going to brain dump a bunch of random thoughts :)

Mono is actually now part of dotnet:
https://github.com/dotnet/runtime/tree/main/src/mono
dotnet provides two different runtimes. coreclr and monovm both of
which are largely xplat.
The traditional .NET Framework and Mono are going away in favor of
dotnet. Still largely the same runtime, base class libraries, etc that
.NET developers are used to + all the new features and it's continued
evolution, etc

tl;dr; from my perspective
I've felt like this has been a growing problem with how Linux does
packaging, right or wrong doesn't matter. The fact still remains that
this'll continually become more challenging and/or impossible problem
at some point. Most, if not all, of the current popular programming
languages have some sort of packaging system:
C#, nuget
java, maven
ruby, rubygems
python, pip
node.js, npm
php, pakcagist
js, bower

to name a few.

The current approach is to rebuild ever language from source, but most
devs don't want to re-implement a whole bunch of functionality they
can get with the push of a button by adding some "package". As
programs get more complex there are more libraries being written,
shared, and included. Unless you can completely automate the building
of every package this breaks down really fast.

Maybe its time to re-evaluate this system?
Could we provide some kind of sandbox that builds these projects and
allows for an internet connection to import all of the "packages"? Is
it possible to ensure that the packages are exclusively pulled from
"authorized" sources?

Cheers,
Stephen

Re: getting pinta updated in Debian

[Gunnar Wolf]

Timotheus Pokorra dijo [Wed, Mar 02, 2022 at 10:35:36PM +0100]:
> Hello Mike,
> 
> I have some experience with Mono packaging in Fedora.
> I know of the dotnet SIG in Fedora. They made a massive effort, involving
> Microsoft employees, to get dotnet core built according to the Fedora rules
> (build from source, not using external files, etc).
> (...)
> It is really difficult to package dotnet packages, because of all the nuget
> dependancies. We have not figured that out for Fedora. Or did not have the
> volunteers yet to do that.
> 
> Alternatives to dotnet: Mono, dotgnu
> https://www.gnu.org/software/dotgnu/
> "As of December 2012, the DotGNU project has been decommissioned."
> 
> Mono: it is the alternative to .NET Framework, which Microsoft will support
> for many years to come. But the new stuff is happening in dotnet, so
> projects like Pinta are moving from Mono to dotnet.

Uff... .NET -- A reimplementation of the "write once, debug
everywhere" fiasco :-(

Re: NEW processing friction

[Andreas Tille]

Am Thu, Mar 03, 2022 at 09:57:26AM -0700 schrieb Sean Whitton:
> > PS: I'm currently considering writing up some summary of the bunch
> > of threads that was born out of my initial mail.
> >
> > [1] https://lists.debian.org/debian-devel/2022/01/msg00226.html
> 
> Assuming I'm not misreading, the ftpteam currently thinks (B).

What do you mean be "misreading"?  My mail I linked above or some
ftpmaster statements I'm not aware about (or which I was misreading)?

Kind regards

   Andreas.

-- 
http://fam-tille.de

Re: NEW processing friction

[Sean Whitton]

Hello,

On Thu 03 Mar 2022 at 07:36am +01, Andreas Tille wrote:

> Hi Sean,
>
> Am Wed, Mar 02, 2022 at 08:33:35AM -0700 schrieb Sean Whitton:
>>
>> I'm sorry to be responding only a month later, but I think there are
>> some reasons why binNEW is not the worst place to be doing these extra
>> checks: packages with SONAME bumps are typically C or C++ projects and
>> these are (i) large, such that d/copyright is more likely to drift
>> simply because of the volume of files; and (ii) often contain embedded
>> code copies with different copyright and licensing.  My own NEW
>> experience is that I've consistently found more problems in binNEW
>> packages than anywhere else.
>
> Thanks a lot for your insight into this topic.  I'd like to stress my
> point (again) that besides I was naively thinking that the checks done
> on packages that are passing new due to binary package changes (which
> are not only due to changed SONAME) my main point is that I've found
> a discrepancy in statements of ftpmaster teams.  My question whether
> we agree to status A or B[1] was not yet answered (or I missed some
> explicit answer).
>
> Kind regards
>
>  Andreas.
>
> PS: I'm currently considering writing up some summary of the bunch
> of threads that was born out of my initial mail.
>
> [1] https://lists.debian.org/debian-devel/2022/01/msg00226.html

Assuming I'm not misreading, the ftpteam currently thinks (B).

-- 
Sean Whitton

Re: lintian groff-message warning "can't set the locale"

[Felix Lechner]

Hi Nick,

On Sun, Oct 25, 2020 at 6:23 PM Nick Black  wrote:
>
> My Salsa CI pipeline is blowing up in the lintian step, with
> lots of warnings of the form:

Following an upgrade of the Salsa runners to bullseye [1] the bug you
reported here originally was closed. [2]

Thank you for using Lintian!

Kind regards,
Felix Lechner

[1] https://salsa.debian.org/salsa/support/-/issues/277#note_299577
[2] https://bugs.debian.org/973313

Bug#1006721: ITP: node-remark-slide -- simple, in-browser, markdown-driven slideshow tool

[Doug Torrance]

Package: wnpp
Severity: wishlist
Owner: Doug Torrance 
X-Debbugs-Cc: debian-devel@lists.debian.org, dtorra...@debian.org

* Package name: node-remark-slide
 Version : 0.15.0
 Upstream Author : Ole Petter Bang 
* URL : https://github.com/gnab/remark
* License : MIT
 Programming Lang: JavaScript
 Description : simple, in-browser, markdown-driven slideshow tool

A simple, in-browser, markdown-driven slideshow tool targeted at
people who know their way around HTML and CSS, featuring:

* Markdown formatting, with smart extensions
* Presenter mode with markdown formatted speaker notes and cloned
 slideshow view
* Syntax highlighting, supporting a range of languages
* Slide scaling, thus similar appearance on all devices / resolutions
* Simple markdown templates for customized slides
* Touch support for smart phones and pads, i.e. swipe to navigate
 slides

I intend to maintain this package under the umbrella of the Debian Javascript
Team.