Enrico Zini writes ("Replacing web assets with symlinks to packaged versions"):
> as upstream of https://github.com/spanezz/staticsite I want it so that
> when people git clone it or open a tarball of it, it just works,
> with no need of installing twitter bootstrap in example/theme manually.
>
>
h
features end up being used. This has already caused some lossage,
where a new not-backward-compatible source sub-format was
accidentally introduced into our archive (!)
One part of the task I need help with is negotiating and selecting an
appropriate technical approach.
Thanks fo
Andreas Tille writes ("Cudos to ftpmaster"):
> when looking at the Debian NEW queue[1] this morning for a moment I had
> the impression to be on a false page. Its fitting on a single page
> currently. For me that's a good reason to send a big thanks to the
> great ftpmasters. Currently its real
Victor Porton writes ("Re: How to select an interpretor version?"):
> I am going to write a program which automatically converts between XML
> formats using scripts described by RDF resources located at namespace URLs
> (not a precise description of my project, but you've got the taste).
>
> The
Josh Triplett writes ("Re: Handling Multi-Arch packages that must be installed
for every enabled architecture?"):
> On Sat, Jun 25, 2016 at 07:08:39PM +0100, Ian Jackson wrote:
> > * LD_PRELOAD hacks need their .so installing for all architecture "for
> > w
Victor Porton writes ("Re: How to select an interpretor version?"):
> Geert Stappers, you have misunderstood my problem.
>
> I want to support ALL interpreters available in Debian (Perl, Python, Ruby,
> Java, etc.)
>
> I need to make supporting all interpreters and all their versions
> manageab
Josh Triplett writes ("Handling Multi-Arch packages that must be installed for
every enabled architecture?"):
> That would solve the problem for the couple of cases it has come up in,
> but it seems far from ideal; I'd welcome an cleaner alternative
> solution. Notably, this doesn't work well for
Clint Adams writes ("Re: Neomutt packages available"):
> On Fri, Jun 24, 2016 at 09:41:38AM +0100, Jonathan Dowland wrote:
> > You seem to be either suggesting that the mutt people should be prevented
> > from
> > their pre-existing plan to move to neomutt, or we should have two neomutt
> > packag
Clint Adams writes ("Re: Neomutt packages available"):
> On Fri, Jun 24, 2016 at 09:24:27AM +0100, Jonathan Dowland wrote:
> > Rather than work with the existing team Elimar has persisted with
> > efforts to package neomutt separately and has even suggested a *different*
> > team is set up to maint
Zlatan Todoric writes ("Re: opinions of snappy packages"):
> I forget about Canonical's CLA from time to time - but this solely
> should be a reason to not adopt it in Free software projects.
I think that's up to the individual maintainer.
If the maintainer is prepared to carry the CLA-less patch
ian_br...@mail.ru writes ("Re: [Pkg-xfce-devel] Bug#827104: Recommends:
obsolete package xfce4-volumed"):
> I'm confused. Does the Debian Project actually WANT people to file bug
> reports? If not, why bother having a public bug-tracker, where the
> standard reply is, "That's not a bug, you're jus
Luca Filipozzi writes ("Re: Genesis of the git.d.o/gitlab.d.o confusion (Was:
Next steps for gitlab.debian)"):
> On Wed, Jun 08, 2016 at 03:19:09PM +, Felipe Sateler wrote:
> > That speaks more to the need of actually dropping the not-shiny-anymore
> > services rather than block adding a new
Pirate Praveen writes ("Re: Next steps for gitlab.debian (Re: GitLab B.V. to
host free-software GitLab for Debian project)"):
> On Tuesday 07 June 2016 11:21 PM, Antonio Terceiro wrote:
> > Praveen, I think you could call this new thing something like
> > labs.debian.net. pkgs.debian.net (the fedo
Russ Allbery writes ("Re: Dropping upstart jobs (or not)"):
> I'd happily maintain upstart configuration in my packages forever if
> people were actually maintaining it or developing it, but since that's not
> happening, it's very hard to see how maintaining configuration for a dead
> init system i
Ben Hutchings writes ("Detecting install vs upgrade in postinst"):
> The postinst script for linux-image-* behaves differently on fresh
> installation vs upgrade. For a fresh installation, it updates the
> default symlinks /vmlinuz and /initrd.img to point to the new kernel
> and initramfs version
Simon McVittie writes ("Re: Bug#824884: netbase: should not recommend
ifupdown"):
> On Tue, 24 May 2016 at 09:08:11 -0300, Henrique de Moraes Holschuh wrote:
> > Whatever we do, we absolutely must bring up a fully configured loopback
> > interface by default.
>
> Happily, our default init system
Adam Borowski writes ("Re: trying to use wireless not from gnome... what's the
incantation?"):
> But it's not without problems. The one Britton met is that NM's interface
> is closely married to Gnome. Yes, you can use nm-cli but it's nowhere near
> pretty, so on a laptop or a phone you want a G
Raphael Hertzog writes ("Re: Debian i386 architecture now requires a 686-class
processor"):
> Agreed. For me, the RC severity means "this should be fixed (before next
> stable release)". The possibility of auto-removal implemented by the
> release team is just a tool to make sure that either the b
Guillem Jover writes ("Re: Debian i386 architecture now requires a 686-class
processor"):
> On Wed, 2016-05-18 at 16:57:48 +, Sune Vuorela wrote:
> > On 2016-05-18, Julien Cristau wrote:
> > > Why aren't those bugs RC?
>
> That's indeed a good question! It would probably be best if a neutral
Guillem Jover writes ("Re: Debian i386 architecture now requires a 686-class
processor"):
> I suppose this is related to unconditional SSE2 requirement in new Qt
> libraries, (bugs #792594, #794739), for which I thought I had clarified
> the conditions and for which I've provided patches already,
(Dropping the bug report; replacing with CC to debian-devel)
Adam Borowski writes ("Bug#823465: dpkg: Won't run at all on i586 Pentium MMX
due to illegal instruction"):
> I'm afraid there's not enough people who care about 586 enough to maintain
> it. And the bad decision of i386 to stick to a s
Johannes Schauer writes ("Re: Extending the build profile namespace"):
> I agree with Helmut [and implicitly, disagree with Ian]
Well, from what you say things are much further advanced than I
thought. You may well be right - certainly I'm no expert in this area
and I think both of you are.
Rega
Daniel Pocock writes ("dedicated live CD for PGP master key management"):
> Some specific things that the live image could do:
> - verifying there is no network connection, no DHCP daemon,
> automatically shutting down if a network connection becomes active
> - formatting 2 or 3 flash drives in a m
Helmut Grohne writes ("Extending the build profile namespace"):
> * The nodoc profile is a bit strange. It is supposed to drop
>documentation from packages or to drop documentation packages. The
>former leads to packages whose content varies with profiles (which
>generally is bad)
I t
Adam Borowski writes ("Re: Packaging of static libraries"):
> On Tue, Apr 12, 2016 at 02:52:33PM +0100, Ian Jackson wrote:
> > I'm afraid that LTO is probably too dangerous to be used as a
> > substitute for static linking. See my comments in the recent LTO
> &
Vincent Lefevre writes ("Re: Packaging of static libraries"):
> On 2016-04-12 14:52:33 +0100, Ian Jackson wrote:
> > I'm afraid that LTO is probably too dangerous to be used as a
> > substitute for static linking. See my comments in the recent LTO
> > thread h
Vincent Lefevre writes ("Re: Packaging of static libraries"):
> On 2016-04-10 14:28:02 +0100, Alastair McKinstry wrote:
> > (1) When performance matters. Here we need the static library to be
> > built without position independent code. This can still give several
> > percent gains depending on arc
Brian May writes ("Re: Overall bitrot, package reviews and fast(er)
unmaintained package removals"):
> In the past I have maintained some important packages by doing regular
> NMUs when the maintainer is not responsive (including emails asking to
> take over the package). So just because the *main
Steffen Möller writes ("-flto to become more of a routine - any change in
opinion since 2011?"):
> I admit to be a fan of link time optimisation and would like to see this
> challenge promoted towards more of a routine challenge to establish for
> our packages. I found this informative thread
>
>
Ian Jackson writes ("Re: a poll for Dgit workflows"):
> Marco d'Itri writes ("Re: a poll for Dgit workflows"):
> > I cannot comment on other the workflows of specific tools, mostly
> > because I have never managed to find one that would solve some problems
Marco d'Itri writes ("Re: a poll for Dgit workflows"):
> I cannot comment on other the workflows of specific tools, mostly
> because I have never managed to find one that would solve some problems
> that I have, but my own packages do not require anything like that, not
> even quilt. E.g.:
Than
Pierre-Elliott Bécue writes ("Re: Bug#782264: grub-install fails in nested
LVM"):
> Thanks for your anwser. I understand.
Thanks.
> And I intend to become a contributor (currently working on it).
Thanks, and good luck.
There are of course many ways to be a contributor to Debian that don't
invo
(I'm replying to Manoj and Marco, almost alternately, in one message.
Sorry if that's confusing...)
Manoj Srivastava writes ("Re: a poll for Dgit workflows"):
> On Wed, Mar 23 2016, Marco d'Itri wrote:
> > Having the alleged needs of naive users dictate the design of our tools
> > looks like a ve
Pierre-Elliott Bécue writes ("Re: Bug#782264: grub-install fails in nested
LVM"):
> Le mercredi 23 mars 2016 à 14:56:01+, Ian Jackson a écrit :
> > You do not even have a right to a reply from a human.
>
> I'm not sure to agree with that.
There are too many b
Pierre-Elliott Bécue writes ("Re: Bug#782264: grub-install fails in nested
LVM"):
> Anyway, I was more concerned by the non-ack of my report.
You received an ack of your report from the bug tracking system.
But it seems that you are concerned that this bug is not getting
enough human attention.
Adam Borowski writes ("Re: a poll for Dgit workflows"):
> On Wed, Mar 23, 2016 at 01:32:59PM +, Ian Jackson wrote:
> > Please don't use source format `3.0 (quilt)', it sucks.
>
> Could you tell us what other downsides it has, besides quilt?
> All othe
Marco d'Itri writes ("Re: a poll for Dgit workflows"):
> I like the general idea of dgit, but I will never use it as long as it
> requires committing patched trees.
Obviously, for dgit to be useful, it has to define a standard
interchange format. That format has to be patches-applied because
oth
Brian May writes ("Re: a poll for Dgit workflows"):
> I think the single-debian-patch makes doing security updates a lot
> harder. Particularly if one distribution has been patched, and the patch
> needs to be ported to other distributions.
>
> Sure, you might be able to retrieve/store the individ
Adam Borowski writes ("Re: a poll for Dgit workflows"):
> On Mon, Mar 21, 2016 at 10:19:01AM +0100, Daniel Stender wrote:
> > Ah yes, source format 1.0 fits better here. Thanks for the pointer and
> > comments (Manoj, too).
>
> Please don't use source format 1.0, it sucks. Instead, you can:
> e
The Wanderer writes ("Re: Possible MBF: Packages depending on iceweasel but not
firefox/firefox-esr"):
> Now, one thing which seems like it _could_ fix this without requiring a
> MBF would be for firefox and firefox-esr to acquire 'Provides:
> iceweasel'. That seems like a misuse of the system to
Daniel Stender writes ("a poll for Dgit workflows"):
> I've experimented with applying `gbp import-orig` on an extra
> upstream branch and merging into e.g. dgit/sid, but this seems to be
> substandard because `dgit quilt-fixup` wants to quiltify all the
> changes in the working tree, which isn't w
Steven Chamberlain writes ("Re: Making Debian ports less burdensome"):
> I think the testing autoremoval thing started out the same way, it
> merely reported long-standing RC bugs, but removal was manual in the
> beginning.
>
> Okay, perhaps I should start working on:
>
> * A report of out-of-d
Enrico Zini writes ("Downscaling responsibilities"):
> [stuff]
I just wanted to say thanks for all the work you have put in.
And also to tell you that it is totally OK to not want to end up here:
> 2. I get stuck looking after it forever.
So it is totally OK for you to to do this:
> I have no
Andreas Tille writes ("Statically linked library in libdevel packages? (Was:
Status of teem package (packaging moved from svn to git))"):
> I came across this question since policy says (see link above) that
> static libraries are *usually* provided. I do not question Mattia's
> arguing but if hi
Russ Allbery writes ("Re: support for merged /usr in Debian"):
> What will kill Debian faster than anything else is to have every idea for
> changing something large, interesting, or possibly revolutionary in Debian
> be met with anger, derision, and attacks.
I know you are engaging in hyperbole,
Nikolaus Rath writes ("Re: support for merged /usr in Debian"):
> On Jan 05 2016, Ian Jackson wrote:
> > People who have been using a configuration for many years naturally
> > become upset when they are told that it has been `unsupported' for all
> > of this t
Marco d'Itri writes ("Re: support for merged /usr in Debian"):
> On Jan 05, Ian Jackson wrote:
> > or which do mount /usr using / rather than initramfs, or some such.
>
> And this has already not been supported for many years, even if it works
> in some cases, so
Marco d'Itri writes ("Re: support for merged /usr in Debian"):
> On Jan 05, Ian Jackson wrote:
> > /etc contains files which are modified during normal operation.
>
> Depending on the operation involved, we consider this to be a bug:
> https://wiki.debian.org
Simon Richter writes ("Re: support for merged /usr in Debian"):
> However, we do have a huge installation base outside of that. In most of
> my embedded systems projects, Debian has been the starting point for the
> customized installation, simply because before jessie, you could simply
> call "deb
Marco d'Itri writes ("Re: support for merged /usr in Debian"):
> On Jan 02, Joerg Jaspert wrote:
> > No, /etc can be nicely ro. That is, /, /usr, /etc, ... can be. The log
> > storage and the user homes, as well as a tmp filesystem rw, rest ro.
> > Works nicely, I have 4 of such systems running.
>
Ansgar Burchardt writes ("Re: support for merged /usr in Debian"):
> m...@linux.it (Marco d'Itri) writes:
> > Thanks to my conversion program in usrmerge there is no need for a flag
> > day, archive rebuilds or similar complexity and we can even continue to
> > support unmerged systems.
>
> Is the
Jonas Smedegaard writes ("how to respect licensing for derived installer
images?"):
> I suspect the effective license of the combined work of the official
> Debian install images is quite likely some version of GPL, which means I
> will need to provide (or promise to provide) sources involved.
>
Daniel Reurich writes ("Re: git, debian/ tags, dgit - namespace
proposal [and 1 more messages]"):
> "archive" is rather indescript and confusing too.
Sadly there's not space for an essay, and the underlying situation
(particularly, the existing use of the DEP-14 namespace) is already
confusing :-
Barry Warsaw writes:
> On Nov 16, 2015, at 04:52 PM, Ian Jackson wrote:
> >I'm leaning towards
> > archive/{debian,ubuntu,...}/
> >
> >This is on the grounds that the tag's semantics are that the source
> >code referenced by the that is what is in
Marc Haber writes ("Re: Ideas to improve dpkg/ucf with hooks"):
> On Sun, 15 Nov 2015 23:10:11 +0100, Wouter Verhelst
> wrote:
> >On Fri, Nov 13, 2015 at 05:47:41PM +0100, Marc Haber wrote:
> >> Regarding dpkg, its conffile handling is IMO beyond repair, it should
> >> be deprecated and later remo
Guido Günther writes ("Re: git, debian/ tags, dgit - namespace
proposal [and 1 more messages]"):
> On Mon, Nov 16, 2015 at 03:11:54PM +0100, Stefano Zacchiroli wrote:
> > You're absolutely right in being unwilling to use "dgit" as part of the
> > namespace, on the basis that it is just a specific
Ian Jackson writes ("Re: git, debian/ tags, dgit - namespace proposal
[and 1 more messages]"):
> Colin Watson suggested (in pers.comm)
>pkg/debian/
> This is better but it still has a problem with collate order.
>
> It may seem a petty thing to worry about, but fo
[resending because my MUA messed up]
Ben Hutchings writes ("Re: git, debian/ tags, dgit - namespace
proposal"):
> Deliberately creating identifiers that differ only by case seems
> gratuitously confusing.
I acknowledge that this is a downside of my proposal. However, it is
IMO important that th
Currently, the debian/ git tag namespace is used by a number
of different tools, and can mean different things in different
packages and sometimes even different things for the same package in
different repos or trees.
dgit produces, and the dgit git server requires, tags of this form,
which refer
Marc Haber writes ("Re: Putting default config files in /usr [was; (newbie)
Disruptive LIRC package update.]"):
> On Wed, 11 Nov 2015 13:59:24 +0100, Mat wrote:
> >This is one strong key point of
> >Debian versus most other distribs. Please don't change that.
>
> For systemd, this change is alre
Adrian Knoth writes ("Re: [Pkg-netatalk-devel] Bug#685878: Another year has
passed, still no netatalk3"):
> We need to escalate this. Apparently, none of us has time to work on it,
> so external help is the only way forward I see.
>
> Looks like we're talking about ~10 FIXMEs in debian/copyrights
Wookey writes ("Re: DAK Commands for Bikesheds"):
> It wasn't supposed to be a joke. Bikeshed is an appropriate name, in
> the unix tradition of mildly amusing/punny names.
It's a lovely joke but unfortunately the word `bikeshed' already means
something else in a computer/geeky context. So these
Simon Josefsson writes ("Re: GNU IceCat?"):
> What's a good way to do that efficiently? People have submitted bugs
> against Iceweasel to do some of the things that IceCat does by default,
> for example https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=654336
Well, a good start would be to turn
Niels Thykier writes ("GCC-5 transition will move to testing tonight"):
> Thanks to Adam, Julien, Jonathan, Matthias, Scott, Simon and many
> others, we are ready to migrate the bulk of the GCC-5 transition and
> related sub-transitions to testing tonight. Apologise for the short notice.
Wow, imp
Vincent Bernat writes ("Re: Security concerns with minified javascript code"):
> In the Debian context, the problem is hard. But if you allow network
> access and execution of arbitrary code recovered from some random
> registry, rebuilding the minified version from the unminified one is
> quite tr
Vincent Bernat writes ("Re: Security concerns with minified javascript code"):
> My point is not that's a good idea. My point is that this has been
> tolerated for years while there was an easy workaround solution (running
> autoreconf).
It was only tolerated because problems (that is, packages co
Joachim Breitner writes ("Re: git interface to snapshot.debian.org"):
> Am Dienstag, den 25.08.2015, 21:47 +0100 schrieb Ian Jackson:
> > (Although if a .dsc migrates between suites, the git history
> > is updated.)
>
> I don’t understand that. Is there real
Joachim Breitner writes ("Re: git interface to snapshot.debian.org"):
> Am Dienstag, den 25.08.2015, 13:59 +0100 schrieb Ian Jackson:
> > > If the answer is „Nothing is stopping, just that someone has to do it“,
> > > then I’m volunteering, as long as I c
Jakub Wilk writes ("Re: Security concerns with minified javascript code"):
> Ian Jackson , 2015-08-25, 19:08:
> >I've not heard of people (for example) using private autoconf macros
> >not included in their build tree.
>
> #580190
*reads* *blink*
Err,
Bas Wijnen writes ("Re: Security concerns with minified javascript code"):
> AFAIK Debian doesn't *require* generated files to be rebuilt. For
> example, it used to be common practice for a long time to copy
> config.{guess,sub} from autotools-dev instead of regenerating them
> with autoreconf (I
Niels Thykier writes ("Replacing ldconfig maintscripts with declarative
methods"):
> A possible solution is to replace these scripts with an
> "activate-no-await" trigger (again, no-await to avoid trigger cycles).
> I would need libc-bin to promote its trigger to part of its API for this
> to work
Joachim Breitner writes ("git interface to snapshot.debian.org"):
> this is a follow-up to my question after the dgit talk today: It would
> be great to have a git view of the a package’s history in Debian. There
> is some possible overlap with dgit in the sense that if everyone had
> been using dg
Simon McVittie writes ("Re: Ad-hoc survey of existing Debian git integration
tools"):
> By definition, there shouldn't be any packages in the archive with this,
> because dpkg does not include the local-options when it builds a .dsc:
> that's why it's called "local". You'd have to construct a pack
Thorsten Glaser writes ("Re: Ad-hoc survey of existing Debian git integration
tools"):
> tglase@tglase-nb:~/Misc/Vendor/xrdp $ cat debian/source/local-options
> unapply-patches
I want to test whether a package with this in its source tree works
properly with dgit. Do you know (or does anyone els
Colin Watson writes ("Re: Ad-hoc survey of existing Debian git integration
tools"):
> On Tue, Aug 04, 2015 at 07:47:23AM +0100, Ian Campbell wrote:
> > AIUI this is compatible with dgit, although I've not tried it.
>
> Based on my discussions with Ian J, the only incompatibilities between
> my gi
Ian Campbell writes ("Re: Ad-hoc survey of existing Debian git integration
tools"):
> But git log shows that they are, it's just that Quilt is unaware of
> this (no .pc directory in git). Perhaps grub and python-pip differ here
> but I don't think so.
Right.
> AIUI this is compatible with dgit,
Guido Günther writes ("Re: Ad-hoc survey of existing Debian git integration
tools"):
> On Fri, Jul 31, 2015 at 03:21:59PM +0100, Ian Jackson wrote:
> > I think the problems you are describing arise when the user does _both_
> > (a) manipulate the patches in debina/p
Ian Jackson writes ("Ad-hoc survey of existing Debian git integration tools"):
> I would like to think some more about the workflows of the existing
> tools people are using to work with Debian and git, so that I can
> provide good guidance for how these tools work with dgit
Guido Günther writes:
> Having patches applied with 3.0(quilt) calls out for sync problems
> between your git tree and debian/patches/. This can be mitigated with
> --single-debian-patch --auto-commit but that's not what most people mean
> when talking about 3.0(quilt) - and it kind of defeats it's
Svante Signell writes ("Re: Adding support for LZIP to dpkg, using that instead
of xz, archive wide"):
> On Thu, 2015-07-30 at 11:47 -0700, Steve Langasek wrote:
> > > http://www.debian.org/intro/free
> > > "Truly free software is always free. Software that is placed in the public
> > > domain can
Vincent Bernat writes ("Re: Ad-hoc survey of existing Debian git
integration tools"):
> [Ian Jackson:]
> > Do your published git branches contain the patches-applied or
> > patches-unapplied tree ?
>
> Without using "gbp pq", the published git branches ar
Michael Stapelberg writes ("Re: dgit 1.0, available for all users"):
> Let’s assume I want to make an improvement to a package. I’d start by
> cloning it using dgit, then I’d make my modifications, but then what?
> Typically I’d use git format-patch and send the resulting file to the
> maintainer t
Simon McVittie writes ("Re: Ad-hoc survey of existing Debian git integration
tools"):
> Yes ish, but with the orig/diff structure the way it is, the preferred
> form for modifying a non-native Debian package seems to be the tree
> representing the unpacked package, plus the orig tarball (or enough
picca writes ("Re: Re: RE:RE:Ad-hoc survey of existing Debian git integration
tools"):
> It seems to me but I can be wrong that the dgit informations stored
> under .git/dgit are sort of meta data which point to git ref
> corresponding to packages uploaded into Debian.
Don't look in .git/dgit. T
Vincent Bernat writes ("Re: Ad-hoc survey of existing Debian git integration
tools"):
> There is a patch management system but I think that most people (at
> least me) are just using gbp with plain/normal quilt.
Do your published git branches contain the patches-applied or
patches-unapplied tree
Simon McVittie writes ("Re: Ad-hoc survey of existing Debian git integration
tools"):
> "gbp buildpackage" can work either way, but I think most gbp users
> consider a patches-unapplied tree to be what they normally work with
> (for instance that's what the pkg-perl team uses).
Right.
(dgit need
PICCA Frederic-Emmanuel writes ("RE:RE:Ad-hoc survey of existing Debian git
integration tools"):
> > dgit is a step in this direction.
>
> Yes and it is nice to have meta data (the dgit things) rerpresenting
> the packages which can be shared between derivatives.
I don't understand what you are
Felipe Sateler writes ("Re: Ad-hoc survey of existing Debian git integration
tools"):
> On 29 July 2015 at 07:34, Ian Jackson wrote:
> > If you are an NMUer or a downstream using dgit, you should usually
> > make plain git commits (with no changes to the patch stack).
PICCA Frederic-Emmanuel writes ("RE:Ad-hoc survey of existing Debian git
integration tools"):
> It seems to me that Debian should propose a sort of decentralized
> github which should allow upstream to setup within a minute a 'PPA'
> which can be naturally connected and beneficiate of the buildd,
Felipe Sateler writes ("Re: Ad-hoc survey of existing Debian git integration
tools"):
> On Tue, 21 Jul 2015 18:46:47 +0100, Ian Jackson wrote:
> > That is, the dgit git tree contains the patches in debian/patches/ but
> > also contains the implied changes in the main
Wouter Verhelst writes ("Re: Facilitating external repositories"):
> On Thu, Jul 23, 2015 at 01:03:15PM +0100, Ian Jackson wrote:
> > The /name/ of the external repository should also be covered by the
> > signature.
>
> What would you describe as the "name
Wouter Verhelst writes ("Re: Facilitating external repositories"):
> - It may be GPG-signed by one or more keys. Apt should have a way of
> configuring GPG keys that may be allowed to sign sources.list files,
> preloaded with the set of keys in the Debian keyring. This will allow
> system adm
Thorsten Glaser writes ("Re: Ad-hoc survey of existing Debian git integration
tools"):
> [workflow description]
Thanks. FYI, dgit trees are (for `3.0 (quilt)' format source
packages) what is nowadays called a `patches-applied packaging
branch'.
That is, the dgit git tree contains the patches in
I would like to think some more about the workflows of the existing
tools people are using to work with Debian and git, so that I can
provide good guidance for how these tools work with dgit (and perhaps
send feature requests for those tools, or know what extra features are
needed in dgit).
I am a
Ben Caradoc-Davies writes ("Re: debian github organization ?"):
> On 19/07/15 23:36, Florian Weimer wrote:
> > The single account policy means that users
> > would have to share authentication information across different roles,
> > which may not be acceptable.
>
> I am not sure why this would be
Simon McVittie writes ("Re: GitHub “pull request ” is proprietar y, incom
patible with Git ‘requ est-pull ’"):
> On 16/07/15 18:14, Ian Jackson wrote:
> > Can you point me at the server code, or configuration that handled
> > your push ?
>
> Documenta
Paul Wise writes ("Re: GitHub “pull request ” is proprietary, incom patible
with Git ‘requ est-pull ’"):
> On Wed, Jul 15, 2015 at 9:13 PM, Antonio Terceiro wrote:
> > But if there is server side support for anyone to push to some ref in
> > the maintainer's repository without any authentication i
Antonio Terceiro writes ("Re: GitHub “pull request ” is proprietary,
incompatible with Git ‘req u est-pull ’"):
> On Wed, Jul 15, 2015 at 03:25:52PM +0100, Ian Jackson wrote:
> > Would you like me to write you a proof-of-concept ?
>
> It would be nice, but given the amo
Ben Finney writes ("Re: The Spirit of Free Software, or The Reality"):
> So the above seems to argue either that search engine icons are
> sufficiently important that we can violate the Social Contract, or I've
> misunderstood. I'd like to know exactly where that misunderstanding is.
You are argui
Ian Jackson writes ("Re: The Spirit of Free Software, or The Reality"):
> Right. I find it disappointing to discover that in Debian we have
> deliberately modified Iceweasl to make this problem worse, even if
^
Also, why do I keep doing that ?
e
801 - 900 of 2524 matches
Mail list logo
