Re: finally end single-person maintainership

[Joerg Jaspert]

On 17194 March 1977, Luca Boccassi wrote:
Simple packages need someone who is responsible and responsive for 
them
in the long run and know there history much more than needing 
sporadic

contributions.

...right up until the point where that "bus factor of 1" moves
on/changes priorities/changes job/etc and the package is abandoned.
Fortunately that never happens, though!


And interestingly, this does NOT need required team maintainance. It
does NOT need "package must be in git". It does NOT need "package must
be on salsa".

It "only" needs good procedures in taking over maintainership of
abandoned packages. And hey, for clearly abandoned packages, we have
that, and it works.


The problem is with people who are *not* clearly gone. Who are around
and block changes to "my package, my way, i ignore all outside wishes".
Or who are around and work against project wishes, in some way. And no
amount of "force a team on everyone" and no amount of "you must use
salsa" will solve this problem. While creating problems elsewhere.

--
bye, Joerg

Re: xz backdoor

[Joerg Jaspert]

On 17185 March 1977, Andrey Rakhmatullin wrote:

Didn't DKG start something like this some time ago? Or am I
mis-remembering?
I also thought I remember some Debian-specific PGP-related document 
but I

couldn't find it.


You may remember https://keyring.debian.org/ which has a bunch of links 
to other places too, and from there maybe 
https://keyring.debian.org/creating-key.html - but its all not exactly 
what people ask for. Its more a "go this way and get those results", 
which is fine, but different thing.


--
bye, Joerg

Re: Deprecation of /etc/alternatives? (Re: Reaction to potential PGP schism)

[Joerg Jaspert]

On 17086 March 1977, Gioele Barabucci wrote:

While we are on the topic of alternatives, I hope to see the 
maintscript-based /etc/alternatives paradigm deprecated in favor of 
the 
package-based X-is-X paradigm introduced by `python-is-python3`.


In this scenario gnupg will ship gpg as /usr/bin/gpg-gnupg, while 
sequoia-chameleon-gnupg will ship its gpg as /usr/bin/gpg-sq. Then the 
user can decide to install gpg-is-gnupg or gpg-is-sequoia (with the 
distro-wide preference expressed setting the appropriate Recommends in 
gnupg or sequoia-chameleon-gnupg).


Ugh no, and have tons of near-empty packages for no good reason and also 
make local admins life harder.


--
bye, Joerg

Re: Reaction to potential PGP schism

[Joerg Jaspert]

On 17077 March 1977, Stephan Verbücheln wrote:


How can Debian deal with this? Should Debian intervene to prevent the
worst?


We, as Debian, look and wait what comes out. And then *MAY* at some
point decide to add (or switch to) a new thing, if that appears better. 
Also, it will be a high bar for that.[1]


Individuals, including Debian developers, are - of course - free to jump 
in and take part in this.


[1] not counting the usage/scriptability of gnupg, that bar is somewhere 
down DEEEP in the earth, its so horrible.


--
bye, Joerg

Re: [idea]: Switch default compression from "xz" to "zstd" for .deb packages

[Joerg Jaspert]

On 16988 March 1977, Hideki Yamane wrote:

 Today I want to propose you to change default compression format in 
 .deb,

 {data,control}.tar."xz" to ."zst".
 I want to hear your thought about this.


Negative.


# Compared to past change to xz proposal (in DebConf12)
  * More bandwidth
  * More CPUs
  * More storage bandwidth


Get us actual numbers please on how much a full Debian mirror would 
increase in size.

Also consider services like snapshots.

I do not think wasting space is any good idea.


## More bandwidth
 According to https://www.speedtest.net/global-index, broadband 
 bandwidth

 in Nicaragua becomes almost 10x


And elsewhere it may have gone up a different factor.
Still, there are MANY places where its still bad.


 And, xz cannot use multi core CPUs for decompression but zstd can.
 It means that if we use xz, we just get 2x CPU power, but change to 
 zst,

 we can get more than 10x CPU power than 2012.


In ideal conditions, maybe, but still, thats the first (to me) good 
reason. IMO not good enough to actually do it.



  - Not sure how repository size will be, need an experiment


And keep in mind the repository is mirrored a trillion times, stored in
snapshots, burned into images here and there, so any "small" increase in
size actually means a *huge* waste in the end.

If we switch formats, going to something that's at least as good as the
one we currently have should be the goal. (And I do not mean something
like "its code/algorithm is bad", really, that argument is dead before
it begins even).

Now, thats for .debs. There might be a better argument when talking
about the index files in dists/, they are read so much more often, it
*may* make more sense there.

--
bye, Joerg

Re: Reducing allowed Vcs for packaging?

[Joerg Jaspert]

On 16792 March 1977, Adrian Bunk wrote:

for the contents of packages in the archive the ftp team requires that 
everything is in the preferred form of modification.


Yes. Of course.

But git or svn or even sccs and rcs is NOT, in any way, preferred for of 
modification. Only one way of storage and handling some metadata.


--
bye, Joerg

Re: Sunsetting sso.debian.org

[Joerg Jaspert]

Am 2022-10-18 04:52, schrieb Paul Wise:


Salsa should be there for git (related) things.
NOT as an identity/login provider for Debian

There are already Debian services that do not offer any other option
for auth than Salsa.


Which is bad. And should be changed.


Arguably it is probably a good thing to use Salsa, since it means
services can have an auth option for all of the Debian contributors,
including those who are not currently DDs or DMs.


No, it is a bad, not a good thing, to use Salsa for this.
Salsa is a "repository service" with some added nice features related to 
them. It is good at that, yay. Fine.


Salsa is really bad as an identity/authentication service. Having a 
salsa account does NOT mean ANYTHING related to Debian, like 
DM/DD/whatever. And thats information that such a service ought to 
provide too. It also does not allow any kind of useful management of 
identities besides "the account is there/blocked/deleted". And so, as 
soon as you would want to NOT allow someone a login to a service that 
uses salsa as a login service - you need to delete their account. 
Including their repositories and abilities there. Not good.


IMO that functionality of salsa should be deactivated *right* *now*. To 
not have it get used even more.


Salsa ought to use some service for login, not the other way. Keycloak 
or whatever else, doesnt matter. And that service ought to be properly 
integrated with NM and the DSA services.


--
bye Joerg

Re: Sunsetting sso.debian.org

[Joerg Jaspert]

On 16654 March 1977, Sam Hartman wrote:

I think the minimal solution here, which I'm not volunteering to do, 
is
for tracker.debian.org to gain salsa sso support instead of client 
cert

support.


But that isnt neccessarily the best solution. I think it would be better 
to NOT rely on salsa for SSO.
Salsa should be there for git (related) things. NOT as an identity/login 
provider for Debian, that is a different task.


--
bye, Joerg

Re: Russian locale on reprotest in Salsa CI?

[Joerg Jaspert]

Am 2022-10-13 10:13, schrieb Andreas Tille:


my Russian is a bit rusty but I can understand what I can read here:
   https://salsa.debian.org/science-team/cimfomfa/-/jobs/3372898#L1249



I'm just a bit astonished to see this locale set.  No idea what's wrong
here but I think this should be switched to English.


Well, scroll up a bit. It starts all fine in English, only the last make 
appears to switch.

Build system doing something fun?

Not a salsa thing.

--
bye Joerg

Re: …/doc …/log: .gz → .zst

[Joerg Jaspert]

On 16595 March 1977, Hakan Bayındır wrote:

I’d object that, because after we rotate the logs, we use a lot of z 
commands, namely zcat, zgrep, zless. Which allows us process many 
gigabytes of gzip files without extracting them first.


So you use zstdcat, zstdgrep, etc.pp, done.



--
bye, Joerg

Re: Multiple teams maintaining one package (proposal)

[Joerg Jaspert]

On 16310 March 1977, Jonas Smedegaard wrote:

Salsa access rights include the option to grant access to Debian 
developers at large, which can be used to permit upload rights for 
secondary teams (as upload generally requires Debian membership 
anyway).


Salsa lets one team grant rights to another team. (Group in salsa).
Instead of inviting a member to your group, select the invite group part
and add the team. It can even do "subgroups", so say if the python
team would have different membership for python modules and python
application, one could select to only allow the modules people access.

May be a better selection than adding "all of the DDs".

--
bye, Joerg

Re: automatic NEW processing [was Re: Need help with Multi-Arch in systemd]

[Joerg Jaspert]

On 16200 March 1977, Michael Lustfield wrote:

I do recall that the FTP masters would've been generally open to have 
such an auto-approver (but maybe I'm wrong), but that no-one stepped 
up 
yet to code it up?

A few of us came up with some proof of concept designs/models, but we
ultimately dropped the effort when it became clear the team wasn't 
interested
in such tools. We considered continuing with a tool that would work 
for
individual users reviewing their own work, but there just wasn't 
enough

interest for that either.


I'd be happy to help resurrect (the personal-use version of) the 
project/effort

if there's any chance I won't be working on it by myself...


The place for that feature to end up in is inside dak, obviously.
That feature should read its config (is it enabled? for the current 
package? with which config for it?) from the database (projectb).
And then just hook itself into the part of the uploading that redirects 
packages to NEW.


And then one could look if it gets implemented a bit more generic and 
not NEW specific, but able to do something like this for any policy 
queue. (As in, backports NEW, p-u, whatever). So, configurable per 
queue. For the actual feature and the affected packages.


Any MR going in that direction will be great.

--
bye, Joerg

Re: Need help with Multi-Arch in systemd

[Joerg Jaspert]

On 16194 March 1977, Simon McVittie wrote:


Would it be feasible for dak to have a list of binary package name
regexes mapped to a source package and a section/priority, and 
auto-accept

packages from the given source package that match the regex, assigning
the given section/priority, without manual action? That would let the
ftp team pre-approve src:systemd to ship /^libsystemd-shared-[0-9]+$/
in libs/optional, for example.


At some point somewhere I think it was already said, but in general: We 
love MRs, we are at https://salsa.debian.org/ftp-team/dak/ and something 
doing kind of auto-NEW processing is NOT out of the question.


Exact details have to be hashed out, but this is the wrong thread for 
that. While sometimes NEW can be annoying, it regularly catches bugs 
even if "only a small change in packaging" happened, so it does have 
some reason why its there. But yes, there are some candidates (hello 
kernel) that can make use of something with less humans involved.


Your example above doesn't sound too bad as a starter, though haven't 
put any further thought into it yet.


--
bye, Joerg

Re: About lintian

[Joerg Jaspert]

On 16128 March 1977, Felix Lechner wrote:


With the kind help of the good folks at DSA [1] Lintian's experimental
web application—still labeled "beta"—is now the official web presence.
[2] Please bear with us as we optimize the deployment and implement
additional features for you.


Thanks to you and DSA in getting over the troubles the thing had and
make lintian.d.o the place it should be again.

--
bye, Joerg


signature.asc
Description: PGP signature

Expectation of constructive interaction

[Joerg Jaspert]

Dear fellow Debian community members,

We have been having two weeks of difficult and heated discussion. The 
level of conflict has escalated out of proportion, both within the 
project and outside. 

We remind everyone that you are expected to interact constructively with 
our community. That goes not only for Debian Members, but also everybody 
who uses our mailing lists and other infrastructure.


This is true especially at a time when some in our community have 
received threats and others are expecting them, just because they took 
part in discussions or voted as our constitution allows them to.


This is entirely unacceptable.

We remind you that if you repeatedly send messages which raise the level 
of conflict; if you often behave confrontationally towards people; if 
you tend to disregard cries for help or requests to take a step back: 
you are not meeting our community standards.


We expect people not to justify themselves using the bad behaviour of 
others. As long as you use the unacceptable behaviour of others to 
justify your own unacceptable behaviour, you are not meeting our 
community standards.


Consider this a general warning to everyone / all sides. Different 
opinions are normal, and we have ways to resolve conflicts. But some of 
the behaviour we have witnessed recently is not, ever, tolerable.


Please think about the message you're about to send and whether it 
genuinely furthers discussion or simply antagonises others. For help, do 
reach out to your close circle of friends, and the Community Team.


--
For the DAMs,
 Joerg Jaspert
 Enrico Zini
 Jonathan Wiltshire


signature.asc
Description: PGP signature

Re: Packages in contrib solely because they allow using non-free software

[Joerg Jaspert]

On 16093 March 1977, Dominik George wrote:


That surprised me. If a package is free software, in ful laccordance
with the DFSG, why is it put into contrib? I can see where this note
comes from — the package maintainer does not want to help people
install non-free software, a point of view that is famous with the FSF
and a reason for them to discourage a distribution.



I want to open this for discussion, as I can fully understand both
points of view. While I could discuss this with the winetricks and
lutris maintainers alone, I think it is an important discussion and
decision for the project as a whole.


There is, as usual, no clear answer.

The policy for main is clear on that it needs to be self contained. So 
software in main must not require something outside to work and do its 
job. Contrib is the area where that is allowed. License wise its the 
same as main, but it allows to depend on something not available for 
building or working.


And I think that is why you find those packages over in contrib. Their 
main point is using something that's not in Debian. Yes, it may be 
entirely free software in itself, but that is not all that counts for 
main.


Now, if you can (and do) package a whole bunch of games that lutris 
supports, and the ability to load *more* from elsewhere is there, but 
not neccessary for its core functionality, it would be fine to go to 
main. (Assuming one can "fix" the winetricks dependency in a similar 
way, which I doubt, but thats another point).



--
bye, Joerg

Re: Contributing without your real name

[Joerg Jaspert]

On 16055 March 1977, Stephan Lachnit wrote:


I never really thought of this, and I'm not sure how much one can
contribute to Debian without posting some kind of real name
(sorry if that is already answered somewhere).



I'm aware that for sponsored work the name doesn't really matter,
but can one become a DM or even a DD?


Yes, this is possible and we do have developers with pseudonyms in 
Debian already. DAM gets to know the real name and keeps it 
confidential.


Interesting point is to build up a good reputation for the pseudonym, 
same as for anyone else. Key signing - well, key endorsements appear to 
make this part a little easier, but various people do sign keys of 
pseudonyms too, when they are sure that the key does belong to the 
person with that handle.


So yeah, possible, probably a little easier nowadays.

--
bye, Joerg

Re: RFC: courier-webadmin

[Joerg Jaspert]

On 15999 March 1977, Markus Wanner wrote:

I'm currently considering to drop the binary package courier-webadmin 
from the packaged courier suite due to security concerns.  This is a 
CGI 
binary allowing web based configuration of the Courier MTA.  To modify 
the configuration and restart the server(s), it needs to be setuid 
root.


[description of that stuff]

This is inspired by discussions with a disappointed user providing 
valuable feedback (in combination with somewhat less valuable feedback 
and in English sentences I have a hard time to understand) [2], [3].


So the code itself is not actually the security risk (minus any possible 
bugs, obviously), but the way it has to run and will be setup allows one 
to open holes that can lead to abuse of the courier service on the 
machine?


That does not sound like a good reason to drop it, but more like one to 
ensure that the config you ship is as secure as possible, possibly with 
information for the admin on what they need to keep in mind when 
adjusting it. It might make security drop a bit when installed, but 
(depending on how much this allows), there might be users actually 
depending on it for their instances.


If I'm going to drop this binary package, is a warning in NEWS enough 
(in courier-base, a dependency), or shall I better provide an empty 
shim 
package that actually removes the setuid binary (when upgraded)?


If you decide to remove it, ensuring you don't leave unmaintained files 
around is a good thing.


--
bye, Joerg

Re: NEW queue almost empty

[Joerg Jaspert]

On 15951 March 1977, Federico Ceratto wrote:


If people are interested, there's a little chart I put together:
https://people.debian.org/~federico/new_queue/
(It's manually updated because it requires ssh-ing to coccia.d.o)


Nice. We do have a whole bunch of graphs here:
https://ftp-master.debian.org/stat.html

Reachable from https://ftp-master.debian.org/

Would be nice if you could add yours to that one. If you are interested 
and want to do so, https://salsa.debian.org/ftp-team/dak/ is the repo 
for the merge request, and you want to check what "dak graph" is doing 
to maybe extend that, or look into hourly.functions in config/debian and 
possible extend function queuereport (or put a new beside and add it to 
hourly.tasks to get called).


--
bye, Joerg

Re: Split Packages files based on new section "buildlibs"

[Joerg Jaspert]

On 15949 March 1977, Thomas Goirand wrote:

I'm sorry but I don't understand everything here. If we aren't going 
to

have new components like main/contrib/non-free, how will it work? We
main contain a new Packages.{gz,xz} file containing these? I'm 
guessing

that it's not just a modification to that file, because you wrote the
goal is to diminish its size...



From my original mail:


--8<---cut here---start->8---
The current proposal is to reduce the main Packages.xz files size by
splitting[4] out all of the packages that are not intended for users,
writing those into an own file.
--8<---cut here---end--->8---

The *exact* implementation is currently fluid, a Packages-buildlibs.xz 
and a kind of subcomponent-style for main both seem options.


--
bye, Joerg

Re: Split Packages files based on new section "buildlibs"

[Joerg Jaspert]

On 15949 March 1977, Calum McConnell wrote:

The Rust community's expectation seems to be that you would install 
cargo,
and use that to download and build the clap package directly from 
upstream,

without apt/dpkg being involved at all.
I don't know that that means we should abandon efforts to integrate 
the

debian packages into usable code.


[...]


There might be something about how cargo works that makes this kind of
integration impossible, similar to how the Nix package manager doesn't
play well with others.  But I don't think we should just segregate 
Rust

libraries to a corner of the archive without at least considering it.


While I do think its kind of foolish to assume the rust people in Debian 
haven't thought if its feasible to do so (or not), the best way to find 
out is talking to them. I found them quite helpful and friendly, even 
when I told them that their way is not what we want in Debian. I mean, I 
block their most preferred way from (continuing to) enter Debian, the 
rest of the team tells them similar for a longish time, so if it would 
be easy to just flip something and be "more debian like", I do think it 
would have been used.


Of course, if you find the magic, all the better.

And if that way comes around in a year or three, the proposal here makes 
it *easy* (archive side) to "switch them back into the main packages 
file".


--
bye, Joerg

Re: Split Packages files based on new section "buildlibs"

[Joerg Jaspert]

On 15948 March 1977, Paul Wise wrote:


Does this include the -dev packages for C/etc libraries?


No.

I guess it also applies to Haskell and other statically-linked 
languages.

https://wiki.debian.org/StaticLinking


StaticLinking itself is not enough. This is about languages where the 
actual development in it is discouraged from doing with the debian 
packaged stuff. Where you do not go "I need lib XY, i install 
libxy-perl/libxy-dev/whatever the name" and hack around using it. But 
"Oh, i want to hack on foo, i go get foo/cargo .../whateverthetool" and 
the debian package only ever comes in play if you do build debian 
packages using it.



The current proposal is to reduce the main Packages.xz files size by
splitting[4] out all of the packages that are not intended for users,
writing those into an own file. Those packages would have a section 
of

"buildlibs", independent of their other properties.

Should (almost?) everything in the existing libdevel section move to
the new buildlibs section?


No, if so we would have split that section out.

--
bye, Joerg

Split Packages files based on new section "buildlibs"

[Joerg Jaspert]

Hi everybody,

Short Reason: Too many packages of no use to our users.

Longer reason: Many packages get added to Debian that are of no (direct)
use to our users. Each package adds metadata to the indices that needs
to be downloaded, processed by tools and also clutters up the whole
package list for no practical benefit. A split out packages file will
allow us to minimise the effect on users.

More and more packages are being uploaded into the Debian archive which
are only ever used for building packages. These are not only never
intended to be installed onto an end-user's system, they are even
actively discouraged from being used directly by a user. The two
currently most notable examples are packages used by the Go and Rust
programming languages and their ecosystem, but there well may be
others[1]. While we need their library packages to build the
applications that use them, they are entirely statically compiled and
none of the libraries will ever be installed on a normal user's system.

Moreover, the language ecosystem in Debian actively discourages users
from installing them for anything other than rebuilding a Debian
package. If you do general (non-Debian-specific) development using Go or
Rust on your machine, the expectation is that you will use the
language-specific tools to install your dependencies [2].

Currently however, all of those packages end up in the indices we
generate, which users have to download and package managers have to read
and deal with. Each of those packages therefore slightly increases the
size of these indices for little reason and while many users have access
to large bandwidth connections and fast CPUs, that is not the case for
many other users and does not benefit global warming.

For the Rust ecosystem, those sizes increase even more, as each of their
libraries can provide multiple features. For example, a TLS library can
link against GnuTLS or OpenSSL or some other random TLS implementation.
Such features may even be combined in various different ways, resulting
in an excess number of possible feature combinations for one Rust
package, called "crate". Those are "mapped" to the Debian package world
by creating something we call *feature packages*, with one such feature
package per feature or combination thereof (usually grouped by common
dependencies).

Those feature packages are empty packages, only containing a symlink for
their /usr/share/doc/… directory. Their size is smaller than the
metadata they will produce. Adding new features means one more trip
through the NEW queue each time such new binary packages are introduced.

The FTPTeam disagree with the feature-package solution[3], so currently
there is a workaround. By collapsing the features into the main library
package and declaring the features using the Provides header similar
functionality is achieved. However this doesn’t work in all situations,
for example:

   Tools can generate really long Provides: lines, with the current
   record being around 250kb. That's long enough that a tool (not dak
   itself) broke on it already. And those lines may grow larger in
   future.

   Some features may need different (build-)dependencies (say, GnuTLS
   vs OpenSSL), should those conflict with each other, you cannot
   combine them into one package and must fall back to the feature
   package solution.

   Generally, the workaround involves changing upstream's dependency
   structure in order to fit it into the aforementioned Debian
   constraints, and so of course this may not always play nicely with
   other packages that expect the unchanged upstream dependency
   structure. The feature-package solution is a 1-to-1 mapping.

There have been multiple discussions between the FTPTeam and the Rust
package maintainers. The FTPTeam does not want those feature packages in
the part of main downloaded by users and currently rejects them from
NEW, while the Rust maintainers see them as needed and the workaround as
just that. Both sides agree that this is not a productive and
sustainable solution and that we need to agree on something better.

The current proposal is to reduce the main Packages.xz files size by
splitting[4] out all of the packages that are not intended for users,
writing those into an own file. Those packages would have a section of
"buildlibs", independent of their other properties. That section should
only be activated on buildds and in situations that need
build-dependencies available (say, an archive rebuild, a user rebuilding
packages that need Build-Dependencies from there), but not by default
anywhere else. This section will allow feature packages and *may* even
let them bypass binary-NEW if they only add new feature (empty)
packages.

The exact way of how this gets implemented, both in dak and also apt, is
still being discussed between the ftpteam and the apt maintainers. We
have ideas from writing out section based packages files to presenting
it as a subcomponent to main, and we think we will have 

Re: NEW queue almost empty

[Joerg Jaspert]

On 15946 March 1977, Phil Morrell wrote:


There can never be too much of a good thing, so I just wanted to hand
out another thank you to the FTP masters (and this year's trainees)


Well, the current trainee does seem to have a "damn, nothing there" 
problem right now. :)


--
bye, Joerg

Re: NEW queue almost empty

[Joerg Jaspert]

On 15940 March 1977, Christian Kastner wrote:

The NEW queue length is down a single digit, from ~500 not all too 
long

ago. That's an amazing effort by ftp-master that must have consumed a
*lot* of energy.


It consumed quite a batch of my poor jelly beans. :)
<
--
bye, Joerg

Re: DAM Key and identity requirements

[Joerg Jaspert]

On 15892 March 1977, Michael Richardson wrote:


> A natural person may only have one identity in Debian.


> This was effectively enforced before by requiring cross-signing 
> keys,
> and relying on people doing the cross-signing to have key 
> signing

> policies strong enough to reliably connect a key to a person.



Does "one identity" mean one key, or one u...@debian.org?


It means one identity. Translatable to user@

I ask, because the occasional need to generate a new key from scratch 
means
giving up many cross-signatures.  People often keep the old key alive 
for
awhile for this reason.  I kept my 1994 era generated PGP2 format key 
alive

until at least 2010, even though it was too weak for new things.
My current key goes back to 2005, and it never got as many signatures 
as the

old key.


Thats why we said nothing about the keys.

--
bye, Joerg

Re: tag2upload service architecture and risk assessment - draft v2

[Joerg Jaspert]

On 15508 March 1977, Sam Hartman wrote:

First off: I, for personal reasons, am a bit detached right now with
anything Debian (though that should change soon). For that reason, I
haven't read most of the mail threads, though i skimmed over this one a
bit.


Scott> Your proposal completely changes the notion of what our
Scott> package archive is while, IMO, pretending to be something
Scott> else.



During the DPL campaign, a number of people, including Joerg, made
statements that I interpreted as explicitly wanting to make this change.
That is, they wanted to move our authoritative source format to Git,
possibly even getting rid of dscs in the medium future.


Yes.


Now we all get to think about it and decide how their implementation
experience influences whether we think it is a good idea.


I currently do not have too deep a thought on how good their
implementation is. Just one thing I've seen picked at multiple times,
and in different places: The current implementation appears to move away
the final integrity check linking an upload to a person away from the
archive software to some other.

Thats a no-go.

Note: I do not say it must be "a dsc" "a git commit" or "a something"
that is used for this check. That is an implementation detail. But the
final check/link of an upload with a maintainer(s key) has to be "in"
the archive. Systems before it can *additionally* do any number of them,
but the final one is in dak.


At least in my mind, this is all predicated on believing that moving
away from today's dscs toward git as authoritative source is actually a
good idea.
If you don't believe that, then you're never going to like this proposal
at all.
I guess you could decide you want tag2upload somehow even though you
don't want that transition.
I personally don't see how you get there unless you buy into the idea of
moving toward git as source.
Also, I want to make it clear that the DPL campaign didn't establish a
project direction.  It established enough interest that the idea was
worth exploring.
I'm not saying that because people brought this up in the campaign,
we've somehow decided to make a change.
I'm also not saying that this is somehow a DPL issue because it happened
in the DPL campaign.


I do like (as I stated in the past too) to move to something more git
like. I still want to keep the link between upload and maintainer in the
archive. I am sure that is achievable somehow. It may require one more
roundtrip with the maintainer for a signature.

Also, note that entirely relying on git for stuff introduces us back to
sha1, something the archive got rid of. Going backwards doesn't seem to
be a good idea?!

--
bye, Joerg

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

[Joerg Jaspert]

On 15413 March 1977, Aurelien Jarno wrote:


Thats ok, end of May is a nice point to take.
Thanks for the work and the timeframe for the rest!

kfreebsd-amd64 and kfreebsd-i386 have now been moved to debian-ports. As
hurd-i386 has been moved earlier, it means that all the 3 architectures
have now been moved.


Thank you!

--
bye, Joerg

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

[Joerg Jaspert]

On 15381 March 1977, Aurelien Jarno wrote:


> It would be nice to have a bit more than 2 weeks to do all of that.
Ok. How much? Is 6 or 8 weeks better? I don't think, given how long this
is on the table already, it doesn't make much difference if its 2 or 8.
Just something thats clear defined and not some random, non-clear
"sometime in the future" point.

The hurd-i386 architecture has been moved to to debian-ports yesterday.
I hope it shows the willingness to do that. Please give us at least 4
more weeks to do the remaining kfreebsd-*. That will provide some margin
to account for the non-infinite free time to work on that (especially in
the freeze period) and possibly to get more disk space for the
debian-ports machine.


Thats ok, end of May is a nice point to take.

Thanks for the work and the timeframe for the rest!

--
bye, Joerg

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

[Joerg Jaspert]

On 15371 March 1977, Aurelien Jarno wrote:


How is the move to debian-ports supposed to happen? I won't have the
time to do anything about it within the 2 weeks.



The process to inject all packages to debian-ports is to get all the
deb, udeb and buildinfo files from the archives (main and debug) and
associate them with the .changes files that are hosted on coccia. We'll
also need to fetch all the associated GPG keys used to sign the changes
files. Then we can inject that in the debian-ports archive.



It would be nice to have a bit more than 2 weeks to do all of that.


Ok. How much? Is 6 or 8 weeks better? I don't think, given how long this
is on the table already, it doesn't make much difference if its 2 or 8.
Just something thats clear defined and not some random, non-clear
"sometime in the future" point.

--
bye, Joerg

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

[Joerg Jaspert]

On 15371 March 1977, Samuel Thibault wrote:


> It seems to exist there, so probably someone who can upload there and
> is interested in hurd-i386 goes and uploads stuff.
Within a two-week timeframe only?

(while everybody is supposed to be busy fixing RC bugs)


I just jumped over old threads - its not actually a new thing what we
discuss now. Its always the same. This next release. Just this one thing
over there, then.

Now, hurd does have double usage (ftp-master and ports) for *years*. And
it never ever moved despite knowing that we want it off.

I don't believe that anything changes just because we wait again.

Also, note, that it is a team decision, not me alone, I am just the
messenger. If you want us to change it, mail the team with the reasons,
and we at least discuss it again. No guarantees on outcome.

--
bye, Joerg

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

[Joerg Jaspert]

On 15370 March 1977, Samuel Thibault wrote:


Today we had our regular FTPMaster meeting and discussed hurd and both
kfreebsd architecture and decided to remove them from unstable and
experimental 2 weeks from now.

Just before the Buster release? That's far from the easiest timing.


There is never an easy timing.

[...]

within the coming two-three months (I am already struggling to find time
to do what I engaged to). Basically, it means no non-official release of
Debian Hurd along Buster. Or at best I could just make that non-official
release now, with all the still pending RC bugs.


It all depending on the amount of people the above shows (one) is one
good reason why its not viable.


How is the move to debian-ports supposed to happen? I won't have the
time to do anything about it within the 2 weeks.


I honestly wonder if it really needs to be anywhere. It itself doesn't
seem to have many developers, probably less users, and heck, last
upstream kernel seems to be from 2016. While it sure has some nice ideas
and concepts in it somewhere, it doesn't seem to go anywhere, at all.
Not just in Debian, but anywhere.

But then, I am not involved in Debian Ports. So no idea. It seems to
exist there, so probably someone who can upload there and is interested
in hurd-i386 goes and uploads stuff.

--
bye, Joerg

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

[Joerg Jaspert]

Hi

back in August 2018 we discussed architecture inclusion into
unstable/experimental.

Today we had our regular FTPMaster meeting and discussed hurd and both
kfreebsd architecture and decided to remove them from unstable and
experimental 2 weeks from now.

--
bye, Joerg
The sun? That’s the hottest place on Earth.


signature.asc
Description: PGP signature

Re: Removal of 'Valid-Until' tag in archived jessie-backports

[Joerg Jaspert]

On 15360 March 1977, Thomas Walker wrote:


Hi, I've noticed that previous release's backports have the
'Valid-Until' tag removed when they are moved to archive.debian.org
but that seems to have not happened with 'jessie-backports' (which has
a 'Valid-Until' that is well past expiration). I fully understand that
backports are not considered part of the lts support, but leaving them
marked as forever expired seems a break from past practice. Could the
'Valid-Until' field please be removed from the archived
'jesie-backports'?


No they don't. At archive time stuff only gets copied over to the
archive, nothing gets changed.

And no, I won't remove those lines. Their whole reason is to break apt
when they expire, it would be wrong to unbreak it. Users who still want
to use it can override it in apt config.

--
bye, Joerg

Re: Removal of Wheezy and Jessie (except LTS) from mirrors

[Joerg Jaspert]

On 15353 March 1977, Hideki Yamane wrote:


The data is, of course, not lost - the whole of it is synced
to archive.debian.org, so if you still need it you will be able to get
it from there.[1]

 Some vendors asks their users to use archive.d.o but maybe archive.d.o
 doesn't have enough resource to deal with I'm afraid.
 https://discuss.circleci.com/t/apt-get-update-return-404/29237/3


Except for the LTS part of jessie, none of wheezy/jessie should be used
anymore, its out of security support.

--
bye, Joerg

Re: Removal of Wheezy and Jessie (except LTS) from mirrors

[Joerg Jaspert]

On 15348 March 1977, Thorsten Glaser wrote:


It would be great if the last state of LTS, ideally with a signature
that does not expire for a couple of years¹, were available from
archive.d.o as well.


Right. I am going to import the wheezy lts foo later into
archive.debian.org (into the security part of it). Until then its fine
to keep using it from security.d.o, we are not currently removing from
there.

No, i am not going to fiddle with the valid-until, same as we not do it
fo any of the other suites we import to archive. They are meant to run
out. We simply do not support those releases anymore.

--
bye, Joerg

Re: Removal of Wheezy and Jessie (except LTS) from mirrors

[Joerg Jaspert]

On 15347 March 1977, Thorsten Glaser wrote:


deb http://archive.debian.org/debian wheezy main
deb http://archive.debian.org/debian-security wheezy/updates main
deb http://archive.debian.org/debian wheezy-updates main
deb http://archive.debian.org/debian wheezy-backports main
… out of which the second and third line don’t work.



Looking manually, http://archive.debian.org/debian-security/dists/
misses anything past lenny, http://archive.debian.org/debian/dists/
similarily does not have any updates.



Were the wheezy/updates and wheezy-updates merged into just wheezy
as last step before archiving, so that those two lines can just be
dropped?


Yes, it is common that the last point release, just at end of life time,
takes in what was in those suites at that time.

--
bye, Joerg

Re: Collaborative decision making with Loomio

[Joerg Jaspert]

On 15111 March 1977, Dmitry Smirnov wrote:
>> You can't solve a social problem using technical means.
> I do not share your skepticism. We can benefit from imposing some structure 
> and there is nothing wrong about exploring options to _improve_ the process 
> while not necessarily aiming at solving social problem. What problem by the 
> way?

There is no benefit if we split up discussions to just another medium.
Unless you propose to close the mailinglist, all that happens is that
there is one more place to rehash the same arguments all over.

> Saying "people are the problem" is too harsh as you are basically giving up 
> already, if not worse.

No its not. Its reality.

> Disagreements are good. In unhealthy environment there may be no 
> disagreements because either nobody have opinions to contribute or no guts to 
> speak up. Disagreements allow to explore problems from many sides and produce 
> deeper understanding.

Disagreements are good. As long as all sides are able *and* willing to
find a consensus somewhere in the middle. And stop discussion.

> I'd say let's try the tool and see if it works for us. In process of
> trying we may find some inspirations regardless of the outcome.

Feel free to setup something. Maybe it even gets us something. *I* doubt
it.

-- 
bye, Joerg

Re: Collaborative decision making with Loomio

[Joerg Jaspert]

On 15111 March 1977, Dmitry Smirnov wrote:

> Loomio [1] is a powerful tool to organize decision making. We have a long 
> standing RFP [2] for Loomio and I hope that with help of Ruby team it can be 
> packaged without too much effort.

It is not the tool here that is the problem. It is the people involved
that are. No matter being on a mailing list or loomio or
whatevermagictool, as long as people are unwilling to accept the other
sides and willing to find consensus, you can throw tools around as much
as you want. You wont get anywhere.

Or simply put:

You can't solve a social problem using technical means.

-- 
bye, Joerg

Re: Should the weboob package stay in Debian?

[Joerg Jaspert]

On 15109 March 1977, Adam Borowski wrote:

>> It is covered.  We explicitly list a number of things that we consider to be
>> of higher priority than arbitrary compatibility with third parties (free
>> software; our users' needs; creating a developer community that is welcoming
>> to all people, instead of one that mirrors a wider culture which
>> discriminates against people based on their identity).
> If you put technical needs below religious ones (and this particular
> religion is especially vile), something is really wrong.  Debian is supposed
> to be inclusive for all users.  Working software is much more important than
> hurt feelings -- especially if you care about feelings of only a single
> group.

> The diversity statement we approved explicitely welcomes participation by
> everyone, and (by my reading) implicitly bans censorship.  You're trying to
> promote censorship, and that I protest against.

Please read
https://blog.valerieaurora.org/2017/08/15/what-white-supremacists-dont-want-you-to-know-the-paradox-of-tolerance/
and apply it here. It has a slightly different topic ( (In)tolerance ),
but most of it fits pretty damn well the point of inclusive or not.

Working software is not neccessarily much more important than hurt
feelings. Not if hurt feelings make us a worse place to be. And, unless
its "hurt feelings" of intolerant nazis[1], it doesn't matter if it's only
a single group or not. They are important. And hey, its not a just a
random group of 5 - its about half of humanity (and way to less of em as
members of our community)...

Now, can we all please stop being ridiculous and stop this thread?
Anyone who disagrees with the maintainers decision can either ignore it
or appeal to a higher body (FTPMaster, GR). More discussion won't make
it any better. Especially not as nearly all people discussing the matter
are mysteriously missing the body pieces so prominently featured in that
little-kid-selected-names of binaries.


[1] The one set of people valid to be excluded everywhere, no further
question asked. Stupid shitheads.

-- 
bye, Joerg

Re: Should the weboob package stay in Debian?

[Joerg Jaspert]

On 15102 March 1977, Marc Dequènes (duck) wrote:

> It has been brought to my attention that this package, its name and
> the name of the binaries and further content was deemed offensive.
> This was already raised in the past (~2012 IIRC) but the package was
> reintroduced and has been in the archive since then.

Back then it was one tool of many in this, mainly, that was drawing bad
attention.

> This thread is about giving your opinion and discussing with upstream
> about it, and us DD to decide the fate of this package. I hope this
> would help draft proper policy criteria about what we consider not
> acceptable.
> May I dare to hope we would discuss this is a civilized manner?

It won't work. Also, this being my only mail in this thread (and none
ever in the other).

This will draw attention, and unfortunately it most likely will draw
attention of the wrong type of people.

I'm sure there is stuff in this package is offending to some. In names
of binaries and possibly in comments of code. I'm sure it is completly
pointless to have that stuff in, and that it would still be great tools
without those childish things.

Now, if upstream would think so too, it wouldn't be there. I highly
doubt it will all be cleaned up, no matter how long this thread.

Remove it then? One possibility. But then, where do we stop? This weboob
thingie is actually a tiny little "wannabe-bad" package only. The
archive has far worse contents. Do we remove them all to get to a nice
clean safe-for(whats the goal? Kids? Sensitive person of [fill in
something]?) archive? Which standard do we apply? Ultra-left? Right?
Conservative Christian? Islamic? Orthodox? Jewish? Gay? Homophobic? One
of those many that I missed? All of them together, because our community
possibly contains members of most, if not all of those, so lets keep
only what all can agree on? Thats a tiny subset.

Don't get me wrong, I'm not saying we can never remove things. And that
we have to accept everything. But we are so big a community, being
offending to a part of us - is a property a lot of packages will have.
:/ Whats the right criteria to apply - independent of this one package
here?

-- 
bye, Joerg

Re: uploaded but not processed

[Joerg Jaspert]

On 15029 March 1977, Mattia Rizzolo wrote:
> The upload will stay in the queue forever until either the key becomes
> trusted again and so it can be processed (e.g. you push an update the
> the keyring maintainers push it to the live keyring) or an ftp-master
> manually moves it out of the way.

Moved them out of the queue.

-- 
bye, Joerg

Re: salsa editor omits \n at end of file

[Joerg Jaspert]

On 14991 March 1977, Guus Sliepen wrote:
>> Knowing that I will now just go and add an extra empty line at the bottom of
>> the text/source code files edited, but, well, maybe there is a bit more
>> UNIXish solution to that?
> The best solution is to fix salsa.

Its not "salsa" nor "salsa editor", its gitlab and its webbased editor. 
(nitpick,
but salsa is only our instance name).

And the best way to get that fixed is to file an issue upstream with
gitlab.

-- 
bye, Joerg

Re: New lintian warning: vcs-deprecated-in-debian-infrastructure

[Joerg Jaspert]

On 14986 March 1977, Ole Streicher wrote:

>  which IMO proves that a sophisticated "layout" with namespaces or
> subdirs is a bad idea for canonical URLs.
> Why can't we have a flat name space with redirection
> https://git.debian.org/
> (or similar) that just redirects to the proper real location within salsa?
> Our source package names are unique, so there should be no conflicts.

Thats called packages.debian.org in combination with the vcs urls and
exists for a long time. It can be argued that the way of updating the
vcs urls stuff ought to be different, but the above wish already exists.

> That would make the discovery of a certain package *much* easier than
> the current structured approach.

packages.d.o/packagename and you are there. Nothing else needed.
Even independent of the underlying vcs, not hardcoded to git or one
provider of hosting it.

-- 
bye, Joerg

Re: New lintian warning: vcs-deprecated-in-debian-infrastructure

[Joerg Jaspert]

On 14984 March 1977, Jonas Smedegaard wrote:

>> That was announced several times and it will not reside. 
> Why? Lack of volunteers maintaining a redirector, or new service 
> incompatible with indirections, or?

Multiple things, and it ended up a decision we took at the meeting in
Hamburg.

First off we (the salsa admins) would have liked to take over the
hostname. But then we discussed and thought through it. What would it
get us? A host of problems and not much gain actually. It sounds simple
"Hey the host is same, no need to change packages" - but that is not
true. Gitlab is very different in its layout and handling of things than
old alioth.

Before you come "Well, apache redirect map", think of it. We have that
right now already. Actually twice. There is one map on alioth itself,
trying to map old stuff into cgit, and there is the new alioth
redirector mapping migrated stuff to alioth. Now what, that only does a
small subset of requests, http. Not git. (Not ssh). And it needs manual
action for each and every migrated package...

Very much not optimal. And the cgit one, while being there for a long
time, still does not work for all cases, is a mess, declared as
"unmaintainable" by its maintainer.

So redirecting is a bad way, its hard to maintain and only does it for a
subset of the needed pieces. The redirector WILL go away in the not-too
distant future, it is a hacky interims solution.

So, moving the hostname. Could have done that. When? How about

"Here is salsa, its all new gitlab, entirely different to alioth, btw,
anonscm moved over, if you didn't migrate your repos yet, you won't see
them on anonscm anymore"?

Or would

"Here is salsa, its all new gitlab, entirely different to alioth, btw,
in half a year, anonscm moves over, if you migrate your repos before,
you won't see them on anonscm until then"

be better?

And both leave out that part of "And hey, the whole entirely different
to alioth means its a new url, please immediately update your packages
vcs-whatever entries for it", which means an upload anyways..


So that got us to "It would be nice. It does not work usefully. -> It
won't happen". And basically you can expect another hostname change to
happen *AGAIN* in the future, should we switch from gitlab to
whatever-is-good-then, UNLESS that hypothetical thing is about identical
on the whole layout. THEN one can do a "switchover day is X, all repos
and groups and whatnot will be forcefully migrated then, no user action
needed".

-- 
bye, Joerg

Re: Updated proposal for improving the FTP NEW process

[Joerg Jaspert]

On 14969 March 1977, Gert Wollny wrote:

> Sure thing, I'll give it a try. Since I'm not familiar with the dak
> code, would you be so kind to point me to the functions and variables
> (if available) that are there to 
>   - extract or hold the bugs listed in the last changelog entry,
>   - query the BTS (to be able to get the header and see whether 
> it's a ITP) (if this is not available I can get that probably 
> from bugreport)
>   - where you compose the final email (to add the bug in the CC).

Your starting point is process-new.py

-- 
bye, Joerg

Re: Updated proposal for improving the FTP NEW process

[Joerg Jaspert]

On 14967 March 1977, Gert Wollny wrote:

I so like proposals from people who have never ever done any of the work
they propose something one. BUt hey...

> (1) Given that all new source package come with an ITP bug, when a
> package must be rejected, the FTP team could CC this bug in the
> rejection message. This would have the advantage that for everyone
> interested in the package the information why the package was rejected
> can easily be found. In addition, For large packages, where a review
> takes more than one day, the reviewer could send messages to the ITP
> about problems the moment they are found, so maintainers could start to
> work on correcting the errors earlier.

If someone comes up with a patch to process-new which does this in a
halfway reliable way, it doesn't need a long time wasting thread on
devel to get it.

> (2) To improve the initial quality of uploads to NEW I also propose the
> introduction a (voluntary) review step: Someone who is interested in
> getting additional reviews to a package before uploading it to NEW
> could file a "Request for review" (RFR) bug against wnpp. Then those
> who are willing to review packages can step in and also have a common
> place to comment on problems of the package that need fixing. When
> someone satisfied with the package they add a comment to the bug
> "Reviewed-By: name ", and when doing the actual upload, the
> maintainer replicates these R-B messages in the changelog closing the
> RFR bug. For large packages one might also add a comment "subir/module
> X Reviewed-By: ..." to indicate only a partial review.
> This R-B- information could also be added to that persons QA page under
> a new section "Reviewed Uploads".

> In a way this replicates what sponsors do for uploads of non-DDs, but
> especially for large packages a second pair of eyes is always helpful.

And that is thankfully something everyone can just do (ask your peers
for review). And is something that got proposed tons of times. Never see
anything come from it.

> Implementing the first point is essentially up the the FTP team.

No its not, its up to the ones that want it to patch dak process-new.
That is, parsing the bug-close list (if any), finding out if thats
really an ITP, and if so, CC it on rejection/prod.
Note that this has to be automatic, if it requires us to enter anything,
it is doomed to fail.

-- 
bye, Joerg

Re: [Pkg-javascript-devel] three.js_80+dfsg2-2_amd64.changes REJECTED

[Joerg Jaspert]

On 14963 March 1977, Pirate Praveen wrote:

>> I wonder why you think "a single ftpmaster". We are a team. We closely
>> coordinate what we do and how we do it. When one of us rejects, the team
>> rejects - it just happens to be a random one of us doing it. Others do
>> not need to get involved and review everything. Or we wouldn't ever be
>> able to get anything done if each of us always has to weight in on any
>> single issue.
> Thanks for the clarification. I was thinking about it more like how the
> courts work in India (possibly in other countries too). When a single
> judge decides on a case, there is always an option to appeal to larger
> bench (more number of judges).

Right.

> The team as a whole has to weigh in only when the decision of a single
> team member is challenged and such a review is requested.

> I don't think it is healthy to not have an option of reviewing
> individual members decisions.
>
> That leaves me only GR as a possible escalation route. I will think
> about it.

And no, I didnt say one can not ever challenge a reject, although one
can put that meaning in my words, sorry for that. Quite the contrary,
despite other rumours, we are all just humans, and humans make mistakes.
And we are open to be told about such and do admit them, and yes, that
does happen.

But if you continously "run into the same wall", then it does not do any
good to assume its that one person hating you and that, if you happen to
get to another team member, they will like you. It's the wrong mindset.

Also, possibly we should adjust our communications here, at least get
others to respond/jump in (earlier). Not sure we need it so much formal
as Ian wrote down, but get someone else in early shouldn't hurt.

-- 
bye, Joerg

Re: [Pkg-javascript-devel] three.js_80+dfsg2-2_amd64.changes REJECTED

[Joerg Jaspert]

On 14963 March 1977, Pirate Praveen wrote:

> 1. If a single ftp master is in disagreement, there should be a team
> decision (in previous cases of disagreement also, other team members did
> not get involved).

I wonder why you think "a single ftpmaster". We are a team. We closely
coordinate what we do and how we do it. When one of us rejects, the team
rejects - it just happens to be a random one of us doing it. Others do
not need to get involved and review everything. Or we wouldn't ever be
able to get anything done if each of us always has to weight in on any
single issue.

-- 
bye, Joerg

Re: Extended Long Term Support for Wheezy

[Joerg Jaspert]

On 14954 March 1977, Raphael Hertzog wrote:

> - for ftpmasters, can we keep wheezy/updates on security.debian.org for
>   one year more?  (it might be possible to archive wheezy and drop it from
>   the main mirror, that would be a clear sign to everybody that something
>   important changed, and we could reconfigure the buildd to use another
>   repository)

No.

> - are there other problems related to this extended LTS that need to be
>   discussed?

If this would be "just" extending the current LTS ways for more time,
then it would be OKish to stay on donated, voluntarily managed,
infrastructure. After all it helps all users of wheezy with updates,
nominally over all of wheezy.

But the proposal is effectively just for a benefit of a few paying
customers, with a very selected set of packages and architectures, all
the rest lost out. Thats not ok to ask volunteers to support, nor
is it ok to use projects infrastructure for. The companies that want it,
should run it.

-- 
bye, Joerg

Re: FTBFS with parallel make

[Joerg Jaspert]

On 14929 March 1977, Philipp Hahn wrote:
> we (Univention GmbH) rebuild packages (from Debian-Jessie or newer)
> using "-j8". Several builds failed, but work when I use "-j1":

> With all the reproducible build stuff going on, I think it would be nice
> if someone™ can also donate CPU time to check that -j`nproc` works.

Very well volunteered, you are running the builds already, so go the
next step and submit bugs and patches based on them. Not very useful for
others to waste time in doing the thing you already run.

-- 
bye, Joerg

Re: Marking bugs as pending for salsa.d.o

[Joerg Jaspert]

On 14907 March 1977, Byung-Hee HWANG "(황병희, 黃炳熙)" wrote:

>  Joerg Jaspert <jo...@debian.org> writes:
>> I'm on it, code lives in https://salsa.debian.org/salsa/webhook
> Your code looks so beautiful, i am a fan for Ruby. 

No idea which code you have been reading, are you sure it was mine?

> So we should study Ruby very hard? For use Salsa.

Only if you want to directly contribute to this. Which is a general
thing. Anyone can write some spethial-for-them webhook and then can use
whichever language they want. We stick with ruby as gitlab is ruby and
so we do not get too much into the mix we have to maintain.

-- 
bye, Joerg

Re: Marking bugs as pending for salsa.d.o

[Joerg Jaspert]

On 14907 March 1977, Rafael Laboissière wrote:
> In the Git repositories of packages that I maintain at alioth.d.o, a
> script [*] is called in the post-receive hook for tagging the bugs
> listed in the meta tag "Closes:" of gbp-dch as "pending".

> Is there a way to have a similar integration service for the Git
> repositories at salsa.d.o?

I'm on it, code lives in https://salsa.debian.org/salsa/webhook

Feel free to open issues or merge requests with additions of stuff we
ought to have too, right now it supports close/tagpending. I've got some
local changes not yet pushed, to check (via soap using ruby-soap4r) if a
bug is open or not, before tagging it pending, will commit em later.

Usage will be a simple webhook you configure for your repository.

In case people want to send patches:
https://docs.gitlab.com/ce/user/project/integrations/webhooks.html is
the upstream doc on what we get (loadsa data in json) and which events
it can run on (many).

One constraint: It will run separate and will have *NO* access
whatsoever to the actual git repository (to parse files or stuff),
everything we have is either in the JSON OR hardcoded via url parameter
(say, source package name).

More docs to come on wiki for salsa when it goes live.

-- 
bye, Joerg

Re: salsa.debian.org (git.debian.org replacement) going into beta

[Joerg Jaspert]

On 14899 March 1977, Philip Rinn wrote:

> Is it true (and intended) that -guest users can't create projects within
> teams/groups they are member of? Or am I missing something? [I was not able to
> create a project within the Debian Science Team]

Those rights depend on the access level you have been given inside that 
project/group.


-- 
bye, Joerg

Re: Proposed change of offensive packages to -offensive

[Joerg Jaspert]

On 14864 March 1977, Iain R. Learmonth wrote:
> This option is defined in the source code as "Define to 1 to replace
> politically incorrect insults with less offensive ones." and so by not
> defining this option, the package is explicitly built to be offensive.
> Obviously we should allow for a transitional package here...

Pretty much overkill - and for sudo you actively need to turn on insults
before it spits out any.

-- 
bye, Joerg

Re: ftp master uploads disappearing?

[Joerg Jaspert]

On 14812 March 1977, Attila Szalay wrote:
> For me, the uploaded package was disappeared when I accidentally used a
> wrong gpg kez to sign it. It was also mine, just an old, 1024 bit long one.
> In that case I received nothing back about the upload.

That works as designed.

As the upload queue is a place anyone can upload to, we only send mails
after we successfully checked the signature against a current key in the
keyring. If that step fails, no mail will ever get out.

Thats not the most userfriendly one, if you have trouble with your key,
but its the safest option to not make us spam random people for some
forged .changes.

-- 
bye, Joerg

Re: salsa.debian.net

[Joerg Jaspert]

On 14771 March 1977, Florian Weimer wrote:
> I received some key SSH import notices from salsa.debian.net, but I
> didn't request anything.

> Is this harmless, or is something fishy going on?

Harmless, sorry.

Salvatore guessed right, and the mails had been a mistake at that point.

-- 
bye, Joerg

Re: Call for volunteers: FTP Team

[Joerg Jaspert]

On 14768 March 1977, Philip Hands wrote:
>> ...Well, in keeping with the Toy Story theme, FTW Masters is
>> worshipped by the Squeezes (packages alien to the archive) and at the
>> time of a "Win" a package new to the archive is selected as for the
>> "World".  Finally, New Maintainers tremble with trepidation at the
>> power of The Claw, as it is known internally.
> I like "The Claw" -- responsible for picking up NEW packages, and giving
> them to the kids, or dropping them.

Don't you all have something more important to do?

-- 
bye, Joerg

Re: Call for volunteers: FTP Team

[Joerg Jaspert]

On 14767 March 1977, Jonathan Carter wrote:
>> it has been quite a while since the last call for volunteers, so here is
>> an update: Yeah, we still need people, and we want you. Well, that is,
>> if you are a Debian Developer, for this. If you are not and want to
>> help, read the last paragraph please.
> If someone hypothetically joins, are they allowed to rename the FTP team
> to something that doesn't include "FTP"?

GopherTeam?

-- 
bye, Joerg

Call for volunteers: FTP Team

[Joerg Jaspert]

Hello Debian world,

it has been quite a while since the last call for volunteers, so here is
an update: Yeah, we still need people, and we want you. Well, that is,
if you are a Debian Developer, for this. If you are not and want to
help, read the last paragraph please.


Ever felt compelled to do the hard groundwork? Ever wanted to help at a
nicely central place inside Debian? Or just want to write some Python
code and still look for a good place to stick it in?

Here we are. Come join the Nav^Wteam. Just sign over there to the right,
or even easier, mail us. We won't bite you, thats for sure. At least not
right away. :)

The criteria are the same as always: You need to be a DD (except for
coding only, though it helps to know the usual flow of a package) and
you need to be able to deal with the existing team members.

An occasional flame should also not disturb you, if you are working in
the NEW queue you will stand between the people uploading and the
packages entering the archive, rejecting something is not always liked
much. (But you often get positive replies and thanks, to keep your
spirits up :) ).

And - if you get headaches when reading legal texts - we all do. But it
is needed and things like NEW are mainly about that, the ftpteam is
*the* one place to decide if something is ok for Debian to distribute or
not, and you will have to take this decision. (Yes, there is more, but
this is the main point you are going to check).

Obviously the other points we made in earlier mails, like [1], still
apply too.



Another good way helping the ftpteam is - by not joining us! Yvan eht
Nioj! (Or for people not watching Simpsons: Join the Navy!)
Err, no, of course not, but: Join the QA team!
There is a lot of work commonly associated to the QA group but not many
people doing it. You could help out there, which in turn will help us
again.


[1] http://lists.debian.org/debian-devel-announce/2010/03/msg3.html

Stay tuned for more news coming from the team soon.

-- 
bye, Joerg
You tried your best and failed miserably. The lesson is: never try.

Re: OpenSSL disables TLS 1.0 and 1.1

[Joerg Jaspert]

On 14757 March 1977, Kurt Roeckx wrote:

> I've just uploaded a version of OpenSSL to unstable that disables
> the TLS 1.0 and 1.1 protocol. This currently leaves TLS 1.2 as the
> only supported SSL/TLS protocol version.

Thats nice for any environment where on can freely define that
everything works like this.

Unfortunately real world doesnt work like it.

> This will likely break certain things that for whatever reason
> still don't support TLS 1.2. I strongly suggest that if it's not
> supported that you add support for it, or get the other side to
> add support for it.

In many cases this isnt possible.

> OpenSSL made a release 5 years ago that supported TLS 1.2. The
> current support of the server side seems to be around 90%. I hope
> that by the time Buster releases the support for TLS 1.2 will be
> high enough that I don't need to enable them again.

I wonder if there is a middle way that ensures that all new stuff does
go TLS1.2 (or later, whenever), but does allow older stuff still to
work. Which isnt the case if they are just disabled.

-- 
bye, Joerg

Re: Database of all (historic) package versions - dak?

[Joerg Jaspert]

On 14640 March 1977, Philipp Hahn wrote:
> I guess  would work, but I'm denied
> login permission on "mirror.ftp-master.debian.org".

Projectb does noit have what you want.

-- 
bye, Joerg

Re: "Ask HN: What do you want to see in Ubuntu 17.10?"

[Joerg Jaspert]

On 14635 March 1977, Nikolaus Rath wrote:

> Maybe I'm just exceedingly unlucky, but I have yet to find a laptop
> where all of the following works:
> - Suspend
> - Hibernate
> - Airplane-mode Hotkey (especially hard apparently)
> - Volume Hotkeys
> - Brightness Hotkeys
> - Suspend/hibernate hotkeys
> - Hot-plug of external monitor

I'm pretty happy with my Tuxedo (tuxedocomputers.com) XC17xx. Those are
based on Clevo BareBones which you can find at multiple notebook
sellers (Sanger is a pretty well known one too).

Tuxedo gets them to you with a Linux preinstalled and though thats a
Ubuntu thingie, they offer the script they use for their extra settings
as well as extra .debs for stuff they put on, so its easy to take over
settings and throw away the preinstalled stuff.

With that all of the above works without problems here, even me
regularly switching between Laptop Display only, one external and two
external Displays attached (autorandr a nice tool here).

-- 
bye, Joerg

Re: "RoQA" RM bugs

[Joerg Jaspert]

> we have human ftpmasters

You sure? When did u last check? How thouroughly?



Not good enough, I'm sure.

-- 
bye, Joerg

Re: alias type forwarders WAS: SPAM

[Joerg Jaspert]

On 14603 March 1977, Geert Stappers wrote:

>> The debian lists work. Alioth currently wouldn't, I think, but software
>> could be upgraded.
>> It has a different problem which is way worse: It breaks usual alias
>> type forwarders, which are used *a lot* within Debian.
> What are the ideas about changing those aliases into something
> that wouldn't break by SPF, DKIM and such?

I'm not a member of DSA, and as they run the mail servers, its their
call. From what I know of their opinions[1], not likely to happen.

[1] personal, I don't think the team has formed a team one yet. Again,
I'm not a member of it.

-- 
bye, Joerg

Re: SPAM

[Joerg Jaspert]

On 14602 March 1977, Vincent Danjean wrote:
>> That would be the next step, DMARC, which is SPF plus DKIM plus some
>> extra DNS records. And DMARC then allow to tell other mail servers (that
>> follow DMARC) to get rid (spamfilter) mail that aren't from what your
>> DNS says it should be from (or aren't signed correctly/at all). But its
>> even more maintenance and burden for a group like Debian.
> Is it even possible?

Yes.

> I was under the impression that DMARC plays very bad with mailing
> lists. If I recall correctly, mailman has to modify mails that come
> from a DMARC domain.

The debian lists work. Alioth currently wouldn't, I think, but software
could be upgraded.

It has a different problem which is way worse: It breaks usual alias
type forwarders, which are used *a lot* within Debian.

-- 
bye, Joerg

Re: SPAM

[Joerg Jaspert]

On 14602 March 1977, Philip Hands wrote:

> I guess we could help the mail servers of the recipients of the initial
> messages make that decision if we did SPF for debian.org, but I guess
> that the lack of SPF probably indicates that this is very hard to do
> with our distributed setup.

With the current setup that allows every DD to use their @debian.org
from any random server they have access to, it is impossible.

Debian (DSA) would need to offer an outgoing SMTP relay and we would
need to force everyone to use that for any mail with an @debian.org
address, and then you can enter them in the SPF record.

Thats a lot of ongoing maintenance work added for an unclear benefit:
SPF is a mixed thing. Some mail operators even take the existance of an
SPF header to score mail HIGHER, not lower.

And it doesn't really stop mail appearing from other hosts.

That would be the next step, DMARC, which is SPF plus DKIM plus some
extra DNS records. And DMARC then allow to tell other mail servers (that
follow DMARC) to get rid (spamfilter) mail that aren't from what your
DNS says it should be from (or aren't signed correctly/at all). But its
even more maintenance and burden for a group like Debian.

-- 
bye, Joerg

Re: Can we kill net-tools, please?

[Joerg Jaspert]

On 14533 March 1977, Marco d'Itri wrote:

dak override net-tools net optional
I: Will change priority from important to optional
Continue (y/N)? y

dak override iproute2
iproute2 is in section 'net' at priority 'important'

Whoever wants net-tools can have it by simply installing it - or getting
it by one of its rev-deps/recommends, which isn't a short list either.

-- 
bye, Joerg

Re: Thanks to ftpmasters for being so responsive

[Joerg Jaspert]

On 14534 March 1977, Ian Jackson wrote:
>> If everybody agrees that
>>   - new versions of packages shall be only uploaded to experimental
>>   - uploads to testing will only be done on request of the RT or with
>> really new packages
>>   - everything else can be rejected
>> processing would be much easier and the fun could go on.
> Certainly I wouldn't upload an update to sid that I didn't intend for
> what-is-currently-testing, even during the deep freeze.

s/testing/unstable/ in the second point uo there.

Thats what common sense says. Thats not what happened. Will be
interesting to see what happens this time.

(Also note that *entirely* NEW things aren't affected, as they aren't
considered for migration anyways).


-- 
bye, Joerg

Re: Crowd funding campaign to package browserify in debian

[Joerg Jaspert]

On 14530 March 1977, Pirate Praveen wrote:
>> While its good (for someone) that this work is done, and hooray if it
>> can be sponsored by crowdfunding, I dont think that this list is the
>> proper place for it.

> 2. I think -devel is right place for discussing a problem that goes
> beyond a single team and was already discussed here many times.

For any problem, yes. For fundraising, no.

-- 
bye, Joerg

Re: Crowd funding campaign to package browserify in debian

[Joerg Jaspert]

On 14529 March 1977, Pirate Praveen wrote:
>> We are onto our second round of crowd funding
>> https://www.generosity.com/community-fundraising/debian-browserify-2
> gulp is now accepted in main. If we get more support for the campaign,
> we hope to continue packaging more nodejs build tools (next target is
> rollup and babel-cli). If you like the work we re doing, please support
> the campaign.

While its good (for someone) that this work is done, and hooray if it
can be sponsored by crowdfunding, I dont think that this list is the
proper place for it.

-- 
bye, Joerg

Re: which JavaScript dependencies really need a separate package?

[Joerg Jaspert]

On 14526 March 1977, Daniel Pocock wrote:

> - For those JavaScript libs that have complicated build systems that are
> not (yet) supported on Debian, is it reasonable for a package like
> homer-ui to simply include the intermediate product of the build, just
> before it is minified, into the Debian source package?  This may not be
> the "preferred form of modification", but it is not difficult to make
> modifications to it.

Thats simple to answer by reading
https://lists.debian.org/debian-ctte/2016/10/msg00066.html

What you proposed is not source (first point), so has no place in main.
You may be able to follow the second point.

> - The FTP masters have also expressed concern about the standalone
> packaging of very small[3] JavaScript dependencies.  Is that still the
> same for stretch and beyond?

Small packages are bad. Sometimes they may make sense, sometimes another
environment sucks really bad and the best way for us is to deal with it.

-- 
bye, Joerg

Re: Release impact of introducing a new archive section?

[Joerg Jaspert]

On 14518 March 1977, Josh Triplett wrote:
>> (my first thought was a canonical online location, but these tools may
>> not want that at runtime and can't rely on it at build time, but maybe
>> that should be the source used for the package)
> Packaging this data (section names, short descriptions, and long
> descriptions) seems like a great idea.  Ideally, packages would have a
> Depends on this and use the data at runtime, rather than using a
> Build-Depends and compiling it in.  With some care, such a package could
> also serve as the basis for the descriptions on packages.debian.org.

Does it need a package? Or just a file in the archive somewhere?

-- 
bye, Joerg

Re: Release impact of introducing a new archive section?

[Joerg Jaspert]

On 14516 March 1977, Josh Triplett wrote:
> I've now written and submitted all of these patches.

Thanks!

Lets give it some time for them to get into packages and then we add
sections. Please ping again, so it doesnt get forgotten.

-- 
bye, Joerg

Re: Release impact of introducing a new archive section?

[Joerg Jaspert]

On 14515 March 1977, Josh Triplett wrote:
>> while at it, please also add a section for golang package, we have over
>> 500 in the archive already:
> I don't see any bug filed on ftp.debian.org requesting such a section.
> Could you please do so, with a short and long description of the new
> section?  (You should also get an ack from an ftpmaster.)

> I don't have any objection to adding such a section, but I'm already
> halfway through the patches to add the "rust" and "javascript" sections.

> The following might work as a description for such a section; feel free
> to copyedit:
>
> Go programming language, libraries, and development tools
>
> Packages in the "golang" section provide implementations of the Go
> programming language, development tools for Go, and many third-party Go
> libraries.

Ack from me if he files the bug.

-- 
bye, Joerg

Re: Release impact of introducing a new archive section?

[Joerg Jaspert]

On 14515 March 1977, Josh Triplett wrote:
>> Longer version: I think we should patch the tools first and /if/ we are
>> in time before the release, we can add the sections.  To my knowledge,
>> there are basically no ill effects of tools knowing sections that does
>> not yet exist.
> That's a good idea; thank you.  I'll start working on those patches.

While you are in there, there is #816693, also I'm unsure (and offline
atm) how many perl6 packages we currently have.

And maybe to take suggestion from #802488 in mind.

And thanks for the work on it.

-- 
bye, Joerg

Re: Archive changes - indices compression and checksums

[Joerg Jaspert]

On 14490 March 1977, Steve McIntyre wrote:

>>as started in March[1] we have just adjusted unstable to no longer
>>generate gzip compressed Packages/Sources files. We plan to wait about a
>>week before adjusting testing too.
>>Additionally we turned off SHA1 checksums for the (In)Release files for
>>all testing suites.

> I understand the desire to add functionality, but can you explain why
> you're removing the older formats? It's breaking other tools, and I'm
> not convinced there's much benefit...

The SHA1 removal shouldn't break stuff. (We keep MD5 and SHA256, with
MD5 for Jigdo).

The .gz removal still breaks more than anticipated, so they will stay
and get turned off after stretch got stable. Removing them is simply for
space, bandwidth and amount of files reason.

-- 
bye, Joerg

Re: Browserified files and DFSG

[Joerg Jaspert]

On 14490 March 1977, Pirate Praveen wrote:
>> I have referred this to CTTE
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830978
> grunt is now available in main, a big part of this issue is resolved,

Thanks for that work to all who did it.

-- 
bye, Joerg

Re: call for participation - Debian contributors survey, 1st ed.

[Joerg Jaspert]

On 14484 March 1977, Stefano Zacchiroli wrote:
> Participation in the survey is completely anonymous, with no logging of
> any provenance information (e.g., IP address, HTTP referrer), and all
> questions are optional.

No logging or name is needed, with the set of questions in this survey
one only needs a bit of knowledge of Debian and its people to identify a
high amount of the survey takers, I think. (I still took it)

-- 
bye, Joerg

FTP Master move, second try | Upload queue

[Joerg Jaspert]

Hi

first a short announce: Saturday (that is, 29th of October) we give it
another shot of moving the ftp-master host, so expect another bit of
downtime there.

More importantly: With the changes to the upload queues I announced just
yesterday, we turned off ftpd on the ftp-master host. Anyone who has an
upload config snippet trying to upload there - please adjust to
ftp.upload.debian.org!

-- 
bye, Joerg

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[Joerg Jaspert]

On 14466 March 1977, Ondřej Surý wrote:

> to stop you from bickering on and on, the build script can be
> reconstructed
> just from reading gulpfile.js and would consist of installing ruby-sass,
> coffeescript and node-uglify and running:

> #!/bin/sh
> # I absolutely new nothing about gulp, coffeescript, sass and uglify 15
> minutes ago...
> [...]
> If you insist I can add build.sh script to the missing-source, but

No, you do not put it in missing-source foo. You use it during the build
of your package, thats the correct thing to do.

> that's a new information for me that we are now doing distro
> just for hipsters that can't read and write more than one twitter
> message at the time, and can't read a simple makefile.

Silly, you forgot later updates to the package not done by you. There is
no reason why a security team should have to learn the above steps. They
should edit the source and just build the package and that should do the
right thing. Not needing to dig up whatever crap may be needed for
todays hip sillyscript transformation.

-- 
bye, Joerg

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[Joerg Jaspert]

>> On 14458 March 1977, W. Martin Borgert wrote:
>> > If I package a compiler and put y.tab.c in the package, drop
>> > grammar.y in d/m-s/, would it be OK or not?
>> If you come up with a good reason for it, yes. But I doubt you would
>> find one here.
> Let's say I need a special tool to compile it, e.g.
> bison-priscus, and I don't want to package it for Debian?

Seriously, the question in this thread? Where the initial mail is the
answer of the question?

>> > If I don't even check that bison actually can process the file, would
>> > it still be OK?
>> No.
>> You as the maintainer have to guarantee that the file is buildable with
>> tools available in main. You can't if you don't ever check this.
> IIUC, this is exactly the situation of epoch.js in
> knot-resolver-module-http. I assume, it has not been build from
> its original *.coffee sources, because the make tool (gulp) is
> not in Debian. So the package must go into contrib?

Yes, thats what contrib is for. "require stuff outside main to build or
function".

-- 
bye, Joerg

Re: "Browserified" stuff

[Joerg Jaspert]

On 14457 March 1977, Martín Ferrari wrote:

>> It is not useless, and contrib is way different than any random
>> repository out there.
> I am not sure about that. We discourage people from using contrib, and
> don't promise much support. Whereas upstream can offer the latest
> package always.

> This is server software; as a sysadmin, many times I decide which tools
> to use by checking if they are present in debian stable main, and I
> don't think I am alone in that.

Me as admin is fine with stuff in contrib too. (Honestly, as admin even
non-free, though I have to check licenses sometimes there. But as admin
I want a working system and *mostly* don't care from which component it
comes.)

>> The solution is to have the full build environment needed (for
> The solution I am aiming for is to drop all this handlebars nonsense. I
> am currently checking libjs-mustache (handlebars is just a superset of
> it) as it can do most of what handlebars does and it seems to have a
> less braindead toolchain.

Thats also a good way out, yes.

-- 
bye, Joerg
 yes, I'm annoying.

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[Joerg Jaspert]

On 14458 March 1977, W. Martin Borgert wrote:

>> Dunno. It would be great if the line wasn't challenged just to prove a
>> point
> I don't think tincho nor myself want to challenge a line, we
> would like to know where it is :~)

> If I package a compiler and put y.tab.c in the package, drop
> grammar.y in d/m-s/, would it be OK or not?

If you come up with a good reason for it, yes. But I doubt you would
find one here.

> If I don't even check that bison actually can process the file, would
> it still be OK?

No.
You as the maintainer have to guarantee that the file is buildable with
tools available in main. You can't if you don't ever check this.

> There are some packages, that currently have only generated
> JS files without the original sources (not only SASS and
> CoffeeScript, but also large JS libraries, that are bundled from
> many source files), which seems not in line with DFSG.

> No need to eject them from main, however, because maintainers
> can just add the missing sources in the way they like.

If they don't then there sure is a reason to eject it from main.

-- 
bye, Joerg
http://meta.wikimedia.org/wiki/How_to_win_an_argument

Re: "Browserified" stuff

[Joerg Jaspert]

On 14456 March 1977, Martín Ferrari wrote:
> On 09/10/16 23:56, Adam Borowski wrote:
>
>> Another issue is, as mentioned in the TC discussion, the inability to fix
>> any non-trivial security bugs in stable.  I can't quite imagine the Security
>> Team hunting for a specific old version of grunt and all of its extensive
>> dependencies to rebuild the buggy package.  Such state hits the definition
>> of "contrib" exactly, why not actually use it for this purpose?  Demotion of
>> libjs-handlebars would require changing or demoting two more packages:
>> prometheus and kcov, which would be a hassle but not the end of the world.
> Prometheus being in contrib basically means the work I have done for the
> past year is worthless, as users could as well just grab unofficial
> packages from other places. I am not saying this to justify the mess
> with handlebars, I want to find a solution, but putting this in contrib
> or non-free is not an option for me.

It is not useless, and contrib is way different than any random
repository out there.

The solution is to have the full build environment needed (for
prometheus and all its dependencies) in main - or accept that it can't be
done (or is too much work for the amount of people interested in doing
it) and move to contrib. There isn't anything bad or de-valuing in that,
thats simply how it is defined in our policies.

-- 
bye, Joerg
I’m not normally a praying man, but if you’re up there, please save me Superman!

Re: "Browserified" stuff

[Joerg Jaspert]

On 14455 March 1977, Adam Borowski wrote:
> On Sat, Oct 08, 2016 at 10:45:08PM +0200, Joerg Jaspert wrote:
>> we had a discussion inside the FTP Team about the "browserified js"
>> issue. We understand that "browserified" refers to various changes to
>> the original source, from concatenating multiple (local and remotely
>> fetched) files together, arbitary transformations (down to something
>> akin to compilation), minifying and others. Not all "browserification"
>> may necessarily use all of those ways.
> [...]
>> - We acknowledge that it appears to be a big task to provide a proper
>>   "browserification" environment within Debian. Due to the freeze coming
>>   up we would understand the Release Team granting an RC exception for
>>   stretch for such non-sources already in main, with the condition that
>>   this will not extend to another release.
> Could you please suggest some stick to ensure that the condition you mention
> is actually enforced?  I've got an impression that once a RC exception is
> granted, it stays forever, renewed around every freeze.

First of they have to grant it. I have no idea if they do or not, not
having asked them at all.
Second - the enforcing will have to come from us ftpmasters - by
removing the packages at some point, if they don't get fixed.

> Another issue is, as mentioned in the TC discussion, the inability to fix
> any non-trivial security bugs in stable.  I can't quite imagine the Security
> Team hunting for a specific old version of grunt and all of its extensive
> dependencies to rebuild the buggy package.  Such state hits the definition
> of "contrib" exactly, why not actually use it for this purpose?  Demotion of
> libjs-handlebars would require changing or demoting two more packages:
> prometheus and kcov, which would be a hassle but not the end of the world.

I would understand the security team to define them as "not supported
(unless the maintainer does all the work)", and yes, contrib is IMO the
way better place for them.

-- 
bye, Joerg
<_DeadBull_> ohne speicher, tastatur, mouse, pladde, monitor, also nur die
Hardware...

"Browserified" stuff

[Joerg Jaspert]

severity 817092 serious
thanks

Hi

we had a discussion inside the FTP Team about the "browserified js"
issue. We understand that "browserified" refers to various changes to
the original source, from concatenating multiple (local and remotely
fetched) files together, arbitary transformations (down to something
akin to compilation), minifying and others. Not all "browserification"
may necessarily use all of those ways.


- "Browserified", even if it may end up editable by others, is not the
  preferred form of modification as upstream uses, as such it is not
  source.

- "Browserified" files can be shipped in Debian unmodified, same as (for
  example) PDF files from upstream can. But it is the maintainers
  obligation to ensure that they are rebuildable within Debian, so their
  original source must be provided within the source package or be
  reachable via build-dependencies (in case of concatenations). If this
  can not be done (source or tools missing), they either have to be
  removed or the package must move to either contrib or non-free.

- We acknowledge that it appears to be a big task to provide a proper
  "browserification" environment within Debian. Due to the freeze coming
  up we would understand the Release Team granting an RC exception for
  stretch for such non-sources already in main, with the condition that
  this will not extend to another release.

-- 
bye, Joerg (the ftpmaster behind the curtain)


signature.asc
Description: PGP signature

Re: Archive changes

[Joerg Jaspert]

On 14247 March 1977, Joerg Jaspert wrote:

> I've just activated a few changes to the archive we talk(ed) about for a
> long time. And while it is not exactly the start of this release cycle,
> it should still work out nicely (so one hopes).

Tuesday to now - i think the majority of what breaks with this change
should be found by now.

> As of now, InRelease/Release files, Packages and Sources no longer
> provide MD5Sum and SHA1sums, only SHA256.

>From the breakage people mentioned, I think this will change, and the
following seems (to me) to be the best way now: SHA1 stay off. But MD5
will come back, until the day we release stretch. Anything later than
stretch (and its support suites) will NOT carry MD5sums.

That hopefully gives enough time for those places where it's a larger
change to get rid of MD5.

> Additionally I turned off generating gzip compressed versions of those
> files, xz is there.

I would have imagined changing a (de)compressor being simpler than
possibly adjusting checksums that one may use as a key into a data
struct or so.

Turns out it does breaks more than I thought. Yet it sounds less serious
than the checksums, so - opinions? Keep it xz only? Bring back gz? For
how long, til stretch too, or shorter?

> To test it, this is limited to experimental. We hope nothing breaks on it,
> but lets try for a few days. If that works out, we should adjust
> unstable, and another short time later coordinate with the release team
> to adjust testing, so it ends up in the next release.

Adjusting unstable:

I've just turned off SHA1 sums there (next dinstall delivers),
compression waits for replies to the above, MD5 for release time.

-- 
bye, Joerg
Naturally; worms that don't know what they are doing end up as
fish bait, instead of getting invited into weird math experiments.
-- Lars Wirzenius

Re: Archive changes

[Joerg Jaspert]

Am 2016-03-16 01:20, schrieb Steve McIntyre:

I've just activated a few changes to the archive we talk(ed) about for 
a
long time. And while it is not exactly the start of this release 
cycle,

it should still work out nicely (so one hopes).
As of now, InRelease/Release files, Packages and Sources no longer
provide MD5Sum and SHA1sums, only SHA256.

That (Packages and Sources) will break jigdo generation for debian-cd
(and hence all CD/DVD/BD builds). We can't fix this easily in a short
timescale - current released jigdo clients (both in Debian and
externally) use md5 internally to reference files in the archive. Not
as a *security* feature; this is the core design of jigdo.


B.

If it really turns out that this is unchangeable for now - the code is
flexible enough to allow to freely select checksum types by suite, so
md5 could be turned on for a suite too. Without getting sha1 back.
(Its written so that it can simply support any checksum apt_pkg 
supports).


Im not sure we *want* to support that, at least for sure not for more 
than stretch, but we could.



Additionally I turned off generating gzip compressed versions of those
files, xz is there.

And that will break various other parts of debian-cd.


Question is how hard a change of a compression tool is there.

To test it, this is limited to experimental. We hope nothing breaks on 
it,

but lets try for a few days. If that works out, we should adjust
unstable, and another short time later coordinate with the release 
team

to adjust testing, so it ends up in the next release.

Please, no. We need more time than that to fix things up.


Its not like its an entirely new idea to do this.
How much?


Also, from reading the current replies, noone has a problem with 
removing sha1, so that one seems a set thing. md5 and gz files removals 
make people more happy.


--
bye Joerg

Re: Archive changes

[Joerg Jaspert]

Am 2016-03-16 08:32, schrieb Stefano Zacchiroli:


>To test it, this is limited to experimental. We hope nothing breaks on it,
>but lets try for a few days. If that works out, we should adjust
>unstable, and another short time later coordinate with the release team
>to adjust testing, so it ends up in the next release.

I've noticed an upcoming breakage in sources.debian.net too, and
reported it as #818324. Luckily that is trivial to fix for us.

But it might be a good idea to track all upcoming breakages using the
BTS. Fell free to tag and/or mark as blocking the above bug report as
needed. And to report more similar bugs :)


Yes please.

--
bye Joerg

Re: support for merged /usr in Debian

[Joerg Jaspert]

On 14173 March 1977, Ian Jackson wrote:
>> Is there any use case that requires supporting unmerged systems?
> Someone has already mentioned mounting /usr ro.  But one generally has
> to keep /etc rw.  I don't think that the right way to address this is
> to make /etc a mount point.

No, /etc can be nicely ro. That is, /, /usr, /etc, ... can be. The log
storage and the user homes, as well as a tmp filesystem rw, rest ro.
Works nicely, I have 4 of such systems running.

Yes, updates are a bit annoying (especially as those systems also
disallow any further rw mounts after boot), as they include reboots or
remounts, depending on if you block further remounts or not.
But thats a minor thing.

-- 
bye, Joerg
But Marge, what if we chose the wrong religion? Each week we just make
God madder and madder.

New file in / of our mirros

[Joerg Jaspert]

Hi,

in response to bug#752134 I implemented a little sha256sums $(find|grep)
logic to create a file "extrafiles" in the top level of our mirror tree.

The intention is to list all files that, unlike Packages and their
files, aren't otherwise verifyable via existing signatures already.
This appears in all our public archives, that is, main archive,
debian-debug as well as the old backports archive for squeeze.

I hope I catch all files, improvements always welcome, the logic is in
dak[1], file dinstall.functions, function "signotherfiles". The important
part is:

sha256sum $(find * -type f | egrep -v 
'(pool|i18n|dep11|source)/|Contents-.*\.(gz|diff)|installer|binary-|(In)?Release(.gpg)?|\.changes')

[1] Clone from https://ftp-master.debian.org/git/dak.git/

-- 
bye, Joerg
 we have release cycles, that's why it takes so long to get a
release out; if we had release race cars, things would go a lot faster


signature.asc
Description: PGP signature

Re: Bug#808767: ITP: apt-transport-gs -- APT transport for repositories privately held on GCS

[Joerg Jaspert]

On 14164 March 1977, Marcin Kulisz wrote:

>> * Marcin Kulisz (kuLa) , 2015-12-22, 16:07:
>> >* Package name: apt-transport-gs
>> s/gs/gcs/ ?
> Honestly I'm not sure about it (I mean package name not the change). I don't
> really mind to change it to gcs.
> I called package *-gs to keep it in the 2 letter convention and to
> emphasise

Which two-letter convention?

apt-transport-https
apt-transport-spacewalk
apt-transport-s3
apt-transport-tor

> that links later are starting with gs://, but if people think it
> should be gcs instead I'll change it.

Why are they gs: when its for gcs?

-- 
bye, Joerg
Marge, it takes two to lie. One to lie and one to listen.

Re: Rename security suite to *-security

[Joerg Jaspert]

On 14160 March 1977, Thijs Kinkhorst wrote:

> Seems like a good plan. I'm assuming that people using the old style
> configuration on the new release would get an error message (and not a
> silent lack of updates); or even better: that they are automatically
> redirected to the new locations.

Depends. If we just go with the new layout for dists/$suite, 404 are
expected. If we go with symlinks, no error there - and about noone will
switch, and then they get 404 a release later.

-- 
bye, Joerg
Ralph: Me fail English? That's unpossible.

Re: Upcoming version of apt-file - using apt-acquire and incompatibilities

[Joerg Jaspert]

On 14154 March 1977, Paul Wise wrote:
>> http://ftp.de.debian.org/debian/dists/experimental/main/Contents-source.diff/>
>>  
>> They now appear.
> Thanks, there are still some missing though:
> testing main/contrib/non-free
> unstable/experimental contrib/non-free

They get generated whenever there are changes.

-- 
bye, Joerg
All my life I've had one dream, to achieve my many goals.

Re: Upcoming version of apt-file - using apt-acquire and incompatibilities

[Joerg Jaspert]

On 14153 March 1977, Paul Wise wrote:
> Looks like Contents-source.diffs don't exist on the mirrors, filed a
> bug against ftp.d.o:
> http://ftp.debian.org/debian/dists/unstable/main/Contents-source.diff/ (404)
> https://bugs.debian.org/807727

http://ftp.de.debian.org/debian/dists/experimental/main/Contents-source.diff/

They now appear.

-- 
bye, Joerg
But Marge, what if we chose the wrong religion? Each week we just make
God madder and madder.

Re: An abrupt End to Debian Live

[Joerg Jaspert]

On 14121 March 1977, Fernando Toledo wrote:
>> [ I don't know why this post is not showing up on planet.debian.org:
>> https://danieltmp.wordpress.com/2015/11/09/an-abrupt-end-to-debian-live/> I 
>> am sending it here by mail now. ]
> I'm part of developer team for Huayra GNU/Linux [1] a debian derivated
> distro that shipped in more than MILLON of netbooks to high school
> students in past years. And today the State was delivered about
> 5.316.988 netbooks

> I was very sad this news. Debian Live and specific tool live-builder is
> our main build system and the BEST tool to make live systems. (including
> compare on other gnu/linux distributions)
> The Daniel (and another contribs) work was excelent.

> Please, Debian developers must still support this project.

Note that declaring it dead is an action that Daniel did. He can easily
continue developing it, noone stops him from doing so. It may end up no
longer being the tool that debian-cd uses to create live images for the
Debian project, but it looks like there are more than enough other users
for it, so stopping it seems kinda like an overreaction.

-- 
bye, Joerg
(to my limited brain, Joerg is the nice guy proving the dark 
conspiracies of a ftpmaster cabal wrong)
  -- Jonas Smedegaard

Re: DAK Commands for Bikesheds

[Joerg Jaspert]

On 14071 March 1977, Anthony Towns wrote:
>> > For the "Master" and "Uploader" fields, it would probably be nice if
>> > you could specify DDs by uid instead of just fingerprint. (Especially
>> > so that updates to the keyring were automatically reflected in bikeshed
>> > permissions)
>> Fingerprint handling is way easier, especially when taking DMs in
>> account, so that is noted, but will probably not be in the very first
>> version.
> I think uid handling would be pretty easy:

I look into that when I'm there, sure.

> Happy to have another look when there's enough code to suggest an
> actual patch.

Looking at current speed, that will be end of this month.
It's going slow, but at least it's going.

> I'm assuming that an upload to a bikeshed gets REJECTed if:
>  - uploader isn't in the acl for the bikeshed

while acl != "freeforall"

>  - it's not a listed package for the bikeshed

Now that shows a different understanding of listing the packages. One
thats also valid and interesting, but one that for example Thomas (and
me) had different: (Note, always talking about source package)

Current, according to docs:
-> Packages as listed on create or add time are added to the bikeshed on
   create (or add) time, newer version put in if so selected by
   auto-update.

Yours, to fit the REJECT rule:
-> Only packages listed, regardless of auto-update, may ever be
   uploaded.

Which could both be valid. Hrm.

>  - it's not in the overrides for unstable (or base-suite?)

Initially my answer was "base suite", but that hurts backports. But just
unstable also hurts, for the same reason: Overrides change enough
over the lifetime of a release, that I think the best will be a
combination, so "base-suite + unstable" overrides.
That would allow all thats in base-suite but may have been removed in
unstable, but also allow all new additions to unstable to get
backported.

>  - it fails standard corruption checks (bad tarball, lintian)
>  - it has an older version that what's already in the bikeshed
>  - it has an older version that what's already in the base-suit ?

Ack. May actually want to see if we make the lintian checks
configurable, ie. ability to turn off at least the soft rejects for it.

>> Right, so, the mergeback feature is intended for transitions and bigger
>> $whatevers in Debian that need longer preparation. And it needs the
>> "base-suite" to cooperate, that is, it needs to be turned on in the base
>> suite (so I think unstable and possibly testing will support it, I doubt
>> that stable ever will).
> I could imagine proposed-updates supporting it?
> I think for testing, it would be better to have britney pull from a
> bikeshed (similarly to how it pulls from testing-proposed-updates)
> rather than let people push to testing.

Ack, but I leave that decision to the actual people responsible for
those suite.

>> Your -pull-from is basically my -add, just with an added suite. My way
>> of thinking is coming from a way more limited usage, so I adjusted add
>> to optionally take Suite as parameter, now one can select from where the
>> package comes.
> Hmm. I was thinking of "add" as just changing what's allowed to be
> uploaded.

That goes with what I wrote above, different understanding of what the
listed packages mean.

>> I think so, yes. If the whole of the project wants to adjust that, I
>> wouldn't be against it, but I think its too far a change from the
>> concept of DM as we have now that I just want to put it in.
> So the reason I think DMs shouldn't create bikesheds directly is mostly
> about permissions:
>  - DM creates bikeshed
>  - DD uploads package DM doesn't have perms to upload in unstable
>  - DM merges package into unstable

It should fail at the last point then.

> You could put in extra checks to ensure DMs can only create bikesheds
> for packages they're allowed to play with, or to ensure mergebacks check
> DM ACLs when invoked by a DM, but all-in-all it seems to me if a DM is
> clever enough to be playing with bikesheds, it's about time they became
> a DD anyway.

Ay.

> (Maybe we should have called DM's "Debian Apprentices" to emphasise DMs
> should become DDs after a while... If nothing else, would have allowed
> a Sith model of package maintenance which would be amusing)

Well, there are people who are happy to be "just" a DM. We shouldn't
block them from getting DD, but if they like DM, sure, maintain your
package and be happy :)

-- 
bye, Joerg

Re: DAK Commands for Bikesheds

[Joerg Jaspert]

On 14070 March 1977, Stefano Zacchiroli wrote:
> On Sun, Sep 20, 2015 at 03:48:24PM +0200, Joerg Jaspert wrote:
>> I've updated https://ftp-master.debian.org/users/joerg/README.commands> with 
>> hopefully not too many new errors. :)
> Minor nit (assuming I've got the naming convention right).

Thanks, updated.

-- 
bye, Joerg
 Deine Größe macht mich klein 
<@joerg> doll
 du darfst mein Bestrafer sein 
(!) Wrecktum was kicked from #german by joerg [ok]

Re: DAK Commands for Bikesheds

[Joerg Jaspert]

On 14070 March 1977, Anthony Towns wrote:
>> Please check if I forgot something obvious or if there is some big error
>> in it. Patches/git trees to merge from/... are welcome.
> dcut from dput-ng uses $login-$timestamp rather than "EPOCH" per se. Does
> this actually matter, or is it just convention though?

Convention, we don't enforce it. Though we keep the right to do it,
should we suddenly end up with loads of collisions or something.

> ] The file needs to be signed by a valid key from the Debian uploader
> ] keyrings.
> Does the $login in the filename have to correspond to the signing
> key? Ditto the Uploader: field?

Dito.

> ] This file has to be uploaded to ftp.upload.debian.org.
> I presume dak-commands will be queue-able if anyone updates
> queued? There's nothing fundamental preventing it, right?

Correct.

> -1 on abbreviated command names fwiw; it's a text file so
>   Action: create-bikeshed
> seems fine to me. I'd be a little inclined to have "bikeshed-create"
> personally, YMMV obviously. "update-bikeshed-acl" or "bikeshed-acl"
> or similar might be clearer than "access-bikeshed".

The shortcut mostly comes from lazyness, bs is less to type. I've
renamed access-bs to acl-bs, acl is a much better fit.

And renamed all commands from foo-bs to bikeshed-foo.

> I kind of think "Bikeshed: foo" might be better than "Name: foo" ?
> We have "Package: foo" not "Name: foo" in the Packages file, eg.

Accepted.

> ] if the name conflicts with an existing bikeshed a
> ] random string will be appended to it.
> Outright rejection would be better here, IMO. The user can always add
> a random string themselves if that's what they actually want.

Hrm, I think its nicer to "help along". They want a bikeshed, they get
one, even if someone else ended up having a similar one already.
But it makes it easier in code, so gone the postfix is.

> ] Package: A name of a source package to import from the base-suite.
> ] Repeat as often as needed.
> That's unusual. Is having multiple packages on a single header also
> valid? eg:
>   Package: glibc, systemd, sysvinit
> ?

I think it's cleaner to have one per package tag, but its either that or
only one line, comma-seperated. No preference here.

> If "Master:" is specified, is the uploader implicitly considered a
> master as well, or do they need to specify themselves?

Yes, any Master: value is added on top of the default uploader.

> (It seems they are implicitly considered a master when updating the
> bikeshed's ACLs) I would have thought "Owner:" would make more sense
> than "Master:" fwiw.

Then you end up having multiple owners. Master IMO shows better what the
intended value of it is - the ones with access to change around its
settings. (Got to that from the MASTER role in irc.debian.orgs chanserv).

> ] including dropping a bikeshed
> (Demolishing would be a more amusing verb :)

Adjusted, added demolish-bs as an alias for the drop-bs command.

> (Likewise, "modify-bs" should clearly be "paint-bikeshed" given it only
> changes things that have no technical effect...)

Similar here. Also, if my CSS guru doesn't deny its possibility, both
create and modify will gain either a color or a style option, so you can
have your own color/style in the bikeshed overview page later on, so
modify will change things with technical effect (HTML "code"!), and
paint-bikeshed fits so much more then too. :)

> For the "Master" and "Uploader" fields, it would probably be nice if
> you could specify DDs by uid instead of just fingerprint. (Especially
> so that updates to the keyring were automatically reflected in bikeshed
> permissions)

Fingerprint handling is way easier, especially when taking DMs in
account, so that is noted, but will probably not be in the very first
version.

> ] (eg., DMs need an ACL set for their package).
> It seems like it would be good to have some way of letting a DM hack on a
> package that they can't do in unstable -- ie, where they can practice,
> or demo their ideas, etc. This might be handy for "summer of code"
> projects for example.

Ack.

> I wonder if it might be better to have two permissions arrangements: (a)
> don't specify any fingerprints, and anyone who can upload to unstable
> can upload to the bikeshed (same ACLs for DMs), or (b) do specify
> fingerprints, and those keyholders can upload anything in the bikeshed
> (no ACLs for DMs), but no one else can.

So basically what it is now (set no uploader and its same as for
unstable, set fingerprints and its those), except for the "DMs need an
ACL" is turned into "DMs don't need an ACL for a package, if listed as
an Uploader in this bikeshed"? That would allow them to upload all
packages to that bikeshed.

Alternative would be to add that as a third option, so one would have

 - free for all, ACLs for DMs (as unstable)
 - free for all listed, ACLs for DMs
 - free for all listed, no ACLs for DMs
 
> Has the Auto-Update / mergeback stuff been implemented yet? It doesn't
> seem like it quite