Processed: Re: Bug#1068823: (No Subject)

[Debian Bug Tracking System]

Processing control commands:

> reassign -1 src:apt
Bug #1068823 [general] Stepwise Debian upgrade to enable systems with little 
free storage space to upgrade without breaks due to "No space left on device"
Bug reassigned from package 'general' to 'src:apt'.
Ignoring request to alter found versions of bug #1068823 to the same values 
previously set
Ignoring request to alter fixed versions of bug #1068823 to the same values 
previously set
> severity -1 wishlist
Bug #1068823 [src:apt] Stepwise Debian upgrade to enable systems with little 
free storage space to upgrade without breaks due to "No space left on device"
Severity set to 'wishlist' from 'normal'

-- 
1068823: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068823
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1068823: (No Subject)

[Jeremy Bícha]

Control: reassign -1 src:apt
Control: severity -1 wishlist

On Sat, Apr 13, 2024 at 1:00 PM mYnDstrEAm  wrote:
> Thanks guys, these are very useful methods and I'll mention these as 
> alternatives to disk cleanups recommended at 
> https://unix.stackexchange.com/q/774199/233262 (this would probably very 
> useful to have at places about upgrades failing due to disk space issues even 
> though people only look these up once the problems already occurred).
>
> However, the problem of the upgrade requiring more disk space than displayed 
> at first remains and the command by Zeimetz can't be used with a built-in 
> rememberable well-known command like sudo apt-get upgrade --stepwise

Personally, I don't think a machine that has that limited storage
ought to be upgraded using apt from one Debian stable release to
another. I suggest upgrading the storage first. If that's not
possible, I recommend replacing the OS with a new image of Debian
rather than trying to use apt to upgrade a few packages at a time. As
has already been mentioned, it is not supported to arbitrarily break
apt updates up like that to upgrade from say Debian 12 to the
not-yet-released Debian 13.

Thank you,
Jeremy Bícha

Bug#1068823: (No Subject)

[mYnDstrEAm]

Thanks guys, these are very useful methods and I'll mention these as 
alternatives to disk cleanups recommended at 
https://unix.stackexchange.com/q/774199/233262 (this would probably very useful 
to have at places about upgrades failing due to disk space issues even though 
people only look these up once the problems already occurred).

However, the problem of the upgrade requiring more disk space than displayed at 
first remains and the command by Zeimetz can't be used with a built-in 
rememberable well-known command like sudo apt-get upgrade --stepwise

I don't think peripheral devices would be the common case for personal 
computers, rather one would simply specify a directory on a partition that is 
larger than the root partition.

Upgrading individual packages is not what this is about in case that wasn't 
clear. It's one upgrade but it's separated into several steps where one batch 
of packages are download and installed, the cache deleted, and then the next 
batch.
If the upgrade breaks in between due to disk space, because the user aborted 
it, a crash, or an error, then only some packages are upgraded...a stepwise 
upgrade could if anything be a way to *avoid* that (or at least interruptions 
due to disk space problems) and to make them less problematic.
The key thing is that it would be usable with a simple command (such as by 
adding --stepwise)...if that command only executes a few already existing 
commands with no apt changes required for the basic functionality of this, 
that's all the better.

Bug#1061518: (no subject)

[other]

Package: general
Severity: serious
X-Debbugs-Cc: a...@a.com, h...@test.com

Bug#1057386: Subject: ITP: imsprog -- linux chip programmer for CH341a devices

[Mikhail Medvedev]

Package: wnpp
Severity: wishlist
Owner: Mikhail Medvedev 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name    : imsprog
  Version : 1.1.2-12
  Upstream Author : Mikhail Medvedev 
* URL : https://github.com/bigbigmdm/IMSProg
* License : GPL-3
  Programming Lang: C, C++, Bash
  Description : GUI Chip programmer for CH341a devices


IMSProg  -  QT-based  GUI  application  -  I2C,  MicroWire and SPI EEP‐
ROM/Flash chip programmer for CH341a devices. The IMSProm is a free I2C
EEPROM  programmer tool for CH341A device based on QhexEdit2 and modify
SNANDer programmer.

 IMSProg consists of three executable modules:

 1. IMSProg - the chip programmer itself.

 2. IMSProg_editor - chip database editor.

 3. IMSProg_database_update - online chip database update from  the ex‐
ternal web-server.


--
Mikhail Medvedev 

[no subject]

[Zebediah Beck]

Good day sir/madam

I'm a long time debian user but would like that contribute technical
documentation to the community in thanks for your tireless work on this
magnificent ecosystem.

Thanks
Zebb

Bug#1056052: Subject: ITP: wasix-libc -- wasix libc implementation for WebAssembly

[daichi1.fukui]

Package: wnpp
Owner: Fukui Daichi 
X-Debbugs-Cc: debian-devel@lists.debian.org
Severity: wishlist

* Package name: wasix-libc
  Version : 0.0~git20230922.d0362cb
  Upstream Author : Johnathan Sharratt 
* URL : https://github.com/wasix-org/wasix-libc
* License : Apache-2.0 and Apache-2.0-with-LLVM-Exceptions and Expat
  Programming Lang: C
  Description : wasix libc implementation for WebAssembly

Reason for ITP:
wasix-libc is the libc implementation for WebAssembly (WASM) with POSIX 
conformance.
WASIX is a superset on top of WASI, so wasix-libc incorporates POSIX-compliant 
extentions
such as support for sockets, which are not available in wasi-libc.
With this package, we will be able to build a C source code with POSIX 
interfaces into a WASM module.

A git repository will be created on salsa:
https://salsa.debian.org/dfukui/wasix-libc

Maintenance plan:
Because I have less experience in debian packaging, I would like to
ask Debian developers to review my upload. I need a sponsor too.
Report will be sent to Debian Bug Tracking System 

Subject: Package name streamlink-twitch-gui RTP: streamlink-twitch-gui A graphical user interface on top of the Streamlink command line interface

[james smith]

Package name : streamlink-twitch-gui
Severity: RTP
Package name: streamlink-twitch-gui
Version: 0.0.27
Upstream Author: https://github.com/rustdesk/rustdesk
URL: https://streamlink.github.io/streamlink-twitch-gui/
License: MIT
Description: A graphical user interface on top of the Streamlink
 command line interface
Copyright: N/A depends=('streamlink' 'libxss' 'gtk3')
optdepends=('libpulse: Pulseaudo) source=("
https://github.com/streamlink/streamlink-twitch-gui/releases/tag/v2.3.0;
"LICENSE-$pkgver.html:
https://github.com/streamlink/streamlink-twitch-gui/blob/master/LICENSE;
"OSS-LICENSES-$pkgver.html::
https://github.com/streamlink/streamlink-twitch-gui/blob/master/LICENSE;)
sha512sums=() Please let me know if you need any more info

Bug#1011504: Subject: ITP: deepin-image-editor -- Image editor is a public library for deepin-image-viewer and deepin-album developed by Deepin Technology.

[Aiguo Ma]

Package: wnpp
X-Debbugs-Cc: debian-devel@lists.debian.org
Owner: Ma Aiguo 
Severity: wishlist

* Package name: deepin-image-editor
  Version : 1.0.13
  Upstream Author : Deepin Technology Co., Ltd.
* URL : https://github.com/linuxdeepin/image-editor
* License : GPLv3.
  Programming Lang: C++
  Description : Image editor is a public library for
deepin-image-viewer and deepin-album developed by Deepin Technology.

I intend to co-maintain this package inside pkg-deepin team.

[no subject]

[Michael Lazin]

The UFW firewall package uses iptables at the backend, but it is lacking
syntax to block UDP ports and I think this would be useful.

I ran the command "UFW default deny incoming UDP" and it wrote to the chain
successfully, but I ran nslookup afterwards and it succeeded, meaning that
it did not block UDP all ports because DNS uses UDP.  This may be a bug.

Michael Lazin

.. τὸ γὰρ αὐτὸ νοεῖν ἐστίν τε καὶ εἶναι.

Bug#1009236: Subject: ITP: node-canvas-confetti -- on-demand confetti gun

[Onyeka Ikwuegbu]

Package: wnpp
Severity: wishlist
Owner: Michael Ikwuegbu 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-canvas-confetti
  Version : 1.5.1
  Upstream Author  : Kiril Vatev 
* URL : https://github.com/catdad/canvas-confetti#readme
* License : ISC
  Programming Lang: JavaScript
  Description :  on-demand confetti gun
 canvas-confetti is a performant confetti animation in the browser.
 The library helps customize confetti effects.
  .
  Node.js is an event-based server-side JavaScript engine.

   Praveen agreed to sponsor this package.

Bug#1005379: Subject: ITP: elpa-macaulay2 -- Software system for algebraic geometry research (Emacs package)

[Torrance, Douglas]

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

* Package name: elpa-macaulay2
 Version : 1.19.1
 Upstream Author : Dan Grayson 
* URL : http://github.com/Macaulay2/M2-emacs
* License : GPL-3+
 Programming Lang: Emacs Lisp
 Description : Software system for algebraic geometry research (Emacs 
package)

Macaulay 2 is a software system for algebraic geometry research, written by
Daniel R. Grayson and Michael E. Stillman.  Based on Groebner bases, it
provides algorithms for computing homological invariants of rings and
modules.

This package contains the modes for running Macaulay2 within Emacs and
editing Macaulay2 code.

The binary package elpa-macaulay2 already exists in the archive and is built
currently by the macaulay2 source package.  However, the code was split off into
its own repository a while ago, and I believe it would simplify things if it
had its own source package as well.

I intend to continue maintaining this package under the umbrella of the Debian
Math Team.


signature.asc
Description: PGP signature

Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not

[Felipe Sateler]

On Tue, 25 Jan 2022 21:38:01 +0100, Vincent Bernat wrote:

> 
> I think we should forego the NEW queue. If people want to check
> packages, they can do it once they are in unstable with regular bugs.
> Current checks are partly done by Lintian and I suppose people could
> watch new Lintian warnings and detect bad packages quickly. This could
> be done when src is not NEW as a test. People could loose their upload
> rights if they are caught abusing the system (and get DM rights for some
> selected packages instead).

+1. If we have a good remediation mechanism, this bottleneck is not 
necessary.

Re: Do we need to hide packages in NEW queue (Was: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not))

[Francesco Poli]

On Wed, 26 Jan 2022 07:38:10 +0100 Andreas Tille wrote:

> Am Tue, Jan 25, 2022 at 01:45:11PM -0800 schrieb Russ Allbery:
[...]
> > The question, which keeps being raised in part
> > because I don't think it's gotten a good answer, is what the basis is for
> > treating copyright and licensing bugs differently than any other bug in
> > Debian?

I thought the basis was the fact that copyright and licensing bugs may
have bad legal consequences (lawsuits against the Project for
distributing legally undistributable packages, things like that), while
technical bugs do not cause issues with lawyers and are, in this sense,
"easier" to fix.
The consequences of introducing a "legally botched" package into the
archive are thus harder to undo, with respect to introducing a
technically flawed package...

> > 
> > The need for pre-screening was obvious when we had export control issues,
> > but my understanding is that those have gone away.  Are we working from
> > legal advice telling us that this pre-screening is required for some legal
> > purpose?  If so, is it effective for the legal purpose at which it is
> > aimed?  Is this system left over from old advice?  Have we checked our
> > assumptions recently?

I am under the impression that the pre-screening in the NEW queue is an
attempt to catch legal issues *before* the package is introduced into
the archive.
As far as I remember, the FTP masters are the people responsible for
what the Debian Project distributes through its archive...

Is this wrong (or no longer valid)?

[...]
> > NEW processing is a lot of friction for the project as a whole and a lot
> > of work for the ftp team.  If we were able to do less work at the cost of
> > a minimal increase in bugs, or at the cost of handling bugs a bit
> > differently, maybe that would be a good thing?
> > 
> > In other words, it's unclear what requirements we're attempting to meet
> > and what the basis of those requirements is, which makes it hard to have a
> > conversation about whether the current design is the best design for the
> > problem we're trying to solve.
> 
> I'm CCing debian-legal for this branch of the discussion (but I do not
> read this list and think keeping debian-devel in the row is a good idea).

Personally, I think the legal pre-screening by the FTP masters in the
NEW queue is useful and should be kept.

In fact, I wish the pre-screening were stricter.

I've seen cases, where a bug is reported against a legally
undistributable package and the issue is left unaddressed for ages with
nobody apparently caring enough.
Maybe it's better, if such issues are addressed *before* the package is
accepted into the archive...


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpWiRMgvfmm3.pgp
Description: PGP signature

Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not

[Alec Leamas]

Hi,

Not a DD, still raising my voice. I'm *not* advocating that Fedora's 
processes are "better", just trying to add ideas.


On 26/01/2022 11:43, Adam Borowski wrote:

On Tue, Jan 25, 2022 at 09:38:01PM +0100, Vincent Bernat wrote:



I think we should forego the NEW queue. If people want to check
packages, they can do it once they are in unstable with regular bugs.


Without the NEW queue, there would be no point at which packaging receives
any sort of review.  I'd prefer Debian to deliver at least some level of
quality.


Perhaps wrong to focus on the queue as such. The focus should be the 
need for a manual review -- this is IMHO the important point.


The current ftpmaster review model is somehow modeled after a 
"supervisor" idea. Fedora uses peer reviews. The advantage is the 
incentive to make reviews:  I can review your package if you review 
mine. One could of course imagine that this would lead to sloppy 
reviews. However, this is not my experience.


It also means a more transparent process.



Otherwise, we'd fall to the level of NPM.  And there's ample examples what
that would mean.


Indeed.


Current checks are partly done by Lintian and I suppose people could
watch new Lintian warnings and detect bad packages quickly.


Lintian is just a dumb machine that can ease human reviews but not replace
them.



Yes. It's interesting to compare to Fedora's tooling fedora-review which 
has another focus: It outputs list of things to check when reviewing a 
package. Some of those are automatically checked, others are just a 
checkbox which should be manually checked. Lintian is a good tool, but 
not IMHO a review support.




This could be done when src is not NEW as a test.


I've managed to trample upon someone else's package just yesterday -- and it
escaped automated checks because a binary of that name already existed in
the archive, just not on any arch which I test.



Yes, one of those manual checks...

On 26/01/2022 11:29, Adam Borowski wrote:

> For practical reasons we have to obey the laws, no matter how oppressive
> they are.  But I don't see why we should do more than eg. Fedora which
> has corporate backing with an actual legal team.

Also note that this legal team *not* is used to review all packages. 
Instead, they are a resource which are contacted by packagers when we 
need advice. The typical situation is in a (peer) review where things 
cannot be settled. The legal team also files bugs as required, and 
maintain the packaging manual's copyright part.


Of course, this creates a very different social relation between the 
legal team and the rest.


Just my 5 öre
--alec

Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not

[Gard Spreemann]

Adam Borowski  writes:

> On Tue, Jan 25, 2022 at 09:38:01PM +0100, Vincent Bernat wrote:
>> For me, the copyright check is just a bad excuse. People upload
>> non-distributable stuff everywhere and it seems the world continue to go
>> round. What amount of non-distributable packages is stopped by the NEW
>> queue?
>> 
>> I think we should forego the NEW queue. If people want to check
>> packages, they can do it once they are in unstable with regular bugs.
>
> Without the NEW queue, there would be no point at which packaging receives
> any sort of review.  I'd prefer Debian to deliver at least some level of
> quality.
>
> Otherwise, we'd fall to the level of NPM.  And there's ample examples what
> that would mean.

Is this not the job of the Policy and of community self-policing by
means of RC bugs?


 Best,
 Gard


signature.asc
Description: PGP signature

Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not

[Stephan Lachnit]

On Wed, Jan 26, 2022 at 11:43 AM Adam Borowski  wrote:
>
> On Tue, Jan 25, 2022 at 09:38:01PM +0100, Vincent Bernat wrote:
> >
> > I think we should forego the NEW queue. If people want to check
> > packages, they can do it once they are in unstable with regular bugs.
>
> Without the NEW queue, there would be no point at which packaging receives
> any sort of review.  I'd prefer Debian to deliver at least some level of
> quality.
>
> Otherwise, we'd fall to the level of NPM.  And there's ample examples what
> that would mean.

I disagree with the comparison to NPM. Simply because not everyone can
upload - you have to be DD or DM to do that, which means you have to
go through a non-trivial process where it is checked that you know
what you do. As of right now, a malicious acting DD can already upload
harmful packages without NEW stopping this at all.

Regards,
Stephan

Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not

[Adam Borowski]

On Tue, Jan 25, 2022 at 09:38:01PM +0100, Vincent Bernat wrote:
> For me, the copyright check is just a bad excuse. People upload
> non-distributable stuff everywhere and it seems the world continue to go
> round. What amount of non-distributable packages is stopped by the NEW
> queue?
> 
> I think we should forego the NEW queue. If people want to check
> packages, they can do it once they are in unstable with regular bugs.

Without the NEW queue, there would be no point at which packaging receives
any sort of review.  I'd prefer Debian to deliver at least some level of
quality.

Otherwise, we'd fall to the level of NPM.  And there's ample examples what
that would mean.

> Current checks are partly done by Lintian and I suppose people could
> watch new Lintian warnings and detect bad packages quickly.

Lintian is just a dumb machine that can ease human reviews but not replace
them.

> This could be done when src is not NEW as a test.

I've managed to trample upon someone else's package just yesterday -- and it
escaped automated checks because a binary of that name already existed in
the archive, just not on any arch which I test.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Aryans: split from other Indo-Europeans ~2900-2000BC → Ural →
⣾⠁⢠⠒⠀⣿⡁ Bactria → settled 2000-1000BC in northwest India.
⢿⡄⠘⠷⠚⠋⠀ Gypsies: came ~1000AD from northern India; aryan.
⠈⠳⣄ Germans: IE people who came ~2800BC to Scandinavia; not aryan.

Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not

[Adam Borowski]

On Wed, Jan 26, 2022 at 10:44:37AM +0100, Gard Spreemann wrote:
> Jonas Smedegaard  writes:
> > Quoting Vincent Bernat (2022-01-25 21:38:01)
> >> I didn't comment at first because I thought someone else would raise 
> >> the idea. But it seems people still like the idea of a NEW queue. Not 
> >> me. The NEW queue is a hindrance.

> > I don't like current copyright laws, and I suspect a fair amount of 
> > people involved in Free Software doesn't.

I for one consider copyright theft, a crime against humanity[1], and a waste
of time.  Any second spent dealing with copyright is a second not spent adding
features or fixing technical bugs.

For practical reasons we have to obey the laws, no matter how oppressive
they are.  But I don't see why we should do more than eg. Fedora which
has corporate backing with an actual legal team.

For those of you without a Fedora box at hand, I made a tarball:
  https://angband.pl/tmp/fedora-licenses.tar.xz
This is so less than we do!

> > I just don't think the solution is to ignore copyright or licensing 
> > statements.

On the other hand, "grep -r Copyright|uniq" plus a copy of non-standard
licenses would be enough.

> To me, the elephant in the room is this question: Does the way the NEW
> queue currently works provide good (good enough?) assurances to
> ourselves that we are *not* ignoring copyright or licensing?

I think the NEW review is much needed, and currently grossly inadequate
-- and that's because 95% of the FTPmaster time being spent on copyright
crap rather than technical matters.


Meow!

[1]. The needs of a human go into two groups: 1. those shared with
non-human animals (food, air, freedom, shelter, reproduction, not being
killed, not being hurt, etc), and 2. those dependant on transmission
of ideas.  And transmission of ideas is directly hindered by copyright.
-- 
⢀⣴⠾⠻⢶⣦⠀ Ash nazg durbatulûk,
⣾⠁⢠⠒⠀⣿⡁   ash nazg gimbatul,
⢿⡄⠘⠷⠚⠋⠀ ash nazg thrakatulûk
⠈⠳⣄   agh burzum-ishi krimpatul.

Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not

[Gard Spreemann]

Jonas Smedegaard  writes:

> Quoting Vincent Bernat (2022-01-25 21:38:01)
>> I didn't comment at first because I thought someone else would raise 
>> the idea. But it seems people still like the idea of a NEW queue. Not 
>> me. The NEW queue is a hindrance.
>
> For the record, I don't "like" the NEW queue.
>
> I don't like current copyright laws, and I suspect a fair amount of 
> people involved in Free Software doesn't.
>
> I just don't think the solution is to ignore copyright or licensing 
> statements.

To me, the elephant in the room is this question: Does the way the NEW
queue currently works provide good (good enough?) assurances to
ourselves that we are *not* ignoring copyright or licensing?

It feels like we are answering "yes" based on the amount of heroic work
the FTP masters put in, and the amount of waiting developers have to
suffer through. We're gauging our solution to a problem solely by the
amount of effort, sweat and tears we put in, so to speak.


 Best,
 Gard
 


signature.asc
Description: PGP signature

Re: Do we need to hide packages in NEW queue (Was: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not))

[Philip Hands]

Andreas Tille  writes:

...
> May be some intermediate step would be to not hide packages in NEW queue
> but exposing them as an apt source.  If I'm correct this is not the case
> since it had certain legal consequences for the project if code with
> certain non-free licenses would be downloadable from some debian.org
> address.  May be NEW could be considered as some kind of pre-non-free as
> long as it is not checked and the legal consequences are not valid for
> us any more.  But I'm not educated in international law - just asking
> whether somebody might know better.

I have a repository on salsa: 
https://salsa.debian.org/installer-team/branch2repo
that allows one to easily take a collection of branches (with the same
branch name) from several repos, and assemble the (u)debs that one can
build from all those branches into an apt repo.

The motivation for that is for testing patches to Debian-Installer, but
it should work for anything, so if that (or something like it) got
merged into the main salsa-CI pipeline then people could more easily
decouple the testing of new packages from their progress through NEW.

This does of course raise the question of whether I ought to be able to
do that, since it creates apt repos, such as this (trivial) example:

  
https://salsa.debian.org/installer-team/branch2repo/-/jobs/2365384/artifacts/browse/public/

that publish .debs from a debian.org host, that could easily be created
from sources that have never been near NEW.

Of course, the URL is not exactly obvious there, and the artifacts will
get deleted, so maybe that's a difference, but I don't suppose it would
be too hard to make that into a stable 'pages' URL and ensure that it
got built often enough to keep the repo there permanently.  Would that
cross the line?

I think the important distinction is probably that once packages get
through NEW they are mirrored all over the world, by unsuspecting third
parties, who live in every jurisdiction under the sun. They are also
incorporated into down-stream distros, often with little/no manual
oversight, some of whom then do things like selling their resulting
distribution for profit.

That involves other people in a lot of risks that might not apply to
Debian itself, so I'd suggest requires rather more caution than trying
to see what we alone can expect to get away with.

Do we need to shut down salsa's ability to do the above (given that one
can do all of that from a guest account, using any old code you
uploaded), or is that OK because the URLs are unstable and/or obscure?
(obviously, given that I did it, I think it's OK)

If obscure URLs are enough, I'd think it would be OK to have things in
the NEW queue available from repo URLs that were not something that one
could easily mirror, and would not be an "all of current NEW repo" but
rather something like an apt repo per upload, so that one could easily
test stuff stuck in NEW, but wouldn't be tempted to just install
everything that hits NEW by default.

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

Do we need to hide packages in NEW queue (Was: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not))

[Andreas Tille]

Am Tue, Jan 25, 2022 at 01:45:11PM -0800 schrieb Russ Allbery:
> Jonas Smedegaard  writes:
> 
> > I just don't think the solution is to ignore copyright or licensing
> > statements.
> 
> That's not the goal.  The question, which keeps being raised in part
> because I don't think it's gotten a good answer, is what the basis is for
> treating copyright and licensing bugs differently than any other bug in
> Debian?
> 
> The need for pre-screening was obvious when we had export control issues,
> but my understanding is that those have gone away.  Are we working from
> legal advice telling us that this pre-screening is required for some legal
> purpose?  If so, is it effective for the legal purpose at which it is
> aimed?  Is this system left over from old advice?  Have we checked our
> assumptions recently?

May be some intermediate step would be to not hide packages in NEW queue
but exposing them as an apt source.  If I'm correct this is not the case
since it had certain legal consequences for the project if code with
certain non-free licenses would be downloadable from some debian.org
address.  May be NEW could be considered as some kind of pre-non-free as
long as it is not checked and the legal consequences are not valid for
us any more.  But I'm not educated in international law - just asking
whether somebody might know better.

I'd consider it a big step forward to develop against packages from NEW
queue.  (And yes, *I* know how to help myself with a local mirror but
team wide development is something else.)
 
> NEW processing is a lot of friction for the project as a whole and a lot
> of work for the ftp team.  If we were able to do less work at the cost of
> a minimal increase in bugs, or at the cost of handling bugs a bit
> differently, maybe that would be a good thing?
> 
> In other words, it's unclear what requirements we're attempting to meet
> and what the basis of those requirements is, which makes it hard to have a
> conversation about whether the current design is the best design for the
> problem we're trying to solve.

I'm CCing debian-legal for this branch of the discussion (but I do not
read this list and think keeping debian-devel in the row is a good idea).

Kind regards

  Andreas. 

-- 
http://fam-tille.de

Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not

[Erik Huelsmann]

Hi Russ,

> > I just don't think the solution is to ignore copyright or licensing
> > statements.
>
> That's not the goal.  The question, which keeps being raised in part
> because I don't think it's gotten a good answer, is what the basis is for
> treating copyright and licensing bugs differently than any other bug in
> Debian?

Sorry to barge in (not being a Debian dev): Having seen this
discussion go back and forth on the topic, I agree that this is the
question. However, after all these mails - including yours - I'm left
with: Posing the question is one thing, but getting it answered is
another. Is there anybody specifically more likely to have an answer
here than anybody else? And if so, is that person/group involved in
this discussion now? If not, shouldn't they be made aware of it?

> The need for pre-screening was obvious when we had export control issues,
> but my understanding is that those have gone away.  Are we working from
> legal advice telling us that this pre-screening is required for some legal
> purpose?  If so, is it effective for the legal purpose at which it is
> aimed?  Is this system left over from old advice?  Have we checked our
> assumptions recently?
>
> NEW processing is a lot of friction for the project as a whole and a lot
> of work for the ftp team.  If we were able to do less work at the cost of
> a minimal increase in bugs, or at the cost of handling bugs a bit
> differently, maybe that would be a good thing?
>
> In other words, it's unclear what requirements we're attempting to meet
> and what the basis of those requirements is, which makes it hard to have a
> conversation about whether the current design is the best design for the
> problem we're trying to solve.


-- 
Bye,

Erik.

Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not

[Russ Allbery]

Jonas Smedegaard  writes:

> I just don't think the solution is to ignore copyright or licensing
> statements.

That's not the goal.  The question, which keeps being raised in part
because I don't think it's gotten a good answer, is what the basis is for
treating copyright and licensing bugs differently than any other bug in
Debian?

The need for pre-screening was obvious when we had export control issues,
but my understanding is that those have gone away.  Are we working from
legal advice telling us that this pre-screening is required for some legal
purpose?  If so, is it effective for the legal purpose at which it is
aimed?  Is this system left over from old advice?  Have we checked our
assumptions recently?

NEW processing is a lot of friction for the project as a whole and a lot
of work for the ftp team.  If we were able to do less work at the cost of
a minimal increase in bugs, or at the cost of handling bugs a bit
differently, maybe that would be a good thing?

In other words, it's unclear what requirements we're attempting to meet
and what the basis of those requirements is, which makes it hard to have a
conversation about whether the current design is the best design for the
problem we're trying to solve.

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

Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not

[Vincent Bernat]

 ❦ 25 January 2022 21:51 +01, Jonas Smedegaard:

>> I didn't comment at first because I thought someone else would raise 
>> the idea. But it seems people still like the idea of a NEW queue. Not 
>> me. The NEW queue is a hindrance.
>
> For the record, I don't "like" the NEW queue.
>
> I don't like current copyright laws, and I suspect a fair amount of 
> people involved in Free Software doesn't.
>
> I just don't think the solution is to ignore copyright or licensing 
> statements.

I mentioned it. No need to ignore, just file regular bugs. I said:

> For me, the copyright check is just a bad excuse. People upload
> non-distributable stuff everywhere and it seems the world continue to
> go round. What amount of non-distributable packages is stopped by the
> NEW queue?
-- 
Use the "telephone test" for readability.
- The Elements of Programming Style (Kernighan & Plauger)

Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not

[Jonas Smedegaard]

Quoting Vincent Bernat (2022-01-25 21:38:01)
> I didn't comment at first because I thought someone else would raise 
> the idea. But it seems people still like the idea of a NEW queue. Not 
> me. The NEW queue is a hindrance.

For the record, I don't "like" the NEW queue.

I don't like current copyright laws, and I suspect a fair amount of 
people involved in Free Software doesn't.

I just don't think the solution is to ignore copyright or licensing 
statements.


 - 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: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not

[Vincent Bernat]

 ❦ 21 January 2022 09:51 -05, M. Zhou:

> I'd rather propose choice C. Because I to some extent understand
> both sides who support either A or B. I maintain bulky C++ packages,
> and I also had a little experience reviewing packages on behalf of
> ftp-team.

I didn't comment at first because I thought someone else would raise the
idea. But it seems people still like the idea of a NEW queue. Not me.
The NEW queue is a hindrance. I have stopped contributing to Python
stuff for this reason. Packaging something can take weeks because you
need to upload one package, wait for it to be reviewed, then package the
next one, etc. You could upload many packages at once, but it makes
testing and building more difficult. New contributors may just give up
by the time their first package is accepted. I think we have many
unmaintained packages for this reason (no real stats on my side, but
when a package is several versions late, it's usually a sponsored upload
or one of my packages).

I would propose that there should be a reputation system. You can get
points by uploading stuff without issues and lose them if there are
errors. If you have enough points, you can spend them to skip the check.
But someone would have to implement it and the team being understaffed
for whatever reason (and maybe not convinced by this system), I know
this won't be done (we don't have PPA because FTP team wants to
implement it but no time, we don't have autosigned packages because
nobody has time to implement it, etc).

For me, the copyright check is just a bad excuse. People upload
non-distributable stuff everywhere and it seems the world continue to go
round. What amount of non-distributable packages is stopped by the NEW
queue?

I think we should forego the NEW queue. If people want to check
packages, they can do it once they are in unstable with regular bugs.
Current checks are partly done by Lintian and I suppose people could
watch new Lintian warnings and detect bad packages quickly. This could
be done when src is not NEW as a test. People could loose their upload
rights if they are caught abusing the system (and get DM rights for some
selected packages instead). This could be opt-in if people find this
idea offensive.
-- 
Avoid temporary variables.
- The Elements of Programming Style (Kernighan & Plauger)

Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not

[Phil Morrell]

On Mon, Jan 24, 2022 at 01:49:19PM -0500, Theodore Y. Ts'o wrote:
> On Mon, Jan 24, 2022 at 08:15:30AM +0100, Andreas Tille wrote:
> > 
> > its surely an interesting topic how to avoid binary name changes and its
> > also interesting to discuss ABI changes and workarounds.
> > 
> > However, my point was that I want to know what policy ftpmaster applies
> > to new binary names and to focus on this topic.
> 
> As far as I know, ftpmaster requires a long, laborious review every
> single time there is a new binary package released.  As a result, it
> strongly disincentivizes maintainers from packaging up new releases
> because it's a pain in the posterior.
> 
> Even if it isn't formal policy, the long delay has happened enough
> times that I just assume it will be there, and it influences my
> behavior accordingly.

I like the earlier thread idea of de-coupling the copyright review
(eventually of NEW entirely? but for now, just bin NEW) from "the other
checks and balances". Ultimately, a mistake in debian/copyright *can* be
just considered a bug with priority determined just like any other, so
long as it is still legal for Debian to distribute. However, this is an
issue whenever upstream ships a new source file, not when a new binary
is added, so I hope that good maintainers do their due diligence on new
upstream releases.

If that is agreed informally, then while a lottery review would be a
cool addition, it would not be a prerequisite to dropping its
requirement for sources which have already been accepted into the
archive once. This could be formalised via a GR empowering the FTP team.

That last has made me wonder if the ftp-master team could split the NEW
source queue into two phases, one where a copyright review is performed
and one where the other checks are. I can see pros and cons for either
way round these phases could be done, but one should feed into the
other. Presumably, that this has not already happened means there would
be little benefit because of context switching?


signature.asc
Description: PGP signature

Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not

[Andreas Tille]

Am Mon, Jan 24, 2022 at 06:50:17PM -0500 schrieb Theodore Y. Ts'o:
> 
> So could the Release Team figure out a way to automatically rebuild
> packages that have source dependencies on static libraries?
> 
> This would solve the problem of new binary packages causing a full
> ftpmasters policy review of packages, at least for those who need to
> create new binary packages each time SONAME gets bumped.

If I were a member of the release team I would wait until this thread
might uncover some statement by ftpmaster whether this full review
is actually intended or the waiting time is rather caused by the lack
of an appropriate automatic tool that needs to be written.

Kind regards

 Andreas.

-- 
http://fam-tille.de

Re: Back to the topic of changed binary named (Was: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not))

[Stephan Lachnit]

On Mon, Jan 24, 2022 at 8:15 AM Andreas Tille  wrote:
>
> However, my point was that I want to know what policy ftpmaster applies
> to new binary names and to focus on this topic.  I really want to know
> that policy of ftpmaster and I really would like to see that documented
> and I'm afraid that thread is drifting away from the original topic
> that I will not get any answer on this.
>
> So again: I see a conflict in my interpretation of the mail[1] (original
> posters again in CC) which suggests "an auto-approver" and what I'm
> currently observing and I would be really happy if we can document the
> policy for changed (and new) binary names of existing source packages.

Since I feel my mail went lost in the discussion, here again my opinion:

Option C. New binary packages where the src is already in Debian can
still go through NEW for sanity checks, but do not require a
d/copyright review. These packages should be checked with priority
since they should be quick to review. Same goes for source packages
renames.

Instead, I suggest starting a "d/copyright review lottery" working
group with the goal to review the d/copyright of every package in
testing if changed since the last stable release, especially before
the next stable release. I would personally join this endeavor and
help to write tools to keep track of which packages are "eligible" for
the lottery.
This offloads a lot of work from the ftp-masters and in making regular
d/copyright reviews for all packages split among project members
should also increase the quality of these.

On Mon, Jan 24, 2022 at 8:15 AM Andreas Tille  wrote:
>
> To give another example which has nothing todo with ABI changes:
> Currently I'm afraid of splitting some Arch: all data from some
> Arch: any package since I'm simply afraid of the changed package
> sticking long in new queue.  I know this is bad - but I consider
> users waiting for package updates worse.

On Mon, Jan 24, 2022 at 7:49 PM Theodore Y. Ts'o  wrote:
>
> As far as I know, ftpmaster requires a long, laborious review every
> single time there is a new binary package released.  As a result, it
> strongly disincentivizes maintainers from packaging up new releases
> because it's a pain in the posterior.  A while back, people asked me I
> could update f2fs-tools, and it was shortly before the release freeze,
> and even though there was apparently security fixes involved that
> would be fixed in the latest version of f2fs-tools, I knew there would
> be no point, since there was no way the package would squirt out the
> review pipeline before the release freeze.
>
> Even if it isn't formal policy, the long delay has happened enough
> times that I just assume it will be there, and it influences my
> behavior accordingly.

These are just two examples where the delay of updates in the NEW
queue affects the quality of a package or a Debian release - while it
should do the opposite. I'm sure there are many more, I'm not a DD for
a long time but I heard the "won't make improvement xyz because of the
NEW queue" argument regularly. IMHO if there is not a sudden increase
of review time from the ftp-masters, something needs to be done before
packages start losing quality due to NEW.

Regards,
Stephan

Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not

[Theodore Y. Ts'o]

On Mon, Jan 24, 2022 at 08:48:28PM +0100, Paul Gevers wrote:
> Hi Ted,
> 
> I think this is the second time you write something like this, but for
> dynamically linked libraries, the rebuild happens (by the Release Team,
> (please use transition trackers for that) because we automatically track
> transitions [1]). Unless people don't follow the convention that your binary
> matches the SONAME. But nowadays we find those more and more due to
> autopkgtest (reverse dependencies that fail because they can't find the
> appropriate library). It becomes increasingly more difficult to hide the
> fact that your package is not named appropriately.

So could the Release Team figure out a way to automatically rebuild
packages that have source dependencies on static libraries?

This would solve the problem of new binary packages causing a full
ftpmasters policy review of packages, at least for those who need to
create new binary packages each time SONAME gets bumped.

- Ted

Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not

[Paul Gevers]

Hi Ted,

On 24-01-2022 19:44, Theodore Y. Ts'o wrote:

No, dpkg-shlibsdeps doesn't save you.  Again, consider the
hypothetical package libshaky, which over the period of 9 months, has
soname changes which generate (over time) packages libshaky3,
libshaky4, libshaky6, libshaky7, and libshaky8.

The latest version of libshaky sources will create the binary packages
libshaky8, libshaky-bin, and libshaky-dev.  Other various external
packages such as say, shaky-cli uses libshaky4, shaky-gtk uses
libshaky6, shaky-qt might use libshaky7, etc.

Now suppose that there is a critical security bug fixed in the latest
version of libshaky sources.  So the security fix is might be fixed in
libshaky8, but the same security bug that allows remote code execution
as well as privileged escalation might apply to libshaky[3467] as
well, but since the fix was only in the latest version of libshaky,
you might as well have been using static libraries in libshaky.
Except that is apparently not allowed by policy.  Oops.


I think this is the second time you write something like this, but for 
dynamically linked libraries, the rebuild happens (by the Release Team, 
(please use transition trackers for that) because we automatically track 
transitions [1]). Unless people don't follow the convention that your 
binary matches the SONAME. But nowadays we find those more and more due 
to autopkgtest (reverse dependencies that fail because they can't find 
the appropriate library). It becomes increasingly more difficult to hide 
the fact that your package is not named appropriately.


Paul

[1] https://release.debian.org/transitions/


OpenPGP_signature
Description: OpenPGP digital signature

Re: Back to the topic of changed binary named (Was: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not))

[Theodore Y. Ts'o]

On Mon, Jan 24, 2022 at 08:15:30AM +0100, Andreas Tille wrote:
> Hi Paul and others,
> 
> its surely an interesting topic how to avoid binary name changes and its
> also interesting to discuss ABI changes and workarounds.
> 
> However, my point was that I want to know what policy ftpmaster applies
> to new binary names and to focus on this topic.  I really want to know
> that policy of ftpmaster and I really would like to see that documented
> and I'm afraid that thread is drifting away from the original topic
> that I will not get any answer on this.

As far as I know, ftpmaster requires a long, laborious review every
single time there is a new binary package released.  As a result, it
strongly disincentivizes maintainers from packaging up new releases
because it's a pain in the posterior.  A while back, people asked me I
could update f2fs-tools, and it was shortly before the release freeze,
and even though there was apparently security fixes involved that
would be fixed in the latest version of f2fs-tools, I knew there would
be no point, since there was no way the package would squirt out the
review pipeline before the release freeze.

Even if it isn't formal policy, the long delay has happened enough
times that I just assume it will be there, and it influences my
behavior accordingly.

- Ted

Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not

[Theodore Y. Ts'o]

On Mon, Jan 24, 2022 at 10:20:48AM +0800, Paul Wise wrote:
> On Sun, 2022-01-23 at 17:43 -0500, Theodore Y. Ts'o wrote:
> 
> > That only works if there are no other packages depending on those
> > shared libraries which are coming from other source packages.
> 
> I don't think that is true, I believe you can put multiple things in
> the depends section of an shlibs file and dpkg-shlibdeps will propagate
> that to reverse dependencies just fine. From the manual pages it looks
> like the same applies to the symbols files. I found on my system that
> there are *already* packages that do something similar (see below).

No, dpkg-shlibsdeps doesn't save you.  Again, consider the
hypothetical package libshaky, which over the period of 9 months, has
soname changes which generate (over time) packages libshaky3,
libshaky4, libshaky6, libshaky7, and libshaky8.

The latest version of libshaky sources will create the binary packages
libshaky8, libshaky-bin, and libshaky-dev.  Other various external
packages such as say, shaky-cli uses libshaky4, shaky-gtk uses
libshaky6, shaky-qt might use libshaky7, etc.

Now suppose that there is a critical security bug fixed in the latest
version of libshaky sources.  So the security fix is might be fixed in
libshaky8, but the same security bug that allows remote code execution
as well as privileged escalation might apply to libshaky[3467] as
well, but since the fix was only in the latest version of libshaky,
you might as well have been using static libraries in libshaky.
Except that is apparently not allowed by policy.  Oops.

  - Ted

P.S.  Let's assume that the reason why SONAME needs to be bumped every
single time is not because upstream is lazy, and just bumps the SONAME
"just in case", but because they did a terrible job designing the
library ABI, and there are complex structures that need to all the
time because they are exposed in the public headers, yet the
structures depend on internal implementation details, so they are
constantly fluid.  This is not a hypothetical situation; the openssl
libraries are very much in the case, and when we were trying to get
them to agree to create a stable ABI for the Linux Standard Base,
usptream basically said, "no can do".

So complex ABI analysis isn't going to help you; you basically have to
rebuild all of the dependent packages whenever the SONAME gets bumped.

Back to the topic of changed binary named (Was: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not))

[Andreas Tille]

Hi Paul and others,

its surely an interesting topic how to avoid binary name changes and its
also interesting to discuss ABI changes and workarounds.

However, my point was that I want to know what policy ftpmaster applies
to new binary names and to focus on this topic.  I really want to know
that policy of ftpmaster and I really would like to see that documented
and I'm afraid that thread is drifting away from the original topic
that I will not get any answer on this.

So again: I see a conflict in my interpretation of the mail[1] (original
posters again in CC) which suggests "an auto-approver" and what I'm
currently observing and I would be really happy if we can document the
policy for changed (and new) binary names of existing source packages.

To give another example which has nothing todo with ABI changes:
Currently I'm afraid of splitting some Arch: all data from some
Arch: any package since I'm simply afraid of the changed package
sticking long in new queue.  I know this is bad - but I consider
users waiting for package updates worse.

Kind regards
Andreas.


[1] https://lists.debian.org/debian-devel/2021/07/msg00231.html

Am Mon, Jan 24, 2022 at 10:20:48AM +0800 schrieb Paul Wise:
> On Sun, 2022-01-23 at 17:43 -0500, Theodore Y. Ts'o wrote:
> 
> > That only works if there are no other packages depending on those
> > shared libraries which are coming from other source packages.
> 
> I don't think that is true, I believe you can put multiple things in
> the depends section of an shlibs file and dpkg-shlibdeps will propagate
> that to reverse dependencies just fine. From the manual pages it looks
> like the same applies to the symbols files. I found on my system that
> there are *already* packages that do something similar (see below).
> ...

-- 
http://fam-tille.de

Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not

[Paul Wise]

On Sun, 2022-01-23 at 17:43 -0500, Theodore Y. Ts'o wrote:

> That only works if there are no other packages depending on those
> shared libraries which are coming from other source packages.

I don't think that is true, I believe you can put multiple things in
the depends section of an shlibs file and dpkg-shlibdeps will propagate
that to reverse dependencies just fine. From the manual pages it looks
like the same applies to the symbols files. I found on my system that
there are *already* packages that do something similar (see below).

> But my claim is that if the upstream can't manage to maintain a stable
> ABI, then maybe we shouldn't be trying to ship shared libraries.  But
> officially, that's not allowed, since it's considered bad.

Personally, to detect such upstreams I think Debian needs a service
tracking ABI using abipkgdiff (from abigail-tools) and pkg-abidiff.
Once we have that it isn't too much more work for Debian to maintain
the SONAME instead of upstream.

> If we have that solution for Rust and Golang, the maybe it can also
> make life easier for upstreams that can't maintain an ABI.

I initially mainly wanted it for static linking detection, I expect
there is some of that (at least in -static packages) in Debian and that
we are not thinking to rebuild such packages after security issues.

Packages that have complex dependencies in shlibs/symbols files:

$ grep -h '^lib.*,' /var/lib/dpkg/info/*.shlibs
libbfd 2.37.50-multiarch.20220106 binutils-multiarch (>= 2.37.50.20220106), 
binutils-multiarch (<< 2.37.50.20220107)
libopcodes 2.37.50-multiarch.20220106 binutils-multiarch (>= 2.37.50.20220106), 
binutils-multiarch (<< 2.37.50.20220107)
libbctoolbox 1 libbctoolbox1 (>= 4.4.0), libbctoolbox1 (<< 4.5.0)
libbellesip 1 libbellesip1 (>= 4.4.0), libbellesip1 (<< 4.5.0)
libbfd 2.37.50-system.20220106 libbinutils (>= 2.37.50.20220106), libbinutils 
(<< 2.37.50.20220107)
libopcodes 2.37.50-system.20220106 libbinutils (>= 2.37.50.20220106), 
libbinutils (<< 2.37.50.20220107)
libboost_python39 1.74.0 libboost-python1.74.0 (>= 1.74.0), 
libboost-python1.74.0-py39
libeabutil 0 libevolution (>= 3.42.3), libevolution (<< 3.43)
libeabwidgets 0 libevolution (>= 3.42.3), libevolution (<< 3.43)
libecontacteditor 0 libevolution (>= 3.42.3), libevolution (<< 3.43)
libecontactlisteditor 0 libevolution (>= 3.42.3), libevolution (<< 3.43)
libecontactprint 0 libevolution (>= 3.42.3), libevolution (<< 3.43)
libemail-engine 0 libevolution (>= 3.42.3), libevolution (<< 3.43)
libessmime 0 libevolution (>= 3.42.3), libevolution (<< 3.43)
libevolution-addressbook-importers 0 libevolution (>= 3.42.3), libevolution (<< 
3.43)
libevolution-calendar-importers 0 libevolution (>= 3.42.3), libevolution (<< 
3.43)
libevolution-calendar 0 libevolution (>= 3.42.3), libevolution (<< 3.43)
libevolution-mail-composer 0 libevolution (>= 3.42.3), libevolution (<< 3.43)
libevolution-mail-formatter 0 libevolution (>= 3.42.3), libevolution (<< 3.43)
libevolution-mail-importers 0 libevolution (>= 3.42.3), libevolution (<< 3.43)
libevolution-mail 0 libevolution (>= 3.42.3), libevolution (<< 3.43)
libevolution-shell 0 libevolution (>= 3.42.3), libevolution (<< 3.43)
libevolution-smime 0 libevolution (>= 3.42.3), libevolution (<< 3.43)
libevolution-util 0 libevolution (>= 3.42.3), libevolution (<< 3.43)
libgnomecanvas 0 libevolution (>= 3.42.3), libevolution (<< 3.43)
libgconf-2 4 libgconf-2-4 (>= 2.31.1), gconf-service
libgnustep-base 1.28 libgnustep-base1.28 (>= 1.28.0), gnustep-base-runtime (>= 
1.28.0)
libortp 15 libortp15 (>= 1:4.4.0), libortp15 (<< 1:4.5.0)
libphonon4qt5 4 libphonon4qt5-4 (>= 4:4.11.1), phonon4qt5
libtotem 0 libtotem0 (>= 3.38.2-1), libtotem0 (<< 3.39)

$ grep -h ',.*<<' /var/lib/dpkg/info/*.symbols
| libc6 (>> 2.33), libc6 (<< 2.34)
| libc6 (>> 2.33), libc6 (<< 2.34)
| libc6 (>> 2.33), libc6 (<< 2.34)
| libc6 (>> 2.33), libc6 (<< 2.34)
| libc6 (>> 2.33), libc6 (<< 2.34)
| libc6 (>> 2.33), libc6 (<< 2.34)
| libc6 (>> 2.33), libc6 (<< 2.34)
| libc6 (>> 2.33), libc6 (<< 2.34)
| libc6 (>> 2.33), libc6 (<< 2.34)
| libc6 (>> 2.33), libc6 (<< 2.34)
| libc6 (>> 2.33), libc6 (<< 2.34)
| libc6 (>> 2.33), libc6 (<< 2.34)
| libc6 (>> 2.33), libc6 (<< 2.34)
| libc6 (>> 2.33), libc6 (<< 2.34)
| libc6 (>> 2.33), libc6 (<< 2.34)
| libc6 (>> 2.33), libc6 (<< 2.34)
| libc6 (>> 2.33), libc6 (<< 2.34)
| libc6 (>> 2.33), libc6 (<< 2.34)
| libc6 (>> 2.33), libc6 (<< 2.34)
| libc6 (>> 2.33), libc6 (<< 2.34)
| libc6-i386 (>> 2.33), libc6-i386 (<< 2.34)
| libc6-i386 (>> 2.33), libc6-i386 (<< 2.34)
| libc6-i386 (>> 2.33), libc6-i386 (<< 2.34)
| libc6-i386 (>> 2.33), libc6-i386 (<< 2.34)
| libc6-i386 (>> 2.33), libc6-i386 (<< 2.34)
| libc6-i386 (>> 2.33), libc6-i386 (<< 2.34)
| libc6-i386 (>> 2.33), libc6-i386 (<< 2.34)
| libc6-i386 (>> 2.33), libc6-i386 (<< 2.34)
| libc6-i386 (>> 2.33), libc6-i386 (<< 2.34)
| libc6-i386 (>> 2.33), libc6-i386 (<< 2.34)
| libc6-i386 (>> 2.33), libc6-i386 (<< 2.34)
| libc6-i386 (>> 2.33), libc6-i386 (<< 2.34)

Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not

[Theodore Y. Ts'o]

On Sat, Jan 22, 2022 at 08:58:37AM +0800, Paul Wise wrote:
> > The other thing that's perhaps considering here is that unfortunately,
> > there are some upstreams that are extremely irresponsible with library
> > ABI backwards compatibility, where they bump the SONAME essentially at
> > every release.  I recall one extreme case a few years ago where there
> > were over ten(!) SONAME bumps for a particular library over 12 months.
> 
> You could avoid NEW for these SONAME bumps by using a single binary
> package and ensuring that the symbols/shlibs depend on the right
> version ranges. Or add Provides libfoo-abi-N or libfoo-abi (= N)
> and have the symbols and or shlibs generate dependencies on that.

That only works if there are no other packages depending on those
shared libraries which are coming from other source packages.  After
all, if the only consumers of those shared libraries is source package
for those libraries, there's a much simpler solution --- just
compiling the d*mned package using static linking, and just moving on.

But if there are other packages which are using those shared
libraries, then the official party line is that just shipping static
libraries in libshaky-dev is bad, Bad, BAD, since it means that when
there are security bugs fixed in the sources for libshaky, they aren't
automatically fixed for all of the users of libshaky until they
relink.

But my claim is that if the upstream can't manage to maintain a stable
ABI, then maybe we shouldn't be trying to ship shared libraries.  But
officially, that's not allowed, since it's considered bad.
Unfortunately, that's effectively punishing maintainers who are
supporting sources which support shared library.  For those languages
like Rust, etc., which don't support shared libraries, life is *much*
simpler.

> In the past I've suggested a solution to static linking and binary
> packages containing source could be to have a service scanning every
> binary package for static/source files (.a, Rust, Golang etc), noting
> the relevant package/version tuples and then searching the buildinfo
> files for binary packages that built with those packages installed and
> automatically rebuilding affected packages, or having a service that
> would let you manually rebuild packages affected by security issues.
> 
> https://wiki.debian.org/StaticLinking

If we have that solution for Rust and Golang, the maybe it can also
make life easier for upstreams that can't maintain an ABI.  (And yes,
I don't have much patience with those folks given that e2fsprogs has
had a stable library since 1997, which is the last time I've had to
bump an SONAME for libext2fs.  But that's because I'm careful, where
as some other developers like for f2fs-tools, bump their SONAME every
!@#@?!  release.  Sigh...)

- Ted

Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not

[Stephan Lachnit]

On Fri, Jan 21, 2022 at 7:04 PM Paul Gevers  wrote:
>
> It's not only the copyright that the ftp-master are responsible for. New
> binaries fill a place in the Debian namespace and they *are* the keepers
> of that.

One could say that for new binaries packages whose src is already in
Debian, the ftp-masters skip the d/copyright review and only do the
other tasks. This should allow for way quicker transitions of simple
SOVERSION bumps.

In general I prefer a random d/copyright check more than one based on
the introduction of a new binary, as I just don't see any connection
between a new binary name and a change of copyright.

Regards,
Stephan

Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not

[Andreas Tille]

Hi,

Am Fri, Jan 21, 2022 at 07:04:33PM +0100 schrieb Paul Gevers:
> > I have heard this argument and my mail was simply to find out what
> > fellow developers think about this.  IMHO the issue is sufficiently
> > important to have some kind of documented consensus about this.
> 
> It's not only the copyright that the ftp-master are responsible for. New
> binaries fill a place in the Debian namespace and they *are* the keepers of
> that.

I absolutely agree that a four eyes principle.  On the other hand several
maintainers consider uploading to experimental (as in said case of onetbb)
and trust a team to verify the issues mentioned above.
 
> And https://lists.debian.org/debian-devel/2021/07/msg00231.html

Yes, this mail was for sure my motivation to write my mail.  IMHO it
says that there is no need for manual inspection ... and I would love
if this would be clarified and documented.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not

[Simon McVittie]

On Sat, 22 Jan 2022 at 08:58:37 +0800, Paul Wise wrote:
> On Fri, 2022-01-21 at 13:55 -0500, Theodore Ts'o wrote:
> > The other thing that's perhaps considering here is that unfortunately,
> > there are some upstreams that are extremely irresponsible with library
> > ABI backwards compatibility, where they bump the SONAME essentially at
> > every release.

I don't think characterizing that as irresponsible is entirely fair,
and it risks setting up incentives that harm us: if the upstream for
a package I maintain is breaking backwards-compat, I'd prefer them to
acknowledge it and bump the SONAME, rather than saying "well, it isn't
*that* big a break" and ignoring it.

> You could avoid NEW for these SONAME bumps by using a single binary
> package and ensuring that the symbols/shlibs depend on the right
> version ranges. Or add Provides libfoo-abi-N or libfoo-abi (= N)
> and have the symbols and or shlibs generate dependencies on that.

I used that method for early GTK 4 prereleases in experimental, when
upstream were breaking ABI in each 3.9x prerelease. They specifically
weren't guaranteeing API or ABI stability yet at that stage in
development, but I wanted to start packaging early, before it was too
late to incorporate feedback that could result in further incompatible
changes. (At the time the source package was called src:gtk+4.0, but
it's in the git history of src:gtk4 now.)

I think this is fine for prereleases and experimental, but for packages
with more than a trivial number of reverse-dependencies it is likely
to cause issues for testing/unstable transitions, because it defeats
the release team's "smooth upgrades" mechanism (in which they keep the
old libfoo1 binaries and the old src:foo in testing until there are no
more rdeps, even after they have been superseded by a new src:foo with
libfoo2, so that migration doesn't have to all happen in one go). I
would say that maintainers who are considering doing this in unstable
should talk to the release team first.

smcv

Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not

[Paul Wise]

On Fri, 2022-01-21 at 13:55 -0500, Theodore Ts'o wrote:

> Can we have better automated tooling, either in Lintian, or in when
> source packages are rebuilt, that can take care of this?
> 
> The other thing that's perhaps considering here is that unfortunately,
> there are some upstreams that are extremely irresponsible with library
> ABI backwards compatibility, where they bump the SONAME essentially at
> every release.  I recall one extreme case a few years ago where there
> were over ten(!) SONAME bumps for a particular library over 12 months.

You could avoid NEW for these SONAME bumps by using a single binary
package and ensuring that the symbols/shlibs depend on the right
version ranges. Or add Provides libfoo-abi-N or libfoo-abi (= N)
and have the symbols and or shlibs generate dependencies on that.

> But if we're going to do that, then we could also just support static
> libraries, and just rebuilt all of the pacakges that link statically
> with libshaky, thus solving the security argument for shared
> libraries.  This also avoids the fairness problem where some packages
> are reguarly going through ftpmaster review, and others aren't...

In the past I've suggested a solution to static linking and binary
packages containing source could be to have a service scanning every
binary package for static/source files (.a, Rust, Golang etc), noting
the relevant package/version tuples and then searching the buildinfo
files for binary packages that built with those packages installed and
automatically rebuilding affected packages, or having a service that
would let you manually rebuild packages affected by security issues.

https://wiki.debian.org/StaticLinking

In addition there are toolchain changes coming in at least Golang and
possibly GCC (pushed by Fedora IIRC) for adding source file/package
information into generated binaries.

The scanning/buildinfo/rebuilding idea would produce more builds than
strictly necessary, but perhaps the coming toolchain changes could be
helpful in filtering down the lists.

Ultimately the best option would be for all build toolchains to have
instrumentation that enables us to completely graph the flow of source
data to -dev binary packages etc to final binary packages. Perhaps each
build system, compiler etc would communicate with a daemon that would
collect the file/etc paths/hashes/etc, map those back to package,
version tuples and upload those to dak in buildgraph files.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not

[Theodore Ts'o]

On Fri, Jan 21, 2022 at 01:28:54PM -0500, Scott Kitterman wrote:
> 
> 1.  When the SO name changes and the binary package name is adjusted 
> accordingly, it is not super rare for the maintainer to mess something up in 
> the renaming and end up with an empty binary package, which does no one any 
> good.  I note that for debhelper compat 15 there appears to be some related 
> work in progress.  Perhaps this is, or can be extended to be, sufficient to 
> eventually make this kind of error a thing of the past.

Can we have better automated tooling, either in Lintian, or in when
source packages are rebuilt, that can take care of this?

The other thing that's perhaps considering here is that unfortunately,
there are some upstreams that are extremely irresponsible with library
ABI backwards compatibility, where they bump the SONAME essentially at
every release.  I recall one extreme case a few years ago where there
were over ten(!) SONAME bumps for a particular library over 12 months.

The problem with this is that it makes for a massive headache when it
comes to security updates.  The claim for why we want to use shared
libraries, despite the library dependency hell problem, is that when a
security problem gets fixed, all we need to do is to upload a new
shared library package, and all of the packages which depend on it
automatically get updated.  Well, if during the course of a testing
release, we have binary packages depending on libshaky3, libshaky5,
libshaky6, libshaky7 and libshaky8, now if there's a long-standing
security bug that gets fixed, it's not necessarily the case that when
the Debian maintainer which uploads an updated libshaky source
package, which might result in binary packages libshaky-dev,
libshaky-bin, and libshaky8, that there will be updates for
libshaky{3,5,6,7}.

Now that we are requiring source uploads for everything entering
testing, there's easy answer to this --- which is to simply have an
automated system which rebuilds all of the packages that have a
build-depends on libshaky-dev, so all the packages will now have a
dependency on libshaky8.  Huzzah!

But if we're going to do that, then we could also just support static
libraries, and just rebuilt all of the pacakges that link statically
with libshaky, thus solving the security argument for shared
libraries.  This also avoids the fairness problem where some packages
are reguarly going through ftpmaster review, and others aren't...

Just a thought

- Ted

Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not

[Scott Kitterman]

On Friday, January 21, 2022 1:33:07 PM EST Adam Borowski wrote:
> On Fri, Jan 21, 2022 at 01:28:54PM -0500, Scott Kitterman wrote:
> > 2.  New binary package "steals" binary from another source.  This is
> > sometimes OK.  Sometimes it's accidental.  It could also be malicious (I
> > don't remember if I've every actually seen this done for an intentional
> > "steal" or not, I might have).
> 
> Stealing a binary does not go through NEW.

It does.  Binary is new to that source so there is no existing override.

Scott K

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

Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not

[Adam Borowski]

On Fri, Jan 21, 2022 at 01:28:54PM -0500, Scott Kitterman wrote:
> 2.  New binary package "steals" binary from another source.  This is 
> sometimes 
> OK.  Sometimes it's accidental.  It could also be malicious (I don't remember 
> if I've every actually seen this done for an intentional "steal" or not, I 
> might have).

Stealing a binary does not go through NEW.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Aryans: split from other Indo-Europeans ~2900-2000BC → Ural →
⣾⠁⢠⠒⠀⣿⡁ Bactria → settled 2000-1000BC in northwest India.
⢿⡄⠘⠷⠚⠋⠀ Gypsies: came ~1000AD from northern India; aryan.
⠈⠳⣄ Germans: IE people who came ~2800BC to Scandinavia; not aryan.

Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not

[Scott Kitterman]

On Friday, January 21, 2022 12:19:12 PM EST Andreas Tille wrote:
> Hi Mo,
> 
> Am Fri, Jan 21, 2022 at 09:51:12AM -0500 schrieb M. Zhou:
> > I'd rather propose choice C. Because I to some extent understand
> > both sides who support either A or B. I maintain bulky C++ packages,
> > and I also had a little experience reviewing packages on behalf of
> > ftp-team.
> > 
> > A -- Some (e.g. C++) packages may frequently enter the NEW queue,
> > with OLD src and NEW bins (e.g. SOVERSION bump). A portion of devs
> > feel it is not necessary for frequently because it drastically
> > slows down the maintainer's work. In the worst case, when the
> > package finally passed the NEW queue, the maintainer may have
> > to go through NEW queue again upon the next upload. (This is very
> > likely to happen for tensorflow, etc).
> 
> I have heard this argument and my mail was simply to find out what
> fellow developers think about this.  IMHO the issue is sufficiently
> important to have some kind of documented consensus about this.

Speaking only for myself, not the FTP Team.

There are other considerations.  Here's a few I thought of without investing a 
lot of time in it (not necessarily comprehensive):

1.  When the SO name changes and the binary package name is adjusted 
accordingly, it is not super rare for the maintainer to mess something up in 
the renaming and end up with an empty binary package, which does no one any 
good.  I note that for debhelper compat 15 there appears to be some related 
work in progress.  Perhaps this is, or can be extended to be, sufficient to 
eventually make this kind of error a thing of the past.

2.  New binary package "steals" binary from another source.  This is sometimes 
OK.  Sometimes it's accidental.  It could also be malicious (I don't remember 
if I've every actually seen this done for an intentional "steal" or not, I 
might have).

3.  New package added for reasons that make sense to the maintainer, but not 
for the archive as a whole.  I've seen this come up multiple times, usually in 
the context of the binary being too trivial (which is a judgment call).

It's not just let's do extra copyright/license checks.

Scott K

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

Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not

[Paul Gevers]

Hi,

I'm not involved in ftp-master, but...

On 21-01-2022 18:19, Andreas Tille wrote:

Am Fri, Jan 21, 2022 at 09:51:12AM -0500 schrieb M. Zhou:

I'd rather propose choice C. Because I to some extent understand
both sides who support either A or B. I maintain bulky C++ packages,
and I also had a little experience reviewing packages on behalf of
ftp-team.

A -- Some (e.g. C++) packages may frequently enter the NEW queue,
with OLD src and NEW bins (e.g. SOVERSION bump). A portion of devs
feel it is not necessary for frequently because it drastically
slows down the maintainer's work. In the worst case, when the
package finally passed the NEW queue, the maintainer may have
to go through NEW queue again upon the next upload. (This is very
likely to happen for tensorflow, etc).


I have heard this argument and my mail was simply to find out what
fellow developers think about this.  IMHO the issue is sufficiently
important to have some kind of documented consensus about this.


It's not only the copyright that the ftp-master are responsible for. New 
binaries fill a place in the Debian namespace and they *are* the keepers 
of that.


And https://lists.debian.org/debian-devel/2021/07/msg00231.html

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not

[Andreas Tille]

Hi Mo,

Am Fri, Jan 21, 2022 at 09:51:12AM -0500 schrieb M. Zhou:
> I'd rather propose choice C. Because I to some extent understand
> both sides who support either A or B. I maintain bulky C++ packages,
> and I also had a little experience reviewing packages on behalf of
> ftp-team.
> 
> A -- Some (e.g. C++) packages may frequently enter the NEW queue,
> with OLD src and NEW bins (e.g. SOVERSION bump). A portion of devs
> feel it is not necessary for frequently because it drastically
> slows down the maintainer's work. In the worst case, when the
> package finally passed the NEW queue, the maintainer may have
> to go through NEW queue again upon the next upload. (This is very
> likely to happen for tensorflow, etc).

I have heard this argument and my mail was simply to find out what
fellow developers think about this.  IMHO the issue is sufficiently
important to have some kind of documented consensus about this.
 
> B -- Uploads with OLD src and OLD bin are not required to go through
> NEW queue, even if a decade as passed as long as the src names and
> bin names are kept unchanged. One of the supports for B is that
> the d/copyright file may silently rot (get outdated), as uploads 
> without updated d/copyright won't be rejected. Checking packages
> when they bump SOVERSION is to some extent a "periodical" check.
> This worked very well for packages with stable ABI. But for pacakges
> without stable ABI, especially bulky (C++) packages, this is
> painful for both uploaders and ftp checkers.

I also heard that argument that passing the new queue is a good chance
to review d/copyright.  But as you said it will never catch code that
never needs passing new queue again.  So also here I would seek for
opinions since this argument is in conflict with my interpretation
of the said mail I was refering to[1].

> Given the understanding of both options, I propose choice C:
> 
> C. Lottery NEW queue:
> 
> if (src is new):
> # completely new package
> require manual-review
> elif (src is old) but (bin is new):
> if not-checked-since-last-stable-release:
> # approximate advantage of choice B.
> require manual-review
> elif src.version already exists in archive
> # choice A wants to avoid this case.
> auto-accept
> else:
> if (lottery := random()) < threshold
> require manual-review
> else:
> # I expect a faster pace of debian development.
> auto-accept
> 
> In this way concerns for both people supporting A and B can be partly
> addressed. The old-src-new-bin case have a large chance to pass NEW
> as long as they have been reviewed once after the last stable release.
> The burden for ftp-team can be reduced. And pace of maitnainers can
> be faster with less chance of being blocked and unstable to do anything
> but wait.

I agree that this solution possibly covers both sides.  However my
question was a bit simpler since I wanted to find out whether we really
have supporters of both sides and how strong their arguments might be
for the respective side.  Than we can document the issue and possibly
your suggestion might be an acceptable solution (if and only if we
realise that there are those conflicting opinions).

> > I would love to have this clearly documented since in case B. I would
> > stop wasting my and ftpmaster time with nagging which is not
> > rectified
> > than.
> > 
> > I personally clearly prefer A. and I wish we could clarify this
> > situation.
> 
> Me too. I perfer A personally as well. Debian might be the only major
> distribution which checks the license so thoroughly. Unconditionally
> allow an old-src-new-bin upload to pass is basically impossible, I
> speculate. Choice C might be more practical and feasible.

"Speculate" is the term we need to get rid of first. ;-)
This was my motivation to write the initial mail.
 
> It must be many outdated d/copyright in our archive. Letting eligible
> uploads automatically pass with a high probability is not likely
> causing problem even if yet another outdated d/copyright sneaked in.

I perfectly agree that we have a high probablility for outdated
d/copyright files in our archive.  However, I would like to consider
this problem as orthogonal to the binary name change issue.  It puts
an absolutely not rectified bias on those packages that are typically
changing binary packages frequently - at least I do not see any good
reason to prefer a package that by chance has a new binary name over
any other package inside the archive.

That's why I would rather consider to do a call for volunteers to
verify d/copyright files of *completely* random packages.  I do not
see any point in putting this workload onto ftpmaster but may be as
a first interesting step to join the ftpmaster team.

Kind regards

 Andreas.
 
> > [1] https://lists.debian.org/debian-devel/2021/07/msg00231.html
> > [2] https://ftp-master.debian.org/new/onetbb_2021.4.0-1~exp1.html

-- 

Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not

[M. Zhou]

Hi Andreas,

Thank you for mentioning this. Your post inspired me to came up a
new choice.

On Fri, 2022-01-21 at 11:33 +0100, Andreas Tille wrote:
> 
> This recently happed for me in the case of onetbb (which was not
> uploaded by myself - so I'm not even asking for myself while other
> packages of mine (new ones and ones with just renames) are waiting in
> the queue.)  There are lots of other packages (namely numba and lots
> of
> other packages depending from numba that FTBFS) depending from onetbb
> -
> thus I pinged on #debian-ftp more than once (which I really hate).

When I was once an ftp-trainee (now I'm not in ftp-team), there was no
popcon query when doing dak review. Whether a package is of high
priority depends on one's experience to some extent. Even if I knew
some packages must have a high popcon, their bulky size make the
review process (checking files one by one) not quite easy.

> Due to this I'd like to have a clear statement here (which would
> prove myself in pinging either right or wrong and thus I'm asking):
> 
>   A. Packages with new binary package names should not undergo
>  the copyright inspection by ftpmaster and can be
>  auto-approved (either technically or manually)
> 
>   B. Any package in the new queue needs to be inspected by
>  ftpmaster for copyright issues and it takes as long as
>  it takes no matter whether it is a new package or a
>  package with changed binary name.
> 

I'd rather propose choice C. Because I to some extent understand
both sides who support either A or B. I maintain bulky C++ packages,
and I also had a little experience reviewing packages on behalf of
ftp-team.

A -- Some (e.g. C++) packages may frequently enter the NEW queue,
with OLD src and NEW bins (e.g. SOVERSION bump). A portion of devs
feel it is not necessary for frequently because it drastically
slows down the maintainer's work. In the worst case, when the
package finally passed the NEW queue, the maintainer may have
to go through NEW queue again upon the next upload. (This is very
likely to happen for tensorflow, etc).

B -- Uploads with OLD src and OLD bin are not required to go through
NEW queue, even if a decade as passed as long as the src names and
bin names are kept unchanged. One of the supports for B is that
the d/copyright file may silently rot (get outdated), as uploads 
without updated d/copyright won't be rejected. Checking packages
when they bump SOVERSION is to some extent a "periodical" check.
This worked very well for packages with stable ABI. But for pacakges
without stable ABI, especially bulky (C++) packages, this is
painful for both uploaders and ftp checkers.

Given the understanding of both options, I propose choice C:

C. Lottery NEW queue:

if (src is new):
# completely new package
require manual-review
elif (src is old) but (bin is new):
if not-checked-since-last-stable-release:
# approximate advantage of choice B.
require manual-review
elif src.version already exists in archive
# choice A wants to avoid this case.
auto-accept
else:
if (lottery := random()) < threshold
require manual-review
else:
# I expect a faster pace of debian development.
auto-accept

In this way concerns for both people supporting A and B can be partly
addressed. The old-src-new-bin case have a large chance to pass NEW
as long as they have been reviewed once after the last stable release.
The burden for ftp-team can be reduced. And pace of maitnainers can
be faster with less chance of being blocked and unstable to do anything
but wait.

> I would love to have this clearly documented since in case B. I would
> stop wasting my and ftpmaster time with nagging which is not
> rectified
> than.
> 
> I personally clearly prefer A. and I wish we could clarify this
> situation.

Me too. I perfer A personally as well. Debian might be the only major
distribution which checks the license so thoroughly. Unconditionally
allow an old-src-new-bin upload to pass is basically impossible, I
speculate. Choice C might be more practical and feasible.

It must be many outdated d/copyright in our archive. Letting eligible
uploads automatically pass with a high probability is not likely
causing problem even if yet another outdated d/copyright sneaked in.

> Kind regards
> 
>  Andreas.
> 
> [1] https://lists.debian.org/debian-devel/2021/07/msg00231.html
> [2] https://ftp-master.debian.org/new/onetbb_2021.4.0-1~exp1.html
> 

Are libraries with bumped SONAME subject of inspection of ftpmaster or not

[Andreas Tille]

Hi,

if a source package in Debian creates a new binary package name it has
to pass the new queue.  If I understand this posting from last year[1]
correctly (people in CC who were in CC of that posting) this is just
because nobody has written some kind of "auto-approver" for dak.

Usually the "social" workaround for this missing piece of code is to
ping ftpmaster either via IRC or mail and explain that this code can be
easily accepted since it was once checked for copyright.  This typically
happens for library packages with bumped sonames very reliably (thanks
to ftpmasters who are helping here quickly).

However it happens from time to time when I do so that I'm told: Well
that's new upstream code and new copyright inspection is needed and thus
we need time ($volunteers, $others_are_waiting etc. - I think I'm long
enough inside the project that I do not need the latter instructions).
This recently happed for me in the case of onetbb (which was not
uploaded by myself - so I'm not even asking for myself while other
packages of mine (new ones and ones with just renames) are waiting in
the queue.)  There are lots of other packages (namely numba and lots of
other packages depending from numba that FTBFS) depending from onetbb -
thus I pinged on #debian-ftp more than once (which I really hate).

Due to this I'd like to have a clear statement here (which would
prove myself in pinging either right or wrong and thus I'm asking):

  A. Packages with new binary package names should not undergo
 the copyright inspection by ftpmaster and can be
 auto-approved (either technically or manually)

  B. Any package in the new queue needs to be inspected by
 ftpmaster for copyright issues and it takes as long as
 it takes no matter whether it is a new package or a
 package with changed binary name.

I would love to have this clearly documented since in case B. I would
stop wasting my and ftpmaster time with nagging which is not rectified
than.

I personally clearly prefer A. and I wish we could clarify this
situation.

Kind regards

 Andreas.

[1] https://lists.debian.org/debian-devel/2021/07/msg00231.html
[2] https://ftp-master.debian.org/new/onetbb_2021.4.0-1~exp1.html

-- 
http://fam-tille.de

subject

[zainalabd...@softkhana.com]

This is the body

Bug#998710: Subject: ITP: golang-gopkg-macaroon.v2 -- Native Go implementation of macaroons

[Mathias Gibbens]

Package: wnpp
Severity: wishlist
Owner: Mathias Gibbens 
X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org

* Package name: golang-gopkg-macaroon.v2
  Version : 2.1.0-1
  Upstream Author : Roger Peppe
* URL : https://github.com/go-macaroon/macaroon
* License : BSD-3-clause
  Programming Lang: Go
  Description : Native Go implementation of macaroons

 The macaroon package implements macaroons as described in
 the paper "Macaroons: Cookies with Contextual Caveats for
 Decentralized Authorization in the Cloud"

This ITP reintroduces the golang-gopkg-macaroon.v2 package to the
archive. It was previously RM'ed in #917811 as no packages depended on
it.

This package is a dependency for packaging golang-gopkg-macaroon-
bakery.v2, which is in turn a dependency for LXD (ITP #768073).

This package will be team-maintained within the Debian Go Packaging
Team.


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

Bug#998709: Subject: ITP: golang-gopkg-macaroon-bakery.v2 -- High level operations for building systems with macaroons

[Mathias Gibbens]

Package: wnpp
Severity: wishlist
Owner: Mathias Gibbens 
X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org

* Package name: golang-gopkg-macaroon-bakery.v2
  Version : 2.3.0-1
  Upstream Author : Roger Peppe, Canonical Inc
* URL : https://github.com/go-macaroon-bakery/macaroon-bakery
* License : LGPL-3.0-with-exception
  Programming Lang: Go
  Description : High level operations for building systems with macaroons

 This library is a companion to gopkg.in/macaroon.v2. It provides
 higher level operations for building systems with macaroons.

This ITP reintroduces the golang-gopkg-macaroon-bakery.v2 package to
the archive. It was previously RM'ed in #911001 as no packages depended
on it.

This package is a dependency for packaging LXD (ITP #768073).

This package will be team-maintained within the Debian Go Packaging
Team.


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

[no subject]

[asiaa gonzalez]

Hi?

Bug#976852: Subject: ITP: node-iterall -- utilities for using JavaScript Iterables

[Abraham Raji]

Package: wnpp
Severity: wishlist
Owner: Abraham Raji 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name    : node-iterall
  Version : 1.2.2
  Upstream Author : Lee Byron  (http://leebyron.com/)
* URL : https://github.com/leebyron/iterall
* License : Expat
  Programming Lang: JavaScript
  Description : utilities for using JavaScript Iterables
iterall provides a few crucial utilities for implementing and working with
Iterables, Async Iterables and Array-likes in all JavaScript environments,
even old versions of Internet Explorer, in a tiny library weighing well
under 1KB when minified and gzipped.
.
Node.js is an event-based server-side JavaScript engine.

This module is a dependency for a version of graphql that is used by 
gitlab. I will package and maintain this module with the help Debian
JS Team.

Abraham Raji
-- 
Mea navis aëricumbens anguillis abundat.

[no subject]

[Tor G Salte]

Sendt fra E-post for Windows 10

Bug#950588: (no subject)

[Fabrice BAUZAC]

Package: wnpp
Severity: wishlist
Owner: Fabrice BAUZAC 

* Package name: golang-github-jfrog-gofrog
  Version : 1.0.5-1
  Upstream Author : JFrog Ltd.
* URL : https://github.com/jfrog/gofrog
* License : Apache-2.0
  Programming Lang: Go
  Description : A collection of go utilities

Description: The gofrog collection of go utilities (library)
 This collection from JFrog contains modules for:
 * Running tasks in parallel
 * Caches following the Least-recently-used policy
 * Running commands and reading their output
 * Creating random files
 * A reader that publishes to multiple consumers
 * Basic AES encryption/decryption

Note: my ultimate goal is to package the JFrog-CLI commandline tool
(Apache-2.0 license).  golang-github-jfrog-gofrog is one of its
dependencies, and I have run dh-make-golang to help me make it.

Re: Bug#949198: (no subject)

[Andrei POPESCU]

Control: retitle -1 ITP: parsero -- Audit tool for robots.txt of a site

On Vi, 17 ian 20, 21:37:48, Thiago Andrade Marques wrote:
> Subject: ITP: parsero -- Audit tool for robots.txt of a site
> Package: wnpp
> Owner: Thiago Andrade Marques 
> Severity: wishlist
> 
> * Package name: parsero
>   Version : 0.0+git20140929.e5b585a
>   Upstream Author : Javier Nieto 
> * URL : https://github.com/behindthefirewalls/Parsero/
> * License : (GPL-2+
>   Programming Lang: Python3
>   Description : Audit tool for robots.txt of a site
> 
> Parsero reads the Robots.txt file of a web server and looks at the Disallow 
> entries.
> The Disallow entries tell the search engines what directories or files hosted 
> on a
> web server must not be indexed. For example, "Disallow: /portal/login" means 
> that the
> content on www.example.com/portal/login it's not allowed to be indexed by 
> crawlers
> like Google, Bing, Yahoo... This is the way the administrator have to not 
> share
> sensitive or private information with the search engines.
> 

-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Bug#949198: (no subject)

[Thiago Andrade Marques]

Subject: ITP: parsero -- Audit tool for robots.txt of a site
Package: wnpp
Owner: Thiago Andrade Marques 
Severity: wishlist

* Package name: parsero
  Version : 0.0+git20140929.e5b585a
  Upstream Author : Javier Nieto 
* URL : https://github.com/behindthefirewalls/Parsero/
* License : (GPL-2+
  Programming Lang: Python3
  Description : Audit tool for robots.txt of a site

Parsero reads the Robots.txt file of a web server and looks at the Disallow 
entries.
The Disallow entries tell the search engines what directories or files hosted 
on a
web server must not be indexed. For example, "Disallow: /portal/login" means 
that the
content on www.example.com/portal/login it's not allowed to be indexed by 
crawlers
like Google, Bing, Yahoo... This is the way the administrator have to not share
sensitive or private information with the search engines.

Bug#941221: (no subject)

[Miriam Ruiz]

Package: wnpp
Severity: wishlist
Owner: Miriam Ruiz 

* Package name: knitpy
  Version : 0.1.1~git20180430
  Upstream Author : Jan Schulz 
* URL : https://github.com/janschulz/knitpy
* License : BSD-3-clause
  Programming Lang: Python
  Description : report generation tool with Python

 Knitpy is an elegant, flexible and fast dynamic report generation with
 Python. It is a port of knitr and rmarkdown to Python and uses the IPython
 kernel infrastructure to execute the code.
 .
 Features:
  - Code blocks and inline code.
  - Plots are shown inline.
  - Output formats html, pdf and docx.
  - Code chunk arguments eval, results (apart form "hold"), include and echo
  - Errors in code chunks are shown in the document.
  - Uses the IPython display framework, so rich output for objects implementing
_repr_html_() or _repr_markdown_(). Mimetypes not understood by the final
output format are automatically converted via pandoc.
  - Can be imported and used from Python.
  - Supports a --debug mode.

Depends:
 python3-jupyter-client,
 python3-jupyter-core,
 python3-ipykernel,
 python3-traitlets,
 python3-pypandoc,
 python3-yaml

Recommends:
 texlive-latex-base,
 texlive-fonts-recommended

Bug#940329: (no subject)

[Andreas Noteng]

Package: wnpp
Severity: wishlist
Owner: Andreas Noteng 

* Package name: scantailor-advanced
  Version : 1.0.17~2019.08.16-1
  Upstream Author : 4lex4 <4le...@zoho.com> 
* URL : https://github.com/4lex4/scantailor-advanced/
* License : GPL3+
  Programming Lang: C++
  Description : Interactive post-processing tool for scanned pages

Scan Tailor is an interactive post-processing tool for scanned pages. It
performs operations such as page splitting, deskewing, adding/removing
borders, and others. You give it raw scans, and you get pages ready to be
printed or assembled into a PDF or DJVU file. Scanning, optical character
recognition, and assembling multi-page documents are out of scope of this
project.

The current scantailor package in Debain is removed from stable and
testing due to it blocking QT4-removal (#875176). The project is not
dead upstream, but development is going slow. Scantailor Advanced is a
fork that uses QT5, and also includes some extended features.

Bug#927419: Subject: ITP: libtest-mockdatetime-perl -- mock DateTime->now calls during tests

[Alex Mestiashvili]

Package: wnpp
Owner: Alexandre Mestiashvili 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libtest-mockdatetime-perl
  Version : 0.02-1
  Upstream Author : Wolfgang Kinkeldei 
* URL : https://metacpan.org/release/Test-MockDateTime
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : mock DateTime->now calls during tests

 Getting the current time sometimes is not very helpful for testing
 scenarios. Instead, if you could obtain a known value during the
 runtime of a testcase will make your results predictable.
 .
 This module allows faking a given date and time for the runtime of a
 subsequent code block. By default the on keyword is exported into the
 namespace of the test file. The date to get mocked must be in a format
 that is recognized by DateTime::Format::DateParse.

This package is a dependency for Dancer2::Plugin::Auth::Extensible and
will be maintained under the Debian Perl Group umbrella.

Bug#914293: Subject: ITP: node-append-transform -- Install a transform to require.extensions that always runs last

[Nicolas Mora]

Package: wnpp
Severity: wishlist
Owner: Nicolas Mora 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-append-transform
  Version : 1.0.0
  Upstream Author : James Talmage  
(github.com/jamestalmage)

* URL : https://github.com/istanbuljs/append-transform
* License : Expat
  Programming Lang: JavaScript
  Description : Install a transform to require.extensions that 
always runs last


 Install a transform to require.extensions that always runs last, even 
if

 additional extensions are added later
 .
 Node.js is an event-based server-side JavaScript engine.

This package is a dependency for the package node-istanbuljs

Bug#900123: (no subject)

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-vcr
  Version : 0.1.0
  Upstream Author : Scott Chamberlain ()
* URL : https://cran.r-project.org/package=vcr
* License : MIT
  Programming Lang: GNU R
  Description : GNU R record HTTP calls to disk
 Record test suite 'HTTP' requests and replays them during future runs. A
 port of the Ruby gem of the same name. Works by hooking into the
 'webmockr' R package for matching 'HTTP' requests by various rules
 ('HTTP' method, 'URL', query parameters, headers, body, etc.), and then
 caching real 'HTTP' responses on disk in 'cassettes'. Subsequent 'HTTP'
 requests matching any previous requests in the same 'cassette' use a
 cached 'HTTP' response.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-vcr
This package is needed in the autopkgtest of some r-cran-packages and
would help closing 3 bugs.

Bug#898687: (no subject)

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-colourpicker
  Version : 1.0
  Upstream Author : Dean Attali,
* URL : https://cran.r-project.org/package=colourpicker
* License : MIT
  Programming Lang: GNU R
  Description : GNU R colour picker tool for selecting colours in plots
 This GNU R colour picker can be used as an input in Shiny apps
 or Rmarkdown documents. The colour picker supports alpha opacity, custom
 colour palettes, and many more options. A Plot Colour Helper tool is
 available as an RStudio Addin, which helps you pick colours to use in your
 plots. A more generic Colour Picker RStudio Addin is also provided to let
 you select colours to use in your R code.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-colourpicker
This package belongs to a set of dependencies for r-cran-brms which is
needed to upgrade r-cran-emmeans to the latest upstream version.

Bug#898423: (no subject)

[Laurent Baillet]

Package: wnpp
Severity: wishlist
Owner: Laurent Baillet 

* Package name: libai-decisiontree-perl
  Version : 0.11
  Upstream Author : Ken Williams 
* URL : https://github.com/kenahoo/perl-ai-decisiontree
* License : GPL-1+ or Artistic
  Programming Lang: Perl
  Description : Automatic Learner of Decision Trees

The AI::DecisionTree module automatically creates so-called "decision trees"
to explain a set of training data. A decision tree is a kind of categorizer
that use a flowchart-like process for categorizing new instances. This
implementation uses the gain obtained at each node in order to figure out
what are the most useful informations in order to take decisions.

This module is not developed anymore but it nicely does what it was
written for.

It is a suggestion for AI::Categorizer that I plan to package within Debian
Perl Team.

[no subject]

[Jaay Hernandez]

Format: 1.8 Date: Fri, 01 Dec 2017 23:32:58 +0100 Source: tor Binary: tor
tor-geoipdb Architecture: source Version: 0.3.1.9-1 Distribution: unstable
Urgency: high Maintainer: Peter Palfrader  Changed-By:
Peter Palfrader  Description: tor - anonymizing overlay
network for TCP tor-geoipdb - GeoIP database for Tor Closes: 700179 882281
Changes: tor (0.3.1.9-1) unstable; urgency=high . * New upstream version,
including among others: - Fix a denial of service bug where an attacker
could use a malformed directory object to cause a Tor instance to pause
while OpenSSL would try to read a passphrase from the terminal. (Tor
instances run without a terminal, which is the case for most Tor packages,
are not impacted.) Fixes bug 24246; bugfix on every version of Tor. Also
tracked as TROVE-2017-011 and CVE-2017-8821. Found by OSS-Fuzz as testcase
6360145429790720. - Fix a denial of service issue where an attacker could
crash a directory authority using a malformed router descriptor. Fixes bug
24245; bugfix on 0.2.9.4-alpha. Also tracked as TROVE-2017-010 and
CVE-2017-8820. - When checking for replays in the INTRODUCE1 cell data for
a (legacy) onion service, correctly detect replays in the RSA- encrypted
part of the cell. We were previously checking for replays on the entire
cell, but those can be circumvented due to the malleability of Tor's legacy
hybrid encryption. This fix helps prevent a traffic confirmation attack.
Fixes bug 24244; bugfix on 0.2.4.1-alpha. This issue is also tracked as
TROVE-2017-009 and CVE-2017-8819. - Fix a use-after-free error that could
crash v2 Tor onion services when they failed to open circuits while
expiring introduction points. Fixes bug 24313; bugfix on 0.2.7.2-alpha.
This issue is also tracked as TROVE-2017-013 and CVE-2017-8823. - When
running as a relay, make sure that we never build a path through ourselves,
even in the case where we have somehow lost the version of our descriptor
appearing in the consensus. Fixes part of bug 21534; bugfix on
0.2.0.1-alpha. This issue is also tracked as TROVE-2017-012 and
CVE-2017-8822. - When running as a relay, make sure that we never choose
ourselves as a guard. Fixes part of bug 21534; bugfix on 0.3.0.1-alpha.
This issue is also tracked as TROVE-2017-012 and CVE-2017-8822. *
Build-depend on libcap-dev on linux-any so we can build tor with
capabilities support to retain the capability to bind to low ports; closes:
#882281, #700179. Checksums-Sha1: 8c132af553721ba81f0d2a297f5141f5b455435d
1824 tor_0.3.1.9-1.dsc 5d6d5f00691d35c782f9126b7ad70a678343a832 6092702
tor_0.3.1.9.orig.tar.gz 7b33ff16dfe470cc5bd3af53960a7ebc7204f415 48881
tor_0.3.1.9-1.diff.gz Checksums-Sha256:
d767ca3b900a839b03083a0492c0e2d08ddf0bb15bf9323fd1280d1f115714d2 1824
tor_0.3.1.9-1.dsc
6e1b04f7890e782fd56014a0de5075e4ab29b52a35d8bca1f6b80c93f58f3d26 6092702
tor_0.3.1.9.orig.tar.gz
dde9f4b63e0ec28d4d649988a494b0bb0e10897df2cb22268c9b2042f080d59f 48881
tor_0.3.1.9-1.diff.gz Files: 893c1b5715d321f859707836b2d00e61 1824 net
optional tor_0.3.1.9-1.dsc 585e62d086ae7df7cd873f735d726118 6092702 net
optional tor_0.3.1.9.orig.tar.gz 02e347d9a5e3bf1b8871dfd75eaa3d19 48881 net
optional tor_0.3.1.9-1.diff.gz

Re: [yay for broken usage of was: in the Subject header]

[Guillem Jover]

On Thu, 2018-01-11 at 01:06:06 +0100, Johannes Schauer wrote:
> Quoting Philipp Kern (2018-01-11 00:20:17)
> > Why is it making comparing packages with each other difficult?
> 
> What I meant here was what I mentioned elsewhere in this thread. We can check
> whether two binary packages built with a different set of build profiles 
> active
> are actually the same by using the tools from the reproducible builds project.
> And the easiest way to do the comparison is to compare their hashes. If the
> build profile would be included, then comparing the packages would be made 
> more
> difficult.

Or IOW:

  cmp a.deb b.deb

vs

  dpkg-deb -R a.deb a
  dpkg-deb -R b.deb b
  sed -i -e '/^Built-For-Profiles/d' a/DEBIAN/control
  sed -i -e '/^Built-For-Profiles/d' b/DEBIAN/control
  diff -Naur a b

While then not comparing the actual .deb, for any other suspicious
members, difference in format, strange padding, etc, or control.tar
metadata changes.

> > At the same time for a stable port the archive can ensure that the build
> > profile was actually the default one (or accept divergences with a conscious
> > decision, like using NEW or BYHAND).
> 
> The archive can already do this check by investigating the buildinfo file that
> was uploaded together with the binary packages.

Actually this information is also readily available in the .changes
file which DAK is already parsing.

Thanks,
Guillem

Re: [yay for broken usage of was: in the Subject header]

[Johannes Schauer]

Quoting Philipp Kern (2018-01-11 00:20:17)
> On 2018-01-10 22:53, Johannes Schauer wrote:
> > But unless we want to pull a full Gentoo here and really make the
> > information with which build profile a given binary package was built part
> > of the binary package and thus overhaul all our dependency resolvers,
> > unless the plan is to do that, I don't see why binary packages should
> > contain this information.
> > 
> > Either it is used for dependency resolution and then we should have the
> > field or it isn't and then the field is rather making things like comparing
> > packages with each other difficult. We already accept that the uniqueness
> > of packages with respect to their name/version/arch only holds within a
> > certain distribution. But that distribution will also always know with
> > which build profiles they built all their packages.
> Why is it making comparing packages with each other difficult?

What I meant here was what I mentioned elsewhere in this thread. We can check
whether two binary packages built with a different set of build profiles active
are actually the same by using the tools from the reproducible builds project.
And the easiest way to do the comparison is to compare their hashes. If the
build profile would be included, then comparing the packages would be made more
difficult.

> It's an additional annotation of what the package actually contains.

I would rather say that the set of build profiles active is a property of the
*build* and not a property of the binary package. Especially considering that
most build profiles require identical package contents. We also don't store in
binary packages which build dependencies were installed in which version during
the build even though this is also something that can have great influence on
the content of the binary package.  Instead, we store this information in the
buildinfo file which I also find a better fit for storing the information which
build profiles were active because build profiles are a property of the package
build.

> If you upload the set of bootstrap packages and especially if you have
> multiple intermediate stages, you surely would want to know which packages
> will need to be rebuilt to the point of not requiring build profiles anymore,
> no?

At all points during the bootstrapping, we know which source packages we built
with with which profiles active either by simply keeping track of what is being
done or by investigating the generated buildinfo files which contain that
information. It is not necessary to have this information stored in the binary
packages itself for this purpose.

> At the same time for a stable port the archive can ensure that the build
> profile was actually the default one (or accept divergences with a conscious
> decision, like using NEW or BYHAND).

The archive can already do this check by investigating the buildinfo file that
was uploaded together with the binary packages.

> So I don't think it's as black and white wrt full flexibility in dependencies
> as you paint it. :)

Surely, rarely anything is really black and white. :)

Thanks!

cheers, josch


signature.asc
Description: signature

Re: [yay for broken usage of was: in the Subject header]

[Philipp Kern]

On 2018-01-10 22:53, Johannes Schauer wrote:
But unless we want to pull a full Gentoo here and really make the 
information
with which build profile a given binary package was built part of the 
binary
package and thus overhaul all our dependency resolvers, unless the plan 
is to
do that, I don't see why binary packages should contain this 
information.


Either it is used for dependency resolution and then we should have the 
field
or it isn't and then the field is rather making things like comparing 
packages
with each other difficult. We already accept that the uniqueness of 
packages

with respect to their name/version/arch only holds within a certain
distribution. But that distribution will also always know with which 
build

profiles they built all their packages.


Why is it making comparing packages with each other difficult? It's an 
additional annotation of what the package actually contains. If you 
upload the set of bootstrap packages and especially if you have multiple 
intermediate stages, you surely would want to know which packages will 
need to be rebuilt to the point of not requiring build profiles anymore, 
no?


At the same time for a stable port the archive can ensure that the build 
profile was actually the default one (or accept divergences with a 
conscious decision, like using NEW or BYHAND).


So I don't think it's as black and white wrt full flexibility in 
dependencies as you paint it. :)


Kind regards
Philipp Kern

Bug#885604: Subject: ITP: node-meant -- Similar to 'Did you mean', returns probable correction

[Sruthi Chandran]

Package: wnpp
Severity: wishlist
Owner: Sruthi Chandran 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-meant
  Version : 1.0.1
  Upstream Author : Daijiro Wachi
* URL : https://github.com/watilde/meant#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Similar to 'Did you mean'
 Compares an item (a string for finding an approximate value) with the
list for
 comparing with the item, to return the probable correction.
 .
 If 'foa' is given as the item and the list includes 'foo', 'bar',
'baz', the
 module will return 'foo'
 .
 Node.js is an event-based server-side JavaScript engine.
 .
 Dependency for npm 5



signature.asc
Description: OpenPGP digital signature

Bug#879995: Subject: ITP: node-validate-npm-package-name -- Checks if a string is a valid npm package name

[Sruthi Chandran]

Package: wnpp
Severity: wishlist
Owner: Sruthi Chandran 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-validate-npm-package-name
  Version : 3.0.0
  Upstream Author : zeke
* URL : https://github.com/npm/validate-npm-package-name
* License : ISC
  Programming Lang: JavaScript
  Description : Checks if a string is a valid npm package name
 This module can determine if a string is valid to be used a npm module
name. This module will show conformance to old naming rules and new
naming rules separately.
 .
 Node.js is an event-based server-side JavaScript engine.
 .
 This is a dependency of npm5.



signature.asc
Description: OpenPGP digital signature

Bug#879782: Subject: ITP: node-get-func-name -- Utility for getting a function's name for node and the browser

[Sruthi Chandran]

Package: wnpp
Severity: wishlist
Owner: Sruthi Chandran 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-get-func-name
  Version : 2.0.0
  Upstream Author : Jake Luer 
(http://alogicalparadox.com)
* URL : https://github.com/chaijs/get-func-name#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Utility for getting a function's name for node and
the browser
 This is a module to retrieve a function's name securely and
consistently both in NodeJS and the browser.
 .
 Node.js is an event-based server-side JavaScript engine.



signature.asc
Description: OpenPGP digital signature

Bug#870218: (no subject)

[Yinhang Liu]

Package: wnpp
Severity: wishlist
Owner: Yinhang Liu 

* Package name: libxcam
  Version : 1.0.0
  Upstream Author : Wind Yuan 
* URL : https://github.com/01org/libxcam
* License : Apache-2.0
  Programming Lang: C, C++ 
  Description : Extended camera features and cross platform computer vision 
project

libXCam is a project for extended camera features and focus on
image/video quality improvement. There are lots features supported
in image pre-processing, image post-processing and smart analysis.
This library makes GPU/CPU working together to improve image quality.
OpenCL is used to improve performance in different platforms.

[no subject]

[АЛЕЌСѦНДِР̗ ЛЕБЕДЀВ҉]

https://lh3.googleusercontent.com/xDa0Z7rwT1huYi-lXe62b8lI58Amjmb_VgN-JwPLrbpg6wpFUOQ-VfQTP3O6NDFajGKlfMQ0E2qimvq9QTYfR2bBk3xPfzIIM26LhjbXy-4PpPh5GqDbW21EdovwDk8_j4FpGk-dbfFSL8Z7TxpIuB79fYH4-U7NxfEYC6nffvPnummhEEsjNllOS8RAo-FUDrnsSLMigfsHYQZhGM2nMMucEzhdSAWswahgjZVNbYglbjnQKqt44WdT85JGTDrr8gsEuBiy7FbPUwjC7mjgdNahkSWfSsb_Yf02prnSgQfKpk58EN8kN9kmCvqeGkt02j0jPxUoH7zVmAUs2t7g7vgHHpo7VLPgZg9_loYUdj3R1d0N2ChnPOc8o4BfqjoAdYT6lF1YOihlImii7Q1XKwBPqrICqJkS-h1nq-lNRCNBl1gCbPBeEngGA61VKYehK8jyJrWbSpJcpX0DKABXTfkFBqwoGG5jlGckIIf_CQlMMpFdueE8IXSDvUxtfGeKDWEuRoGxM2a7dw3OxlGCQ9a9Ugy2snZIHVSgXX_hoQ0Jw1CZNNMSwcu65YTpxdMS3hCzVrc3Bu69LGNac5n5IqimG_rzDiXXLsVHXYj_gorNgpXY3pxKUZ4eeUE5ByjNUpv83ZdLQpops5d4p3e2q_14zqEPdnoxqbyjvXrosy6PKaY=m22?cpn=bl5iV7RLw3bdUPpZ=WEB=1.20170727

Re: Subject: UMASK 002 or 022?

[Paul Wise]

On Thu, Jun 29, 2017 at 12:21 AM,  gwmfms6 wrote:

> Paul, you seemed to indicate that you were able to set a different "user
> default" umask in Stretch that's respected by gnome apps like gedit?

No, I didn't indicate that. See my other reply for clarification.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Subject: UMASK 002 or 022?

[gwmfms6]

My thinking in advocating for OTHER being 7 (ie, 027 or 077) was that 
the incidents when someone wants OTHER to have access to their files are 
fewer than when they do not want OTHER to have access. Do users 
generally want OTHER to be able to read all their files? Or do they have 
a particular set of files that they want OTHER to be able to 
access/read? In this context it makes more sense to me to put the burden 
on adjusting those specific files that the user wants OTHER to have 
access to instead of having them that way by default. Having to adjust 
those specific files also reinforces to the user what they are doing 
(ie, they are giving the world access to those particular files).




On 2017-06-28 07:25, Ian Jackson wrote:

Paul Wise writes ("Re: Subject: UMASK 002 or 022?"):

On Wed, Jun 28, 2017 at 1:11 AM,  gwmfms6 wrote:
> This discussion should be on whether to set a default UMASK of 077 or 027.

I think the appropriate default umask is 077 due to the possibility of
some sites not naming the primary group of each user after the user.


The appropriate default umask is 002 if the user's primary group is
named after the user, or 022 otherwise.

If only we had some kind of automated information processing equipment
which could collect necessary inputs and then make correct decisions.

Ian.

Re: Subject: UMASK 002 or 022?

[gwmfms6]

Paul, you seemed to indicate that you were able to set a different "user 
default" umask in Stretch that's respected by gnome apps like gedit? How 
did you do it?



On 2017-06-28 09:21, Paul Wise wrote:

On Wed, Jun 28, 2017 at 7:25 PM, Ian Jackson wrote:


The appropriate default umask is 002 if the user's primary group is
named after the user, or 022 otherwise.


AFAICT, neither of these achieve what the initiator of the thread
wants to achieve; no read access by other users to one's files on
multi-user systems by default.

Re: Subject: UMASK 002 or 022?

[Paul Wise]

On Wed, Jun 28, 2017 at 8:59 PM,  gwmfms6 wrote:

> You didn't notice because you run umask from your shell configuration?

I should clarify, I meant bash shell not gnome-shell.

>  In other words, you have a working umask in Stretch?

In my terminals yes, but not in apps launched from the GUI.

> Can you tell me how to "run `umask 027` from my shell configuration"?

I have the equivalent of this:

echo 'umask 027' >> ~/.bashrc

> Currently, I have not found a way to get gnome to respect umask setting in 
> Stretch.

No idea how to do that.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Subject: UMASK 002 or 022?

[gwmfms6]

You didn't notice because you run umask from your shell configuration? 
In other words, you have a working umask in Stretch?


I want a working umask in stretch. Can you tell me how to "run `umask 
027` from my shell configuration"? Currently, I have not found a way to 
get gnome to respect umask setting in Stretch.



On 2017-06-28 00:14, Paul Wise wrote:

I had "UMASK 027" in /etc/login.defs and I didn't notice that this no
longer works because I also run `umask 027` from my shell
configuration. If you can track down why this no longer works, please
file a bug about it and convince the maintainer to fix it in stretch.

Re: Subject: UMASK 002 or 022?

[gwmfms6]

Setting umask in ~/.profile on Jessie works for me.


On 2017-06-28 01:04, Arto Jantunen wrote:

It doesn't work since pam_umask isn't run by default. However as far as
I know this has been the case for a very long time (the oldest install 
I

can check quickly is squeeze and it has the same issue).

Re: Subject: UMASK 002 or 022?

[Paul Wise]

On Wed, Jun 28, 2017 at 7:25 PM, Ian Jackson wrote:

> The appropriate default umask is 002 if the user's primary group is
> named after the user, or 022 otherwise.

AFAICT, neither of these achieve what the initiator of the thread
wants to achieve; no read access by other users to one's files on
multi-user systems by default.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Subject: UMASK 002 or 022?

[Ian Jackson]

Paul Wise writes ("Re: Subject: UMASK 002 or 022?"):
> On Wed, Jun 28, 2017 at 1:11 AM,  gwmfms6 wrote:
> > This discussion should be on whether to set a default UMASK of 077 or 027.
> 
> I think the appropriate default umask is 077 due to the possibility of
> some sites not naming the primary group of each user after the user.

The appropriate default umask is 002 if the user's primary group is
named after the user, or 022 otherwise.

If only we had some kind of automated information processing equipment
which could collect necessary inputs and then make correct decisions.

Ian.

Subject: UMASK 002 or 022?

[gwmfms6]

I'd like to know why giving the world (Other) read access is even under 
consideration. If user wants a file to have Other readability this 
should be on the user to set it, but it should not be the default.


What is the justification that every user be able to read every other 
user's documents?


This discussion should be on whether to set a default UMASK of 077 or 
027.



NOTE: this discussion is made all the more important currently because 
it seems impossible to set a UMASK at all on Debian Stretch. None of the 
usual ways work within gnome on Debian Stretch. Can anyone comment on 
this fact? How does one get gnome to respect the umask value that's set 
in ~/.profile? Or if not ~/.profile where does one set the default umask 
value for gnome?

Re: Subject: UMASK 002 or 022?

[Simon Richter]

Hi,

On 27.06.2017 19:11, gwmf...@openmailbox.org wrote:

> I'd like to know why giving the world (Other) read access is even under
> consideration. If user wants a file to have Other readability this
> should be on the user to set it, but it should not be the default.

That can be solved by excluding people from the directory the files are
in -- in order to access a file, all directories on the way there need
to have at least 'x' permission for the current user.

So, an umask of 022 and having each user in a single-member primary
group gives the user all options:

 - To make your home directory completely private, chmod it to 750 (the
group permissions don't matter really, because there is no one else in
the group).

 - To allow other users to pass through your home directory (e.g. the
webserver on the way to ~/public_html), chmod your home to 751.

 - To create a directory that a group of users may write to, use chgrp
and then set permissions to 2770 (or 2775, if others should also be able
to read).

The Debian installation used to ask whether home directories should be
private by default, IIRC that question still exists but is too low
priority to be shown outside of expert mode. You can use

dpkg-reconfigure adduser

to set this up, then new user home directories will be created with 750
permissions.

This method allows a one-time setup of desired behaviour, while the
umask would need to be set at every login, and if it weren't set up
correctly, this would lead to files having the wrong permission with no
warning -- that's why it's more robust to just create files as readable
for others and lock them out of the entire home directory.

> What is the justification that every user be able to read everyone
> else's documents?

That depends on your use case. At university, we generally left the home
directory open, and kept a separate ~/private directory with restrictive
permissions, because it allowed us to easily share non-private files by
just telling people to get them from our home directories.

   Simon




signature.asc
Description: OpenPGP digital signature

Re: Subject: UMASK 002 or 022?

[Philip Hands]

Paul Wise  writes:

> On Wed, Jun 28, 2017 at 1:11 AM,  gwmfms6 wrote:
>
>> I'd like to know why giving the world (Other) read access is even under
>> consideration. If user wants a file to have Other readability this should be
>> on the user to set it, but it should not be the default.
>
> I expect for most Debian deployments this isn't that relevant, since
> most are either servers with no real users or single-user systems with
> no guest account.
>
>> What is the justification that every user be able to read everyone else's
>> documents?
>
> This decision was made in the mists of time and has never been questioned.
>
>> This discussion should be on whether to set a default UMASK of 077 or 027.
>
> I think the appropriate default umask is 077 due to the possibility of
> some sites not naming the primary group of each user after the user.

077 is poor choice of default given that we decided to have users in
their own dedicated group precisely to allow more generous group
permissions, and if someone decides to deviate from that policy they
need to take care of the consequences of their actions.

In case anyone is wondering why we have users in their own group is it
to allow one to create shared group directories, with the group s-bit
set, so that anyone in that group can create files in that directory.

If one has a 077 umask, that results in files in s-bit directories being
created that only the creator can read, which is almost certainly not
what you wanted.

To fix that, one sets a umask of something like 027 or 022 or 002
depending on your needs, but on traditional *nix systems all users would
generally be in a users or staff group, so you just gave
overly-permissive access to your home directory by doing that -- hence
the dedicated per-user groups.

> That said, 027 would probably be a reasonable default too since most
> sites do not do that.

I think 027 is much easier to justify, is seems likely that anyone that
prefers 022 over 027 is more likely to know why.

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

Re: Subject: UMASK 002 or 022?

[Arto Jantunen]

Paul Wise  writes:
> On Wed, Jun 28, 2017 at 1:11 AM,  gwmfms6 wrote:
>> NOTE: this discussion is moot at the present time anyway because it is
>> impossible to set a UMASK at all on Debian Stretch. None of the usual ways
>> work within gnome on Debian Stretch. Can anyone comment on this fact?
>
> I had "UMASK 027" in /etc/login.defs and I didn't notice that this no
> longer works because I also run `umask 027` from my shell
> configuration. If you can track down why this no longer works, please
> file a bug about it and convince the maintainer to fix it in stretch.

It doesn't work since pam_umask isn't run by default. However as far as
I know this has been the case for a very long time (the oldest install I
can check quickly is squeeze and it has the same issue).

-- 
Arto Jantunen

Re: Subject: UMASK 002 or 022?

[Paul Wise]

On Wed, Jun 28, 2017 at 1:11 AM,  gwmfms6 wrote:

> I'd like to know why giving the world (Other) read access is even under
> consideration. If user wants a file to have Other readability this should be
> on the user to set it, but it should not be the default.

I expect for most Debian deployments this isn't that relevant, since
most are either servers with no real users or single-user systems with
no guest account.

> What is the justification that every user be able to read everyone else's
> documents?

This decision was made in the mists of time and has never been questioned.

> This discussion should be on whether to set a default UMASK of 077 or 027.

I think the appropriate default umask is 077 due to the possibility of
some sites not naming the primary group of each user after the user.
That said, 027 would probably be a reasonable default too since most
sites do not do that.

> NOTE: this discussion is moot at the present time anyway because it is
> impossible to set a UMASK at all on Debian Stretch. None of the usual ways
> work within gnome on Debian Stretch. Can anyone comment on this fact?

I had "UMASK 027" in /etc/login.defs and I didn't notice that this no
longer works because I also run `umask 027` from my shell
configuration. If you can track down why this no longer works, please
file a bug about it and convince the maintainer to fix it in stretch.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Subject: UMASK 002 or 022?

[gwmfms6]

I'd like to know why giving the world (Other) read access is even under 
consideration. If user wants a file to have Other readability this 
should be on the user to set it, but it should not be the default.


What is the justification that every user be able to read everyone 
else's documents?


This discussion should be on whether to set a default UMASK of 077 or 
027.



NOTE: this discussion is moot at the present time anyway because it is 
impossible to set a UMASK at all on Debian Stretch. None of the usual 
ways work within gnome on Debian Stretch. Can anyone comment on this 
fact?

Bug#844474: Subject: ITP: golang-github-geertjohan-go.rice -- Go package for embedding web resources into Go executables

[Potter, Tim (HPE Linux Support)]

X-Debbugs-CC: debian-devel@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Package: wnpp
Severity: wishlist
Owner: Tim Potter 

* Package name: golang-github-geertjohan-go.rice
  Version : 0.0~git20160123.0.0f3f5fd-1
  Upstream Author : Geert-Johan Riemer
* URL : https://github.com/GeertJohan/go.rice
* License : BSD-2-clause
  Programming Lang: Go
  Description : Go package for embedding web resources into Go executables

go.rice is a Golang package that makes working with resources such as
html, js, css, images and templates very easy. During development
go.rice will load required files directly from disk. Upon deployment
it is easy to add all resource files to a executable using the rice
tool, without changing the source code for your package. Several
methods are provided for adding resources to your binary by go.rice.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#837805: (no subject)

[IOhannes m zmoelnig]

Package: wnpp
Severity: wishlist
Owner: IOhannes m zmölnig (Debian/GNU) 

* Package name: python-can
  Version : 1.5.2
  Upstream Author : Brian Thorne 
* URL : https://bitbucket.org/hardbyte/python-can
* License : LGPL v3
  Programming Lang: Python
  Description : Controller Area Network (CAN) interface module for Python

Binary package names: python-can, python3-can

 The Controller Area Network (CAN, aka "CAN bus") is a bus standard designed
 to allow microcontrollers and devices to communicate with each other. It
 has priority based bus arbitration, reliable deterministic
 communication. It is used in cars, trucks, boats, wheelchairs and more.
 .
 The ``can`` package provides controller area network support for
 Python developers; providing `common abstractions to
 different hardware devices`, and a suite of utilities for sending and receiving
 messages on a can bus.

I intend to maintain this package (and another CAN bus related package) within
the Debian Python Modules Team.

Bug#835254: (no subject)

[Mouaad Aallam]

Package: wnpp
Severity: wishlist
Owner: Mouaad Aallam 

* Package name: google-android-studio-installer
  Version : 2.1.3.0
  Upstream Author : Google, Inc
* URL : https://developer.android.com/studio/index.html
* License : public-domain
  Programming Lang: C, Java, Bash
  Description : This is a packaged script that automatically downloads 
Google's Android Studio package and unpacks it into Debian-friendly paths.
  Target  : contrib

 Google Android Studio (IDE) Installer
 This package will download the Google Android Studio package and create a
 Debian package.
 .
 Android Studio is the official integrated development environment (IDE) for
 Android platform development and provides the fastest tools for building apps
 on every type of Android device.
 .
 WARNING: Installing this Debian package causes android-studio-ide-*-linux.zip
 to be downloaded from dl.google.com and/or from other suggested mirrors. The
 End User License Agreement of this binary package is available at
 developer.android.com.

Bug#830547: (no subject)

[Al Nikolov]

Package: wnpp
Severity: wishlist
Owner: Al Nikolov 

* Package name: trac-icalview
  Version : 15654
  Upstream Author : Xavier Péchoultres 
* URL : http://trac-hacks.org/wiki/IcalViewPlugin
* License : GPL2
  Programming Lang: Python
  Description : Provides iCalendar feeds for ticket queries

This plugin provides iCalendar feeds for ticket queries as standard
roadmap module. It use 2 optional custom fields for event date and
duration.

This package is going to replace trac-icalviewdplugin in order
to be aligned with the majority of Trac hacks package names.

Re: Unidentified subject!

[cbannister]

On Sun, Jun 12, 2016 at 12:04:59AM +1200, 
bounce-debian-devel=cbannister=slingshot.co...@lists.debian.org wrote:

Weird! Don't know what happened here. :(

-- 
The media's the most powerful entity on earth. 
They have the power to make the innocent guilty 
and to make the guilty innocent, and that's power.
 -- Malcolm X

Unidentified subject!

[bounce-debian-devel=archive=mail-archive . com]

[no subject]

[Adolfo Holzmann]

Hi people:
i'm a real person not machine, i'm from chile and i have a friend who
knows php, Java,bootstrap,html5,phonegap,laravel,codeigniter and many
others. He is a father of 2 kids and he is unemployed, could you give
him a work as a dedicated developer?

Ps: i can prove that i'm not a machine...The closed line integral in
the electric field is 0 and a machine cant eat "empanada","choripan"
and drink "chicha".

Thanks for read me

His facebook:
https://www.facebook.com/renofari?fref=ts

Bug#815760: (no subject)

[Christian Ehrhardt]

Subject: ITP: dpdk -- Data Plane Development Kit
Package: wnpp
Owner: Christian Ehrhardt <christian.ehrha...@canonical.com>
Severity: wishlist

* Package name: dpdk
  Version : 2.2
  Upstream Author : Thomas Monjalon <thomas.monja...@6wind.com>
* URL : http://dpdk.org/
* License : BSD (core libs), GPLv2 (kernel components)
  Programming Lang: C
  Description : Data Plane Development Kit

1. What is DPDK useful for
DPDK is a set of libraries and drivers for fast packet processing. It
was designed to run on any processors. The first supported CPU was Intel
x86 and it is now extended to IBM Power 8, EZchip TILE-Gx and ARM. It
runs mostly in Linux userland. A FreeBSD port is available for a subset
of DPDK features.

Main libraries
- multicore framework
- huge page memory
- ring buffers
- poll-mode drivers

Usage
These libraries can be used to:
- receive and send packets within the minimum number of CPU cycles
  (usually less than 80 cycles)
- develop fast packet capture algorithms (tcpdump-like)
- run third-party fast path stacks
Some packet processing functions have been benchmarked up to hundreds
million frames per second, using 64-byte packets with a PCIe NIC.


2. Maintenance Plan
I'm currently maintaining dpdk for ubuntu (launchpad.net/ubuntu/+source/dpdk)
and the existing packaging should be suitable for Debian also.

It'd be great to have this packaged in Debian too, so that we can share the
work. I am looking for co-maintainers to help me with this.

But I'm not a Debian developer, so I'd like to have a more Debian centric
co-maintainer for a proper Debian expertise and opinion in all the work.
I'm also no DD, so sponsors will be needed.

[no subject]

[Gerardo Ramos]

Sent from Mail for Windows 10

Bug#796920: Subject: ITP: ripper -- scrape licenses out of files

[Fernando Ike]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org
Owner: Fernando Ike f...@midstorm.org

* Package name: ripper
  Version : 0.0~git20150415.0.bd1a682-1
  Upstream Author : Emmanuel Odeke emm.od...@gmail.com
* URL : https://github.com/odeke-em/ripper
* License : Apache-2.0
  Programming Lang: Go
  Description : scrape licenses out of files
 Ripper inspect source files and show the license if it found. It
 support directories, files or URI repositories as argument.
 .
 This package provides command-line to use alone or embbed in others
 programs.

-- 
Fernando Ike
http://www.fernandoike.com

Bug#795101: Subject: ITP: stenographer -- full-packet-capture utility

[Hilko Bengen]

Package: wnpp
Severity: wishlist
Owner: Hilko Bengen ben...@debian.org

* Package name: stenographer
  Version : 0.0~git20150805.0.b8123c7-1
  Upstream Author : Google
* URL : https://github.com/google/stenographer
* License : Apache-2.0
  Programming Lang: Go, C++
  Description : full-packet-capture utility
   Stenographer is a full-packet-capture utility for buffering packets
   to disk for intrusion detection and incident response purposes. It
   provides a high-performance implementation of NIC-to-disk packet
   writing, handles deleting those files as disk fills up, and provides
   methods for reading back specific sets of packets quickly and easily.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87fv3rw35e@msgid.hilluzination.de

[no subject]

[Éderson Almeida de Jesus]

Em 28 de julho de 2015 21:05, Paulo Henrique Santana
p...@softwarelivre.org escreveu:

 Olá Ederson

 - Mensagem original -
  De: Éderson Almeida de Jesus ederje...@gmail.com

  Sendo assim, gostaria de saber se há a possibilidade de fazer a gravação
  das palestras e disponibilizar os vídeos, bem como o material das mesmas no
  FTP da DebConf Video Archive[4]. No próprio site da DebConf [5] há a
  seguinte descrição An archive with all available recordings from previous
  DebConfs and other Debian events is available at http://video.debian.net.;

 AS palestras do FISL16 foram gravadas e os arquivos estão disponíveis com os 
 links na grade:
 Veja a sala 41D.

 http://schedule.fisl16.softwarelivre.org/#/2015-07-10

 Abraços,


Olá Paulo,

Que ótimo que as palestras do FISL16 foram todas gravadas e estão disponíveis!!!

Ainda acho que seria interessante colocar essas palestras no FTP da
DebConf Video, assim teríamos um backup em outro server, caso o
server do softwarelivre.org fique indisponível. Além disso, como o
assunto é relacionado ao Debian e a distribuição disponibiliza o
servidor para este conteúdo, acho boa a ideia em colocar no server
apontado pela distribuição.

O assunto de disponibilização do conteúdo surgiu, pois como ainda irá
ocorrer a MiniDebConf  no Latinoware 2015 então pensei em dar este
aviso/dica ao pessoal que organiza o evento para que se possível fazer
a gravação e a disponibilização do conteúdo, dessa forma, quem não
puder comparecer poderá assistir as palestras baixando do FTP.

Bom, não quero desviar do assunto deste post (que é a chamada para
atividades e palestras para a MiniDebconf @ Latinoware 2015), então
Antonio Terceiro e pessoal da organização, se houver a possibilidade
de gravação e disponibilização dos materiais acho que a comunidade
ficaria muito feliz com isso.

Atenciosamente;


Éderson A. Jesus
E-mail.: ederjesus at gmail dot com


--
To UNSUBSCRIBE, email to debian-devel-portuguese-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAG8ND-MoWie78dq51p2JpcNbsuu-L2ZqUASj-uF4O0Bj=k-...@mail.gmail.com