Re: Mandatory LC_ALL=C.UTF-8 during package building

[Guillem Jover]

Hi!

On Thu, 2024-06-06 at 15:31:55 +0100, Simon McVittie wrote:
> On Thu, 06 Jun 2024 at 13:32:27 +0300, Hakan Bayındır wrote:
> > C, or C.UTF-8 is not a universal locale which works
> > for all.
> 
> Sure, and I don't think anyone is arguing that you or anyone else should
> set the locale for your interactive terminal session, your GUI desktop
> environment, or even your servers to C.UTF-8.
> 
> But, this thread is about build environments for our packages, not about
> runtime environments. We have two-and-a-half possible policies:

> 1. Status quo, in theory:
> 
>Packages cannot make any assumptions about build-time locales.
> 
>The benefits are:
> 
>- Diagnostic messages are in the maintainer's local language, and
>  potentially easier to understand.

I think this is way more important than the relative space used to
mention it though. :) I'm a non-native speaker, who has been involved
in l10n for a long time, while at the same time I've pretty much
always run my systems with either LANG=C.UTF-8 or before that LANG=C,
LC_CTYPE=ca_ES.UTF-8 and LC_COLLATE=ca_ES.UTF-8.

And I think forcing a locale on buildds makes perfect sense, because
we want easy access to build logs. But forcing LC_ALL from the build
tools implies that no tool invoked will get translated messages at
all, and means that users (not just maintainers) might have a harder
time understanding what's going on, we make lots of l10n work rather
pointless, and if no one is running with different locales then l10n
bugs might easily creep in.

>- If a mass-QA effort wants to assess whether the program is broken by
>  a particular locale, they can easily try running its build-time tests
>  in that locale, **if** the tests do not already force a different
>  locale. (But this comes with some serious limitations: it's likely
>  to have a significant number of false-positive situations where the
>  program is actually working perfectly but the **tests** make assumptions
>  that are not true in all locales, and as a result many upstream
>  projects set their build-time tests to force specific locales
>  anyway - often C, en_US.UTF-8 or C.UTF-8 - regardless of what we
>  might prefer in Debian.)

I consider locale sensitive misbehavior as a category of "upstream"
bugs (be that in the package upstream or the native Debian tools), that
deserve to be spotted and fixed. I can understand though the sentiment
of wanting to shrug this problem category off and wanting instead to
sweep it under the carpet, but that has accessibility consequences.

>   The costs are:

>   - […] but if I'm expected to diagnose the
> problem by reading Chinese error messages, as a non-Chinese-speaker I
> am not going to get far.)

Just as an aside, but while getting non-English messages makes for
harder to diagnose bugs, I've never found it a big deal to deal with
that kind of bug reports, as you can grep for (parts of) the
translated message, and then get the original English string from the
.po for example, or can translate the text back to know what it is
talking about, or ask the reported to translate it for you.

> 2½. Unwelcome compromise (increasingly the status quo):
> 
>Whenever a package is non-reproducible, fails to build or fails tests
>in certain locales (for example legacy non-UTF-8 locales like C or
>en_GB.ISO-8859-15), we add `export LC_ALL=C.UTF-8` to debian/rules and
>move on.
> 
>This is just (2.) with extra steps, and has the same benefit and cost
>for the affected packages as (2.) plus an additional cost (someone must
>identify that the package is in this category and copy/paste the extra
>line), and the same benefit and costs for unmodified packages as (1.).

I agree though, that if we end up with every debian/rules
unconditionally exporting LC_ALL, then there's not much point in not
making the build driver do it instead.


Related to this, dpkg-buildpackage 1.20.0 gained a --sanitize-env,
which for now on Debian and derivatives sets LC_COLLATE=C.UTF-8 and
umask=0022.

But _iff_ we end up with dpkg-buildpackage being declared the only
supported entry point, _and_ there is consensus that we'd want to set
some kind of locale variable from the build driver, then I guess this
could be done as a Debian vendor-specific thing, or via the
dpkg-build-api(7) interface.

Thanks,
Guillem

Re: Enabling some -Werror=format* by default?

[Guillem Jover]

Hi!

On Mon, 2024-06-10 at 16:06:13 +0500, Andrey Rakhmatullin wrote:
> On Mon, Jun 10, 2024 at 07:48:59AM +0200, Helmut Grohne wrote:
> > > We recently increased the time_t size on certain architectures and some
> > > packages started failing to build because they were using a format
> > > specifier too narrow for the wider time_t, e.g. #1067829.
> > > But the only reason those package FTBFS is they enable either -Werror or
> > > some more specific non-default switch like -Werror=format=2, so I suspect
> > > much more packages contain similar code but gained only a warning. Isn't
> > > this a bad thing? Should we enable at least some combination of -Wformat*
> > > switches by default? Should we at least add a new flag to dpkg-buildflags
> > > and do some test rebuilds with it enabled?
> > 
> > It wasn't quite clear to me what -Werror=format=2 actually means.
> > According to the gcc documentation[1], -Wformat=2 currently means:
> > 
> > -Wformat -Wformat-nonliteral -Wformat-security -Wformat-y2k.

Those are in addition to the ones enabled by -Wformat=1, which are:

  -Wnonnull -Wno-format-contains-nul -Wno-format-extra-args
  -Wno-format-zero-length

So all the above would supposedly turn into -Werror too.

> But I don't know if even -Werror=format is too much to enable by default
> globally (I assume it's a good thing to enable it, though).

Hard to say w/o a rebuild I guess. (And take into account this can
also affect configure-style checks, which might become silent errors
but end up disabling features or enabling unexpected code paths or
similar.)

In general I think it's good (in principle) to enable -Werror flags
that detect actual bugs in code, the problem is always going to be
the amount of fallout and work that creates, and whether there's
consensus about that work commitment being acceptable to maintainers
in Debian, or whether that can interfere with transitions going on,
etc.

> > It also is unclear how this impacts the archive and yes, I'd recommend a
> > rebuild. Note though that we likely need this rebuild both on a 64bit
> > architecture and a 32bit architecture that is not i386 (due to how t64
> > works). A partial archive rebuild may work to gauge the size of the
> > problem.
> > 
> > I note that this kind of change affects cross builds, so performing
> > cross builds for armhf on amd64 will likely show many of these failures
> > (in addition to all the regular cross build failures).
> > 
> > I recommend doing more research before moving forward with this. In
> > particular a MBF about introduced problems would be prudent before doing
> > the switch and even if we don't switch, such a MBF bears value on its
> > own.

> Do you think it makes sense to add this a flag that enables -Werror=format
> to dpkg-buildflags(1), before, or after a test rebuild, before, or after
> the MBF if we do one?

If by adding you mean adding a new feature flag that is disabled by
default, then depending on the feature area, that might unfortunately
be equivalent to enable it by default (due to the «all» keyword).

(I started a design to version the build flags interface, but I got
stuck, so I let it brew as a background process, have pending to finish
that up and propose it on d-dpkg.)

Thanks,
Guillem

Re: Enabling some -Werror=format* by default?

[Guillem Jover]

Hi!

On Mon, 2024-06-10 at 20:09:21 +0500, Andrey Rakhmatullin wrote:
> On Mon, Jun 10, 2024 at 04:24:54PM +0200, Guillem Jover wrote:
> > > Do you think it makes sense to add this a flag that enables -Werror=format
> > > to dpkg-buildflags(1), before, or after a test rebuild, before, or after
> > > the MBF if we do one?
> > 
> > If by adding you mean adding a new feature flag that is disabled by
> > default, then depending on the feature area, that might unfortunately
> > be equivalent to enable it by default (due to the «all» keyword).
> 
> Another related question: if not via dpkg-buildflags, how do we do
> rebuilds with changed default flags?

Ah, you can still use its mechanism (just not its policy) where a
rebuild should be able to use DEB__APPEND for that, or set
them in one of its config files.

If having a modified dpkg-dev emitting those by default would be less
cumbersome for the rebuilder, I'm happy to provide an out of archive
package for that for example, which I think we have done for some
rebuilds.

Thanks,
Guillem

Re: Enabling some -Werror=format* by default?

[Guillem Jover]

Hi!

On Mon, 2024-06-10 at 18:01:58 +0200, Helmut Grohne wrote:
> Ideally, we'd not just do a rebuild with the flags, but also do a
> rebuild without and then compare the binary .debs. In the event that we
> misguide configure, we expect the .debs to differ and otherwise to equal
> due to the work of the reproducible builds folks. That equality has a
> really annoying difference in practice though: Build ids are dependent
> on the compiler flags, so the comparison would have to magically ignore
> changes in build id and this is where things become quite difficult.

A quick check seems to indicate warning flags do not get recorded in
the object files, which make sense as these are not supposed to change
the emitted objects.

(This can be seen with «dwarfdump .../*.debug | grep DW_AT_producer»
on the debug files from the -dbgsym packages.)

Thanks,
Guillem

Re: Reviving schroot as used by sbuild

[Guillem Jover]

Hi!

On Tue, 2024-06-25 at 09:32:21 -0700, Russ Allbery wrote:
> Simon McVittie  writes:
> > Persisting a container root filesystem between multiple operations comes
> > with some serious correctness issues if there are "hooks" that can modify
> > it destructively on each operation: see 
> > and . As a result of that, I think the
> > only model that should be used in new systems is to have some concept of
> > a session (like schroot type=file, but unlike schroot type=directory)
> > so that those "hooks" only run once, on session creation, preventing
> > them from arbitrarily reverting/overwriting changes that are subsequently
> > made by packages installed into the chroot/container (for example dbus'
> > creation of the messagebus uid/gid in #499014, and exim4's creation of
> > Debian-exim in #994836).
> 
> I'm not entirely sure that I'm following the nuances of this discussion,
> so this may be irrelevant, but I think type=btrfs-snapshot provides the
> ideal properties for container file systems.  This unfortunately require
> file system support and therefore cannot be used unless you've already
> embraced a file system with subvolumes, but if you have, you get all of
> the speed of a persistent container root file system with none of the
> correctness issues, because you get a fresh (and almost instant) clone of
> a canonical root file system that is discarded after each build.
> 
> I use that in combination with a cron 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.

I manage my chroots with schroot (but not via sbuild, for dog fooding
purposes :), and use type=directory and union-type=overlay so that I
get a fast and persistent base, independent of the underlying filesystem,
with fresh instances per session. (You can access the base via the
source: names.) I never liked the type=file stuff, as it's slow to
setup and maintain.

Regards,
Guillem

Re: Q: Ubuntu PPA induced version ordering mess.

[Guillem Jover]

Hi!

On Tue, 2024-07-02 at 00:54:13 +0100, Wookey wrote:
> On 2024-07-01 23:59 +0200, Alec Leamas wrote:
> > But this is not about third parties, it's about upstream which publishes PPA
> > packages. So far these are by far the most used Linux packages.
> > 
> > I also hesitate to add an epoch, after all they are basically considered
> > evil. But if we should not use them when upstream has a broken versioning we
> > are about to replace, when should we use it?
> 
> Quite. People are quite resistant to spoiling neat version numbers
> with epochs, and no-one likes them, but they don't do any actual harm
> (except sometimes break scripts and tools that forgot to allow for
> them),

Oh, but they can cause actual harm. As has been mentioned on this
list many times, epochs by design invalidate existing versioned
relationships in both packaging fields (inside the distro (but in this
case that does not look like a problem) and on custom local packages),
and on tools/(maint)scripts comparing these versions. These can either
cause letting versions that should not be installed through, or can
cause version unsatisfiability.

There's also the problem that epochs are (currently) not included as
part of the filenames.

They are also a common source of errors, due to people forgetting they
need to add them in relationships (if you read package changelogs,
this is a common-ish occurrence).

This is covered in the dpkg FAQ (although I should probably also add
the accidental omission case):

  
https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_What_are_version_epochs_and_why_and_when_are_they_needed.3F

> and this seems seems like a very sensible use case: essentially
> jus thwat they are intended for.. Yes it was upstream that messed up
> not us/you, but we have the technology and you can make user's lives
> easier by just adding an epoch.

I guess the first question that pops in my mind is whether users who
have installed the packages from the PPA, because the Debian/Ubuntu
packages were not satisfactory, are going to be switching to the
Debian/Ubuntu packages? Perhaps only temporarily and then back to
the PPA? Are we going to get a version arms-race then?

(Personally I'd find the "sort the mess on the PPA side", the better
approach, but *shrug*.)

> It's a pity upsream didn't know about the 0~ trick so that it wouldn't
> matter what crazy version string was used, but it's done now.

AFAIUI upstream was using "correct" versions in their releases, they
just used the build-increment-based versions in that PPA.

Thanks,
Guillem

Re: Mandatory LC_ALL=C.UTF-8 during package building

[Guillem Jover]

Hi!

On Fri, 2024-06-07 at 15:40:07 +0200, Alexandre Detiste wrote:
> Maybe a compromise would be to at least mandate some UTF-8 locale.

Ah, good thinking! That would actually seem acceptable. I've prepared
the attached preliminary patch (missing better commit message, etc),
as a PoC for how this could look like. If there's consensus about
something like this, I'd be happy to merge into a future dpkg release.

Although I'm not sure though whether this would be enough to make it
possible to remove the hardcoding of LC_ALL=C.UTF-8 usage in debhelper,
which seems counter to l10n work, or perhaps to switch to a subset of
the locale settings. Niels?

Thanks,
Guillem
From 94c2540fe290ffaa70680d21725e3541642ab2f2 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Tue, 2 Jul 2024 03:34:35 +0200
Subject: [PATCH] dpkg-buildpackage: Require an UTF-8 (or ASCII) locale when
 building packages

Proposed-by: Alexandre Detiste 
---
 scripts/dpkg-buildpackage.pl | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/scripts/dpkg-buildpackage.pl b/scripts/dpkg-buildpackage.pl
index df2edded9..3f02f81ca 100755
--- a/scripts/dpkg-buildpackage.pl
+++ b/scripts/dpkg-buildpackage.pl
@@ -27,6 +27,7 @@ use File::Temp qw(tempdir);
 use File::Basename;
 use File::Copy;
 use File::Glob qw(bsd_glob GLOB_TILDE GLOB_NOCHECK);
+use I18N::Langinfo qw(langinfo CODESET);
 use POSIX qw(:sys_wait_h);
 
 use Dpkg ();
@@ -589,6 +590,19 @@ if ($signsource && build_has_none(BUILD_SOURCE)) {
 if ($sanitize_env) {
 run_vendor_hook('sanitize-environment');
 }
+my %allow_codeset = map { $_ => 1 } qw(
+UTF-8
+ANSI_X3.4-1968
+ANSI_X3.4-1986
+ISO646-US
+ASCII
+US-ASCII
+);
+
+my $codeset = langinfo(CODESET);
+if (not exists $allow_codeset{$codeset}) {
+error(g_('requires a locale with a UTF-8 (or ASCII) codeset'));
+}
 
 my $build_driver = Dpkg::BuildDriver->new(
 ctrl => $ctrl,
-- 
2.45.2

Re: Mandatory LC_ALL=C.UTF-8 during package building

[Guillem Jover]

Hi!

On Tue, 2024-07-02 at 09:52:05 +0100, Simon McVittie wrote:
> On Tue, 02 Jul 2024 at 03:47:29 +0200, Guillem Jover wrote:
> > On Fri, 2024-06-07 at 15:40:07 +0200, Alexandre Detiste wrote:
> > > Maybe a compromise would be to at least mandate some UTF-8 locale.
> >
> > dpkg-buildpackage: Require an UTF-8 (or ASCII) locale when
> > building packages
> 
> Allowing ASCII seems counterproductive: that puts us in the code path
> where various tools and runtimes (especially Python) will refuse to
> process or output anything outside the 0-127 range, which I believe is
> exactly the problem that debhelper aims to solve by using C.UTF-8 for
> some categories of package (in particular those that build with Meson).
> 
> To get what Alexandre suggested, we'd need to allow UTF-8 but not allow
> ASCII (so for example fr_FR.UTF-8 or C.UTF-8 is fine, but in particular
> the C locale is not).

Err, you are right. I think I implemented this from my recollection of
the thread, trying to enforce as little as possible, and to try to let
users set "translations" to pure ASCII if desired, but that then defeats
the point brought up in the original mail, and the locale setting in
debhelper. I'll amend the PoC commit to only allow UTF-8.

(Also as long as LC_CTYPE is UTF-8 I think it should not matter whether
LC_MESSAGES is non-UTF-8 as the output codeset should still be UTF-8.)

> Or perhaps this pseudocode?
> 
> if (charset != UTF-8) {
> emit a warning
> export LC_ALL=C.UTF-8
> unset LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE (etc.)
> }

As it stands, I don't think this would be good enough, because it would
introduce an implicit setting in dpkg-buildpackage while it is
currently not the only supported entry point, so packages could still
not rely on this being always set, and it still disables translated
messages.

While erroring out (even when dpkg-buildpackage is still not the only
supported entry point) would not give a full guarantee that a package
build is always done in a UTF-8 locale, it at least forces the caller
(be that a tool or a human) to change the running environment, while
not forcing untranslated messages. I guess this could be made a stronger
guarantee if debhelper switched from unconditionally setting the locale
to performing a similar check and erroring out too (instead of simply
removing the locale setting).


But from your pseudocode, now I realize the check I implemented is
probably too naive, as it should probably at least also check whether
LC_COLLATE is also UTF-8. So I'll try to think how to make it more
robust.

But, I guess I can at least unconditionally set LC_CTYPE=C.UTF-8 when
using --sanitive-env, right away though.

Thanks,
Guillem

Re: Q: Ubuntu PPA induced version ordering mess.

[Guillem Jover]

Hi!

On Tue, 2024-07-02 at 03:32:53 +0200, Guillem Jover wrote:
> On Tue, 2024-07-02 at 00:54:13 +0100, Wookey wrote:
> > Quite. People are quite resistant to spoiling neat version numbers
> > with epochs, and no-one likes them, but they don't do any actual harm
> > (except sometimes break scripts and tools that forgot to allow for
> > them),
> 
> Oh, but they can cause actual harm. As has been mentioned on this
> list many times, epochs by design invalidate existing versioned
> relationships in both packaging fields (inside the distro (but in this
> case that does not look like a problem) and on custom local packages),
> and on tools/(maint)scripts comparing these versions. These can either
> cause letting versions that should not be installed through, or can
> cause version unsatisfiability.
> 
> There's also the problem that epochs are (currently) not included as
> part of the filenames.
> 
> They are also a common source of errors, due to people forgetting they
> need to add them in relationships (if you read package changelogs,
> this is a common-ish occurrence).

Ah, another one that I had forgotten (which I had in mind adding
explicitly to the FAQ), but I guess is a variant of the "them being
confusing" point.

Epochs make it way harder to understand the history of the archive.
When you are not familiar with a package and its history it might be
hard to tell what happened to it to require an epoch bump, where in
many cases this is not even documented in the changelog (and it gets
worse now with the trimmed changelogs), and you might need to dig
into that history (via BTS, or git, or mailing list threads) to know
for example whether a security issue affects old versions or not,
whether that package used to be a different source package, whether it
was due to an unnecessary epoch bump to revert a problematic version,
whether it was for a proper version-space reset, etc.


The fact that they are perceived as ugly, is a good thing, but it's
not the main reason they should be avoided, to me that's just a
materialization of their powerful and problematic nature. They indeed
have their place, but I still have the feeling people reach for epochs
too easily, because in general their addition _seems_ trivial (but not
its irreversible consequences).

Thanks,
Guillem

Re: Mandatory LC_ALL=C.UTF-8 during package building

[Guillem Jover]

Hi!

[ Mostly trying to clarify some of my earlier comments. ]

On Fri, 2024-06-07 at 17:20:29 +0100, Simon McVittie wrote:
> On Fri, 07 Jun 2024 at 14:32:14 +0200, Guillem Jover wrote:
> > I'm a non-native speaker, who has been involved
> > in l10n for a long time, while at the same time I've pretty much
> > always run my systems with either LANG=C.UTF-8 or before that LANG=C,
> > LC_CTYPE=ca_ES.UTF-8 and LC_COLLATE=ca_ES.UTF-8.
> 
> So diagnostic messages in your non-English language are so important to
> you that you ... set your locale environment variables to values that
> result in you seeing diagnostic messages in English instead? I'm not
> sure I understand the point you're making here :-)

Ah, sorry, I see how my sentence might not be obvious to fully
unpack. :)

I know enough people in my locale surroundings that either do not have
a good enough command of English for whom output messages by default in
English would be a significant barrier to entry, or people who while
having a good command of English still feel more comfortable (or just
prefer) output messages to be in their native locale (to reduce mental
load for example). I've set my locale to C.UTF-8 or variants (in most
of my devices), in most part as a locale immersion device (so that I
could improve my English skills), while at the same time I'd consider
myself an exception in my locale group. My involvement in l10n has been
to try to help those groups of people, in addition to help me retain
some usage of my native language, and as a side effect to spot weird
or wrong constructs I might make in English strings too, which tend
to become obvious once you try to translate them. :)

> If your point is that people-who-are-not-you place a higher value on
> having diagnostic messages come out in their non-English language than
> you personally do, then, yes, that's certainly a valid thing for those
> people to want.

More or less, the point I was trying to make was that while emitting
messages by default in English would not really affect me, I still think
it would be a significant problem (not just a preference) or a barrier
to entry for a big enough group of people.

> But I'm not sure that our current package set actually achieves that -
> increasingly many of our packages overwrite the locale with "C.UTF-8"
> in some layer of their build system, because they cannot guarantee that
> the locale they inherit from the environment is anything reasonable (in
> particular, it might be "C", which often breaks tools that want to work
> with non-ASCII filenames, inputs or outputs). In the enumeration from
> my earlier message, you want (1.), but increasingly, what you actually
> get is (2½.) instead, and that results in neither you nor Giole getting
> the results you would hope for.
> 
> The compromise that Alexandre suggested elsewhere in the thread -
> requiring the locale to be *something* UTF-8, but leaving it unspecified
> exactly which UTF-8 locale, so that a French-speaking developer can ask
> for fr_FR.UTF-8 and get their compiler warnings in French - seems like
> something that might actually give you what you want in more cases than
> the status quo does? If we mandate a UTF-8 locale, then stack layers like
> debhelper's meson plugin could probably stop forcing C.UTF-8.

Ideally, yes. I think the situation now is a bit better with the
recent dpkg uploads, but I'll expand in the thread from Alexandre's
suggestion.

> > we make lots of l10n work rather pointless
> 
> Surely only if that l10n work was done on tools that are only ever run
> from package builds, and never interactively? A lot of localization is
> done for end-user-facing tools (GUI, TUI or CLI) which are never relevant
> during a package build anyway.
> 
> Even for compilers and similar non-interactive development tools, if
> a French-speaking developer runs gcc in the fr_FR.UTF-8 locale during
> their upstream development, they'll still benefit from its warnings being
> localized into French, even if they would never see those same warnings
> during a Debian package build of the same software.
> 
> (Analogous: I similarly benefit from gcc having ANSI colour highlights
> in its output, even though my Debian package build logs don't have those.)

Sorry, right, my comment was specifically in the context of the dpkg
tooling (and surrounding scaffolding and helpers). If dpkg is always
forcing output messages in English from say dpkg-buildpackage, the are
going to be a set of tools that will pretty much never see any of
their output in localized form.

> > and if no one is running with different locales then l10n
> > bugs might easily creep in
> 
> If no one is running (their interactive sessions) with a particular
> locale, why do we even support that locale?

This comment was in the context where the tooling forces a specific
locale, so users cannot have the chance of using it even if they want.

Thanks,
Guillem

Re: Mandatory LC_ALL=C.UTF-8 during package building

[Guillem Jover]

Hi!

On Sat, 2024-07-06 at 13:13:48 +0200, Alexandre Detiste wrote:
> Le mar. 2 juil. 2024 à 14:37, Guillem Jover  a écrit :
> > On Tue, 2024-07-02 at 09:52:05 +0100, Simon McVittie wrote:
> > > On Tue, 02 Jul 2024 at 03:47:29 +0200, Guillem Jover wrote:
> > > > On Fri, 2024-06-07 at 15:40:07 +0200, Alexandre Detiste wrote:
> > > > > Maybe a compromise would be to at least mandate some UTF-8 locale.
> > > >
> > > > dpkg-buildpackage: Require an UTF-8 (or ASCII) locale when
> > > > building packages
> > >
> > > Allowing ASCII seems counterproductive: that puts us in the code path
> > > where various tools and runtimes (especially Python) will refuse to
> > > process or output anything outside the 0-127 range, which I believe is
> > > exactly the problem that debhelper aims to solve by using C.UTF-8 for
> > > some categories of package (in particular those that build with Meson).
> > >
> > > To get what Alexandre suggested, we'd need to allow UTF-8 but not allow
> > > ASCII (so for example fr_FR.UTF-8 or C.UTF-8 is fine, but in particular
> > > the C locale is not).
> >
> > But, I guess I can at least unconditionally set LC_CTYPE=C.UTF-8 when
> > using --sanitive-env, right away though.

I did something like that as part of dpkg 1.22.7, with commit:

  
https://git.dpkg.org/cgit/dpkg/dpkg.git/commit/?id=df60765ed4bc6640b788c796dd0c627d7714f807

Which should guarantee a UTF-8 codeset and stable sorting, while
preserving any translated output messages (and other locale settings).

> One thing that could be fixed quite quickly is fixing the few
> remaining official buildd workers that does not yet run with an UTF-8 locale.

Something I realized after adding the above change, is that sbuild has
been running dpkg-buildpackage with --sanitize-env for a while now,
which checking now I was told about at the time, but I either didn't
piece together its consequences or perhaps forgot that the sbuild
package is nowadays used in build daemons (instead of the old fork)
and then forgot. :) (BTW, not blaming josch! I think that change in
sbuild on its own makes sense, I guess I was just not expecting the
option to be used that way, and perhaps its documentation should have
somehow made it more clear. :)

I guess this is both good and "bad". It's good because now all build
daemons will have a guaranteed UTF-8 locale codeset already starting
with Debian trixie, as requested in this thread, and give us a more
uniform build environment. It's "bad" because part of the reason to
add this through a new --sanitize-env option was to make this behavior
and its guarantees opt-in, but if the official Debian builds are using
this, then it's in a way equivalent to having set this by default w/o
the option, but perhaps worse because people running local build will
not have the same environment (although it's going to be easy to
replicate by passing that option, but a bit harder when calling
debian/rules directly which we still support).

I'm not sure the current state is ideal, because we are back to
packages being able to rely on some stuff on build daemons, that are
not guaranteed by default for our supported build entry points, and if
the result of this is that we end up patching all dpkg-buildpackage
callers to pass --sanitize-env, then we could have as well simply
changed the default instead. I think a way forward could be to make
the sanitizing the default, and finally drop debian/rules as a
supported (user) build entry point, I had in mind re-proposing this
already, but the above kind of gives it more urgency, so I'll try to
do that soon.

This also means, I guess, that part of the previous freedom I thought
we had to modify the --sanitize-env behavior is kind of gone now (and
would be gone too if we move its behavior as the default one), and we
should apply similar care as if the default itself was being changed,
because it has the potential to break the archive (via build daemons).
I'm thinking that depending on the changes there, it might be better
to gate them via dpkg-build-api(7) levels. I should also document the
vendor specific behavior in some manual page, as it is currently
listed as unspecified "vendor specific".

> If one is unlucky the build will mysteriously fail.
> 
> Adding  export {LC_ALL|LANG|LC_CTYPE}=C.UTF-8
> in every single d/rules by fear of this seems overkill.

> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074586
> https://buildd.debian.org/status/package.php?p=xrayutilities

I implemented the attached patch (also on the next/req-utf8 branch) to
force a locale with a UTF-8 codeset, which would be a no-op now when
using --sanitize-env, but I didn't merge that for now, because I'm not
sure of the potenti

Bug#1080349: ITP: golang-github-victoriametrics-easyproto -- simple building blocks for protobuf marshaling and unmarshaling

[Guillem Jover]

Package: wnpp
Severity: wishlist
Owner: Guillem Jover 

* Package name: golang-github-victoriametrics-easyproto
  Version : 0.1.4-1
  Upstream Author : VictoriaMetrics
* URL : https://github.com/VictoriaMetrics/easyproto
* License : Apache-2.0
  Programming Lang: Go
  Description : simple building blocks for protobuf marshaling and 
unmarshaling

 This package provides simple building blocks for marshaling and unmarshaling
 of protobuf messages with proto3 encoding.
 .
 Features
 .
  * there is no need for protoc or go generate; just write simple
maintainable code for marshaling and unmarshaling protobuf messages.
  * does not increase your binary size by tens of megabytes unlike
traditional protoc-combiled code may do.
  * allows writing zero-alloc code for marshaling and unmarshaling of
arbitrary complex protobuf messages.
 .
 Restrictions
 .
  * It supports only proto3 encoding, e.g. it does not support proto2 encoding
features such as proto2 groups.
  * It does not provide helpers for marshaling and unmarshaling of well-known
types, since they are not used too much in practice.


This is a new dependency required by victori-metrics.

Thanks,
Guillem

Bug#1080351: ITP: golang-github-bboreham-go-loser -- Loser Tree data structure, for fast k-way merge

[Guillem Jover]

Package: wnpp
Severity: wishlist
Owner: Guillem Jover 

* Package name: golang-github-bboreham-go-loser
  Version : 0.0~git20230920.fcc2c21-1
  Upstream Author : Bryan Boreham
* URL : https://github.com/bboreham/go-loser
* License : Apache-2.0
  Programming Lang: Go
  Description : Loser Tree data structure, for fast k-way merge (library)

 This module provides support for a Loser Tree structure, which works for
 built-in types like int and string.
 .
 See (https://en.wikipedia.org/wiki/K-way_merge_algorithm#Tournament_Tree)
 for more details on the algorithm.


This package is needed by new versions of Prometheus and VictoriaMetrics.

Thanks,
Guillem

Bug#1080354: ITP: golang-opentelemetry-collector -- OpenTelemetry Collector (library)

[Guillem Jover]

Package: wnpp
Severity: wishlist
Owner: Guillem Jover 

* Package name: golang-opentelemetry-collector
  Version : 0.108.1-1
  Upstream Author : OpenTelemetry - CNCF
* URL : https://github.com/open-telemetry/opentelemetry-collector
* License : Apache-2.0
  Programming Lang: Go
  Description : OpenTelemetry Collector (library)

 The OpenTelemetry Collector offers a vendor-agnostic implementation on how
 to receive, process and export telemetry data. In addition, it removes the
 need to run, operate and maintain multiple agents/collectors in order to
 support open-source telemetry data formats (e.g. Jaeger, Prometheus, etc.)
 to multiple open-source or commercial back-ends.
 .
 Objectives:
 .
  * Usable: Reasonable default configuration, supports popular protocols,
runs and collects out of the box.
  * Performant: Highly stable and performant under varying loads and
configurations.
  * Observable: An exemplar of an observable service.
  * Extensible: Customizable without touching the core code.
  * Unified: Single codebase, deployable as an agent or collector with
support for traces, metrics and logs.


This package is required by new Prometheus and VictoriaMetrics releases.

Thanks,
Guillem

Bug#1080428: ITP: golang-github-go-viper-mapstructure -- decode generic map values into native Go structures and vice versa

[Guillem Jover]

Package: wnpp
Severity: wishlist
Owner: Guillem Jover 

* Package name: golang-github-go-viper-mapstructure
  Version : 2.1.0-1
  Upstream Author : Viper
* URL : https://github.com/go-viper/mapstructure
* License : Expat
  Programming Lang: Go
  Description : decode generic map values into native Go structures and 
vice versa

 mapstructure is a Go library for decoding generic map values to
 structures and vice versa, while providing helpful error handling.
 .
 This library is most useful when decoding values from some data stream
 (JSON, Gob, etc.) where you don't *quite* know the structure of the
 underlying data until you read a part of it. You can therefore read a
 map[string]interface{} and use this library to decode it into the proper
 underlying native Go structure.
 .
 Go offers fantastic standard libraries for decoding formats such as
 JSON. The standard method is to have a struct pre-created, and populate
 that struct from the bytes of the encoded format. This is great, but the
 problem is if you have configuration or an encoding that changes
 slightly depending on specific fields.
 .
 Perhaps we can't populate a specific structure without first reading the
 "type" field from the JSON. We could always do two passes over the
 decoding of the JSON (reading the "type" first, and the rest later).
 However, it is much simpler to just decode this into a
 map[string]interface{} structure, read the "type" key, then use
 something like this library to decode it into the proper structure.
 .
 This library is a blessed fork of github.com/mitchellh/mapstructure,
 which  has been archived by its upstream.
 See  https://github.com/mitchellh/mapstructure/issues/349.
 .
 You can migrate to this package by changing your import paths in your Go
 files to github.com/go-viper/mapstructure/v2. The API is the same, so you
 don't need to change anything else.


This package is a dependency for golang-opentelemetry-collector.

Thanks,
Guillem

Bug#1080429: ITP: golang-github-mostynb-go-grpc-compression -- Go gRPC encoding wrappers for compression algorithms missing from google.golang.org/grpc

[Guillem Jover]

Package: wnpp
Severity: wishlist
Owner: Guillem Jover 

* Package name: golang-github-mostynb-go-grpc-compression
  Version : 1.2.3-1
  Upstream Author : Mostyn Bramley-Moore
* URL : https://github.com/mostynb/go-grpc-compression
* License : Apache-2.0
  Programming Lang: Go
  Description : Go gRPC encoding wrappers for compression algorithms 
missing from google.golang.org/grpc

 This respository contains Go gRPC encoding wrappers for some useful
 compression algorithms that are not available in google.golang.org/grpc.
 .
  * github.com/mostynb/go-grpc-compression/lz4
- using (https://github.com/pierrec/lz4)
  * github.com/mostynb/go-grpc-compression/snappy
- using (https://github.com/golang/snappy)
  * github.com/mostynb/go-grpc-compression/zstd
- using (https://github.com/klauspost/compress/tree/master/zstd)
 .
 The following algorithms also have experimental implementations, which
 have not been tested as much as those above. These may be changed
 significantly, or even removed from this library at a future point.
 .
  * github.com/mostynb/go-grpc-compression/experimental/klauspost_snappy
- using (https://github.com/klauspost/compress/tree/master/s2)
  in snappy compatibility mode
  * github.com/mostynb/go-grpc-compression/experimental/s2
- using (https://github.com/klauspost/compress/tree/master/s2)
 .
 Importing any of the packages above will override any previously
 registered encoders with the same name. If you would prefer imports to
 only register the encoder if there is no previously registered encoder
 with the same name, then you should instead import one of the following
 packages:
 .
  * github.com/mostynb/go-grpc-compression/nonclobbering/lz4
  * github.com/mostynb/go-grpc-compression/nonclobbering/snappy
  * github.com/mostynb/go-grpc-compression/nonclobbering/zstd
  * 
github.com/mostynb/go-grpc-compression/nonclobbering/experimental/klauspost_snappy
  * github.com/mostynb/go-grpc-compression/nonclobbering/experimental/s2


This package is a dependency for golang-opentelemetry-collector.

Thanks,
Guillem

Re: Should OpenSSL/ libssl3 depend on brotli?

[Guillem Jover]

Hi!

On Sat, 2024-09-07 at 00:12:58 +0200, Sebastian Andrzej Siewior wrote:
> Is it okay for libssl3 do depend on libbrotli? It would increase minimal
> installs by ~900KiB on amd64.
> tl;dr

> coreutils build-depends on libssl-dev which makes libssl essential.
> libssl already supports compression via libz and zstd. Both libraries
> are already pulled in by dpkg so letting libssl depend on them did not
> change much.

Perhaps an alternative option would be to switch coreutils to use
libmd instead of libcrypto? It seems to contain all the needed algos
that are currently used by coreutils, and it is already part of the
pseudo-essential set via dpkg and passwd via libbsd. This would reduce
the pseudo-essential set size, and also free you from this constraint
when deciding whether to include brotli (or future new dependencies).

Thanks,
Guillem

Re: Question about library package splitting

[Guillem Jover]

Hi!

On Fri, 2024-09-06 at 11:32:55 +0200, Ervin Hegedüs wrote:
> Here comes the problem: libmodsecurity3 has two types of collection stores:
> in-memory and LMDB. It's VERY important: you MUST decide the type of
> choosed backend in compilation time, later you can't change it in runtime!

I think ideally upstream would be modified so that this decision can
be made somehow at runtime? Then most of the problem presented goes
away.

> If you choose the in-memory storage, you will lose your stored data when
> you restart the web server, but it does not need any dependency.

I initially thought the libmodsecurity library would contain minimal
to no dependencies, where avoiding the lmdb one would then make sense,
but checking now, it has lots of dependencies, so this does not seem
like a very strong argument.

> I don't want to force users to use LMDB, rather I prefer to deliver two
> library packages: one with in-memory and one with LMDB.

See above about making this a run-time selection. But if this is not
feasible or upstream does not want to go that way, the problem I see
is that selecting how the library behaves then becomes a system global
binary selection of behavior, depending on what implementation is
installed. Also this does not seem very user friendly, as shared
libraries tend to be just dependencies one does not need to care of,
as these get pulled automatically by whatever might need them.

I guess though there is some small precedent that I know of in Debian
with for example the ffmpeg libraries such as libavcodeN and
libavcodec-extraN and similar, or the multiple libblas.so.N and
liblapack.so.N implementation providers.

> I couldn't find any guideline in Debian packaging documentation but found
> the libcurl-dev as a pattern.

I think this is somewhat different, as these are co-installable, and
whether to use one or the other is selected by the package using it
at build time, not by the user.

> Based on that I created a simple test package to emulate the behavior
> (compiling libmodsecurity takes more time - this package is very simple and
> anyone can build few seconds):
> 
> https://salsa.debian.org/airween/testlib/

> Before I send the modified package structure, I would like to ask few
> questions:

Even with the above, if you still want to go in this direction:

> * in this case the API hides the differences between two solutions; Is it
> enough to make one -dev package and two different runtime packages?

Given that this seems to be an implementation detail and supposedly
neither the API nor ABI change, and this seems to be intended as a
mechanism for the *user* to select the implementation, and not the
package linking against it to select it, then I think a single -dev
package would be better.

In this case how to allow switching implementations can be done either
via Provides+Conflicts+Replaces; or Conflicts+Replaces and then making
the symbols or shlibs file generate dependencies on both library as
alternatives such as «libfoo | libfoo-lmdb».

> * are the names acceptable "libmodsecurity3t64" and
> "libmodsecurity3-lmdbt64"?

The t64 suffix for the lmdb one should not be needed.

> * based on the test package, are there any comments or advice to be
> considered?

Some passing and non-exhaustive packaging comments:

- autotools should support out-of-tree builds, so there should be no
  need to copy the source tree into a subdirectory, just creating the
  subdir and calling ../configure should do.
- you can use execute_after_ or execute_before_, instead of duplicating
  the dh calls.
- you do not need the .dirs fragment files, as the .install ones
  should take care of creating the needed directories.
- debian/compat is deprecated, you can use debhelper-compat (= 13)
  instead.
- if you are going to support omitting specific packages per
  build-profile, then you should add a Build-Profile field to the
  relevant binary packages, so that they do not get built at all,
  and then also annotate the lmdb build dependency, although this all
  seems a bit excessive?

Thanks,
Guillem

Re: svn.debian.org

[Guillem Jover]

Hi,

On Sat, Nov 06, 2004 at 08:51:03AM +0100, Osamu Aoki wrote:
> It took me a while to get SVN access to some projects at svn.debian.org.
> 
> It will be nice if someone can update web page contents of
> svn.debian.org.

Done.

> Of couse, svn+ssh with absolute path /svn/pkg-ime/ worked but this is
> not so obvious from this svn.debian.org.  But short message stating
> svn+ssh requires prepending of /svn/ or change all the listed URL to be
> with /svn/ may be more useful.  (Assuming permission issues are gone and
> symlink svn --> .  works)

Oh didn't know there was a symlink now, it was added later than when I
automated the page, so I didn't put that url initially.

thanks,
guillem

Re: Bug#280534: ITP: kernel-patch-linuxabi -- Runs programs written for different Unix's under Linux

[Guillem Jover]

Hi Russell,

On Wed, Nov 10, 2004 at 11:28:25AM +1000, [EMAIL PROTECTED] wrote:
> Package: wnpp
> Severity: wishlist
> 
> * Package name: kernel-patch-linuxabi
>   Version : 20040724
>   Upstream Author : Various
> * URL : 
> http://www.lubemobile.com.au/ras/debian/sarge/kernel-patch-linuxabi

The URL is meant to point to the upstream website or download area.
I've seen you've done that with two other ITPs.

regards,
guillem

Re: State of gcc 2.95 use in Debian unstable

[Guillem Jover]

On Tue, Nov 15, 2005 at 06:00:06PM +0100, Thiemo Seufer wrote:
> while preparing an upload of gcc-2.95 which fixes its worst problems
> I wondered how many users of it are actually left. 9 packages in
> unstable still declare a build dependency on gcc-2.95 or g++-2.95,
> this makes it IMHO a plausible release goal to get rid of 2.95
> maintenance for etch.

> Obsolete according to #debian-hurd, no request for removal filed yet:
> 
>GNU Hurd Maintainers 
>   gnumach1Build-Depends: gcc-2.95

I'll be asking for its removal this week.

> Openfirmware emulator/replacement(?), powerpc specific, needs update:
> 
>Guillem Jover <[EMAIL PROTECTED]>
>   openhackwareBuild-Depends-Indep: gcc-2.95

I'll allocate some time to upgrade this to latest gcc.

thanks,
guillem


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

Requesting pistachio removal in a week

[Guillem Jover]

Hi,

Initially I packaged pistachio because it was supposed to be the next
microkernel to be used by the Hurd. That's questionable now. Also the
package suffers some problems that I don't want to spend time fixing,
like it not building on all supposedly supported arches, upstream not
being much active externally, although they develop on internal repos
which cannot be pushed outside due to research and paper publications
or master thesis.

I'll be requesting its removal in one week, if someone wants to adopt
it please notify me and upload directly.

The package description is:

 L4Ka::Pistachio is built from ground up incorporating the research
 results of the last seven years of microkernel and multi-server
 research. The code is written in C++ with a strong focus on performance
 and portability.

regards,
guillem


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

Bug#303488: ITP: openhackware -- OpenFirmware emulator

[Guillem Jover]

Package: wnpp
Severity: wishlist
Owner: Guillem Jover <[EMAIL PROTECTED]>

* Package name: openhackware
  Version : 0.4
  Upstream Author : Jocelyn Mayer <[EMAIL PROTECTED]>
* URL : <http://perso.magic.fr/l_indien/OpenHackWare/>
* License : GPL
  Description : OpenFirmware emulator

 OpenHackWare is an OpenFirmware emulator intended to be used on PowerPC
 machines. It is not a real OpenFirmware as it knows nothing about Forth.
 It emulates the OpenFirmare boot time interface as well as the RTAS
 interface. It also emulates some known "interpret" strings, to make it
 able to launch known OSes.

regards,
guillem


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

Bug#303489: ITP: proll -- JavaStation PROM 2.x compatible replacement

[Guillem Jover]

Package: wnpp
Owner: Guillem Jover <[EMAIL PROTECTED]>
Severity: wishlist

* Package name: proll
  Version : 18
  Upstream Author : Pete A. Zaitcev <[EMAIL PROTECTED]>
* URL : <http://people.redhat.com/zaitcev/linux/>
* License : GPL
  Description : JavaStation PROM 2.x compatible replacement

 Proll is a 2.x PROM compatible replacement for JavaStations, that can
 be used on emulators such as Qemu or to make possible booting Linux, as
 later 3.x series of the PROMs are unable to boot it.
 .
 JavaStations came with two different PROMs installed in them. Version 2.30
 shipped with the earliest Mr. Coffee models, and was updated by latter
 versions of the Sun Netra J software environment to 3.11. Krups and
 Espresso came with 3.x versions of the PROM by default.

regards,
guillem


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

Re: Bug#317430: ITP: apt-history -- logs the changes when installing

[Guillem Jover]

Hi,

On Fri, Jul 08, 2005 at 02:03:32PM +0200, Nico Golde wrote:
> * Package name: apt-history
>   Version : 0.1
>   Upstream Author : Vittorio Palmisano <[EMAIL PROTECTED]>
> * URL : http://redclay.altervista.org/archivio/python/apt-history/
> * License : GPL
>   Description : logs the changes when installing
> 
> apt-history logs the changes of /var/lib/dpkg/status when installing,
> removing, upgrading packages with apt-get

Does this package makes sense now that dpkg logs into
/var/log/dpkg.log?

regards,
guillem


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

Re: Bug#317430: ITP: apt-history -- logs the changes when installing

[Guillem Jover]

On Sat, Jul 09, 2005 at 09:00:19PM +0200, Goswin von Brederlow wrote:
> I guess you would have to divert apt-get and aptitude for that and log
> the invocations.
> 
> Actualy with aptitude taking the list of non automatic packages should
> give you exactly the install list.

aptitude has had such kind of log for a long time:

/var/log/aptitude

regards,
guillem


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

Re: Packaging software which does not use autotools

[Guillem Jover]

On Mon, 2006-08-14 at 23:10:04 +0200, Michael Rasmussen wrote:
> On 2006-08-14 22:33:49, Hendrik Sattler wrote:
> > Do you plan to support other system than linux in a fork? If no, there
> > is

> Well, the software is already prepared to support *BSD, Solaris and
> Linux, but I only intent to support Linux - the only thing I use on a
> day to day basis.

If the current build system supports those arches, and yours does not,
it seems a step back. Also consider that we have non-Linux based Debian
ports as well, so if it does not build on those, bugs with patches will
have to be submitted for the package...

regards,
guillem


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

Re: Packaging software which does not use autotools

[Guillem Jover]

As complement to what Wouter and Michael have replied...

On Sun, 2006-08-20 at 23:24:49 +0200, Michael Rasmussen wrote:
> What I have made is a generic package which just does not concerns
> itself with other arches than for GNU/Linux. If people wants to compile
> for *BSD or Solaris they can get the source tar-ball upstream. Also my
> package does not take into considerations to build clients for Windows
> or Mac OSX.

I'm not talking about upstream but Debian ports (see below). Also you
said you are taking over upstream, and reducing its portability seems
as well a step back...

> In my opinion it is a reasonable choice since the purpose of the
> package is to create deb-packages?

I don't think so.

> Which non-linux versions are you referring to?

Debian GNU/Hurd .
Debian GNU/kFreeBSD .

> If the compile with option -std=c99 and -pedantic showing no warnings
> or errors the ought to be able to compile on any arch with gcc-4.1.
> Only dependency for building it is libc6.

It might, but it does not have to. For example it could be including
header files from  or , and if the system now is
assumed to be Linux blindly then it will fail.

We might end up faster if you provide the source packages somewhere so
we can take a look.

regards,
guillem


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

Re: inet-superserver virtual package

[Guillem Jover]

On Mon, 2006-08-28 at 12:27:43 +0200, Marco d'Itri wrote:
> On Aug 28, Guillem Jover wrote:
> > Just yesterday night dato raised the issue on #d-release, and I was
> > telling about the virtual package, and that we could move to it now,
> > and worry later about a possible transition to that new update-inetd
> > (if it happens to exist some day), aj was fine with that.

> OK, but then let's do it right.
> The idea is to move update-inetd from netbase to each one of the inetd
> packages (openbsd-inetd, inetutils-inetd, rlinetd, xinetd), which will
> provide the inet-superserver virtual package and depend on a version of
> netbase which does not have update-inetd (is a Replaces needed too?).

I'm not convinced that duplicating update-inetd in most of the
inetd providing packages is a good idea, even if this would allow
xinetd to be able to replace a normal inetd easily. I'd prefer that the
odd cases override update-inetd, via a custom script that gets called
if present from u-i or replace it or whatever.

Also in case the mythical rewrite happens it will be easier to
coordinate just one instance than all of them, or to sync them if
people start fixing their instances.

> netbase then will temporarily depend on inet-superserver to allow smooth
> upgrades until the other packages will switch to a dependency on the
> virtual package[1][2].

Do you mean only a depedency to the virtual package, w/o a real one?

> [2] At the same point we should argue about the tcpd dependency too,
> currently most packages rely on netbase pulling it. I see arguments for
> both having the inetd depend on it if needed (some directly use libwrap)
> and having the server packages depend on it if needed (some do not
> actually use it). I favour the first option, BTW.

Yes we could do that at the same time. And I prefer the first option
as well.

regards,
guillem


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

Re: inet-superserver virtual package

[Guillem Jover]

On Wed, 2006-08-30 at 14:22:07 +0200, Marco d'Itri wrote:
> On Aug 30, Guillem Jover wrote:
> > I'm not convinced that duplicating update-inetd in most of the
> > inetd providing packages is a good idea, even if this would allow
> > xinetd to be able to replace a normal inetd easily. I'd prefer that the
> > odd cases override update-inetd, via a custom script that gets called
> > if present from u-i or replace it or whatever.

> I can't see why this would be better.

Well, if we want to be able to replace any of the inetd with any other
one we need a neutral format (as someone else also said in the other
thread), this neutral format could be the existing inetd.conf, because
the other packages should support already converting from it, so the
only thing needed would be to add this hook support to update-inetd for
the specific cases where the application does not read the "neutral"
format directly. Also because this hook support should imply minimal
code, just passing the whole arguments to it if the file is present.

> > Also in case the mythical rewrite happens it will be easier to
> > coordinate just one instance than all of them, or to sync them if
> > people start fixing their instances.

> I do not believe this. xinetd and rlinetd need their own versions of
> the program anyway, so at best it could be shared by openbsd-inetd and
> inetutils-inetd. Coordinating the changes in a 13 KB code base among
> 2 or 4 maintainers is easy.

This is a fair point, thought there would be way more of those. But
consider the above, and if the others have to support the "neutral"
format, we may as well share the code, for all of them.

> > > netbase then will temporarily depend on inet-superserver to allow smooth
> > > upgrades until the other packages will switch to a dependency on the
> > > virtual package[1][2].

> > Do you mean only a depedency to the virtual package, w/o a real one?

> No.

Then I agree here with Roger, that spreading this dependency all over
the place makes future changes difficult innecessarily, even if you
can consider me biased I'd think the same if the package for this
depedency was going to be inetutils-inetd. ;)

regards,
guillem


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

Re: ITP: lsjk -- development files for arbitrary-precision numeric evaluation

[Guillem Jover]

Hi,

On Fri, 2006-09-01 at 09:43:03 +0200, Gürkan Sengün wrote:
> Package: wnpp
> Severity: wishlist
> 
> * Package name: lsjk (source package name)

Could you please use the X-Debbugs-CC header when sending the ITPs
instead of CCing directly debian-devel? Otherwise we don't get to see
the bug number and the replies do not get recorded there, if people do
not make the effort (which they would not need to do) to search the
bug number in the BTS or the wnpp pages.

thanks,
guillem


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

Re: ITP: bzr-plugin-webserve -- web interface for bazaar-ng

[Guillem Jover]

Hi,

On Mon, 2006-09-11 at 16:05:55 +0200, Arnaud Fontaine wrote:
> Package: wnpp
> Owner: Arnaud Fontaine <[EMAIL PROTECTED]>
> Severity: wishlist
> 
> * Package name: bzr-plugin-webserve
>   Version : web interface for bazaar-ng
>   Upstream Author : Goffredo Baroncelli <[EMAIL PROTECTED]>
> * URL : 
> http://goffredo-baroncelli.homelinux.net/bazaar/bazaar-webserve
> * License : GPL
>   Programming Lang: Python
>   Description : web interface for bazaar-ng
> 
> Webserve is a web interface to bazaar-ng (aka bzr) repositories. This is
> the porting of the mercurial web  interface to bazaar-ng. It can be used
> as a standalone server or as a cgi script with apache for example.

If you are not going to use reportbug to file ITPs, could you then please
use the X-Debbugs-CC field as explained in "Sending copies of bug reports
to other addresses" [0]?

[0] 

thanks,
guillem


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

Re: (proposed) Mass bug fil ing for debcon f "abuse" by using low|medium priority debconf notes?

[Guillem Jover]

On Thu, 2006-09-14 at 19:41:53 +0200, Christian Perrier wrote:
> As a conclusion and combining both, I would really like to unsderstand
> why so many fellow developers insist on using LOW priority NOTES in
> their debconf templates and use them in maintainer scripts.

> Packages with low priority debconf notes:
> -----
> 
> Guillem Jover <[EMAIL PROTECTED]>
>   fbset -- config:16 fbset/create_framebuffer_devices

As Mark Brown, I did that following the policy. I don't have any
problem removing it, but would be nice to get the policy fixed.

>   xfstt -- config:13 xfstt/default_port_changed

Fixed in incoming.

> Packages with medium priority debconf notes:
> --------
> 
> Guillem Jover <[EMAIL PROTECTED]>
>   bochs -- config:10 bochs/bochsrc

Will be fixed with next upload.

regards,
guillem


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

Re: Volunteers needed to experiment with tags in debian/control

[Guillem Jover]

On Thu, 2006-09-07 at 20:27:26 +0200, Enrico Zini wrote:
> I would like to experiment with a little new plan for having tags flow
> again from the web submissions[1] to the Packages file.

> The plan goes as this:
> 
>  0) Download http://people.debian.org/~enrico/2006-09/debtags-updatecontrol
>  1) Edit debian/control adding an empty "Tag:" field for every *binary*
> package
>  2) In your package root directory, run debtags-updatecontrol.
> The script will check debtags.alioth.debian.org for new tags, and it
> will guide you through reviewing all the differences.
>  3) Have a look at debian/control: you will find that the Tag: field has
> been updated with the new tags
>  4) Upload the package: I will notice that it has the Tag: field and
> I'll know that I don't have to do manual review of tags for it.

Not really, as dpkg-gencontrol will strip unknown fields. You'll need
"XB-Tag:". But I'll be adding support into dpkg-dev for the Tag field
once we branch it for etch+1 (which may go to experimental for a while).

> The script is smart enough to ask you to review only the differences
> between the data on Alioth and the data in your package.  If you reject
> changes from Alioth, it will also offer you to mail the patch back to
> it.

I've not sent the diff, because I wanted to see if dak reports the
diff when overriding... (I'll send it later).

> [...]. What I need is to have some packages with a Tag: field in the
> control file, so that I can implement and test the final part of the
> plan, which consists in updating the override file to let your tags
> through.

Now you have xfstt in incoming with such field. =)
All my other packages will aquire the field as soon as a new upload
happens (they have that locally already).

regards,
guillem


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

Re: new mplayer

[Guillem Jover]

Hi,

On Tue, 2006-09-26 at 01:46:42 +0200, Luca Capello wrote:
> FWIW, I cannot build it in a clean and updated-to-latest-sid pbuilder
> (complete script available on request, 10K gzipped):

> Script started on Tue 26 Sep 2006 01:38:35 AM CEST
> [EMAIL PROTECTED]:~/test$ sudo pbuilder build mplayer_1.0~rc1~svn19921.dsc
> [...]
> Checking for DirectFB ... /tmp/mplayer-conf-24598-4424.c:1:30: error: 
> directfb_version.h: No such file or directory
> no (failed to get version)
> [...]

I fixed this the other day, and forgot about it, here's the patch.
I've switched that test completely to pkg-config, hope it's not a
problem.

regards,
guillem
Index: configure
===
--- configure   (revision 20007)
+++ configure   (working copy)
@@ -3701,52 +3701,39 @@
 echocheck "DirectFB"
 if test "$_directfb" = auto ; then
   _directfb=no
-  if linux && test -c /dev/fb0; then
+  if pkg-config --exists 'directfb' ; then
 cat > $TMPC <
 int main(void) { IDirectFB *foo; DirectFBInit(0,0); return 0; }
 EOF
-  for _inc_tmp in "" -I/usr/local/include/directfb \
-  -I/usr/include/directfb -I/usr/local/include -I/usr/include; do
-cc_check $_inc_tmp -ldirectfb && _directfb=yes && \
-  _inc_extra="$_inc_extra $_inc_tmp" && break
-  done
+cc_check `pkg-config --libs --cflags directfb` && _directfb=yes
   fi
 fi
 
 if test "$_directfb" = yes; then
-  cat > $TMPC << EOF
-#include 
-int
-dfb_ver = DIRECTFB_MAJOR_VERSION DIRECTFB_MINOR_VERSION DIRECTFB_MICRO_VERSION
-;
-EOF
-  if $_cc -E $TMPC $_inc_extra > "$TMPO"; then
-_directfb_version=`sed -n 's/^dfb_ver[^1-9]*\(.*\)/\1/p' "$TMPO" | tr -d 
'() '`
-_def_directfb_version="#define DIRECTFBVERSION $_directfb_version"
-if test "$_directfb_version" -ge 913; then
-   _res_comment="$_directfb_version"
-else
-_def_directfb_version='#undef DIRECTFBVERSION'
-   _directfb=no
-   _res_comment="version >=0.9.13 required"
-fi
+  _directfb_version=`pkg-config --modversion directfb`
+  _directfb_version_c=`echo $_directfb_version | sed 's/^0*//' | tr -d '. '`
+  _def_directfb_version="#define DIRECTFBVERSION $_directfb_version_c"
+  if pkg-config --atleast-version='0.9.13' directfb ; then
+_res_comment="$_directfb_version"
   else
+_def_directfb_version='#undef DIRECTFBVERSION'
 _directfb=no
-_res_comment="failed to get version"
+_res_comment="version >=0.9.13 required"
   fi
 fi
 echores "$_directfb"
 
 if test "$_directfb" = yes ; then
   _def_directfb='#define HAVE_DIRECTFB 1'
-  if test "$_directfb_version" -ge 913; then
+  if pkg-config --atleast-version='0.9.13' directfb ; then
 _vosrc="$_vosrc vo_directfb2.c"
 _vomodules="directfb $_vomodules"
-_ld_directfb='-ldirectfb'
+_ld_directfb="`pkg-config --libs directfb`"
+_inc_extra="$_inc_extra `pkg-config --cflags directfb`"
   fi
 
-  if test "$_directfb_version" -ge 915; then
+  if pkg-config --atleast-version='0.9.15' directfb ; then
 _vosrc="$_vosrc vo_dfbmga.c"
 _vomodules="dfbmga $_vomodules"
   fi

Re: Bug#396611: ITP: mach -- make a chroot of a rpm-based distribution

[Guillem Jover]

On Wed, 2006-11-01 at 19:00:03 +0100, Loïc Minier wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Loic Minier <[EMAIL PROTECTED]>
> 
> * Package name: mach
>   Version : 0.9.0.2

It's unfortunate that they chose the same name as the microkernel.

regards,
guillem


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

Re: update-inetd

[Guillem Jover]

Hi,

On Thu, 2007-01-11 at 13:40:21 +1100, Brian May wrote:
> We really need a constant way of dealing with this in package updates.
> 
> It seems to boil down to:
> 
> * should packages disable inetd config entries on removal and in
> preparation for upgrade, and then reenable the entries after upgrade
> is complete?

I agree with Andreas, if you don't have to change the current entry I
don't see the point in enabling and disabling it. And I'm removing the
entries on package removal.

> * what about entries that should be disabled by default? That is the
> maintainer has decided the majority of users will not need it?

I'm installing entries disabled by default, and although my current
approach feels a bit dirty, seems to work. For example the snippets
for inetutils-telnetd:

,--- postinst 
if [ "$1" = "configure" ]; then
  if [ -x /usr/sbin/update-inetd ]; then
update-inetd --group STANDARD \
  --add "## 
telnet\tstream\ttcp\tnowait\troot\t/usr/sbin/telnetd\ttelnetd"
  fi
fi
` postinst 

,--- postrm 
if [ "$1" = "remove" ]; then
  if [ -x /usr/sbin/update-inetd ]; then
update-inetd --group STANDARD --remove '^(## |)telnet'
  fi
fi
`--- postrm 

Arguably this cases should be handled by update-inetd, but we know it
needs some fixing.

Hmm now looking at this, I should be using which instead of the full
path for update-inetd...

regards,
guillem


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

Re: RFC: Better portability for package maintainers

[Guillem Jover]

On Sun, 2006-05-21 at 09:44:50 -0700, Erast Benson wrote:
> because non-glibc Debian architectures does exists (i.e.
> FreeBSD,Solaris,Darwin), and it is time to consider them and accept
> their existence. Those core architectures are open sourced and their
> communities will only grow over time. It is not like they will
> disappear, that means Debian must adjust to the new fact of life: "we
> have more than one major OS totally open-sourced at its core".

There's no such thing as a non-glibc FreeBSD port for Debian for years
now. The only one maintained and in good shape is GNU/kFreeBSD (based
on glibc).

regards,
guillem


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

Re: Bug#363486: dpkg: [update-alternatives] New categories for: WORD, EXCEL, MEDIA-PLAYER etc.

[Guillem Jover]

On Wed, 2006-06-14 at 03:06:09 +0300, Jari Aalto+mail.linux wrote:
> I don't see real obstacle here. Granted that the alternatives system
> should be extended to look for
> 
> $HOME/debian/alternatives
> 
> Before checking
> 
> /etc/laternatives
> 
> Perhaps I should file a wishlist for it.

Please don't, we already have several of those...

regards,
guillem


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

Re: Bug#374029: Fixing inconsisten and unusefull Build-Depends/Conflicts definition

[Guillem Jover]

On Fri, 2006-06-16 at 23:10:36 +0200, Goswin Brederlow wrote:
> Package: debian-policy
> Severity: normal

> [Side note: Buildds/dpkg-buildpackage has no robust way of telling if
> the optional build-arch field exists and must call build. This is
> wastefull for both build dependencies and build time.]

I've a counter-proposal. ;) Make dpkg source v2.0 (Wig And Pen) format
require build-arch and build-indep.

> Why is this proposal better than others that have failed before?
> 
> - non disruptive: Current buildd behaviour will continue to build all
>   existing packages.

Ditto.

> - Packages will not instantly have RC bugs.

Ditto.

> - Simple to implement.
>   + Trivial change in dpkg for the new field.
>   + dpkg-checkbuilddeps has to parse 3 fields (2 with -B option)
> instead of 2 (1).
>   + sbuild, same change
>   + Simple change for 'apt-get build-dep'

Those changes will not be needed.

> - Buildds/dpkg-buildpackage can use the build-arch target
>   + reduces Build-Depends field and install time of same
>   + build-indep is no longer called, reduces compile time and disk
> space

Only will need changes in dpkg-buildpackage.

> - Build-Depends/Conflicts-Indep becomes usefull, build-indep becomes
>   usefull

Ditto.

regards,
guillem


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

Re: Bug#200163: ITP: png2ico -- command-line PNG to ICO converter

[Guillem Jover]

Hi,

On Sat, Jul 05, 2003 at 08:45:53PM +0200, martin f krafft wrote:
> * Package name: png2ico
>   Version : 20021208
>   Upstream Author : Matthias Benkmann <[EMAIL PROTECTED]>
> * URL : http://www.winterdrache.de/freeware/png2ico/
> * License : GPL
>   Description : command-line PNG to ICO converter
> 
> Converts PNG files to Windows icon resource files. If you're looking
> for a program to create a favicon.ico for your website, look no
> further. If you need instructions or don't even know what a favicon
> is, check out my short tutorial on how to create and install
> a favicon.ico.

What about icoutils ?

regards,
guillem

Re: Format of Release file and tools to create

[Guillem Jover]

Hi,

On Wed, Sep 24, 2003 at 08:39:06PM +, [EMAIL PROTECTED] wrote:
> where can I find the "official" definition for the Release
> file (http://ftp.us.debian.org/debian/dists/sarge/Release),
> e.g. a BNF or an informal description?
> 
> Which is the tool (of choice) to create the files?
> 
> How are the lines with the md5sums created?

The script is called ziyi is part of dak and can be found at:

  

regards,
guillem

Re: architecture alias and disto rebuild

[Guillem Jover]

Hi,

On Tue, Sep 13, 2005 at 11:58:40AM +0200, Adeodato Simó wrote:
> * Bill Allombert [Mon, 12 Sep 2005 17:39:36 +0200]:

> > So I propose a alternate solution:
> 
> > If the distro foobar rebuild packages on i386, they could use
> > i386foobar as architecture name instead of i386, this way every
> > package they rebuild will be clearly marked as such. 
> 
> > Of course, if foobar want to allow regular Debian package to be installed,
> > they can just patch dpkg so that it accept both kind of package.
> 
> > The morale of the story is: since we have now comprehensive plateform
> > handling with CPU-SYSTEM, why not go a little farther and add a BUILDER
> > field with the suitable logic in dpkg so that it allow to install
> > packages from any builder by default ?
> 
>   This would be a gross hack, and I don't see why people who don't
>   bother to use a simple, clean and tested mechanism to mark rebuilds
>   (namely, dch -i) would go and use this other yet-to-be-implemented
>   one.

I agree with Adeodato that this "solution" is a gross hack, but I'd
rather start using something like dpkg-sig over the .deb files, so you
would be able to check from where does that specific .deb file come
from, be it Debian official or a deriviative, etc, w/o having to
modify the sources.

regards,
guillem


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

Re: Build-Depend'ing on libasound2-dev just for Linux

[Guillem Jover]

Hi,

On Fri, Sep 16, 2005 at 09:09:25AM +0200, Josselin Mouette wrote:
> Le vendredi 16 septembre 2005 à 00:33 +0200, Aurelien Jarno a écrit :
> > It is maybe a crazy idea, but it is the only one that work. What you 
> > suggest simply doesn't work, as not+linux is a provided package, and the 
> > autobuilders are not able to see it. In short a package with such a 
> > build-dependency will FTBFS on non linux architectures, if built by an 
> > autobuilder.
> 
> In this case, it is enough to do something like:
> Build-Depends: type-handling, libasound2-dev | not+linux-gnu

No, that's too late, the Build-Depends are analyzed before installing
them. You'd need some kind of ugly Build-PreDepends or similar.

So type-handling is broken, do not use it. We (the GNU/kFreeBSD team)
have adopted it and will push for its removal once dpkg gets the
needed functionality.

regards,
guillem


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

Proposal: Start wrapping source control file fields

[Guillem Jover]

Hi,

A while ago bug 90989 was submitted, it was asking to extend the
definition of source control file fields to be all (physical not
logical) multi-line. I think it makes sense as we are supposedly
using RFC822, and more given some really long and obscene fields
in packages from d-i or xorg.

As debian-policy will not allow this kind of change without
demonstrated wide use, I'll start wrapping source control fields
on new uploads of all my packages. I did that pre-sarge, but
reverted just before release to not introduce possible delays
(although nothing broke during that period), and when lintian
started giving errors about that.

I will not set a lintian override so it's easy to track down,
be it to revert or to be able to see how wide spread it has got.

So please speak now if you have anything against this.

regards,
guillem


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

Bug#461985: ITP: libbsd -- BSD compatibility library

[Guillem Jover]

Package: wnpp
Severity: wishlist
Owner: Guillem Jover <[EMAIL PROTECTED]>

* Package name: libbsd
  Version : 0.0
  Upstream Author : The FreeBSD project
* URL : http://www.freebsd.org/
* License : BSD
  Programming Lang: C
  Description : BSD compatibility library


This library provides some functions available on FreeBSD's libc but
not on glibc. This devel package also includes some queue macro
definitions not present on includes from glibc.


-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.23.12-zulo (PREEMPT)
Locale: LANG=C, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



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

Re: Wrong Architecture for openhackware

[Guillem Jover]

tags 339870 wontfix
thanks

Hi,

On Sat, 2008-01-12 at 18:47:53 +0100, Roland Stigge wrote:
> Debian Bug Tracking System wrote:
> >* Error out if the toolchain used to build is not powerpc-linux-gnu.
> >  (Closes: #322300, #339870)
> 
> Again, I don't agree here (backed by p2): The package is wrong if it
> asserts that it's "Architecture: all". It contains powerpc specific
> stuff and can only be built on (i.e. for) that architecture. Therefore,
> it should be "Architecture: powerpc".

The only relevant part here is that it provides ppc binaries, the fact
that it needs a ppc toolchain is not, I'd say, it's an arch:all package
after all. Take vgabios as a similar example, it can be built anywhere
(because it uses bcc and bin86), it's an arch:all package that provides
i386 binaries, but yet it cannot be used on real i386 hardware, so
making it arch:any would make it a bit useless, you could only use it
under i386 to emulate i386 systems.

Also those are firmwares, you will not be able to run them directly on
your host system anyway, they either might need to be installed in a
BIOS/PROM/whatever or used inside an emulator, so I don't think they
are in the same situation as normal binaries.

Yes, ideally, to be pedantically correct, we would either have
powerpc (or other) cross-toolchains on the archive, or we'd have
Multiarch support and the package could be arch:powerpc and would be
possible to install on other arches. But this is not possible right
now, so consider this wontfix.

Other packages in a similar situation are proll, openbios-sparc,
bochsbios and vgabios (there might be others).

> Workarounds like an error on wrong toolchain architecture are wrong
> (there is an error anyway if you try to build on !powerpc).

That error is too late, and this one at least explains why it's
failing.

regards,
guillem


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

Re: changing the default syslog daemon for lenny?

[Guillem Jover]

Hi,

On Thu, 2008-01-31 at 00:11:44 +0100, Michael Biebl wrote:
> For 12.) and 28.), I'd file a wishlist bug providing a config file
> snippet for /etc/rsyslog.d/

Can we please use /etc/syslog.d/ instead? this way we don't get locked
in any specific implementation. I'm preparing a patch for
inetutils-syslogd to support that, and it might also make sense to
require all system-log-daemon providers to support that dir as well.

> And finally, if it is approved that rsyslog should be become the default
> system-log-daemon, I'd file wishlist bugs against the remaining packages
> to change the dependency to rsylog | system-log-daemon, where
> appropriate.

rsyslogd seems to have a lot of features, and it's a bit big compared
to other implementations, do normal users need all that stuff?
Sysadmins can easily change it, and I bet most of the users do not
care much what syslogd is installed as long as it's just logging.

The list of syslogd sorted by Installed-Size:

Package: socklog-run
Installed-Size: 148

Package: sysklogd
Installed-Size: 212

Package: inetutils-syslogd
Installed-Size: 216

Package: syslog-ng
Installed-Size: 552

Package: rsyslog
Installed-Size: 672

regards,
guillem


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

Re: changing the default syslog daemon for lenny?

[Guillem Jover]

On Thu, 2008-01-31 at 05:30:47 +0100, Michael Biebl wrote:
> Guillem Jover wrote:
> > On Thu, 2008-01-31 at 00:11:44 +0100, Michael Biebl wrote:
> > > For 12.) and 28.), I'd file a wishlist bug providing a config file
> > > snippet for /etc/rsyslog.d/
> >
> > Can we please use /etc/syslog.d/ instead? this way we don't get locked
> > in any specific implementation. I'm preparing a patch for
> > inetutils-syslogd to support that, and it might also make sense to
> > require all system-log-daemon providers to support that dir as well.
>
> I'd rather not do that. There is no common config file format, that all  
> sylog daemons understand. E.g. you can't mix syslog-ng configuration  
> with metalog or rsyslog. The additional functionality of rsyslog is  
> implemented via special directives, which other syslog daemons won't  
> understand. So, I don't think this is a good idea.

I've just checked a bit and sysklogd, inetutils-syslogd and rsyslog
understand the standard syslog.conf format. rsyslog has additional
directives, but IMO those should not be used by third party packages
that would drop config snippets under /etc/syslog.d/. rsyslog could of
course read configs from syslog.d and rsyslog.d, and admins could
install those under /etc/rsyslog.d/ or edit /etc/rsyslog.conf to make
use of those additional features.

The only daemons not understanding the standard format are syslog-ng,
socklog, and metalog (which is not even on the distro).

My concern is making packages explicitely dependant on rsyslog, when
they could be generic, making it difficult for admins to switch
syslogd and also any future transition to another syslogd.

regards,
guillem


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

Re: Automatic mirror selection

[Guillem Jover]

On Fri, 2008-02-01 at 21:09:24 +0100, Leo costela Antunes wrote:
> Adam Borowski wrote:
> > Uhm, and how exactly do you get the arch?  At DNS time you don't have
> > anything but the requester's or his ISP's IP.
> 
> This would have to be placed inside sources.list at some point, then I
> figure the automatic or manual process responsible should stick
> "dpkg-architecture -qDEB_BUILD_ARCH" somewhere in there, so you just
> have to query ".geomirror.d.net", for instance, to get the best
> mirror for your country which contains your arch.

You might want you use «dpkg --print-architecture» instead, so you
avoid a dependency on dpkg-dev.

regards,
guillem


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

Re: How to cope with patches sanely

[Guillem Jover]

On Thu, 2008-01-31 at 10:54:11 +0100, Pierre Habouzit wrote:
>   Of course, that would mean that the few debian/rules (hi Manoj) in
> Debian not being makefiles [...]

You were probably thinking about Josip (and now the VDR team):

  

regards,
guillem


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

Re: unknown-field-in-control homepage

[Guillem Jover]

Hi,

On Wed, 2008-02-06 at 20:23:37 +0100, Jonas Meurer wrote:
> On 06/02/2008 Russ Allbery wrote:
> > > I'm not sure whether this is an issue with dpkg or rather with lintian,
> > > but if I check the cryptsetup deb+udeb packages after building them,
> > > lintian reports that udebs don't allow the Homepage field in
> > > debian/control.
> > 
> > This is what I was told by (a d-i maintainer | someone who was willing to
> > express an opinion).  I'm happy to change lintian if having Homepage in
> > udeb is deemed acceptable.  Otherwise, dpkg should probably be modified to
> > not propagate Homepage fields into udebs.
> 
> I raised this issue on #debian-boot (irc), and was told that the
> concerns by "(a d-i maintainer | someone who was willing to express an
> opinion" were correct. Frans Pop from the debian-installer team verified
> that the Homepage field should not be included in the udeb:
> 
> 20:11 < mejo> fjp: did you see Russ's response to my question regarding
>   Homepage Field in udebs?
> 20:11 < mejo> fjp: i mean on [EMAIL PROTECTED]
> [...]
> 20:12 < fjp> mejo: Please file a bug against dpkg-dev.
> 20:14 < fjp> mejo: Russ is correct: we don't want the homepage field in
>  the control file of udebs
> 
> 
> If nobody has any objections, i'll follow Frans' advice and file a bug
> against dpkg-dev.

Yes, makes sense. I've just fixed it in dpkg's git [0].

regards,
guillem

[0] 


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

Re: unknown-field-in-control homepage

[Guillem Jover]

On Thu, 2008-02-07 at 10:23:51 +0100, Raphael Hertzog wrote:
> Except it will only work if the package uses 'Package-Type' and not
> 'X*-Package-Type'.

X*B*-Package-Type should work as well.

regards,
guillem


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

Bug#465402: O: directfb -- direct frame buffer graphics

[Guillem Jover]

Package: wnpp
Severity: normal

Now that the library transition is over, and all major bugs should be
fixed, I've been able to finally orphan the directfb suite of packages.

It might make sense for whoever takes over, to adopt the whole suite
(directfb, dfb++ and fusionsound), they have been maintained in the
pkg-directfb alioth project, which I can hand over to the new
maintainer(s).

All patches have been sent and merged upstream, except for one, which
I'm taking care of. There's intructions in that patch header on how to
proceed for next upstream release.


The package description is:
 DirectFB is a graphics library which was designed with embedded systems
 in mind. It offers maximum hardware accelerated performance at a minimum
 of resource usage and overhead.


-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.24.1-zulo (PREEMPT)
Locale: LANG=C, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



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

Re: Bug#465402: O: directfb -- direct frame buffer graphics

[Guillem Jover]

Hi,

On Tue, 2008-02-12 at 16:03:04 +0100, Fathi Boudra wrote:
> Otavio Salvador, Luis Mondesi and me would like to adopt directfb and
> friends.

Sure, I've transferred the alioth project now (you sort out the
project perms).

Something I forgot to say before about latest upstream release, I
didn't package it because it's currently considered as a development
branch by upstream.

regards,
guillem


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

Re: How to express bullet lists

[Guillem Jover]

On Sun, 2008-02-17 at 09:17:44 +, Simon Huggins wrote:
> On Sun, Feb 17, 2008 at 09:22:17AM +0100, Andreas Tille wrote:
> > On the other hand
> >  http://packages.debian.org/sid/ht
> 
> > is perfectly formatted on the web pages.   It seems to be according
> > to the fact that parts of the description where a line starts with
> > two spaces are wrapped into  tags in the HTML code.  This
> > could be used as workaround. 
> > (Did I missed some documentation of this behaviour?)
> 
> Yes.
> 
> http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Description
> 
> The others are probably bugs then.  Do you have a list to name and
> shame?

There's additional information, including a proposal by Daniel Burrows and
a list of packages compiled by Tomas Pospisek at:

  

regards,
guillem


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

Re: How to cope with patches sanely

[Guillem Jover]

On Sat, 2008-02-23 at 09:08:23 -0600, Manoj Srivastava wrote:
> On Sat, 23 Feb 2008 08:46:03 -0500, David Nusinow <[EMAIL PROTECTED]> said: 
> > This argument assumes that dpkg-source -x will apply that patch stack
> > automatically as well, which has been discussed elsewhere.
> 
> Currently vapourware, no?

I want to clarify this, as I've seen it mentioned several times on this
thread. dpkg-source supports extracting Wig&Pen since etch. The missing
bit is source package generation (I posted a proof of concept script to
convert quilted source packages to debian-dpkg [0]).

regards,
guillem

[0] 


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

Re: dpkg semi-hijack - an announcement (also, triggers)

[Guillem Jover]

Hi,

I'd like to clarify few more things, which have been brough up the past
few days. Even if I don't usually accept open invitations to flamefests
(re the OP).

On Mon, 2008-03-10 at 14:42:48 +1000, Anthony Towns wrote:
> On Sun, Mar 09, 2008 at 10:38:44PM -0500, Steve Greenland wrote:
> > On 09-Mar-08, 19:30 (CDT), Daniel Stone <[EMAIL PROTECTED]> wrote: 
> > > I was going to ask on which grounds exactly you were judging the dpkg
> > > team's competence (and that of iwj's: have you reviewed the branch
> > > yourself? can you confidently say that it's all fine?),

> > The problem is not the dpkg team has reviewed the patch and had problems
> > with it, it's that they've ignored it for 6 months.
> 
> That's not the full picture.

This was a nice summary.

> > I don't approve of IanJ's hijack attempt, but in this he's got a
> > legitimate complaint. 
> 
> Against the wishes of, afaict, Guillem and Raphael, Ian's made applying
> his triggers patch dependent on:
> 
>   - reversion to two space indenting

- reversion of unrelated commits

>   - a policy of bulk conversion of intentation style, instead of
> the current policy of gradual conversion from two-space to
> four-space
> 
>   - having explicit casts to (char*) of NULL in order to support
> some non-Debian architectures

- having the commits not split into logical parts

- having unrelated features/changes in the same branch

>   - having the git log not be bisectable or particularly meaningful
> except historically

>   - having Ian be part of the dpkg team

The missing changelog entries are actually minor compared to the rest
of the problems with the branch.

The branch has never been in an acceptable state, it needs cleanup,
which Ian has refused to do, repeatedly, and wasted probably more time
and everyone's energy starting this (and previous) massive flamefests
than what would have taken to just fix it.

About rebasing (-i), we've asked for the branch to be rebased as part
of the needed cleanup (or any other method which would have resulted in
a clean branch or series of patches). He could have kept his existing
branch if he so desired, but I don't really see much point in that given
that the resulting cleaned up branch would not resemble the original one
anyway. One of his excuses was that he had based other feature branches
on this one, which is another bad idea, as this was tying unrelated
changes together.

Also I don't think we'd have insisted on rebasing (even if I personally
would prefer so) if the branch would not have been a mess, FWIW, we've
merged clean branches before in the team. And I don't really understand
this aversion to rebasing a branch that should be pulled from at some
point (I'm obviously not talking about the official branches here),
most people would find sending messed up patches unacceptable, but not
this?

> If he hadn't done that, afaict the patch would've been handled pretty
> much the way Tollef's was.

I've to say, overall, interactions with Ian have been mostly
unpleasant, demotivating and confrontational. Not really my definition
of "fun".

> I don't believe anyone on the dpkg team at any point gave Ian a definite
> answer on any of the above issues over the past months; though I doubt
> he would have accepted a "no" on any of them anyway.

Maybe we've not sent a strong enough message, but there was repeated
long conversations, AFAIR, on mail and IRC about how we'd like to see
such a branch or series of patches being submitted.


Anyway, after the freeze was announced it was clear that Ian was not
going to fix the branch, and because having this feature for lenny is
highly desirable I was just going to have to fix it myself and review
during that process, but got quite sick for a week, during which he
started all this mess.

I'm back on the clean/split/merge process, and should finish soonish
if I don't get distracted by more useless flamefests... Also given that
he does not have commit access any longer I'll be taking care of
integrating any reasonable change that might be on any of his branches,
in the same way we'll be getting eventually at all the remaining patches
that are waiting on the BTS.


And I'm also quite disappointed with the amount of people that have
jumped to conclusions without knowing the context of all this.


regards,
guillem


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

Re: dpkg compilation on Solaris

[Guillem Jover]

Hi Michel,

On Thu, 2008-03-13 at 15:51:15 +0100, BRIAND, Michel (EKITO) wrote:
> dpkg ported to Solaris, has problems with obstack and strlen.

Please use debian-dpkg or preferibly the BTS to discuss this kind of
thing, debian-devel is not the appropriate forum. If you could file a
bug report we can move the discussion there.

> I've seen that a recent patch converted all that stuff to libcompat.

Yes, one of the reasons for those changes was to accomodate the needed
stuff for Solaris and other systems. I've not forgotten this and
it's also on the TODO list. Will get to it before the .17 upload.

> Can you help me get this new version (I do not have git) and I need to
> go with dpkg 1.14.16.x 

You can take snapshots from the git repo from the gitweb interface:

  

regards,
guillem


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

Re: dpkg semi-hijack - an announcement (also, triggers)

[Guillem Jover]

On Wed, 2008-03-12 at 10:01:35 +, Ian Jackson wrote:
> Guillem Jover writes ("Re: dpkg semi-hijack - an announcement (also, 
> triggers)"):
> > On Mon, 2008-03-10 at 14:42:48 +1000, Anthony Towns wrote:
> > > Against the wishes of, afaict, Guillem and Raphael, Ian's made applying
> > > his triggers patch dependent on:
> > > 
> > >   - reversion to two space indenting

I seems I'll need to clarify this as well, as it's not correct, and has
been brought somewhere else... The rest has already been explained
several times, and I don't think there's any need to be repetitive.

> The history of this change is as follows:
>   * At some point, without any kind of discussion, Guillem
> unilaterally reformats several files to 8-character indents.

This is not correct. The changes referred to in bug 375711 were
introduced when:

  Wichert reindents configure.c:

  <http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=1b7b5f21>

  Initial version by Wichert of showpkg.c:

  <http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=54cc8a5f>

  New function by Fumitoshi Ukai in archives.c:

  <http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=520ad305>

  Initial version of tarfn.c (git history does not go further and the
  ChangeLog is not detailed enough, from the header I assume it was
  Bruce Perens):

  <http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=1b80fb16>

>   * On the *26th of June 2006* I noticed this because it caused
> an unnecessary merge conflict while I was trying to do a merge
> between the Ubuntu and Debian versions of dpkg.

I doubt actually this caused any merge conflict, given that those files
had been this way for a long long time.

>   * I thought it was a mistake because surely no-one would
> deliberately change the indent depth in an existing piece of free
> software.  (A plausible mechanism for the mistake involves an
> editor with tab-width set to 2; these kind of things do happen
> occasionally.)

It does not matter if it was a mistake or not, this kind of change
should have never landed in any unrelated non-official branch mixed
with other stuff. And I disagree that no one would want to change
coding style as I explained in:

  <http://lists.debian.org/debian-dpkg/2007/05/msg00086.html>

>   * I therefore posted saying to debian-dpkg that this loooked like a
> mistake.  I also filed a bug, #375711, with a patch to revert the
> change.
>   * On the *30th of May 2007* I got the same merge conflict again in a
> later merge.  My bug report had gone unanswered.  By this point
> there is a considerable body of changes in Ubuntu which ought to
> be merged into Debian, all of which have the original formatting
> as I requested in my bug report.

The patch in that bug had been partially applied (explained at [0]):

  <http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=b31f79e7>

And I guess at this point I should have just closed the bug, but this
was a continuos source of conflict, so leaving it open seemed to be
the less annoying.

I disagree with the rest of the patch[1], which was also wrong (due to
the resulting mixed indentantion), as I explained at:

  [0] <http://lists.debian.org/debian-dpkg/2007/08/msg6.html>

  [1] 
<http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=diff;att=1;bug=375711>

>   * So I post to debian-dpkg again and Guillem tells me it was
> deliberate.

I said in [0] that "I think that those changes were done on purpose".

guillem


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

Re: Default value for CFLAGS/LDFLAGS set by dpkg

[Guillem Jover]

Hi,

On Mon, 2008-03-31 at 16:21:14 -0400, Aaron M. Ucko wrote:
> Kurt Roeckx <[EMAIL PROTECTED]> writes:
> 
> > I also have to wonder that if we have something like this as default,
> > why -Bsymbolic-functions would be a good default, and not -Bsymbolic.
> 
> It's also worth noting that the original proposal (
> http://lists.debian.org/debian-devel/2007/12/msg00090.html ) gave
> testing -Bsymbolic-functions as a potential use case, but *NOT* as an
> actual proposed default (at least AFAICT).

Raphaël reverted that part prior to the dpkg 1.14.17 upload:

 

regards,
guillem


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

Adding lzma to dpkg's Pre-Depends

[Guillem Jover]

Hi,

As per policy 3.5 I'm bringing this up here. I'd like to add lzma to
dpkg's Pre-Depends, so that we can use lzma compressed packages after
lenny w/o having to add an lzma Pre-Depends on each .deb package
compressed that way.

For a lengthier discussion, please check:

  

And my reasoning:

  

regards,
guillem


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

Re: Adding lzma to dpkg's Pre-Depends

[Guillem Jover]

Hi,

On Wed, 2008-04-02 at 14:01:16 +1000, Anthony Towns wrote:
> On Tue, Apr 01, 2008 at 08:05:06AM +0300, Guillem Jover wrote:
> > As per policy 3.5 I'm bringing this up here. I'd like to add lzma to
> > dpkg's Pre-Depends, so that we can use lzma compressed packages after
> > lenny w/o having to add an lzma Pre-Depends on each .deb package
> > compressed that way.
> 
> Hrm. Alternatively, the packages _do_ pre-depend on lzma though; and
> you're aiming to avoid that by making lzma Essential:yes -- in the same
> way packages that pre-depend on perl or bash don't need an explicit
> dependency.

Well not really Essential, it's going to be pulled like that yes, but
other derivatives, might want to disable it. And I agree with Chris that
it makes sense for dpkg to Pre-Depend on lzma as it's the one calling
it, and that's an internal implementation detail, in case there's a
liblzma in the future and we'd switch to using it, packages should not
require to be changed.

> libz and libbz2 are both included statically;

Switching to dynamic linking is something I've been pondering for some
time, but that's independent of this discussion, and something not to
be changed at this point of the release anyway.

> would it make more sense to do the same thing with the lzma (ie,
> copy the binary into /usr/lib/dpkg), instead of making lzma
> essential?

The lzma package is tiny, it could be halved as I pointed out in the
bug report (should probably just file bug reports on lzma for that).
That would imply an installed size of about 150 KiB, 100 of those
are just the lzma binary. In that case I don't really see the gain
in having mostly the package there but w/o it being handled by the
packaging system.

regards,
guillem


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

Re: How to handle Debian patches

[Guillem Jover]

On Fri, 2008-05-16 at 15:49:25 -0700, Russ Allbery wrote:
> That would work, although it does... well, not double, but at least
> increase the work for any branch that also has a submission branch, since
> any upstream merge conflicts have to be resolved on both branches.  Or is
> there some way to reuse the resolution work done with one of those
> branches when rebasing/merging the other?

Check 'man git-rerere'.

regards,
guillem


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

Re: what about an special QA package priority?

[Guillem Jover]

On Wed, 2008-05-21 at 06:11:46 +0200, Bernd Eckenfels wrote:
> In article <[EMAIL PROTECTED]> you wrote:
> > even though it's "just" a command line utility.  Who knows what
> > weird, unexpected side effects there might be from running such an
> > app within a tight bash loop.
> 
> none*. And not cleaning up yourself also improves performance for short
> running apps.
> 
> * unless we talk persistent resources like files or ipc.

There's also the case of PIE applications, and someone else dlopening
them, althought I don't think this is that common right now.

regards,
guillem


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

Re: Handling of removed packages

[Guillem Jover]

Hi,

On Thu, 2008-05-29 at 21:37:28 +0200, Franklin PIAT wrote:
> I suggest to modify dpkg so it refuse to install package, unless the
> option "--insecure" is specified. Such option's manpage description
> would be :

That'd be mostly just annoying for no actual benefit. It would break
existing software using 'dpkg -i', and people would end up adding that
option to the config file.

> > dpkg --install --insecure package_file...
> > The option --insecure is now mandatory to install a ".deb" package.
> > 
> > Installing a ".deb" file manually is considered a bad practice (i.e
> > insecure), because the package wouldn't be updated when the maintainer
> > release a security update.

This is not true if the package comes from the repo you've fetched it
from.

> > Instead of downloading and installing a .deb file, you should declare
> > it's apt repository. This is done by adding the package's repository
> > to /etc/apt/sources.list or /etc/apt/sources.list.d/. See
> > sources.list(5).

There's few other ways to upgrade a system than with apt.

> * This option would be an effective solution to educate new users.
> * For the same reason, we should remove gdebi's "Install" button.

I don't think this kind of punishment would educate any users. So I
don't see this being implemented in dpkg, sorry.

regards,
guillem


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

Re: Anything wrong with bzr.debian.org or debcheckout ?

[Guillem Jover]

On Thu, 2008-06-19 at 14:32:00 +1000, Robert Collins wrote:
> On Thu, 2008-06-19 at 13:27 +0900, Charles Plessy wrote:
> > I tried to debckechout zlib and it failed:
> > 
> > anx159tmp$ debcheckout zlib
> > declared bzr repository at http://bzr.debian.org/bzr/pkg-zlib/zlib/debian
> > bzr branch http://bzr.debian.org/bzr/pkg-zlib/zlib/debian zlib ...
> > bzr: ERROR: Transport error: Server refuses to fullfil the request 
> > checkout failed (the command shown above returned non-zero exit code)
> > 
> > I took rando
> 
> Its a bug in your bzr, fixed upstream already I believe.

And can be worked around by installing python-pycurl.

regards,
guillem


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

Re: Bug#426877: dpkg: Option "--oknodo" should be the default behaviour for "start-stop-daemon" (LSB specs)

[Guillem Jover]

Hi,

On Fri, 2008-07-04 at 01:47:39 -0700, Steve Langasek wrote:
> > I think being LSB compliant is good for Debian.
> 
> The LSB init script specification *is a specification for the init scripts
> of LSB packages*.  It has NOTHING to do with LSB compliance of LSB
> implementations.  Debian is an LSB *implementation*, NOT a collection of LSB
> applications.  Conforming with the LSB init script specification would NOT
> make Debian packages conformant LSB applications!
> 
> The LSB init script spec is a reasonable and internally consistent set of
> guidelines for init scripts.  It's not a bad policy; in fact, 90% of it is
> word-for-word identical with the Debian init script policy.  But the LSB
> init script spec is *not* the Debian init script policy, and we should not
> blindly seek conformance to an LSB *application* spec for its own sake.

Agreed.

> I happen to be in favor of seeing Debian adopt at least one feature of the
> LSB init script spec that we miss, which is the mandatory 'status' argument.
> But this needs to be adopted as part of Debian policy itself, through our
> normal procedures for such changes.

Yeah, this is something I've on my TODO list, most of the needed code
is already on s-s-d. Will try to get something working this weekend.

regards,
guillem


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

Re: Bug#534507: ITP: kalternatives -- graphical alternatives system configuration tool

[Guillem Jover]

Hi!

On Tue, 2009-06-30 at 12:32:23 +0200, Pino Toscano wrote:
> Few days ago, I had a nice talk with Guillem, and he told me that dpkg 
> developers are working for cleaning up update-alternatives' code, and 
> planning 
> to convert it to C (along with provide a dpkg library); since the previous 
> are 
> either happening or planned to be soon, I will avoid to rewrite the parser 
> twice, but wait for the dpkg library and help testing it, which is what 
> kalternatives will use (when it is ready, of course).
> 
> Would it be acceptable for now?

Sure, as discussed, as long as this is only temporary until we provide
a better interface, it seems wasted effort having to rewrite it twice.

thanks,
guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: multiarch and maintainer scripts

[Guillem Jover]

Hi!

On Thu, 2009-07-02 at 13:58:48 -0700, Russ Allbery wrote:
> Goswin von Brederlow  writes:
> > what can be done if the maintainer scripts of a package must behave
> > differently when unpacking the i386 deb on i386 or the i386 deb on
> > amd64?

We discussed this with Steve some days ago. My initial idea was to
make “dpkg --print-architecture” polymorphic, and change what it
prints depending on what architecture the package being installed is.

That would require less packaging changes, but it seems pretty
fragile and non-obvious behaviour, and we have several packages using
“uname -m”, they'd need to be changed due to this or just to
multiarchify them anyway, so we discarded it.

But yesterday I came up with a simpler and cleaner solution, just
export an env var matching the package arch being installed. Something
like DPKG_MAINTSCRIPT_ARCH or similar.

> > For example 32bit fglrx-glx needs to divert /usr/lib/libGL.so.1.2 on
> > i386 but /usr/lib32/libGL.so.1.2 on amd64.

I don't think this example is relevant. Once libgl has been
multiarchified, then everywhere the i386 file is going to be located
under ‘/usr/lib/i486-linux-gnu/libGL.so.1.2’.

> Surely this is as simple as:
> 
> case `dpkg --print-architecture` in
> amd64)
> # Do some stuff.
> ;;
> i386)
> # Do some other stuff.
> ;;
> esac
> 
> isn't it?

In this case it might have been enough, or not needed at all.

But that would print the arch dpkg was built for (i.e. the native
architecture), not the foreign arch of the package we are installing,
which is what we'd be interested in most cases like grub, eglibc,
module-init-tools or util-linux maint scripts.

regards,
guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#536888: ITP: tlock -- Terminal locker

[Guillem Jover]

Hi!

On Tue, 2009-07-14 at 15:28:53 +0200, Cyril Brulebois wrote:
> Ryan Kavanagh  (14/07/2009):
> > This package will also provide the library packages librpass0 and 
> > librpass0-dev,
> > with long description:
> > 
> >  Static library installed with tlock, it provides a function readpass() that
> >  reads in a password string from standard input of process and returns it  
> > back,
> >  AS  IS, to the calling application. While fetching password from standard
> >  input, readpass first turns off the echo of input characters  and the
> >  generation of signals through keystrokes, reads in the password, turns the
> >  character echo and signal generation back on, and returns to the calling
> >  application a character pointer pointing at the password string.
> 
> Do we really need this standalone library?! And please, pretty please,
> stop putting the SONAME in the -dev package name when it isn't needed.
> (Also, the first word of the description for this dynamic library is
> “static”?)

It seems that tlock does not memset the clear text passwords after use,
it does not mlock them either (although to be fair, really few programs
handling passwords seem to be doing so), and reimplements strcmp for no
apparent reason.

Also why do we need tlock when we have vlock and away?

regards,
guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: backward/forward binary compatibility checker

[Guillem Jover]

Hi!

On Thu, 2009-08-06 at 18:38:41 +0400, Andrey Ponomarenko wrote:
> Colleagues, I'm software engineer from Institute for System
> Programing of Russian Academy of Sciences and we are developing a free
> lightweight tool for checking backward/forward binary compatibility of
> shared C/C++ libraries in OS Linux. It checks interface signatures and
> data type definitions in two library versions (headers and shared
> objects) and searches ABI changes that may lead to incompatibility.
> We have released 1.1 version of this tool and we'd like you to consider
> its usefulness for your project.
> The wiki-page with the latest release of binary compatibility checker is
> http://ispras.linux-foundation.org/index.php/ABI_compliance_checker

How does this compare with projects like icheck or abicheck?

regards,
guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Automatic Debug Packages

[Guillem Jover]

Hi!

On Tue, 2009-08-11 at 13:03:13 -0700, Russ Allbery wrote:
> Open questions:

> * Can we require a one-to-one correspondance between binary package names
>   and debug package names that provide symbols for that binary package?  I
>   think we should; I think it would make the system more straightforward.

Being able to debug your system with a mixture of applications using an
old and new shared library coming from the same source package for which
the soversion got bumped is pretty helpful, w/o needing to downgrade the
whole debugging package every time one wants to debug applications
using either.

regards,
guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#540365: ITP: turnin-ng -- Assignment submitter and manager

[Guillem Jover]

On Sun, 2009-08-09 at 16:40:44 -0400, Ryan Kavanagh wrote:
> On Sun, Aug 09, 2009 at 05:23:43PM +0200, Guillem Jover wrote:
> > I hope the packages uploaded won't have a «project» binary in the
> > PATH?
> 
> At the moment yes, Turnin-NG provides /usr/bin/project since that's what the
> original turnin / project app provided. However, I can either:
>  1) Rename the project script to something else upstream.
>  2) Rename it in the Debian package and add a note to README.Debian.
> 
> I'm not sure which I prefer. #1 has the advantage of being consistent across 
> all
> distributions. #2 makes it so that if someone else wants to move away from 
> SPARC
> and use Turnin-NG as a direct replacement for their old binaries, they can.
> 
> What do you think?

I'd rename it upstream, less troubles for everyone. It's of course
unfortunate that the original program was named like that, but I don't
think continuing to take over such generic name is good in general. You
could still document that in the Description, and README.Debian maybe
also including a recipe for sites that might want to create for example
a compat symlink under /usr/local for transitional purposes, or something
to that effect.

For the upstream part you could also do a slow transition, provide a
«project» wrapper that prints a warning on stderr notifying the user
about it being obsolete and pointing to the new name, the executing
the actual program. The wrapper could be shipped for a period of time
before complete removal, and installed only if enabled via some
configure flag (or make target, as in “make install-obsolete”). Or
just document the rename.

thanks,
guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: What's the use for Standards-Version?

[Guillem Jover]

Hi!

On Thu, 2009-08-13 at 11:15:37 +0200, Reinhard Tartler wrote:
> Raphael Hertzog  writes:
> > > BTW also Maintainer and Uploader fiels are uselessly exported.
> >
> > Same here, they are used. While in stable the info might not be up-to-date,
> > in sid it does and those infos are used by the PTS.
> 
> What about exposing them in the Source file for /unstable/ *only*, and
> leave them out for /stable/ and /testing/?

If those fields do not represent reality I think the correct thing to
do would be to fix that instead of just removing them. The archive
overrides are meant to be used for stuff like that, and it could be
automated to inject those fields from unstable into testing and
stable.

regards,
guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Override changes

[Guillem Jover]

Hi!

On Wed, 2009-08-05 at 23:49:52 +0200, Joerg Jaspert wrote:
> if you need to request an override change for your package, please use
> the BTS in future, no longer reply to the override disparity mail you
> will receive from the archive.

What about mass override change suggestions? Should those also go to
the BTS?

> The format for such bug reports against the ftp.debian.org
> pseudopackage:
> 
> Subject: override: PACKAGE1:section/priority, [...], PACKAGEX:section/priority
> 
> Include the justification for the change in the body of the bug please.

... if they should go to the BTS, could you specify which format would
you prefer them in?

> This new way will make it easier for us to keep track which are already
> done and which not.

... and in that case would you like me to file as bugs the ones that I
previously sent to override-cha...@d.o but have not yet been handled?

thanks,
guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFC: update-inetd migration to dpkp-triggers

[Guillem Jover]

Hi!

On Mon, 2009-09-07 at 22:06:23 +0100, Roger Leigh wrote:
> On Fri, Sep 04, 2009 at 10:02:21PM -0700, Steve Langasek wrote:
> > On Fri, Sep 04, 2009 at 09:54:19PM +0200, Serafeim Zanikolas wrote:
> > > * document that local policy will live in /etc/inetd.conf.d/ and any 
> > > manual
> > >   changes will be made effective by running update-inetd
> > 
> > I think this violates the principle of least surprise (restarting the daemon
> > after making your changes has been enough to make those changes take effect
> > since the inception of these daemons), and will be displeasing to many
> > admins as a result.
> 
> I can't say that this part thrills me either.  However, we have as yet
> not come up with a saner alternative.

Yes that's something I don't like much either. But I was just thinking,
another possibility could be to add support for xinetd framgments to
the other three inted implementations. I'd gladly accept patches for
inetutild-inetd (or cook one if we'd agree this is the way to go, time
allows and no one has done so yet).

Also using /etc/inetd.conf.d to store xinetd style framgnets seems a
bit confusing to me. Why not reuse the xinetd directory instead?

regards,
guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFC: update-inetd migration to dpkp-triggers

[Guillem Jover]

On Mon, 2009-09-07 at 13:59:48 -0700, Steve Langasek wrote:
> On Mon, Sep 07, 2009 at 09:40:51PM +0100, Roger Leigh wrote:
> > There are many obvious examples of update-foo scripts which behave in
> > this manner.  The requirement to run a script to update the working
> > configuration is nothing new in Debian.
> 
> The only obvious example I have of an update-* script that a user has to run
> to effect changes to their config is update-grub.
> 
> And update-grub has been an unqualified disaster.
> 
> (Some of the reasons for which don't apply in this case, I'll grant you -
> but I certainly wouldn't agree that there are good precedents for this in
> Debian.)

The other one I can offer is update-exim4.conf, which is the default
from several ways to handle the exim4 configuration. But something I've
always found pretty confusing and always switched my boxes to use the
monolithic configuration file in /etc/exim4/exim4.conf. I'd would
consider using the conffile fragments under /etc/exim4/conf.d if those
were natively loaded by exim4 itself, a la apache.

regards,
guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#545795: ITP: libbind -- standard resolver library

[Guillem Jover]

Hi!

On Wed, 2009-09-09 at 10:20:57 +0200, Ondřej Surý wrote:
> Package: wnpp
> Severity: wishlist
> Owner: "Ondřej Surý" 

> * Package name: libbind
>   Version : 6.0
>   Upstream Author : Internet Systems Consortium
> * URL : https://www.isc.org/software/libbind
> * License : BSD
>   Programming Lang: C++
>   Description : the standard resolver library
>  
>  ISC's libbind provides the standard resolver library, along with
>  header files and documentation, for communicating with domain name
>  servers, retrieving network host entries from /etc/hosts or via DNS,
>  converting CIDR network addresses, performing Hesiod information
>  lookups, retrieving network entries from /etc/networks, implementing
>  TSIG transaction/request security of DNS messages, performing
>  name-to-address and address-to-name translations, and utilizing
>  /etc/resolv.conf for resolver configuration.

This seems to be already packaged:

  

And there's also the one coming from the bind9 source packages.

regards,
guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Transitional (dummy) packages considered silly

[Guillem Jover]

On Wed, 2009-09-23 at 10:51:50 +0200, Goswin von Brederlow wrote:
> Magnus Holmgren  writes:
> > When a binary package is renamed or split, as well as if several packages 
> > are 
> > merged under a new name, transitional packages are normally created, which 
> > depend on the new packages, which in turn Replaces and Conflicts with, and 
> > possibly Provides, the old packages. I find those dummy packages as silly 
> > to 
> > create as to uninstall after upgrading.
> 
> Dpkg has the ability to vanish empty packages. A dummy package should
> be completly empty and not even contain a /usr/share/doc/. That way on
> installation the package pulls in its depends and then vanishes. So no
> more need to uninstall after upgrading. This only works if the
> superseeding packages Provide the old one though. Otherwise depends on
> the old package would become unsatisfied.

That's not correct. dpkg only disappears packages that have been
completely replaced while installing other packages. There's two cases
for this:

 1. The package to disappear has files that get completely replaced by
the new one. Needs the Replaces field.
 2. The disappearing package contains empty directories, and all of
them are shipped as well by the new package. Does not need
Replaces field, because directory takeover is an implicit
Replaces, so this is actually a subcase of 1.

dpkg will never disappear a packages just because it's empty w/o the
previous conditions. And just to clarify, in no case the Provides field
plays any role in the disappearing process.

regards,
guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: piuparts-MBF: owned and unowned files after purge

[Guillem Jover]

Hi!

On Mon, 2009-10-19 at 20:14:12 +0200, Holger Levsen wrote:
> Reasoning: "a piuparts clean archive" is a release-goal for squeeze (and was 
> for lenny) and this is prohibited per debian-policy. As the impact of the 
> bugs ain't that high (except that we break our quality promise with it and 
> blatantly violate policy), I think "important" is the right severity.
> 
> http://piuparts.debian.org/sid/owned_files_after_purge_error.html shows which 
> packages need to remove owned files after purge, see 
> http://www.debian.org/doc/debian-policy/ch-files.html#s10.7.3

> Guillem Jover 
>inetutils

This include inetutils-ping and inetutils-syslogd, which are false
positives.

For inetutils-ping it lists files having disappeared which belong to
iputils-ping, a package which Conflicts ang gets removed when installing
inetutils-ping. The log incorrectly lists /bin/ping and /bin/ping6
belonging to inetutils-ping when they should belong to iputils-ping (the
one present before the test run, and for which those files disappeared
at the end of the run, as it didn't get reinstalled).

For inetutils-syslogd, there's left over files from rsyslogd which
again Conflicts and gets removed when installing the former. And the
rest of disappearing files also from rsyslogd.

So it seems piuparts needs to get fixed to take into account packages
being removed due to Conflcits. And probably should purge those
packages which got removed, or reinstall them at the end of the run.

regards,
guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Packages relying on HOME when building

[Guillem Jover]

Hi!

There's some packages which rely on HOME existing and often being
writtable. This is broken behaviour as the package does not have any
businesss verifying if it exists or writting outside of its build dir
(or /tmp).

Some of our buildds try to detect by setting HOME to something like
/non-existent. But then it gets pretty confusing for the maintainers
trying to reproduce those FTBFS (c.f. #544835).

So, I'd propose that any script used to build source should set HOME
to a non existent value. And we should probably ammend policy to state
that no source package should expect a working HOME. If no one opposes
I'll start filing bug reports.

thanks,
guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: unused parameters passed to maintainer scripts

[Guillem Jover]

Hi!

On Mon, 2009-10-26 at 00:12:24 +0200, Eugene V. Lyubimkin wrote:
> I've done a small research against maintainer scripts from all binary packages
> from sid distribution and discovered that some parameters which are passed to
> maintainer scripts are not used at all, specifically:
> 
> - in-favour   (prerm, postinst) - for sure;
> - removing   (prerm, postinst) - for sure;
> -   (postrm) - most probably, checked only a
> part so far.
> 
> So, the question: how do people think, is a goal to deprecate&remove these
> params in dpkg and policy worthy?

What'd be the point of doing that? The maintainer scripts have to be
called anyway for those cases, and the fact that no one uses them now or
in Debian, does not mean there's no use for this information in the
future or in other places.

regards,
guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Proposed mass prototypejs bug filing for multiple security issues

[Guillem Jover]

Hi!

On Mon, 2009-10-26 at 15:39:37 -0400, Michael Gilbert wrote:
> That list was taken from the secure-testing tracker's embedded code
> copies list, which is hard to keep up to date and accurate.  It could
> use some more care and better maintaining; but code copies are
> plentiful, making it very difficult to track progress on all of them.
> 
> I have not yet sent any reports because I am still in the process of
> generating a more accurate list.

You might find  very useful to find this
kind of embedded copies. Althought it seems it's having some problem
right now (Peter CCed).

regards,
guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: ReBuild-Depends?

[Guillem Jover]

Hi!

On Thu, 2009-10-29 at 18:33:12 +0300, Dmitry E. Oboukhov wrote:
> I have a package which contains a code like following:
> 
> #include 
> 
> FILE *file_handle;
> 
> int foo(int something, const char *fmt, ...)
> {
> // some statements
> 
> va_list ap;

Seems you are missing a va_start call here.

> int res = vfprintf(file_handle, fmt, ap);
> va_end(ap);
> return res;
> }

regards,
guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Upstart on kFreeBSD? [was: The future of the boot system in Debian]

[Guillem Jover]

Hi!

On Sat, 2009-11-07 at 14:00:23 +, Alan Jenkins wrote:
> On 9/5/09, Petter Reinholdtsen  wrote:
> > change the init.d script
> > handling to treat upstart jobs as init.d scripts, to provide an
> > alternative for architectures lacking upstart support

> I read this as a euphemism for non-linux architectures such as
> kFreeBSD.  But I don't understand how this would be done.

> An alternative would be to make upstart more portable.  At the moment
> the only obvious technical problem is the use of ptrace(), but I don't
> see this as insurmountable.  I think the biggest problem would be to
> persuade upstream.

There's several others (taken from this thread [0]):

 * SIGPWR
 * inotify
 * waitid()
 * epoll, eventfd, signalfd, timerfd
 * ptrace
 * netlink proc connector
 * netlink udev interface

Check Scott's [1] and Petr's [2] mails on that thread for more details.

[0] 
[1] 
[2] 

> I'm prepared to work on the code... if it's really feasible, it
> shouldn't take too long.  What I can't do is make a solid case to
> upstream by myself.  It would really need agreement from the debian
> upstart maintainers that this is their preferred way forward, along
> with a commitment that Debian will help resolve any portability issues
> which arise in future versions of upstart.

The biggest issue I see is that someone will have to step up and
become “upstream” for the non-Linux ports, given Scott's position.
I'm not sure how he'd expect those to get released, if as outright
forks or something else, that'd need to be discussed with him. It will
also need copyright assignments [3] for the code that might need to be
merged back.

[3] 

> Does this make any sense?  Is anyone already working on running
> upstart scripts on non-linux architectures?

It was brought up in the debian-bsd list, but I don't know of any one
working on it.

regards,
guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bits from the FTPMaster meeting

[Guillem Jover]

Hi!

On Sun, 2009-11-15 at 22:22:52 +, Neil Williams wrote:
> On Sun, 15, Nov, 2009 at 02:37:56PM -0500, Joey Hess spoke thus..
> > Note that debootstrap does not support data.tar.bz2.
> 
> debootstrap-1.0.20/functions: extract
> 
>   progress "$p" "$#" EXTRACTPKGS "Extracting packages"
>   packagename="$(echo "$pkg" | sed 's,^.*/,,;s,_.*$,,')"
>   info EXTRACTING "Extracting %s..." "$packagename"
>   ar -p "./$pkg" data.tar.gz | zcat | tar -xf -

This has been fixed now in debootstrap's svn. I've also sent now a set
of patches to use dpkg-deb instead of ar when available.

> deb-gview is also affected by this but I haven't had any bug reports.
> Fairly easy to fix that in deb-gview though due to the use of
> libarchive.
> 
> multistrap will also be affected.

Well, IMO any program implementing .deb extraction w/o using something
like --fsys-tarfile, --extract or --control from dpkg-deb (until we
have the upcoming libdpkg...), should be prepared to handle the format
described in deb(5), and deserves a bug otherwise. The fact that the
Debian archive only accepts a subset of the valid .deb format, or that
we might not want to have bzip2 compressed packages in the base system
is a matter of policy in Debian, and does not mean others might want to
do otherwise.

regards,
guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Tool suggestions for new formats?

[Guillem Jover]

Hi!

On Mon, 2009-11-23 at 17:28:39 -0800, Rodrigo Gallardo wrote:
> Part of my usual workflow with the 1.0 format is to do an interdiff on
> the .diff.gz from the previous version to the one I intend to upload,
> to check that the changes correspond to what my vcs says they are. Now
> that the changes are in a tarball, are there any recommended tools to
> do that comparison?
> 
> A quick check on the intertubes found this
>  http://tardiff.coolprojects.org/
> Anyone tried it? What package would this (or some other equivalent but
> better suggestion) be a good addition to? devscripts?

Just use debdiff, which even supports stuff like comparing a source
format 1.0 against a 3.0.

regrads,
guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bits from the FTPMaster meeting

[Guillem Jover]

On Tue, 2009-11-24 at 10:25:59 +, Neil Williams wrote:
> On Sat, 21 Nov 2009 03:01:06 +0100
> Guillem Jover  wrote:
> > Well, IMO any program implementing .deb extraction w/o using something
> > like --fsys-tarfile, --extract or --control from dpkg-deb (until we
> > have the upcoming libdpkg...), should be prepared to handle the format
> > described in deb(5), and deserves a bug otherwise. The fact that the
> > Debian archive only accepts a subset of the valid .deb format, or that
> > we might not want to have bzip2 compressed packages in the base system
> > is a matter of policy in Debian, and does not mean others might want to
> > do otherwise.
> 
> Fixed in multistrap 2.0.4, just arriving in sid.

Checking the svn repo I still see at least one problematic piece of
code. In “emrootfslib (unpack_debootstrap)” it's using ar + tar, and
using a temporary file when it could just use a pipe, but it could have
just used ‘dpkg-deb -X’ instead of ‘dpkg -x’ to get the list of files.
Then you get any format supported by dpkg-deb for free, in addition to
being a bit more optimal.

> I'll update deb-gview for its next release, although I'll need some
> real packages using data.tar.bz2 before I can test it.

You could repack an existing .deb using dpkg-deb and the -Z option.
But please, make sure to read deb(5) and support any valid deb package.

thanks,
guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bits from the FTPMaster meeting

[Guillem Jover]

On Sat, 2009-11-28 at 22:31:29 +, Neil Williams wrote:
> On Sat, 28 Nov 2009 22:25:31 +0100 Guillem Jover wrote:
> > On Tue, 2009-11-24 at 10:25:59 +, Neil Williams wrote:
> > > I'll update deb-gview for its next release, although I'll need some
> > > real packages using data.tar.bz2 before I can test it.
> > 
> > You could repack an existing .deb using dpkg-deb and the -Z option.
> 
> deb-gview doesn't repack anything. It inspects the contents of the .deb
> directly using libarchive. deb-gview does not use dpkg.

You were asking for a package compressed with something els than gzip
for testing purposes, I was offering an easy way to get you one from
any existing package by repacking using dpkg-deb.

Still that will not give you testing coverage for all valid .debs,
like having members starting with _ inbetween the mandatory ones,
additional members afterwards, etc.

regards,
guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#559802: CVE-2009-3736 local privilege escalation

[Guillem Jover]

Hi!

On Tue, 2009-12-08 at 10:23:41 -0500, Michael Gilbert wrote:
> > CVE-2009-3736[0]:
> > | ltdl.c in libltdl in GNU Libtool 1.5.x, and 2.2.6 before 2.2.6b,
> > | attempts to open a .la file in the current working directory, which
> > | allows local users to gain privileges via a Trojan horse file.
> 
> So, as i interpret the issue, the difference here is that libtool will
> load any and all .la and .a file available on the LD_LOAD_LIBRARY path;
> whereas python will load modules in the current directory only if they
> are specifically called from the script. 

I think you mean LD_LIBRARY_PATH? And then I don't think that's a
problem, if you add ‘.’ to LD_LIBRARY_PATH then you get to keep the
pieces, in the same way if you add it to PATH.

> I have just recently realized that LD_LOAD_LIBRARY has a relatively
> safe default that does not include the current working directory.
> Given this fact, I believe that the impact is rather limited (only
> users that have modified that LD_LOAD_LIBRARY path are affected; and
> i'm sure there are those who have done this, but it is a minor subset
> of all debian users).

If you are talking about LD_LIBRARY_PATH, then the default is for it
to be empty.

> Hence, I think that for any package embedding libtool, updates should
> be pushed in stable-proposed-updates, rather than DSAs.  As for libtool
> itself, it may still make sense to issue a DSA.
> 
> If there is concurrence on this assessment, I will send a message along
> these lines to all of the bugs that I submitted.

The following are the conditions needed to trigger either of the
problematic cases, AFAIUI.

Both problems only happen iff:

  * The caller requests to load a filename with a ‘.la’ extension
(explicitly via lt_dlopen or implicitly via lt_dlopenext).
  * The filename does not have a directory component.

For the ‘.la’ problem:

  * It will try to load the filename from the current directory iff
the search in all the other paths didn't succeed. Which includes
the paths from the dependency_libs field from the ‘.la’ file,
LTDL_LIBRARY_PATH, LD_LIBRARY_PATH, and the system default paths
from libltdl.

So this will mostly only happen when the plugin is not installed,
but the application requests it.

For the ‘.a’ problem:

  * If the ‘.la’ file contains a non-empty “old_library” variable,
then it will try to load the static library name from the current
directory.

So this will happen if the static version of the plugin was built.

regards,
guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: dpkg-trigger complains at dpkg-reconfigure time

[Guillem Jover]

Hi!

On Fri, 2009-12-11 at 08:31:26 +0100, Raphael Hertzog wrote:
> On Thu, 10 Dec 2009, Joey Hess wrote:
> > Raphael Hertzog wrote:
> > > Because the postinst is called by dpkg-reconfigure (of debconf) and it
> > > doesn't set the same environment variables that dpkg does set when
> > > it calls the postinst by itself. In particular DPKG_MAINTSCRIPT_PACKAGE
> > > is missing.
> > > 
> > > (dpkg does also set DPKG_MAINTSCRIPT_ARCH and DPKG_RUNNING_VERSION)
> > > 
> > > It's a bug in dpkg-reconfigure, please file it or reassign.
> > 
> > Does it actually make sense for dpkg-trigger to see those environment
> > variables when the postinst is not being run by dpkg?

Well I guess ideally no one but dpkg should be running the maintainer
scripts. Meanwhile, I'd say yes, although it does not seem appropriate
for anyone except dpkg itself to set DPKG_RUNNING_VERSION, the others
seem perfectly fine to me. OTOH dpkg-reconfigure is doing stuff that
dpkg itself should be doing somehow, but until it does we might want
to consider it part of dpkg.

This gives me even more reasons to think that at some point in the
future we should really move dpkg-reconfigure into dpkg.

> > Seems possible that any deferred trigger processing it then sets up
> > will not take effect until the next dpkg run, which could be well
> > after dpkg-reconfigure finishes.
> 
> Right.
> 
> > Perhaps dpkg-reconfigure needs to call dpkg --configure --pending ?
> 
> Indeed, it's probably a good idea. Or maybe: "dpkg --triggers-only
> --pending" (but reading the doc I'm not sure if --configure is not
> better).
> 
> Guillem, does --triggers-only bring the package back to configured
> if they were in that state before the trigger registration ?

“--triggers-only --pending” might leave packages in triggers states,
so yes just “--configure --pending” should do it. BTW, this is
documented in dpkg(1).

regards,
guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: What is the best place for package meta-data ?

[Guillem Jover]

Hi!

On Sun, 2009-08-02 at 18:47:00 +0900, Charles Plessy wrote:
> In the Debian Med and Science teams, we are looking for efficient ways to
> document slow-changing metadata relevant to our packages, in particular:

> Alternatives will be much easier to build if we manage to centralise the
> information in a common place. This could be in the source packages
> themselves, either in a dedicated file or in debian/control (but not
> necessarly ending in the Packages and Sources files), or in the file we
> use to create our metapackages. Ultimately we would like to be able to
> have this information flow in places like the Ultimate Debian Database
> and the web pages proposing the packages for download.

Given that this is supposed to be upstream-only information, are you
aware of DOAP [0]? It seems to me it would be better to reuse already
existing infrastructure than to create yet a new one, that only a
subset of Debian might end up using. This could also be submitted
upstream I think.

It's XML though, but it could be easily transformed to any output format
we'd want to use, say control-style for example, which most of our tools
already handle, if need be.

[0] 


regards,
guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#409563: ITP: thinkfinger -- library and utility for the SGS Thomson Microelectronics fingerprint reader

[Guillem Jover]

Hi,

On Wed, 2007-02-07 at 23:39:39 +0100, Luca Capello wrote:
> ATM I don't really see any reason to create a separate package just
> for tf-tool, because libthinkfinger + tf-tool (binary and manpage)
> should generate a package around less than 50K in size.  In case new
> tools will be added, we can split the package.
> 
> Is a strong reason against this?

Please do not include it in the lib package, it's a pain afterwards
when a new version with a different soname is introduced and disallows
parallel installation of those. (This will also be a problem for
multi-arch).

regards,
guillem


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

Re: Where did Bacula 1.38.11-7+b1 come from?

[Guillem Jover]

On Thu, 2007-02-22 at 19:51:17 +0100, Florian Weimer wrote:
> Binary-only NMUs are a necessary evil.  The implementation kind of
> sucks, but I'm not sure how a better approach would look like.  It's
> not just the dependencies problem, it's also quite confusing that
> you've got a source package which builds different binary package
> versions on different architectures (but their are other ways to
> achieve that).  For instance, this pretty much rules out precise
> tracking based on binary packages.

The resulting .changes will get a field like this:

  Source: bacula (1.38.11-7)

which can be used to track back from which source this binary
originated. Or are you referring to something different?

regards,
guillem


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

Re: Where did Bacula 1.38.11-7+b1 come from?

[Guillem Jover]

On Fri, 2007-02-23 at 19:13:09 +0100, Florian Weimer wrote:
> * Guillem Jover:
> > The resulting .changes will get a field like this:
> >
> >   Source: bacula (1.38.11-7)
> >
> > which can be used to track back from which source this binary
> > originated.
> 
> Yeah, but this only helps if you've got a source version to compare
> to.  You could derive that from a binary version if you've got the
> corresponding Package entry, but this information might not be
> available anymore when you need it.

Sorry if I was unclear, but this field with that information is present
in the binary packages and then exposed through the Packages file. It's
even on dpkg's status file.

> Furthermore, it's not particularly useful to address the
> inconsistencies added by binNMUs when there are other problems.  Some
> binary packages have different version numbering schemes on different
> architectures, or they are built from different source packages.

The only current problem I see from the binNMU implementation in dpkg
is that packages that have a different source version than the one for
the binary packages will not receive a proper binNMU version as those
package generate the version manually, neither the binary:Version will
be correct, as we'd have to introduce a binary::Version or
similar to be able to deal with those. Given the small amount of
packages doing this I decided to implement something that'd work for
almost all packages except for the few odd cases, that would be
problematic anyway now. This could be fixed in the future if there's
a pressing need.

regards,
guillem


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

Re: Second call for votes for the debian project leader election 2007

[Guillem Jover]

On Thu, 2007-03-29 at 10:28:34 -0600, Oleksandr Moskalenko wrote:
> It is really this simple to do using mutt.
> 
> 1. To encrypt the vote you need to have the key. It could be accomplished in
> several ways. They way I did it was by copying
> 
> from the call for votes email into a file such as foo.txt and running
> 
> $gpg --import foo.txt

You might want to use ^K from inside mutt, instead.

regards,
guillem


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

Re: Use bz2 not gz for orig.tar ?

[Guillem Jover]

On Thu, 2007-04-12 at 12:12:00 +1000, Drew Parsons wrote:
> Do we have plans for lenny to enable the use of bzip2 instead of gzip
> for the upstream orig.tar source tarballs?  Does dpkg/apt support this
> already or has this already been thought about?

As other people have replied etch's dpkg supports unpacking source
and binary packages with gzip, bzip2 and lzma. The compression support
will probably be added in 1.14.1 or so alongisde Wig&Pen. There's few
items still pending before the 1.14.0 release.

regards,
guillem


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

Re: Bug#420344: ITP: swingx -- Extensions to the Swing GUI toolkit

[Guillem Jover]

Hi,

On Sat, 2007-04-21 at 20:00:10 +0200, Torsten Werner wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Torsten Werner <[EMAIL PROTECTED]>
> 
> * Package name: swingx
>   Version : 20070415

Take into account that if upstream later on changes the version to
something not date based you might have to use an epoch.

regards,
guillem


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

Re: Inactive maintainer (package: libguichan0)

[Guillem Jover]

Hi,

On Sat, 2007-05-05 at 09:17:43 +0200, Patrick Matthäi wrote:
> Now I have complained an offical report at the dbd about it:
>   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=421859
> But without any answer.

This bug report has only been filed 3 days ago...

regards,
guillem


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