[Russ Allbery]
> ip address also has one of the worst output UI decisions I've ever seen,
> namely this line:
>
> inet 192.168.0.195/24 brd 192.168.0.255 scope global dynamic wlan0
>
> specifically "192.168.0.195/24", which is notation (IIRC) invented by this
> command, used nowhere else in
[Johannes Schauer]
> Old sbuild will not help you. The problem is mainly, that older
> chroots contain an apt installation that has no support for the
> [trusted=yes] option in sources.list.
So if someone really needs this, I guess a workaround would be to
backport apt 1.0 to squeeze...?
Yes, it
[Chris Boot]
> There probably doesn't need to be an ABI break for every version, but
> there is with 2.4.6 => 2.4.7 due to the addition of some variables. If
> this was a shared library it wouldn't necessitate a soname bump as it's
> essentially just a new symbol, but a plugin that happens to use
[The Wanderer]
> it is IMO not viable for actual use - except perhaps by people who
> already know completely what they are doing and how to override
> aptitude's suggestions.
That sounds like you believe aptitude has only a command-line
interface. Mostly I use its full-screen interface. (To se
[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
[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 Mon, Sep 8, 2014 at 11:15 PM, Thomas Goirand wrote:
> > - database-server: commonly one would expect MySQL, and postgress gets
> > installed
[Paul Wise]
> Isn't tasksel for people with no expectations? People who know
> something about the technology they are looking for will install the
> r
[Manuel A. Fernandez Montecelo]
> If you agree that "source-is-missing" also applies in those cases, do
> you also think that we should immediately declare all source packages
> in Debian containing a 'configure' script as somehow non free (unless
> we can check unambigously that they were generat
[micah]
> it feels like a bit too aggressive pressure for my tastes. I've seen
> a lot of developers of packages who have found out their package will
> be removed from testing, but don't have the time to resolve the
> situation before it gets removed, resulting in much pulling of hair.
If only w
[Paul Tagliamonte]
> I was going to send a mail about this yesterday. I've decided
> I'm going to start a quest to support this. I settled on
> Build-Indep-Architecture myself.
Sorry for the bikeshedding, but don't we already have ways to express
exactly what we mean?
Build-Depends-Indep: so
[Christoph Anton Mitterer]
> btw: And quite obviously, this post is not about bashing upstart,..
No, and it's also not about Debian. Could we ... do our Canonical
bashing somewhere else? Please? Thanks.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "uns
[Thorsten Glaser]
> I absolutely do not want to see anything related to ruby on my
> systems.
Why? Is this just an emotional reaction, or is it the 13 MB of
dependencies, or something else?
I wonder if anyone feels the same way about, say, libraries written in
FORTRAN, or binaries linked agains
[Norbert Preining]
> On Di, 03 Sep 2013, Peter Samuelson wrote:
> > texlive-lang-european? It doesn't look like it to me (no Breaks or
> > Conflicts), but I haven't actually tried it.
>
> conflicts there are, texlive-base conflicts with all the old packages.
I
> > Sounds like you are saying 'texlive-lang-danish' is only useful as a
> > package dependency - in other words, users would never install it
> > explicitly because they want its functionality. Is that correct? This
[Norbert Preining]
> I never said that. The functionality is now in
> te
[Norbert Preining]
> I understood your proposal, of course. Still, since there are no rdepends
> besides very few (1?) build-depends on these two packages, I consider
> it a a waste of resources.
Sounds like you are saying 'texlive-lang-danish' is only useful as a
package dependency - in other w
[Thomas Goirand]
> Oh ok. Not useful at all if you ask me. Why? Because sometimes, you
> can't change the MAC address. For example, if you use the OpenStack
> bare metal driver, then you continue to use virtual machine images,
> though they will be used on a real hardware where you can't change
>
> On Wed, 2013-07-31 at 01:30 +0100, Steve Langasek wrote:
> > That's correct. If you want to talk to a loopback-only service,
> > you should be connecting to 'localhost', *not* to the hostname.
[Christoph Anton Mitterer]
> Well why not? Imagine that one server in a cluster serves a debian
> pac
> On Tue, Jun 25, 2013 at 08:04:00AM -0400, Scott Kitterman wrote:
> > This comes up periodically. They aren't real.
[Darac Marjal]
> It would appear they're real enough to trigger clamav's detection,
> which was the problem the OP was having.
Yes. It is not really a fixable problem. The test
[Alberto Garcia]
> I was unaware of this thing and I'm sure I'm overlooking something,
> so can someone give a simple example of actual problems introduced by
> using epochs?
One real problem is that epochs make it easier to introduce human
error in specifying reverse runtime and build deps. E.g
[Igor Pashev]
> Currently /var/lib contains data for system utilities (dpkg, apt,
> aptitute) and for user application like databases.
>
> What about moving default location for applications to /export ?
Wrong list, please bring this up instead on fhs-discuss. (If that
still exists - it looks a
[Matt Zagrabelny]
> I've grepped the d-d list, but didn't find any threads regarding
> fixing epochs in package versions.
This does come up occasionally.
> If so, could we add a field to debian/control such as
> "Supersede-Epoch". If set to 'yes', then dpkg considers this package
> to have an ep
[James Cloos]
> And where does one find dh_make?
>
> Searching on goog suggests it would be part of debhelper. But it isn't:
Someone suggested 'apt-file', but in this case the simpler thing is:
apt-cache search dh_make
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
wi
[Mathieu Malaterre]
> I do not believe in debian life-span, a package manager ever switch
> an implementation of a package. So libjpeg9 and libjpeg-turbo will
> have to co-live.
It happens. Look at the source for 'libc6'. It used to be glibc,
these days it is a fork called eglibc. Likewise the
Zack,
Thank you SO MUCH for your service this past 3 years. Your hard work,
persistence, calm voice and especially your transparency have been much
appreciated.
Peter
signature.asc
Description: Digital signature
[Russ Allbery]
> Oh, I thought they'd given up on Safe. For some reason it stuck in
> my mind that it had too many issues and ended up being deprecated.
> Apparently, I either made that up or misremembered something.
Possibly you were thinking of suidperl, the hack to allow Perl programs
to use
[Charles Plessy]
> - If mentors.debian.org needs to follow the DMCA, why would
> mentors.debian.net be exempt of it ?
It's not exempt, but it's also not Debian's problem.
> - If mentors.debian.org can distribute unreviewed packages by becomming a
> DMCA safe harbor, wouldn't it be po
> +++ Jonathan Dowland [2013-04-05 10:09 +0100]:
> > On Fri, Apr 05, 2013 at 11:07:31AM +0200, Thomas Koch wrote:
> > > This java code should be replaces with something in perl/python/non-JVM.
> >
> > Why?
[Wookey]
> Because it's an entirely unnecessary circular build-dependency. java
> is not p
[Vincent Lefevre]
> I disagree. If the freeze occurred only once (almost) all RC bugs
> were fixed, there would be (almost) no delay. I suspect that the
> length of the freeze is due to the fact that the freeze occurred
> while too many RC bugs were already open.
Agreed: in July 2012, many - too
[Jonathan Dowland]
> On Mon, Apr 01, 2013 at 04:45:19PM +0100, Neil McGovern wrote:
> > You seem to believe that unstable is more important than stable
> > releases. I do not. One of us is in the wrong project.
>
> If, you are suggesting here, that the release process in Debian is utterly
> set i
> > Anyway, rsync sounds like the most appropriate mechanism to
> > transfer these particular databases.
[iceWave IT]
> My blacklists should be available for everyone not only for those who
> can connect with my server via ssh...
rsync doesn't require ssh; for your scenario you probably just wan
[Joachim Breitner]
> this seems to be a good disk-space for human-time trade to me as well:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699333
I'm a bit confused. Given that perhaps 99% of Built-Using would be for
trivial things like crt1.o and libgcc.a, which are concentrated into a
rela
[Benjamin Drung]
> Image the opposite. You want to package a software that is only
> available in a downstream distribution (e.g. Ubuntu or Linux
> Mint). Do you prefer to have a non-native format or a native format?
If their native format is an archive in gzipped tar file format, like
ours is, I
[Holger Levsen]
> Hi Andreas,
>
> On Donnerstag, 10. Januar 2013, Andreas Beckmann wrote:
> > Hi,
> >
> > the following packages from wheezy ship files that are excluded from
> > the .md5sums file:
> >
> > gridsite: FILE WITHOUT MD5SUM /var/lib/gridsite/.gacl
> > gridsite: FILE WITHOUT MD5S
[Joachim Breitner]
> > And a foo-dev Recommends: foo-prof is not suitable because?
>
> because we cannot tell what the user will want. For example, a user of
> xmonad will not want -prof packages installed, and an addition 400MB of
> useless stuff on his computer is not in his, and hence our, int
[Timo Juhani Lindfors]
> Peter Samuelson writes:
> > Note that this adds a keyring to the current list. If the intent
> > is to use the specified keyring alone, use --keyring along with
> > --no-default-keyring.
>
> You probably read "man gpg" bu
[Timo Juhani Lindfors]
> Is
>
> /usr/bin/gpgv --quiet --keyring /etc/myprogram/trusted.gpg file file.sig
> chmod a+x file
> ./file
>
> still a safe way to ensure that only code signed by a key in trusted.gpg
> gets executed?
>From the manpage:
Note that this adds a keyring to the current l
[Helmut Grohne]
> I ask you not to use this proposal for the following reasons:
>
> * Given a package it is now much harder to see whether it is tagged M-A
>or not. Especially you can no longer determine the tagging by simple
>examination of package lists.
That's fair. Though I imagine
In bug #695229, I noted that an Architecture: all package really should
be Multi-Arch: foreign. This led to an IRC discussion between Goswin,
Steve L. and me in which I formulated the proposal:
If a package is 'Architecture: all', and all its dependencies are
'Multi-Arch: foreign' (inclu
[Hideki Yamane]
> > henrich@hp:/tmp$ du -k Packages.*
> > 6052Packages.bz2
> > 5812Packages.xz
> > henrich@hp:/tmp$ time bzip2 -d Packages.bz2
> >
> > real0m0.999s
> > user0m0.956s
> > sys 0m0.020s
> >
> > henrich@hp:/tmp$ rm Packages
> > henrich@hp:/tmp$ time xz
> On Sat, Nov 10, 2012 at 10:47:43AM +0100, Adam Borowski wrote:
> > On the other hand, widespread dumb-ass assumptions about i386/amd64 may
> > cause quite a bit of issues: basically any Makefile that talks about "x86"
> > is somewhat suspicious. This is the main reason one may want to oppose
>
> On Donnerstag, 8. November 2012, Ben Hutchings wrote:
> > > And an annoying technical detail makes it suboptimal to add the microcode
> > > packages as a recommendation of the firmware-linux-nonfree package.
> > ...which is that dpkg does not support architecture-specific relations
> > in binary
[vangelis mouhtsis]
> Can please someone explain why a package should be orphaned
> from maintaining? (i hope the reason is not lack of maintainers)
Yes it is. Or more precisely, every package needs a maintainer with:
1) the skills to maintain it (familiarity not only with Debian
packaging i
[Kelly Clowers]
> But I basically never report bugs. I have used Sid for years, and in
> fact I often don't notice bugs in my personal workflow (maybe if I
> can think of myself as a user? I notice end-user-impacting bugs in
> other areas). If someone comes over and sees me working the might
> say
> This preserves the ability to upload a manual binNMU, which is not
> common, but is useful and sometimes necessary. (And not only for
> bootstrapping an arch or a compiler.)
...and I forgot to add that something like this is required by the GR
http://www.debian.org/vote/2007/vote_002, or at le
[Joerg Jaspert]
> As one thing to keep in mind - we have an acl structure in dak.
> Currently it reads something like
>
> all DD keys are allowed all uploads.
> all DM keys are allowed their own uploads according to DM rights.
> all buildd keys are allowed binary only uploads for their arch.
>
>
[Christoph Anton Mitterer]
> Wouldn't it make sense to start discussions about moving to the
> "strongest" possible?
No. What makes sense is to use a hash that has the properties that are
needed for a particular application.
To use your example of dpkg file checksums, their purpose has _nothing
[Chris Knadle]
> However since all DNS servers are generally meant to use port 53, I
> think it's unlikely to install more than one DNS server locally, so
> I'm not sure if doing this makes sense from a packaging perspective.
> [I can see how it does from an administration perspective.]
It's actu
[Joachim Breitner]
> Would it be possible to extend the syntax to specify lists of
> packages not by name, but by Maintainer,
> e.g. pkg-haskell-maintainers@l.a.d.o? Bonus points if such an
> assigment is expanded at dinstall time, so that the statement “DM
> 1234 may upload all packages owned by
[Neil Williams]
> These are not native packages, they are expressly used by other
> distributions than Debian or even Debian derivatives - just because
> I'm on the upstream team / am the entire upstream team does NOT mean
> that I am justified in polluting the tarball released to RPM users
> with
[Russ Allbery]
> The problem is that the software is called wallet, both the software
> itself and the primary client binary that users invoke. And, of
> course, we have a bunch of documentation and automation at Stanford
> that assumes that name.
That actually seems like a reasonable name to me
[Thomas Goirand]
> Typically, I have / on 2 small RAID1 partitions making the array on the
> first
> 2 HDD (1 or 2 gigs), and /usr on a LVM on a much, much larger RAID array
> (I use mostly software RAID1 and RAID10, but in some cases, much bigger
> hardware RAID5). So yes, that's my usual server
[Russ Allbery]
> All PAM modules are installed under /lib, because that's the path
> used by libpam to load them. However, I don't think the vast
> majority of PAM modules could be considered critical for early boot
> or need to be usable without /usr mounted
It seems pam already looks in both /
> > Automating get-orig-source is a fine idea, but tying it to DEP-5
> > would be unfortunate.
[Jonas Smedegaard]
> You mean that you prefer a separate file for this info?
>
> What should be its name? What should be its syntax?
>
> ...and why start from scratch with this - or does something els
[Peter Samuelson]
> And there is something to be said for the dpkg-source / debhelper
> style, in which each configuration parameter lives in its own tiny
> file (e.g., 'debian/source/format', 'debian/compat',
> 'debian/pyversions') rather than
[Jonas Smedegaard]
> Format:
> http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
> Source: http://susy.oddbird.net/
> Repackaged, excluding non-DFSG licensed fonts and source-less
> JavaScript
> Files-Excluded:
> docs/source/javascripts/jquery-1.7.1.min.js
> docs/source/j
[Holger Levsen]
> if thats true, I don't want any of my package maintainance jobs. can
> you please fire me?
You've been around awhile. If that is true, you should know how to RFA
or orphan packages and/or retire from the Project. You should know by
now that it isn't up to others to "fire" you.
[Raphael Hertzog]
> It the next upstream version of your javascript library provides new
> files, they will not be in the symlink tree that you built in your
> package. So at runtime, it will fail because of the missing file.
Forgive me if I'm missing something basic here, but this sounds like a
[Philip Ashmore]
> I guess I'm confused as to why bash completion needs these.
Easy enough to read /etc/bash_completion and /etc/bash_completion.d/*
and see for yourself why it needs these.
bash-completion is full of special cases to "do the right thing" in
hundreds or thousands of different cir
[Philip Ashmore]
> On my machine running "set > set.txt && ls -lsa set.txt" reveals that my
> environment contains 225517 of "stuff" - some of it is even being
> taken up by
> exported function definitions!
As mentioned earlier, 'set' is not reporting much more than the
environment exported to ex
> > Switch to the deadline IO scheduler
> > [...] and make proper use of cgroups.
> > [...] And disable memory overcommit
[Serge]
> instead of fixing a single default option you suggest every debian
> user to tweak and/or rebuild the kernel? Are you serious? ;)
What?!? "and/or rebuild the kerne
[Russell Coker]
> Would it be possible to have somewhere on the Debian servers for
> storing such files so that they can be referenced in a README file or
> something rather than sent to everyone? I'm sure that most people
> who build a Wordpress package won't use them.
As Paul Wise said, best i
[Steve McIntyre]
> You're not measuring the time taken to sync to the flash drive
> either, so all you're going to be seeing is the speed of writing to
> cache.
Huh, I figured the 'sync' call at the end of each test run covered
that.
> I've done lots of work with USB flash and MMC/SD cards over
[Steve McIntyre]
> The major win with dd onto a raw device is that you can specify the
> block size. For most USB sticks, using a block size of 4MB or so is
> going to be *much* faster than using the default for dd (512 bytes)
> or cp (10 KB IIRC).
That seemed a little fishy to me, since none of
[Samuel Thibault]
> > I think "cp" is even more straightforward.
>
> Does cp accept that way since a long time?
I'm not sure, but I've been using things like "cp boot.img /dev/fd0"
for probably 10 or 15 years on various Linux and Unix systems. (The
fact that I referred to a floppy drive may giv
[Steve McIntyre]
> (http://www.debian.org/releases/stable/amd64/ch04s03.html.en)
While it is refreshing to see "cat debian.iso > /dev/sdX" instead of
the usual dd nonsense (it seems there's an extremely widespread myth
that you need to use dd any time you're reading or writing block
devices), I t
[Uoti Urpala]
> The reason why most old applications do not follow that approach (at
> least not yet) is pretty obvious: their authors never considered it.
> etc-overrides-lib semantics have only become a seriously considered
> alternative fairly recently.
If I'm not mistaken, I first saw this so
[Patrick Lauer]
> 1.0_pre20120503 maybe
That'd be wrong if you expect a real _alpha, _beta or _pre of the given
version in the future. I think in that case you'd need something like
1.0_alpha_alpha20120503 or 1.0_alpha_pre20120503.
There's something to be said for imposed structure, but in this
[David Weinehall]
> So... A (admittedly expensive) pre-inst script that checks the
> system for calls to /usr/sbin/node outside of Debian packages would
> likely do the trick?
That seems like a pretty big violation of the spirit, and possibly the
letter, of Debian Policy.
I mean, why not just t
systemd, or is it just the only one
that's interesting enough to talk about?
I ask because, if porting systemd to kFBSD is a mere matter of
emulating cgroups with jails (from what I understand, jails provide
roughly a superset of cgroups functionality), that's a somewhat
different picture
situation with
software from either the Free Software Foundation or the Apache
Software Foundation seems to be that, oddly, more people think
Canonical is evil than think the FSF and ASF are evil.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
--
To UNSUBSCRIBE, email to debian-dev
ays involves M-A:same.
Now the exact syntax is a bikeshedding issue. My original idea was
"M-A: same-as libfoo" but perhaps something like "M-A: same [libfoo]"
or "M-A: same: libfoo" or even "M-A: same: libc6, libc6.1, libc0.1..."
Finally, I note that thi
[Ian Jackson]
> If you install on i386 your 2 binaries and libc6, you /do/ need the
> i386 libfakeroot. Otherwise if you say "fakeroot " it
> won't work, no matter that /usr/bin/fakeroot is amd64.
libfakeroot is something of a special case, indeed. As a hack to my
proposal, perhaps it can be 'M
0g
Package: gimp-texturize
Multi-Arch: same-as libgimp2.0
Package: libsasl2-modules
Multi-Arch: same-as libsasl2-2
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". T
[Brad Spengler]
> Frankly it makes more sense for me to offer .debs myself than to deal
> with a bureaucracy and non-standard kernel in Debian. It contains
> who-knows-what extra code, and I doubt anyone looked at any of it to
> see if it allows for some way to leak information I prevent against
eing compiled by installing
> the binary package.
Yeah, that's pretty much what he already said. What he's asking is
whether this is actually a good idea, or whether there are better
options.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
--
To UNSUBSCRIBE, ema
[Bernd Zeimetz]
> So there are sources which have executable debhelper files already? I
> doubt it as you'd have to chmod them manually.
Not for native packages.
Not for packages in format 3.0 (quilt).
In both cases, execute permission in debian/ is preserved, with the
obvious exception of debia
[Kees Cook]
> This doesn't work with source-format-1 packages without adding
> "chmod" lines for the scripted debhelper config files in the rules
> file. Perhaps this isn't a big deal since we should all be using
> source-format-3 anyway.
We should? I prefer to think of this whole debacle as yet
uild and propagation. It also would require manual intervention for
any dependency loop.
And (3) seems like a very complex workflow to solve a very small problem.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with
[Goswin von Brederlow]
> Where the relevant patches added to binutils and gcc for this?
See for yourself: http://sites.google.com/site/x32abi/
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject
red file, that change on each 'zip'
invocation. I'm testing with zip 3.0-4 on kfreebsd-i386.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2020183045.ge2...@p12n.org
[Jakub Wilk]
> If a package is marked as "Multi-Arch: same", files with the same
> name have to be (byte-to-byte) identical across all architectures.
> Unfortunately, not all packages obey this requirement.
[libsvn-java 1.6.17dfsg-2+b1]
usr/share/java/svn-javahl.jar
This file is in a pac
so the library itself can be M-A: same? (I suppose a side benefit
is you can use Recommends and cut down a little on the size of your
strict Dependency closure.)
> - BinNMUs (see <http://deb.li/CHYh>).
So I guess we can ignore changelog.Debian.gz hits, as there's not much
we can do
ived, but at least it is
going through Debian infrastructure. The latter even, I believe, uses
proper list software.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe&
[Russ Allbery]
> Compressing all the whitespace out of it seems fine to me; you can
> fix that well enough using an indenter.
Yes, but why would _any_ obfuscator, I mean minimizer, compress
whitespace but not remove comments? The cleverest re-intender in the
world isn't going to be able to resto
[Olivier Berger]
> For users, which don't read d-d-a and receive such emails (below),
> it's a bit unclear what's really happening, IMHO :-/
Ummm ... don't we strongly encourage all package maintainers to read
d-d-a? If not, we should. It is very low traffic and some
[Alessandro Ghedini]
> It doesn't really sound as intended *only* for Parrot (ok, as of now it
> does support only parrot, but in the future this may change).
>
> Also, aren't parrot-nqp and nqp different things? (parrot-nqp is currently
> used to build nqp).
Are you saying one of them is nqp an
sr/lib/${triplet}/pkgconfig:/usr/share/pkgconfig
pkg-config "$@"
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110915183755.gb16...@p12n.org
in /usr/bin and stil be Multi-arch: same.
I don't know how pkg-config handles multiarch either, but however
it detects the desired host arch (is it just the PKG_CONFIG_PATH
variable?), your /usr/bin/foo-config shouldn't have to care.
--
Peter Samuelson | org-tld!p12n!peter | http://
one step.
Not to say we _can't_ adopt the tmpfiles.d approach, just that doing
this sort of thing inside your init script need not be painful.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubs
have Build-Depends-Indep. I wonder if we're using it
everywhere we should be.)
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.deb
rom stunnel4. From
the ITP, I cannot figure out why I would want this instead, or indeed,
why Debian should ship both.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Tr
ad wasn't a _total_ waste of time after all.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110719224237.gh4...@p12n.org
bian releases) would
only be justifiable if there were very solid arguments why systemd is
a big net win for the project, or after a vote showing significant
support for the package.
Just sayin',
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
--
To UNSUBSCRIBE, email to debian-de
file on package purge. Call it the ucf use case.
I'm just laying out the options, I don't know whether one, two, or all
three options would be sensible.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
wi
irable behaviors
for the same basic feature, maybe that's a sign that it is a bad idea
after all.)
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Conta
ight - this is not worth a package
transition. Just wait for the next ABI bump. And if there never is
one, oh well.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble?
now what tools you need and why, not just
"install packaging-dev".
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110617220006.gc4...@p12n.org
;s no need. Additionally, though, if the generated
files you're looking at are really large in comparison to the rest of
the package, then it might be best to drop them to save bandwidth for
uploads and downloads. But I'd say autoconf and automake output isn't
nearly large enough to
, once presumably by hand with some sort of suite override switch,
and that does rather break the abstractions of debian/rules, debhelper,
and the like.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject o
a files
if depended-on
request some binNMUs
This is unstable after all, right? (:
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.
1 - 100 of 539 matches
Mail list logo
