Package: wnpp
Severity: wishlist
Owner: Balasankar C
* Package name: ruby-responders
Version : 2.0.2
Upstream Author : Plataforma Tecnologia
* URL : http://blog.plataformatec.com.br
* License : Expat
Programming Lang: Ruby
Description : Set of Rails res
[Daniel Pocock]
> Would it be worthwhile giving people another option, for example,
> allowing a percentage of DDs to formally veto decisions? Would this
> be better than people leaving outright?
That sounds like a pretty good description of either a GR, or the
Technical Committee. We have both
Am 14.11.2014 um 03:52 schrieb Cameron Norman:
> Apparently newer versions of systemd-journald do not forward to syslog
> by default; that has to be explicitly configured (although rsyslog
> already reads the journal and collects the logs). Not sure if 215 is
> affected by that behavior, will have
On Fri, 2014-11-14 at 20:44 +, Adam D. Barratt wrote:
> On Fri, 2014-11-14 at 21:38 +0100, Svante Signell wrote:
> > 1) If a DD (the only persons able to vote?)
That point is also addressed in the CfV.
> change their mind, can they
> > do so before the deadline, or is their vote set in stone
On Fri, 2014-11-14 at 21:38 +0100, Svante Signell wrote:
> 1) If a DD (the only persons able to vote?) change their mind, can they
> do so before the deadline, or is their vote set in stone once issued?
They can vote as many times as they wish, with the last valid vote
received before the end of t
Hi,
I have two questions about the GR voting going on (I'm not subscribed to
debian-vote, unfortunately, and somebody even wanted me to be
banned :( )
1) If a DD (the only persons able to vote?) change their mind, can they
do so before the deadline, or is their vote set in stone once issued?
2)
* Raphael Hertzog [141114 12:34]:
> On Thu, 13 Nov 2014, Bernhard R. Link wrote:
> > * Raphael Hertzog [14 22:26]:
> > > Helper tools should usually rely on the output of `dpkg-vendor --query
> > > vendor`
> > > to find out the name of the current vendor. The retrieved string must be
> > > c
Ron writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
repositories"):
> Right, and like you already noted, there's potential for ambiguity
> in tag names anyway once the illegal characters have been mangled.
Raphael is proposing an unambiguous mangling which deals with this
problem.
* Neil Williams , 2014-11-14, 15:21:
Mathieu Malaterre wrote:
[...]
Sometimes you even get a hardcoded "/buildd" toplevel path,
Or /tmp/buildd/, or /home/bob/, which both smell like a (small) security
hole.
So my questions are:
1. Is it possible to post-processed those objects file and c
On Fri, 14 Nov 2014, Henrique de Moraes Holschuh wrote:
> The BTS needs it: it is the very base of version-aware bug state
> tracking. It builds the DAG by combining the DAGs extracted from the
> Debian changelogs of each branch of the package, AFAIK.
Speaking of which, one of the long standing id
[Andrey Rahmatullin]
> Not all Debian contributors are Debian Contributors whatever that means.
> Lots of people without keys somewhere in official keyrings are doing
> useful work. Some of them are even maintaining packages.
And actually, come January, a pretty high fraction of official Debian
D
On Fri, Nov 14, 2014 at 05:43:49PM +, Ian Jackson wrote:
> Ron writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
> repositories"):
> > Right, gitweb, cgit, gitk, etc. are all going to do exactly the same
> > thing, take them from the DAG of the repo. They are unlikely to care
> >
Hi,
Ian Jackson:
> Worse, unless I'm mistaken, there are some current workflows which
> involve subsequent uploads to the same suite not necessarily being
> fast forwards.
>
Meh. Anybody whose upload depends on being able to force-push a branch
deserves to lose. (I'm talking about the general cas
Hi Michael Ole,
Quoting Michael Ole Olsen (2014-11-14 00:19:36)
> It would be very cool if the debian installer had a listofpackages.txt
>
> and that listofpackages.txt could be edited by the user
>
> then we would be getting customized debian installs
A list of _all_ packages would be too inflex
Hi,
Henrique de Moraes Holschuh:
> > That said I did consider that side of it too, but I'm having a hard
> > time thinking of an example where you would actually care about
> > ordering the tags for some task. Do you have one that comes to mind?
>
> The BTS needs it: it is the very base of versi
Ron writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
repositories"):
> Right, gitweb, cgit, gitk, etc. are all going to do exactly the same
> thing, take them from the DAG of the repo. They are unlikely to care
> about how the tag names would textually sort (and even less likely to
Thorsten Glaser writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
repositories"):
> On Fri, 14 Nov 2014, Ian Jackson wrote:
> > expect to find version numbers matching ^\d+\~, then anything matching
>
> These are common enough for me to have not only seen,
> but also used (in native
Richard Hartmann writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
repositories"):
> Can you at least suggest, not require, that the NMUer should also send
> a link to a publicly available branch with the patch(es) which are
> based on the packaging branch's correct tag? That makes pu
On Fri, Nov 14, 2014 at 03:13:30PM -0200, Henrique de Moraes Holschuh wrote:
> On Sat, 15 Nov 2014, Ron wrote:
> > On Fri, Nov 14, 2014 at 03:39:05PM +, Ian Jackson wrote:
> > > Ron writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
> > > repositories"):
> > > > Why include the epo
On Fri, 14 Nov 2014, Richard Hartmann wrote:
> On Fri, Nov 14, 2014 at 11:56 AM, Raphael Hertzog wrote:
> > On Thu, 13 Nov 2014, Tobias Frost wrote:
> >> One point came to my mind: NMUs
> >> Can we maybe add some words what would be best practice to handle NMUs?
> >
> > I think the current best pr
On Sat, 15 Nov 2014, Ron wrote:
> On Fri, Nov 14, 2014 at 03:39:05PM +, Ian Jackson wrote:
> > Ron writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
> > repositories"):
> > > Why include the epoch in tags at all?
> >
> > Because we want to be able to tell not just which tag was w
Hi,
>> Really, if all the energy that people put into complaining about systemd
>> and looking for proves to back their complaints (many of which are
>> certainly valid!) would be put into providing alternative
>> implementations of these interfaces that many desktop environments say
>
> I *have*
On Fri, Nov 14, 2014 at 11:56 AM, Raphael Hertzog wrote:
> On Thu, 13 Nov 2014, Tobias Frost wrote:
>> One point came to my mind: NMUs
>> Can we maybe add some words what would be best practice to handle NMUs?
>
> I think the current best practices are fine: the NMUer should send a
> debdiff to th
On Fri, 14 Nov 2014, Ian Jackson wrote:
> expect to find version numbers matching ^\d+\~, then anything matching
These are common enough for me to have not only seen,
but also used (in native packages, of course) them.
(But: Yes, epochs should belong into filenames, except
for filesystem naming
On Fri, Nov 14, 2014 at 03:39:05PM +, Ian Jackson wrote:
> Ron writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
> repositories"):
> > Why include the epoch in tags at all?
>
> Because we want to be able to tell not just which tag was which but
> also what order they are in.
Rig
On Fri, 14 Nov 2014, Ralf Jung wrote:
> Really, if all the energy that people put into complaining about systemd
> and looking for proves to back their complaints (many of which are
> certainly valid!) would be put into providing alternative
> implementations of these interfaces that many desktop
Bernhard R. Link writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
repositories"):
> Raphael Hertzog [14 22:26]:
...
> > When a Git tag needs to refer to a specific version of a Debian package,
> > the Debian version needs to be mangled to cope with Git's restrictions.
> > The co
Ron writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
repositories"):
> Why include the epoch in tags at all?
Because we want to be able to tell not just which tag was which but
also what order they are in.
The only reason I excluded epoch from filenames is that it makes tools
like
Hi,
>> How does having yet another NTP client shut off existing NTP clients?
>
> https://github.com/systemd/systemd/commit/7b8b9686e050a2b19ed2a3686af187dffaab5c08
What do you think this commit does/announces? This is about removing
support from timedatectl to control other NTP clients. If you n
Raphael Hertzog wrote:
> On Thu, 13 Nov 2014, Bernhard R. Link wrote:
> > * Raphael Hertzog [14 22:26]:
>
> > Is using the vendor you use git on a good default for the vendor code
> > you are currently working on? In my experience those two are quite
> > unrelated.
>
> Do you have a better d
On Fri, 14 Nov 2014 14:34:19 +0100
Mathieu Malaterre wrote:
> While reading the wiki page for AutomaticDebugPackages, I was
> wondering if it is possible to post-processed object file to
> manipulate relatives path for debug info ?
>
> Typical use case is that after installing the -dbg package,
Package: wnpp
Severity: wishlist
Owner: Hideki Yamane
X-Debbugs-CC: debian-devel@lists.debian.org,
pkg-fonts-de...@lists.alioth.debian.org
Package name: fonts-ricty-diminished
Version: 3.2.3
Upstream Author: 遊佐泰紀 (Yasunori Yusa)
URL: https://github.com/yascentur/RictyDimi
On Fri, Nov 14, 2014 at 11:25:36AM +0100, Raphael Hertzog wrote:
> On Fri, 14 Nov 2014, Ron wrote:
> > > So I am a Kali Linux contributor. We use git repos to maintain all our
> > > packages and we use git-buildpackage.
> >
> > I guess the first question there is what were the arguments put forwar
While reading the wiki page for AutomaticDebugPackages, I was
wondering if it is possible to post-processed object file to
manipulate relatives path for debug info ?
Typical use case is that after installing the -dbg package, you end up
with a gdb backtrace saying:
[...]
brw_meta_fast_clear (brw=
Brian May writes:
> On 14 November 2014 04:20, Carlos Alberto Lopez Perez
> wrote:
>
>> The last one that I read is that udev is going to stop working on
>> non-systemd systems:
>>
>> http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html
>>
>>
> I don't read anything in that po
On Nov 14, Raphael Hertzog wrote:
> This is just a proof that storing the patches as real commits is useful.
> And that's the point of the patch-queue tag. Instead of having the patches
> only as real commits in the local repository, they get pushed to the
> public repository too under that tag (
On Thu, 13 Nov 2014, Ralf Jung wrote:
> How does having yet another NTP client shut off existing NTP clients?
https://github.com/systemd/systemd/commit/7b8b9686e050a2b19ed2a3686af187dffaab5c08
This is like MSDNAA: give away stuff for free (support xntpd¹)
to get people used to the drug (systemd)
On Thu, 13 Nov 2014, Bernhard R. Link wrote:
> * Raphael Hertzog [14 22:26]:
> > Helper tools should usually rely on the output of `dpkg-vendor --query
> > vendor`
> > to find out the name of the current vendor. The retrieved string must be
> > converted to lower case. This allows users to ov
On Thu, 13 Nov 2014, Tobias Frost wrote:
> One point came to my mind: NMUs
> Can we maybe add some words what would be best practice to handle NMUs?
I think the current best practices are fine: the NMUer should send a
debdiff to the BTS. Maybe the patch doesn't apply on top of the
supplementary ch
On Fri, 14 Nov 2014, Ron wrote:
> > So I am a Kali Linux contributor. We use git repos to maintain all our
> > packages and we use git-buildpackage.
>
> I guess the first question there is what were the arguments put forward
> for deciding to 'standardise' on gbp? If there wasn't one, maybe that'
Package: wnpp
Severity: wishlist
Owner: Thomas Goirand
* Package name: python-pyeclib
Version : 0.9.10
Upstream Author : Kevin Greenan
* URL : https://bitbucket.org/kmgreen2/pyeclib
* License : BSD-2-clause
Programming Lang: C, Python
Description : int
Package: wnpp
Severity: wishlist
Owner: Thomas Goirand
* Package name: liberasurecode
Version : 0.9.10
Upstream Author : Eric Lambert
* URL : https://bitbucket.org/tsg-/liberasurecode
* License : BSD-style
Programming Lang: C
Description : support of m
Unsubscible
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/9f33e2b9ded6d34c966a72f4ef9dfd8c26627...@cn010089.schaeffler.com
43 matches
Mail list logo
