Bug#849859: ITP: golang-github-nebulouslabs-demotemutex -- Allow an RWMutext writelock to be demoted to a readlock.

[Free Ekanayaka]

Package: wnpp
Owner: Free Ekanayaka 
Severity: wishlist

* Package name: golang-github-nebulouslabs-demotemutex
  Version : 
  Upstream Author : 
* URL or Web page : 
* License : 
  Description : Allow an RWMutext writelock to be demoted to a readlock.

Re: HEADSUP: mails sent to n...@bugs.debian.org are NOT sent to the submitter

[Riku Voipio]

On Tue, Dec 27, 2016 at 08:00:18AM +0800, Paul Wise wrote:
> On Tue, Dec 27, 2016 at 7:03 AM, Ian Jackson wrote:
> 
> > When I decided that debbugs should work like this:
> 
> I think this was the right decision and still is, with this additional reason:
> 
> Folks are much busier these days and every extra unnecessary email
> takes extra time and brain space that could be spent on other tasks
> and thoughts.

Every other bug tracker, including all new ones like github, by default
sends emails to submitter (and everyone who ever touched the bug). Debian
is the odd one out. Filtering mails at the recieving side is easy.
 
> >  * Make all submitters of new bugs be subscribed by default.
> 
> I definitely do not want this myself and I don't think it is a good
> idea, for the reasons you mentioned and more importantly for the one I
> mentioned. If it changes, I would want a way to disable subscription
> for all bugs I submit. Probably a good idea to have a Subscribe: yes
> option at submit@ time too.

I understand your position, but my gut feeling is vas majority of users
filing bugs expect to be kept upto date on how the fixing proceeds. So the
subscibe by default and a "Subscribe: no" pseudoheader is better. 

Riku
 

Re: Bug#849703: ITP: ansible-doc -- Documentation for Ansible

[Evgeni Golov]

Ohai,

On Sat, Dec 31, 2016 at 01:07:44PM -0500, Harlan Lieberman-Berg wrote:
> "W. Martin Borgert"  writes:
> > Then why not make an additional binary package from the same
> > source package? This way ansible and its documentation would
> > not get out of sync.
> 
> Unfortunately, we don't build ansible off of the git repository, but
> rather from the released tarballs.  (The version in upstream's git
> requires much more extensive dfsg cleanup, and would until recently have
> required the bundling of multiple upstream repositories together.)

Actually, I think building from a release tarball is a good thing. This
ensures that every distro has the same Ansible.

> It's been a while since we made the decision not to pull from upstream's
> git; Toni, I'd be happy to work with you on seeing if it's doable now.

How about we talk to upstream to actually include the docs in the tarballs?
That should not be that hard.

Then we can build and ship them and everyone wins?

Evgeni

Re: [buildd-tools-devel] Bug#843773: Bug#843773: misleading timestamps in binnmus

[Guillem Jover]

[ Had this half-drafted, but had not found the time to finish it up
  until now. ]

Hi!

On Mon, 2016-11-14 at 13:52:18 +, Ian Jackson wrote:
> Johannes Schauer writes ("Re: [buildd-tools-devel] Bug#843773: Bug#843773: 
> misleading timestamps in binnmus"):
> > Instead, file conflicts might be created from files with
> > content that depends on SOURCE_DATE_EPOCH.
> 
> tl;dr:
>Analysis.  Revised proposal:
>Introduce BUILD_DATE_EPOCH (= time of sbuild binnmu invocation)
>and use it for file timestamps (only (for now))

Thanks for the analysis. Although I see few problems with it.

* binNMUs are not co-installable anyway, and although I've got code
  to make them so on the dpkg side, other parties who have to deal
  with dependency resolution are less than enthused on the prospect
  of having to cover that new invariant.
* Even if we made binNMUs co-installable, they would contain files
  with different metadata, which is currently not considered when
  checking for the same-ness of the files, but I think it does
  make sense to consider in the future.
* Even if we didn't consider the metadata part of the criteria for
  same-ness, it still will need to be stored in the dpkg db, but the
  filesystem is a shared resource and only one of the instances can
  be present so the divergent metadata will make verification somewhat
  worthless, or way more complex to implement or reason about.
* Even if any of the above are ignored/solved somehow, the binNMUs
  will contain different metadata, which means you could end up
  with timestamps on disk going back and forth in time for the same
  content. Say you install one of each on several consecutive days
  libfoo_1+b2_arch-a, libfoo_1+b1_arch-b and libfoo_1+b3_arch-c,
  which might also upset some backup solutions.

And this would be yet another reason why allowing coexistence of
Multi-Arch:same and binNMUs that are not in lockstep for all
architectures would be a bad idea.

In any case the concept of binNMUs as being pure rebuilds is simply
an illusion. They are sourceful updates where the source is discarded,
and not only is the environment they are built against different, their
contents will be at least different just because of the different
version and different changelog entry.


So, yes, again IMO Multi-Arch:same plus ref-counted files are broken by
design, and they are pretty much incompatible with binNMUs. I stated
this in the monumental multiarch thread here some years ago. There
was rough consensus that this was either not a problem or one where
its benefits outweighted the potential problems. Fine, but then do not
expect miracles out of the current situation we got into. :)


So, I think this has been already implemented in sbuild and pbuilder,
but indeed, my proposal would be for now to ignore all this, and just
emit a changelog entry with the current build date for each binNMU.

When combined with the M-A:same and ref-counted files requirements, this
*is* still conceptually and practically wrong, because binNMUs are not
triggered for all architectures in lockstep, and are not triggered for
the same reasons (a b1_arch-y might not exist for the same reasons a
b1_arch-z).

The only correct "solution" I see while keeping the current mess, would
be to declare binNMU versions a globally shared resource across all
architectures (in and out of archive!), trigger them globally for all
architectures (or replay them for late comers), and use the binNMU
trigger date for the changelog entry (and ideally also the email address
of the person or role who triggered the binNMU, instead of the buildd
doing the build).

(Well the *only* correct solution would be IMO to ban ref-counted files,
but I don't think that will gain much favor this time around either,
although I think I might make it possible to disable it at dpkg build
time for those downstreams that do not want anything to do with this
insanity. :)

Thanks,
Guillem

Feedback on 3.0 source format problems

[Guillem Jover]

Hi!

I'm interested in what things people still find so off-putting to the
point of not wanting to use the new 3.0 source formats, or what makes
people use them in anger and similar (if people would state which one
of these apply that would be helpful). All these including objective
and subjective issue. And even existing bug references would be fine.

I've created an initial draft wiki page with few things I had noted
down, where I'll try to summarize things mentioned on the thread:

  


(I'm not using  because
TBH it read more like a sales brochure than a more neutral page…)

Thanks,
Guillem

Re: Bug#849703: ITP: ansible-doc -- Documentation for Ansible

[Evgeni Golov]

On Sun, Jan 01, 2017 at 05:38:50PM +0100, Evgeni Golov wrote:
> Ohai,
> 
> On Sat, Dec 31, 2016 at 01:07:44PM -0500, Harlan Lieberman-Berg wrote:
> > "W. Martin Borgert"  writes:
> > > Then why not make an additional binary package from the same
> > > source package? This way ansible and its documentation would
> > > not get out of sync.
> > 
> > Unfortunately, we don't build ansible off of the git repository, but
> > rather from the released tarballs.  (The version in upstream's git
> > requires much more extensive dfsg cleanup, and would until recently have
> > required the bundling of multiple upstream repositories together.)
> 
> Actually, I think building from a release tarball is a good thing. This
> ensures that every distro has the same Ansible.
> 
> > It's been a while since we made the decision not to pull from upstream's
> > git; Toni, I'd be happy to work with you on seeing if it's doable now.
> 
> How about we talk to upstream to actually include the docs in the tarballs?
> That should not be that hard.
> 
> Then we can build and ship them and everyone wins?

Let's continue here:
https://github.com/ansible/ansible/issues/19769

Re: Feedback on 3.0 source format problems

[Nikolaus Rath]

On Jan 01 2017, Guillem Jover  wrote:
> (I'm not using  because
> TBH it read more like a sales brochure than a more neutral page…)

TBH this feels like you're sniping at Raphael here, which I think is
pretty sad and inappropriate.


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Re: [buildd-tools-devel] Bug#843773: Bug#843773: misleading timestamps in binnmus

[Adam Borowski]

On Sun, Jan 01, 2017 at 05:40:44PM +0100, Guillem Jover wrote:
> The only correct "solution" I see while keeping the current mess, would
> be to declare binNMU versions a globally shared resource across all
> architectures (in and out of archive!), trigger them globally for all
> architectures (or replay them for late comers)

As someone who tried to make unofficial jessie for x32, I say: hell yeah,
oh so much please do this!  Or better yet, just drop that concept altogether
and instead make binNMUs automated _sourceful_ uploads.

For someone who's trying to simulate testing/stable at home, inconsistent
binNMU versions create such a mess that, despite jessie-x32 being mostly
done, you didn't hear it announced, I didn't bother to build security
updates as planned, it's a bitch to upgrade to unstable, and I'm not trying
that again for stretch.

So here's another reason for your idea, and why binNMUs are bad.


Meow!
-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11

Re: Feedback on 3.0 source format problems

[Guillem Jover]

On Sun, 2017-01-01 at 10:47:59 -0800, Nikolaus Rath wrote:
> On Jan 01 2017, Guillem Jover  wrote:
> > (I'm not using  because
> > TBH it read more like a sales brochure than a more neutral page…)
> 
> TBH this feels like you're sniping at Raphael here, which I think is
> pretty sad and inappropriate.

Hmm, I brought it up because it does read like that to me (please have
a look if you haven't), and it does not feel right for me to change the
tone of that page on my own.

I don't have an inherent problem with people advertising features and
trying to "sell" them to users, more so if you have invested time and
energy in them and truly think they are superior. And just to be clear
I switched all packages I maintain to 3.0 formats long time ago and
never looked back, and I'm pretty happy about it.

But then, I know that part of the resistance to the new formats was
in part due to that very aggressive advertising campaign, that for
whatever reason annoyed some quarters of the project. So, when trying
in a way to start a dialogue with the people that got annoyed at the
time, I think it would be a bad idea to cloud that with a page like
that. I see taking a neutral position as a way to try to "heal" that
divide in the project. Hope that explains.

Thanks,
Guillem

Re: Feedback on 3.0 source format problems

[Christoph Biedl]

Guillem Jover wrote...

> On Sun, 2017-01-01 at 10:47:59 -0800, Nikolaus Rath wrote:

> > TBH this feels like you're sniping at Raphael here, which I think is
> > pretty sad and inappropriate.

Well, bringing up more old stories, even if 'The secret plan behind
the "3.0 (quilt)" Debian source' was meant to be a joke, it wasn't
quite helpful to convince the people who were not sure about the
concept. So Guillem's wording might be inappropriate but Raphael will
have to stand that.

> But then, I know that part of the resistance to the new formats was
> in part due to that very aggressive advertising campaign, that for
> whatever reason annoyed some quarters of the project. So, when trying
> in a way to start a dialogue with the people that got annoyed at the
> time, I think it would be a bad idea to cloud that with a page like
> that.

This is a good plan, go for it. Overall (and starting advocacy), I'm
not a huge fan of 3.0 (quilt) but - especially when used with DEP-3
headers - it is the best thing Debian has, way better than 1.0 and all
the other hand-crafted patch handling I happen to see in some
packages. Also, this format has been around for several years now, it
is understood, well-tested and widely accepted.

So I might suggest "Deprecate source format 1.0" as a buster release goal.

Christoph


signature.asc
Description: Digital signature

wording: "reverse dependence" vs "depender"

[Adam Borowski]

Oi you lot!

I wonder, would it be better if we switched to using the word "depender" in
place of "reverse dependency"?  It certainly sounds clumsier, but it is far
less likely to be confused, especially by new readers.  I myself often find
sentences which include references to both depends and reverse depends quite
hard to parse.


Meow!
-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11

Re: wording: "reverse dependence" vs "depender"

[Ben Finney]

Adam Borowski  writes:

> Oi you lot!

Wassp!?

> I wonder, would it be better if we switched to using the word
> "depender" in place of "reverse dependency"?

I don't know a simple term in English that carries that meaning.

To me, “depender” feel like a neologism and does not make me confident
the reader would know what is meant. I vote −1 to that term.

The adjective “dependent” is IMO fine, so perhaps the noun phrase
“dependent package” is a good candidate. It's not the single word you're
looking for, but maybe it is unambiguous for the purpose?

-- 
 \ “I still have my Christmas Tree. I looked at it today. Sure |
  `\   enough, I couldn't see any forests.” —Steven Wright |
_o__)  |
Ben Finney

Re: Feedback on 3.0 source format problems

[Bastien ROUCARIES]

On Sun, Jan 1, 2017 at 6:21 PM, Guillem Jover  wrote:
> Hi!
>
> I'm interested in what things people still find so off-putting to the
> point of not wanting to use the new 3.0 source formats, or what makes
> people use them in anger and similar (if people would state which one
> of these apply that would be helpful). All these including objective
> and subjective issue. And even existing bug references would be fine.
>
> I've created an initial draft wiki page with few things I had noted
> down, where I'll try to summarize things mentioned on the thread:
>
>   
>

Ok I love 3.0 format except that I could not specify wildcard in ls
debian/source/include-binaries and
#668588 if it still apply

Bastien


> (I'm not using  because
> TBH it read more like a sales brochure than a more neutral page…)
>
> Thanks,
> Guillem
>

Re: Bug#791828: dput-ng: Please make coinstallable with dput

[Ben Finney]

On 08-Jul-2015, Tobias Frost wrote:

> I'd love to use both dput and dput-ng without the need of installing
> the version I'd use next..

As discussed briefly in the thread from 2016-12, my counter-proposal
is that the two packages should ideally:

* Be alternative implementations of the same set of features, so that
  any features that people actually use should be implemented in each.

* Eventually converge so closely that they merge, and there is just
  one ‘dput’ that is the single obvious package to install.

> Thanks for consdering!

I look forward to working (gradually and carefully) with the ‘dput-ng’
maintainers to make this request redundant :-)

-- 
 \“You don't change the world by placidly finding your bliss — |
  `\you do it by focusing your discontent in productive ways.” |
_o__)   —Paul Z. Myers, 2011-08-31 |
Ben Finney 


signature.asc
Description: PGP signature

[Fwd: [Pkg-pascal-devel] Bug#472304: marked as done (fpc: doesn't link dynamically)]

[Abou Al Montacir]

Dear All,

Since last month I'm really stuck with a spammer closing this very same
bug#472304 as soon as I reopen it.

I've reported abuse multiple times via the link at the foot of the bug page but
nothing changed.
Can anyone help please?

bug#472304: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=472304 id="-x-evo-
selection-start-marker">
-- 
Cheers,
Abou Al Montacir

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

Re: wording: "reverse dependence" vs "depender"

[Johannes Schauer]

Hi,

Quoting Ben Finney (2017-01-01 23:37:19)
> Adam Borowski  writes:
> > I wonder, would it be better if we switched to using the word "depender" in
> > place of "reverse dependency"?
> 
> I don't know a simple term in English that carries that meaning.
> 
> To me, “depender” feel like a neologism and does not make me confident
> the reader would know what is meant. I vote −1 to that term.
> 
> The adjective “dependent” is IMO fine, so perhaps the noun phrase
> “dependent package” is a good candidate. It's not the single word you're
> looking for, but maybe it is unambiguous for the purpose?

at a time where I was also wondering whether it would make sense to have some
common terminology for all these things I wrote up this wiki page:

https://wiki.debian.org/DependencyHell

In the section "Specifying the object of a dependency relation" you can see
three answers for what you are asking that I have seen used in the wild.

Contributions to that page welcome. :)

cheers, josch


signature.asc
Description: signature

Re: wording: "reverse dependence" vs "depender"

[Michael Lustfield]

On Jan 1, 2017 4:37 PM, "Ben Finney"  wrote:

Adam Borowski  writes:

> Oi you lot!

Wassp!?

> I wonder, would it be better if we switched to using the word
> "depender" in place of "reverse dependency"?

I don't know a simple term in English that carries that meaning.

To me, “depender” feel like a neologism and does not make me confident
the reader would know what is meant. I vote −1 to that term.


I imagine any non-English speaker would significantly oppose creating new
slang for this. I had to scratch my head when I read the subject wondering
if it was a typo for defender.

I can't, at this moment, think of a decent alternative.

Re: Specification of FTP upload queue management commands

[Ben Finney]

Emilio Pozuelo Monfort  writes:

> On 29/12/16 20:49, Ben Finney wrote:
> > Where is the canonical specification of the commands accepted by
> > ‘dak’?
>
> See gregor's link, or read the source:
>
> https://anonscm.debian.org/cgit/mirror/dak.git/tree/daklib/command.py

This surprises me. To be clear: There is no published documentation for
the remote command interface to ‘dak’?

Not even on the level of 
ftp://ftp.upload.debian.org/pub/UploadQueue/README>?

Is there an open bug report for ‘dak’ requesting a reference to what
commands it accepts?

> Whether it's dput's job to support dak commands or that belongs to a
> different tool is up to you. But maybe you should support it just to
> stop losing users to dput-ng :P

What tool to ‘dak’ maintainers expect maintainers to use for
communicating commands to ‘dak’?

-- 
 \  “I find the whole business of religion profoundly interesting. |
  `\ But it does mystify me that otherwise intelligent people take |
_o__)it seriously.” —Douglas Adams |
Ben Finney

Re: wording: "reverse dependence" vs "depender"

[Ben Finney]

Ben Finney  writes:

> The adjective “dependent” is IMO fine, so perhaps the noun phrase
> “dependent package” is a good candidate. It's not the single word
> you're looking for, but maybe it is unambiguous for the purpose?

https://english.stackexchange.com/questions/366158/noun-for-thing-which-depends-on-foo>

-- 
 \   “The Initial Mystery that attends any journey is: how did the |
  `\   traveller reach his starting point in the first place?” —Louise |
_o__)  Bogan, _Journey Around My Room_ |
Ben Finney