Am Montag, den 02.01.2017, 10:16 +1100 schrieb 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
❦ 4 janvier 2017 04:52 GMT, Scott Kitterman :
>>> It's surprisingly awkward, and, at least for me, it turns out that
>>> externalizing my rebased branch as a patch series solves many of
>>> problems surprisingly well. All the other solutions I can think of
>>> require one or more things I don'
Nikolaus Rath writes:
> On Jan 03 2017, Russ Allbery wrote:
>> Speaking as a Debian user who frequently has to apply local patches or
>> produce local versions of Debian packages for my job (usually weird
>> backports or bizarre local requirements), I cannot express to you how
>> much I prefer a
On Wed, Jan 4, 2017 at 1:30 PM, Nikolaus Rath wrote:
> But I am not sure if a package structure like
>
> mypkg/upstream/*
> mypkg/debian/*
> mypkg/patches/* (?)
>
> would have any *practical* benefits over the current situation, because
> this transformation could be trivially automated in either
On January 4, 2017 12:33:43 AM EST, Nikolaus Rath wrote:
>On Jan 03 2017, Russ Allbery wrote:
>> Nikolaus Rath writes:
>>
>>> The thing that's delivered to users in 99% of the cases is the
>binary
>>> package. In the (comparatively) rare cases where the user is
>retrieving
>>> the source, I am
On Jan 03 2017, Russ Allbery wrote:
> Nikolaus Rath writes:
>
>> The thing that's delivered to users in 99% of the cases is the binary
>> package. In the (comparatively) rare cases where the user is retrieving
>> the source, I am not convinced that most of these users truly prefer a
>> Debian-spe
On Jan 04 2017, Paul Wise wrote:
> On Mon, Jan 2, 2017 at 1:21 AM, Guillem Jover wrote:
>
>> 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.
>
> I've been reading this thread and keep being reminded of our
> discussio
On Wed, 2017-01-04 at 14:47 +1000, Russell Stuart wrote:
> The central
issue here appears to be that none of the proposed ways
> of using git
within Debian help with that task.
On Wed, 2017-01-04 at 04:42 +, Colin Watson wrote:
>
> git-dpm does too, and I agree it's nice.
>
> It produces a p
On January 3, 2017 10:22:22 PM EST, Nikolaus Rath wrote:
>On Jan 03 2017, Russ Allbery wrote:
>> It's surprisingly awkward, and, at least for me, it turns out that
>> externalizing my rebased branch as a patch series solves many of
>these
>> problems surprisingly well. All the other solutions
On Tue, 2017-01-03 at 18:37 -0800, Russ Allbery wrote:
> Even if we never used tarballs, and instead our unit of operation was
> the upstream Git repository plus Debian branches, I would maintain a
> rebased branch of Debian changes to upstream
This is not a novel requirement. Most projects I've
On Tue, Jan 03, 2017 at 07:36:46PM -0800, Russ Allbery wrote:
> That said, gbp pq does something else I really like, namely it exports in
> the source package all of the metadata that anyone else would need to pick
> up the package without needing a copy of my Git repository (except for
> history).
Nikolaus Rath writes:
> The thing that's delivered to users in 99% of the cases is the binary
> package. In the (comparatively) rare cases where the user is retrieving
> the source, I am not convinced that most of these users truly prefer a
> Debian-specific source package with patches in debian/
Nikolaus Rath writes:
> When talking about percentages, I think it's worth keeping in mind the
> 1000% longer that it takes to comprehend a diff of two patches-unapplied
> trees (as gbp produces them) over a diff of two patches-applied trees
> (as git-dpm and dgit with maint-merge workflow produc
On Mon, Jan 2, 2017 at 1:21 AM, Guillem Jover wrote:
> 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.
I've been reading this thread and keep being reminded of our
discussion on #debian-dpkg a while ago.
I think most
Nikolaus Rath writes:
> Are there really upstreams that do that? I'd expect that the primary
> consumer of Debian patches are other distributions, downstreams, and
> users.
> I'd think that anything that's relevant for upstream development is
> forwarded to upstream by the maintainer in whatever
On Jan 03 2017, Russ Allbery wrote:
> It's surprisingly awkward, and, at least for me, it turns out that
> externalizing my rebased branch as a patch series solves many of these
> problems surprisingly well. All the other solutions I can think of
> require one or more things I don't really want t
On Jan 03 2017, Ian Jackson wrote:
> Recently, my nm-applet can no longer control my network-manager
> daemon. I get a message saying[1]:
>
> "org.freedesktop.NetworkManager.network-control-request failed: not
> authorized"
>
> I think this is related to a similar problem in *-power-manager,
On Wed, Jan 4, 2017 at 2:54 AM, Russ Allbery wrote:
> Well, if we had one more thing: a patches.debian.org service that would
> show the git-debcherry-extracted patches against upstream. I really like
> being able to just point upstream at all the patches relevant to them that
> Debian has applie
On Jan 04 2017, Scott Kitterman wrote:
>>Curating a patch series is only 5% slower than commiting directly to
>>the Git repository to me. I just have to remember to gbp pq import
>>before making new changes, gbp pq export when I'm done, and once in a
>>great while I have to do a small bit of reba
On Jan 03 2017, Russ Allbery wrote:
> Sean Whitton writes:
>> On Tue, Jan 03, 2017 at 10:36:22AM -0800, Nikolaus Rath wrote:
>
>>> I still haven't really made up my mind if I want to use git-maint-merge
>>> or git-dpm. Russ recently raised a valid point with the Debian
>>> modifications over-time
On Jan 03 2017, Sean Whitton wrote:
> On Tue, Jan 03, 2017 at 10:36:22AM -0800, Nikolaus Rath wrote:
>> I still haven't really made up my mind if I want to use git-maint-merge
>> or git-dpm. Russ recently raised a valid point with the Debian
>> modifications over-time becoming all tangled up and i
On Jan 03 2017, Sean Whitton wrote:
> Hello,
>
> On Tue, Jan 03, 2017 at 10:39:33AM -0800, Nikolaus Rath wrote:
>> >
>> > git log --oneline 1.2.3..debian/1.2.3-1 -- . ':!debian'
>>
>> Yes, but that's not as useful as what git-debcherry produces.
>>
>> For example, if you get a merge conflict
gregor herrmann writes:
> Personally I have the feeling that lots of these discussions and also
> the creation of new tools (git-dpm, git-pq, git-debcherry, dgit) are
> just workarounds for the actual problem: Many of us would like to work
> in and with git but the whole infrastructure still revo
Toni Mueller writes:
> I found them only on PyPI. Did you find them elsewhere?
We get them from releases.ansible.com. Are the docs in the tarballs in
PyPi?
--
Harlan Lieberman-Berg
~hlieberman
Package: wnpp
Severity: wishlist
Owner: Carl Suster
Control: block 724718 by -1
* Package name: rpyc
Version : 3.3.0
Upstream Author : Tomer Filiba
* URL : https://github.com/tomerfiliba/rpyc
* License : MIT
Programming Lang: Python
Description : trans
Michael Biebl writes ("Re: "not authorised" doing various desktoppy things"):
> Check if your session is marked as active and local
> $ loginctl show-session $XDG_SESSION_ID
I see (amongst other things):
Remote=no
Active=yes
State=active
> Might be #844785
Perhaps it is. The symptoms see
On Tue, 03 Jan 2017 20:15:10 +, Sean Whitton wrote:
> On Tue, Jan 03, 2017 at 10:54:07AM -0800, Russ Allbery wrote:
> > Well, if we had one more thing: a patches.debian.org service that would
> > show the git-debcherry-extracted patches against upstream. I really like
> > being able to just p
On Tue, Jan 3, 2017 at 5:38 PM, Abou Al Montacir wrote:
> What about requiring signed mail for closing a bug report?
We have sponsored maintainers, who theoretically could get by entirely
without an OpenPGP key. I don't know if any exist but I don't think
they should be blocked from -done. Also,
Package: wnpp
Severity: wishlist
Owner: Carl Suster
Control: block 724718 by -1
* Package name: terminaltables
Version : 3.1.0
Upstream Author : Robpol86
* URL : https://github.com/Robpol86/terminaltables
* License : MIT
Programming Lang: Python
Descriptio
Package: wnpp
Severity: wishlist
Owner: Carl Suster
Control: block 724718 by -1
* Package name: flask-cors
Version : 3.0.2
Upstream Author : Cory Dolphin
* URL : https://github.com/corydolphin/flask-cors
* License : MIT
Programming Lang: Python
Description
On Tue, Jan 03, 2017 at 04:33:39PM -0800, Russ Allbery wrote:
> I'm unconvinced that any of that work would really be avoided via other
> mechanisms. The most time-consuming part is rebasing and squashing
> related changes together into one coherent diff, but that's going to be
> just as hard with
On Tue, 03 Jan 2017 at 21:59:05 +, Sune Vuorela wrote:
> If I recall correctly, for most
> networky (and removable media things), the default policykit
> configuration is that 'local logged in users' are allowed to do this.
They must usually be active as well as locally logged in. (This means
On January 3, 2017 7:33:39 PM EST, Russ Allbery wrote:
>Sean Whitton writes:
>> On Tue, Jan 03, 2017 at 10:36:22AM -0800, Nikolaus Rath wrote:
>
>>> I still haven't really made up my mind if I want to use
>git-maint-merge
>>> or git-dpm. Russ recently raised a valid point with the Debian
>>> mo
Package: wnpp
Severity: wishlist
Owner: Carl Suster
Control: block 724718 by -1
* Package name: flask-restplus
Version : 0.9.2
Upstream Author : Axel Haustant
* URL : https://github.com/noirbizarre/flask-restplus
* License : MIT
Programming Lang: Python
De
Sean Whitton writes:
> On Tue, Jan 03, 2017 at 10:36:22AM -0800, Nikolaus Rath wrote:
>> I still haven't really made up my mind if I want to use git-maint-merge
>> or git-dpm. Russ recently raised a valid point with the Debian
>> modifications over-time becoming all tangled up and impossible to
>
Package: wnpp
Severity: wishlist
Owner: Carl Suster
Control: block 724718 by -1
* Package name: safe
Version : 0.4
Upstream Author : Hsiaoming Yang
* URL : https://github.com/lepture/safe
* License : BSD
Programming Lang: Python
Description : password
On Mon, Jan 02, 2017 at 01:09:35PM -0800, Nikolaus Rath wrote:
> On Jan 02 2017, Russ Allbery wrote:
> > Furthermore, it forces a rebased, clean representation of the patches,
> > which I for one hugely prefer to the mess that you get if someone was
> > packaging in Git and just randomly commits t
Package: wnpp
Severity: wishlist
Owner: Carl Suster
Control: block 724718 by -1
* Package name: colorclass
Version : 2.2.0
Upstream Author : Robpol86
* URL : https://github.com/Robpol86/colorclass
* License : MIT
Programming Lang: Python
Description :
Hi!
A happy new year, everyone!
On Sat, Dec 31, 2016 at 01:07:44PM -0500, Harlan Lieberman-Berg wrote:
> Unfortunately, we don't build ansible off of the git repository, but
> rather from the released tarballs.
I found them only on PyPI. Did you find them elsewhere?
> It's been a while since
Hi there,
as the stretch freeze approaches, I'm getting concerned about the
status of logrotate, most notably #734688. The maintainer (CC'ed)
hasn't shown any sign of activity for a while, also no response to a
private message (I admit, it's been just a few days).
Since the fix includes switching
Hello Nikolaus,
On Tue, Jan 03, 2017 at 10:29:49AM -0800, Nikolaus Rath wrote:
> On Jan 03 2017, Sean Whitton wrote:
> > You mentioned previously that you're trying to use the
> > dgit-maint-merge(7) workflow. In that case, why do you want git-dpm?
>
> I don't. I was just trying to get a better
Hello,
On Tue, Jan 03, 2017 at 10:39:33AM -0800, Nikolaus Rath wrote:
> >
> > git log --oneline 1.2.3..debian/1.2.3-1 -- . ':!debian'
>
> Yes, but that's not as useful as what git-debcherry produces.
>
> For example, if you get a merge conflict when rebasing, the above
> incantation will lis
On 2017-01-03, Ian Jackson wrote:
> Can someone please help explain to me how these things are supposed to
> work ? Specifically, how is (presumably as a consequence of me
> logging in using a display manager) my session supposed to be granted
> the ability to manage various system resources like
Am 03.01.2017 um 21:05 schrieb Ian Jackson:
> Recently, my nm-applet can no longer control my network-manager
> daemon. I get a message saying[1]:
>
> "org.freedesktop.NetworkManager.network-control-request failed: not
> authorized"
>
> I think this is related to a similar problem in *-power
Recently, my nm-applet can no longer control my network-manager
daemon. I get a message saying[1]:
"org.freedesktop.NetworkManager.network-control-request failed: not
authorized"
I think this is related to a similar problem in *-power-manager,
#848623.
I am running:
* sysvinit
* lightdm
On Jan 03 2017, Nikolaus Rath wrote:
> On Jan 03 2017, Sean Whitton wrote:
>> Hello Russ,
>>
>> On Mon, Jan 02, 2017 at 09:29:24AM -0800, Russ Allbery wrote:
>>> Furthermore, it forces a rebased, clean representation of the patches,
>>> which I for one hugely prefer to the mess that you get if so
On Jan 03 2017, Russ Allbery wrote:
> Nikolaus Rath writes:
>
>> For example, if you get a merge conflict when rebasing, the above
>> incantation will list two commits: the original debian commit and the
>> merge commit. git-debcherry, on the other hand, will synthesize one
>> patch, consisting o
On Tue, 03 Jan 2017, Niels Thykier wrote:
> An exception in my experience: In process is cheaper when the
> (de)compressor is available in the PerlIO Layer as native C code.
> Notable example being libperlio-gzip-perl where you use "open(my $fd,
> '<:gzip', $file)".
> At least that was the case w
Nikolaus Rath writes:
> For example, if you get a merge conflict when rebasing, the above
> incantation will list two commits: the original debian commit and the
> merge commit. git-debcherry, on the other hand, will synthesize one
> patch, consisting of the original Debian commit, but modified t
On Jan 03 2017, Sean Whitton wrote:
> Hello Russ,
>
> On Mon, Jan 02, 2017 at 09:29:24AM -0800, Russ Allbery wrote:
>> Furthermore, it forces a rebased, clean representation of the patches,
>> which I for one hugely prefer to the mess that you get if someone was
>> packaging in Git and just random
Niels Thykier writes:
> Russ Allbery:
>> I've done extensive benchmarking of this in Perl for a different
>> project and yes, fork and exec of an external compresser is *way*
>> faster than using a library. I suspect the Perl compress libraries are
>> making extraneous data copies or doing somet
On Jan 03 2017, Ian Jackson wrote:
> Sean Whitton writes ("Re: Converting to dgit (was: How to get history into
> dgit)"):
>> On Mon, Jan 02, 2017 at 07:22:54PM -0800, Nikolaus Rath wrote:
>> > I'll have to bring this up one more time. I just read
>> > https://bugs.debian.org/cgi-bin/bugreport.cg
On Jan 03 2017, Sean Whitton wrote:
> Hello Nikolaus,
>
> On Mon, Jan 02, 2017 at 07:22:54PM -0800, Nikolaus Rath wrote:
>> I'll have to bring this up one more time. I just read
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794244, and that
>> sounds (in "USING GIT-DPM WITH DGIT FOR THE FIR
Russ Allbery:
> [...]
>> I wouldn't have expected that either, but it appeared to be 4-5 times
>> slower than the equivalent code with fork a decompressor, which is why I
>> swapped it out. [I didn't bother to benchmark them, because the
>> differences between them was so stark.]
>
> I've done ext
On Tue, 03 Jan 2017, Russ Allbery wrote:
> If you're using DB_File, I think you have to use the explicit put()
> and get() API instead of the tied magical hash in order to get error
> reporting.
That matches what documentation I've found so far.
Instead of really working on hacking this out, I've
Don Armstrong writes:
> On Tue, 03 Jan 2017, Ian Jackson wrote:
>> Also, have you checked whether your DB library properly throws errors
>> on writes to a tied hash ?
> I don't know whether it does or not; I went looking to see whether you
> could trap errors on untie(), and untie doesn't return
On Tue, Jan 03, 2017 at 03:05:27PM +, Ian Jackson wrote:
> Geert Stappers writes ("Re: Can we kill net-tools, please? (and this
> thread)"):
> > This e-mail is to request to leave this thread in the year 2016.
Happy New Year
> > We have concencus that the install priority of net-tools sho
Hi,
Would you be interested in Amazon CloudFront Users list for your email
marketing campaign?
We also have other technology users like
Imperva Incapsula
Akamai
MaxCDN
Rackspace
Microsoft Azure CDN
KeyCDN
Cachefly
Accelerate
CDN77.com
Limelight Networks
Please let me know your target audience i
Package: wnpp
Severity: wishlist
Owner: Free Ekanayaka
* Package name: golang-github-nebulouslabs-entropy-mnemonics
Version : 0.0~git20150811.0.6afa27f-1
Upstream Author : Nebulous
* URL : https://github.com/nebulouslabs/entropy-mnemonics
* License : Expat
P
Sean Whitton writes ("Re: Converting to dgit (was: How to get history into
dgit)"):
> On Mon, Jan 02, 2017 at 07:22:54PM -0800, Nikolaus Rath wrote:
> > I'll have to bring this up one more time. I just read
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794244, and that
> > sounds (in "USIN
Vincent Bernat writes ("Re: Feedback on 3.0 source format problems"):
> 2 janvier 2017 01:45 -0800, Josh Triplett :
> > Personally, when I want to patch a random package, I run "debcheckout
> > package-name", make changes, commit them, format-patch, [...]
Really, I can't let this pass without plu
Guillem Jover writes ("Feedback on 3.0 source format problems"):
> 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 t
Sven Joachim writes ("Re: auto-removal and alternative dependencies"):
> No need to do so, this has been filed[1] quite some time ago already.
...
> 1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745475
That's a rather unsatisfying bug report.
I see people arguing about the severity. I don
On Tue, 03 Jan 2017, Ian Jackson wrote:
> The result is that you ignore nonzero exit status from your
> decompression program. My theory for the incident we are discussing is
> that your decompressor got a SIGTERM, and your script got EOF on the
> pipe.
Yeah, this is likely it. Thanks for catching
On Tue, Jan 03, 2017 at 03:24:40PM +, Jonathan Dowland wrote:
> The UI for ip(8) is absolutely appalling. I'd like Debian to continue to carry
> net-tools in parallel to iproute2 until such time as a third tool (with a
> decent UI) comes along and obsoletes iproute2.
...
> I have no problem wit
On Mon, Dec 26, 2016 at 02:50:50PM +0100, Marco d'Itri wrote:
> Recently the net-tools maintainer has forked the abandoned net-tools
> code base and started developing it again, after 15 years of stasis.
...
> Can we stop shipping two network configuration CLI tools in the default
> install?
The
Geert Stappers writes ("Re: Can we kill net-tools, please? (and this thread)"):
> This e-mail is to request to leave this thread in the year 2016.
> We have concencus that the install priority of net-tools should be lowered.
That has been done.
> It doesn't matter what is "easy" with "ip" or with
Don Armstrong writes ("Re: Migration despite an RC bug?"):
> On Sat, 31 Dec 2016, Ian Jackson wrote:
> > I've debugged a lot of this kind of thing. Point me at your
> > (pre-just-fixed) code and I might spot it ?
>
> These two are how I think I've fixed it:
I don't think so. I cloned[1] the cod
On Mon, 2017-01-02 at 23:26 +0500, Andrey Rahmatullin wrote:
> On Mon, Jan 02, 2017 at 07:25:04PM +0100, Geert Stappers wrote:
> > Banning those words in the Subject-line to our BTS would be too hars.
>
> ITYM "won't".
What about requiring signed mail for closing a bug report?
--
Cheers,
Abou Al
On Tue, Jan 03, 2017 at 10:49:05AM +0800, Paul Wise wrote:
> > Probably we don't have enough people looking at the spam reports. That
> > probably could be improved with better advertising, e.g. on
> > https://www.debian.org/intro/help
>
> Right now only the BTS admins can look at and act on spam
Hello Russ,
On Mon, Jan 02, 2017 at 09:29:24AM -0800, Russ Allbery wrote:
> Furthermore, it forces a rebased, clean representation of the patches,
> which I for one hugely prefer to the mess that you get if someone was
> packaging in Git and just randomly commits things directly to the
> packaging
71 matches
Mail list logo
