Bug#1061111: RFS: dpkg-buildenv/1.0.0 [ITP] -- Builds debian packages in a docker container.

[Guillem Jover]

Hi!

On Fri, 2024-01-19 at 14:13:07 +, Aidan wrote:
> On Fri, 19 Jan 2024, 00:08 Guillem Jover,  wrote:
> > …regardless of whether this is or not the last blocking issue, I'd
> > still very much appreciate if you could rename the project and tool
> > upstream. :)

> I shall rename the tool to remove "dpkg". Unless there are any objections
> I'm going to rename it to:
> "debpic: DEbian Build Package In Container"

That looks better, yes, and thank you for considering doing that!

(Also the pic part also evokes into my mind "image" which seems apt in
this context. :)

Thanks,
Guillem

Bug#1061111: RFS: dpkg-buildenv/1.0.0 [ITP] -- Builds debian packages in a docker container.

[Guillem Jover]

Hi!

On Thu, 2024-01-18 at 23:14:49 +, Aidan wrote:
> On Thu, Jan 18, 2024 at 6:30 PM David Kalnischkies wrote:
> > On Thu, Jan 18, 2024 at 02:35:40PM +, Aidan wrote:
> > > I am looking for a sponsor for my package "dpkg-buildenv":
> >
> > Similar to my recent "veto" of apt-verify in #1059267, which was
> > subsequently ignored and pushed into the archive anyhow, I would
> > like to call into question the naming of the package/application…
> >
> > There are various "dpkg-build*" tools already that grabbing 'env' feels
> > wrong (I would confuse it probably with 'flag' on a bad day), especially
> > if that isn't at least discussed with dpkg maintainers (I at least see
> > no mention of it on the list) and given that this is something that
> > "just" works with Docker.

Just by chance I had seen the mail on the mentors list, but thanks for
the heads-up, because I tend to look there very sporadically!

My reaction was pretty similar TBH. There's enough confusion with
things like dpkg-reconfigure and dpkg-preconfigure and other packages
that have also grabbed from the dpkg-* namespace, which I'd like to
reduce. In this case, it would remove the possibility to use such name
in the future, creates confusion, and it looks like a layer violation,
because it's setting up apt, containers and stuff which should be
sitting on top and not below dpkg.

> > As explained in the other bug, there is no veto and as you can see its
> > easy to completely ignore me (and anyone else) but I wanted to say it
> > anyhow, so that nobody is surprised later on.

> Thanks for taking a look David.
> For the name I choose "dpkg'' because it stands for "debian package" and
> dpkg-buildenv is intrinsically related to debian packaging.
> However I understand the usage of dpkg may imply the package has been
> officially created and maintained by the dpkg developers.

Yes, see above. I also appreciate naming is hard, :) but all other
similar implementations could have claimed the same about using dpkg-*,
and I think josch questions are also relevant, even though I also
understand that even among all other options, none might seem
completely suitable to you. But…

> If the package's name was the last blocking issue preventing adoption in
> Debian then I would spend the time to rename it.

…regardless of whether this is or not the last blocking issue, I'd
still very much appreciate if you could rename the project and tool
upstream. :)

Thanks,
Guillem

Re: Debian versioning question

[Guillem Jover]

Hi!

On Sat, 2023-11-11 at 03:28:21 +, Wookey wrote:
> On 2023-11-10 23:44 +0100, Preuße, Hilmar wrote:
> > On 10.11.2023 03:10, Wookey wrote:
> > > I think your options are
> > > 1) add an epoch (which exists to deal with this sort of problem)
> > > 
> > Well, would like to avoid it, if possible.
> 
> There is no real reason to avoid epochs

Oh, but there are! See .

> but they always feel a bit
> 'ugly' so people do tend to avoid them if they can.

That's the lesser of the issues with epochs. :)

Thanks,
Guillem

Re: Prevent dpkg-buildflags from overwriting any (or at least some) flags during compilation

[Guillem Jover]

Hi!

On Sat, 2023-07-22 at 13:12:28 +0200, Guillem Jover wrote:
> [ This feels more like a packaging question than one for dpkg development,
>   please redirect further replies to debian-mentors(?) now on Cc. :) ]

[ Sorry noticed the typo in the mentors list address just when I was
  sending the mail. :/ ]

> On Wed, 2023-07-12 at 15:21:26 +0200, Jędrzej Dudkiewicz wrote:
> > I have few projects that I pack for our internal use. I use `debuild`
> > to compile them. They all use CMake. CMakeLists.txt contains carefully
> > selected sets of flags that we want to use. Unfortunately when the
> > package is built, `debuild` overrides a few flags (it adds -g, changes
> > -Os to -O2) and we definitely don't want that. Is there some way to
> > prevent `dpkg-flags` from changing them?
> 
> Usually with build systems you should be able to denote what compiler
> flags are required (or well, highly desirable) and which ones are
> truly optional. Say the difference in a Makefile between:
> 
>   CFLAGS ?= optional such as -O2.
>   CFLAGS += required such as -fwrapv or highly desirable such as -Wbar.
> 
> or similar. For dpkg itself for example, the build system will default
> to check for the availability of lots of warning flags and append them
> unconditionally, but makes it possible to disable this behavior by
> passing --disable-compiler-warnings to ./configure. I assume you could
> do something similar with CMake.
> 
> > I don't want to repeat those flags in debian/rules as this way I will
> > have to change them in two places in case any of them changes.
> 
> Ack.
> 
> > Is there some simple way to avoid usage of `dpkg-buildflags` during 
> > compilation?
> 
> This depends on how dpkg-buildflags is being called, if you had a
> hand-crafted debian/rules, then you can control how to call it. But if
> using dh/debhelper, then not really, because that seems a bit counter
> to what both debheler and dpkg-buildflags are supposed to be doing.

Thanks,
Guillem

Bug#950760: RFS: libbpf/0.0.6-1 -- eBPF helper library (development files)

[Guillem Jover]

On Thu, 2020-02-06 at 09:39:29 +0100, Michael Biebl wrote:
> Am 06.02.20 um 09:22 schrieb Adam D. Barratt:
> > On 2020-02-06 08:12, Paul Gevers wrote:
> > > But, if I am correct, the source could be using a version without epoch
> > > and only use the epoch in the binary package (which can be dropped if
> > > libbpf0 is ever replaced by libbpf1).
> > 
> > Yes. It's a little more work on the packaging side, but entirely
> > possible to do it that way.

While this case is precisely what epochs were designed for, I'd still
try to minimize its usage here as much as possible. And go for no
epoch on the source packages, and prefixing the epoch in the binary
packages, because the one in libbpf1 could then be dropped.

> There is also libbpf-dev, which could not drop the epoch on a soname
> bump. Would be kinda odd if going forward libbpfx would not have an
> epoch and libbpf-dev does.

We already have similar cases in the archive. And the nice thing of
not going with a full epoch bump is that it can always be bumped for
the source later on, while the reverse is not possible. :)

> One other alternative could be, to ask your upstream to change the
> versioning scheme and instead of using 0.0.6, switch to 6.0.0 as first
> version number (which would be higher then 5.x)
> Other distros might have similar problems.

That might be even better, yes. :)

Thanks,
Guillem

Re: Sharing a script between two "Multi-Arch: foreign" packages

[Guillem Jover]

Hi!

On Tue, 2019-08-06 at 16:45:09 +0200, Jens Reyer wrote:
> Both build and install a "wineserver" binary, which we install as
> /usr/lib/wine/wineserver32 or wineserver64.  We call that binary from a
> script [2] /usr/lib/wine/wineserver which currently is in pkg:wine
> (arch:all), which is only "recommended" [3] by pkg:wine32 or pkg:wine64.
> 
> Since the wineserver{32|64} file is not found by the Wine code, these
> filenames are broken without our wineserver script.  So I'd like to move
> that script to pkg:wine32 and pkg:wine64.

> [2] There are also unrelated reasons for having this script.  Otherwise
> I'd dpkg-divert the 32-bit wineserver in favor of the 64-bit one, which
> would perfectly match the way Wine works (Wine uses the 32-bit
> wineserver only for pure 32-bit installations, but the 64-bit server for
> mixed and 64-bit installations).
> I could dpkg-divert the script, but that looks like a workaround, not a
> solution, to me.

I've checked the script, and the only reason I see for it being a
wrapper is perhaps the -p0 option? Couldn't that be passed by whoever
is running that program?

If so a probably nicer option would be to turn the wineserver pathname
into an alternative, then you can assign the 32-bit variant a lower
priority than the 64-bit one, and things will just work automatically.

Thanks,
Guillem

Re: How to determine the filename for dlopen()

[Guillem Jover]

Hi!

On Mon, 2017-11-13 at 13:23:01 +0100, Ferenc Wágner wrote:
> I'm packaging a program which wants to dlopen() some library.  It finds
> this library via pkg-config (PKG_CHECK_MODULES).  How to best determine
> the filename to use in the dlopen() call?  It should work cross-distro,
> for cross-compilation and whatnot.  Is it always safe to use the SONAME
> as the filename?  I'm currently considering something like
> 
> ld -shared -o dummy.so $(my_LIBS)
> objdump -p dummy.so | fgrep NEEDED
> 
> coded up properly for Automake.  I'd be grateful for any insight.

IMO dlopen()ing an external library that is not part of the same
project is a practice that should be very strongly discouraged, if
not completely abolished.

Please see this very nice mail from Simon McVittie [S], my reply [G],
and Florian Weimer's [F], for several of the reasons why.

 [S] https://lists.debian.org/debian-devel/2017/03/msg00164.html
 [G] https://lists.debian.org/debian-devel/2017/03/msg00343.html
 [F] https://lists.debian.org/debian-devel/2017/03/msg00346.html

Thanks,
Guillem

Re: package pynmea2

[Guillem Jover]

On Tue, 2017-11-14 at 12:13:55 -0200, Herbert Fortes wrote:
> There was a ITP-RFS for pynmea2. But python-nmea2 already
> exists.
> 
> https://packages.qa.debian.org/p/python-nmea2.html
> 
> I asked the contributor (2017-11-12) to close the bugs with 
> an n-d...@bugs.debian.org but he sent -cl...@bugs.debian.org 
> to ITP only. RFS still open.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871468
> 
> Today I received an email saying that pynmea2 was accepted. It
> already has a page:
> 
> https://packages.qa.debian.org/p/pynmea2.html

:(

> What to do ? Ask FTP-Master to remove the package ?

This is IMO, fundamentally a problem with the current python policy
which does not require that source package names MUST be normalized
and namespaced with python-, and get py prefixes removed and similar.
Following the exemple set by other lang-specific policies.

This causes the problem of different name manglings depending on who
is packaging, and search misses like happened here. It also
unjustifyingly stomps on the global source package namespace with
many times extremely generic names. :(

I filed #791635 some time ago, but didn't find the energy to it
discuss forward given the initial reply. But probably I should!

Thanks,
Guillem

Re: How to find Multi-Arch path(s)

[Guillem Jover]

On Sat, 2017-11-25 at 11:36:27 +0100, Ole Streicher wrote:
> Guillem Jover <guil...@debian.org> writes:
> > The point is that the Multi-Arch concept in Debian is all about the
> > interfaces. How packages and files interface with each other, and
> > what is possible and allowed. Some examples:
> >
> >   * A script might be arch-independent in the contents sense; i.e., it
> > is the same on all architectures. But its interface might be
> > arch-dependent, because itself uses processor or kernel specific
> > interfaces, and its output changes depending on the architecture.
> > These cannot be marked as Mutli-Arch foreign.
> >   * A compiled binary might be arch-dependent in the contents sense;
> > i.e., it is different on each architecture. But its interface might
> > be arch-independent, because it does not change independently on
> > where it is executed, or for what arch it was built for. These can
> > be marked as Multi-Arch foreign.
> 
> Ahh. This is the point. So, there is (in my case) no reason to put *any*
> binary to /usr/lib//iraf; they all should go to /usr/lib/iraf,
> indepentent of the architecture. That means, that the main package
> (f.e.) cannot be co-installed for different archs, but this is also not
> required.

Correct.

> >   * A shared library that is being linked by some other package with
> > executables, needs to match their architecture and needs to be
> > coinstallable with itself, otherwise you could not install
> > packages of different architectures linking againts that library.
> > Say prog-a:i386 → libso:i386, and prog-b:amd64 → libso:amd64.
> > These are usually as Multi-Arch same.
> 
> The package does not support shared libs yet -- as I said they made some
> funny solutions: f.e. IRAF has its own incarnation of the libc, which is
> implemented on the base of FORTRAN libs, and this lib is also called
> "libc.a". To avoid using the wrong lib, this one is not linked by "-lc",
> but by specifying the full path. Changing this to some shared lib
> approach *and* being still compatible to third-party plugins is not
> trivial and part of the longer-term evolution (depending on the success
> of the package).

Ugh. :)

> So, I have a development package with "libc.a" and other stuff, but also
> some executables (compiler) which are arch dependent. Handling multiarch
> here is probably not worth the effort -- I see no use case to have the
> development environment for more than one arch co-installed, and
> therefore I would put the contents (binaries and static libs) to
> /usr/lib/iraf/ and mark it with "Multi-arch: no".
> 
> Would this be OK?

Depends on who are the intended users of those libraries and for
that compiler (!?).

If those are needed to build only the iraf plugins, then Multi-Archifying
them, might make it possible to cross-build them easily. But that depends
on what all of this entails.

Personally I'd only mark a package as Multi-Arch: no in case there's
been determined that marking it with anything else would be wrong, and
that there's no other option, like package splitting and file
reorganization, etc, to make it Multi-Arch ready.

> > So, say, your native arch (the one dpkg was built for) is amd64,
> > and you have enabled i386 as a foreign arch. You then install the
> > main iraf package for amd64 (the default), and then want to use some
> > extension/plugin that is available only for 32-bit arches. apt for
> > example will just pull the i386 version, because it'd be marked as
> > Multi-Arch foreign and the dependencies would be fullfilled.
> 
> Looks like as I want it. Let me repeat with my own words (just to be
> sure I understand it): I have
> 
> iraf   - Multi-arch: foreign, x86_64, i386, ...
> iraf-sptables  - Multi-arch: foreign, i386; Depends: iraf
> 
> On a x86_64 with i386 enabled, when I do an "apt install iraf-sptables",
> I get iraf as x86_64 and iraf-sptables as i386. Correct?

That depends on apt's behavior, other package manager frontends could
behave differently. In this case apt might prefer to make the
dependencies "self-contained" and pull iraf:i386, or it might prefer
to give the native version more weight. I'm not certain. In any case
you'd always be able to do:

  # apt install iraf-sptables iraf:amd64

or if you've got iraf:i386, just:

  # apt install iraf:amd64

and the package would get cross-graded.

> Thank you very much for your patience and your good explanations! I feel
> now that I understand the multiarch idea a bit better (well, hopefully).

No problem!

Thanks,
Guillem

Re: How to find Multi-Arch path(s)

[Guillem Jover]

Hi!

On Fri, 2017-11-24 at 13:59:40 +0100, Ole Streicher wrote:
> Guillem Jover <guil...@debian.org> writes:
> > On Fri, 2017-11-24 at 09:52:23 +0100, Ole Streicher wrote:
> >> So, how can I canonically (ideally from C) retrieve a sorted list of
> >> supported multi arch paths at runtime? Or is there another good way to
> >> solve this? I would think it is a standard use case for multi arch,
> >> isn't it?
> >
> > In general if you have to modify an upstream codebase to make it
> > package-manager aware (be that dpkg, rpm or whatever), that to me seems
> > like a big red sign too. In this case I think the problem is indeed that
> > the original question is flawed, so there's no good answer. :)
> 
> IRAF is a quite old program (>>30 years), with some unconventional
> solutions. And it is in "maintenance mode" yet.
> 
> The Multi-Arch solution upstream took is to put the binaries into
> directories
> 
> /iraf/iraf/bin.linuxfor 32 bit Linux (x86)
> /iraf/iraf/bin.linux64  for 64 bit Linux (x86)
> /iraf/iraf/bin.macosx   for 32 bit Mac OSX
> /iraf/iraf/bin.macintel for 32 bit Mac OSX
> 
> (similar subdirs bin. are under /iraf/iraf/unix, /iraf/iraf/noao etc.)

This is closer to the old multilib approach, which we are trying to
deprecate. I'd completely scrap and ignore this concept from upstream.

> and then have explicit if statements "if 64-bit linux also look in
> 32-bit dirs".  This is not applicable for Debian; first because of the
> FHS violation; but also because other archs are not really possible. The
> ARM architecture is however a working platform, with some use cases
> (people want to run it on their raspberry).

Exactly.

> Therefore I move everything unter /iraf/iraf to /usr/share/iraf (because
> it is arch independent), except the bin.* dirs, which in a Debian
> Multiarch environment should go into /usr/lib//iraf, right?

Nope, as I've mentioned on my previous mail, I'd make the executables
also arch-neutral on their pathnames.

The point is that the Multi-Arch concept in Debian is all about the
interfaces. How packages and files interface with each other, and
what is possible and allowed. Some examples:

  * A script might be arch-independent in the contents sense; i.e., it
is the same on all architectures. But its interface might be
arch-dependent, because itself uses processor or kernel specific
interfaces, and its output changes depending on the architecture.
These cannot be marked as Mutli-Arch foreign.
  * A compiled binary might be arch-dependent in the contents sense;
i.e., it is different on each architecture. But its interface might
be arch-independent, because it does not change independently on
where it is executed, or for what arch it was built for. These can
be marked as Multi-Arch foreign.
  * A shared library that is being linked by some other package with
executables, needs to match their architecture and needs to be
coinstallable with itself, otherwise you could not install
packages of different architectures linking againts that library.
Say prog-a:i386 → libso:i386, and prog-b:amd64 → libso:amd64.
These are usually as Multi-Arch same.

There are other fancy scenarios, and there's the more complex
"allowed" value, but the examples below should cover our case here.

> > So, going back. AFAIUI the iraf project supports plugins/extensions in
> > the form of executables. 
> 
> Yes.
> 
> > And some might only be available in a single arch.
> 
> No. They are available under 32-bit archs. At least armhf and
> i386 (linux + kfreebsd). Maybe x32.

Well, ok, so arch-classes, all the same. :)

So, say, your native arch (the one dpkg was built for) is amd64,
and you have enabled i386 as a foreign arch. You then install the
main iraf package for amd64 (the default), and then want to use some
extension/plugin that is available only for 32-bit arches. apt for
example will just pull the i386 version, because it'd be marked as
Multi-Arch foreign and the dependencies would be fullfilled.

That of course means, that whoever is calling those extension should
not need to care what the arch is, because supposedly anything that
can be executed will do. And what to install is decided by the package
manager and/or the user. So that's why the executable pathnames should
be arch-neutral.

> > If that's the case, that looks like those extensions should be
> > placed under a /usr/lib/iraf (or similar, perhaps even /usr/libexec if
> > we allowed that!), and those package be marked "Multi-Arch: foreign",
> > then that's the package manager's problem to choose the most
> > appropriate architecture for those binaries (perhaps by using the
> > futurable executable attribute of an arch).
> 
>

Re: How to find Multi-Arch path(s)

[Guillem Jover]

Hi!

On Fri, 2017-11-24 at 09:52:23 +0100, Ole Streicher wrote:
> I want to package a software, "iraf" (with extensions) that uses some
> system dependent binaries internally. Some of the extensions will be
> available in 32 bit only, so this is a good use case for
> Multi-Arch. That means, that the binaries will go to
> 
> /usr/lib/${DEB_TARGET_MULTIARCH}/iraf

It that was to be used, then it should be DEB_HOST_MULTIARCH, the
_TARGET_ variants are for canadian cross-compilers. :) If this is not
clear from the man page, I'm happy to clarify it further.

> At run time, I would now need to get the list of paths that are
> supported by the system, in their "preferred" order (so, even from a
> binary compiled for i386, it would be preferred to call a x86_64 binary
> if that is supported on the system). This list is generally not known at
> compile time, since it depends on the details of the target system
> configuration (f.e. an architecture may be supported via a software
> emulation).
> 
> However, I could not find out how to get this list?
> 
> "dpkg --print-architecture" and "dpkg --print-foreign-architectures"
> gives only what dpkg is configured for, not what is supported as
> executable. And, it does not return the multi-arch triplet.

While there are requests to include this information, so that it can
be retrieved and used, in this case it does not seem this is what you
should be using anyway, even if it was there.

> "dpkg-architecture -q DEB_HOST_MULTIARCH" may give the host architecture
> (default, or specified by the arch name), but from the manpage and the
> package description of dpkg-dev it is not intended for runtime, but for
> package build/development.

Exactly. When one needs the matching triplet or multiarch normalized
triplet for the package's arch, that's best solved by injecting that
at build time, which is already known at that point. In most cases
when one needs to know those matching triplets for *any* arch at
run-time, that's a sign there's something wrong with the design, and
I'd recommend going back to the drawing board. :)

> So, how can I canonically (ideally from C) retrieve a sorted list of
> supported multi arch paths at runtime? Or is there another good way to
> solve this? I would think it is a standard use case for multi arch,
> isn't it?

In general if you have to modify an upstream codebase to make it
package-manager aware (be that dpkg, rpm or whatever), that to me seems
like a big red sign too. In this case I think the problem is indeed that
the original question is flawed, so there's no good answer. :)

So, going back. AFAIUI the iraf project supports plugins/extensions in
the form of executables. And some might only be available in a single
arch. If that's the case, that looks like those extensions should be
placed under a /usr/lib/iraf (or similar, perhaps even /usr/libexec if
we allowed that!), and those package be marked "Multi-Arch: foreign",
then that's the package manager's problem to choose the most
appropriate architecture for those binaries (perhaps by using the
futurable executable attribute of an arch).

Hope that helps!

Thanks,
Guillem

Bug#670195: RFS: lierolibre/0.1-1

[Guillem Jover]

On Wed, 2012-04-25 at 01:50:59 +0200, Martin Erik Werner wrote:
 On Tue, 2012-04-24 at 10:14 +0800, Paul Wise wrote:
  I note many files don't have copyright/license headers:
  
  http://tieguy.org/blog/2012/03/17/on-the-importance-of-per-file-license-information/

 I'm aware, I have taken to practice adding copyright headers to all
 *header* files whose related code I poke in, but since I have not made
 changes to all bits, many remain unchanged.

Well strictly speaking you don't really need to add a Copyright notice
to be able to add the per-file license headers; you could do the latter
right away for all project files, and do the former when time permits a
proper authorship research, or at least for yours when you modify them.

regards,
guillem



-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120425054045.ga7...@gaara.hadrons.org

Re: binNMU safe and ${binary:Version} or ${source:Version}

[Guillem Jover]

On Fri, 2006-10-13 at 10:01:08 -0700, Steve Langasek wrote:
 On Fri, Oct 13, 2006 at 04:13:07AM +0300, Guillem Jover wrote:
  On Tue, 12 Sep 2006 15:11:23 -0700 Steve Langasek wrote:
   The documentation for this probably belongs in debian-policy; current
   versions of policy seem to mention Source-Version, though, not the new
   substvars, and I'm not sure if anyone has submitted a patch for this?

  I was waiting until after the etch release to send such patch. I'd
  consider Source-Version to be now half-deprecated, due to it needing
  a versioned Build-Dependency on dpkg-dev.

 But this is a versioned Build-Dependency that can be satisfied today in
 etch; I don't see any reason to delay updating policy.

Yes it can be satisfied, but if policy specifies that the field is
deprecated, people wanting to follow policy will start Build-Depending
on a versioned dpkg-dev, which I rather not see happening if not
strictly needed (like in case of non-binNMU safe packages).

Maybe this is a void concern that can be fixed by proper wording in
the policy, though. Another option could be to up the dpkg-dev version
in build-essential, thus avoiding completely the Build-Depends.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: binNMU safe and ${binary:Version} or ${source:Version}

[Guillem Jover]

[ Found this today on the web archives. ]

Hi,

On Tue, 12 Sep 2006 15:11:23 -0700 Steve Langasek wrote:
 The documentation for this probably belongs in debian-policy; current
 versions of policy seem to mention Source-Version, though, not the new
 substvars, and I'm not sure if anyone has submitted a patch for this?

I was waiting until after the etch release to send such patch. I'd
consider Source-Version to be now half-deprecated, due to it needing
a versioned Build-Dependency on dpkg-dev. After the release we can
fix the policy and advertise it widely as deprecated and even add a
warning in lintian/linda. Once all packages have been fixed, we could
consider removing that substvar, to avoid all confusion it carries...

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: PearPC Section (contrib or main)

[Guillem Jover]

On Sat, Oct 09, 2004 at 08:15:47PM +0200, Ramón Rey Vicente wrote:
 Leo Costela Antunes wrote:
 | PearPC does not need MacOS X or other non-free operating system to be
 | fully used, it can be used with Debian/PPC for example, so, does it need
 | to stay in contrib?
 
 And, whats about dosemu? dosemu not need a non-free operating system to
 be fully used. With dosemu-freedos for example, you reach a fully
 funtional DOS-like environment. Why dosemu is into contrib section? More
 specifically, dosemu, dosemu-freedos and xfonts-dosemu

Because freedos needs a non-free compiler to build.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: PearPC Section (contrib or main)

[Guillem Jover]

On Sat, Oct 09, 2004 at 08:15:47PM +0200, Ramón Rey Vicente wrote:
 Leo Costela Antunes wrote:
 | PearPC does not need MacOS X or other non-free operating system to be
 | fully used, it can be used with Debian/PPC for example, so, does it need
 | to stay in contrib?
 
 And, whats about dosemu? dosemu not need a non-free operating system to
 be fully used. With dosemu-freedos for example, you reach a fully
 funtional DOS-like environment. Why dosemu is into contrib section? More
 specifically, dosemu, dosemu-freedos and xfonts-dosemu

Because freedos needs a non-free compiler to build.

regards,
guillem