Re: Difficult Packaging Practices

[Vincent Bernat]

 ❦ 27 mai 2019 16:15 +10, Ben Finney :

>> If you just want to get upstream's idea of their package onto a system
>> with their release schedule and their recommended dependency versions,
>> there are better ways than getting a package into Debian.
>
> In the Debian mentors forum (that is, the chat channel, the mailing
> list, etc.) we make a point of saying: that's fine!
>
> Not every package needs to be in Debian, for its users to install that
> package. Someone who wants what you describe above can learn how to make
> a Debian package that will only be side-loaded from that community's own
> repository, or whatever.

People using tools like fpm will never get familiar with our tools and
will never be contributors.
-- 
The man who sets out to carry a cat by its tail learns something that
will always be useful and which never will grow dim or doubtful.
-- Mark Twain


signature.asc
Description: PGP signature

Re: Consensus Call: Do We Want to Require or Recommend DH; comments by 2019-06-16

[Jonas Smedegaard]

Quoting Andreas Tille (2019-05-27 06:29:05)
> On Sun, May 26, 2019 at 07:28:55PM +0200, Vincent Bernat wrote:
> > > We "uphold this reputation" by maintaining many packages, which is 
> > > good.
> > 
> > Do we? I am now using nix to get packages for stuff not in Debian. 
> > Our package count is artificially inflated by *-perl packages, 
> > golang-* packages which may not be present in some other 
> > distributions. But for some ecosystems, we are severely behind. We 
> > may argue we are better on some metrics, but this has nothing to do 
> > with the fact we have so many ways to build a package.
> 
> Some Debian Med people are concerned about the droping usage of Debian 
> Med packages since people prefer BioConda[1] over it.  There is even a 
> scientific paper (I've only seen a printed version not online yet) who 
> compares ways to package biology software.  We are way better than 
> other distributions - but we are lagging begind BioConda a lot.  We 
> have some upstreams who are doing Debian packaging by the help of the 
> Debian Med team but that's just a minor fraction.  Lots of BioConda 
> packages are maintained by Upstream since they consider it easy.
> 
> In short: Our "reputation" is scaring people away to favour other 
> techniques.

We agree that some get scared away from Debian.  Question is why.

Like rpm, Debian arguably has a single unified _core_ structure: 
debian/rules must be a make file.  hat Sam, me, and Vincent disagree on 
in this subthread is is lack of a unified _framework_ like short-form dh 
sequencer being mandatory is what scares people off.

Does that paper you talk about point to _causes_ Debian packaging being 
more scary? Is it a) complexities related to hardening, cross-building, 
bootstrapping etc. or b) lack of a single¹ unified build framework, or 
c) that Debian is "different" in package naming and code availability 
than other system package managers or or misc. language-specific package 
managers, or d) something else than what you snipped from the beginning 
of this subthread?


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Twoi Fani z FanPage czekają na nowy post. Sprawdź.

[Specjalista ds . Facebook’a | Olaf Dyk .]

Dzień dobry,



skuteczne administrowanie*_ FanPage na Facebook’u _*to nasza specjalność.



W związku z tym, pragniemy zaproponować Państwu przesłanie więcej informacji w 
tym zakresie aby zwiększyć zysk Państwa firmy oraz ilość fanów.



Przesłanie odpowiedzi o treści *TAK*, umożliwi nam kontakt z Państwem.



Ponieważ sami prowadzimy biznes, jesteśmy świadomi, że podstawą każdej firmy są 
klienci.



Zadbamy o przypływ nowych klientów dla Państwa firmy .



 
Pozdrawiam Serdecznie
Specjalista ds.Facebook’a | Olaf Dyk.

Re: Difficult Packaging Practices

[Ben Finney]

Sam Hartman  writes:

> If you just want to get upstream's idea of their package onto a system
> with their release schedule and their recommended dependency versions,
> there are better ways than getting a package into Debian.

In the Debian mentors forum (that is, the chat channel, the mailing
list, etc.) we make a point of saying: that's fine!

Not every package needs to be in Debian, for its users to install that
package. Someone who wants what you describe above can learn how to make
a Debian package that will only be side-loaded from that community's own
repository, or whatever.

Perhaps that needs to be stated louder or more consistently?

-- 
 \   “Truth is stranger than fiction, but it is because fiction is |
  `\ obliged to stick to possibilities, truth isn't.” —Mark Twain, |
_o__)  _Following the Equator_ |
Ben Finney

Bug#929606: ITP: dataset-fashion-mnist -- (DL-Policy) A MNIST-like fashion product database.

[Mo Zhou]

Package: wnpp
Severity: wishlist
Owner: Mo Zhou 

* Package name: dataset-fashion-mnist
* URL : https://github.com/zalandoresearch/fashion-mnist
* License : MIT
  Description : A MNIST-like fashion product database.

This is a part of DL-Policy[1]'s experiments.

The first, typical dataset used by everyone who started to learn machine
learning and deep learning is very possibly MNIST[2].  MNIST had been
used for over 30 years by researchers and engineers to valiate their
algorithms and learning frameworks, etc. However, The original MNIST
dataset doesn't have (I didn't find it) an explict license. And I have
to use an alternative -- the modern replacement of that MNIST dataset,
i.e. fashion-mnist. It has an explicit MIT license.

Packaging this dataset is to some extent meaningful:

  1. Dataset size: ~30MiB. Very friendly to any modern storage devices.
  2. A "UnitTest" dataset for virtually any deep learning framework.
 Developers can use this dataset to validate any machine learning
 or deep learning frameworks.
  3. Very easy to train and validate. This is a tiny "toy" dataset.
 A weak CPU can train models on this dataset in a reasonable timeframe.
  4. As an DL-Policy-compliant dataset package example.
  5. The dataset it self is frozen. Subsequent maintainance burden after
 the initial upload is nearly zero ...

See also:
https://github.com/zalandoresearch/fashion-mnist#why-we-made-fashion-mnist

[1] https://salsa.debian.org/lumin/deeplearning-policy
[2] http://yann.lecun.com/exdb/mnist/

Re: Consensus Call: Do We Want to Require or Recommend DH; comments by 2019-06-16

[Scott Kitterman]

On May 25, 2019 5:26:47 PM UTC, Sam Hartman  wrote:
>
>Hi. Almost two weeks ago [1] I  started a discussion on whether we
>wanted to increase the strength of our recommendation of the dh
>sequencer from debhelper.
>This message is a consensus call summarizing my reading of the
>discussion.
...
>
>Please send any comments by 2019-06-16.
>Please distinguish cases where you believe I've misread the discussion
>from new contributions intended to change the community's view.
>
>...
>Is Not Using DH a Bug?
>==
>
>It's certainly not an RC bug.  There was some talk of it eventually
>being an RC bug if a new package doesn't use DH (and doesn't fall under
>an exception).  I don't think there's consensus for that today.
>
>It's obviously not a bug if one of the exceptions applies, but once the
>lintian tag exists, overriding that tag sounds to me like best practice
>to document the exception.  (Presumably for things like Haskell we'd
>want Lintian to be smart enough to figure that out on its own)
>
>To some extent I'm extrapolating from implications of the rest of the
>consensus call for the rest of this section.  There was some discussion
>of whether not using dh should be a normal bug, but the comments about
>that were inconsistent with the rest of the discussion.  But if the
>consensus call above that existing packages (absent exceptional
>circumstances) should use dh stands, that's approximately the
>definition
>of a normal bug.  So my reading is that absent exceptional
>circumstances, not using dh is a normal severity bug.
>
>It doesn't mean you should file that bug and it doesn't mean that you
>should go fix that bug.  We definitely didn't get the kind of support
>we'd be needing for a mass bug filing or anything like that.  It
>wouldn't serve a point.  This isn't atypical.  There are a lot of
>things
>lintian flags that are technically bugs, but we wouldn't want to mass
>file all lintian tags (even if we could filter out false positives) as
>bugs.
>
>This paragraph is very much my interpretation.  I'd personally say that
>if you're going to file a bug that a particular package doesn't use dh,
>have a good reason and document it in that bug.  Your reason might be
>"I
>want to contribute; I'm willing to dedicate time and updating the
>packaging would make it much more appealing to work on."  Often your
>reason will be that there's some other problem, migrating to dh will
>fix
>that problem, and between the time you're willing to spend and the time
>you hope the maintainer will spend it's worth doing a good job of that
>migration.
>
>My interpretation of our standard practices is that maintainers have
>wide discretion in which bugs they work on.  That said, if someone
>submits a patch, it's good if you review it.  It's fine to ask them to
>do the necessary testing work and it's fine to hold them to the same
>high standards that you hold yourself to.  If they are less experienced
>with the package it might make sense for them to do tests that make up
>for that experience gap.  None of this  changes any of that or asks
>maintainers to treat bugs about dh differently than other bugs.

On what basis is it a bug of any kind?

A lintian check does not a buggy package make.

Assuming a package that is otherwise working correctly, you have a policy 
compliant, fully functional package.  That seems to me like the very definition 
of not a bug.

If we want to make not using dh except in certain situations a bug, it seems 
like something for a policy should kind of item.  We have an existing process 
for updating policy, so this should probably be kicked over there for further 
evaluation.

Scott K

Re: Consensus Call: Do We Want to Require or Recommend DH; comments by 2019-06-16

[Andreas Tille]

On Sun, May 26, 2019 at 07:28:55PM +0200, Vincent Bernat wrote:
> > We "uphold this reputation" by maintaining many packages, which is
> > good.
> 
> Do we? I am now using nix to get packages for stuff not in Debian. Our
> package count is artificially inflated by *-perl packages, golang-*
> packages which may not be present in some other distributions. But for
> some ecosystems, we are severely behind. We may argue we are better on
> some metrics, but this has nothing to do with the fact we have so many
> ways to build a package.

Some Debian Med people are concerned about the droping usage of Debian
Med packages since people prefer BioConda[1] over it.  There is even a
scientific paper (I've only seen a printed version not online yet) who
compares ways to package biology software.  We are way better than other
distributions - but we are lagging begind BioConda a lot.  We have some
upstreams who are doing Debian packaging by the help of the Debian Med
team but that's just a minor fraction.  Lots of BioConda packages are
maintained by Upstream since they consider it easy.

In short:  Our "reputation" is scaring people away to favour other
techniques. 

Kind regards

   Andreas.

[1] https://bioconda.github.io/

-- 
http://fam-tille.de

Re: Difficult Packaging Practices

[Russ Allbery]

Sam Hartman  writes:

> I think it's a combination of a lot of things.  We have high standards,
> a lot of complexity, and you have to get most or all of that right to
> contribute.  You have to have a package that meets our standards.  You
> have to have a copyright file that meets our standards.  You have to be
> able to figure out our processes.  You have to be willing to follow our
> processes.  And you eventually have to deal with the PGP mess.

> If you don't find value in the things where we have high standards,
> Debian doesn't make a lot of sense.  If you just want to get upstream's
> idea of their package onto a system with their release schedule and
> their recommended dependency versions, there are better ways than
> getting a package into Debian.

This is my experience as well.  I've occasionally tried to get people at
work (at various jobs) interested in packaging software for Debian,
without all that much success.  The problem seems less any one specific
thing and more that they're perfectly content with a Debian package
created by running fpm on some install tree, and don't see the point in
doing any more work than that.  This is usually in the context where
there's some other config management system in use, so to them all the
packaging format is good for is as a container of files with a version
number attached.

It's not that they don't understand the merits of having what they think
of as the base operating system properly maintained and integrated; it's
more that they don't see any value in doing that work for the incremental
thing that they're adding.  They cobble together some combination of local
config management and a deployment method until it works and then move on
to some (from their perspective) more interesting problem.

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

Re: Difficult Packaging Practices

[Jérémy Lal]

Le dim. 26 mai 2019 à 23:01, Sam Hartman  a écrit :

> > "Adrian" == Adrian Bunk  writes:
>
> Adrian> It is a problem for people making their first contributions
> Adrian> to Debian to get them into unstable. The problem here is
> Adrian> lack of sponsors willing to do proper reviews and then
> Adrian> uploads. Usually the package in question is already using
> Adrian> dh.
>
> My experience is consistent with the above.
> I can't send links because most of my conversations with people getting
> started contributing to Debian  have been that: actual conversations
> with lungs compressing air to blow out mouths.
>
> Unfortunately, I've found that it's often a combination of factors.
>
> The one first cited is  the difficulty finding a sponsor.
>

There's a gap between getting some unknown software into debian,
and getting well-known software into debian.
Some well-determined upstream develop can manage to get software
into debian, and even get it into stable, and then just quit maintaining it
!
On the other hand, when a fellow DD uploads a software it usually means
that piece is worth it. So i'm not that keen on making it easier to get any
kind
of software into debian.


> But in at least some cases it's more complex than that.
>
> for example in one case someone was talking about finding a sponsor.  I
> said that I didn't normally sponsor packages I couldn't adequately test,
> so that limited what I'd sponsor, but if the contributor could find
> something within that set I'd sponsor it.
>
> He came up with something.
> Then he said but really the hard part there was not the sponsorship, but
> the dependency problem
> Apparently upstream had forked some library already in Debian and you
> had to use the fork for the package to work.
>

It might also mean the upstream software is still maturing and not ready for
prime time.

I think it's a combination of a lot of things.  We have high standards,
> a lot of complexity, and you have to get most or all of that right to
> contribute.  You have to have a package that meets our standards.  You
> have to have a copyright file that meets our standards.


When it's hard to make upstream conform to DFSG it's either easy to fix,
or impossible to fix. So it's not that hard to deal with.


> You have to be
> able to figure out our processes.  You have to be willing to follow our
> processes.  And you eventually have to deal with the PGP mess.
>

Are you referring to the identity check ?
That mess is onto the uploader's hand.
You don't need to have your identity checked as an upstream author, and
the identity check is the best part of subscribing to a community.


> If you don't find value in the things where we have high standards,
> Debian doesn't make a lot of sense.
> If you just want to get upstream's idea of their package onto a system
> with their release schedule and their recommended dependency versions,
> there are better ways than getting a package into Debian.
>

There are even ways that are supported by software available in Debian !
(thinking of flatpak but many other ways to allow users to install software
easily).

--
Jérémy

Re: Consensus Call: Do We Want to Require or Recommend DH; comments by 2019-06-16

[Philip Hands]

Adrian Bunk  writes:

...
> Often the most difficult part of packaging are the unique rules the 
> Debian ftp team requires for debian/copyright that are not required in 
> distributions with actual lawyers. That's a completely separate topic.

That seems needlessly snide, and glosses over the fact that we are bound
by constraints that other distributions are not, such as giving a damn
about the license conditions we inflict on our downstreams, which I
suspect the lawyers you allude to are not being retained to contemplate.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Difficult Packaging Practices

[Sam Hartman]

> "Adrian" == Adrian Bunk  writes:

Adrian> It is a problem for people making their first contributions
Adrian> to Debian to get them into unstable. The problem here is
Adrian> lack of sponsors willing to do proper reviews and then
Adrian> uploads. Usually the package in question is already using
Adrian> dh.

My experience is consistent with the above.
I can't send links because most of my conversations with people getting
started contributing to Debian  have been that: actual conversations
with lungs compressing air to blow out mouths.

Unfortunately, I've found that it's often a combination of factors.

The one first cited is  the difficulty finding a sponsor.
But in at least some cases it's more complex than that.

for example in one case someone was talking about finding a sponsor.  I
said that I didn't normally sponsor packages I couldn't adequately test,
so that limited what I'd sponsor, but if the contributor could find
something within that set I'd sponsor it.

He came up with something.
Then he said but really the hard part there was not the sponsorship, but
the dependency problem
Apparently upstream had forked some library already in Debian and you
had to use the fork for the package to work.

I think it's a combination of a lot of things.  We have high standards,
a lot of complexity, and you have to get most or all of that right to
contribute.  You have to have a package that meets our standards.  You
have to have a copyright file that meets our standards.  You have to be
able to figure out our processes.  You have to be willing to follow our
processes.  And you eventually have to deal with the PGP mess.

If you don't find value in the things where we have high standards,
Debian doesn't make a lot of sense.
If you just want to get upstream's idea of their package onto a system
with their release schedule and their recommended dependency versions,
there are better ways than getting a package into Debian.


--Sam

Re: Consensus Call: Do We Want to Require or Recommend DH; comments by 2019-06-16

[Adrian Bunk]

On Sun, May 26, 2019 at 11:34:39AM +0200, Vincent Bernat wrote:
>...
> We have a reputation of having difficult
> packaging practices. We uphold this reputation as long as we have so
> many ways to do the same thing.

  [citation needed]

I do honestly not know what statements/comparisons from people outside
Debian are the basis for this claim, and whether making dh more mandatory
is even related to them.

It is a problem for people making their first contributions to Debian to 
get them into unstable. The problem here is lack of sponsors willing to 
do proper reviews and then uploads. Usually the package in question is 
already using dh.

Often the most difficult part of packaging are the unique rules the 
Debian ftp team requires for debian/copyright that are not required in 
distributions with actual lawyers. That's a completely separate topic.

It is perfectly possible that there is something else I am not aware
of, and you are assuming everyone in this discussion is.

It would therefore be really useful if you could send some links to 
statements from people outside Debian *why* they consider Debian to
have difficult packaging practices.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Consensus Call: Do We Want to Require or Recommend DH; comments by 2019-06-16

[Vincent Bernat]

 ❦ 26 mai 2019 12:04 +02, Jonas Smedegaard :

>> > * People who make changes across the archive such as enabling 
>> >   hardening, cross-building, bootstrapping, etc benefit 
>> >   significantly from more uniformity in packaging practices.  The 
>> >   time they spend working on packages that use dh is significantly 
>> >   less.  That is, people working on making Debian more reproducible 
>> >   benefit from when we adopt more uniform practices.
>> 
>> It has also been said that non-unformity makes also the life of 
>> everybody more difficult when they look at a random package. This 
>> includes non-DD/DM people. We have a reputation of having difficult 
>> packaging practices. We uphold this reputation as long as we have so 
>> many ways to do the same thing.
>
> We "uphold this reputation" by maintaining many packages, which is
> good.

Do we? I am now using nix to get packages for stuff not in Debian. Our
package count is artificially inflated by *-perl packages, golang-*
packages which may not be present in some other distributions. But for
some ecosystems, we are severely behind. We may argue we are better on
some metrics, but this has nothing to do with the fact we have so many
ways to build a package.
-- 
English literature's performing flea.
-- Sean O'Casey on P. G. Wodehouse


signature.asc
Description: PGP signature

Re: Hurd-i386 and kfreebsd-{i386,amd64} removal

[John Paul Adrian Glaubitz]

On 5/26/19 1:22 PM, Bastian Blank wrote:
> [SN: Trimmed Cc list]
> 
> Hi John

My name is Adrian. Thanks.

> On Sun, May 26, 2019 at 06:48:36AM +0200, John Paul Adrian Glaubitz wrote:
>> Could you PLEASE stop posting to debian-ports@? You are sending these mails 
>> to every Debian Ports architecture mailing list.
> 
> Please stop shouting.  Please fix your MUA to produce readable mails.
> Thank you.

Please stop sending mails to users which are not affected by your discussion.

I'm sorry but after kindly asking two times not to use this address for
this discussion as you are reaching way too many unrelated lists, I think
it's a fair thing to spell that "please" in capital letters.

> Also -ports goes to all port specific mailing lists.

No, debian-ports goes to every architecture list which is really annoying
when you're on all these lists.

I got this email through the following mailing lists:

debian-arm, debian-alpha, debian-hppa, debian-ia64, debian-68k, debian-powerpc,
debian-sparc, debian-superh, debian-riscv. None of these are related to BSD
or Hurd yet the discussion was on these lists.

It's not related to Debian Ports and therefore not too much to ask to reduce
the noise on unrelated mailing lists. And I would also like to continue using
Thunderbird without having to mess with the configuration now.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Hurd-i386 and kfreebsd-{i386,amd64} removal

[Bastian Blank]

[SN: Trimmed Cc list]

Hi John

On Sun, May 26, 2019 at 06:48:36AM +0200, John Paul Adrian Glaubitz wrote:
> Could you PLEASE stop posting to debian-ports@? You are sending these mails 
> to every Debian Ports architecture mailing list.

Please stop shouting.  Please fix your MUA to produce readable mails.
Thank you.

Also -ports goes to all port specific mailing lists.

Bastian

-- 
Without facts, the decision cannot be made logically.  You must rely on
your human intuition.
-- Spock, "Assignment: Earth", stardate unknown

Re: Consensus Call: Do We Want to Require or Recommend DH; comments by 2019-06-16

[Jonas Smedegaard]

Quoting Vincent Bernat (2019-05-26 11:34:39)
>  ❦ 25 mai 2019 13:26 -04, Sam Hartman :
> 
> > * People who make changes across the archive such as enabling 
> >   hardening, cross-building, bootstrapping, etc benefit 
> >   significantly from more uniformity in packaging practices.  The 
> >   time they spend working on packages that use dh is significantly 
> >   less.  That is, people working on making Debian more reproducible 
> >   benefit from when we adopt more uniform practices.
> 
> It has also been said that non-unformity makes also the life of 
> everybody more difficult when they look at a random package. This 
> includes non-DD/DM people. We have a reputation of having difficult 
> packaging practices. We uphold this reputation as long as we have so 
> many ways to do the same thing.

We "uphold this reputation" by maintaining many packages, which is good.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Consensus Call: Do We Want to Require or Recommend DH; comments by 2019-06-16

[Vincent Bernat]

 ❦ 25 mai 2019 13:26 -04, Sam Hartman :

> * People who make changes across the archive such as enabling hardening,
>   cross-building, bootstrapping, etc benefit significantly from more
>   uniformity in packaging practices.  The time they spend working on
>   packages that use dh is significantly less.  That is, people working
>   on making Debian more reproducible benefit from when we adopt more
>   uniform practices.

It has also been said that non-unformity makes also the life of
everybody more difficult when they look at a random package. This
includes non-DD/DM people. We have a reputation of having difficult
packaging practices. We uphold this reputation as long as we have so
many ways to do the same thing.
-- 
Say what you mean, simply and directly.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature