Re: Packaging Games with In-App Purchases

[Tobias Frost]

On Sun, Jul 14, 2019 at 12:37:52PM +0700, Bagas Sanjaya wrote:
> Hello,
> 
> Let's imagine that I will package a city-building game titled
> makaecity. 

Can you share a link? My $searchengine vodoo failed on me...

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.

Well, if it is GPL3, you can patch out the real-money-purchasing thing,
I guess, can't you?

On the other side: Can you actually play (and win) the game without
any purchase? Because any IAP will have pricacy concerns… (Desert Island
Test, Dissident test)

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

> Cheers, Bagas
> 
> -- 
> An old man doll... just what I always wanted! - Clara
> 


signature.asc
Description: PGP signature

Re: git & Debian packaging sprint report

[Ansgar]

Sean Whitton writes:
> On Fri 12 Jul 2019 at 02:06PM +02, Ansgar 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.

What is the DebConf BOF then for?  It says it is "a requirements
collecting BOF for that [git push] discussion"?

Ansgar

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

[Ansgar Burchardt]

Russ Allbery writes:
> 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.

If we have no consensus that doing something is the right thing, then
lintian should probably not start raising a warning about it and one
should keep in mind that Policy might not reflect consensus when
referring to it.

Ansgar

Re: git & Debian packaging sprint report

[Sean Whitton]

Hello,

On Sun 14 Jul 2019 at 09:48AM +02, Ansgar wrote:

> What is the DebConf BOF then for?  It says it is "a requirements
> collecting BOF for that [git push] discussion"?

To my mind, the BoF and the work at the sprint are two efforts to
improve things that are running in parallel.  I think we can expect
the them to enhance each other.

If the BoF or e-mail discussion comes up with requirements which are
impossible for our solution to satisfy, then we misjudged what to spend
our time on at the sprint.  Ian and I have been working on this stuff
for long enough that we felt able to make a judgement about what would
be useful, however.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Packaging Games with In-App Purchases

[Ben Hutchings]

On Sun, 2019-07-14 at 12:37 +0700, Bagas Sanjaya wrote:
> 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.

How does that work, in a game that can easily be modified?  Does it
depend on a server that keeps track of currency and items, and is the
server free software?  If there's a dependency on a non-free server, I
think the game would belong in contrib (though I'm not sure).

Ben.

> Any suggestion on packaging makecity and other programs/games with
> IAPs?
> 
> Cheers, Bagas
> 
-- 
Ben Hutchings
friends: People who know you well, but like you anyway.




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

Re: unsigned repositories

[Sam Hartman]

> "Julian" == Julian Andres Klode  writes:

Please carefully consider uses of apt besides the system level apt
running as root installing packages on the system.

What about when I use the apt libraries to explore some repository and
parse its packages files etc.
Asking people to go set up the keys for some of these use cases seems
like a lot of work.

Re: Packaging Games with In-App Purchases

[Sam Hartman]

> "Tobias" == Tobias Frost  writes:

Tobias> Well, if it is GPL3, you can patch out the
Tobias> real-money-purchasing thing, I guess, can't you?

Tobias> On the other side: Can you actually play (and win) the game
Tobias> without any purchase? Because any IAP will have pricacy
Tobias> concerns… (Desert Island Test, Dissident test)

You can, but I don't think you are under an obligation to do so.
I think you should make the privacy issues here.
But free software is not inherently against capitalism, making money, or
any of that.

You could of course patch the game to redirect it (and the purchases) to
your servers rather than the original servers.
Doing that might involve writing servers.

--Sam

Re: git & Debian packaging sprint report

[Sam Hartman]

> "Sean" == Sean Whitton  writes:

Sean> If the BoF or e-mail discussion comes up with requirements
Sean> which are impossible for our solution to satisfy, then we
Sean> misjudged what to spend our time on at the sprint.  Ian and I
Sean> have been working on this stuff for long enough that we felt
Sean> able to make a judgement about what would be useful, however.

The BOF will almost certainly come up with requirements that are
impossible for any solution to meet.
THe BOF is not judging requirements, only collecting them.

People proposing solutions can use the BOF input where it is helpful.
We as a project can use that input in guiding discussions too.  However
just because something is proposed as a requirement at the BOF doesn't
mean we will be able to (or will choose to) meet that requirement.

Also, the BOF was proposed by me in the hopes of getting things moving.
We've had a lot of activity since I submitted that original BOF
proposal.  If Sean and Ian think they already have enough information to
put something together, I think that's great.  My BOF proposal was
intended to enable work, not to slow it down.

--Sam

Re: Packaging Games with In-App Purchases

[Sam Hartman]

> "Ben" == Ben Hutchings  writes:

Ben> On Sun, 2019-07-14 at 12:37 +0700, Bagas Sanjaya wrote:
>> 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.

Ben> How does that work, in a game that can easily be modified?
Ben> Does it depend on a server that keeps track of currency and
Ben> items, and is the server free software?  If there's a
Ben> dependency on a non-free server, I think the game would belong
Ben> in contrib (though I'm not sure).

The game would not belong in contrib just because it uses a non-free
server.
We have this discussion on -project every few years and it becomes
painfully clear within the first 20 messages or so that if depending on
a non-free server was enough to get your software into contrib, huge
sections of the archive would end up in contrib, and both our users and
the free software community would be harmed.

Users would be harmed because things like free software libraries that
can talk to both openstack and AWS would have a hard decision to make.
They would either end up dropping the AWS dependency or moving to
contrib.  Enough would choose not to drop the AWS dependency that even
users who wanted to access entirely free services would end up often
needing contrib.

The free software community would be harmed because contrib would become
needed enough that even people who valued free software would end up
using it.

I'm massively overly simplifying here.  But we do have this conversation
periodically, and it's no fun, and we end up back at the current status
quo.

--Sam

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

[Sam Hartman]

> "Ansgar" == Ansgar Burchardt  writes:

Ansgar> Russ Allbery writes:
>> 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.

Ansgar> If we have no consensus that doing something is the right
Ansgar> thing, then lintian should probably not start raising a
Ansgar> warning about it and one should keep in mind that Policy
Ansgar> might not reflect consensus when referring to it.

When the policy decision was made, I think we did have consensus.

So, no, that's our current policy at least until something changes it.
The processes I'm aware of for changing policy absent a consensus to do
so are GR and TC.

--Sam

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

[Theodore Ts'o]

On Sat, Jul 13, 2019 at 02:22:01PM -0700, 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.

The alternative seems to be a large number of package maintainers
willfuly ignoring a particular reading of the Policy, whether or not
that reading of the policy is "correct" or not.  Hopefully we can
avoid bug priority escalation/descalation wars over what might or
might not be a policy violation.   Oh joy

- Ted

P.S.  I'm going to be adding an override in e2fsprogs for
package-supports-alternative-init-but-no-init.d-script because it
has false positive, regardless of its claim:

N:Severity: important, Certainty: certain

It most *definitely* is not certain.  We went through quite a bit of
trouble providing alternative functionality via cron, and not via
(only) systemd timers.  I will admit the functionality is slightly
better if you are using systemd, but as saying goes, "patches
gratefully accepted".  Whining for developers to do extra work via
Debian Policy is, well, not.

And I say all of this not being a systemd fan.  But the vast majority
of Linux ecosystem has made a choice, and we should just move *on*.

Re: Packaging Games with In-App Purchases

[Tobias Frost]

On Sun, Jul 14, 2019 at 08:50:54AM -0400, Sam Hartman wrote:
> > "Tobias" == Tobias Frost  writes:
> 
> Tobias> Well, if it is GPL3, you can patch out the
> Tobias> real-money-purchasing thing, I guess, can't you?
> 
> Tobias> On the other side: Can you actually play (and win) the game
> Tobias> without any purchase? Because any IAP will have pricacy
> Tobias> concerns… (Desert Island Test, Dissident test)
> 
> You can, but I don't think you are under an obligation to do so.

The intention of this question was to re-ensure that this is really
free, nothing more, not to imply any obligations to do so. (It wouldn't
be the first time that upstreams do "ammend" the GPL3 in an incompatible
way)

> I think you should make the privacy issues here.

(EPARSE) Sorry, I don't understand what you mean…

> But free software is not inherently against capitalism, making money, or
> any of that.

Yes, never disputed.

> You could of course patch the game to redirect it (and the purchases) to
> your servers rather than the original servers.
> Doing that might involve writing servers.
> 
> --Sam
> 

Search field in LXDE Desktop

[patrick . dreier]

Dear Man and Woman!

Windows XP has a Search field in Startup Menu.
Please add a Search field in LXDE Menu.

With kind Greetings!

Proposition: Insert Mozilla Firefox Release in Debian

[patrick . dreier]

Dear Woman and Man!

Please Insert Mozilla Firefox Release in Debian.

With kind Greetings!

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

[Chris Lamb]

Jérémy Lal wrote:

> "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.

Difficulties are always inherent in shipping any opinionated linter to
people with a wide spectrum of motivations and ideas. Furthermore, if
it becomes pervasive then there is not only a risk of its output being
followed without attention, when interpreted as a kind of de-facto
policy there is an additional a danger of it being beaten from a
plowshare back into a sword on contentious issues.

As the first line of defense to the above, Lintian reflects the
positions taken and espoused in our official Policy and should [0]
always defer to that esteemed text.

It therefore follows that if the Debian Policy decrees a certain
direction and Lintian mirrors that then in the rare cases of dissent
or disagreement the right and proper course of action is to re-raise
it via Policy and its various appeal processes. If that is not
possible then that is a regrettable state of affairs, but Lintian is
not the venue to stage one's passive-aggressive proxy war on
controversial and highly-charged issues within Debian and its
maintainers have neither the strength, stomach nor spoons for such
maneuevers.

As Sean implies in an adjacent message, all of the above is compounded
by there being a number of recommendations that are considered to be
good practice by most [1] but are not part of Policy (and most should
or can never be). Lintian's various severity levels ("E:", "W:", "I:",
etc), as well as responding to cordial and reasonable requests to
adjust these do allow it to address, albeit extremely clumsily, the
extremely wide spectrum involved here.

As a postscript, it seems like the term "agenda" was a regrettable
choice for this thread given that it carries an implication of
underhanded and dishonest motives. As I am certain that would never be
the intention of my dear colleagues, to avoid any possible
misinterpretations for the remainder of my message I have adopted
alternative terms instead.

  [0] Or, if you may excuse an RFC2119 pun, "MUST"...
  [1] Feel free to dilute to taste with similar terms.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org 🍥 chris-lamb.co.uk
   `-

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

[Chris Lamb]

Theodore Ts'o wrote:

> P.S.  I'm going to be adding an override in e2fsprogs for
> package-supports-alternative-init-but-no-init.d-script because it
> has false positives

Regardless of the specifics of this particular package if Lintian
could feasibly not emit this false-positive, would it surely not be
more sensible to get this fixed there instead?

That would not only be a cleaner solution than an override (which you
would likely just have to remove later...) it would be a general
kindness in that it could potentially save countless other developers
undergoing the same manual process as you.

> It most *definitely* is not certain.

Again, this sounds like something trivially addressed in Lintian
itself, or perhaps even by not reading too much into this apparently
entirely-adjunct advisory classification that is, after all, not
central to Lintian's operation.


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org 🍥 chris-lamb.co.uk
   `-

Bug#932059: ITP: kwartz-client -- Configuration of a Kwartz client

[Georges Khaznadar]

Package: wnpp
Severity: wishlist
Owner: Georges Khaznadar 

* Package name: kwartz-client
  Version : 1.0-1
  Upstream Author : georges Khaznadar 
* URL : https://salsa.debian.org/georgesk/kwartz-client
* License : GPL-2+
  Programming Lang: shell (sh)
  Description : Configuration of a Kwartz client

 Kwartz is a school server featuring many services, deployed in French
 schools. This package makes it easier for sysadmins to integrate a
 GNU-Linux client machine in a network ruled by a Kwartz service, to
 allow users to authenticate against the LDAP directory, auto-mount
 Samba shares for themselves, and for the groups and projects they
 belong to.

Considerations about sustainability:

1. this package is small, and just contains a few shortcuts to make
   it easier for everyone with the right permissions to configure
   libpam-ldapd and other pam modules with a set of questions targeting
   newbie users.
2. LDAP services in a school, together with Gnu-Linux clients should become
   less uncommon as free software spreads around. Kwartz is not a unique case,
   I hope that this solution may be developed in more flavors, to target
   other "popular" LDAP services deployed in schools.
3. I shall keep maintaining this package as long as I teach in my school
   since it is necessary for my students.
4. The package is maintained in
   https://salsa.debian.org/georgesk/kwartz-client

libfuse3-dev is a virtual package?

[Theodore Ts'o]

So this is weird.  I can't install libfuse3-dev on my buster system:

# apt install libfuse3-dev
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Package libfuse3-dev is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'libfuse3-dev' has no installation candidate

Apt seems to think it is a virtual package:

# apt show libfuse3-dev
Package: libfuse3-dev
State: not a real package (virtual)
N: Can't select candidate version from package libfuse3-dev as it has no 
candidate
N: There is 1 additional record. Please use the '-a' switch to see it
N: No packages found
# apt show -a libfuse3-dev
Package: libfuse3-dev
Version: 3.4.1-1
Priority: optional
Section: libdevel
Source: fuse3
Maintainer: Laszlo Boszormenyi (GCS) 
Installed-Size: 668 kB
Depends: libfuse3-3 (= 3.4.1-1), libselinux-dev
Suggests: fuse
Homepage: https://github.com/libfuse/libfuse/wiki
Tag: devel::library, role::devel-lib
Download-Size: 128 kB
APT-Sources: https://mirrors.kernel.org/debian buster/main amd64 Packages
Description: Filesystem in Userspace (development) (3.x version)
 Filesystem in Userspace (FUSE) is a simple interface for userspace programs to
 export a virtual filesystem to the Linux kernel. It also aims to provide a
 secure method for non privileged users to create and mount their own filesystem
 implementations.
 .
 This package contains the development files.

But as near as I can tell, it's a real package:

https://packages.debian.org/buster/libfuse3-dev

Help?

- Ted

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

[Russ Allbery]

Sam Hartman  writes:
>> "Ansgar" == Ansgar Burchardt  writes:

> Ansgar> If we have no consensus that doing something is the right
> Ansgar> thing, then lintian should probably not start raising a
> Ansgar> warning about it and one should keep in mind that Policy
> Ansgar> might not reflect consensus when referring to it.

> When the policy decision was made, I think we did have consensus.

> So, no, that's our current policy at least until something changes it.

For the record, this is exactly the way that I view it as well.

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

Re: libfuse3-dev is a virtual package?

[Sven Joachim]

On 2019-07-14 11:56 -0400, Theodore Ts'o wrote:

> So this is weird.  I can't install libfuse3-dev on my buster system:
>
> # apt install libfuse3-dev
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Package libfuse3-dev is not available, but is referred to by another package.
> This may mean that the package is missing, has been obsoleted, or
> is only available from another source
>
> E: Package 'libfuse3-dev' has no installation candidate
>
> Apt seems to think it is a virtual package:
>
> # apt show libfuse3-dev
> Package: libfuse3-dev
> State: not a real package (virtual)
> N: Can't select candidate version from package libfuse3-dev as it has no 
> candidate
> N: There is 1 additional record. Please use the '-a' switch to see it
> N: No packages found
> # apt show -a libfuse3-dev
> Package: libfuse3-dev
> Version: 3.4.1-1
> Priority: optional
> Section: libdevel
> Source: fuse3
> Maintainer: Laszlo Boszormenyi (GCS) 
> Installed-Size: 668 kB
> Depends: libfuse3-3 (= 3.4.1-1), libselinux-dev
> Suggests: fuse
> Homepage: https://github.com/libfuse/libfuse/wiki
> Tag: devel::library, role::devel-lib
> Download-Size: 128 kB
> APT-Sources: https://mirrors.kernel.org/debian buster/main amd64 Packages
> Description: Filesystem in Userspace (development) (3.x version)
>  Filesystem in Userspace (FUSE) is a simple interface for userspace programs 
> to
>  export a virtual filesystem to the Linux kernel. It also aims to provide a
>  secure method for non privileged users to create and mount their own 
> filesystem
>  implementations.
>  .
>  This package contains the development files.
>
> But as near as I can tell, it's a real package:
>
>   https://packages.debian.org/buster/libfuse3-dev

This can happen if you have assigned a negative Pin-Priority to
libfuse3-dev.  According to apt_preferences(5), a Priority < 0 "prevents
the version from being installed", and apparently apt achieves this by
pretending that the package is not there at all.

Cheers,
   Sven

Re: unsigned repositories

[Eduard Bloch]

Hallo,
* Sam Hartman [Sun, Jul 14 2019, 08:46:18AM]:
> > "Julian" == Julian Andres Klode  writes:
>
> Please carefully consider uses of apt besides the system level apt
> running as root installing packages on the system.
>
> What about when I use the apt libraries to explore some repository and
> parse its packages files etc.
> Asking people to go set up the keys for some of these use cases seems
> like a lot of work.

IMHO this could and should be mitigated. I.e. give people a tool they
can work with without studying rocket science, following the spirit of
letsencrypt etc., which handles the snakeoil key handling in a lazy way.

Something like:

apt-ftparchive ... --auto-sig
(create a new PGP key OR load and use the PGP key with identity of the current
InRelease file; auto-generated key is stored in user's private keyring
and can be extracted with ...)



Best regards,
Eduard.

--
Angela Merkel zitiere ich ja am liebsten wörtlich. Ich hab noch keine
bessere Möglichkeit gefunden, diese Frau zu beleidigen.
-- Volker Pispers

How to adopt a dead package?

[Perry E. Metzger]

Howdy! bozohttpd was removed from Debian a while ago because of a
lack of activity by the upstream maintainer and some outstanding
security issues, but said maintainer re-awakened and fixed a bunch of
bugs (including the outstanding security issues).

If I wanted to adopt the package and get it back into Debian, what
would I need to do? I haven't been a package maintainer before. I
presume there's a document somewhere I can read with detailed
instructions?

Perry
-- 
Perry E. Metzgerpe...@piermont.com

Re: unsigned repositories

[Sam Hartman]

> "Eduard" == Eduard Bloch  writes:

Eduard> Hallo, * Sam Hartman [Sun, Jul 14 2019, 08:46:18AM]:
>> > "Julian" == Julian Andres Klode  writes:
>> 
>> Please carefully consider uses of apt besides the system level
>> apt running as root installing packages on the system.
>> 
>> What about when I use the apt libraries to explore some
>> repository and parse its packages files etc.  Asking people to go
>> set up the keys for some of these use cases seems like a lot of
>> work.

Eduard> IMHO this could and should be mitigated. I.e. give people a
Eduard> tool they can work with without studying rocket science,
Eduard> following the spirit of letsencrypt etc., which handles the
Eduard> snakeoil key handling in a lazy way.

Most of the repository generation tools these days do a fairly good job
of signing the release file.
What I'm more worried about is configuring the client apt library in
cases where you are using it for things other than the main apt instance
on the system.

Re: How to adopt a dead package?

[Andrey Rahmatullin]

On Sun, Jul 14, 2019 at 02:05:25PM -0400, Perry E. Metzger wrote:
> Howdy! bozohttpd was removed from Debian a while ago because of a
> lack of activity by the upstream maintainer and some outstanding
> security issues, but said maintainer re-awakened and fixed a bunch of
> bugs (including the outstanding security issues).
> 
> If I wanted to adopt the package and get it back into Debian, what
> would I need to do? I haven't been a package maintainer before. I
> presume there's a document somewhere I can read with detailed
> instructions?
Generic instructions: https://mentors.debian.net/intro-maintainers
Reintroducing packages: 
https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#reintroducing-pkgs

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Propostion Laisse les deux des Installation

[patrick . dreier]

Mes Dames et Messieurs!

Propostion Laisse les deux des Installation
1) Installation
2) Graphical Install

Mes meilleurs Salution!

Propositon: Multiarchitecture Support in Next Debian 64-bit, Mozilla Firefox Release,...

[patrick . dreier]

Dear Woman and Man!

Propositon: Multiarchitecture Support in Next Debian 64-bit (64-bit and
32-bit), Mozilla Firefox Release, in LXDE Startup Menu a Search field
32-bit i386 for Adobe Reader ftp.adobe.com

With kind Greetings!

Re: How to adopt a dead package?

[Perry E. Metzger]

On Sun, 14 Jul 2019 23:11:46 +0500 Andrey Rahmatullin
 wrote:
> > If I wanted to adopt the package and get it back into Debian, what
> > would I need to do? I haven't been a package maintainer before. I
> > presume there's a document somewhere I can read with detailed
> > instructions?  
> Generic instructions: https://mentors.debian.net/intro-maintainers
> Reintroducing packages:
> https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#reintroducing-pkgs

Thank you!

Perry
-- 
Perry E. Metzgerpe...@piermont.com

Re: libfuse3-dev is a virtual package?

[Theodore Ts'o]

On Sun, Jul 14, 2019 at 07:12:59PM +0200, Sven Joachim wrote:
> This can happen if you have assigned a negative Pin-Priority to
> libfuse3-dev.  According to apt_preferences(5), a Priority < 0 "prevents
> the version from being installed", and apparently apt achieves this by
> pretending that the package is not there at all.

Thanks for the hint; you called it exactly.  I had this in my apt
preferences:

Package: *
Pin: release a=testing
Pin-Priority: 900

Package: *
Pin: release o=Debian
Pin-Priority: -10

... and I'm currently still on Buster, having not moved on to Bullseye
yet.

- Ted

Re: systemd services that are not equivalent to LSB init scripts

[Simon McVittie]

On Sun, 14 Jul 2019 at 09:21:37 -0400, Theodore Ts'o wrote:
> P.S.  I'm going to be adding an override in e2fsprogs for
> package-supports-alternative-init-but-no-init.d-script because it
> has false positive, regardless of its claim:
> 
> N:Severity: important, Certainty: certain
> 
> It most *definitely* is not certain.  We went through quite a bit of
> trouble providing alternative functionality via cron, and not via
> (only) systemd timers.

Every LSB init script is equivalent to a systemd service that is
"required" or "wanted" by one of the targets that are reached during boot,
but the converse is not true. Not every systemd service is "required"
or "wanted" by those targets: some systemd services start on-demand,
which is not a concept that exists within the narrower scope of LSB
init scripts. Some of the triggering events have equivalents (at least
approximately) in a broader non-systemd ecosystem that includes things
like cron; others do not.

Putting this one first because I think it's the least ambiguous:
Some systemd system services are meant to be started on-demand via
D-Bus activation (/usr/share/dbus-1/system-services/*.service with
SystemdService= pointing to a systemd.service(5)). If the D-Bus
service has a suitable Exec= line, then dbus-daemon can launch the
daemon via traditional D-Bus activation (dbus-daemon-launch-helper)
on non-systemd-booted systems; but on a systemd system it's best if it
configures SystemdService= to delegate that job to systemd, because unlike
systemd, dbus-daemon is not really designed to be a service manager,
and is certainly not a fully-featured service manager. udisksd in the
udisks2 package is one of the canonical examples of this pattern. This
is probably not allowed by a strict reading of Policy, but in the case
where traditional activation already works (which in practice it usually
does) there's clearly no actual functional bug for non-systemd users -
the service is working as well as it ever did - so it should be allowed.

Some systemd system services are meant to be triggered by systemd timers
(systemd.timer(5)), which trigger execution of a systemd service when
the timer "goes off", and can have an analogous (ana)cron job used on
non-systemd-booted systems. It sounds as though your use-case in e2fsprogs
is a good example of this; apt is another. As with D-Bus above, this
doesn't seem to be allowed by a strict reading of Policy. I think the case
where there is an approximately equivalent cron job should certainly be
allowed. If there is no equivalent cron job, I would personally say that's
a bug but probably not RC; it would be in the spirit of previous Technical
Committee decisions on init systems to expect maintainers to apply good
patches, if someone with an interest in non-systemd inits contributes
a cron job that doesn't seem like it will harm future maintenance.

Some systemd system services are meant to start on-demand via socket
events (systemd.socket(5)), and can work via inetd on non-systemd-booted
systems. micro-httpd appears to be an example of this - I'm a bit surprised
there aren't more. Perhaps this indicates limitations in the infrastructure
around inetd services making it hard to implement "use systemd.socket(5)
under systemd or inetd otherwise"?

Some systemd system services are meant to start during suspend/resume by
hooking into targets like suspend.target, and could presumably work via
/etc/pm or /etc/acpi or whatever else non-systemd users use for power
management events on non-systemd-booted systems (I've lost track of what
that would be). tlp-sleep.service in the tlp package is an example, which
appears to hook into elogind via /lib/elogind/system-sleep/49-tlp-sleep,
a mechanism of which I was not previously aware.

Some systemd system services (I don't know of any examples in Debian)
are meant to be triggered by an inotify event (systemd.path(5)), which
could presumably have an equivalent using something like the incron
package if non-systemd users want it badly enough. I don't think the
maintainers of any systemd services that make use of that mechanism
should be expected to invent a whole parallel infrastructure that they
will not, themselves, use, but if non-systemd users build a suitable
mechanism, then it might be reasonable to expect service maintainers
to apply patches that add simple integration "glue" files analogous to
.path units for that other mechanism.

I've deliberately been saying "the non-systemd ecosystem" rather than
"the sysvinit ecosystem" because the latter would be very misleading -
sysvinit itself is really very simple, and its only contribution to any
of this is to run /etc/init.d/rc at runlevel changes. For full coverage
of equivalents of the units I described above it would be at least the
sysvinit/sysv-rc/cron/anacron/dbus-daemon-launch-helper/inetd/elogind/incron
ecosystem, and I'm sure I've missed some.

systemd system services can also be linked to an arbitrary non-boot
unit by declaring that th

Re: systemd services that are not equivalent to LSB init scripts

[Vincent Bernat]

 ❦ 14 juillet 2019 19:23 +01, Simon McVittie :

> Some systemd system services are meant to start on-demand via socket
> events (systemd.socket(5)), and can work via inetd on non-systemd-booted
> systems. micro-httpd appears to be an example of this - I'm a bit surprised
> there aren't more. Perhaps this indicates limitations in the infrastructure
> around inetd services making it hard to implement "use systemd.socket(5)
> under systemd or inetd otherwise"?

inetd uses stdin/stdout to communicate with the daemon and have to
launch one instance for each client connecting. systemd.socket pass a
regular listening socket on first connection to the daemon and the
daemon can then serve multiple clients. It is simple to convert an
existing daemon to systemd.socket and it doesn't come with a performance
impact. It can even simplify some aspects of an always-running daemon,
like reloading without impacting the traffic.
-- 
Familiarity breeds contempt -- and children.
-- Mark Twain


signature.asc
Description: PGP signature

Re: unsigned repositories

[Eduard Bloch]

Hallo,
* Sam Hartman [Sun, Jul 14 2019, 02:07:55PM]:
> > "Eduard" == Eduard Bloch  writes:
>
> Eduard> Hallo, * Sam Hartman [Sun, Jul 14 2019, 08:46:18AM]:
> >> > "Julian" == Julian Andres Klode  writes:
> >>
> >> Please carefully consider uses of apt besides the system level
> >> apt running as root installing packages on the system.
> >>
> >> What about when I use the apt libraries to explore some
> >> repository and parse its packages files etc.  Asking people to go
> >> set up the keys for some of these use cases seems like a lot of
> >> work.
>
> Eduard> IMHO this could and should be mitigated. I.e. give people a
> Eduard> tool they can work with without studying rocket science,
> Eduard> following the spirit of letsencrypt etc., which handles the
> Eduard> snakeoil key handling in a lazy way.
>
> Most of the repository generation tools these days do a fairly good job
> of signing the release file.

I am looking at this from the POV of a regular/lazy user. The next best
tool here is apt-ftparchive. Does it help you with signing? No. Does its
manpage even mention InRelease signing in any way? Not really.

Therefore, the critical voices in this thread are right - too early to
enforce strict signing.

> What I'm more worried about is configuring the client apt library in
> cases where you are using it for things other than the main apt instance
> on the system.

Understood, but what's the plan? Shouldn't this be another part of the
apt-secure manpage? Showing the user configuration examples for the few
main usecases?

Best regards,
Eduard.

Re: unsigned repositories

[Russ Allbery]

Eduard Bloch  writes:

> I am looking at this from the POV of a regular/lazy user. The next best
> tool here is apt-ftparchive. Does it help you with signing? No. Does its
> manpage even mention InRelease signing in any way? Not really.

For what it's worth, if I were setting up a small personal repository and
didn't want to deal with configuring reprepro (which I thought was
best-in-class here the last time I surveyed the field), I'd use aptly,
which will do the signing for you and has a pretty simple interface for
adding a new package to the repository.

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

Re: systemd services that are not equivalent to LSB init scripts

[Russ Allbery]

Vincent Bernat  writes:

> inetd uses stdin/stdout to communicate with the daemon and have to
> launch one instance for each client connecting. systemd.socket pass a
> regular listening socket on first connection to the daemon and the
> daemon can then serve multiple clients.

I believe the wait option for at least xinetd behaves in roughly the same
way, although it's normally only used for UDP services.

There seems to be a clear infrastructure gap for the non-systemd world
here that's crying out for some inetd-style program that implements the
equivalent of systemd socket activation and socket passing using the same
protocol, so that upstreams can not care whether the software is started
by systemd or by that inetd, and provides an easy-to-configure way for
Debian packages to indicate this should be used if systemd isn't in play.
It doesn't seem like it would be too difficult to implement such a thing,
but I don't think it already exists.

I believe the convention in the runit/daemontools world is to decide this
is not an important problem to solve and lots of small running daemons is
not something that needs to be avoided, and to use tcpserver or some
equivalent that behaves like inetd for a single service.  Even here,
though, I'm not sure if any of those implementations use the same socket
passing protocol as systemd, and I'm not sure if they're yet trivial to
configure as part of Debian packaging.

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

Re: How to adopt a dead package?

[Theodore Ts'o]

On Sun, Jul 14, 2019 at 02:34:50PM -0400, Perry E. Metzger wrote:
> On Sun, 14 Jul 2019 23:11:46 +0500 Andrey Rahmatullin
>  wrote:
> > > If I wanted to adopt the package and get it back into Debian, what
> > > would I need to do? I haven't been a package maintainer before. I
> > > presume there's a document somewhere I can read with detailed
> > > instructions?  
> > Generic instructions: https://mentors.debian.net/intro-maintainers
> > Reintroducing packages:
> > https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#reintroducing-pkgs
> 
> Thank you!

Hey Perry,

Long time no chat!

Two things to highlight.  First, bozohttpd has been out of Debian for
about 5 years, so it's worth taking a quick look through the upgrading
checklist in the Debian Policy document for changes since its list
Standards conformance claim, which is against version 3.9.3 (we're not
at version 4.4):

   https://www.debian.org/doc/debian-policy/upgrading-checklist.html


Secondly, one good thing is that the packaging for bozohttpd appears
to be very simple, if obsolete.  And fortunately, debhelper compat
level 5 is deprecated, but it's at least still supported by modern
versions of debhelper (which is version 12; see the COMPATIBILITY
LEVELS section of the debhelper man page for more details).

The New Maintainer's Guide is going to give you examples using the new
recommended "dh" template, where the core of the debian/rules makefile
looks like this:

%:
dh $@

The last version of bozohttpd's debian/rules file runs explicit
debhelper commands, e.g.:

binary-arch: build install
dh_testdir
dh_testroot
dh_installdocs
...

The developer's reference guide recommends using the existing
packaging when reintroducing a package.  And that's probably good
advice, although it may cause some initial confusion when you read the
New Maintainer's Guide, since it assumes you are packaging a new
package, where there is no legacy packaging effort to use as a base.

That being said, it might be simpler to guarantee pacakging policy
complaince if you were to start from scratch; the primary files which
you'd like to pay special attention are the current
debian/{post,rm}{inst,rm} files.

Finally, if you need someone to help be a mentor and sponsor the
upload, or if you have any questions, please feel free to contact me
off-line; I'd be happy to help.

Cheers,

- Ted

Re: unsigned repositories

[Jeremy Stanley]

On 2019-07-14 21:23:57 +0200 (+0200), Eduard Bloch wrote:
[...]
> I am looking at this from the POV of a regular/lazy user. The next best
> tool here is apt-ftparchive. Does it help you with signing? No. Does its
> manpage even mention InRelease signing in any way? Not really.
[...]

On that note, I just do:

apt-ftparchive release . | gpg2 --clear-sign --output InRelease

Works great. Would simply adding that to the EXAMPLES section of
apt-ftparchive(1) suffice? It's right in line with the existing
example of a compressed Packages.gz file.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature

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

[Theodore Ts'o]

On Sun, Jul 14, 2019 at 11:10:36AM -0300, Chris Lamb wrote:
> Theodore Ts'o wrote:
> 
> > P.S.  I'm going to be adding an override in e2fsprogs for
> > package-supports-alternative-init-but-no-init.d-script because it
> > has false positives
> 
> Regardless of the specifics of this particular package if Lintian
> could feasibly not emit this false-positive, would it surely not be
> more sensible to get this fixed there instead?

There is a bug open against Lintian already, but it's not at all clear
it's solveable short of solving the halting problem.  E2fsprogs is
shipping 5 systemd unit files for which the cron.d file is a rough
substitute.  So the only choice is whether you want false positive or
false negative reports for a Lintian "Important" warning.

I'm getting 5 Important Lintian errors, one for each systemd unit
files.  Some of them are associated with a systemd.timer setup, and
some are normal system services unit files.  *All* of them in
combination implement the functionality which is also (mostly)
provided by cron.d entry and the e2scrub_all_cron shell script.

Just suppressing the warning for systemd.timer files would not be
sufficient.  You'd have to suppress *all* Lintian complaints of this
class if there is at least one timer file and at least one cron.d file
in the package.   But that's going to subject to false negatives.

Or, you know, you could solve the halting problem.  :-)

> That would not only be a cleaner solution than an override (which you
> would likely just have to remove later...) it would be a general
> kindness in that it could potentially save countless other developers
> undergoing the same manual process as you.

I prefer not to either (a) delay a release of e2fsprogs until this
Lintian bug is solved, one way or another (and it's not clear it can
be solved easily), or (b) deal with people complaining and filing bugs
regarding the Lintian Important report.

So override does seem to be the best approach, especially given how
charged the whole sysvinit vs systemd controversy and my lack of faith
that the Lintian bug is going to be resovled any time soon.  I'd
*much* rather avoid any flames directed at me caused by this false
positive.

  - Ted

Re: systemd services that are not equivalent to LSB init scripts

[Theodore Ts'o]

On Sun, Jul 14, 2019 at 07:23:31PM +0100, Simon McVittie wrote:
> micro-httpd appears to be an example of this - I'm a bit surprised
> there aren't more. Perhaps this indicates limitations in the infrastructure
> around inetd services making it hard to implement "use systemd.socket(5)
> under systemd or inetd otherwise"?

I'll note that it's a bit tricky even in the cron vs systemd.timer use
case.  That's what I was referring to when I said we had to go through
some effort just to enable the "use cron" functionality, since we had
to make sure that this was inhibited in the case where cron and
systemd is enabled on the system.

So requiring support of non-systemd ecosystems is in general, going to
require extra testing.  In the case of cron/systemd.timers, this means
testing and/or careful code inspection to make sure the following
cases work:

* systemd && cron
* systemd && !cron
* !systemd && cron

Support of non-systemd ecosystems is not going to be free, and some
cases, it is not going to be fun, something which many have asserted
should be something we should be striving for.  The challenge is how
do we develop the consensus to decide whether or not we force
developers to pay this cost.

And if we don't, is it better to just let this rot where we allow
developers to violate current policy with a wink and a nudge until
it's clear that we do have consensus?  Or do we force them to do the
work?  Or do we somehow go through the pain and effort to try to
determine what that consensus actually is?

- Ted

Re: systemd services that are not equivalent to LSB init scripts

[Vincent Bernat]

 ❦ 14 juillet 2019 12:30 -07, Russ Allbery :

> There seems to be a clear infrastructure gap for the non-systemd world
> here that's crying out for some inetd-style program that implements the
> equivalent of systemd socket activation and socket passing using the same
> protocol, so that upstreams can not care whether the software is started
> by systemd or by that inetd, and provides an easy-to-configure way for
> Debian packages to indicate this should be used if systemd isn't in
> play.

What's the point? The alternative to not using systemd socket server is
to run the daemon as usual. If an upstream decides to tie a daemon to
systemd socket server by delegating the socket creation to systemd, why
would we need to implement anything? Don't we have better things to do?
This init diversity crusade is eating our time.
-- 
Make sure every module hides something.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

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

[Adam Borowski]

On Sun, Jul 14, 2019 at 09:21:37AM -0400, Theodore Ts'o wrote:
> but as saying goes, "patches gratefully accepted".  Whining for developers
> to do extra work via Debian Policy is, well, not.

If patches are actually accepted, that's fine.

But this Policy item currently servers as a tool to _sometimes_ get a patch
through.  In some cases such patches get stonewalled, and if you _then_ NMU
a package in question, you can get calls for getting demoted from DD.

We released Buster basically useless in GUI mode in !systemd, despite a
solution been discussed[1] and _implemented_ in January 2018, with multiple
later submissions.  And it's not that they haven't been noticed -- the
existence of that patchset was used to justify removal of (unlamented) shim.

So even that on-paper severity is not enough to get patches accepted.
Without it, regressions would be even worse.


Meow!

[1]. Only one member of the systemd team was helpful, so this can't be
called consensus on their part -- but not for a lack of trying.
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢰⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ NADIE anticipa la inquisición de españa!
⠈⠳⣄

Re: systemd services that are not equivalent to LSB init scripts

[Martin Steigerwald]

Hello.

Theodore Ts'o - 14.07.19, 22:07:
> So requiring support of non-systemd ecosystems is in general, going to
> require extra testing.  In the case of cron/systemd.timers, this
> means testing and/or careful code inspection to make sure the
> following cases work:
> 
> * systemd && cron
> * systemd && !cron
> * !systemd && cron
> 
> Support of non-systemd ecosystems is not going to be free, and some
> cases, it is not going to be fun, something which many have asserted
> should be something we should be striving for.  The challenge is how
> do we develop the consensus to decide whether or not we force
> developers to pay this cost.

I believe forcing someone who does volunteer work by maintaining 
packages for Debian is not going to work out. Or even more so: I do not 
see how Debian project could force developers. The only effective way to 
force anything would be to threaten with loosing membership status or 
privileged. But I would not go that route as I see it as destructive 
one.
 
> And if we don't, is it better to just let this rot where we allow
> developers to violate current policy with a wink and a nudge until
> it's clear that we do have consensus?  Or do we force them to do the
> work?  Or do we somehow go through the pain and effort to try to
> determine what that consensus actually is?

I do not have a solution for the divide behind all of this.

But I do have some hints that may be beneficial or constructive to 
someone:

There is a group of Debian developers in the Debian Init Diversity team 
working on exactly that: diversity regarding init systems. This is a 
group consisting on both Debian and Devuan developers who decided that 
working together is going to benefit both Debian and Devuan. Some people 
of that group did a *ton* of work to improve sysvinit, insserv, 
startpar, runit and I believe also openrc packages. When I look at the 
bug tracker I believe sysvinit in Buster is in a better state than it 
was since a long, long time. It even has a new upstream maintainer who 
actively dug through Debian bug reports with the aim to fix as much 
upstream bugs as possible. Also another developer worked on elogind 
package. I running Debian Sid with Plasma desktop on Sysvinit since more 
than a month already. It needed some minor tweaks as for example 
Pulseaudio was not started automatically and Evolution which I use for 
work needs some services that are nowadays started by user systemd 
service files. I am currently using some quite half baked user services 
frontend for runit for starting these I worked on some time ago.

So I believe there is some talent to draw from when it comes to 
supporting alternative init systems within Debian packages. Both within 
Debian and Devuan communities.

So far the Debian init diversity team runs their publicly accessible 
mailing list on infrastructure outside Debian, also to stay out of the 
heat of all the discussions regarding systemd and focus on getting 
actually work done.

As for the fio package I maintain: I did a sysvinit script myself for it 
and I am gladly willing to accept patches to support other init systems. 
During that work I was even able to improve upon the upstream systemd 
service file considerably as I learned about an option to daemonize fio I 
was not aware of.

Testing sysvinit stuff can be done on either Debian or Devuan inside a 
VM. Actually for me it is the other way around: To actually test the 
systemd service file for the fio service I need to use another system 
meanwhile, as my main laptop runs on sysvinit and elogind since more 
than a month and I have no intentions to change it back at the moment. 
Instead I plan to switch my other laptop as well, which should be as 
easy as:

apt install elogind libpam-elogind-compat sysvinit

In addition to that if you have some cron job or sysvinit script which 
requires some testing I am happy to help out as I manage to allocate 
time for that. I am not sure whether that libpam-elogind-compat package 
from experimental is still needed. Also it can easily be switched back 
to Systemd as well as well.

That mentioned I believe there is no use in forcing anyone to do 
anything within the Debian project except what is necessary to maintain 
the boundaries of a code of conduct which helps everyone who uses Debian 
or contributes to it welcome.

Again, I do not have a quick or easy solution. And I may be the only 
Debian package maintainer who switched his main system to sysvinit, but… 
it may still be interesting to read about this different perspective 
here.

I did not share my reasons for switching to Sysvinit. Simply because I 
am just not interested in triggering yet another discussion for or 
against Systemd here.

Thanks,
-- 
Martin

Re: systemd services that are not equivalent to LSB init scripts

[Russ Allbery]

Vincent Bernat  writes:
>  ❦ 14 juillet 2019 12:30 -07, Russ Allbery :

>> There seems to be a clear infrastructure gap for the non-systemd world
>> here that's crying out for some inetd-style program that implements the
>> equivalent of systemd socket activation and socket passing using the
>> same protocol, so that upstreams can not care whether the software is
>> started by systemd or by that inetd, and provides an easy-to-configure
>> way for Debian packages to indicate this should be used if systemd
>> isn't in play.

> What's the point? The alternative to not using systemd socket server is
> to run the daemon as usual.

The point is to support on sysvinit services that, upstream, only support
socket activation.

> If an upstream decides to tie a daemon to systemd socket server by
> delegating the socket creation to systemd, why would we need to
> implement anything? Don't we have better things to do?  This init
> diversity crusade is eating our time.

I'm not saying you should write this.  I'm saying that people who want to
support alternatives to systemd should consider writing this, since it
would make it much easier to continue to support a whole class of services
on both systemd and non-systemd environments.

In other words, I think the best way forward for those who want to support
alternatives to systemd would be for those interested to collaborate on
building tools that implement the functionality of systemd unit files
without being tied to systemd.  That way, there could be a suite of tools
that either interprets unit files directly or that could use some
configuration generated automatically from unit files.  That way, we've
separatedly the API from the implementation and added multiple
implementations, and hopefully this will significantly increase the
chances that packages will work on non-systemd systems even if the
maintainer doesn't test them on such systems.  One such tool would be an
inetd-style service that implements socket activation.  Another could be a
jailing wrapper program that implements the namespacing and syscall
filtering features of systemd.  And so forth.

For better or worse, the unit file syntax is becoming increasingly common
upstream, and more upstreams assume they can configure their software with
that syntax and get a consistent set of features.  Implementing that
configuration syntax and those features seems more likely to me to be
viable in the long run than maintaining multiple configuration sets for
every package.

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

Bug#932091: ITP: golang-github-knqyf263-go-dep-parser -- Golang library for dependency parser

[Nobuhiro Iwamatsu]

Package: wnpp
Severity: wishlist
Owner: Nobuhiro Iwamatsu 

* Package name: golang-github-knqyf263-go-dep-parser
  Version : 0.0~git20190521.1ef8521-1
  Upstream Author : Teppei Fukuda
* URL : https://github.com/knqyf263/go-dep-parser
* License : Expat
  Programming Lang: Go
  Description : Golang library for dependency parser

 go-dep-parser is golang library that dependency parser for multiple
 programming languages.
 .
 This parses package dependencies using the packaging system of each language.
 Supports the following systems:

  -bundler / Ruby
  -cargo / Haskell
  -composer / PHP
  -npm / node.js
  -pipinv / Python
  -poetry / Python
  -types / Python
  -yarn / node.js

Bug#932092: ITP: golang-github-knqyf263-nested -- Golang library for easier way to handle the nested data structure

[Nobuhiro Iwamatsu]

Package: wnpp
Severity: wishlist
Owner: Nobuhiro Iwamatsu 

* Package name: golang-github-knqyf263-nested
  Version : 0.0.1
  Upstream Author : Teppei Fukuda
* URL : https://github.com/knqyf263/nested
* License : Expat
  Programming Lang: Go
  Description : Golang library for easier way to handle the nested data 
structure

 nested is a golang library that this provides functionality to easily handle
 nested data structures.
 .
 This library provides functions for set, get and delete data, and converting
 and getting data into integer.

Re: Proposition: Insert Mozilla Firefox Release in Debian

[Paul Wise]

On Sun, Jul 14, 2019 at 9:57 PM  wrote:

> Please Insert Mozilla Firefox Release in Debian.

Mozilla Firefox is available in Debian, the package name is firefox-esr.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Search field in LXDE Desktop

[Paul Wise]

On Sun, Jul 14, 2019 at 9:51 PM  wrote:

> Please add a Search field in LXDE Menu.

This suggestion sounds like it would be best to send to the LXDE community:

https://lxde.org/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Proposition: Insert Mozilla Firefox Release in Debian

[The Wanderer]

On 2019-07-14 at 22:03, Paul Wise wrote:

> On Sun, Jul 14, 2019 at 9:57 PM  wrote:
> 
>> Please Insert Mozilla Firefox Release in Debian.
> 
> Mozilla Firefox is available in Debian, the package name is
> firefox-esr.

That's the ESR version. I read this as being a request to include the
"release" version, i.e., mainline non-ESR.

My understanding is that that's a nonstarter for one reason and another,
but I don't recall all the specifics involved.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Proposition: Insert Mozilla Firefox Release in Debian

[Russ Allbery]

The Wanderer  writes:
> On 2019-07-14 at 22:03, Paul Wise wrote:
>> On Sun, Jul 14, 2019 at 9:57 PM  wrote:

>>> Please Insert Mozilla Firefox Release in Debian.

>> Mozilla Firefox is available in Debian, the package name is
>> firefox-esr.

> That's the ESR version. I read this as being a request to include the
> "release" version, i.e., mainline non-ESR.

> My understanding is that that's a nonstarter for one reason and another,
> but I don't recall all the specifics involved.

It's there, it's the firefox package.  It's just not included in stable
releases because it doesn't get security support for the lifetime of
stable, so doesn't meet our stable guarantees.

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

Bug#932100: ITP: golang-github-knqyf263-go-version -- Go library for parsing and verifying versions, and version constraints

[Nobuhiro Iwamatsu]

Package: wnpp
Severity: wishlist
Owner: Nobuhiro Iwamatsu 

* Package name: golang-github-knqyf263-go-version
  Version : 1.1.1
  Upstream Author : Teppei Fukuda
* URL : https://github.com/knqyf263/go-version
* License : MPL-2.0
  Programming Lang: Go
  Description : Go library for parsing and verifying versions, and version 
constraints

 go-version is a library for parsing versions and version constraints,
 and verifying versions against a set of constraints. go-version can sort
 a collection of versions properly, handles prerelease/beta versions,
 can increment versions, etc.