Nikolaus Rath writes ("Re: The Spirit of Free Software, or The Reality"):
> On Jul 15 2015, Ian Jackson wrote:
> > If I use Iceweasl to visit the EFF's web pages, over TLS, I see no
> > reason why I should be exposed to any privacy violations (other than
> >
Nikolaus Rath writes ("Re: The Spirit of Free Software, or The Reality"):
> On Jul 15 2015, Bas Wijnen wrote:
> > As Jakub was saying: just starting it up without even visiting a
> > site yet will do a POST and a *few dozen* GET requests. Shouldn't
> > it be waiting with its checks until it actua
Antonio Terceiro writes ("Re: GitHub “pull request ” is proprietary,
incompatible with Git ‘req u est-pull ’"):
> But if there is server side support for anyone to push to some ref in
> the maintainer's repository without any authentication in a way that
> won't otherwise interefere with the maint
Gerrit Pape writes ("Re: git repositories for packages and signed pushes"):
> On Sat, Jul 11, 2015 at 06:23:59PM +0100, Ian Jackson wrote:
> > The only significant problem is that the relevant versions of git are
> > currently only in experimental. Can we expect these
Marc Haber writes ("Re: The Spirit of Free Software, or The Reality"):
> On Wed, 15 Jul 2015 14:56:28 +1000, Ben Finney
> wrote:
> >Whatever my position ends up being on that, I do have a firm position on
> >another aspect: I greatly appreciate that you're grappling with these
> >issues in Mozilla
Mike Hommey writes ("Re: The Spirit of Free Software, or The Reality"):
> On Wed, Jul 15, 2015 at 01:06:28AM +0200, Jakub Wilk wrote:
> > GET http://www.ebay.com/favicon.ico
> > GET http://en.wikipedia.org/favicon.ico
> > GET http://www.yahoo.com/favicon.ico
> > GET http://www.google.com/favicon.ic
Wouter Verhelst writes ("Re: dgit: all users of dgit << 0.30 please upgrade"):
> On Tue, Jul 14, 2015 at 06:00:32PM +0100, Ian Jackson wrote:
> > * I am going to move the git repositories. The old version of dgit
> >will stop working when I do.
>
> In
A new version of dgit, 0.30, is now in testing.
This has a number of important improvements, but it is not fully
backward compatible with older dgit; furthermore it is not compatible
with a change I intend to make to the server-side infrastructure very
soon.
All existing users of dgit must upgrad
Antonio Terceiro writes ("Re: GitHub “pull request ” is proprietary,
incompatible with Git ‘requ est-pull ’"):
> I have a few ideas about this. I have used gerrit before, and it
> provides a really nice experience except for 2 little facts:
>
> - you have to use a web UI thingy to review patches
Tollef Fog Heen writes ("Re: git repositories for packages and signed pushes"):
> Ian Jackson :
> > I'll also have to talk to DSA about what they think about running a
> > backport of git.
>
> We generally don't have a problem with running backports a
Ben Finney writes ("Re: GitHub “pull request” is proprietary, incompatible with
Git ‘request-pull ’"):
> A putative decentralised [0] Git pull request feature would IMO require
> that anyone with a Git repository can submit a pull request to any
> other, without any registration on a privileged c
We've had some discussion of some of these issues already, but let me
summarise:
Most current workflows for Debian packaging with git involve a git
repository somewhere, and in practice it is very impractical not to
trust the contents of (at least some branches in) that repository.
Currently AFAI
Ben Finney writes ("Re: GitHub “pull request” is proprietary, incompatible with
Git ‘request-pull ’"):
> My reading of https://developer.github.com/v3/#authentication>
> leads me to infer there's no way for to submit a GitHub “pull request”
> without having a GitHub account.
>
> Decentralisation
Tormod Volden writes ("desktop files for xscreensaver hacks in different
desktop environments"):
> Then some DEs would like to use these desktop files and some DEs need
> to have them hidden. Up to now we have been using "OnlyShowIn=GNOME;"
> but e.g. Mate wants to be added [2].
>
> I would like
Dimitri John Ledkov writes ("Re: GitHub “pull request” is proprietary, incomp
atible with Git ‘request-pull ’"):
> What you have described here is github pull requests =) they use
> refs/pull/# namespace though, so one needs to tweak fetch config to
> get them all.
Except that (a) we don't have a
Philip Hands writes ("Re: GitHub “pull request” is proprietary, incompatible
with Git ‘request-pull ’"):
> Ian Jackson writes:
> > (It may be that there is already some software that does this. If so
> > I'm not aware of it.)
>
> Having just been
I realise I'm coming to this conversation late, but:
I have some experience of writing a stunt git push receiver. I would
be willing to write another.
The rough shape would be something like:
* Instead of doing git-request-pull, submitter does git push to some
special URL (perhaps an ssh gi
It looks like nothing got done about this :-(.
Is there any (GPL-compatible) TLS HTTP client library or tool in
jessie which allows me to specify explicitly the expected End Entity
certificate ?
At the moment I'm using curl and wget. I was using --cacert=blah
--capath=/dev/null and it did DTRT s
Niko Tyni writes ("Re: linking perl statically against libperl"):
> If there are several /usr/bin/perl processes and /usr/bin/perl is
> statically linked against libperl, every process has its own copy of
> the libperl code in memory. In the case of dynamic linking, there's just
> one copy.
I don'
Martin Zobel-Helas writes ("Re: Debian Installer Jessie RC 3 release"):
> Can you please explain why you are doing thins now instead of earlier
> releases? This BR has been open since October! Also i expect mininal
> changes in an RC3, not such massive functional changes.
This is not the first tim
Guillem Jover writes ("Bits from the dpkg project: 1.17.x series, general
news"):
> * Raphaël Hertzog has stepped down as maintainer.
Raphael, I want to thank you for all your hard work, and your
contributions to dpkg, some of which have been very important to the
whole of Debian.
Regards,
Ian.
Paul Wise writes ("Re: GitHub “pull request” is proprietary, incomp atible with
Git ‘request-pull’"):
> Just an FYI, there are Debian folks who reject patches to Debian
> services that are sent via git send-email rather than github pull
> requests. Personally I am disappointed by this.
Well, the
Andreas Noteng writes ("Re: Minified javascripts in packages"):
> Guess I'll have to start over again and figure out how to manually
> concatenate the separate upstream files into one huge file. I can see
> how it makes sense, but it also seems like a lot of work for very
> little gain…
So you pro
Vincent Bernat writes ("Re: Minified javascripts in packages"):
>13 avril 2015 17:37 +1000, Ben Finney :
>> Is the implication of “built by web services” that the source isn't
>> available for redistribution? Those would be excluded from Debian
>> trivially by that criterion, then.
>
>Usually, thi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
devo...@vote.debian.org writes ("Results for Debian Project Leader 2015
Election"):
> This message is an automated, unofficial publication of vote results.
> Official results shall follow, sent in by the vote taker, namely
> Debian Project Se
Bernhard R. Link writes ("Re: Should .a library contains non-reallocatable
code?"):
> Compare that to the straightforward case of just building a dynamic
> instead of a static library with some simple:
No-one is proposing that shared libraries should not be built, and
used, when possible. We are
Simon Richter writes ("Re: Should .a library contains non-reallocatable code?"):
> On 25.02.2015 15:35, Ian Jackson wrote:
> >> In libvxi-dev I provide a -fPIC .a library only, mainly for size reasons
> >> (the library consists of RPC proxy/stub code for the VXI-11 p
Simon Richter writes ("Re: Should .a library contains non-reallocatable code?"):
> Am 24.02.2015 um 11:01 schrieb Alastair McKinstry:
> > I agree with this; are there any cases where only a static library _is_
> > provided, and if so why? why not provide a .so?
>
> In libvxi-dev I provide a -fPIC
Bernhard R. Link writes ("Re: Should .a library contains non-reallocatable
code?"):
> Ian Jackson [150224 15:50]:
> > + gcc -Wall main.c -L. -lbar1 -lbar2
>
> You forgot to change that line as I said to change it.
Ah yes, sorry. I can reproduce the problem that way
Jonathan Dowland writes ("Re: conflicts between Debian's and upstream's Debian
package"):
> The "bad" packages Harald is talking about, I think, are external to
> Debian — I don't think he's trying to protect a DD here. So this is
> courtesy rather than hiding problems.
I don't think reference to
Jeff Epler writes ("Re: Should .a library contains non-reallocatable code?"):
> On Thu, Feb 19, 2015 at 05:19:30PM -0600, Jeff Epler wrote:
> > * foomodule is a Python wrapper for libfoo, so it must be shipped
> >as a .so, but if it links libfoo.a, and libfoo.a is not -fPIC,
> >it is not p
simply not possible with static
> libraries.
In practice, a .so built in the way you suggest (with unresolved
references to the dependent static libraries) is not sanely useable in
the ways people normally want to use shared libraries. See just below
for a detailed explanation:
> Ian Jackson [1
Ian Jackson writes ("Re: Should .a library contains non-reallocatable code?"):
> Jeff is correct.
...
> That not usually a problem. Providing that only the relevant symbols
> are exported from the .so, the executable simply results in multiple
> completely independent copies
Bernhard R. Link writes ("Re: Should .a library contains non-reallocatable
code?"):
> Jeff Epler [150220 00:19]:
> > * libbar has a stable API, so it should be shipped as a .so,
> >but if it links libfoo.a, and libfoo.a is not -fPIC, then
> >libbar has to be shipped as a a static library
Mehdi Dogguy writes ("Re: Hosting offers for Debian development"):
> I imagine that this kind of question has been asked many times in the past
> but I didn't see a formal answer for it[1]: If someone is working on some
> new project/service for Debian and wants to be hosted on a DSA-managed
> mach
Daniel Kahn Gillmor writes ("Re: [Reproducible-builds] Reproducible Builds —
proof of concept successful for 83% of all sources in main"):
> However, for packages that don't use a framework we can fix, or which
> use a tool that has no plans to adopt these kinds of modes upstream,
I think that if
Jay Berkenbilt writes ("packages for adoption: icu, tiff, xerces-c, psutils"):
> The other two packages are relatively low-effort packages to maintain.
> The psutils package is dead upstream though there is someone out there
> who might be interested in taking over upstream. I would introduce him
>
olivier sallou writes ("Re: Any way to apply patch on some archs only?"):
> Le Thu Jan 29 2015 at 9:58:18 AM, Paul Wise a écrit :
> > Please post some details of the bug, the patch you want to apply and
> > which package you are talking about so that we can give you a better
> > answer to your que
olivier sallou writes ("Re: Any way to apply patch on some archs only?"):
> Le Thu Jan 29 2015 at 9:58:18 AM, Paul Wise a écrit :
> > On Thu, Jan 29, 2015 at 4:16 PM, olivier sallou wrote:
> > > In my current case, I can apply on all archs if needed, but I wondered if
> > > there was an easy way,
Niko Tyni writes ("Re: new pre-dependency: perl{,-base,-modules} -> dpkg (>=
1.17.17)"):
> On Mon, Jan 19, 2015 at 11:15:04AM +0100, Guillem Jover wrote:
> > I've not looked into the details yet, but just to comment that there's
> > been talk about possibly reverting that fix, because in some erro
Russell Stuart writes ("Re: Who gets an email when with bugreports [was: Re:
Unauthorised activity surrounding tbb package]"):
>
> 701234-subyes-8aba1368a9ac33362ea1f68c28446c15-65bf3bd3886fb8abfe59d40709c84...@bugs.debian.org
>
> I presume this "invite" address is unforgeable (because Ian Jac
Guillem Jover writes ("Re: new pre-dependency: perl{,-base,-modules} -> dpkg
(>= 1.17.17)"):
> On Sun, 2015-01-18 at 20:12:55 +0200, Niko Tyni wrote:
> > In order to fix trigger related wheezy->jessie upgrade failures in
> > xfonts-traditional (#774844, cc'd), I intend to make the main perl
> > bi
Firstly, I should say: I'm sorry that I got the design of this wrong
when I set up the BTS. I hadn't appreciated at the time that bug
reports are actually (amongst other things) ad-hoc mailing lists.
Paul Wise writes ("Re: Who gets an email when with bugreports [was: Re:
Unauthorised activity su
Adam Borowski writes ("Re: length of a package extended description"):
> Some data: count of packages with descs of a given length:
...
Here's Adam's data with cumulative package count, and cumulative
percentage:
> 1- 4 13772 13772 30%
> 5- 9 21324 35096 77%
> 10- 14 6531 41627 91%
>
Marco d'Itri writes ("Re: length of a package extended description"):
> On Jan 09, Vincent Lefevre wrote:
> > Shouldn't the length be limited by the Debian policy?
>
> Shouldn't the length be limited by common sense?
Yes.
> In this case I think that listing the packages without the description
Guillem Jover writes ("Re: one package altering other package's postrm"):
> As mentioned before, just add a versioned Breaks against the cron
> package not supporting that, do not mangle its maintainer scripts.
...
> If using current apt with APT::Get::Purge=true or --purge, or the
> aptitude TUI a
Tollef Fog Heen writes ("Re: curl and certificate verification in jessie"):
> ]] Daniel Kahn Gillmor
> > Unfortunately, this is quite a subtle API change, and it's not clear how
> > to do it safely or sanely.
>
> For curl, it sounds like a simple curl_set_option(CURL_SSL_EE_CERT,…)
> call or simi
Ian Jackson writes ("Re: curl and certificate verification in jessie"):
> Daniel Kahn Gillmor writes ("Re: curl and certificate verification in
> jessie"):
> > It seems to narrowly solve the case in question, but possibly at the
> > risk of making the semanti
Daniel Kahn Gillmor writes ("Re: curl and certificate verification in jessie"):
> It seems to narrowly solve the case in question, but possibly at the
> risk of making the semantics of the API even more confusing than it
> already is.
If they didn't want the API to be full of confusing
backward-co
Daniel Kahn Gillmor writes ("Re: curl and certificate verification in jessie"):
> So, the idea is that when you "accept" an EE cert, you need to do it
> with an explicit associate to a specific peer's name, not just the cert
> itself. newer versions of GnuTLS provide this facility, but it's not
>
Tollef Fog Heen writes ("Re: curl and certificate verification in jessie"):
> Ian Jackson:
> > Each time you generate an EE key which you intend to use this way,
> > also create an ad-hoc single-shot CA. Generate one EE certificate
> > using the CA, on the EE pu
Firstly, I should say that I agree with Peter and Tollef's objectives.
I'm not an expert on TLS but I was under the impression that this
behaviour - requiring that TLS authentication be done by a nontrivial
certificate chain - was specified by the standards (presumably X.509
rather than TLS). I c
Philip Hands writes ("Re: init system policy"):
> Ian Jackson writes:
> > I don't know how much etckeeper users use modifying (rather than
> > recording) git operations, but I can imagine that this approach might
> > easily result in etckeeper's git fig
Philip Hands writes ("Re: init system policy"):
> Would it perhaps make sense to have etckeeper additionally keep track of
> files in /lib directories for packages that have this /etc overrides
> /lib scheme? Such packages could add their config-outside-etc
> directories to a list somewhere, perha
Ron writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
repositories"):
> As I explained in the earlier discussion with Henrique, there are more
> things than just : and ~ which are perfectly legal in debian version
> strings, but are illegal constructs in git refnames.
AFAICT[1], the
Laurent Bigonville writes ("Re: Re: init system policy"):
> Matthias Urlichs wrote:
> > See "man 5 sudoers" for details.
>
> You probably want to use "runuser" that has been introduced recently in
> utils-linux
Or `really' from chiark-really (from chiark-utils).
Ian.
--
To UNSUBSCRIBE, email
Guido Günther writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
repositories"):
> On Fri, Nov 14, 2014 at 03:44:35PM +, Ian Jackson wrote:
> > Current practice seem so be to replace both : and ~ with _. Unless
> > we
>
> This didn't work
Neil Williams writes ("Re: making dput a wrapper around git"):
> On Tue, 18 Nov 2014 16:48:10 +0100
> Daniel Pocock wrote:
> > If an upload to NEW is rejected though then the "-1" version is not
> > known to the archive and should be used again for a fixed upload
> > shouldn't it?
>
> No. You sim
Daniel Pocock writes ("Re: making dput a wrapper around git"):
> One of the problems with a VCS right now though is the order of events
> required to make a tag. If I tag and then upload and my upload is
> rejected for any reason then the tag is not valid.
dgit's answer to this is to say: you sho
Daniel Pocock writes ("making dput a wrapper around git"):
> How would people feel if dput was a wrapper around git?
If you would like to work in a world where dput was a wrapper around
git, then please install dgit and spell `dput' as `dgit push'.
If you do that then people who hate git (a perfe
Simon McVittie writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
repositories"):
> As far as I can see from what you've said elsewhere, for source format
> 3.0 (quilt), you're aiming for the "patches applied and also serialized
> in debian/patches/" state (matching git-dpm I think?),
Anthony Towns writes ("Re: Being part of a community and behaving"):
> "Steve, as long as bugs like [1] are not fixed in systemd-shim, I'm not
> going to make it the first alternative. Installing a half-broken logind
> whould be a disservice to our users."
> https://bugs.debian.org/cgi-bin/bugrepo
Simon McVittie writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
repositories"):
> gbp-pq and git-dpm are the other way round: the tree can be built with
> dpkg-buildpackage, but the cost is that you have to commit in a way that
> isn't the normal git thing (either using a specific to
Simon McVittie writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
repositories"):
> I agree that the expected contents of the branches are far more
> important than their names. Unfortunately, while acting as "the Debian
> expert" for Debian derivatives at $day_job, I keep finding that
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.
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,
&
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
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
Tobias Frost writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
repositories"):
> [Ian:]
> > And you should add:
> >The packaging branch should not contain a `.pc' directory.
>
> Maybe I got the above wrong: you mean "patch applied" after e.g
> quilt push -a ? I think, removing .
Thibaut Paumard writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
repositories"):
> [patches applied vs unapplied]
>
> However, we should perhaps strongly recommend that this choice be
> documented in debian/README.sources.
I think it would be better to document this by the use of d
Raphael Hertzog writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
repositories"):
> Much like we have a "default desktop environment" we should have a default
> layout for a git packaging repository.
There's an argument for that.
Of course (donning my partisan colours) I think the a
Ian Jackson writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
repositories"):
> I think you need to be more explicit about the implications for `3.0
> (quilt)' format packages. Something like:
>
>If the git tree contains debian/format specifying `3.0
Matthias Urlichs writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
repositories"):
> This DEP describes an integrated workflow.
That's true right now. But I think a document called `Recommended
layout for Git packaging repositories' ought to cover the reasonable
possibilties which a
Raphael Hertzog writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
repositories"):
> For development releases
>
>
> Packages uploaded to the current development release should be prepared
> in a `/master` branch.
I preferred the previous text for this section
Raphael Hertzog writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
repositories"):
> +When you have good reasons to only store the `debian` packaging directory
> +(for example when the uptream sources are really huge and contains mostly
> +non-patchable data), you can do so but you sho
Simon McVittie writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
repositories"):
> On 12/11/14 05:54, Mathieu Parent wrote:
> > Also, the vendor/* branches heads should be at a descendent commit of
> > the corresponding upstream branch, diffing only by the debian dir.
...
> Concrete e
Scott Kitterman writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
repositories"):
> Who's going to do patches to existing tools (e.g. git-dpm is the one
> I use and care about) so they comply with this and similarly scripts
> to convert existing git repos to match this recommendation?
Raphael Hertzog writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
repositories"):
> The DEP will neither encourage and discourage its use. It only mentions
> that if a maintainer is using it, it should store pristine-tar data
> in the "pristine-tar" branch.
Would it be worth mentioni
Barry Warsaw writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
repositories"):
> On Nov 11, 2014, at 10:26 PM, Raphael Hertzog wrote:
> >Vendor namespaces
> >-
> >
> >Each "vendor" uses its own namespace for its packaging related
> >Git branches and tags: `debian/*` f
Raphael Hertzog writes ("RFC: DEP-14: Recommended layout for Git packaging
repositories"):
> following the initial discussion we had in August
> (https://lists.debian.org/debian-devel/2014/08/thrd2.html#00499), I have
> written a first draft of the Debian Enhancement Proposal that I suggested.
> I
Ben Finney writes ("Re: Removing duplication: Word lists of common words in
languages"):
> Ian Jackson writes:
> > I had roughly this question in 2013, and found the answer. Here is
> > probably the best starting point:
> >
> > http://www.chiark.greenend.o
Dirk Eddelbuettel writes ("Re: r-base-core upload to unstable does not respect
freeze policy"):
>
> There was a bug report requesting builds against tcl/tk 8.5 instead of 8.6.
> No more, no less -- and I complied.
>
> This nothing to do with wheezy transition issue. I would have thought
> you k
Simon McVittie writes ("Re: r-base-core upload to unstable does not respect
freeze policy"):
> On 11/11/14 15:55, Ian Jackson wrote:
> > perhaps we should in general make more use of testing chroots for RC
> > bugfixes to testing during the freeze.
>
> For build-
Andreas Tille writes ("r-base-core upload to unstable does not respect freeze
policy"):
> [stuff]
I don't want to take away from what you've said, but:
> So I used a testing chroot
perhaps we should in general make more use of testing chroots for RC
bugfixes to testing during the freeze. This
Ben Finney writes ("Re: Removing duplication: Word lists of common words in
languages"):
> Where is a good authoritative source of such words, by frequency, for
> various natural languages, suitable for inclusion in Debian as a data
> package?
I had roughly this question in 2013, and found the an
Santiago Vila writes ("Re: REISSUED CfV: General Resolution: Init system
coupling"):
> On Mon, Nov 10, 2014 at 06:12:46PM +, Ian Jackson wrote:
> > I have a half-written series to make it cope with lettered, rather
> > than numbered, options. Would it be worth my
Neil McGovern writes ("Re: REISSUED CfV: General Resolution: Init system
coupling"):
> Indeed, unfortunately so. Given the rather rushed nature though, it
> would be nice to try and work out a way of avoiding having to do this
> manual action in future. I'm currently working from
> http://anonscm.
Sam Hartman writes ("Time for compassion and the Init GR"):
> [stuff]
Thanks for putting all of that into words.
The future looks scary for Debian as a community, but for all of us,
even if we lose, this result should have some positive aspects. If
the vote provides a definitive conclusion, we c
The Wanderer writes ("Re: Punctuation characters in Debian packaging"):
> On 11/04/2014 at 12:12 PM, Ian Jackson wrote:
> > apt-get seems to prefer actual package names to ones resulting from
> > stripping `+' (which is also IMO a bug).
>
> Can you explain wh
Ansgar Burchardt writes ("Re: Punctuation characters in Debian packaging"):
> No. I don't think package names should be forbidden just because APT
> treats them in a special way. Otherwise you would have to forbid "+" and
> "." anywhere in package names as well as trailing "-" as apt treats all
> o
Joachim Breitner writes ("Re: Punctuation characters in Debian packaging"):
> Am Montag, den 03.11.2014, 15:40 +0000 schrieb Ian Jackson:
> > There are probably a lot of things missing. If you know about some
> > corner of Debian tooling which has exciting syntax, pleas
Bernhard R. Link writes ("Re: dgit and git-dpm"):
> To do an NMU, one has to generate a debdiff anyway to post it to the
> bug report (as the rules for NMUs mandate).
Generating it and reading it are two different things.
As I say, I intend for dgit to be able to send the debdiff to the BTS
all b
Santiago Vila writes ("Re: Bug#752450: ftp.debian.org: please consider to
strongly tighten the validity period of Release files"):
> I have a laptop with testing which I use mostly on weekends. I have a
> partial mirror there, which I try to update as soon as I login into
> the system.
Firstly, I
Stephane Chazelas writes ("Re: Punctuation characters in Debian packaging"):
> Just a wee note:
...
> > ^ package, name (in apt-get and other libapt-pkg old shells
> > users)
> [...]
>
> "old shells" (Thomson, Mashey, Bourne) and new ones: zsh (with
> extendedglob), rc, es, aka
I have just made this wiki page:
https://wiki.debian.org/Punctuation
There are probably a lot of things missing. If you know about some
corner of Debian tooling which has exciting syntax, please add the
information you have.
I have deliberately not listed use in regexps, because regexp engines
Russ Allbery writes ("Re: Bug#752450: ftp.debian.org: please consider to
strongly tighten the validity period of Release files"):
> Russell Stuart writes:
> > If there are two "ways" and one requires a human and the other is
> > completely automatic, all other things being equal for me the "right
Thorsten Glaser writes ("Re: dgit and git-dpm"):
> Ian Jackson dixit:
> [ NMU ]
> >A dgit user should be able to do this without reading the debdiff:
>
> This is a dangerous habit to get into
Why ?
Of course for this NMU approach to be a good one, dgit needs to
Guido Günther writes ("Re: dgit and git-dpm (was Re: Standardizing the layout
of git packaging repositories)"):
> I do wonder if we should switch to using git-pbuilder by default and
> rather offer to invoke 'git-pbuilder create' in case we don't find a
> proper base.cow for it.
I got the impress
901 - 1000 of 2524 matches
Mail list logo
