t; magnitude in Debian that was managed on this professional level. I
> especially praise the way you have communicated the progress.
100% agreed. The care and excellence that you've brought to this work has
been exceptional.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
it to do something like set the soft limit to the
hard limit (that sounds like a very INN sort of thing to do), but if so, I
couldn't find it in a quick search.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
for supporting architectures, including
the kernel, GCC, binutils, etc. If that ecosystem stops supporting
architectures, it will be very difficult for Debian to keep support, and
doing so usually requires the people interested in keeping those
architectures working to also become upstream kernel
job to update the source subvolume
daily to ensure that it's fully patched.
Unfortunately, there's no way that we can rely on this, but it would be
nice to continue to support it for those who are using a supported
underlying file system already.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
n access the base via the
> source: names.) I never liked the type=file stuff, as it's slow to
> setup and maintain.
Ah, thank you, I didn't realize that existed. That sounds like a nice
generalization of the file system snapshot approach.
--
Russ Allbery (r...@deb
ll that my contribution to this thread accomplished was to
demonstrate that I set up sbuild years ago based on a wiki article for
btrfs and don't know what I'm talking about. :) Apologies for that.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ion numbers that are much
smaller. In other words, to quote policy, "situations where the upstream
version numbering scheme changes." Yes, in this case it was only in their
packages and not in their software releases, but that still counts when
they have an existing user base that has those packages installed.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
uot; specifically:
https://docs.python.org/3/library/fractions.html
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ately exit with no changes to the commit message, and to do that we
probably need to write down what those expectations are. I think the
Policy language was written in a time where we just assumed there was an
obvious way for editors to behave that didn't include things like
backgrounding the
ed debian/unstable
and debian/experimental.
Personally, I use debian/unstable but do experimental development in that
same branch if it's "targeting unstable," which is either the best or
worst of both worlds, depending on your perspective.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
much to say about this unless we need
some mechanism for labeling such packages other than a MR to Lintian. The
important information is the list of packages that shouldn't be used this
way, and the hard part is probably gathering that list.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
d
rather continue down the path of providing Debian tools and processes that
reduce the delta between how Debian packaging uses Git and how most free
software development uses Git.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Otto Kekäläinen writes:
> On Tue, 2 Apr 2024 at 17:19, Jeremy Stanley wrote:
>> On 2024-04-02 16:44:54 -0700 (-0700), Russ Allbery wrote:
>> [...]
>>> I think a shallow clone of depth 1 is sufficient, although that's not
>>> sufficient to get the correc
I think that tying core Debian packages to the Red Hat boat anchor is a
horrible, horrible idea.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
same thing, don't have this problem, and make it just as easy for
users to enable the package.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
ertainly, that's my problem for not being attentive enough, but it's
worth making it easier on the poor sap in a hurry. That effect is even
worse when the phrasing is more drawn-out, like "If X, you should not say
Y."
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
r-productive, since it implies
some ongoing relationship to the original upstream release that isn't
accurate.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
t release of OpenLDAP.
That's a bit more than FUD, although I agree that it's not specifics.
I agree that it's unclear at the moment whether the problem is unique to
OpenLDAP or whether other applications would encounter the same problem.
--
Russ Allbery ([EMAIL PROTECTED])
port in the KDC, but I may have been doing something wrong...)
README.servers in the openafs-fileserver package explains how to set up
OpenAFS with Kerberos v5 authentication via krb524d, and at least with the
packages in sid it's been fairly well-tested. The setup scripts needed a
bit of work that
Brian May <[EMAIL PROTECTED]> writes:
>>>>>> "Russ" == Russ Allbery <[EMAIL PROTECTED]> writes:
> Russ> You're correct, although it's very close. It will be
> Russ> possible with the 1.4.1 release (and is almost possible
>
harder for other utilities
like lintian to analyze the package properly.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Nicolas Boullis <[EMAIL PROTECTED]> writes:
> On Sun, Nov 20, 2005 at 12:39:24PM -0800, Russ Allbery wrote:
>> Well, one practical concern is that it makes it harder for other
>> utilities like lintian to analyze the package properly.
> Well, that's an argument I don
se the same approach that my similar svnlog program for
Subversion uses.)
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
rwise evaluate, whether the existing infrastructure component is
similarly available or not. I'd think this would just be common sense.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Goswin von Brederlow <[EMAIL PROTECTED]> writes:
> Russ Allbery <[EMAIL PROTECTED]> writes:
>> C'mon, this is a free software project. The obvious first step for
>> providing better infrastructure would be to make that infrastructure
>> publically avail
f RC bugs
right now, partly due to the documentation licensing issues, whereas the
list of orphaned packages is much smaller and easier to look over.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
I read that page religiously for my packages and
will investigate and attempt to fix any problem that shows up there.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
to get to my mail too. But
Maybe the right thing to do would be to work out a way for package
maintainers to provide input to their own P-a-s entries in some sort of
automated fashion? It does seem like a package maintainer is generally
going to know this sort of thing, and I hate to bother
e into a form someone else could run,"
but who knows), if you want to make an argument that your stuff is better,
you have to actually release it as free software as far as I'm concerned.
It's the minimal bar to meet, and it's not even interesting to have a
co
;t thinking to base it on the control
file so much as letting the maintainer send a PGP-signed message somewhere
to change it, but either way, that's a concern.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ice to eventually get some
resolution on this, but it's a known thorny licensing issue and isn't the
easiest thing to work through.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "
incomplete job, which I think everyone, including the ftp-masters, would
agree with.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Goswin von Brederlow <[EMAIL PROTECTED]> writes:
> Russ Allbery <[EMAIL PROTECTED]> writes:
>> Funny, I just did a Google search for
>> site:www.debian.org cvs repository www.debian.org
>> and there it was, plain as day.
> That implies that you alread
but this is making that impossible.
Thanks in advance!
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
pository. But it doesn't work with svn.debian.org.
> Assuming nothing is wrong, you may need to wait up to 24 hours for that
> to take effect.
Hm, I *thought* it had been several weeks already, actually. But maybe
I'm confused and I just got added and I'm misremembering think
eady just pretend that this is the case. If your package has
gone for more than two weeks, it seems to me like you could decide to
treat it in all respects as if it had been rejected and just go on with
your life. If it ends up getting accepted, you could orphan it, or decide
to pick it up again.
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:
> Russ Allbery <[EMAIL PROTECTED]> writes:
>> Anand Kumria <[EMAIL PROTECTED]> writes:
>>> A simple assurance that your package will be rejected from the NEW queue
>>> if no ftp-master approves it within
iginal vi than vim offers. I won't lose lots of sleep if I lose
this argument. :)
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
nt for a while in
upstream). It was changed to -j because that's what upstream did. The -j
flag is present upstream as of 1.13.18.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
back on /run? That way, /run could
be created during the boot process, then moved to /var/run and removed
again once /var is available, making it a transient aspect of the boot
process and not hanging around as a new top-level directory.
--
Russ Allbery ([EMAIL PROTECTED]) <
ssary to
> ensure /var is mounted early -- keeps the filesystem sane, and it's just
> a simple matter of programming, rather than arguing over what's ugly.
Yeah, I agree with this too.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
on fixing
some problems with the package.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ftware via e-mail, fine, send me a
copy of it, I'll put it up on my public web site, and then it will be
free. And then one could have a more meaningful conversation about where
it should fit into buildd.debian.org.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyr
teering to work with the maintainer to try to get the bug count down.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
nal
preference, not arguing that other people's preferences are wrong.)
On the other hand, I don't consider it a major issue and can live with
whatever decision people come to, which is why I voted both alternatives
above further discussion in the straw poll experiment. :)
--
Russ
Petter Reinholdtsen <[EMAIL PROTECTED]> writes:
> [Russ Allbery]
>> Also, I think this is a little silly for small packages. My experience
>> with this sort of volunteer work in other areas is that if one person
>> does nearly all the work on a regular basis, you
the BTS when a package has hundreds of bugs, and certainly I doubt new
bug reporters are really reviewing all of the existing bugs if there are
more than a hundred of them. (debbugs's strong point is handling a small
number of bugs on *lots* of different packages; I find it somewhat
difficu
Erinn Clark <[EMAIL PROTECTED]> writes:
> * Russ Allbery <[EMAIL PROTECTED]> [2005:12:22 09:14 -0800]:
>> (debbugs's strong point is handling a small number of bugs on *lots* of
>> different packages; I find it somewhat difficult to follow when dealing
>> wi
MIT, but if you
prefer Heimdal, I won't stand in your way. :)
> The first can be worked around, but the second is probably very
> important to anyone running AFS and kerberos.
Not really.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
Package: wnpp
Severity: wishlist
Owner: Russ Allbery <[EMAIL PROTECTED]>
* Package name: svn2cl
Version : 0.4
Upstream Author : Arthur de Jong <[EMAIL PROTECTED]>
* URL : http://ch.tudelft.nl/~arthur/svn2cl/
* License : BSD (3-clause)
intainer is a Debian developer, so I'm going to point
him at my package and probably won't end up maintaining it myself.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ontent with GSSAPI
authentication and ticket forwarding, so I've not looked in detail), it's
something else that I'm not aware of.
> Thanks for a very informative answer. I'd really like to get to the
> bottom of this, but that remains to be seen...
Me too. It really should all just work.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
Daniel Kobras <[EMAIL PROTECTED]> writes:
> Corrin Lakeland <[EMAIL PROTECTED]>
>gnubg
I've adopted gnubg with Corrin's permission and this is now fixed in the
version just uploaded yesterday.
--
Russ Allbery ([EMAIL PROTECTED]) <http://
e is
spent waiting in various queues for someone to have free time.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
upload since feb 2004.
Already requested with ftp.debian.org, see Bug#344597.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
a for services provided by this system, which seems to fit the
> bill.
I vote for this. At Stanford, we're slowly trying to migrate local data
for services running on the machine into /srv. It's the Right Thing from
the FHS perspective so far as I can tell.
--
Russ Allbery
bian.
If you want to call that a joke, feel free. *shrug*. I actually believe
in free software.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
nerator, until such time as it's free. Since otherwise, I'd be missing
the whole point.
I want to build up the information commons, not work on doing something
great just for the sake of doing something great. Unless the work enters
the general commons, all the code and effort is
Andrew Suffield <[EMAIL PROTECTED]> writes:
> On Sun, Jan 08, 2006 at 10:30:07PM -0800, Russ Allbery wrote:
>> They're investing in writing better tools, and they're keeping them
>> private so as to maintain a competative advantage with them over Red
>> Hat, S
simply wrong and
should be removed so far as I can tell.
You may want to ask upstream why they did that, but I'd patch Configure to
remove -nostdlib in the maketop function that writes out the Makefile.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
is committed to free software from the ground up.
And certainly, I would oppose blessing any closed-source toolset as part
of Debian's infrastructure, regardless of its origins. Which is where I
entered this particular thread.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ting paid.
Finding good ways of taking advantage of the work of people who are paid
to work on free software is very important for any free software project,
including Debian.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ned out to be the problem that started all
the attempts at rebuilding things (in case anyone else happens upon this
thread). The versions of everything in sarge aren't set up to support
256-bit AES as the only supported enctype, but this will probably work in
etch.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
Florian Weimer <[EMAIL PROTECTED]> writes:
> * Russ Allbery:
>> Debian isn't perfect at this. There are portions of the Debian
>> infrastructure where the exact version that Debian is running are not
>> necessarily available. However, these are generally consid
ackages like Firefox or
OpenOffice may have different needs than the majority of packages in
Debian.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
f work for the Debian Perl group
that I could do as soon as I find some free time.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ince last upload, etc.), almost
of the packages in the worst shape have a regular maintainer.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
is a good reminder of that. :) However, the more that you deploy and
depend on closed-source tools, the less interesting Ubuntu is to me
personally. (It's quite likely that you don't care, and that's fine. I
don't really expect you to.)
--
Russ Allbery ([EMAIL PROTECTED])
Thomas Viehmann <[EMAIL PROTECTED]> writes:
> Russ Allbery wrote:
>> The thing is... most of the orphaned packages are in fairly good shape.
> How do you know?
Well, because at one point I went through the PTS for each one of them,
checked for filed bugs, checked lintia
stop telling us that the only reason why we're
not working harder for Ubuntu is because we're jealous, *listen* to what
we're actually saying, and help synchronize the hard cases.
All this nattering on mailing lists doesn't make the software any better.
--
Russ Allbery ([
n against
> those whose sexual orientation may be different from your own.
Er, I thought it was offensive because it was sexist, not because there's
anything wrong with being lesbian.
Regardless, I think this was pretty much the poster child for "two wrongs
don't make a ri
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> On Sat, 14 Jan 2006 11:19:37 -0800, Russ Allbery <[EMAIL PROTECTED]> said:
>> Er, I thought it was offensive because it was sexist, not because
>> there's anything wrong with being lesbian.
> Umm, the fac
y review it for changes that should be
incorporated in Debian, and nothing makes that impossible faster than
changes like autotools modifications.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject
like getopt().
The problems generally only arise with functions that return pointers.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ctually causing problems.
If you identify a case where it causes or is likely to cause problems,
surely that's a regular bug report that maintainers should then deal with
according to its severity.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
, given that there are .config scripts written in Perl in
Debian. In krb5-config, for instance, there is a bit of Perl code that
parses the default realm out of an existing /etc/krb5.conf file. It's
possible to rewrite that code in sed (I've done it), but it's not quite as
thorough
oo
been modified to use a more conventional installation structure? (Or is
imake going away completely?)
I'd love it if imake itself just used a better directory layout, since
it's going to be a *long* time before everything that currently uses imake
switches to some other build system (e
hink this is going to make the fewest packages
buggy while still accomplishing the goal.
> - "Turn the SHOULD into a MUST in policy and have dpkg-buildpackage
> check the Standards-Version"
Checking the standards version for this sort of thing seems rather evil to
me, but maybe
xbattbar
xcal
xcalendar-i18n
xcb
xclip
xclips
xdkcal
xdm
xdmx
xdu
xengine
xfaces
xfishtank
xfm
xfs
xfwp
xgdipc
xinput
xipmsg
xlbiff
xli
xlockmore
xlockmore-gl
xmeter
xmix
xmon
xnest
xpostit
xrn
xserver-common
xserver-xorg
xsysinfo
xtel
xtoolwait
xtrlock
xutils
xvfb
xview-clients
xviewg
xviewg-dev
x
e can deal with.
I've done that sort of X configuration hacking to make imake install
things in appropriate locations and use the right compilers in the past.
It's not fun work; it's painful, tedious, and exceedingly boring, and I
wouldn't recommend it if you can avoid it.
the above copyright notice
> and this paragraph are preserved on all copies. This software is
> provided "as is" with no express or implied warranty.
That license doesn't appear to grant the right to distribute modified
works.
--
Russ Allbery ([EMAIL PROTECTED])
James Vega <[EMAIL PROTECTED]> writes:
> On Fri, Jan 27, 2006 at 07:52:35PM -0800, Russ Allbery wrote:
>> James Vega <[EMAIL PROTECTED]> writes:
>>
>> > Copyright Notice:
>> > -
>> > Copyright (C) 1992-1996 Gnanasekaran
lysis reverses and one
instead starts looking at the cost of removing it. The inherent merits of
the language rarely end up being a decisive factor.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subjec
mething and make it so much better. Few
rewrites that are started actually finish. The few that are often
introduce lots of new bugs in exchange for the old, known, worked-around
bugs.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCR
d source packages. Debian is a binary distribution.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
t makes less sense than it sounds to
include the section two man pages with Linux rather than separately in the
manpages-dev package; the userspace API is often not exactly the system
call exposed by the kernel, since libc mediates the system call and often
does some rejiggering of data types in
t. It saves on moving things around later, I can't see how it
breaks anything in the DFSG, and it means one less controversial grey area
decision that we have to make all the time.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIB
rules that are hard to verify.
In other words, it seems like a lot of work, and it's not clear what
problem it would really solve.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Certainly it's possible, and I expect the lintian maintainers would
welcome patches, but I don't think it's that straightforward.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
does not
> make their use mandatory.
Hm, I've only been doing this in packages that use AC_CANONICAL_HOST. Is
there benefit to doing this even with packages that don't care at all
about the system type and don't even include config.guess and config.sub
in the source package?
--
lose if
the package has a script that the user runs called configure but the
script isn't an Autoconf script, but I'm not sure if that happens for any
of our packages.)
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to
Pjotr Kourzanov <[EMAIL PROTECTED]> writes:
> Russ Allbery wrote:
>> Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:
>>> Please just add the recommended --host and --build makefile snippet
>>> and feed that to configure in *all* packages. It is b
's a long archived discussion on the Autoconf mailing list about it.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Miles Bader <[EMAIL PROTECTED]> writes:
> Russ Allbery <[EMAIL PROTECTED]> writes:
>> `--host=HOST-TYPE'
>> the type of system on which the package will run. By default it
>> is the same as the build machine. Specifying it enables the
>>
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:
> Russ Allbery <[EMAIL PROTECTED]> writes:
>> That's the old way. Autoconf changed this in the current releases.
>> Now, specifying --host signals that you're cross-compiling, whether it
>> disagre
nd it would surprise me if cross-compiling such things was
really on anyone's radar or will be. (Apologies if Mozilla has put a ton
of work into that already -- I'm fairly sure that the example could be
replaced by dozens of other large packages if need be.)
--
Russ Allbery ([EMAIL PRO
ated to them.
You have to do a new upload with the maintainer set to the QA group. I
had no idea that those were orphaned. See:
<http://www.debian.org/doc/manuals/developers-reference/ch-pkgs.en.html#s-orphaning>
although it could perhaps be slightly more explicit.
--
Russ A
ore than that. In addition, they also verify licensing issues. I
consider that check to be an integral part of the Debian QA process and
wouldn't want to do without it.
US export legislation is the reason why we don't make things in NEW
publically available until after
Package: wnpp
Severity: wishlist
Owner: Russ Allbery <[EMAIL PROTECTED]>
* Package name: libafs-perl
Version : 2.2.3
Upstream Author : Norbert Gruener <[EMAIL PROTECTED]>
* URL : http://www.mpa-garching.mpg.de/kwiki/nog/afsperl/
* License : GPL
Package: wnpp
Severity: wishlist
Owner: Russ Allbery <[EMAIL PROTECTED]>
* Package name: webauth
Version : 3.2.4
Upstream Author : WebAuth Team <[EMAIL PROTECTED]>
* URL : http://webauthv3.stanford.edu/
* License : MIT/X
Description : cook
1 - 100 of 3448 matches
Mail list logo
