We seem to be moving to a de facto standard of UTF-8 for non-ASCII
characters in debian/control files. This is not specified in Policy
[1], but for hopefully obvious reasons, consistency is a Good Thing,
and UTF-8 seems to be the best solution for this sort of thing.
In my sid control files, I s
[Peter Samuelson]
> I suggest that the affected source packages[3] be run through the
> command 'iconv -f ORIGINAL_CHARSET -t utf-8' as soon as convenient.
Ehhh, I see I have already ruined my credibility by pasting the wrong
source package list. The real list is much shorter.
[Steinar H. Gunderson]
> Transliterating is somewhat of a kludge (and I think in most cases
> UTF-8 is a much better solution); OTOH I'd rapidly get confused in
> the list of Japanese maintainers if their names weren't
> transliterated.
I think it's a valid choice for a maintainer who natively sp
[Marco d'Itri]
> > Would people support a mass bug at minor severity?
> Make it normal.
Given that Policy recommends debian/changelog to be utf-8, coupled with
the observation (which I had not thought of) that various tools may
require a maintainer's name in debian/control and debian/changelog to
[Thaddeus H. Black]
> Would Peter permit me a mild dissent? I prefer Latin-1.
Dissents are fine. (:
The reason to go with UTF-8 is for consistency. Tools that wish to
render text onto the screen ought to be able to depend on knowing the
encoding that text is in. See below for why I (and many
[Matthew Garrett]
> Defining the character set as utf-8 means that any non-unicode
> capable application is going to have issues, yes.
Postulate an app that is ignorant of character sets - we'll call it
"aptitude". Fixing it to make it accept utf-8 and spit out the correct
encoding for its LC_CT
[Roger Leigh]
> I've been using Debian with UTF-8 only locales for over 12 months
> now. I now consider it fine for general use, with respect to
> terminal and application support. Unlike a couple of years ago, most
> things work perfectly.
Some apps like 'screen' do not just configure themselv
[William Ballard]
> I like my transactions to have ACID consistency and dpkg does not
> have this by design - apt does.
"You keep using that word. I do no think it means what you think it
means." Let's see how ACID-compliant apt install runs are
Atomicity - no. Your install does not, fo
[Miguel Gea Milvaques]
> I don't undestand why software loading files (as we are talking) must
> be in contrib. An example: xpdf, if you have not a pdf file you could
> not use it, only it gave us a blank page. You could read a lot of
> different files, a free pdf files or a non-free pdf files, an
> >even in cases where it *is* documented, this is not by any
> >stretch of the imagination a typical use case.
[Peter 'p2' De Schrijver]
> That's not true. Firmware can created by anyone and requires only
> documentation and a compiler/linker for the target processor. In many
> cases the
[Tollef Fog Heen]
> Assume makes an ass of u an' me.
Why do people keep circulating this saying? It makes no sense.
Normally, assuming only ever has the power to make an ass of the person
who did the assuming, i.e. "me", not "u and me". And even then, it's
not like you could get very far in lif
[Steve Langasek]
> The four most common porting problems for software are endianness
> (differs between i386/amd64 and powerpc), word size (differs between
> i386/powerpc and amd64), char signedness (differs between i386/amd64
> and powerpc), and use of non-PIC code in shared libs (which is a
> pr
[Henrique de Moraes Holschuh]
> Not from what I know of dist-cc. You just need dist-cc, and nothing
> else. dist-cc just offloads the number-crunching, so it uses no data
> from the non-master node. AFAIK anyway (which is NOT much on dist-cc
> matters).
Right. distcc runs the C preprocessor o
[Pierre Habouzit]
> I mean that you have no way to say for huge source packages : you
> only need to build this , this, this and this pacakge. since the
> changes I've made won't affect the others.
As far as mirror bandwidth goes (including end user bandwidth *from*
the mirrors), that's a problem
[Pierre Habouzit]
> > As far as mirror bandwidth goes (including end user bandwidth *from*
> > the mirrors), that's a problem for rsync/zsync to solve.
>
> 1- binary backages do not have the same name (so rsync/apt-get are lost)
It's still a problem for rsync/zsync to solve. I didn't mean to sa
[Goswin von Brederlow]
> Which also avoids that packages will be unavailable on every new
> architecture debian introduces because the maintainer has to adjust
> the Architecture: line.
I suppose it'd be nice to be able to use !foo in the Architecture: line
for cases where something is known not
[Nikita V. Youshchenko]
> Maybe it's better just not to provide oss drivers for chips supported
> by alsa? AFAIK OSS will be removed from kernel soon...
It may or may not be removed soon - I note that it isn't listed in
Documentation/feature-removal-schedule.txt in kernel 2.6.11 yet.
Anyway, two
[Blunt Jackson]
> I am familiar with the nss issue, although that's not really relevant
> to this question. The nss issue, and the related question in the FAQ
> is that when statically linking to libc, there are still dynamic
> loads required -- but libc handles this for the application.
> (Presum
[Jason Lunz]
> I just figured out a way to do this for the ssh binary. Maybe this would
> work for you?
As others have pointed out, there is -Wl,-Bstatic and -Wl,-Bdynamic -
but even absent those, you can just refer to the .a files directly if
you wish. So instead of -Lopenbsd-compat/ -lopenbsd-
[Christopher Crammond]
> Suppose you have a repository stuffed full of binary packages, in
> this case Debian Packages. If you were unlucky enough to have them
> in a rather un-organized fashion, I was just wondering if the package
> file itself would provide said information to allow me to write
[Alexander Schmehl]
> Curently it's quite easy to run unstables lintian, debootstrap and
> pbuilder on system running stable for the other packages. So I don't
> see a big problem creating and testing packages on a stable system.
It would make more sense to me to run lintian *inside* pbuilder, t
[Steve Langasek]
> python-dev provides an interface that packages can build-depend on
> which gives them both /usr/bin/python, and a set of development tools
> from the corresponding version of python. This is not analogous to
> petsc-dev, which only depends on the versioned -dev package.
The on
[Nathanael Nerode]
> Put it in the .diff.gz. If it's too large for that to seem
> reasonable to you, then you proabably shouldn't put it in your
> package. :-)
Heh, and how large is that? The combined effect of 'configure' and
'**/Makefile.in' can look pretty formidable, yet people exist who
c
[Anand Kumria]
> - require the developer to generate a new key
> - require the developer to have _at least_ N
> number of other, existing developers sign
> their key
> - once the devel
[Enrico Zini]
> My hope is that if more people start to use it, then package managers
> can start building features with it.
I thought that Enhances is merely the converse of Suggests, and that it
was invented for situations where it is problematic or inconvenient to
use Suggests directly, as whe
[Andreas Orfanos]
> I hope I post this to the right list.
debian-user is probably the right list, actually.
> The delay was not due to lots of new modules, it was clear that the
> incremental list of compiled components on the screen was moving up
> slow. I remember kernel builds where ultra fas
[Henrique de Moraes Holschuh]
> Hmm... wasn't the situation around this bug cleared up in another
> d-devel thread no more than two or three days ago, and a fix already
> commited to CVS?
That's what I thought. But the bug is still open. And jvw's reasoning
that it is OK for ftp.debian.org to c
[Erinn Clark]
> Yet just today you filed a bug (#340403) for documentation to be
> included in the package since you were unable to explain dpkg-sig's
> strengths. How is it possible for you to claim something is more secure
> when you don't understand it well enough to say how it's different?
Th
[Goswin von Brederlow]
> > Use 2: I have this Ubuntu CD and want to know which debs are from
> >debian and which got recompiled
> >
> > Look for all debs that have a deb signature of the debian archive
> > (to be added to dinstall at some point).
[Matthew Garrett]
> The answer is "
[Steinar H. Gunderson]
> All three might eventually be truly broken, but you can bet that MD5
> will be the first to go. If you use SHA-256 today instead of MD5, you
> probably buy yourself a few extra years, which you can use to smooth
> out the transition to the next hash function when the world
[George Danchev]
> Even using weak hash sum algorythms you can easily make the hash
> collider life tremendously difficult by simply having more than one
> (ok two should be enough) hash sums generated with _different_
> (weak?) algorythms on the same entity.
What you have just defined is a new h
[Wesley J. Landaker]
> As described by the upstream website (the rest of this is a quote):
>
> What is sendcard?
> Sendcard is a multi-database (It currently supports 9 different
> databases!) e-card or virtual postcard program written in PHP. Suitable
> for large or small sites, it is very easy
[Lior Kaplan]
> * Package name: culmus-fancy
> Description : Type1 Fancy Hebrew Fonts for X11
I understand that the 'culmus' package already exists, and other
packages like 'lmodern' don't follow any particular name convention
either, but could you consider naming this thing t1-culmus-f
[Florian Weimer]
> > It should be replaced with "-". Beyond alphanumerics, only ".",
> > "_", "-" are in the POSIX portable filename character set[1], and
> > some systems do not allow the character "+" in file names.
[Henning Makholm]
> However there are already plenty of files with "+" in th
[Anthony Towns]
> gnupg comes close to being this, except for two things: it's got too
> many dependencies, and it's command line arguments are overly
> complex. A "gpgh" variant (like gpgv but for hashing) might work,
> though. It doesn't support --check, and "gpg --print-md md5
> /etc/motd" has
First of all, let me cast my vote for -doc-XX rather than -XX-doc. It
makes much more sense from a sorted package names point of view, which,
as others have said, is important in package manager UIs.
[Norbert Preining]
> texlive-documentation-czechslovak texlive-cs-doc
Czech and Slovak are two
[Adam Heath]
> > File: foo%20bar/hellurei.txt
> > Size: 12345
> > MD5: 012345667
> > SHA-256: 0a0a0a0a0a0a0a0a0a0a0a0a
> > Mode: 0644
> Checksum:
> md5: 0123456789[B
> sha-256: 0a0a0a0a0a0a0a0a0a0a0a0a
Checksum: md5: 01230123012301230123012301230123
C
[Frank Küster]
> > Why do we need two packages containing the "latex" command, for example?
>
> Why do we need N packages that provide MTA functionality?
That's not equivalent. An equivalent question would be more like "why
do we need N packages all containing the source code for exim and
build
[Roberto C. Sanchez]
> Is there a way to not allow changelog entries to automatically close
> bugs assigned to other packages?
This has been suggested before; the standard counterargument is "what
about closing an ITP?"
signature.asc
Description: Digital signature
[Hans Hagen]
> how about a package (zip or rpm) with 'goodies'; since user are
> willing to install other non-free stuff (acrobat reader and such)
> they probably also hav eno problems with les-free goodies
It's not OK to violate someone's copyright just because users don't
mind things which are
[Russ Allbery]
> 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
Could be done, but my understa
[Daniel Burrows]
> (1) The first line begins with N > 2 spaces,
Don't you mean N >= 2?
> (2) The first non-space character of the first line is a bullet
> character, and
>
> (3) Each subsequent line begins with at least N + 1 + M spaces,
> where M is the number of spaces immed
[Daniel Burrows]
> (1) The first line begins with N >= 2 spaces,
> (3) Each subsequent line begins with at least N + 2 spaces.
Hm. That brings up the minor point of whether N should ever be
anything but (2 * nest_level).
I don't feel strongly about that one, though.
Also, in the Best P
[Peter Samuelson]
> Hm. That brings up the minor point of whether N should ever be
> anything but (2 * nest_level).
Or if you consider nest_level to be zero-based, (2 + 2 * nest_level).
It occurs to me, though, that some might prefer the raw presentation
look of (2 + 3 * nest_leve
[Thomas Hood]
> After installation you should have a tmpfs mounted on /run. This has
> been created for the use of that handful of packages that need a
> place to store run time state files independently of networking.
Given the need, and now the reality, of /run, is there any need for a
separat
[Steve Langasek]
> Given the reality of /lib, is there any need for a separate /usr/lib?
>
> The principle is the same: /lib is used only for the minimal system
> required for booting, and everything else should go in /usr/lib.
> /run should be used only for junk that needs to be stored early in
[Anthony Towns]
> I realise your heart's set on /run, but is there any possibility
> of putting it under /lib/run or /boot/early-writable-fs instead of
> introducing a new directory on / that's of very limited use?
/lib is no more appropriate than /sbin. That it is already overloaded
in the FHS
[Thomas Hood]
> Any other defenders of /lib/run? Of /run?
/etc/run. mtab and resolv.conf and the lvm1 state files and so forth
always lived in /etc before, so there's continuity.
signature.asc
Description: Digital signature
[Miquel van Smoorenburg]
> I tested this and it works fine. It's also a better solution, since
> several packages contain directories in /var/run and ofcourse they
> expect them to still exist after a reboot.
That's a bug, IMO - they should mkdir -p in their init scripts if
necessary. It's not l
[Frank Küster]
> You are right - I was under the impression that this means "people
> who will do maintainer uploads of this package", but in fact it just
> says "maintainers" in the Policy.
Right, the field is misnamed, it should be "Maintainers:" but that
might be slightly confusing, visually.
[Brian May]
> Is there anyway you can disable this implicit shell, either with ssh
> or rsh? I really don't like it. I would rather each parameter be
> passed straight to the remote executable via exec without being
> parsed by sh first.
So you want rsh/ssh to do the job of word splitting? The q
[Roger Leigh]
> In the case of someone who attaches a patch to a bug report, I think
> getting a mention in the Debian (or upstream) ChangeLog is
> sufficient.
Indeed, back in the days when reporting a bug and attaching a patch was
all I was willing to spend time doing, I thought a mention in the
[Peter Eisentraut]
> What do you think about this request? It seems reasonable, but I
> think if this should be supported, there ought to be a general policy
> (formal or informal) on it because I think many other init scripts
> will suffer from similar problems.
This issue was mentioned in the
[Steve Langasek]
> That's fine; I'm just saying that there's not much point in telling
> people to *not* ship /var/run (or subdirectories thereof) in their
> package.
Hmm, it should be noted that if you do remove /var/run/foo from your
package, you need to make sure the postrm deletes the directo
[Thomas Hood]
> Would it be useful if the initscript that clears /var/run also
> created a directory hierarchy under /var/run?
I cannot fathom how telling someone else to do a particular 'mkdir -p'
and 'chown' could possibly be simpler than putting the 'mkdir -p' and
'chown' into your init script
[Paul TBBle Hampson]
> Although as Steve Langasek has pointed out, the Sarge->Etch upgrade
> will be hard unless the etch key becomes available to Sarge users
> who've not touched their system since Sarge r0a... I guess this comes
> down to making the etch key available in some kind of Sarge-signe
[Stephan Hermann]
> Oh, I never signed an NDA, so I've never seen the code, actually I'm
> not interested in the code, because if I have a problem with the
> result, I can file bugs against this products, or bug the maintainers
> of the code in their present irc channel :)
It is clear that you do
[Martin Meredith]
> Thing is, in ubuntu - we don't neccesarily have "maintainers" for
> packages.
>
> We use a collaborative process - anyone who had access can modify the
> package. Basically - many many people can change a package, which can
> be confusing for people.
Here's the thing: the Mai
[Sami Haahtinen]
> like 'dpkg --show-primary-contact ' That way we could even
> add a separate field Preferred-Contact: (or something alike) that
> could override the maintainer and modifier.
"Preferred contact" is *exactly* what the Maintainer field means.
[Well, and the co-maintainers ("Uploade
(M-F-T set.)
[Frans Jessop]
> When somebody wants to become a DD he is told ?Go find a package to
> maintain, one that you can be the maintainer for.? I see serious
> problems with this approach as Debian increases in DD's. I will how
> this is in a second. What I think should be emphasized is
[Ken Bloom]
> $substvar{'Source-Version'}= $fi{"L Version"};
> +#Indep-Version is for supporting binary NMUs when a strict
> +#version dependancy is required against an arch independant package
> +$substvar{'Indep-Version'}= $fi{"L Version"};
> +#strip out the +bN format binar
[Adam M.]
> Instead of doing blind substitutions like it is done currently, it is
> possible to separate Arch:all from Arch:any|other|whatever in the
> substitution script such that,
>
> Source-Version => bin NMU version for binaries that are build
> Source-Version => 'original' version for Arch:
[EMAIL PROTECTED]
> There seems to be a fairly good amount of Debian Sarge packages
> available via http://klik.atekon.de/.
You know, I almost didn't bother to visit the web site, since you're
unwilling to even sign your name to your message, and you didn't say
anything about what klik is or why
[Thomas Bushnell BSG]
> Since you don't do bin-NMU's, you could simply alter the version of
> every package to add an "ubuntu" tag, and then be done with it,
> right? That would work well and be very easy to implement.
You are so hung up on this point, it's not even funny.
Do you really think u
[Jérôme Warnier]
> After the last update of OOo in Sid (aka Unstable), I wonder if it is
> generally considered acceptable to keep obsolete packages in
> experimental (currently, Sid has 2.0.1-2 and Experimental 2.0.1-1).
Hmmm, I thought experimental was garbage-collected automatically in
this ca
[Jérôme Warnier]
> Or even better: a list of all packages already installed on my system
> which have an experimental version?
There might be a better way, but assuming you have experimental in your
sources.list...
t=$(tempfile);
awk > $t '/^Package:/{print "^" $2 "$"}' \
/var/lib/apt/li
[David Nusinow]
> As far as I understand it, this is simply grandfathered in. I'm not
> that up on the FHS details though, so I may be wrong. Remember also
> that this isn't X11R6 any more, but X11R7.
Branden toyed with the idea of setting ProjectRoot to /usr when
packaging XFree86 4.0. I was so
[Josselin Mouette]
> Because python and ruby have similar features
Same with perl and python.
> and the former is more widely spread and used.
Same with perl and python.
Actually these days perl and python are fairly evenly split, but even
so, there's no need for both. Of 63 config scripts on
[Manoj Srivastava]
> On Sun, 29 Jan 2006 04:35:08 +0100, Josselin Mouette <[EMAIL PROTECTED]>
> said:
> > Deliberate use of words a non-native English speaker cannot
> > understand won't help your argumentation.
>
> I beg your pardon. I was expecting a modicum of competence, obviously
> my trus
[Andreas Hoenen]
> * Package name: dblatex
> DocBook to LaTeX Publishing that transforms your SGML/XML DocBook
> documents to DVI, PostScript or PDF by translating them in pure LaTeX
> as a first process. MathML 2.0 markups are supported, too. It is a
> clone of DB2LaTeX.
Please explain in
[Lionel Elie Mamane]
> The remaining question is the equivs package, which is NMU-maintained
> these days. I suppose that the qa group should take it after a week
> or two?
If you think it should be orphaned / hijacked, I'm willing to adopt it.
I use it.
Peter
signature.asc
Description: Digita
Package: wnpp
Severity: normal
I intend to hijack 'equivs', as its maintainer (Fabio Rafael da Rosa
<[EMAIL PROTECTED]>) is believed MIA.
I will wait a week or so to see he shows up.
Peter
signature.asc
Description: Digital signature
[dann frazier]
> * Package name: slimscrobbler
> Description : SlimServer plugin that submits listening data to Last.FM
OK...
> Version : x.y.z
> Upstream Author : Name <[EMAIL PROTECTED]>
> * URL : http://www.example.org/
> * License : (GPL, LGPL, BSD,
[dann frazier]
> > > Version : x.y.z
> > > Upstream Author : Name <[EMAIL PROTECTED]>
> > > * URL : http://www.example.org/
> > > * License : (GPL, LGPL, BSD, MIT/X, etc.)
> > >
> > > (Include the long description here.)
>
> I couldn't really come up with anything
[Daniel Schepler]
> > If you're suggesting that with a move of update-inetd then netbase
> > would become more like the netbase-data I was suggesting as an
> > alternative, with minimal dependencies, that would be fine with me.
[Marco d'Itri]
> Yes, because only the files in /etc/ would be left
[Anthony DeRobertis]
> If there is really a problem with not being able to include
> everything in netkit-data or whatever, we need an update-services
> command, etc.
/etc/services.d (:
signature.asc
Description: Digital signature
[Christopher Martin]
> If an issue is highly controversial, then I can think of no better
> way of settling it in a way that most developers will accept than a
> vote. People respect votes much more than decrees, even if they don't
> agree with them.
And yet in this very thread we *still* have pe
[Thomas Weber]
> let's think about HTML files with Javascript.
>
> What are these? Documentation, computer programs, both?
To me the much more interesting question is "Given that you can make a
distinction between documentation and other software, why do users of
documentation not deserve the sa
[Jean-Christophe Dubacq]
> Is non-free not already distributable ? If something is not
> distributable, then it cannot even be in non-free.
non-free is distributable via the Debian FTP sites. However, not all
of it is distributable in other ways:
- some non-free software may have a license gran
[Hendrik Sattler]
> Me just doesn't get the rationale behind differing between firmware
> in a PROM and firmware that the driver loads into the hardware.
> There is none.
Good, then we can stop talking about including it in main. We don't
ship hardware, so if firmware is part of the hardware, we
[Michael Poole]
> What's the purpose of an assembler without assembly code to use it
> on? Despite Anthony's claim, I see no packages that can use nasm out
> of the box
If you hadn't already shot your credibility, you just did. Anthony
listed a dozen or so packages in Debian which require nasm
[Stefani Banerian]
> * Package name: sqlitemanager
> Version : x.y.z
> Upstream Author : Name <[EMAIL PROTECTED]>
> * URL : http://www.example.org/
> * License : (GPL, LGPL, BSD, MIT/X, etc.)
The information content here is rather thin.
signature.asc
Descript
[Kevin Mark]
> if a piece of software was initially created to enable the use of
> non-dfsg software with a dfsg system it is classified as 'ícontri',
> but then someone creates dfsg-software to use this software, now its
> classified as 'main'. Would this follow?
You're trying to sneak in an uns
[Peter Samuelson]
> > There's a big difference between enabling someone to install
> > non-free software, and enabling someone to view data. (Some of
> > which is free, some not.) Also, in case this was your point, swf
> > content is sometimes generated wit
[Eduard Bloch]
> I cannot remember a GR which says exactly this. Neither a GR which
> would clarify our definition of "firmware". And the one I follow is
> that it is more hardware than a software component.
Good. If firmware is hardware rather than software, there is nothing
to discuss. Debian
[Wouter Verhelst]
> What if I'm interested in writing such a driver myself, but less
> interested in having to run Windows?
Then you should get busy writing that driver. Without any such drivers
in existence, it's hard to take this line of reasoning seriously. I
find it absurd that someone woul
[Kevin Mark]
> would it provide any automation or easier processing for the NEW
> queue(ftpmasters)?
I doubt it. They don't take the maintainer's word for stuff like that,
as I understand it - they double-check the copyright and license
declarations in the source code.
> would it allow for redu
[Christian Pernegger]
> Judging from its documentation ndiswrapper doesn't need any non-free
> binaries, the module can be inserted even if no drivers are
> "installed". It might not be very useful like that, but "useful" is a
> very subjective thing in any case
Not *that* subjective. I think yo
[Frank Küster]
> That's not sufficient, because /usr/local may be mounted ro, and
> therefore the command may fail even if the directory is empty.
U.
There are lots of things dpkg can do which fail if filesystems are
mounted read-only. I don't think this is something worth worrying
about.
[Frank Küster]
> Because:
>
> , Policy 4.8
> | The build target must not do anything that might require root privilege.
> `
Right, but the 'binary' target is run as root.
, Policy 4.8
| The `fakeroot' package often allows one to build a package correctly
| even without being root.
[Gustavo Franco]
> I think some of these problems can be detected by lintian, adding
> some more checks there. It could bring more visibility to so common
> errors. Comments ?
A better way to phrase "Comments?" would be: "Here is a proof-of-
concept patch to lintian to demonstrate which of these
[Gustavo Franco]
> I won't waste my time writing a patch without hear Lars' and lintian
> maintainers opinions first.
Fair enough, but your original statement was, IMO, too vague. You said
"some of" the piuparts-detected problems looked as though lintian
should be able to catch them, but you did
[Shaun Jackman]
> A grave bug has been file against a package I maintain pointing out
> that the package does not work on AMD64 and in fact never has, even
> though it builds on AMD64. Since it turns out this package has never
> worked on AMD64, this bug is not a regression, but the status-quo.
>
[Thijs Kinkhorst]
> Yes, but the point raised was whether it would be better to
> centralise that. There are a lot of opportunities to run lintian but
> appearently a lot of packages with errors/warnings are being
> uploaded.
Sometimes lintian tests have bugs / limitations - false positives which
[Hamish Moffatt]
> > flashplugin-nonfree itself contains scripts which I presume meet
> > the DFSG. Do you think we should put it in main?
[Stephen Gran]
> I assume this is a troll
Your refusal to answer his question is itself an answer.
> > > ndiswrapper is a piece of free software. It does
[liw]
> > a) If there is a bug in the packaging, it can be fixed without
> > uploading a new upstream source tarball. Assuming upstream version
> > is 1.2, the first Debian version would be 1.2-1, and the fixed one
> > would be 1.2-2. The .orig.tar.gz file would be the same for 1.2-1
> > and 1.
[Brian May]
> I think these should belong in a separate category then ndiswrapper,
> because, unlike ndiswrapper, they are not even "complete" packages
> without non-free software, and this will never change for the
> lifetime of the installer package.
Never underestimate the Debian universe's co
[Michael Banck]
> Please take into consideration that libselinux is not available on
> Debian's non-Linux ports.
It's not libselinux you should be worried about, but libdevmapper.
He's not depending on libselinux directly, but he notes that on Linux
systems, the dependency chain will pull it in.
[Steve Langasek]
> You could also do, e.g.:
>
> Build-Depends: [...] libselinux1-dev [alpha amd64 arm hppa i386 ia64 m68k
> mips mipsel powerpc s390 sparc linux-any]
Build-Depends: [...] libselinux1-dev [!hurd-i386 !kfreebsd-i386]
When other non-linux ports run into a FTBFS, you add them.
Si
[Peter Kourzanov]
> For most of the packages, what is so different in cross-compilation
> in comparison to native?
Whether or not 'configure' believes it can use tests of the form "try
compiling and running this little program to see what it does". If it
is cross-compiling, it is forced to skip
1 - 100 of 539 matches
Mail list logo
