Re: git & Debian packaging sprint report

[Sean Whitton]

Hello,

On Fri 12 Jul 2019 at 02:06PM +02, Ansgar Burchardt wrote:

> Depends on a lot of things.  As far as I understand this work is in a
> very early stage and a first brainstorming session on what problem this
> is intended to solve, why one should consider doing it, and possible
> requirements is planned for DebConf[1].
>
> Without having any of these, it is hard to comment on anything.

Figuring out how this is going to be deployed as Debian infrastructure
is indeed at an early stage.

I don't think it is accurate to think of the whole project as being at
an early stage.  From my perspective, the hardest problem to solve was
conversion of git trees to uploads, on the server side, in a way that is
user friendly.  We take ourselves to have solved that problem, which to
my mind renders this project beyond the early stages of development.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Is it the job of Lintian to push an agenda?

[Sean Whitton]

Hello,

On Sat 13 Jul 2019 at 11:10PM +02, Jérémy Lal wrote:

> the question
> "Is it the job of Lintian to push an agenda?"
> is a good question, and it would be nice to get a general answer,
> separately from the technical issue about sysvinit scripts.

I think that it is useful to Debian for Lintian to be a bit more
opinionated, and a bit less conservative, than Policy is.

Especially if you turn on all the tag levels, Lintian pushes a fairly
strong set of ideas about what packages should look like.  Most everyone
will find something they disagree with, but it gets us to think about
these things and consider whether they might be good ideas.  Over time,
tags can get turned down in severity or changes can make their way into
the Policy Manual.

Of course, if Lintian gets too far "ahead" of Policy then it would be
less useful.  What I think is useful to us is for it to be just a little
bit more pushy than Policy, as indeed it is.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Is it the job of Lintian to push an agenda?

[Sean Whitton]

Hello,

On Sat 13 Jul 2019 at 02:22PM -07, Russ Allbery wrote:

> Matthias Klumpp  writes:
>
>> With two Debian stable releases defaulting to systemd now, I think a
>> solid case could be made to at least relax the "must" requirement to a
>> "should" in policy (but that should better go to the respective bug
>> report).
>
> The Policy process is not equipped to deal with this because that process
> requires fairly consensus, and I don't believe that's possible to reach on
> this topic.
>
> I don't know what decision-making process the project should use here: a
> big thread on debian-devel (wow, that sounds fun), a bunch of in-person
> conversations at DebConf (probably way more productive but excludes some
> folks), the TC (tried and didn't work very well), a GR, some new mediated
> consensus process, or what.  Or maybe some working group that goes all-in
> on creating a "good enough" automated translation from unit files to
> sysvinit scripts and we support sysvinit that way and thereby dodge the
> problem.
>
> But, and I'm putting my Policy Editor delegate hat on to say this, I
> believe the Policy process is the wrong tool to use here because it will
> not converge.  (That said, Sean, as the other Policy Editor delegate,
> should feel free to disagree if he thinks I'm wrong.)

Just to note that I'm in agreement with Russ on this.  While things may
well change in the future (either the project's opinion on init or the
way Policy works), Policy is not the way to do this for the time being.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Packaging Games with In-App Purchases

[Bagas Sanjaya]

Hello,

Let's imagine that I will package a city-building game titled makecity. The 
game is licensed under GPL(v3), but it has
virtual currency which can be purchased by real money, that is the currency is 
"premium currency" (which is hard or
impossible to get freely except by purchasing). However, premium currency and 
in-app purchases (IAP) is integral in the
game, because some features and items can only be bought by premium currency.

Any suggestion on packaging makecity and other programs/games with IAPs?

Cheers, Bagas

--
An old man doll... just what I always wanted! - Clara

Re: Detecting (upcoming) problems using automatic tests

[Julian Andres Klode]

On Thu, Jul 11, 2019 at 10:23:59PM -0300, Chris Lamb wrote:
> Hi Julian,
> 
> > I was just thinking that adding deprecation warnings and stuff
> > to software is "nice", but the problem with warnings is that they
> > tend to not break tests.
> 
> I'm guessing you have a particular package or use-case in mind that
> sparked this idea — could you share? That might help make this abstract
> concept a little more concrete.
> 
> I'm also assuming that you meant for this to be wider than just GCC
> so, for example, making -Werror global wouldn't be sufficient as it
> wouldn't catch, say, warnings from pure-Python packages.

I was thinking that if we add a run-time warning to APT because we
want to remove or change something next release cycle that that probably
won't break your autopkgtest if it just looks for success.

This means that there is not really much advantage to having deprecation
warnings, as everything will "surprisingly" break the next release cycle.

> 
> > I feel like it would be nice to come up with a standard environment
> > variable to turn warnings into errors, so we can ensure issues are
> > fixed and the warnings are actually useful.
> 
> Hm, although perhaps DEB_BUILD_OPTIONS is the prefered place for this
> kind of toggle rather than an environment variable?

For builds, yes; for autopkgtest I guess not.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

unsigned repositories (was: Re: Dropping Release and Release.gpg support from APT)

[Julian Andres Klode]

On Tue, Jul 09, 2019 at 08:53:04PM +0200, Julian Andres Klode wrote:
> So,
> 
> we currently have code dealing with falling back from InRelease
> to Release{,.gpg} and it's all a bit much IMO. Now that buster
> has been released with an InRelease file, the time has IMO come for
> us to drop support for the old stuff from APT!

One thing also forgotten in all that excitement is unsigned
repositories and repositories without a *Release file.

Now, I'd argue that having support for these repositories, while
convenient, is wrong: I think it makes a lot more sense for people
to "needlessly" sign repositories and not have those code paths in
apt. Because if we have a mistake in these code paths and accidentally
don't verify a signature, that's really bad; but if you needlessly
sign a repository, it's hardly much effort.

We can maybe significantly reduce that risk by just providing a
fake gpgv that successfully verifies any file passed and using
that for unsigned repositories instead, and just you know, fake-sign
the repository (like serve an InRelease file without an actual
signature).

I mean, I don't really know, but I always feel a bit scared by
how complex the verification stuff is.
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Re: Dropping Release and Release.gpg support from APT

[Ben Hutchings]

On Wed, 2019-07-10 at 10:17 +0200, Julian Andres Klode wrote:
> On Wed, Jul 10, 2019 at 10:10:41AM +0200, Philipp Kern wrote:
> > On 2019-07-10 10:04, Julian Andres Klode wrote:
> > > On Wed, Jul 10, 2019 at 10:35:25AM +0800, Paul Wise wrote:
> > > > On Wed, Jul 10, 2019 at 2:53 AM Julian Andres Klode wrote:
> > > > 
> > > > > Timeline suggestion
> > > > > ---
> > > > > now add a warning to apt 1.9.x for repositories w/o 
> > > > > InRelease, but Release{,.gpg}
> > > > > Aug/Sep turn the warning into an error, overridable with an 
> > > > > option (?)
> > > > > Q1 2020 remove the code
> > [...]
> > > We do need them to ship InRelease files. I just filed an issue for OBS
> > > to do that. Given how long we had InRelease file, and how confusing it
> > > is to not provide InRelease files (not to mention that it doubles the
> > > traffic for no-change cases), I'm surprised they aren't using InRelease
> > > files yet.
> > 
> > Given the timeline, shouldn't we also get oldstable to ship an InRelease
> > file?
> 
> What's the use case for having oldstable in your sources.list on
> unstable/testing machines?

I currently have "deb-src ... jessie main" in my sources.list so I can
fetch packages that (might) need a security update.

Obviously I build them in a jessie chroot, but it seems like overkill
to do that for the initial source download too.  And back when I was
doing triage for Debian LTS I wouldn't build at all - I would only look
at the source to see if a bug was present in the old version.

Ben.

> But yes, I think it would make sense to ship an InRelease file
> with 9.10 now that we are capable of having those.
> 
-- 
Ben Hutchings
One of the nice things about standards is that
there are so many of them.




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

Re: Is it the job of Lintian to push an agenda?

[Russ Allbery]

Russ Allbery  writes:

> The Policy process is not equipped to deal with this because that
> process requires fairly consensus, and I don't believe that's possible
> to reach on this topic.

Argh.  That should have been "fairly strong consensus" and fell victim to
last-minute editing.

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

Re: Is it the job of Lintian to push an agenda?

[Russ Allbery]

Matthias Klumpp  writes:

> With two Debian stable releases defaulting to systemd now, I think a
> solid case could be made to at least relax the "must" requirement to a
> "should" in policy (but that should better go to the respective bug
> report).

The Policy process is not equipped to deal with this because that process
requires fairly consensus, and I don't believe that's possible to reach on
this topic.

I don't know what decision-making process the project should use here: a
big thread on debian-devel (wow, that sounds fun), a bunch of in-person
conversations at DebConf (probably way more productive but excludes some
folks), the TC (tried and didn't work very well), a GR, some new mediated
consensus process, or what.  Or maybe some working group that goes all-in
on creating a "good enough" automated translation from unit files to
sysvinit scripts and we support sysvinit that way and thereby dodge the
problem.

But, and I'm putting my Policy Editor delegate hat on to say this, I
believe the Policy process is the wrong tool to use here because it will
not converge.  (That said, Sean, as the other Policy Editor delegate,
should feel free to disagree if he thinks I'm wrong.)

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

Re: Is it the job of Lintian to push an agenda?

[Jérémy Lal]

Hi,

the question
"Is it the job of Lintian to push an agenda?"
is a good question, and it would be nice to get a general answer,
separately from the technical issue about sysvinit scripts.

Jérémy

Re: Is it the job of Lintian to push an agenda?

[Matthias Klumpp]

Am Sa., 13. Juli 2019 um 22:04 Uhr schrieb Vincent Bernat :
>
>  ❦ 13 juillet 2019 11:52 -07, Russ Allbery :
>
> >> Previously, we had a sort of agreement (through the TC decision) that
> >> such scripts should be maintained by people caring about them and we
> >> should only act on bug reports with proper patches to have them.
> >
> > I don't agree that this was ever the agreement.
>
> I was referring to
>  but it seems
> it only applies to non-SysV init script, my bad.
>
> I am still unhappy with the situation, but I don't think it is worth
> arguing about it as I am pretty sure it will have no impact whatsoever.

What will have an impact is moving
 forward, I
guess.
Writing init scripts for sysvinit is a massive amount of work for
non-simple cases, and my own software as well as other software
projects don't actually ship sysvinit scripts anymore (simply because
testing them just isn't worth the time and effort if you can actually
achieve what you wanted easier).
While I think it's fair to request from package maintainers to merge
compatibility scripts for sysvinit, forcing them to write sysvinit
scripts while our default init systemd is systemd and where even
testing those scripts is a major pain is IMHO not.
There was a long discussion on not-shipping / dropping sysvinit
scripts in a request to the TC in 2016
, I am
assuming you meant that when talking about a TC ruling. No decision
was made there though, and normal policy processes should resolve
this.
With two Debian stable releases defaulting to systemd now, I think a
solid case could be made to at least relax the "must" requirement to a
"should" in policy (but that should better go to the respective bug
report).

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Re: Is it the job of Lintian to push an agenda?

[Vincent Bernat]

 ❦ 13 juillet 2019 11:52 -07, Russ Allbery :

>> Previously, we had a sort of agreement (through the TC decision) that
>> such scripts should be maintained by people caring about them and we
>> should only act on bug reports with proper patches to have them.
>
> I don't agree that this was ever the agreement.

I was referring to
 but it seems
it only applies to non-SysV init script, my bad.

I am still unhappy with the situation, but I don't think it is worth
arguing about it as I am pretty sure it will have no impact whatsoever.
-- 
Modularise.  Use subroutines.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Is it the job of Lintian to push an agenda?

[Niels Thykier]

Russ Allbery:
>> Thanks to this new Lintian tag, the current situation is that packages
>> won't pass NEW without a SysV init script (unless a FTP-masters ignore
>> this specific tag despite its severity).
> I haven't worked on Lintian in several years, so perhaps my information is
> stale, but at least previously ftp-master rejects were not based on
> severity, but rather on a hard-coded list of tags maintained by
> ftp-master.

For reference, Russ is correct.  For the people curious about the
concrete tags, please see [1].

Thanks,
~Niels

[1] https://ftp-master.debian.org/#lintianrejects

Re: Is it the job of Lintian to push an agenda?

[Scott Kitterman]

On Saturday, July 13, 2019 2:52:59 PM EDT Russ Allbery wrote:
> Vincent Bernat  writes:
> > Thanks to this new Lintian tag, the current situation is that packages
> > won't pass NEW without a SysV init script (unless a FTP-masters ignore
> > this specific tag despite its severity).
> 
> I haven't worked on Lintian in several years, so perhaps my information is
> stale, but at least previously ftp-master rejects were not based on
> severity, but rather on a hard-coded list of tags maintained by
> ftp-master.

That's correct.  We do also do a general review of the package and lintian 
feedback is one thing we do consider.  Personally, I don't recall having 
rejected a package for this.  I believe I have accepted a few and then filed a 
bug (even prior to the lintian check).

Scott K

Re: Is it the job of Lintian to push an agenda?

[Russ Allbery]

Vincent Bernat  writes:

> Lintian got a new tag to enforce Policy 9.11:

>  Packages may integrate with these replacement init systems by
>  providing implementation-specific configuration information
>  about how and when to start a service or in what order to run
>  certain tasks at boot time. However, any package integrating
>  with other init systems must also be backwards-compatible with
>  sysvinit by providing a SysV- style init script with the same
>  name as and equivalent functionality to any init-specific job,
>  as this is the only start-up configuration method guaranteed to
>  be supported by all init implementations.

Policy 9.11 and this provision were introduced in Policy 3.9.4, which was
published in August of 2012.  I'm therefore very confused by this
statement:

> As usual with a policy change, it will take years.

since this is not a recent Policy change (in fact, prior to this section
of Policy there was no documentation of support for any init system
*other* than sysvinit), and it's *been* years.  So far as I can tell, the
only thing that's new is the Lintian tag.  Lintian aspires to testing as
much of Policy as possible, so my baseline assumption would be that
someone contributing to Lintian just got around to doing the
implementation work.

The Policy provision is, as you noted in the bug references I snipped,
arguably buggy in that it doesn't clarly allow for systemd units that
should not or cannot correspond to init scripts, and it could definitely
use some tweaking (as, possibly, could the Lintian tag), but the base
requirement for providing a corresponding sysvinit init script to start a
daemon that is started via a systemd unit file is not new and has been the
Policy requirement since before systemd became the default init system.

> Some people will push back and the result is that a few people can
> impose to everyone else the additional work to maintain SysV init
> script.

Continued support for sysvinit has been the consensus of the project since
the systemd debate.  We can, of course, change that, but *that* would be
the change, not this.

> Previously, we had a sort of agreement (through the TC decision) that
> such scripts should be maintained by people caring about them and we
> should only act on bug reports with proper patches to have them.

I don't agree that this was ever the agreement.

> Thanks to this new Lintian tag, the current situation is that packages
> won't pass NEW without a SysV init script (unless a FTP-masters ignore
> this specific tag despite its severity).

I haven't worked on Lintian in several years, so perhaps my information is
stale, but at least previously ftp-master rejects were not based on
severity, but rather on a hard-coded list of tags maintained by
ftp-master.

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

Is it the job of Lintian to push an agenda?

[Vincent Bernat]

Hey!

Lintian got a new tag to enforce Policy 9.11:

 Packages may integrate with these replacement init systems by
 providing implementation-specific configuration information
 about how and when to start a service or in what order to run
 certain tasks at boot time. However, any package integrating
 with other init systems must also be backwards-compatible with
 sysvinit by providing a SysV- style init script with the same
 name as and equivalent functionality to any init-specific job,
 as this is the only start-up configuration method guaranteed to
 be supported by all init implementations.

Lintian tag:
 


This tag has false positives, see:
 

Original bug introducing this tag is:
 

The policy update is being discussed here:
 

As usual with a policy change, it will take years. Some people will push
back and the result is that a few people can impose to everyone else the
additional work to maintain SysV init script.

Previously, we had a sort of agreement (through the TC decision) that
such scripts should be maintained by people caring about them and we
should only act on bug reports with proper patches to have them. Thanks
to this new Lintian tag, the current situation is that packages won't
pass NEW without a SysV init script (unless a FTP-masters ignore this
specific tag despite its severity).

This Lintian tag was introduced by the maintainer of runit in a clear
attempt to push more work towards people not shipping SysV init script.
Could it be just reverted on the ground of the TC statement and the fact
that systemd is not an alternative init?
-- 
Zounds!  I was never so bethumped with words
since I first called my brother's father dad.
-- William Shakespeare, "Kind John"


signature.asc
Description: PGP signature

Bug#931988: ITP: kopano-webapp-plugin-intranet -- Kopano WebApp intranet plugin

[Roel van Meer]

Package: wnpp
Severity: wishlist
Owner: Roel van Meer 

* Package name: kopano-webapp-plugin-intranet
  Version : 1.0.0
  Upstream Author : Kopano 
* URL : https://kopano.com/
https://stash.kopano.io/projects/KWA/repos/intranet/browse
* License : AGPL-3
  Programming Lang: PHP, JS
  Description : Kopano WebApp intranet plugin

 This package is a plugin for kopano-webapp, a web interface for the Kopano
 Collaboration Platform.
 .
 This plugin adds one or more buttons in the top menu bar which can be used
 to open a webpage inside Kopano WebApp.

This package is an additional plugin for kopano-webapp. It will be maintained
by Giraffe Maintainers .

Kind regards,

Roel

Re: Notes on packaging PCYNLITX

[Bernd Zeimetz]

Hi,

> If I will packaging PCYNLITX for Debian, any suggestions, assuming that I 
> have read New Maintainers Guideline and
> related Debian packaging documentation?

> [2]: http://www.pcynlitx.tech/the-installation-of-pcynlitx/

after looking at the source - i think your biggest challenge will be to
find a way to build this big mess of shell snippets into something that
will build a debian package in a reliable way. On the first look the
buildprocess does not even stop when there was an error... I think to
become a useful project you should convince upstream to use cmake or
some other reliable build system - you might also need that if you want
to build the source on other architectures or cross-build it...

tl;dr - first fix the source and build-system, then think about Debian.


Bernd



-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F