Tollef Fog Heen writes ("Re: RFC: Idea for improved diversions and alternatives
handling"):
> And the uncommon case:
> debian/foo.divert:
> /lib/libc.so.6 /lib/foo/libc.so.6
>
> (Whose responsibility it is to ensure /lib/foo exists in that scenario
> is something I'm not completely sure about, bu
brian m. carlson writes ("Re: RFC: Idea for improved diversions and
alternatives handling"):
> You still have to handle multiple diversions for /bin/sh. When d-i
> installs the system, you have to have a working /bin/sh immediately; you
> can't wait for the alternatives mechanism to be set up. A
Raphael Hertzog writes ("Bug#489132: lenny release notes, upgrade dpkg first"):
> To work-around a problem that can happen in the perl 5.10 upgrade (see
> #479711), the perl scripts contained in dpkg (update-alternatives,
> dpkg-divert) have been modified... but for the work-around to be used, the
Jon Dowland writes ("Re: Considering the removal of ntpdate"):
> On Fri, Apr 24, 2009 at 12:30:36AM +0200, José Luis Tallón wrote:
> > - For Squeeze+1: just drop it
Why would we ever need to drop it ?
> At some point, sqwalk on STDERR on invocation about its
> deprecated-ness? or is that a st
Raphael Geissert writes ("Switching /bin/sh to dash (part two)"):
> * Make dash essential, make it divert the current /bin/sh symlink by
> default, make another essential package depend on dash. Prompt the
> user before diverting on interactive upgrades.
This needs to be done with great care to en
Goswin von Brederlow writes ("Suggesting new method to handle dpkg diversions"):
> What if each package could list all its current diversions in
> DEBIAN/diverions (i.e. in the control.tar.gz)?
This is in principle a good idea. It does need thinking about quite
carefully to make sure everything h
For some time the idea of having some kind of event queue notification
mechanism in dpkg has been floating about. For example, it would be
used to avoid running scrollkeeper-update dozens of times during an
upgrade and could simplify the emacs addon registration. Wichert and
I even had a good des
Steve Langasek writes ("Re: recent etch upgrade... sashroot (uid=0) started to
impersonate uid=0 (root)"):
> Sure, there may have been a behavior change in libc6. But the output of
> getpwuid(0) is *undefined* when you have more than one record in /etc/passwd
> with uid 0, so it's not a bug for t
Steve Langasek writes ("Re: recent etch upgrade... sashroot (uid=0) started to
impersonate uid=0 (root)"):
> Again, I believe the behavior is not a bug because the behavior of
> getpwuid() when two users share the same uid is undefined.
Where is the format of /etc/passwd standardised, so that we
In late January and February we had a thread about my proposals for a
new dpkg triggers feature. Thanks very much to everyone who provided
feedback.
Following some very cogent criticisms from Florent Rougon I posted a
significantly version on the 2nd of March but we were all too busy
trying to re
Don Armstrong writes ("Re: Reasons for recommends and suggests"):
> On Fri, 18 May 2007, Hendrik Sattler wrote:
> > The description should not explain what the other package is but
> > _what_ it does to the selected package.
>
> In order to explain what the recommended package does to the
> recomm
Guillem Jover writes ("Parsing of dpkg status file considered harmful"):
> Please stop parsing dpkg status file from maintainer scripts. No
> package should assume its location or format (except for now for
> package managment frontends and the like, until there's a proper
> library they can use).
shirish writes ("Using standardized SI prefixes"):
> Please look at http://en.wikipedia.org/wiki/Binary_prefix .
Urgh, these things are ugly and an abomination. We should avoid them.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EM
Bill Allombert writes ("Re: Can we require build-arch/indep targets for
lenny?"):
> In 3 years and a half, I had the time to try all of that...
> So I will try something new: an online petition:
>
> If you would like bug #229357 to get an answer, please
> send a signed email to the buglog.
Pleas
Loïc Minier writes ("Use of "Breaks" dependencies"):
> It's my understanding that dpkg now supports the "Breaks" dependencies,
> and I also recall there was some discussion around last minute fixes
> before etch to support Breaks, but what's the final status: are we
> allowed to use Breaks in p
Robert Collins writes ("RFC: declaritive diversions"):
> I don't have a proposed syntax at this point, but I was thinking a
> control file in the source such as debian/PACKAGENAME.diversions would
> be a good starting point - if thats able to record everything thats
> needed, even if the binaries s
Vincent Fourmond writes ("Source package containing HTML-only form of texinfo
doc"):
> I am currently reviewing the qtoctave package (#430731) before
> sponsoring it. The package is now in a pretty good shape, excepted with
> a problem for which I would like to have some advice: the qtoctave
> u
Simon Richter writes ("Re: Bug#229357: Can we require build-arch/indep targets
for lenny?"):
> The entire issue circles around not being able to reliably detect
> whether the target is present using a simple script. But who said it has
> to be a script?
We want the package to _declare_ whether
Steve Langasek writes ("Re: Bug#229357: Can we require build-arch/indep targets
for lenny?"):
> Attached is a patch to dpkg which implements a check for a 'build-arch'
> target using 'make -f debian/rules -qn build-arch'.
Why are we so resistant to the new debian/control field ? That
doesn't req
Steinar H. Gunderson writes ("Re: RFC: declaritive diversions"):
> if ! dpkg --assert-declarative-diversions 2>/dev/null; then
> dpkg --divert etc.
> fi
I would prefer to do this in dpkg-divert. Eg
dpkg-divert --also-declaratively-declared ...
> Given that we already seem to have such a
Russ Allbery writes ("Re: Can we require build-arch/indep targets for lenny?"):
> Lo?c Minier <[EMAIL PROTECTED]> writes:
> > Why not promote these to requirements in a particular policy version
> > instead? I fear we will have to list 10 Build-Options in all packages
> > in a couple of years.
Recently, this happened:
1. A .deb in which I have an interest, but of which I am
not the maintainer, had its binary package name changed.
So far so good. (In fact I actually approve of the change.)
However, then:
2. The maintainer of this package discovered that its testing
propagati
Sorry for the delay in replying to this ...
Ben Finney writes ("Re: Dpkg triggers and user experience, aka "How do I
disable those triggers" side effect."):
> How about "Resuming deferred installation steps" or similar?
... but yes, I think this would be a better phrase. It is true that
`trigge
Steve Langasek writes ("Re: Adding lzma to dpkg's Pre-Depends"):
> On Tue, Jul 29, 2008 at 09:28:01PM +0200, Andreas Barth wrote:
> > What advantage would we (as in Debian) have if dpkg pre-depends on lzma,
> > instead of the packages pre-depending on lzma?
>
> If dpkg internalizes the lzma suppor
Below is an example report, which would be sent to [EMAIL PROTECTED]
instead if I had it enabled.
Ian.
From: Ian Jackson <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: autopkgtest lenny aolserver4: erroneous package!
Date: Mon, 25 Aug 2008 18:18:13 +0100
Source: aolserver4
Vers
Gonéri Le Bouder writes ("Re: automatic bug filing by test robot"):
> Sorry for promoting my pet toy but I think your script would be a
> great input.
Right ...
> I'm working improving svnbuildstat to be able to support different input. The
> idea is:
> -a database
> -a webinterface to follow t
Jonathan Wiltshire writes ("Re: automatic bug filing by test robot"):
> I'm inclined to agree. I would find it very useful to get reports, but
> not as a bug against my package.
That seems to be the consensus. Fair enough. I shall see about
getting a PTS tag for these reports. I'll leave them f
Daniel Baumann writes ("Debian Live Lenny Beta1"):
> * The rescue flavour, containing system rescue and forensic related
> packages, is missing in this beta release.
I've spoken to Daniel and the main question here is determining the
right list of packages for the rescue flavour.
So in a sp
Lucas Nussbaum writes ("Re: automatic bug filing by test robot"):
> I think that we have a problem with the way we export data from
> automated tests. Consensus is (I think) that bugs should not be filed
> automatically, unless the person filing the bugs is reasonably sure of
> the validity of the
Stefano Zacchiroli writes ("Re: automatic bug filing by test robot"):
> Can you expand what do you mean by "test installs"?
The equivalent of
apt-get install
(without a controlling terminal and with a noninteractive debconf
frontend).
> The main points which are not clear to me are: are depend
Others have explained why this is not a critical bug in this specific
case. (Although as an aside it seems quite incomprehensible to me
that these projects, and Gnome in general, have effectively thrown
away the source!)
But there was one misunderstanding here which I think is important to
correc
Manoj Srivastava writes ("I hereby resign as secretary"):
> I am hereby resigning as secretary, effective immediately.
I'd just like to join all the other people saying that it's sad that
we have come to this. As you know I haven't always agreed with your
decisions :-) but they have alway
I'm not sure if I really want to get into the bz2-vs-gz argument again
but there is a question here that's easy to answer:
Romain Francoise writes ("On bz2 compression in debs"):
> 2) Doesn't the disappearance of 'data.tar.gz' warrant a bump of the
> binary version number, from 2.0 to, say, 3
As I report on debian-dpkg in
<[EMAIL PROTECTED]>
I'm proposing to deploy a new dpkg status file parser.
It would be bad if someone installed the new dpkg but then the new
dpkg rejected their status file. I think I've captured the complete
historical syntax as accepted generated by existing dpkg
Raphael Hertzog writes ("Re: Debian's Linux kernel continues to regress on
freedom"):
> I also argued (on IRC) about the fact that removing some non-free parts
> of upstream source tarballs (like RFC) is not really worth it if we make
> sure that it doesn't end up in binary packages.
I agree wit
David Anderson writes ("Packaging a library that requires cross-compiled code"):
> 2) Package an arm7 cross-compiling gcc with just the right set of
> options, integrate that with the packaging tools, and then package
> with a Build-Depends on the cross-compiler.
>
> Pro: feels like the Right Way,
Ben Finney writes ("Re: modified email address in debian/copyright file"):
> I argue that the only fair place to draw the line is "valid RFC 2821
> email address". The alternative is to leave it to ongoing subjective
> judgement of unspecified Debian parties as to which addresses make
> sense or no
Simon Richter writes ("Re: Packaging a library that requires cross-compiled
code"):
> David Anderson wrote:
> > But, if there is precedent, it might not be too painful to mimick
> > existing cross-compiler packages to build my own. I'll see what I can
> > do.
>
> Please coordinate any such effort
David Anderson writes ("Re: Packaging a library that requires cross-compiled
code"):
> This provides a way to build the entire package, using only
> debian-provided packages, with a 'caching' functionality to avoid
> having to rebuild a toolchain if a previous version of the package is
> installed
David Anderson writes ("Re: Packaging a library that requires cross-compiled
code"):
> I'm not sure what you mean by detecting accidental breakage to the
> build machinery, but that means building a full cross-compiler each
> time the package is rebuilt. Currently, we have a set of rules that
> us
martin f krafft writes ("seeking: Ian Jackson"):
> In the mean time, I'd be grateful if Ian gave me a means to
> communicate with him. Or if someone would offer to relay a message
> to him.
A few people have drawn my attention to this thread, thanks. For
future reference
martin f krafft writes ("Re: RFC 2?821 and CNAMEs"):
> Of course I can ensure that, and that's what I had a while ago: for
> each of my road-warriors (rw.madduck.net; 19 of them; no, not all
> laptops; long story), I had a separate pair of MX RRs.
>
> I sought to simplify that and created rw.maddu
Nico Golde writes ("Re: Bits from the Testing Security team"):
> Yes, dpkg for example links statically against libbz2 and zlib just to
> pick a famous example.
IMO this is a mistake, and I hope it will be reversed soon ...
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
Nico Golde writes ("Re: Bits from the Testing Security team"):
> quoting Adam Heath from #debian-devel:
Thanks for passing that on.
> 2007-10-15 18:07 dpkg's configure has an option for using
> shared libraries or static linking
> 2007-10-15 18:08 for gzip, it can do a
to both the cpu
cost of decompressing it and of course the cpu cost of processing each
file during installation.
> On Tue, Oct 16, 2007 at 02:34:36PM +0100, Ian Jackson wrote:
> > Having dpkg invoke the decompresser as a separate program provides
> > several IMO important a
Roland Mas writes ("Re: Bits from the Testing Security team"):
> I thought the ability to just copy one binary (/usr/bin/dpkg) from one
> box to another and be able to use it right away was precisely the goal
> of static linking in that case.
You still get that, unless the point was to play with n
I've been working on getting my automatic package tester working.
It's currently running but I've redirected its automatic bug
submission emails to me, while I make sure that the bugs it reports
are correct.
One common problem that it finds is ambiguously specified
Build-Depends. For example:
l
Neil Williams writes ("Re: Mandatory support for -nocheck in
DEB_BUILD_OPTIONS"):
> "Packages that run a test suite during the default build must support
> omitting the tests either upon detecting cross-compiling using
> dpkg-architecture or when -nocheck is specified in DEB_BUILD_OPTIONS."
I sup
Loïc Minier writes ("Re: Mandatory support for -nocheck in DEB_BUILD_OPTIONS"):
> On Wed, Nov 07, 2007, Ian Jackson wrote:
> > What you mean is that you don't want binaries generated at one point
> > being executed later during the build. I think it would be better
Florian Weimer writes ("Re: buildds: "Authentication warning overridden.""):
> In this case, HTTPS should be used to download the packages, together
> with proper certificate validation. This has got the added benefit that
> passwords aren't sent in the clear (well, unless an error occurs, but
> t
Steve Langasek writes ("Re: can Breaks be used already? (was Re: Opinions
sought: mlocate appropriate for Priority: standard?)"):
> I think you mean that Ian Jackson always recommends upgrading apt and
> aptitude prior to performing dist-upgrade. :) The release notes haven't
Steve Langasek writes ("Re: dpkg-shlibdeps and private libraries"):
> On Tue, Nov 06, 2007 at 08:51:05AM +0100, Andreas Tille wrote:
> FWIW, I don't agree that this is a fix. In one sense it makes /usr/lib
> "cleaner" by moving private libs into a private directory; however:
There is at least one
=?iso-8859-2?Q?V=E1clav_Ovs=EDk?= writes ("debian archive integrity check
tool?"):
> please, is there any utility/script, that can verify integrity of Debian
> archive? A maintainer of the ftp mirror ftp.linux.cz asks for this in
> a national mailling list about Linux systems. He needs this for n
Mike Hommey writes ("Re: can Breaks be used already? (was Re: Opinions sought:
mlocate appropriate for Priority: standard?)"):
> Maybe with the new symbols thing in dpkg-shlibdeps, the new package
> installation toolstack would not depend on the new libc... but there's
> no guarantee for that, un
Joey Hess writes ("Re: Opinions sought: mlocate appropriate for Priority:
standard?"):
> Given the security history of slocate, and since mlocate has a similar
> design from a security POV, it would be good to get a thurough audit of
> mlocate, perhaps trying some of the same holes. At least it do
Kris Deugau writes ("Re: Syslog file paths in 'metalog'? (#423299)"):
> Literally and exactly that - I want to be able to tell it to put
> daemon.* in /var/daemonlogs/mainlog, mail.info in
> /var/mailbits/mail.info, mail.debug in /tmp/debuglogs/maildebug.log, and
> just to be perverse (and more
"Leo \"costela\" Antunes" writes ("Re: Please don't list available translations
in the package description"):
> While I agree it's an issue (albeit a small one), I think we shouldn't
> file bugs for it while there's no better place to put this information.
> It may reduce the objectiveness of some
Russ Allbery writes ("Re: Priority dependence"):
> * Essential-only, usually only desirable in cases like build chroots.
> Doesn't use priority at all, but should just start from the essential
> packages and compute a dependency closure. This seems to be what the
> intention of Priority: req
Bernhard R. Link writes ("Re: Priority dependence"):
> Calculating a dependency closure is neither an easy nor an task with
> a well-defined outcome. Starting with more data makes that both more
> easy and more likely to come to deterministic results (with a good
> enough starting set, most depende
Russ Allbery writes ("Re: dkms needs a pre-depends entry (Policy 3.5)"):
> Bernd Zeimetz writes:
> > Lets remove all triggers from dpkg then.
>
> For things that have to run to make the package usable, yes.
No.
> I prefer packages to work after they've been configured. Otherwise,
> Depends doe
Steve Langasek writes ("Re: dkms needs a pre-depends entry (Policy 3.5)"):
> As Ian has described it, yes: lsb-release is not "installed" until after
> the python-support trigger is run, so dpkg will run that trigger before
> trying to move up the stack and configure dkms. And since dkms is not y
Russ Allbery writes ("Re: dkms needs a pre-depends entry (Policy 3.5)"):
> This implies to me that the following information in the python-support
> documentation is partially incorrect:
Yes, I think so.
> I believe the only case where you would need to explicitly run
> update-python-modules -p i
Russ Allbery writes ("Re: dkms needs a pre-depends entry (Policy 3.5)"):
> Bernd Zeimetz writes:
> > It should as you can't assume that your dependencies are configured when
> > your own package is being configured (Debian Policy 3.5).
>
> That's not correct. You can assume that your dependencie
Christian PERRIER writes ("Re: The number of popcon.debian.org-submissions is
falling"):
> That number is decreasing. Is that *really* a surprise for anyone?
> These days, in 2010, who is really seriously thinking that, apart from
> a few hardcore geeks, someone who is considering to install a
> L
Paul Wise writes ("Re: How to make Debian more attractive for users, was: Re:
The number of popcon.debian.org-submissions is falling"):
> binNMU style backports where a maintainer requests an auto-backport
> and the backports team schedules it? That would be nice.
That would be fantastic and dea
Stefano Zacchiroli writes ("teaching users how to submit good bug reports"):
>So, point 2: are we *advertising* reportbug enough to our users?
>In particular, I'm thinking about advertising in "push mode" rather
>then in "pull mode".
This approach, trying to make it easier to report bu
Russ Allbery writes ("Moving diversions between packages"):
> 4. Do something else to move the diversions that I haven't thought of and
>that would wonderfully solve all of our problems.
Why not have the new package ship libGL.so.1 to a more specific
filename and create a symlink named libGL.s
Bastien ROUCARIES writes ("Re: How to make Debian more attractive for users,
was: Re: The number of popcon.debian.org-submissions is falling"):
> For isntance the bug sytem could be made simplier for joe
> simpler user, using an http interface than reportbug-ng [...]
I think what's really unde
Bastien ROUCARIES writes ("Re: How to make Debian more attractive for users,
was: Re: The number of popcon.debian.org-submissions is falling"):
> The problem is joe simple user find one package that does not work,
> it seatrch on the web how to report bug, does not find, does not
> report it, and
Goswin von Brederlow writes ("Re: [pkg-nvidia-devel] Moving diversions between
packages"):
> Russ Allbery writes:
> > Ian Jackson writes:
> > > Why not have the new package ship libGL.so.1 to a more specific filename
> > > and create a symlink named libGL
Brian May writes ("Re: How to make Debian more attractive for users, was: Re:
The number of popcon.debian.org-submissions is falling"):
> I would really like to see a HTML/HTTP browser based interface for the
> BTS. I would have several advantages:
I would strongly resist any such suggestion, fo
Fernando Lemos writes ("Re: How to make Debian more attractive for users, was:
Re: The number of popcon.debian.org-submissions is falling"):
> This is free software. If you want to get your idea implemented,
> either file a bug report and patiently wait (and leave debian-devel
> alone) or impleme
Yves-Alexis Perez writes ("Re: How to make Debian more attractive for users,
was: Re: The number of popcon.debian.org-submissions is falling"):
> On 27/07/2010 12:59, Ian Jackson wrote:
> > In context this could be read as an invitation to write the code to
> > allo
Hendrik Sattler writes ("Re: Problem with gfortran and pkg-config"):
> Am Donnerstag 29 Juli 2010, 19:23:40 schrieb Tollef Fog Heen:
> > The reason for stripping -I is so you can
> > have in-tree include files that get included correctly even if their
> > names overlap the files in /usr/include.
>
Petter Reinholdtsen writes ("More advanced home directory creation in Debian?"):
> It would be nice if all the tools copying /etc/skel/ also had a common
> location for their "post-creating" scripts, making sure users created
> by for example adduser, lwat, libpam-mkhomedir and libpam-mklocaluser
>
Russ Allbery writes ("Notes from the DebConf Source Format BoF"):
> * Part of Joey's motivation is that if you look at GitHub, the
> people using it a lot consider Git to be a source package format,
I've been doing that for some non-Debian work. It turns out to be
incredibly convenient, if you'
Giacomo A. Catenazzi writes ("Re: Notes from the DebConf Source Format BoF"):
> I think there are three usual use of the sources:
> - developers/bug trackers/...
> - users: to check and to learn the sources
> - admins: who need to recompile/backport/.. sources
>
> Using git for the last two groups
Tanguy Ortolo writes ("Non-recompilable binaries in source and binary packages
(Adobe Flash strikes again)"):
> Let us say an upstream tarball contains such a non-recompilable binary
> as a minor component that can be stripped and maybe distributed by other
> means. The debian/rules will not compi
Andreas Tille writes ("Re: RFC: Policy 10.1 and appropriateness of package
conflicts"):
> On Fri, Aug 13, 2010 at 09:20:17AM -0400, Michael Hanke wrote:
> > However, the situation of #592242 is different. The package (fsl) that
> > conflicts with other packages (e.g. cyrus-clients-2.2) only instal
Marc Haber writes ("Re: More advanced home directory creation in Debian?"):
> On Tue, 10 Aug 2010 22:36:58 +0200, Petter Reinholdtsen
> wrote:
> >[Ian Jackson]
> >> So while it doesn't use run-parts, it's halfway there already. I
> >> use addu
Michael Hanke writes ("Re: RFC: Policy 10.1 and appropriateness of package
conflicts"):
> Well, it has been 'invented' to address a frequent user-problem that
> people can readily use the GUI parts of that package (because they are
> avialable via wrappers in /usr/bin and visible in the desktop me
Wouter Verhelst writes ("Re: RFC: Policy 10.1 and appropriateness of package
conflicts"):
> wou...@celtic:~$ ls -l /usr/bin/gcc
> lrwxrwxrwx 1 root root 7 jun 6 07:23 /usr/bin/gcc -> gcc-4.4
> wou...@celtic:~$ dpkg -S /usr/bin/gcc
> gcc: /usr/bin/gcc
> wou...@celtic:~$ dpkg -S /usr/bin/gcc-4.1
>
Bernd Zeimetz writes ("Re: Raw Idea: one more control field for sponsors"):
> On 08/13/2010 06:22 PM, Goswin von Brederlow wrote:
> > How? The changes file might not contain the sponsor not the control
> > file. You can get the keyid of the sponsor from the changes file. But
> > would people be hap
Ben Hutchings writes ("Re: More advanced home directory creation in Debian?"):
> On Fri, Aug 13, 2010 at 03:41:45PM +0100, Ian Jackson wrote:
> > One problem is that run-parts does not currently support passing
> > arguments to its scripts:
>
> It does; use the -
Adam Borowski writes ("Re: Notes from the DebConf Source Format BoF"):
> On Fri, Aug 13, 2010 at 11:54:07PM +0100, Ben Hutchings wrote:
> > git://foo.bar.org/meow#debian
>
> At least, neither git clone, merge nor fetch understand that syntax.
They could and should, however, be updated to do so
Russ Allbery writes ("Re: Notes from the DebConf Source Format BoF"):
> That's not the problem being discussed here. The signature is fine. The
> problem is that while Joey may think that his repository is completely
> DFSG-free, it's the current job of ftp-master to actually check that. For
> a
I just had to tell NoScript "forbid debian.org" because I wanted to
read a bug report.
I don't want to be a spoilsport but, honestly!
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: ht
Russ Allbery writes ("Re: Non-recompilable binaries in source and binary
packages (Adobe Flash strikes again)"):
> Ian Jackson writes:
> > If you have this situation you have to have two separate source
> > packages; one in main which builds only the free parts, and
Dominic Hargreaves writes ("Re: OMG WTF BBQ balloons"):
> On Mon, Aug 16, 2010 at 12:00:09PM +0100, Ian Jackson wrote:
> > I just had to tell NoScript "forbid debian.org" because I wanted to
> > read a bug report.
> >
> > I don't want to be a
Russ Allbery writes ("Re: Non-recompilable binaries in source and binary
packages (Adobe Flash strikes again)"):
>Ian Jackson writes:
>>Well, some maintainers have been rebuilding source packages to remove
>>things like RFCs and non-free-GFDL documentation. Perhaps not
I think the key thing to remember here is that both writing fast code,
and its subsequent deployment and performance tuning, are very hard
problems which are fields of research in their own right. Our job in
Debian is not primarily to try to outdo others' work by producing
programs which are bette
Russ Allbery writes ("Re: Atlas proposal"):
> I recommend instead doing the same thing that all the out-of-tree kernel
> modules that build with module-assistant do: ship the source as a .tar.bz2
> file, unpack it during the build, and then make clean after a successful
> build.
>
> Please don't s
Goswin von Brederlow writes ("Re: Bug#592839: dpkg-source option to remove
files on unpack: debian/source/remove-files"):
> No. The files must be legal to be included. They are distributed in the
> tarball after all. So deleting or not deleting makes absolutely no
> difference to ftp-master. This
Josselin Mouette writes ("Re: Atlas proposal"):
> Le jeudi 19 août 2010 à 22:53 +0200, Sylvestre Ledru a écrit :
> > * it will start the build (fakeroot debian/rules custom)
> > * at the end, it installs the .deb packages and removes the
> > libatlas3gf-auto
>
> I think it?s a bit too much to ask
Goswin von Brederlow writes ("Re: Bug#592839: dpkg-source option to remove
files on unpack: debian/source/remove-files"):
> That was my point. Legally we CAN use those files. But we don't WANT to
> use them for DFSG reasons.
I think we are in vigorous agreement, but your tone makes me hesitate.
L
Goswin von Brederlow writes ("Re: Atlas proposal"):
> I also have a package "local-archive" that depends on reprepro,
> generates a local signing key on first install, adds that to the apt-get
> keyring and adds a file:/// url in /etc/apt/sources.list.d/.
I think this scheme is a very bad idea. I
Russ Allbery writes ("Re: For those who care about their packages in Debian"):
> Ben Hutchings writes:
>
> > Please stop filing ITPs and concentrate on packages that should be
> > included in squeeze. The sooner squeeze is out, the sooner you can add
> > stuff to the next release.
>
> This come
Mike Hommey writes ("Re: For those who care about their packages in Debian"):
> On Wed, Aug 25, 2010 at 01:42:34PM +0100, Ian Jackson wrote:
> > Even better would be an option to write something in your .dsc which
> > would cause automatic transfer of your package into uns
Goswin von Brederlow writes ("Re: Atlas proposal [and 1 more messages]"):
> Just dumping the compiled files into /usr/lib/ I find quite unacceptable
> too.
No, it is absolutely fine and it is what atlas-auto should do. It is
a simple matter for its postinst and postrm to deal with these files
exp
sean finney writes ("Re: Atlas proposal [and 1 more messages]"):
> as an admin i'd be very annoyed by that behavior, because there's no way
> for me to know what package the file came from then, or whether it was my
> own accidental actions that led to it (i.e. a make install gone wrong
> somewhere
801 - 900 of 2524 matches
Mail list logo
