Re: Bits from the release team: full steam ahead towards buster

[Emilio Pozuelo Monfort]

Hi,

When all people can complain about are the codenames, it means we are doing
things fairly well :)

On 18/04/18 08:20, Lars Wirzenius wrote:
> On Wed, 2018-04-18 at 11:16 +0500, Andrey Rahmatullin wrote:
>> No, users and, I suspect, a large part of admins and developers cannot
>> easily say which of two codenames is newer, and it doesn't matter what are
>> those two codenames. Numeric versions are usually used to help with this,
>> but not so much in Debian.
> 
> I've been developing a habit of writing both number and codename:
> Debian 9 (stretch) and Debian 42 (billgates).
> 
> I think it would be a good habit for others as well, especially in
> public-facing communication.

That's a very good point, particularly for announcements. I'll try to keep it in
mind.

Cheers,
Emilio

Re: Completed: lists.alioth.debian.org migration

[Scott Kitterman]

On Tuesday, April 17, 2018 08:42:22 PM Holger Levsen wrote:
> On Tue, Apr 17, 2018 at 10:39:22PM +0200, Christoph Biedl wrote:
> > Also, @lists.alioth.debian.org addresses that were *not* migrated now
> > result in bounces as expected. Are there already plans for a MBF
> > severity RC against all packages with a now-failing maintainer address?
> > This might become rather messy, I've counted some 1450 packages.
> 
> please file bugs, so that autoremovals can kick in. Thanks.

I've been watching my FTP team mailbox for new uploads with dead addresses due 
to alioth lists going away.  Yesterday and today it was 5 RC bugs and one 
package rejected from New.

Please, check you've got a working maintainer address before doing a new 
upload.  You'll end up waiting a long time for the Accepted mail if you don't.

Scott K

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

Re: Bits from the release team: full steam ahead towards buster

[Andrey Rahmatullin]

On Wed, Apr 18, 2018 at 09:20:11AM +0300, Lars Wirzenius wrote:
> > No, users and, I suspect, a large part of admins and developers cannot
> > easily say which of two codenames is newer, and it doesn't matter what are
> > those two codenames. Numeric versions are usually used to help with this,
> > but not so much in Debian.
> I've been developing a habit of writing both number and codename:
> Debian 9 (stretch) and Debian 42 (billgates).
Unfortunately there is also a lot of tools where this would be helpful.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Bits from the release team: full steam ahead towards buster

[Lars Wirzenius]

On Wed, 2018-04-18 at 11:16 +0500, Andrey Rahmatullin wrote:
> No, users and, I suspect, a large part of admins and developers cannot
> easily say which of two codenames is newer, and it doesn't matter what are
> those two codenames. Numeric versions are usually used to help with this,
> but not so much in Debian.

I've been developing a habit of writing both number and codename:
Debian 9 (stretch) and Debian 42 (billgates).

I think it would be a good habit for others as well, especially in
public-facing communication.

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

Re: Bits from the release team: full steam ahead towards buster

[Andrey Rahmatullin]

On Tue, Apr 17, 2018 at 10:34:22PM +0200, Christoph Biedl wrote:
> There are people who don't follow every single action in Debian, plain
> stables users for example. For them it's helpful to tell the releases
> apart easily as they might not have the precise names and their order in
> mind. The first letter is a fairly simple way to aid this.
No, users and, I suspect, a large part of admins and developers cannot
easily say which of two codenames is newer, and it doesn't matter what are
those two codenames. Numeric versions are usually used to help with this,
but not so much in Debian.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Completed: lists.alioth.debian.org migration

[Christoph Biedl]

Holger Levsen wrote...

> please file bugs, so that autoremovals can kick in. Thanks.

Sheesh, it's not about removing package but keeping them. By making sure
they are in good shape which, among many other things, means there is a
working well-defined maintainer contact address.

Re: problems in gjots2 and Debian

[Rolf Leggewie]

On 18.04.2018 13:19, Rolf Leggewie wrote:
> I get all this for maintaining a number of packages for 10+ years in
> Debian

BTW, one of the first packages if not THE first package was gjots2.  And
I had to go through a lengthy and cumbersome MIA process to take over. 
Seems like the rules do not apply for DD buddies...

problems in gjots2 and Debian

[Rolf Leggewie]

Wookey wrote:

> > > I had had a look at the new upstream quite a while ago and found
> > > several bugs so I reported them upstream and held off releasing
> > > to Debian.
> > >
> > > https://sourceforge.net/p/gjots2/bugs/
>
> Someone new to this can't tell from this message or that list of 20 bugs
> (none of which obvisouly have your name on), what it is about the
> package which is so buggy that a new version cannot be uploaded.

@Wookey, not to sound aggressive, but you must not have looked very
carefully.  The majority of the bug reports CLEARLY have my name on it
(both first AND last).

The problems have of course changed over time, so I truly cannot recall
every single problem of the last three to four years, some of them might
have been addressed and new ones introduced.  Why do you need to dissect
that now (not that I would object to that in a different context)?  The
latest problem with 3.0.2 is that the program simply fails to start for
me.  That's about as RC as it gets, right?  As I've said here (in my
very first mail, I believe), I was in contact with upstream.  Luckily,
the mail didn't bounce and their reply in the meantime has been that the
program works for them on Fedora but no other hint.  I was now planning
to investigate missing libraries.

@ALL, it seems like no matter what I say, no matter how I explain my
reasons, I cannot convince quite a number of people.  So, I plan not to
waste my time on trying anymore.  Steve is much better of getting to the
relevant points anyhow.  I certainly made mistakes, I would say they are
mostly cosmetic, questions of form I was simply unaware of, but others
perceive them differently.  I apologized, owned up to it and changed
course.  I had no ill intentions.  Yet, I'm still the bad guy for a good
number of people (I've been called "nasty" in private mail).

I get all this for maintaining a number of packages for 10+ years in
Debian and when I complain that one of the "packages I maintain" (!) AKA
"my package" is stolen from me?  I get basically told (by some) that my
packages in collab-maint are free-for-all to upload as they please,
demote me and disrespect my work as they please, I basically get told
that I'm not free to choose NOT to host on such a service by somebody
else.  WTF?  The aggressors who were the ones to violate proper
processes on the other hand get a public pat on the back for manly
behaviour and "no need to apologize" for failing twice.  OK, I got the
message...




signature.asc
Description: OpenPGP digital signature

Re: Lucas Kanashiro and Athos Ribeiro fixed my package and i didnt like it

[Sean Whitton]

Hello,

On Tue, Apr 17 2018, Holger Levsen wrote:

> I really don't get the fuzz about your upload. As I see it, you fixed
> 4 problems and made 2 (easily fixable) mistakes, which could have been
> fixed easily if pointed out nicely, eg. via a bug. And the upload was
> definitly justified (even if done badly), as we have 0-day NMUs for RC
> bugs. (I'm not gonna count Rolfs mistakes here, nor his good work.)

A quick correction here: we have 0-day NMUs for uploads that include
nothing except minimal fixes to RC bugs.  If the upload does anything
else it is meant to go to DELAYED.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: salvaging packages, was Re: Lucas Kanashiro and Athos Ribeiro salvaged my package

[Sean Whitton]

Hello,

On Wed, Apr 18 2018, Paul Wise wrote:

> I'm guessing you are referring to this file?

Yes.

> infinote://gobby.debian.org/debconf17/bof/if_you_love_a_package_let_it_go
> https://gobby.debian.org/export/debconf17/bof/if_you_love_a_package_let_it_go

I didn't know there existed URLs to particular gobby documents.  Thank
you!

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: salvaging packages, was Re: Lucas Kanashiro and Athos Ribeiro salvaged my package

[Paul Wise]

On Wed, Apr 18, 2018 at 12:09 AM, Sean Whitton wrote:

> Yes.  Take a look on gobby (apt-get install gobby and connect to
> gobby.debian.org).

I'm guessing you are referring to this file?

infinote://gobby.debian.org/debconf17/bof/if_you_love_a_package_let_it_go
https://gobby.debian.org/export/debconf17/bof/if_you_love_a_package_let_it_go

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Bug#886968: btrfs-progs-udeb: depends on non-udeb: libzstd1

[Cyril Brulebois]

Hi,

Dimitri John Ledkov  (2018-04-17):
> First, I apologize for not responding to this email earlier, as I have
> missed it in my mailbox.

It's a mail from hours ago, so there's no apology needed.

> Secondly, my work has been blocked by this NEW processing too for
> btrfs-progs. I'm not aware as to which Helmut's work was blocked,
> could you please elaborate what Helmut is blocked on? And/or how can
> libzstd/me help to unblock Helmut? -> is that about patches for
> crossbuilding that are part of

[sentenced cut in the middle but] Yes, Helmut works quite a lot on
crossbuilding and commits sitting in git master looked like what he was
alluding to.

> Now to respond to your main inquiry. I find the tone of above message
> unacceptable. It reads accusational to me, rather than inquisitive.
> 
> It would have been much better to state:
> "I notice that a call to dh_makeshlibs does not pass the -V flag as it
> is custom for many libraries. Why have you not specified a minimum
> required version in this case?"

I suppose that's a fair way to word it. But I did mean to point out that
packages having an impact on the installer should be reviewed by the
installer team, at least for their initial addition; as I tried to make
people aware a few times already (dda@, talks, replies to threads where
udeb additions were mentioned, etc.); since that simple and natural
process wasn't followed here, I did point that out.

> It also feels like you (or others who were made aware of this lack of
> -V) possibly wanted to make this a bug report, and follow-on out of
> band events made it seem like it was felt that it is RC buggy and
> shouldn't clear NEW and/or migrate to testing if passed NEW. In that
> case  a new bug report should have been opened, with above request at
> an RC priority.

I didn't comment on the fact it should get accepted or rejected from
NEW. People pointed me to the udeb addition that probably get some input
from me, so I've briefly looked at it and spotted that issue.

> However, it is good to point out at this time, that udeb version of
> libraries do not currently ship or use symbols files at all to
> generate dependencies.
> But also note that since libzstd1-udeb is a brand new package, any
> version of thereof would correctly and strictly satisfy any udeb
> package that gains a dependency on it. There are no linking or
> dependency bugs in above libzstd1, nor udeb edition of the binary
> packages.

I'm not sure why stashing a -V there once and for all to be future-proof
wouldn't be adequate or desireable. People can argue all they like about
whether the package is RC buggy in this specific revision, but it seems
rather pointless, I really do care about mid/long-term maintenance. I
have enough on my plate to not want to monitor such packages closely,
and open a specific bug report in their next revision…

> This is no different to some other library udebs, e.g. liblzo2-2-udeb

That's another perfect example why udeb additions should get reviewed:
we would have noticed another buggy package, and its bugginess might not
have been copied over to another package.

> Personally, I find it odd to have minimum -V arg version dependencies
> for udebs only, when symbols are present for the deb edition of the
> library. For example, btrfs-progs depends on libc6 (>= 2.8), yet
> btrfs-progs-udeb depends on libc6-udeb (>= 2.27). This causes an
> immense amount of pain, when rebuilding packages locally, mixing &
> matching packages when debugging issues in d-i, and does not at all
> correctly generate private dependencies for udebs that use e.g.
> @GLIBC_PRIVATE and thus require libc6-udeb (>> 2.27), libc6-udeb (<<
> 2.28) style dependency instead. I'm not sure where/how .symbols should
> be used or shipped, to start generate genuinely correct version
> dependencies for udebs across the board. Debhelper? Dpkg?

I have done my share part of performing local builds and various
combinations of udebs, and I never experienced this “immense amount of
pain”.

Are you volunteering to introduce separate symbols support for udebs to
all the required components and to maintain it over time?

> Based on all of the above, I believe libzstd1, and libzstd1-udeb are
> both policy complaint as previously uploaded.

I like the typo.

> If you are still concerned about minimum version dependencies which
> are generated by packages that build/link/gain dependency on libzstd1
> and/or libzstd1-udeb, I welcome you, ftp masters, or anybody else to
> open a new (or clone this) bug report against libzstd for
> consideration. I also welcome references from the Debian Policy to
> educate myself further about library dependencies, and if and how,
> this package is not policy complaint and pointers on how to best fix
> it.

I'm not sure what the issue is with talking to the debian installer team
when you're touching udeb packages and trusting their assessment?

If someone wants to drive an effort to make -V a must for udebs in
policy, that'

Re: Lucas Kanashiro and Athos Ribeiro hijack my package

[Sergio Durigan Junior]

On Tuesday, April 17 2018, Athos Ribeiro wrote:

> @debian-devel:
>
> I am sorry my past actions have been taking so much time of everyone
> else, which could be put into something more productive for the
> community.

No need to apologize, mistakes happen and they provide a way to learn
more about ourselves and our processes.  Keep up the good work!

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Re: alioth deprecation - next steps

[James Clarke]

On Tue, Apr 17, 2018 at 11:37:40PM +0200, Bill Allombert wrote:
> On Tue, Apr 17, 2018 at 10:31:58PM +0100, James Clarke wrote:
> > Even the wiki page you linked there states that GitLab "allows extra
> > files to be attached to the tag".
>
> But it does not say how.
> Research shows that while gitlab has plan to implement the feature, it is
> not actually implemented yet.

I don't appreciate the selective quoting. Here's what I actually said in
full:

> On Tue, Apr 17, 2018 at 10:31:58PM +0100, James Clarke wrote:
> > Or take your tag and turn it into a release; the process is even nicely
> > documented[0], Bill, so perhaps you should get your facts straight before
> > complaining about this. I don't really care, but I imagine comments like
> > that are demoralising for those who put countless hours into providing
> > and maintaining all the services we take for granted in the project.
> > Even the wiki page you linked there states that GitLab "allows extra
> > files to be attached to the tag".
> >
> > Regards,
> > James
> >
> > [0] https://docs.gitlab.com/ce/workflow/releases.html

See that thing there? That's a link. To documentation. It tells you how
to do the thing you want, which has been implemented since 8.something,
I believe. Yes, the Debian wiki *could* tell you how to do that, and I
may do so tomorrow if nobody beats me to it, but at the end of the day
you're a developer who's supposed to be able to find relevant
documentation. It's not like GitLab is an obscure piece of software that
nobody else has ever tried using. Show some initiative.

James

Re: alioth deprecation - next steps

[Alexander Wirt]

On Tue, 17 Apr 2018, Bill Allombert wrote:

> On Tue, Apr 17, 2018 at 10:31:58PM +0100, James Clarke wrote:
> > Even the wiki page you linked there states that GitLab "allows extra
> > files to be attached to the tag".
> 
> But it does not say how.
> Research shows that while gitlab has plan to implement the feature, it is
> not actually implemented yet.
https://salsa.debian.org/formorer/testrepo/tags/0.1
you can btw. just add a release not and attach files to that release note. 

Alex
 

Re: libzstd_1.3.3+dfsg-2_multi.changes REJECTED

[Dimitri John Ledkov]

Hi,

On 17 April 2018 at 20:00, Thorsten Alteholz
 wrote:
>
> as requested by waldi ...
>

With all due respect to yourself, waldi, and ftp-team (masters &
assistants & wizards), I find this reject comment inappropriate, and
not at all informative enough.

As far as I can tell, the package uploaded is fully policy compliant
as I have elaborated elsewhere (on the only concern I have managed to
identify, with a reference from waldi, based on our informal IRC chat,
which was a bit rude on waldi's part).

I normally expect the reject emails to contain the technical
descriptions of identified problems; and/or request for details and
clarifications; or links to newly opened RC bug reports. I hope in the
future, to continue receive reject emails, with similar content as I
have been receiving previously for other rejected uploads.

I have responded to the library version dependencies query from Kibi,
elsewhere, please see that response for further details if you want to
dive into that.

This email is purely about the content of reject comment received from
ftpmaster@.

-- 
Regards,

Dimitri.

Re: Bug#886968: btrfs-progs-udeb: depends on non-udeb: libzstd1

[Dimitri John Ledkov]

On 17 April 2018 at 19:01, Cyril Brulebois  wrote:
> Dimitri John Ledkov  (2018-01-15):
>> On 15 January 2018 at 00:27, Cyril Brulebois  wrote:
>> > Hi,
>> >
>> > Cyril Brulebois  (2018-01-12):
>> >> Your package is no longer installable (along with its rev-dep
>> >> partman-btrfs) because it now depends on libzstd1, which isn't
>> >> a udeb.
>> >
>> > It seems zstd is only an option for btrfs-progs, and I've just confirmed
>> > that setting --disable-zstd on the dh_auto_configure line lets btrfs-progs
>> > build just fine, without the libzstd1 dependency. As far as I can tell,
>> > there's no absolute need for this feature in d-i, and we could consider
>> > building the udeb without zstd support, instead of requesting the addition
>> > of a libzstd1-udeb. What do you think?
>> >
>>
>> That's an oversight on my part. From the recovery point of view, it
>> would be desired to have zstd compression support built-into
>> btrfs-progs-udeb such that one can use d-i recovery mode to
>> backup/restore btrfs filesystems with zstd compression.
>
> Your unreviewed addition of udeb as seen in NEW (currently holding back
> Helmut's work as noticed on #debian-ftp) is broken. It's missing a
> version.
>
> Repeating the same request and piece of advice (since 2012 or so):
> please get udeb-related things reviewed by debian-boot@/me?
>
> Thanks already.

First, I apologize for not responding to this email earlier, as I have
missed it in my mailbox.

Secondly, my work has been blocked by this NEW processing too for
btrfs-progs. I'm not aware as to which Helmut's work was blocked,
could you please elaborate what Helmut is blocked on? And/or how can
libzstd/me help to unblock Helmut? -> is that about patches for
crossbuilding that are part of

Now to respond to your main inquiry. I find the tone of above message
unacceptable. It reads accusational to me, rather than inquisitive.

It would have been much better to state:
"I notice that a call to dh_makeshlibs does not pass the -V flag as it
is custom for many libraries. Why have you not specified a minimum
required version in this case?"

It also feels like you (or others who were made aware of this lack of
-V) possibly wanted to make this a bug report, and follow-on out of
band events made it seem like it was felt that it is RC buggy and
shouldn't clear NEW and/or migrate to testing if passed NEW. In that
case  a new bug report should have been opened, with above request at
an RC priority.

I hope above is an adequate description, of the technical question you
are alluding to.

The proposed update that got rejected from NEW had
```
override_dh_makeshlibs:
dh_makeshlibs -plibzstd1 --add-udeb=libzstd1-udeb
```
(I hope this is enough context from said upload, for more details see
tree at 
https://salsa.debian.org/med-team/libzstd/tree/50c4849ef0ea5d79d7d5f84fd0a46b6404a413eb)

Note, that libzstd1 provides a symbols file, therefore packages that
link against it, normally get the correct minimum version dependency
based on the symbols file.
Therefore lack of -V flag is irrelevant for the actual dependencies
generated on packages that link/depend on libzstd1.

However, it is good to point out at this time, that udeb version of
libraries do not currently ship or use symbols files at all to
generate dependencies.
But also note that since libzstd1-udeb is a brand new package, any
version of thereof would correctly and strictly satisfy any udeb
package that gains a dependency on it. There are no linking or
dependency bugs in above libzstd1, nor udeb edition of the binary
packages.

This is no different to some other library udebs, e.g. liblzo2-2-udeb

Personally, I find it odd to have minimum -V arg version dependencies
for udebs only, when symbols are present for the deb edition of the
library. For example, btrfs-progs depends on libc6 (>= 2.8), yet
btrfs-progs-udeb depends on libc6-udeb (>= 2.27). This causes an
immense amount of pain, when rebuilding packages locally, mixing &
matching packages when debugging issues in d-i, and does not at all
correctly generate private dependencies for udebs that use e.g.
@GLIBC_PRIVATE and thus require libc6-udeb (>> 2.27), libc6-udeb (<<
2.28) style dependency instead. I'm not sure where/how .symbols should
be used or shipped, to start generate genuinely correct version
dependencies for udebs across the board. Debhelper? Dpkg?

Based on all of the above, I believe libzstd1, and libzstd1-udeb are
both policy complaint as previously uploaded.

If you are still concerned about minimum version dependencies which
are generated by packages that build/link/gain dependency on libzstd1
and/or libzstd1-udeb, I welcome you, ftp masters, or anybody else to
open a new (or clone this) bug report against libzstd for
consideration. I also welcome references from the Debian Policy to
educate myself further about library dependencies, and if and how,
this package is not policy complaint and pointers on how to best fix
it.

-- 
Regards,

Dimitri.

Re: alioth deprecation - next steps

[James Clarke]

On Tue, Apr 17, 2018 at 11:10:56PM +0200, Alexander Wirt wrote:
> On Tue, 17 Apr 2018, Bill Allombert wrote:
>
> > On Tue, Apr 17, 2018 at 01:00:56PM +0200, Alexander Wirt wrote:
> > > Hi,
> > >
> > > as you should be aware, alioth.debian.org will be decommissioned with
> > > the EOL of wheezy, which is at the end of May. The replacement for
> > > the main part of alioth, git, is alive and out of beta, you know it
> > > as salsa.debian.org. If you did not move your git repository yet,
> > > hurry up, time is running out.
> > >
> > > The other important service from the alioth set, lists, moved to a
> > > new host and is now live at https://alioth-lists.debian.net [1].
> > > All public list archives moved over too and will continue to exist
> > > under the old URL.
> >
> > What about the most basic service, the download page ?
> > (like )
> >
> > According to
> > 
> > there is no equivalent on salsa.
> >
> > git tags are not a suitable alternative because true release tarballs
> > include files generated by autotools (among others) that are not in
> > git, and git tags tarballs are not signed (signed tags is an different
> > concept).
> >
> > This unfortunately makes salsa unsuitable as a project homepage.
> Create a gitlab-ci job, build your files and provide them under a gitlab
> page. So you are wrong, salsa can work as it.

Or take your tag and turn it into a release; the process is even nicely
documented[0], Bill, so perhaps you should get your facts straight before
complaining about this. I don't really care, but I imagine comments like
that are demoralising for those who put countless hours into providing
and maintaining all the services we take for granted in the project.
Even the wiki page you linked there states that GitLab "allows extra
files to be attached to the tag".

Regards,
James

[0] https://docs.gitlab.com/ce/workflow/releases.html

Re: alioth deprecation - next steps

[Alexander Wirt]

On Tue, 17 Apr 2018, Bill Allombert wrote:

> On Tue, Apr 17, 2018 at 11:10:56PM +0200, Alexander Wirt wrote:
> > On Tue, 17 Apr 2018, Bill Allombert wrote:
> > 
> > > On Tue, Apr 17, 2018 at 01:00:56PM +0200, Alexander Wirt wrote:
> > > > Hi,
> > > > 
> > > > as you should be aware, alioth.debian.org will be decommissioned with
> > > > the EOL of wheezy, which is at the end of May. The replacement for
> > > > the main part of alioth, git, is alive and out of beta, you know it
> > > > as salsa.debian.org. If you did not move your git repository yet,
> > > > hurry up, time is running out.
> > > > 
> > > > The other important service from the alioth set, lists, moved to a
> > > > new host and is now live at https://alioth-lists.debian.net [1].
> > > > All public list archives moved over too and will continue to exist
> > > > under the old URL.
> > > 
> > > What about the most basic service, the download page ?
> > > (like )
> > > 
> > > According to 
> > > 
> > > there is no equivalent on salsa.
> > > 
> > > git tags are not a suitable alternative because true release tarballs
> > > include files generated by autotools (among others) that are not in
> > > git, and git tags tarballs are not signed (signed tags is an different
> > > concept).
> > > 
> > > This unfortunately makes salsa unsuitable as a project homepage.
> > Create a gitlab-ci job, build your files and provide them under a gitlab
> > page. So you are wrong, salsa can work as it. 
> 
> This is a very convoluted and resource-heavy process, and this does not
> solve the signature problem (a gitlab-ci job cannot create the signature
> file without the private key).
> 
> I do not think this is a solution.
You are the first one in two years mentioning this "needed" service. It can't
be that important than and it least for me its too late now. But feel free to
step in and provide a replacement. 

Alex

Re: alioth deprecation - next steps

[Bill Allombert]

On Tue, Apr 17, 2018 at 10:31:58PM +0100, James Clarke wrote:
> Even the wiki page you linked there states that GitLab "allows extra
> files to be attached to the tag".

But it does not say how.
Research shows that while gitlab has plan to implement the feature, it is
not actually implemented yet.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Re: alioth deprecation - next steps

[Bill Allombert]

On Tue, Apr 17, 2018 at 11:10:56PM +0200, Alexander Wirt wrote:
> On Tue, 17 Apr 2018, Bill Allombert wrote:
> 
> > On Tue, Apr 17, 2018 at 01:00:56PM +0200, Alexander Wirt wrote:
> > > Hi,
> > > 
> > > as you should be aware, alioth.debian.org will be decommissioned with
> > > the EOL of wheezy, which is at the end of May. The replacement for
> > > the main part of alioth, git, is alive and out of beta, you know it
> > > as salsa.debian.org. If you did not move your git repository yet,
> > > hurry up, time is running out.
> > > 
> > > The other important service from the alioth set, lists, moved to a
> > > new host and is now live at https://alioth-lists.debian.net [1].
> > > All public list archives moved over too and will continue to exist
> > > under the old URL.
> > 
> > What about the most basic service, the download page ?
> > (like )
> > 
> > According to 
> > 
> > there is no equivalent on salsa.
> > 
> > git tags are not a suitable alternative because true release tarballs
> > include files generated by autotools (among others) that are not in
> > git, and git tags tarballs are not signed (signed tags is an different
> > concept).
> > 
> > This unfortunately makes salsa unsuitable as a project homepage.
> Create a gitlab-ci job, build your files and provide them under a gitlab
> page. So you are wrong, salsa can work as it. 

This is a very convoluted and resource-heavy process, and this does not
solve the signature problem (a gitlab-ci job cannot create the signature
file without the private key).

I do not think this is a solution.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Re: Lucas Kanashiro and Athos Ribeiro hijack my package

[Athos Ribeiro]

On Mon, Apr 16, 2018 at 08:28:08AM +0800, Rolf Leggewie wrote:
> Dear fellow maintainers, dear Lucas and Atheros,

Hi Rolf,

> I'd like to use this opportunity to relay my experiences with Lucas
> Kanashiro (kanash...@debian.org) and Athos Ribeiro
> (athoscribe...@gmail.com). TL;DR Going purely by my "interaction" or
> rather the lack of it with them in the maintenance of gjots2, I have
> some doubts they are fit to be DD or DM.
> 
> Let me be clear, I am not calling for Lucas Kanashiro to be stripped of
> DD privileges, but I would certainly like to raise my objections if
> Athos ever attempted to become DM or DD.  And I want to make sure that
> Lucas' behaviour is documented and known in case of a repeat.
> 
> For many years, I have maintained gjots2 and a number of other packages
> in Debian, I am DM.  Towards the end of March, totally out of the blue
> Lucas and Atheros usurped maintenance of gjots2 from me without NMU, MIA
> or any form of communication with me whatsoever.  I am very active, both
> in Debian and Ubuntu, anything but MIA.  I have a working e-mail
> account.  About a week ago I asked them to reverse their changes which
> until today hasn't happened so I went ahead and did it myself now, doing
> their clean-up work.

Once again, I would like to apologize for the lack of communication on
my end. As I told you last week, before this message and before Lucas
was back from the MiniDebConf in Curitiba, I was really willing to make
things right.

> They might want to argue that gjots2 was poorly maintained and hasn't
> seen an upload to unstable for years.  That still would not give them
> reason to do what they did.  In fact, I have always taken my
> responsibilities seriously.  There are good reasons there was no
> upload.  If they had bothered to check the upstream bug tracker or the
> upstream branch at
> https://anonscm.debian.org/gitweb/?p=collab-maint/gjots2.git they would
> have surely realized I followed upstream closely.  It was simply that I
> was never satisfied with any of the upstream releases.  I have been in
> contact with upstream about this via bug tracker and e-mail (many of
> which bounced, so progress has been slow).  Even the latest upstream
> release 3.0.2 does not work for me and thus I would not upload it to
> unstable.  Agreed, gjots2 is not in good shape but it's not because of a
> lack of effort from the Debian Maintainer.

I am sure you have been taking good care of the packages you maintain
and will keep performing the good work.

> Lucas and Atheros hijacked my package and then failed to clean up after
> the mess they made despite being asked to do so.

I can not change what had happened here but I hope we can put this
behind us and move forward.

@debian-devel:

I am sorry my past actions have been taking so much time of everyone
else, which could be put into something more productive for the
community.

regards,

Athos Ribeiro


signature.asc
Description: PGP signature

"my package" vs "a package I maintain"

[Lucas Nussbaum]

Hi,

On 16/04/18 at 08:28 +0800, Rolf Leggewie wrote:
> Lucas and Atheros hijacked my package [...]

I know I'm late to the thread, but I wanted to make another point.

You write "my package". I think that as Debian maintainers, we should
try to avoid talking about "*my* package", but rather use e.g. "a
package I maintain inside Debian", "a package I take care of", etc.

That's more convoluted, but I think that it does a better job at
conveying that we are not owners of the packages we maintain, but rather
that we are taking care of a small part of a greater whole, governed by
rules and processes that enable it to be resilient to maintainers being
away/busy or leaving the project, or to technical disagreements. And
actually many of the hardest things we have done over the years have
been about building those balanced rules and processes, maybe more than
solving technical issues.

And note that it's also why we have rules or strong recommendations
such as using Debian infrastructure to maintain Debian packages, and
thus why you should not be using GitHub for the packages you maintain.

Lucas

Re: Lucas Kanashiro and Athos Ribeiro fixed my package and i didnt like it

[Holger Levsen]

Dear Lucas,

(it was really nice to meet you in Curitiba and I'm looking forward to
meet you again in the next weeks in Sao Paulo!)

Please relay my condolences to Athos, I wish this wouldnt have
demotivated him, though I'd totally understand if he spents his time on
more fun things to do in future.

I really don't get the fuzz about your upload. As I see it, you fixed 4
problems and made 2 (easily fixable) mistakes, which could have been
fixed easily if pointed out nicely, eg. via a bug. And the upload was
definitly justified (even if done badly), as we have 0-day NMUs for RC
bugs. (I'm not gonna count Rolfs mistakes here, nor his good work.) 

So, tl;dr;: all the best to you two!

and should I ever again reply to this thread on debian-devel, I will hit
myself with a hammer on the head. so sad.


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Re: alioth deprecation - next steps

[Alexander Wirt]

On Tue, 17 Apr 2018, Bill Allombert wrote:

> On Tue, Apr 17, 2018 at 01:00:56PM +0200, Alexander Wirt wrote:
> > Hi,
> > 
> > as you should be aware, alioth.debian.org will be decommissioned with
> > the EOL of wheezy, which is at the end of May. The replacement for
> > the main part of alioth, git, is alive and out of beta, you know it
> > as salsa.debian.org. If you did not move your git repository yet,
> > hurry up, time is running out.
> > 
> > The other important service from the alioth set, lists, moved to a
> > new host and is now live at https://alioth-lists.debian.net [1].
> > All public list archives moved over too and will continue to exist
> > under the old URL.
> 
> What about the most basic service, the download page ?
> (like )
> 
> According to 
> 
> there is no equivalent on salsa.
> 
> git tags are not a suitable alternative because true release tarballs
> include files generated by autotools (among others) that are not in
> git, and git tags tarballs are not signed (signed tags is an different
> concept).
> 
> This unfortunately makes salsa unsuitable as a project homepage.
Create a gitlab-ci job, build your files and provide them under a gitlab
page. So you are wrong, salsa can work as it. 

Alex
 

Re: Completed: lists.alioth.debian.org migration

[Dominic Hargreaves]

On Tue, Apr 17, 2018 at 10:39:22PM +0200, Christoph Biedl wrote:
> A few questions, though (asking for a friend, of course). It might have
> been mentioned before but I have missed it then.
> 
> What is the long-term plan for this service? Indefinitely, or are users
> kindly asked to move away from these addresses when convenient? In the
> latter case lintian should emit according hints since even then this
> might take several years.

We committed to supporting it for 1-2 release cycles. Speaking for myself,
I plan to take a step back after the dust has settled and we see how
running the service works out before setting a firm timeline.

> Also, @lists.alioth.debian.org addresses that were *not* migrated now
> result in bounces as expected. Are there already plans for a MBF
> severity RC against all packages with a now-failing maintainer address?
> This might become rather messy, I've counted some 1450 packages.

I wasn't planning this work. I must admit that I did not check the numbers
but I am surprised it is so high. Can you share the results of
that analysis? It would be interesting to see what the distribution of
packages to lists is.

Thanks,
Dominic.

Re: my package was fixed by someone else and i dont like that

[Holger Levsen]

On Tue, Apr 17, 2018 at 08:38:52PM +0300, Adrian Bunk wrote:
> You could make the point that he should have posted to debian-private
> instead of debian-devel.

Rolf is a DM, so he cannot read debian-private and he might not even
know it exists.

> In any case naming the people who did this is required,

sure, but not in the subject

> and IMHO the package hijack is a much worse offense than
> naming the offenders in an email subject.

you kick me in the face and then i can kick you in the belly, because
that's less bad?

> > 2nd, Athos' upload didnt remove you from uploaders, so "hijacked" is the
> > wrong word as well.
> Changing the Maintainer: field without any previous attempt to 
> contact the maintainer makes it a clear hijack.

only if you differate being listed in the maintainers: or uploaders:
field. *I* wouldnt care about such a distinction.

> > 3rd, why oh why did you reintroduce fixed bugs like 876571? (I'd
> > understand if you just reverted everything the next day but 3 weeks
> > after their upload the urgency is gone...) 
> >...
> At what time does a victim notice that their package was hijacked?

please put "victim" in quotes, noone got harmed here.

and to still answer: Rolf was kept in the uploaders: field, so he was
informed, so your argument is moot.

check 
https://snapshot.debian.org/archive/debian/20180324T213403Z/pool/main/g/gjots2/gjots2_2.4.1-3.dsc

> You are publicly blaming the victim.

"victim". you are publicically demoting real victims here.

> Do you have any proof that the victim was actually notified in any
> way at the time of the hijack?

no, I don't monitor Rolf's incoming email that well.


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Re: alioth deprecation - next steps

[Bill Allombert]

On Tue, Apr 17, 2018 at 01:00:56PM +0200, Alexander Wirt wrote:
> Hi,
> 
> as you should be aware, alioth.debian.org will be decommissioned with
> the EOL of wheezy, which is at the end of May. The replacement for
> the main part of alioth, git, is alive and out of beta, you know it
> as salsa.debian.org. If you did not move your git repository yet,
> hurry up, time is running out.
> 
> The other important service from the alioth set, lists, moved to a
> new host and is now live at https://alioth-lists.debian.net [1].
> All public list archives moved over too and will continue to exist
> under the old URL.

What about the most basic service, the download page ?
(like )

According to 

there is no equivalent on salsa.

git tags are not a suitable alternative because true release tarballs
include files generated by autotools (among others) that are not in
git, and git tags tarballs are not signed (signed tags is an different
concept).

This unfortunately makes salsa unsuitable as a project homepage.

Cheers,
Bill.

Re: hijack my thread

[Wookey]

On 2018-04-17 12:27 -0700, Steve Langasek wrote:
> On Tue, Apr 17, 2018 at 12:49:36PM +0100, Wookey wrote:
> > On 2018-04-17 13:15 +0800, Rolf Leggewie wrote:
> 
> > > the ticket now does
> > > serve a purpose in documenting publicly why there was no upload to
> > > gjots2 in unstable over many years.  The reason given is still valid,
> > > that hasn't changed, no update needed there. It sums up the state of
> > > gjots2 pretty well and thus for the sake of not spreading fake news let
> > > me quote it here.
> 
> > ---
> 
> > > > Thank you for your report.  There are ways in Debian to inform the
> > > > maintainer automatically about new upstream releases (debian/watch).
> > > > Specifically opening bug tickets about new upstream versions being
> > > > available doesn't really help much.
> 
> > > > I had had a look at the new upstream quite a while ago and found
> > > > several bugs so I reported them upstream and held off releasing
> > > > to Debian.
> 
> > > > https://sourceforge.net/p/gjots2/bugs/
> 
> > Someone new to this can't tell from this message or that list of 20 bugs
> > (none of which obvisouly have your name on), what it is about the
> > package which is so buggy that a new version cannot be uploaded.
> 
> > It would help if you actually explained the issue, or at least said
> > which of those bugs were relevant.
> 
> To what end? 

To the end of clear communication for people wondering what's going on

> Are we then going to vote on whether Rolf's decision to defer
> the new upstream releases was technically sound, before we will recognize as
> valid his feelings of frustration that Debian's norms and policies were not
> followed?

No, it would just somewhat defuse the complaint that he appeared to be
an absent maintainer.

> Is our response to a complaint that a maintainer's rights[*] have
> not been respected, to further punish the maintainer by collectively
> usurping that position for ourselves?

No, but if you've been clear about why the package is stuck at
$4-year-old-version then a) someone is probably less likely to hijack
it in the first place, and b) when someone does hijack it, and you
complain and some people critise you (likely round here) you can point
to your clear communication, and it is obvious to all that the
hijackers have acted unreasonably (as opposed to it looking a bit
50:50 and everyone taking sides).

I don't have a dog in this fight (I have never heard of any of these
people or packages before). I was just expressing the impression I
formed when Rolf claimed he'd been clear about why there had been no
uploads for 4 years. I'm not suggesting that no-communication
hijacking is OK.
 
> But by my
> reckoning, that means we should be trying to get our noses out rather than
> sticking them further in.

Possibly. Bit late for that if you ask me :-)

Anyway. I'm going cycling for a week, so you are very unlikely to hear
from me again on this matter, which, as you say, is probably a good
thing. :-)

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Re: Bits from the release team: full steam ahead towards buster

[Philipp Kern]

On 17.04.2018 22:34, Christoph Biedl wrote:
> Also, choosing the names in sorted order (modulo wraparound) would
> create a list in historic order of the releases, easing some assessment
> when talking about releases. That's what Ubuntu does, although using
> consecutive letters is nice but not necessary in my opintion. And yes,
> sid is a problem then. It would hit us in around the year 2055. I expect
> to be stable by then. Stable six feet under.

Turns out that this is a terrible idea. We should use numeric values for
sorting. (And Ubuntu now does the same thing on the technical side.)

Kind regards
Philipp Kern

Re: Completed: lists.alioth.debian.org migration

[Holger Levsen]

On Tue, Apr 17, 2018 at 10:39:22PM +0200, Christoph Biedl wrote:
> Also, @lists.alioth.debian.org addresses that were *not* migrated now
> result in bounces as expected. Are there already plans for a MBF
> severity RC against all packages with a now-failing maintainer address?
> This might become rather messy, I've counted some 1450 packages.

please file bugs, so that autoremovals can kick in. Thanks.


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Re: hijack my thread

[Geert Stappers]

On Tue, Apr 17, 2018 at 12:27:03PM -0700, Steve Langasek wrote:
> > > https://sourceforge.net/p/gjots2/bugs/
> > Someone new to this can't tell from this message or that list of 20 bugs
> > (none of which obvisouly have your name on), what it is about the
> > package which is so buggy that a new version cannot be uploaded.
> 
> > It would help if you actually explained the issue, or at least said
> > which of those bugs were relevant.
> 
> To what end?  Are we then going to vote on whether Rolf's decision to defer
> the new upstream releases was technically sound, before we will recognize as
> valid his feelings of frustration that Debian's norms and policies were not
> followed?  Is our response to a complaint that a maintainer's rights[*] have
> not been respected, to further punish the maintainer by collectively
> usurping that position for ourselves?
> 
> Now, I don't think this thread should ever have been begun the way it was on
> debian-devel.  There are appropriate ways to provide feedback to the DAM and
> the NM team that don't involve publicly naming and shaming people on
> Debian's highest-profile technical mailing list; and the general problem
> could be discussed here without needing to name anyone.  But by my
> reckoning, that means we should be trying to get our noses out rather than
> sticking them further in.

+1



Long version:  Wise words, thank you Vorlon for writing them.
 (yes, that is a compliment)


Groeten
Geert Stappers
-- 
Leven en laten leven

Re: Completed: lists.alioth.debian.org migration

[Christoph Biedl]

Mathias Behrle wrote...

> Big thanks to all involved also from my side, it is great to have the mailing
> lists seamlessly running!

Seconded.


A few questions, though (asking for a friend, of course). It might have
been mentioned before but I have missed it then.

What is the long-term plan for this service? Indefinitely, or are users
kindly asked to move away from these addresses when convenient? In the
latter case lintian should emit according hints since even then this
might take several years.

Also, @lists.alioth.debian.org addresses that were *not* migrated now
result in bounces as expected. Are there already plans for a MBF
severity RC against all packages with a now-failing maintainer address?
This might become rather messy, I've counted some 1450 packages.

Christoph


signature.asc
Description: PGP signature

Re: Bits from the release team: full steam ahead towards buster

[Christoph Biedl]

Emilio Pozuelo Monfort wrote...

> We are about halfway through the buster development cycle, and a release
> update was overdue.

Thanks for all the updates, let's make this an exiting ride.


But briefly bleating by boldly bringing balking bits ...

> Future codenames
> 

So we'll see three consecutives releases starting with the letter "b":
buster, bullseye, bookworm - quite funny and I reckon it's no
coincidence. However, it's bad idea.

There are people who don't follow every single action in Debian, plain
stables users for example. For them it's helpful to tell the releases
apart easily as they might not have the precise names and their order in
mind. The first letter is a fairly simple way to aid this.

Also, people who do any kind of work related to releases would likely
use the names as an identifier, directory and screen session names in my
case. Different starting letters speed up tab completion and similar
matching procedures. Just another letter to type (or even two for buster
vs. bullseye) might sound like nothing, but in the long run it shows.
I might switch to the release numbers then which gives a sad feeling of
loosing some color in the work.


Probably it's too late to revert the decision. But for future codenames
I'm asking you to choose names in a way these aspects are considered as
well - and I regret I never sent this mail right after the buster and
bullseye name announcement as I wanted to.

So, please use names that are really easy to tell apart. Having unique
initial letters among all supported release is an essential part of
it. Taking also the symlinks into account was worth a consideration
although this would block any name starting with "e", "o", "s", "t", or
"u".

Also, choosing the names in sorted order (modulo wraparound) would
create a list in historic order of the releases, easing some assessment
when talking about releases. That's what Ubuntu does, although using
consecutive letters is nice but not necessary in my opintion. And yes,
sid is a problem then. It would hit us in around the year 2055. I expect
to be stable by then. Stable six feet under.

Christoph


signature.asc
Description: PGP signature

Re: Usage of real m68k hardware

[Ingo Jürgensmann]

Am 17.04.2018 um 19:15 schrieb Thorsten Glaser :

>> Yes, of course. But Andreas hit a nerve with this on me. This project
>> has cost me lots of blood, tears and sweat and if someone is asking
>> for it to be completely thrown out out of nothing, I'm getting a bit
>> stressed out.
> I completely agree here. While I’m no longer involved with the
> m68k port specifically, after having spent THREE YEARS of blood,
> sweat and pain to resurrect it, there are several reasons:

I’m still very thankful for your efforts! Really!

> • I have come to actually like that, having been a die-hard 8088
>  user in my childhood, and found the people and community very
>  interesting
>  ‣ there are fun projects like a PCI bridge, which allows using
>a PCI Radeon graphics card with LCDs at 1900x12something
>resolution, currently with GEM/AES only, not yet in Linux

Actually there are some nice developments like 
http://www.apollo-accelerators.com/ to increase the speed of m68k for quite a 
few bugs. 

> • it sends a signal, and the wrong signal in my eyes, that
>  everything not-mainstream is not worth to be supported
>  ‣ specialisation is for downstreams, Debian should stay universal
>  ‣ read up on monoculture in agriculture and why everyone, by now,
>thinks it’s a bad idea
>⇒ hint: Meltdown/Spectre…

Yes, I think this is the main problem since m68k has been kicked out as a 
release arch. This whole second class architecture is a mistake, IMHO. Another 
approach would have been better, like focussing on being release-ready only for 
base and other essential packages, but not the whole archive. 
This effectively killed m68k in the long run. Other archs followed then. 

> • I found Debian ports very useful to gain deep insight on
>  how Debian and all of its components work, and can recommend
>  porting a new or resurrecting an old architecture to everyone
>  wishing to peek below the surface

That’s maybe the only positive thing that evolved in the aftermaths of kicking 
out m68k: a parallel infrastructure was developped that could act without all 
those complicated formalisms of official buildds (at least in the early days). 
But I think this could have been achieved without kicking archs out of Debian. 

I think especially m68k did a great job in teaching many DDs how to deal with 
autobuilders and such. Buildd & co were built, because of m68k and Debian. The 
very first buildd was running on kullervo. 

> On the more technical side, while Adrian’s buildds are qemu,
> I’ve continued running an ARAnyM (also emulation, but different
> and thanks to Doko even FPU-complete) buildd for as long as the
> system it was hosted on allowed me to do so. (That GPLhost domU
> is currently unusable because of spontaneous reboots and other
> problems. I might look into running one on some other system;
> I have a couple of VMs on my workplace desktop but can’t use
> those as they are bridged into the company LAN.)

I’m still not a big fan of emulated buildds. ;-) 
But I have to admit that they are way faster than the old, real hardware.

> We also have a number of Amiga and Atari and I believe at least
> one or two Macintosh systems which, at one point or the other,
> are or were in use as buildds and/or porterboxen.

Well, the last info from buildd.net database: 

buildd=# select name, model, cpu, ram from status where arch='m68k';
name|   model   |  cpu   | ram
+---++-
 washi  | Atari Falcon CT60 | 68060/66   | 256
 prometheus | Aranym/distcc | 733MHz PowerPC | 256
 minthe | Aranym| 8*Xeon 2G  | 768
 phoebe | Aranym| 8*Xeon 2G  | 768
 hobbes | Atari Falcon CT60 | 68060/95   | 512
 merlin | Amiga 1200| 68030/56   |  64
 elgar  | Amiga 4000| 68060/50   | 128
 kullervo   | Amiga 3000UX  | 68060/50   | 128
 crest  | Amiga 4000| 68060/50   | 128
 pacman | ARAnyM| VM040/240  | 512
 vivaldi| Amiga 4000T   | 68060/50   | 384
 theia  | Aranym| Dual 1.8 GHz   | 750
 wario  | ARAnyM| VM040/180  | 768
 zlin3  | Aranym| i386   |  64
 spice  | Amiga 3000| 68040/40   | 320
 aahz   | Amiga 2000| 68060/50   | 128
 akire  | Amiga 2000| 68060/50   | 128
 ara5   | ARAnyM| VM040/170  | 782
 arrakis| Amiga 3000| 68060/50   | 384
 kirby  | ARAnyM| VM040/214  | 512
 pikachu| ARAnyM| VM040/200  | 768
(21 rows)

At least crest, akire and elgar might be still online, maybe kullervo as well, 
but Christian can comment on this, while spice, arrakis & vivaldi are currently 
offline as in powered off or has a NIC that is currently not supported by Linux 
(spice).

I’m not totally opposed in powering on one or two machines again, but it’s a 
matter of ti

hijack my thread

[Steve Langasek]

On Tue, Apr 17, 2018 at 12:49:36PM +0100, Wookey wrote:
> On 2018-04-17 13:15 +0800, Rolf Leggewie wrote:

> > the ticket now does
> > serve a purpose in documenting publicly why there was no upload to
> > gjots2 in unstable over many years.  The reason given is still valid,
> > that hasn't changed, no update needed there. It sums up the state of
> > gjots2 pretty well and thus for the sake of not spreading fake news let
> > me quote it here.

> ---

> > > Thank you for your report.  There are ways in Debian to inform the
> > > maintainer automatically about new upstream releases (debian/watch).
> > > Specifically opening bug tickets about new upstream versions being
> > > available doesn't really help much.

> > > I had had a look at the new upstream quite a while ago and found
> > > several bugs so I reported them upstream and held off releasing
> > > to Debian.

> > > https://sourceforge.net/p/gjots2/bugs/

> Someone new to this can't tell from this message or that list of 20 bugs
> (none of which obvisouly have your name on), what it is about the
> package which is so buggy that a new version cannot be uploaded.

> It would help if you actually explained the issue, or at least said
> which of those bugs were relevant.

To what end?  Are we then going to vote on whether Rolf's decision to defer
the new upstream releases was technically sound, before we will recognize as
valid his feelings of frustration that Debian's norms and policies were not
followed?  Is our response to a complaint that a maintainer's rights[*] have
not been respected, to further punish the maintainer by collectively
usurping that position for ourselves?

Now, I don't think this thread should ever have been begun the way it was on
debian-devel.  There are appropriate ways to provide feedback to the DAM and
the NM team that don't involve publicly naming and shaming people on
Debian's highest-profile technical mailing list; and the general problem
could be discussed here without needing to name anyone.  But by my
reckoning, that means we should be trying to get our noses out rather than
sticking them further in.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org

[*] used loosely, but I can find no better word to express this


signature.asc
Description: PGP signature

Bug#895948: ITP: detachtty -- Utility to connect to detached interactive programs

[Giovanni Mascellani]

Package: wnpp
Severity: wishlist
Owner: Giovanni Mascellani 

* Package name: detachtty
  Version : 11.0.0
  Upstream Author : Massimiliano Ghilardi
  
* URL : https://github.com/cosmos72/detachtty
* License : GPL-2+
  Programming Lang: C
  Description : Utility to connect to detached interactive programs

Detachtty lets you run interactive programs non-interactively, and connect
to them over the network when you do need to interact with them. It is
somewhat similar to screen, but it is less feature-rich, therefore
lighter and with less dependencies. It allows to connect to programs
running on remote hosts by mean of secure SSH connections.

Detachtty was removed from Debian because it was dead upstream. Now the
upstream development has been resumed by another developer, so it is
sensible to repackage it.

Re: my package was fixed by someone else and i dont like that

[Adrian Bunk]

On Mon, Apr 16, 2018 at 12:43:57PM +, Holger Levsen wrote:
> Rolf,
> 
> first of all, you immediatly lost your argument by putting peoples name
> in the subject of a mail to debian-devel. This is really bad style
> (called fingerpointing) and I wish you hadn't done this. Based on this
> behaviour alone, I wouldnt recommend *you* becoming a DD or DM, at least
> not now.

You could make the point that he should have posted to debian-private
instead of debian-devel.

In any case naming the people who did this is required,
and IMHO the package hijack is a much worse offense than
naming the offenders in an email subject.

> 2nd, Athos' upload didnt remove you from uploaders, so "hijacked" is the
> wrong word as well.

Changing the Maintainer: field without any previous attempt to 
contact the maintainer makes it a clear hijack.

> 3rd, why oh why did you reintroduce fixed bugs like 876571? (I'd
> understand if you just reverted everything the next day but 3 weeks
> after their upload the urgency is gone...) 
>...

At what time does a victim notice that their package was hijacked?

You are publicly blaming the victim.

Do you have any proof that the victim was actually notified in any
way at the time of the hijack?

> cheers,
>   Holger

cu
Adrian

-- 

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

Re: Usage of real m68k hardware

[Thorsten Glaser]

Adrian wrote:

>Yes, of course. But Andreas hit a nerve with this on me. This project
>has cost me lots of blood, tears and sweat and if someone is asking
>for it to be completely thrown out out of nothing, I'm getting a bit
>stressed out.

I completely agree here. While I’m no longer involved with the
m68k port specifically, after having spent THREE YEARS of blood,
sweat and pain to resurrect it, there are several reasons:

• odd architectures *do* help in finding odd bugs, often before
  they hit other architectures where they’re hidden by, for
  example, compiler optimisations (more aggressive inlining)
  or arch-specific asm code, until these hiding things no longer
  appear

  ‣ granted, m68k has this specific “2-byte alignment” thing,
but then, anything that actually relies on the precise amount
of struct padding is relying on IB/UB in the first place and,
with that, buggy

• I have come to actually like that, having been a die-hard 8088
  user in my childhood, and found the people and community very
  interesting
  ‣ there are fun projects like a PCI bridge, which allows using
a PCI Radeon graphics card with LCDs at 1900x12something
resolution, currently with GEM/AES only, not yet in Linux

• it sends a signal, and the wrong signal in my eyes, that
  everything not-mainstream is not worth to be supported

  ‣ specialisation is for downstreams, Debian should stay universal

  ‣ read up on monoculture in agriculture and why everyone, by now,
thinks it’s a bad idea
⇒ hint: Meltdown/Spectre…

• I’m running (and helping to work on) x32… another port

• I found Debian ports very useful to gain deep insight on
  how Debian and all of its components work, and can recommend
  porting a new or resurrecting an old architecture to everyone
  wishing to peek below the surface

• I’ve heard someone’s working on making dak dports-capable,
  solving the current worst problem of the fact we use mini-dak
  in that NBS packages are removed from the archive even if
  they’re still Depended upon, which made me really excited
  about dports work


On the more technical side, while Adrian’s buildds are qemu,
I’ve continued running an ARAnyM (also emulation, but different
and thanks to Doko even FPU-complete) buildd for as long as the
system it was hosted on allowed me to do so. (That GPLhost domU
is currently unusable because of spontaneous reboots and other
problems. I might look into running one on some other system;
I have a couple of VMs on my workplace desktop but can’t use
those as they are bridged into the company LAN.)

We also have a number of Amiga and Atari and I believe at least
one or two Macintosh systems which, at one point or the other,
are or were in use as buildds and/or porterboxen.

I’ve also made a point in making ready-to-use ARAnyM images
in the Debian wiki which any maintainer could use to run a
box locally, due to the lack of currently-accessible porterboxen.
This has eroded a bit since I moved away from m68k.

I don’t know how the actual hardware can be helped to become
more usable. I also don’t know if the standard Debian porterbox
setup can be used on/for them. DSA normally does these things;
in dports we want to make things as closely to the main Debian
as possible, but as long as dports are officially unsupported,
it’s hard. (Also, you’d have to talk to Ingo, perhaps Adrian
and ragnar76 about the actual hardware.)

As for the “qemu bug” issue, using an ARAnyM, Amiga, Atari
or Macintosh machine to retry the build (since they all are
slower, although my previous desktop could emulate a 200 MHz
m68k with ARAnyM) before complaining would certainly help.
But this is also not easy, and only a few problems are caused
by qemu issues (I’m actually surprised, I’d have not thought
a qemu-based buildd a viable solution, and I recall Adrian
and me fighting a bit over it initially), so I don’t understand
An3as’ violent reaction.

Contrasted to that, x32 hardware is actually easy: use an amd64
system with “syscall.x32=y” in GRUB_CMDLINE_LINUX then just use
a foreign-arch chroot with pbuilder/cowbuilder or schroot/sbuild
like you would with i386. (I’ve had two cases in which an FTBFS
was actually a hiccup of the buildd, or a difference in host CPU,
and which built just fine on my system, again, in a clean&minimal
environment, so I just did a porter upload.) These are dead useful
to reproduce issues, by the way.


It might also be useful to create one or two buildds with
large hard discs (and possibly RAM) since some of the recent
packages (gcc-*-cross-* most prominently) make Adrian’s
systems explode… especially as his virtual buildds share
(limited) space.


Adrian is currently the single most-involved person driving
debian-ports forwards, on a *lot* of architectures, (not saying
there are no other porters) so I can understand his frustration.

I might even look if I can help any further. Unfortunately, as
I said above, I have no easy solution for running a buildd or
porterbox (c

Re: Bug#895928: ITP: python-base58 -- base58 encode/decode for Python

[Daniele Nicolodi]

On 4/17/18 8:57 AM, Joel Cross wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Joel Cross 
> 
> * Package name: python-base58
>   Version : 0.2.5
>   Upstream Author : David Keijser 
> * URL : https://github.com/keis/base58
> * License : MIT
>   Programming Lang: Python
>   Description : base58 encode/decode for Python
> 
> This package contains the following functions, in a form compatible with that
> used by the bitcoin network:
> - b58encode
> - b58decode
> - b58encode_check
> - b58decode_check

Hi Joel,

I had a look at this Python package a while ago, and I was very
surprised to find that its interface does not match the one of the
functions in the base64 standard library module in the use of strings vs
bytes.  I had to introduce some wrappers to make it sane in that regard.

I see in the upstream repository some commits that suggest that this has
been fixed (breaking the API probably).  However, nothing that hints
that a release has been made after that.

It would be nice to have the fixed version in Debian and to avoid API
breakage, at least once the Python package enters the Debian archive.

Cheers,
Dan

Re: alioth deprecation - next steps

[Alexander Wirt]

On Tue, 17 Apr 2018, Holger Levsen wrote:

Hi Holger, 

> Alexander, thanks for the update on the alioth migration!
> 
> On Tue, Apr 17, 2018 at 01:00:56PM +0200, Alexander Wirt wrote:
> > 17.-20.05.18: During the Mini-DebConf Hamburg any existing cron jobs will 
> > be turned off, websites still on alioth will be disabled.
> 
> we currently use https://reproducible.alioth.debian.org/blog/ and this
> address has been spread wide and far. Do you think it would be possible
> to redirect reproducible.alioth.debian.org on the DNS level to say,
> blog.reproducible-builds.org?
This is probably possible by talking to DSA. 

Alex



signature.asc
Description: PGP signature

Re: salvaging packages, was Re: Lucas Kanashiro and Athos Ribeiro salvaged my package

[Sean Whitton]

Hello gustavo,

On Tue, Apr 17 2018, gustavo panizzo wrote:

> Besides the thread, are you aware of anything written down somewhere?

Yes.  Take a look on gobby (apt-get install gobby and connect to
gobby.debian.org).

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: alioth deprecation - next steps

[Holger Levsen]

Alexander, thanks for the update on the alioth migration!

On Tue, Apr 17, 2018 at 01:00:56PM +0200, Alexander Wirt wrote:
> 17.-20.05.18: During the Mini-DebConf Hamburg any existing cron jobs will be 
> turned off, websites still on alioth will be disabled.

we currently use https://reproducible.alioth.debian.org/blog/ and this
address has been spread wide and far. Do you think it would be possible
to redirect reproducible.alioth.debian.org on the DNS level to say,
blog.reproducible-builds.org?


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#895928: ITP: python-base58 -- base58 encode/decode for Python

[Joel Cross]

Package: wnpp
Severity: wishlist
Owner: Joel Cross 

* Package name: python-base58
  Version : 0.2.5
  Upstream Author : David Keijser 
* URL : https://github.com/keis/base58
* License : MIT
  Programming Lang: Python
  Description : base58 encode/decode for Python

This package contains the following functions, in a form compatible with that
used by the bitcoin network:
- b58encode
- b58decode
- b58encode_check
- b58decode_check

Re: MBF proposal: python modules that fail to import

[Herbert Fortes]

Em 16-04-2018 17:16, Helmut Grohne escreveu:
> On Mon, Apr 16, 2018 at 04:14:21PM -0300, Herbert Fortes wrote:
>> Package python3-dj-static is on the dd-list. But I can import it.
>>
>> # on a bananapi
>>
>> $ python3
>> Python 3.5.3 (default, Jan 19 2017, 14:11:04) 
>> [GCC 6.3.0 20170124] on linux
>> Type "help", "copyright", "credits" or "license" for more information.
> import static # dependency
> import dj_static  # module
>
> 
> For most of these bug reports there exists a setting in which the
> modules can be imported. E.g. a significant chunk of them becomes
> importable after installing python3-pkg-resources.
> 
>> If I understood correct (about the test), please note the diff:
>>
>> python3-dj-static  # Debian package
>> dj_static  # module
>>
>> The package name uses '-' and the module '_'.
> 
> In my initial mail there is a draft.gz that contains the proposed bug
> reports. Searching for python3-dj-static yields:
> 
> | After installing python3-dj-static importing the module dj_static
> | into a python interpreter fails with the following error:
> | 
> | Traceback (most recent call last):
> |   File "", line 1, in 
> |   File "/usr/lib/python3/dist-packages/dj_static.py", line 5, in 
> | from django.conf import settings
> | ModuleNotFoundError: No module named 'django'
> 
> So my heuristic did select the right module and it failed to import,
> because no dependency on python3-django was declared. Thus the bug
> report seems legitimate to me.
> 
-1 bug report. :)

running checksum: verify checksums before uploading
running suite-mismatch: check the target distribution for common errors
running gpg: check GnuPG signatures before the upload
Uploading dj-static_0.0.6-5.dsc
Uploading dj-static_0.0.6.orig.tar.gz
Uploading dj-static_0.0.6-5.debian.tar.xz
Uploading dj-static_0.0.6-5_amd64.buildinfo
Uploading dj-static_0.0.6-5_amd64.changes

Re: missing recommends are not RC severity

[Roberto C . Sánchez]

On Tue, Apr 17, 2018 at 09:21:31AM -0400, Jeremy Bicha wrote:
> On Tue, Apr 17, 2018 at 9:16 AM, Holger Levsen  wrote:
> > (not sure this makes sense as the practical impact is a normal bug, but
> 
> Since I was CC'd on this email and I've filed several Serious bugs for
> this issue, here is what I've been using lately:
> 
> "It is my understanding that is a RC bug for package to recommend a
> library that has been removed from Testing because recommended
> packages won't be auto-removed on upgrade."
> 
> That means users will have libraries installed that will not get any
> security support. I think that's an RC issue.
> 
Except that the reasoning breaks down when you consider that
auto-removal of packages is a function of the package management front
end and not of dpkg itself (which is responsible for validating the
relationships between packages).

There are plenty of available tools to identify system cruft, including
packages that are no longer receiving security support and packages
which do not exist in the current suite/release for which the system is
configured.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: missing recommends are not RC severity

[Jeremy Bicha]

On Tue, Apr 17, 2018 at 9:16 AM, Holger Levsen  wrote:
> (not sure this makes sense as the practical impact is a normal bug, but

Since I was CC'd on this email and I've filed several Serious bugs for
this issue, here is what I've been using lately:

"It is my understanding that is a RC bug for package to recommend a
library that has been removed from Testing because recommended
packages won't be auto-removed on upgrade."

That means users will have libraries installed that will not get any
security support. I think that's an RC issue.

Thanks,
Jeremy Bicha

Re: missing recommends are not RC severity

[Holger Levsen]

On Tue, Apr 17, 2018 at 01:04:47PM +, Scott Kitterman wrote:
> >if your package recommends a package which is not available, this is a
> >normal bug, not one with RC severity (and neither an important one).
> 
> Policy 2.2.1 pretty clearly says otherwise.

wow, I stand corrected, thanks.

(not sure this makes sense as the practical impact is a normal bug, but
that wasn't the question here. also slightly wondering whether "outside
of main" here really ment non-free and contrib, but not non-existing...)


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Re: missing recommends are not RC severity

[Andrey Rahmatullin]

On Tue, Apr 17, 2018 at 01:04:47PM +, Scott Kitterman wrote:
> >if your package recommends a package which is not available, this is a
> >normal bug, not one with RC severity (and neither an important one).
> 
> Policy 2.2.1 pretty clearly says otherwise.
Whlile the release policy says "Packages in main cannot require any
software outside of main for execution or compilation. "Recommends:" lines
do not count as requirements."

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: missing recommends are not RC severity

[Scott Kitterman]

On April 17, 2018 12:52:32 PM UTC, Holger Levsen  wrote:
>folks,
>
>if your package recommends a package which is not available, this is a
>normal bug, not one with RC severity (and neither an important one).

Policy 2.2.1 pretty clearly says otherwise.

Scott K

missing recommends are not RC severity

[Holger Levsen]

folks,

if your package recommends a package which is not available, this is a
normal bug, not one with RC severity (and neither an important one).


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Re: Lucas Kanashiro and Athos Ribeiro hijack my package

[Wookey]

On 2018-04-17 13:15 +0800, Rolf Leggewie wrote:

> the ticket now does
> serve a purpose in documenting publicly why there was no upload to
> gjots2 in unstable over many years.  The reason given is still valid,
> that hasn't changed, no update needed there. It sums up the state of
> gjots2 pretty well and thus for the sake of not spreading fake news let
> me quote it here.


---

> > Thank you for your report.  There are ways in Debian to inform the
> > maintainer automatically about new upstream releases (debian/watch).
> > Specifically opening bug tickets about new upstream versions being
> > available doesn't really help much.
> >
> > I had had a look at the new upstream quite a while ago and found
> > several bugs so I reported them upstream and held off releasing
> > to Debian.
> >
> > https://sourceforge.net/p/gjots2/bugs/

Someone new to this can't tell from this message or that list of 20 bugs
(none of which obvisouly have your name on), what it is about the
package which is so buggy that a new version cannot be uploaded.

It would help if you actually explained the issue, or at least said
which of those bugs were relevant.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Re: MBF proposal: python modules that fail to import

[Herbert Fortes]

> 
> In my initial mail there is a draft.gz that contains the proposed bug
> reports. Searching for python3-dj-static yields:
> 
> | After installing python3-dj-static importing the module dj_static
> | into a python interpreter fails with the following error:
> | 
> | Traceback (most recent call last):
> |   File "", line 1, in 
> |   File "/usr/lib/python3/dist-packages/dj_static.py", line 5, in 
> | from django.conf import settings
> | ModuleNotFoundError: No module named 'django'
> 
> So my heuristic did select the right module and it failed to import,
> because no dependency on python3-django was declared. Thus the bug
> report seems legitimate to me.
> 

That is true. The package does not make sense without Django. It is
a Django middleware. 

I also checked manually in a chroot without Django and got an 'ImportError'.

I will fix the dependency.



Regards,
Herbert

Bug#895891: ITP: golang-github-vimeo-go-magic -- Go bindings for libmagic

[Sascha Steinbiss]

Package: wnpp
Severity: wishlist
Owner: Sascha Steinbiss 

* Package name: golang-github-vimeo-go-magic
  Version : 0.0~git20180208.aff138d-1
  Upstream Author : Vimeo, LLC.
* URL : https://github.com/vimeo/go-magic
* License : BSD-2-clause
  Programming Lang: Go
  Description : Go bindings for libmagic

Go-magic is a Golang library that wraps libmagic and provides API functions
for file type detection. it also provides an API for getting a file's MIME
type using libmagic.

Re: hijack of gjots2 package

[Jeremy Bicha]

On Tue, Apr 17, 2018 at 1:02 AM, Rolf Leggewie  wrote:
> I am happy you and Athos want to contribute to Debian.  My beef is that
> you need to do it the proper way (failure #1).  And that you need to own
> up to and correct in a reasonable time frame mistakes you make (failure
> #2).

So you gave Lucas 4 days to act before you publicly shamed him. Did
you tell him about that deadline in advance?

Meanwhile, you haven't made an upload for your package in 4 years and
you *never* replied to https://bugs.debian.org/876571 (open for 7
months, and the bug that the failed NMU fixed and you reintroduced).

> I would not have made this public if you hadn't failed me the
> second time around as well, leaving me little time to push "RC bug"
> #876571 to bionic (yes, I do want that Recommends in there for that LTS).

Which one and why? You re-introduced 2 recommends, both of which are
not in Testing and at high risk of being removed from Ubuntu very
soon. (In other words, they are RC bugs in Ubuntu too.)

I guess the fact that Ubuntu 18.04 "bionic" will be released very soon
helps explains a bit your newfound sense of urgency with gjots2. But
let me suggest that since you have upload rights to Ubuntu, you could
have made your change in Ubuntu without needing to make the same
change in Debian at the same time.

Of course the other person you shamed did not have the ability to do
the action you demanded. All of us have made mistakes. I think we
should be a lot more forgiving to new contributors instead of telling
everyone that you will object if he ever applies to become a DM. I
strongly hope that Athos does continue contributing to Debian and does
apply to be a DM.

Thanks,
Jeremy Bicha

salvaging packages, was Re: Lucas Kanashiro and Athos Ribeiro salvaged my package

[gustavo panizzo]

Hi

On Mon, Apr 16, 2018 at 09:43:10AM +0200, Andreas Tille wrote:
[snip]


I remember that this discussion comes up quite regularly (no statistic
but to my feeling once a year).  I'd love if we could give fix rules to
yes, yes, yes. I remember this conversation starting and fading every  
year or so (maybe each release cycle?. It doesn't matter)



the process of salvaging a package (or am I missing that this was just
done).  I think the preconditions should contain something like:

 (
  * RC buggy (mandatory feature for salvaging a package)


I'd put a note that discourages people from increasing the severity of   
a bug to RC and then take over the package maintenance

 or
  * No uploads for > 365 days *and* lagging behind upstream
 )
 and
  * Public attempt to contact the former maintainer (be it as
response to the RC bug or for instance CCed to debian-devel
list)

It should be also mandatory that the salvaged package gets Vcs-fields
pointing to salsa.debian.org to enable any interested person to


I'd go even further and require a specific workflow to be followed or a
choice between 2-3 workflows. (e.g. don't switch d/rules to cdbs, use

git)


contribute.  The former Maintainer may not be removed from d/control.
If the salvage is done by a team that should be used as maintainer and
the old maintainer moved to Uploaders.  The changelog owner of the
salvage upload should be added to Uploaders in any case to take over
responsibility for the work.

Opinions?


After the RC bug is open some time should be allowed to the maintainer to
act.
Just putting a number out there, 1 month after the package is removed from
testing _without_ activity in the bug from the maintainer process [1] could 
start.


On Mon, Apr 16, 2018 at 04:11:13PM +0800, Boyuan Yang wrote:

[snip]


Opinions?


I would suggest we exclude NMUs from "No uploads for > 365 days" requirement.


agreed



The person who want to salvage the package probably should also wait for two
weeks after initial public contact, then send another public email, wait for
another two weeks, send another public notification email before doing actual
salvaging efforts (moving packaging repo, uploading packages, etc). Idea
copied from QA/MIA process (https://wiki.debian.org/qa.debian.org/MIATeam).

[1] ^^

agreed, better to re-use established procedures


On Mon, Apr 16, 2018 at 10:26:08AM +0200, Philipp Kern wrote:
[snip]

copied from QA/MIA process 
(https://wiki.debian.org/qa.debian.org/MIATeam).


I know that I am someone who also lacks time quite often. But still, 
this kills a lot of velocity and I wonder how many people will be 
motivated enough to follow up through a whole month of waiting. On the 
other hand if that gives you a blanket "it's now yours, do with it as 
you see fit, including taking over ownership", maybe that's not so 
bad.

I think it strikes a balance, when you want to work on somebody else's
package you want to do it now, most likely, because you need the package
to be in good shape.
But at the same time you don't want to take a 2 weeks holiday without
computer to come back and find your packages under someone else's ownership

And still, 1-3 month is faster than a maintainer that may never come back



(There's of course also the question of VAC notices to crawl, though. 

What if before going in a long VAC (we are potentially talking about
1 year) the maintainer opens a bug in all its packages signaling that
he won't be around for a year and that people should not take over 
his packages.

That bug would open the door for 0 delay NMU

If someone went away for a longer period of time with an intent to 
come back, it should be fair game to fix the package and own related 
breakage but obviously not to just hijack it away from the original 
maintainer.)


how do you know that person is coming back if it never announces it?


On Mon, Apr 16, 2018 at 09:58:59AM +0200, Tobias Frost wrote:
[snip]


Was mentioned on the salvaging packages BoF at Montreal:  
https://lists.debian.org/debian-devel/2012/09/msg00654.html


Besides the thread, are you aware of anything written down somewhere?

--
IRC: gfa
GPG: 0X44BB1BA79F6C6333

Why I am (as of now) not using salsa

[Rolf Leggewie]

Hello,

some people inquired why I am not using salsa for hosting debian
packaging information in the "other" thread.  With alioth being
decomissioned I had to decide where to move.  Some of my upstreams and
co-maintainers are already doing their work in github.com, so it was a
natural choice.  Furthermore, I was a bit unhappy with the lack of
stable URI for the debian-hosted git services.  I think I started out on
alioth.debian.org, then moved to git.debian.org a year later, only to
receive lintian warnings yet a year later that I was not using the
canonical anonscm address (which I found longer than necessary) and now
finally, another year later alioth being decommissioned.  I don't like
having to move every year or so, even if the repos itself did usually
survive.  From what I see, I'd probably also need to create yet another
account on yet another cloud provider whereas I already have a github
account.  I have learned that some people are unhappy with the level of
"free" of github, but to me at this point it is just a tool.  I am not
"married" to the idea of hosting my packages at github, but that's what
it is going to be for now, hoping for a more stable experience there.  I
am in no way locked into github or else I would not have moved there.

Regards

Rolf

PS: The (frankly absurd) idea that collab-maint means "free-for-all" to
usurp and actually upload your packages behind your back had nothing to
do with it, BTW.  ;-)

Re: Lucas Kanashiro and Athos Ribeiro hijack my package

[Rolf Leggewie]

On 17.04.2018 07:42, Clint Adams wrote:
>> In fact, I have always taken my
>> responsibilities seriously.  There are good reasons there was no
>> upload.  If they had bothered to check the upstream bug tracker or the
> Were there also good reasons why you don't respond to bug reports except
> to yell at someone requesting a new version?

Hello Clint,

in all humbleness, excuse my french, but what are you smoking?  Where in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827522#10 am I
yelling?  And in fact, even though I do not like this kind of bug
reports (that is really the role of debian/watch) the ticket now does
serve a purpose in documenting publicly why there was no upload to
gjots2 in unstable over many years.  The reason given is still valid,
that hasn't changed, no update needed there. It sums up the state of
gjots2 pretty well and thus for the sake of not spreading fake news let
me quote it here.

+--[ https://bugs.debian.org/827522#10 ] --+
> From: Rolf Leggewie 
> To: Debian Bug Tracking System <827...@bugs.debian.org>
> Subject: Re: [gjots2] Version 3.0.1 available
> Date: Tue, 31 Jan 2017 15:34:06 +0800
>
> Package: gjots2
> Version: 2.4.1-2
> Followup-For: Bug #827522
>
> Marek,
>
> I thought I had already replied to this ticket but it looks like
> I did not.
>
> Thank you for your report.  There are ways in Debian to inform the
> maintainer automatically about new upstream releases (debian/watch).
> Specifically opening bug tickets about new upstream versions being
> available doesn't really help much.
>
> I had had a look at the new upstream quite a while ago and found
> several bugs so I reported them upstream and held off releasing
> to Debian.
>
> https://sourceforge.net/p/gjots2/bugs/
>
> Regards
>
> Rolf Leggewie

+-+

Re: Hi, I am blind

[Samuel Thibault]

Paul Wise, le mar. 17 avril 2018 11:20:15 +0800, a ecrit:
> On Mon, 2018-04-16 at 10:15 +0200, Samuel Thibault wrote:
> 
> > Well, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855446
> 
> accessible-via seems different to what I propose.
> 
> accessible-via references software that makes each package accessible.

Not exactly software, but the kind of support that software provides:
braille, speech, and which software because that makes a technical
difference in the quality of the information provided.

> The proposed accessible-to would reference classes of abilities that
> are required to use the package. For example accessible-to::sighted.
> I've no idea if this sort of thing would be useful though.

The problem is that "abilities" is a terrible beast to define. "sighted"
for instance does not mean anything, since there is an extremely wide
range of sightedness, which can't for instance actually be reduced a
single "quality" scalar value as opticians define. "being able to read
written braille", "being able to hear speech synthesis", "being able to
read a zoomed display", however, does mean something to users, thus the
accessible-via tags.

> > but it seems https://debtags.debian.org/ hasn't gotten updated yet.
> 
> I'd suggest filing another bug about that.

Eww.

Samuel