Re: Should #1033656 be fixed on stable ?

[Henrique de Moraes Holschuh]

On Thu, Aug 31, 2023, at 09:36, Mathieu Malaterre wrote:
> I messed up src:highway on armhf (neon-less system). This makes the
> package unusable on those systems.
>
> Should I prepare an upload for stable-updates ?

Yes, but make it minimal if you can.   The bar to introduce newer versions in 
stable is far higher.

-- 
  Henrique de Moraes Holschuh 

Re: Cleaning up after 'gbp buildpackage'

[Henrique de Moraes Holschuh]

On Sun, 08 Jul 2018, Daniele Nicolodi wrote:
> On 08/07/2018 19:28, Henrique de Moraes Holschuh wrote:
> > On Sun, 08 Jul 2018, Daniele Nicolodi wrote:
> >> After a successful package build done with 'gbp buildpackage' the
> >> package directory is left in a state which requires to run 'debuild --
> >> clean' before being able to build the package again.
> > 
> > Packages must be buildable several times in a row *without* the need to
> > *manually* call the clean target.
> > 
> > If it needs intermediate cleaning, arrange for it to detect and do so
> > automatically.
> 
> The package builds just fine without intermediated cleaning, it is just
> gbp that complains about uncommitted changes to the source tree. That's

I see.  Yeah, that's gbp trying too hard to protect you from yourself :(

You can, of course, configure it to never warn, but then you lose that
last line of defense.

-- 
  Henrique Holschuh

Re: Cleaning up after 'gbp buildpackage'

[Henrique de Moraes Holschuh]

On Sun, 08 Jul 2018, Daniele Nicolodi wrote:
> After a successful package build done with 'gbp buildpackage' the
> package directory is left in a state which requires to run 'debuild --
> clean' before being able to build the package again.

Packages must be buildable several times in a row *without* the need to
*manually* call the clean target.

If it needs intermediate cleaning, arrange for it to detect and do so
automatically.

-- 
  Henrique Holschuh

Re: Explicit Autoconf disables

[Henrique de Moraes Holschuh]

On Tue, 03 Jul 2018, Ferenc Wágner wrote:
> When building packages in clean chroots many configure checks are
> expected to fail not finding their dependencies.  This is fine.  Until
> somebody tries to build the package in a not so clean chroot, where the
> additional packages present satisfy some of these checks enabling extra
> features.  Or even breaking the build by exposing bugs (see #874600 for
> an example).
> 
> Is adding all possible --disable-whatever options to the configure call
> a good practice?  It clutters debian/rules, isn't easy to do
> exhaustively in an obviously correct way, but protects against some
> changes in the build environment.  I'm interested in hearing your takes
> on the issue.

You could disable them in configure, yes.  But often this is addressed
as build-conflicts, instead.  Especially when you're not going to
*really* test if the end result with the undesired dependencies
installed but the feature disabled in configure.

Which one is best depends really on how easy you want to make for people
to selectively enable these features on local rebuilds.

-- 
  Henrique Holschuh

Re: how best to package when using hardware vectorization with vector-unit specific code?

[Henrique de Moraes Holschuh]

On Wed, 10 May 2017, Kay F. Jahnke wrote:
> I had something simpler in mind. I had hoped that a debian package would
> provide some sort of target-side script which is run when the application
> deploys with the user. Then it would be easy to have a bit of code à la

Cannot be done [easily] for newer stuff like avx because ld.so and the
kernel never got updated properly to do it.

> #! /bin/bash
> 
> for instruction_set in mmx sse sse2 sse3 ssse3 sse4 sse4a sse4.1 sse4.2 avx
> avx2 avx512f avx512pf avx512er avx512cd
> do
>   if [[ $( lscpu | grep $instruction_set ) ]]
>   then
> bestarch=$instruction_set
>   fi
> done
> 
> mv myprogram_$bestarch $target_bin/myprogram

You can do it like that, yes.  I suggest you go with that option.

> ... and optionally delete the binaries for the other ISAs.

If they are large enough to matter, separate them in several binary
packages.  Otherwise, don't bother.  Note that the list of variants
needs to be binary-package-arch specific.  mmx is i386-only, avx is
amd64-only, etc.

> I am using Vc, so whatever Vc supports, my software supports as well. Vc is
> a generic C++ library to abstract away the architecture, so I just compile
> with -mmx -sse or whatever and Vc adapts and produces the code for the
> specific target. I've coded so that my program will also run without using
> the vector units, this is done by simple #ifdefs, and I pass the definition
> in via a -D directive (or I don't, to produce code without vectorization).
> Alternatively Vc can produce a scalar interpretation of the vector code
> which runs on any platform and is equivalent.

Eh, yeah, that would make it far more difficult to use FMV.   But maybe
you should suggest Vc upstream to consider supporting FMV where
available?

-- 
  Henrique Holschuh

Re: Problems with autoconf in pftools

[Henrique de Moraes Holschuh]

On Mon, Mar 27, 2017, at 17:28, Andreas Tille wrote:
> Thanks.  This helped over the autoconf hurdle.  However, it sounds
> pretty strange why documented functions stop working since an extra
> macro set is missing.  I'd call this bad (broken at design).

Meh, no opinion on the design being broken or not, but it is a best
practice to fully document all your autofoo dependencies textually
somewhere, be it at the top of configure.ac, or in
autogen.sh/bootstrap.sh, or in some sort of README or INSTALL file.

Also, it is a best practice to distribute the copies of the
autoconf-archive macros used by the project under m4/ (or some other
subdir where the project stores its own autoconf macros, refer to
AC_CONFIG_MACRO_DIR) for aclocal to pick them up when autoreconf'ing.

Note that autoconf macros sourced from the autoconf archive have a
standard header and they're versioned.  There is no automated machinery
to refresh them when outdated either upstream or in debian (no,
autoreconf doesn't do it), so it has to be done manually.  Don't
downgrade such a macro, unless you really know what you are doing.

-- 
  Henrique de Moraes Holschuh <h...@debian.org>

Re: Can debian/pkg.triggers wait for another package's systemd unit file?

[Henrique de Moraes Holschuh]

On Wed, Dec 7, 2016, at 22:13, Patrick Schleizer wrote:
> a script in my debian/pkg.triggers depends on another package's systemd
> unit being active.

Which is really strange by itself...

> Is it possible to delay my package's trigger until the other package's
> systemd unit has been restarted?

It would be a gross layering violation, which is assured to cause a lot
of trouble.

Can you describe exactly what the two packages are, what you are
attempting to do, and why?

-- 
  Henrique de Moraes Holschuh <h...@debian.org>

Re: Convert debian/pkg-name.triggers into systemd unit file?

[Henrique de Moraes Holschuh]

On Wed, Dec 7, 2016, at 22:15, Patrick Schleizer wrote:
> is it possible to convert a debian package trigger into systemd unit
> file?

What are you trying to do?

-- 
  Henrique de Moraes Holschuh <h...@debian.org>

Re: Modernizing the upstream tarball without version number change

[Henrique de Moraes Holschuh]

On Sat, 12 Nov 2016, Christoph Biedl wrote:
> * Fake a new upstream version number, like foo_1.0a.orig.tar.xz.
>   Yes, it's faking. Using "+repack" is more obvious but still means
>   this gets carried into the Debian version number.

This is the recommended way of doing things, yes.

> * Switch upstream tarball compression. This works, I found an upload[3]
>   where -2 switched from .gz to .xz. Still rather a hack[4], and if this
>   means going away from xz to something older, it feels wrong.

This is going to get people wondering what you were up to.  Don't do it.

-- 
  Henrique Holschuh

Re: Best GPG practices before sending computer to maintenance.

[Henrique de Moraes Holschuh]

On Sat, 12 Nov 2016, Eriberto Mota wrote:
> There is another point to be considered: the RAM memory. The data,

Eriberto, would a full pass of memtest86 work as well?

It is supposed to test the entire RAM in destructive mode, and it does
use a lot of very nasty bit-walking patterns to do it, even...

-- 
  Henrique Holschuh

Re: Best GPG practices before sending computer to maintenance.

[Henrique de Moraes Holschuh]

On Sat, 12 Nov 2016, Paul Wise wrote:
> On Sat, Nov 12, 2016 at 1:26 PM, Johannes Schauer wrote:
> > If you are just worried about GPG, then removing .gnupg should be all you 
> > need
> > to do.
> 
> Deleting files does not remove the data from the block device, it only
> removes metadata.

It is pretty much impossible, short of using the secure erase features
of an SSD and trusting it to implement that correctly -- or using
undocumented SSD firmware bypass commands, which might not even exist in
the first place, etc -- to get an SSD to really erase data from the RAW
flash.

> Even overwriting the block device does not necessarily remove them from an 
> SSD:

In any SSD worth something, overwriting a sector will *never* remove the
old data, as it will always be directed to some other flash block.  It
just schedules the old block for eventual garbage collection and
erasure.

Even trimming a sector won't erase the flash.  The only thing that is
supposed to work is to command the SSD to secure-erase itself, and that
depends on the manufacturer doing its job right in the first place.

Alternatively, using dmcrypt-based FDE, and trashing the encryption key
will give you an erase level that is at least as strong as the strength
of your passphrase.

> I strongly suggest removing the SSD before sending the device.

Indeed.

-- 
  Henrique Holschuh

Re: Build a sort-of-systemd-dependent package on kfreebsd

[Henrique de Moraes Holschuh]

Cc'ing the entire message to debian-mendors. Sorry for the screw-up, I
CC'd something that did not have enough context for any useful help.

On Tue, 08 Nov 2016, Alec Leamas wrote:
> We are about to push the new lirc to stable. As-is, the package declares a
> dependency on systemd and thus rightfully fails to build on kfreebsd
> platforms. This is a pity since the core software lirc builds fine at least
> on FreeBSD 10.3.
> 
> However, lirc contains all sorts of systemd stuff: tweaks in
> rules/dh_auto_install, systemd configuration files, one or two tools. The
> configure script copes with all this and builds a different set of files on
> freebsd.
> 
> I'm now trying to wrap my head around how to conditionalize a packet such as
> lirc. I'm coming from Fedora/RPM and used to just spread some
> %ifarch in the spec file. Now, is something similar possible in debian?
> 
> In particular:
>   - How can I handle that kfreebsd should install a different set of files?
>   - Is it possible to conditionalize the rules file w r t platform?
>   - If so, how?

-- 
  Henrique Holschuh

Re: Build a sort-of-systemd-dependent package on kfreebsd

[Henrique de Moraes Holschuh]

On Tue, Nov 8, 2016, at 10:39, Alec Leamas wrote:
> I'm now trying to wrap my head around how to conditionalize a packet 
> such as lirc. I'm coming from Fedora/RPM and used to just spread some
> %ifarch in the spec file. Now, is something similar possible in debian?

It should be possible, yes.  I am not the best one to explain how, so I
will leave the actual answer to someone that could do it better.  

That said, I think you could get either better (or faster) help on
debian-mentors@lists.debian.org (which I added to Cc:). It is a list
specific to help new maintainers, and doubts about packaging corner
cases are routinely handled there.

-- 
  Henrique de Moraes Holschuh <h...@debian.org>

Bug#839114: RFS: [ITA] Hi, I'd like to adopt systemd-shim

[Henrique de Moraes Holschuh]

On Thu, 29 Sep 2016, Ab B wrote:
> I've only looked at ubuntu but it seems like it's maintained at least
> there.  It looks like mint 15 which dw says is the most popular distro
> seems to use it.

It is gone from Ubuntu.  It will not be present in their next stable
release, refer to https://launchpad.net/ubuntu/+source/systemd-shim

AFAIK, that means the maintenance it will get in Ubuntu will be the
usual for deep-maintenance-only mode packages in stable releases, i.e.
security fixes and critical issues only.

> And I think your predictions sound a little dire.  I'm no expert but
> systemd does seem to be a very active project, which made me
> concerned, but their external interfaces are fairly stable.  That
> leads me to hope that maintaining a shim will require a lot less
> effort than it could in a scenario like the one you suggest.

The shim is not perfect, and cgmanager is also missing functionality...
should that cause important issues, it needs fixing and improvements
upstream.

> If upstream wants to pass the torch and someone takes it up that's
> great.  If upstream just drops the project, then, well, that's a
> problem for ~14k debian users and a lot more users from other distros.

AFAIK, there are no users from other distros.  Derivatives *usually*
don't count as help for this kind of package: they depend on the work
done by either Debian or Ubuntu.  And it has just lost all Ubuntu
derivatives such as Linux Mint, along with Ubuntu.

> One thing I'd like to do is reach out to sysd-shim maintainers in
> other distros.

I wish you good luck with that.  I don't even know of any non-derivative
distros that use systemd-shim...  maybe some of the Debian derivatives
will be interested in helping, but usually that would mean they would be
doing the work in Debian directly already.

> But, in the end, sysd-shim seems to be a fairly recent release.  I'd
> like to try to nurse it along for the next couple of months and see
> how things go.

Eh, as long as you actually know what you are signing up for.  If you
want an easy package, *this one is not going to be it in the long run*
unless someone else helps with the upstream side, that is.

This assumes the current upstream did not have a change of heart and is
now enthusiastic about maintaining systemd-shim or something ;-)

> I personally don't have any plans right now to take over upstream, but
> maybe that will change if I get more familiar with the code.

That would be really nice, yes.  I hope you will do it.

-- 
  Henrique Holschuh

Bug#839114: RFS: [ITA] Hi, I'd like to adopt systemd-shim

[Henrique de Moraes Holschuh]

On Wed, 28 Sep 2016, Ab B wrote:
>   Hello.  I'd like to adopt the systemd-shim package.  I suppose I
> would need a sponsor/mentor to do that?
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832508

Read that bug report again, especially this part:

"The upstream branch is currently at
.  Allison isn't interested any
more in this either, so I suggest that the upstream repo gets mothballed
and systemd-shim just becomes a Debian-native package (I'm not aware of
any other distro using it anyway)."

> Hopefully this will be a fairly low-effort package requiring only
> sporadic attention.

It is the exact opposite.  It is reported to be effectively Debian-only
and needs a new *upstream*.  There is the cgmanager angle as well, which
is very relevant to the results of using systemd-shim, and quite
non-trivial (and it is also upstream work).

A team that is willing to put a lot of upstream-level work into keeping
the whole alternative-to-systemd stack is what this (and the related
packages) need :-(

-- 
  Henrique Holschuh

Re: How to specify a generic architecture to GCC (Was: SSE3 issue with iqtree when trying to enable i386)

[Henrique de Moraes Holschuh]

On Tue, 28 Jun 2016, Andreas Tille wrote:
> I admit I can not answer the question asked by upstream.  The package in
> question is iqtree[1] and they said that they have different
> computational kernels implemented to respect different hardware.
> Current Git[1] does not even build - may be due to some fine tuning of
> gcc options needed???
> 
> Any help is welcome

Well, for Debian unstable/next stable, we will have gcc 6, where you can
actually use FMV to fix this kind of issue sort of "automatically".  But
it is unbackportable (without a full backport of glibc and gcc 6).

https://lwn.net/Articles/691932/

But apparently iqtree is already capable of doing something like FMV on
its own, so you would not need to do the above, and the issue is with
the build tooling.

gcc doesn't much care if the build machine has the same subarch,
instruction set, or even architecture as the code it is compiling, so
you could build SSE3 binaries on a box without SSE3 support easily.

However, that only works when the *build scripts* do not try to run any
code they compiled in the build machine, or when they clearly separate
building build-tools (which will be run in the build machine during the
build) from the build-targets (which are going to be run only when
installed in the target system) and let you use different gcc and
C/LD/CXX/CPPFLAGS for each situation (i.e. are cross-compilation safe).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: reason not to upload new versions as fast as possible to unstable? (expect attempt to migrate to testing )

[Henrique de Moraes Holschuh]

On Fri, 12 Feb 2016, Adam Borowski wrote:
> On Fri, Feb 12, 2016 at 01:21:06PM +0100, toogley wrote:
> > the wicd package currently has version 1.7.3 in unstable and testing, but
> > 1.7.4 is already imported. Generally speaking it seems to me very reasonable
> > to try to upload versions as fast as possible into unstable and testing, so
> > I'm just asking for clarification:
> > 
> > Apart from wanting to migrate a version from unstable to testing, is there
> > any reason not to upload new upstream versions as fast as possible?
> 
> Possible reasons to tone down uploads:
> * truly excessive frequency (like, dailies for more than a few days in a
>   row)
> * interfering with a transition
> * during freeze
> * libreofficeish build times
> * huge tarballs

Let's not forget "Insufficient testing".   If the maintainer did not have
enough time to test the package properly, it is probably a good idea to
delay the upload.

One is not supposed to upload untested crap to unstable ;-)  untested
goodness will be fine, but only because nobody will know it wasn't properly
tested in the first place.

> Doing two uploads in a row is perfectly fine.

Yeah, but it is a lot less fun when the second upload is of the "brown
paperbag" kind.  Been there, done that... Not fun!

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: What to do with a kernel bug which lets my package work result look bad ?

[Henrique de Moraes Holschuh]

On Sun, 06 Sep 2015, Thomas Schmitt wrote:
> > Maybe it should instead drop the long name, and return the ISOFS name,
> > instead.
> 
> This might reduce the probability of a name collision,
> but can still collide with some short Rock Ridge name.

Any name we return can colide, unless we return something that is impossible
for isofs + extensions to return in the first place.

> Better would probably be a hash text derived from all
> available information about the file, which is not very
> much at that level of code, i fear.

We could do that, yes.

> But the actually needed fix is the protection of the
> innocent.

Yes.  It matters little what kind of insanity results from a corrupt/broken
filesystem, as long as we defang it enough for it to not be a viable way to
attack userspace apps.

> > However, one has to check the code throughoutly to ensure it can deal with
> > the 255-bytes size.
> 
> Will dive into the code and already began to read
>   http://kernel-handbook.alioth.debian.org
> 
> Maybe i can make experiments with s/254/256/ and/or
> with truncation to exactly the assumed maximum size.

Just add a strncat or something like that to add as much as possible from
the current chunk, but ensure the end result is no bigger than 255 chars +
NUL, and that it is in fact always NUL-terminated.

I'd check the buffer size where the chunks are being copied to first,
though.  It might be 255, in which case it needs to grow by a byte.

> > Opening a bug report on bugzilla.kernel.org for 'isofs' would be the typical
> > way to go about it, I guess.
> 
> Shall i do already now or better after i exhausted my code reading
> skills and/or managed to get a kernel running with s/254/256/ ?

You can open that report at any time, and send anything you discover as well
as debugging/fix patches to the bug report.

A minimal ISO image that shows the bug would be a nice attachment to the bug
report, too.

> > OTOH, it is a >10-year old bug, so there are some kudos and credit to be
> > proud of for anyone that fixes it :-)
> 
> Is there a find-the-oldest-bug contest ?

Not that I know of, it is just a lot cooler than fixing recent bugs :p

> And is the list open for mere oddities, too ?
> (I have some Linux timestamp peculiarities of which i really
>  don't know whether i shall replay them in libisofs.)

I wouldn't know.  If it is caused by the usual POSIX braindeadness coupled
to some particular filesystem's timestamp precision, well...

OTOH, if it is a bug that can be either fixed or documented (when fixing it
would end up causing worse damage), it might be interesting.

> To our luck there are userland tools to read ISO 9660
> independently of the kernels. Among them is my xorriso.

Indeed...

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: What to do with a kernel bug which lets my package work result look bad ?

[Henrique de Moraes Holschuh]

On Sat, 05 Sep 2015, Thomas Schmitt wrote:
> packages (*), i stumbled over a bug in fs/isofs/rock.c which
> truncates filenames of length 254 or 255 to quite random
> lengths and thus can let readdir(3) emit multiple identical
> names in the same directory.

Ugh.  Yeah, that code looks broken at first glance.  Looks like it doesn't
try to return as much as possible of a file name when it hits the character
limit: it seems to just end the filename at the previous chunk.

Maybe it should instead drop the long name, and return the ISOFS name,
instead.  Nasty crap will, of course, happen if there is a
colision between the two namespaces.  I don't know enough about Rock Ridge
to know whether it mandates something specific in this regard.

Whatever is done to fix this, it needs to properly handle 255-byte file
names, anyway.  A simple fix at first glance would be to append enough of
the current chunk to hit exactly the 255-byte boundary, and truncate at that
point.  This would fix the issue for all valid ISOFS+RRIP filename sizes.

However, one has to check the code throughoutly to ensure it can deal with
the 255-bytes size.  If it doesn't, that's a separate bug that needs fixing.

> What to do now with this knowledge ?

Opening a bug report on bugzilla.kernel.org for 'isofs' would be the typical
way to go about it, I guess.  You could just report in LKML as well, but
then you must ask again should nobody reply after two weeks, etc.

> Does Debian have a kernel department ? With round tuits ?

We do, but they're often overworked.  You can file a bug in the Debian BTS
against the "linux" source package, which is the kernel.

> (On LKML they will at best urge me to fix it myself.

They'd like you to do that, I suppose, since nobody is really working on
ISOFS.  But this is a clear bug that hits legal filesystems, so it is not a
"fix it yourself" deal.  It MIGHT be a "fix it yourself if you want it done
anytime soon", though :-(

OTOH, it is a >10-year old bug, so there are some kudos and credit to be
proud of for anyone that fixes it :-)

>  ISO 9660 driver. This constant "254" might have a good
>  reason. Who can tell ?)

Most of the RRIP support in Linux ISOFS predates git (2.6.11/2.6.12), which
kinda means in practice that you are better off analysing the code in depth
to find out its limitations (and fix them).

The code in fs/isofs/rock.c looks like it has lots of cowebs and some
bitrot, though.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Bug#797771: RFS: [ITP] tzlocal/1.2-1

[Henrique de Moraes Holschuh]

On Wed, 02 Sep 2015, Edward Betts wrote:
>  * Package name: tzlocal
> 
> It builds those binary packages:
> 
>   python-tzlocal - tzinfo object for the local timezone
>   python3-tzlocal - tzinfo object for the local timezone (Python 3 version)

I usually don't bother with this for source packages, but "tzlocal" is a
name with high chances of creating annoying colisions.

Since this source package is extremely unlikely to ever create non-python
packages, maybe you should name the source package also "python-tzlocal"?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Bug#797771: RFS: [ITP] tzlocal/1.2-1

[Henrique de Moraes Holschuh]

On Thu, 03 Sep 2015, Gianfranco Costamagna wrote:
> The question was actually:
> 
> do you think we should rename now that is in the new queue?

Yes, it is not too late.

> we can upload as soon as it is accepted, or ask ftpmasters to kick it out
> and upload again.

I think it is likely better to ask them to remove the upload with the
"wrong" name and upload it again.  That way, a package with the "tzlocal"
name will not have existed in any of the archives (outside of NEW) for any
length of time.

> Not sure this new upload will automatically override the existing one.

I am not sure, either.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Bug#797771: RFS: [ITP] tzlocal/1.2-1

[Henrique de Moraes Holschuh]

On Thu, 03 Sep 2015, Gianfranco Costamagna wrote:
> Hi Henrique,
> 
> Do you think we should rename it?

Yes, otherwise I would not have suggested it :-)

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Bug#784304: RFS: xerces-c/3.1.2+debian-1 [ITA] -- validating XML parser library for C++

[Henrique de Moraes Holschuh]

On Tue, May 5, 2015, at 01:27, Bill Blough wrote:
   * Added lintian overrides for issues that won't be fixed right now:
   no-upstream-changelog, no-symbols-control-file, shlib-calls-exit
   * Added lintian override for false positive (hardening)

Please don't add lintian overrides for real problems just because
they're not going to be fixed soon.

In this case, adding the hardening lintian override would be correct
(assuming it really is a false-positive -- make really really sure it is
a false positive before you add such an override), but the other ones
are best not overriden.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique de Moraes Holschuh h...@debian.org


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1431027418.882425.264144661.0d051...@webmail.messagingengine.com

Bug#773861: Signify - OpenBSD's cryptographic signing tool

[Henrique de Moraes Holschuh]

On Tue, 13 Jan 2015, Riley Baird wrote:
 On 12/01/15 12:37, Brian White wrote:
  I don't maintain Signify it any longer (or even use it) so feel free to do
  with it whatever you like.
 
 Hmm... does that mean that I need to adopt signify before
 signify-openbsd will be accepted?

Well, you cannot take over its package name without a transition that will
take at least one stable-release, either (so, it is a long-term thing).
Otherwise, you will regress the systems that have the old package installed
(and want it).

We went through one such package-name-swap recently, involving the old git
package becoming gnuit, and the old git-core package becoming git.  You can
ask the people involved for the details.

While signify's popcon is low, it is still non-zero and the kind of thing
that is going to be hooked inside a crontab or login script.  So, a
transition of some sort is required to avoid breaking things for its users.

And if the transition also involves renaming /usr/bin/signify, not just the
package's name, it also needs to be handled with care.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150113104051.ga30...@khazad-dum.debian.net

Re: package libpsl needs a new sponsor

[Henrique de Moraes Holschuh]

On Fri, 28 Nov 2014, Tim Ruehsen wrote:
 Hi, I am the author and maintainer of libpsl, a dependency of package wget.
 
 So far Daniel Kahn Gillmor has been the sponsor. He has not responded to my 
 emails asking him to upload a new version of libpsl (last one 17.11.2014).
 Now I am looking for a new sponsor.
 
 The latest uploaded/packaged version is 0.5.1-1.
 The latest release version is 0.6.2 which fixes an issue that should IMHO go 
 into the upcoming Jessie. (It corrects a failure in the pkg-config file which 
 prevents proper detection of libpsl presence.)
 
 The packaging is done and needs review and uploading.
 It can be found in a git repository (https://github.com/rockdaboot/libpsl,  
 branch 'debian').
 
 If there is anything else I can do, please give me a hint.

Jessie is in freeze, entering deep freeze in a few days.

Prepare a fully-justified request for a release unblock, otherwise it is
pointless to upload to sid (experimental is OK).

It must have a full description of the reasons for the change, the diffstat
of the debdiff, and a debdiff.  I usually abridge from the debdiff any noise
such as updates to automatically-generated files/buildsystem (configure,
config.sub/guess, etc).

It is likely that it would be better to just patch 0.5.1-1 with the
pkg-config change, unless the changes between 0.5.1 and 0.6.2 upstream are
all simple and only bugfixes.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141128143639.ga25...@khazad-dum.debian.net

Re: package libpsl needs a new sponsor

[Henrique de Moraes Holschuh]

On Fri, 28 Nov 2014, Tim Rühsen wrote:
   The latest release version is 0.6.2 which fixes an issue that should IMHO
   go into the upcoming Jessie. (It corrects a failure in the pkg-config
   file which prevents proper detection of libpsl presence.)

...

  It is likely that it would be better to just patch 0.5.1-1 with the
  pkg-config change, unless the changes between 0.5.1 and 0.6.2 upstream are
  all simple and only bugfixes.
 
 Well, I could open a few bug reports to libpsl (which already have been fixed 
 upstream)... but it seems pretty pointless ;-)

Please open one about the pkg-config issue, describe it well, and tag it
fixed-upstream...

 I guess you are all pretty busy... I am not in a hurry and will wait for the 
 unfreeze.

If you feel the pkg-config issue is serious enough to warrant the work, and
you're really really fast at preparing a 0.5.1-2 package with the pkg-config
(and debian/changelog) as the only changes, it is probably possible to get
that into Debian jessie (the next Debian stable release).

 Sorry for being a bit clueless about Debian organisation. It's the first time 
 I 
 came in contact with it.

It is usually much easier than this to get fixed packages in Debian, but
we've frozen jessie to fix only the remaining bugs, so there are some rather
draconian fixes only policies in effect right now.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141128222453.ga6...@khazad-dum.debian.net

Re: Depends on exact version

[Henrique de Moraes Holschuh]

On Wed, 12 Nov 2014, Henrique de Moraes Holschuh wrote:
 On Wed, 12 Nov 2014, Roger Light wrote:
  Could you try ${binary:Version} instead?
 
 (= ${binary:Version}) can break binNMUs.  Be careful.

binNMUs will cause a few of the binary packages to have a different
debian revision than the rest of the binary packages and the source
packages.

We have a lintian check for this, I think.

One seldom known detail is that the source package version is just a
*default* value for the binary package versions.  You can override it
during build.  It is not just binNMUs.

This is a valid scenario:

source package foo builds binary packages foo_data, foo_dt2, foo and
dt2.

source package: foo 1.2.3+setone-1

foo_data:all 1.2.3-1
foo_dt2:all  setone-1
foo:i386:  1.2.3-1
foo:arm64: 1.2.3-1+b1
dt2:i386: setone-1
dt2:arm64: setone-1+b1

All built from the same source, but both dt2 and foo were subject to a
binNMU later.  dt2 and foo have separate versioning.

This is not usual, but it is both valid and supported.

Here's a real life example: package hplip used to do this when hplip and
hpijs started being packaged together by upstream.  It took a while and
several releases before upstream moved hpijs to the same version
numbering as hplip.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141113110346.gd19...@khazad-dum.debian.net

Re: Depends on exact version

[Henrique de Moraes Holschuh]

On Wed, 12 Nov 2014, Roger Light wrote:
 Could you try ${binary:Version} instead?

(= ${binary:Version}) can break binNMUs.  Be careful.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141112233246.ga19...@khazad-dum.debian.net

Re: jessie freeze policy: about translation updates

[Henrique de Moraes Holschuh]

On Tue, 11 Nov 2014, bilibop project wrote:
 Jessie Freeze Policy [1] says that translation updates and documentation
 fixes that are included with fixes for the above criteria can be
 considered.
 
 What does exactly mean translation updates ? Does it include the add of
 new debconf .po files (i.e add support for a language that is not
 supported yet) as well as updates of the existing ones ?

Yes.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2014190241.gf2...@khazad-dum.debian.net

Re: about bug self-reporting

[Henrique de Moraes Holschuh]

On Mon, 10 Nov 2014, bilibop project wrote:
 I'm probably off-topic, but I fail to find the proper debian list for this 
 issue:

-mentors or -devel are fine.

 I've found two bugs in packages I maintain: an important bug in an optional
 package, and a RC bug in another package. Nobody has reported them. The
 Freeze Policy [1] says that the fixes for these bugs may be included in 
 jessie.
 My question is: is it welcome to file a bug report against my own package ?

Yes.  But you should make it an exemplary bug report: concise, complete, and
as bias-free as possible :-)

In fact, when you come across a grave or critical issue in your package, you
should file a bug immediately (to warn others), and then proceed with the
fixing...

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141110104339.gb12...@khazad-dum.debian.net

Re: getdns NMU

[Henrique de Moraes Holschuh]

On Fri, 24 Oct 2014, Jakub Wilk wrote:
 But anyway, this workflow seems completely reasonable to me:
 1) upload to mentors.d.n;
 2) have someone review the changes;
 3) have someone commit to upload the NMU;
 4) file a bug (or post to existing bug) stating your intention to NMU.
 
 This is how I did NMUs before I was a DD, and this is how I expect
 non-DDs to NMU my packages.

To avoid wasted work, I suggest that we recommend this, instead:

[for NMUs made through debian-mentors]:

1) add a notice to the relevant bug reports in the BTS stating
   that you are preparing an NMU through debian-mentors

   (if there is no such a bug, open one.  You will reuse it
for step 5.  Title it package: intent to NMU: reasons for the NMU).

2) upload to mendors.d.n.
3) have someone review the changes, repeat steps 2 and 3 as necessary
4) have someone commit to upload the NMU
5) file the NMU bug (if you had to create a bug report in step 1,
   reuse it.  Retitle it to follow the procedure for NMU bugs).

Seems friendly enough to all involved...

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141024134740.gd23...@khazad-dum.debian.net

Re: Build-depending on non-free package

[Henrique de Moraes Holschuh]

On Tue, 02 Sep 2014, Ole Streicher wrote:
 The policy manual says (2.2.2):
 
 | The contrib archive area contains supplemental packages intended to
 | work with the Debian distribution, but which require software outside
 | of the distribution to either build or function.
   ^^^
 
 Which lists a non-free build requirement as its first use case of contrib.

Yeah, but as I said, this doesn't mean it will be autobuildable. It won't
be, at least not yet.

  Contrib is well-suited to packages that require non-free data.  It has
  always had a problem when there are build-time dependencies on
  non-free.
 
 Sure. The bug #690282 is two years old. All I ask here is how this can
 be changed, or what the effective way is to support all platforms
 here -- especially for a DM without abusing his mentor.

It is not trivial to address this request.

It requires manually vetoing which packages from non-free are safe to be
used as contrib build dependencies (much like we manually veto what packages
from non-free can be autobuilt).

AFAIK, even if ftp-master decides to bless every non-free auto-buildable
package to automatically be an acceptable build-time dependency for contrib,
it will likely require autobuilder tooling changes to check for a
xs-autobuild: yes flag when resolving dependencies from non-free, or
something to that effect.

Chances are it won't happen anytime soon.

  Actually, for a *long* time we didn't even autobuild anything in contrib or
  non-free.
 
 So, the first step is done, but not the second?

Yes.  To be clear: AFAIK you currently have four choices:

1. Find a sponsor which will build it on the interesting arches.

2. Move it to non-free and get it vetoed as auto-buildable (requires that
   its license and the license of its non-free build-dependencies allow
   this).  This isn't really supposed to work, but AFAIK we trust people
   will not abuse it, so it should work.

3. Get rid of the non-free build-dependency.

4. Forget about providing pre-built binary packages for the other arches,
   and write a cookbook for your users to build the binary packages
   themselves from the debian source package.

   This can cause problems for testing migration.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140902145609.gc10...@khazad-dum.debian.net

Re: Build-depending on non-free package

[Henrique de Moraes Holschuh]

On Tue, 02 Sep 2014, Jakub Wilk wrote:
 * Henrique de Moraes Holschuh h...@debian.org, 2014-09-02, 11:56:
 2. Move it to non-free and get it vetoed as auto-buildable
 (requires that its license and the license of its non-free
 build-dependencies allow his).  This isn't really supposed to
 work, but AFAIK we trust people will not abuse it, so it should
 work.
 
 I don't think non-free packages build-depending on non-free packages
 can be currently built on buildds.
 
 I looked at a random build log from the non-free package I maintain:
 
 $ grep Packages cuneiform_1.1.0+dfsg-5_i386_1408375836.build
 Get:9 http://cdn.debian.net unstable/main i386 Packages [6888 kB]
 Get:12 http://incoming.debian.org buildd-unstable/main i386 Packages [299 kB]
 Get:13 http://incoming.debian.org buildd-unstable/contrib i386 Packages [32 B]
 Get:14 http://cdn.debian.net unstable/contrib i386 Packages [51.4 kB]
 Get:17 http://ftp.debian.org unstable/main i386 Packages [6887 kB]
 Get:18 http://ftp.debian.org unstable/contrib i386 Packages [51.4 kB]
 
 I don't see the non-free component enabled here.

Indeed.  I just checked the build logs for yet another non-free package
(intel-microcode) which is also auto-built, and it matches your observation.

Only main and contrib are allowed for build dependencies on auto-builders.
It looks like option (2) is out.  I was wrong about the it should work
part.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140902185714.ga21...@khazad-dum.debian.net

Re: Build-depending on non-free package

[Henrique de Moraes Holschuh]

On Thu, 21 Aug 2014, Ole Streicher wrote:
 Paul Wise p...@debian.org writes:
  On Mon, Aug 18, 2014 at 1:07 AM, Ole Streicher wrote:
  I am just looking for a solution for this problem...
 
  It might be easier to port the software to something that isn't
  non-free so the package can be put in main.
 
 As you can see from the bug, dependency from pgplot is quite common. It
 seems not so easy to have a free replacement for that.
 
 At the end, this is what contrib is for, isn't it?

Not really, although it can certainly be used like that (when autobuilding
doesn't get in the way).

Contrib is well-suited to packages that require non-free data.   It has
always had a problem when there are build-time dependencies on non-free.
Actually, for a *long* time we didn't even autobuild anything in contrib or
non-free.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140821121249.ga14...@khazad-dum.debian.net

Re: Build-depending on non-free package

[Henrique de Moraes Holschuh]

On Fri, 15 Aug 2014, Оlе Ѕtrеісhеr wrote:
 One more question:
 Jakub Wilk jw...@debian.org writes:
  * Оlе Ѕtrеісhеr debian-de...@liska.ath.cx, 2014-08-14, 09:46:
  I've uploaded a package to contrib [1], that needs a non-free package
  (pgplot5) as build dependency. While it builds nicely on my local pbuilder
  (after adding non-free), it fails to build on the buildds [2].
 
  This is bug #690282.
 
 Since in debian-devel has an ongoing discussion about source-only
 uploads: how will these cases handled then?

non-free will need an exception to enforced source-only uploads for packages
that cannot be autobuilt.

Whether contrib would get the same exception or not, it is too early to
worry about.  A maintainer can always request that packages be moved from
contrib to non-free when required due to operational or technical reasons.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140815121621.gb26...@khazad-dum.debian.net

Re: Build-depending on non-free package

[Henrique de Moraes Holschuh]

On Thu, 14 Aug 2014, Оlе Ѕtrеісhеr wrote:
 Russ Allbery r...@debian.org writes:
  Also, dak is canonical for priorities, and values in binary packages
  are only used on initial upload to set the initial override value.
  From that point forward, changes have to be made via bugs filed with
  ftp.debian.org.
 
 The package in question was initially uploaded.

Initial priorities are set by the ftpmaster that accepted the package from
NEW.  They may, or may not match the ones in the package's priority field.

i.e. that field is an _advisory_ field.

  It's possible that Policy could stand some work to make this clearer.
 
  or the process should be adjusted to follow the policy (at least
 this is what I would usually expect).

Debian policy does not dictate practice.  It documents best practice.  You
can deviate from it, but you must have really strong _technical_ reasons to
do so.

Archive priorities are at the sole discretion of the ftpmasters.  If
anything, debian-policy would be updated to match reality.

That said, if something *needs* source package priorities to work, I suppose
a case can be made that they should be set to that of the highest priority
binary package built from that source.  But that would be a dynamic
priority, set by dak (the archive software), I guess.  It really depends on
what the usecase for source package priorities would be.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140814183645.ga29...@khazad-dum.debian.net

Re: Autoreconfing guide

[Henrique de Moraes Holschuh]

On Fri, 18 Jul 2014, Wookey wrote:
 +++ Russ Allbery [2014-07-15 23:55 -0700]:
  Yavor Doganov ya...@gnu.org writes:
  
   I also wonder why debian/autoreconf is needed given that autoreconf
   is recursive.
  
  I don't think autoreconf can always figure out what to do when the files
  are buried in some random subdirectory without anything at the top level.
 
 Correct. It's generally when the source is in a subdir and there is
 nothing autotooly at all at the top level. Or when the package
 effectively contains two separate autoconf source trees in it.

Indeed.  In most cases, there will be a shell script somewhere (one of the
usual names is autogen.sh) that will call autoreconf with the appropriate
options.

 level. I don't know if it's possible to explain this layout to
 autotools, or if it's just something we should be telling upstream to
 stop doing? (I've been dealing with it by backing-up

Well, as long as there is an autogen.sh-style script somewhere in the
build tree that does this...

We ought to document locating and using these autogen scripts as a preferred
substitute to running autoreconf directly (this assumes upstream does use
the autogen script :-p).  There is no way to automate adding this to the
package, you have to customize debian/rules in a case-by-case basis, though.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140718225529.ga14...@khazad-dum.debian.net

Re: Autoreconfing guide

[Henrique de Moraes Holschuh]

On Fri, 18 Jul 2014, Russ Allbery wrote:
 Henrique de Moraes Holschuh h...@debian.org writes:
  Indeed.  In most cases, there will be a shell script somewhere (one of
  the usual names is autogen.sh) that will call autoreconf with the
  appropriate options.
 
 Be careful of those scripts.  Often they do other things that you don't
 actually want done, and they don't always regenerate everything.

True.  At some point you have no choice but to either pester upstream, or
document in README.source the stuff that needs to be verified manually at
every new upstream release :-(

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140718231753.gb14...@khazad-dum.debian.net

Bug#749152: RFS: top/2.2.3-1 [ITP]

[Henrique de Moraes Holschuh]

On Sat, 24 May 2014, Hugo Lefeuvre wrote:
  I am looking for a sponsor for my package top
 
 Package name: top
 Version : 2.2.3-1
 Upstream Author : Hugo Pereira Da Costa hugo.pere...@free.fr
 URL : http://hugo.pereira.free.fr/software/
 License : GPL2
 Programming lang: C++ / Qt5
 Section : admin
 
  It builds this binary package:
 
 top   - windowed version of the console top command

This is a massive namespace clash waiting to happen, and that's BAD.

It is also a very bad idea to have Top as the application binary.  You're
just a technicallity away from conflicting with procps, and this is no way
to do things.

Can you take this upstream and check if they'd be amiable to renaming this
to, e.g. qttop or something else that is not just a single camel-case
character away from top ?

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140524160430.gb12...@khazad-dum.debian.net

Bug#731036: RFS: think-rotate/3.0-1

[Henrique de Moraes Holschuh]

On Tue, 03 Dec 2013, Martin Ueding wrote:
  Mostly because the package would not contain the
  majority of the stand-alone thinkpad-specific tools and utils (such as tpb,
  thinkbat, thinkfan, etc).
 
 That is the problem, it is just screen rotation and docking. “-scripts”
 sounds like some assorted scripts, and does not feel like it is claiming
 to be complete like “-utils” would.

think-scripts (or thinkpad-scripts) is fine, IMHO.

However, please do be aware that we already have some thinkpad-specific
scripts or functionality in packages:

acpi-fakekey  (mostly to reroute input events into legacy acpi-like events)
acpi-support

So it is best to make sure there is no duplication, etc.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131204124556.gf17...@khazad-dum.debian.net

Bug#731036: RFS: think-rotate/3.0-1

[Henrique de Moraes Holschuh]

On Tue, 03 Dec 2013, Martin Ueding wrote:
 https://github.com/martin-ueding/think-rotate/issues/26
 
 It looks like there is no `thinkpad-` package in Ubuntu or Debian, but
 several with `think` in them. Does it really make sense to rename this
 to `thinkpad`, when there are other packages like `thinkfinger` and
 `thinklight`?

thinklight is the (trademarked!) name of a ThinkPad thinkvantage feature,
which I hope will come back someday, just like proper LCD screens came
back with the 2013/2014's series-40 (as long as you get a FHD/FHD+/3K IPS
screen, that is).

I don't know about thinkfinger, it is a bit of a misnomer as it is not even
thinkpad-specific in the first place.  I'd have complained about it had I
noticed it in time.

IMHO, the think-rotate naming is weird, but given that we accepted
thinkfinger, it is not a big deal.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131203173404.ga20...@khazad-dum.debian.net

Bug#731036: RFS: think-rotate/3.0-1

[Henrique de Moraes Holschuh]

On Tue, 03 Dec 2013, Martin Ueding wrote:
 Okay, “thinklight” does not count, then.
 
 The question is, whether using “thinkpad-” would cause any trouble with
 trademarks?

We'd need to ask a lawyer to get an useful answer to that question, I think.

 I think “thinkpad-utils” or “thinkpad-tools” or “thinkpad-scripts” is an
 improvement. Would those be okay with you?
 
 The problem is that it started as a single rotation script and then
 evolved into a collection of scripts that do docking, rotating and other
 stuff. The earlier the rename is, the less work it is.

I like thinkpad-scripts.

I think thinkpad-tools would not be a good idea, nor would
thinkpad-utils, though.  Mostly because the package would not contain the
majority of the stand-alone thinkpad-specific tools and utils (such as tpb,
thinkbat, thinkfan, etc).

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131203190126.gb20...@khazad-dum.debian.net

Bug#731036: RFS: think-rotate/3.0-1

[Henrique de Moraes Holschuh]

On Sun, 01 Dec 2013, Martin Ueding wrote:
  * Package name: think-rotate

Could you be persuaded to name this thinkpad-rotate ?

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131202142252.gb5...@khazad-dum.debian.net

Re: No relro when building from inside a Git package ?

[Henrique de Moraes Holschuh]

On Fri, 22 Nov 2013, Andreas Tille wrote:
 I further observed that it only happens if the dir is named .git.  I
 tried
 
 mv .git .tig
 cat  debian/source/include-binaries EOT
 .tig/index
 .tig/objects/pack/pack-0c4620137efe646d9d99b9b2b09b861e364bc678.idx
 .tig/objects/pack/pack-0c4620137efe646d9d99b9b2b09b861e364bc678.pack
 EOT
 
 debuild
 
 and the problem vanishes (the lintian warning vanishes and the file size
 is larger again == same as when using pdebuild).
 
 So lacking better advise I can only say:
 
   - just use pbuilder (simply closing the eyes for the issue)
   - evil grinuse svn instead of git/evil grin
 
 Now its time for you Git experts to solve this riddle.  I'm out.

Maybe something is doing git clean -f -x or worse, git reset --hard just
before the build run, and clobbering important build tooling configured
early in the build prepare process?  This would account for the changed
behaviour when .git is present and valid...

If this is an idiotic automatically clean using git misfeature somewhere,
it might not show up in a regular build log because git output is being
supressed.

strace should show the culprit easily...

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131122115109.gc27...@khazad-dum.debian.net

Re: Packaging for multiarch i386 sse2/non-sse2

[Henrique de Moraes Holschuh]

On Sun, 18 Aug 2013, Adam Borowski wrote:
 C - ship both versions on i386 and switch between them on runtime

The linker can select at runtime different sets of libraries depending on
some cpu flags.  I think it can do that for SSE2 just fine, you'd build two
libs: one without interesting intructions, and other with them, and place
them/name them appropriately for that to work, all in the same binary
package.

I think the glibc package does that, you might want to take a look at it.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130819003913.gb8...@khazad-dum.debian.net

Re: Packaging for multiarch i386 sse2/non-sse2

[Henrique de Moraes Holschuh]

On Mon, 19 Aug 2013, Wookey wrote:
 them use multilib paths to do this - they just use package naming so
 you choose whether to install 'libc6' or 'libc6-i686' (in the same

libc-i686 is multilib AND multiarch enabled:

/lib/i386-linux-gnu/i686/cmov/libSegFault.so
/lib/i386-linux-gnu/i686/cmov/libmemusage.so
/lib/i386-linux-gnu/i686/cmov/libanl-2.13.so
/lib/i386-linux-gnu/i686/cmov/libnss_nisplus-2.13.so
/lib/i386-linux-gnu/i686/cmov/libutil-2.13.so
/lib/i386-linux-gnu/i686/cmov/libpthread-2.13.so
/lib/i386-linux-gnu/i686/cmov/libBrokenLocale-2.13.so
/lib/i386-linux-gnu/i686/cmov/libpcprofile.so
/lib/i386-linux-gnu/i686/cmov/libdl-2.13.so
/lib/i386-linux-gnu/i686/cmov/libnss_files-2.13.so
/lib/i386-linux-gnu/i686/cmov/librt-2.13.so
/lib/i386-linux-gnu/i686/cmov/libnss_compat-2.13.so
/lib/i386-linux-gnu/i686/cmov/libm-2.13.so
/lib/i386-linux-gnu/i686/cmov/libnss_hesiod-2.13.so
/lib/i386-linux-gnu/i686/cmov/libcidn-2.13.so
/lib/i386-linux-gnu/i686/cmov/libc-2.13.so
/lib/i386-linux-gnu/i686/cmov/libcrypt-2.13.so
/lib/i386-linux-gnu/i686/cmov/libresolv-2.13.so
/lib/i386-linux-gnu/i686/cmov/ld-2.13.so
/lib/i386-linux-gnu/i686/cmov/libnsl-2.13.so
/lib/i386-linux-gnu/i686/cmov/libnss_dns-2.13.so
/lib/i386-linux-gnu/i686/cmov/libnss_nis-2.13.so
/lib/i386-linux-gnu/i686/cmov/libthread_db-1.0.so
/lib/i386-linux-gnu/i686/cmov/libnss_hesiod.so.2
/lib/i386-linux-gnu/i686/cmov/libcidn.so.1
/lib/i386-linux-gnu/i686/cmov/libdl.so.2
/lib/i386-linux-gnu/i686/cmov/libthread_db.so.1
/lib/i386-linux-gnu/i686/cmov/libnsl.so.1
/lib/i386-linux-gnu/i686/cmov/libnss_compat.so.2
/lib/i386-linux-gnu/i686/cmov/libutil.so.1
/lib/i386-linux-gnu/i686/cmov/libnss_files.so.2
/lib/i386-linux-gnu/i686/cmov/libresolv.so.2
/lib/i386-linux-gnu/i686/cmov/libnss_nisplus.so.2
/lib/i386-linux-gnu/i686/cmov/libcrypt.so.1
/lib/i386-linux-gnu/i686/cmov/libm.so.6
/lib/i386-linux-gnu/i686/cmov/libc.so.6
/lib/i386-linux-gnu/i686/cmov/libnss_nis.so.2
/lib/i386-linux-gnu/i686/cmov/libanl.so.1
/lib/i386-linux-gnu/i686/cmov/librt.so.1
/lib/i386-linux-gnu/i686/cmov/libnss_dns.so.2
/lib/i386-linux-gnu/i686/cmov/ld-linux.so.2
/lib/i386-linux-gnu/i686/cmov/libpthread.so.0
/lib/i386-linux-gnu/i686/cmov/libBrokenLocale.so.1

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130819021312.ga29...@khazad-dum.debian.net

Re: want to get involved to fix blt package

[Henrique de Moraes Holschuh]

On Tue, 22 Jan 2013, Paul Gevers wrote:
 On 22-01-13 04:26, Paul Johnson wrote:
  I just kicked up some dust about getting the blt package fixed for Wheezy.
 
 If you want this in Wheezy, please read the freeze-policy [1] and make
 sure that your package has minimal changes to fix the bug.

...

 I haven't looked, but from your description it seems too invasive for a
 freeze acceptation. It is probably ok for experimental.

And even if this is the case (i.e. can't go to Wheezy because the changes
are too big), it is still worthwhile because if the package gets fixed in
experimental, it can go to unstable and after a while, it can be uploaded
to wheezy-backports.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130122124028.ga21...@khazad-dum.debian.net

Bug#696600: RFS: sun/0.2-1 [ITP] schedule cron or at-jobs at sunrise/set

[Henrique de Moraes Holschuh]

On Mon, 24 Dec 2012, Paul Wise wrote:
 On Mon, Dec 24, 2012 at 7:45 AM, Steffen Vogel wrote:
 
  There still the problem that the package name (sun) might be too generic
  to be included in the archive. What do you think about this concern?
 
 I think sun is the perfect name for this tool and there is no need to change 
 it.

It is indeed too generic.  Better have a not-so-generic name NOW, than
problems later.

I'd go with sun-cron, or something like that.  Even daylight (which is
likely to also be too generic) would be better than sun, IMHO...

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121224015256.ga19...@khazad-dum.debian.net

Re: Upgrade rar Package Version

[Henrique de Moraes Holschuh]

On Fri, 19 Oct 2012, Martin Meredith wrote:
 It was refused by the maintainers of that for being to non-free

I see.  Well, it was worth a shot.  BTW, using pbuilder to set up i386 and
amd64 chroots helps a lot, at least here it has made it easy for me to do
dual-arch uploads, with two pbuilder calls, each one for a different arch
(and the second one with --binary-arch) and a mergechanges call...

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121019111928.ga12...@khazad-dum.debian.net

Re: Upgrade rar Package Version

[Henrique de Moraes Holschuh]

On Thu, 18 Oct 2012, Martin Meredith wrote:
 The problem with updating the rar package is not a problem with the
 complexity of the package, it's a case of it takes a while for me to
 put together the upload for both amd64 and i386 simultaneously, due to
 the autobuilders not liking non-free packages.

You want to read this.

http://lists.debian.org/debian-devel-announce/2006/11/msg00012.html

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121019001026.ga12...@khazad-dum.debian.net

Re: Moving /home of a package account, and to where?

[Henrique de Moraes Holschuh]

On Mon, 02 Jul 2012, Marc Haber wrote:
 On Sun, Jul 01, 2012 at 07:53:04PM -0700, Russ Allbery wrote:
  It would indeed be best if everything possible was documented, but very
  few people volunteer to do the work to drive changes to the documentation
  through to completion.
 
 This is partly because of the kind-of heavy-handed policy editorial
 process.

You're kidding, right?  Just file a bug with the proposed patch to the
docbook source.  It is _all_ that it takes more often than not.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120702154821.gd3...@khazad-dum.debian.net

Re: Moving /home of a package account, and to where?

[Henrique de Moraes Holschuh]

On Sun, 01 Jul 2012, Marc Haber wrote:
  Yes, but it's user configuration not system configuration.
 
 A system user's .ssh is user configuration?

If it is intended to be manipulated by the local admin, yes, and it would
belong in /etc somewhere.

  If you do want to have that as configuration in /etc, I'd
  suggest symlinking it from /var/lib/foo to /etc/foo/authorized_keys
  (or vice versa), like e.g. postgresql handles cluster configuration.
 
 Can you give a more visible example? Should /etc/foo/authorized_keys
 be a symlink to /var/lib/foo/home/.ssh/authorized_keys? I don't think
 that circumvents the FHS forbidding configuration in /var/lib just by
 making it accessible through /etc.

No.  The real file goes in /etc, the symlink goes in /var/lib.  But you may
need very tight permissions in the directory that hosts these to have sshd
tolerate it, if it will work at all.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120701153641.gg2...@khazad-dum.debian.net

Re: Moving /home of a package account, and to where?

[Henrique de Moraes Holschuh]

On Sun, 01 Jul 2012, Marc Haber wrote:
 On Sun, Jul 01, 2012 at 12:36:41PM -0300, Henrique de Moraes Holschuh wrote:
  On Sun, 01 Jul 2012, Marc Haber wrote:
Yes, but it's user configuration not system configuration.
   
   A system user's .ssh is user configuration?
  
  If it is intended to be manipulated by the local admin, yes, and it would
  belong in /etc somewhere.
 
 I would call that system configuration.

I suppose, since it is system-wide.

  No.  The real file goes in /etc, the symlink goes in /var/lib.  But you may
  need very tight permissions in the directory that hosts these to have sshd
  tolerate it, if it will work at all.
 
 Does sshd honor symlinks when looking for authorized_keys? I am really

Test it.

 really astonished about with which ease we hurl RC bugs at packages
 without having thought-out alternatives.

Sometimes you *really* have to do some heavy work to get something to
actually work sanely.  I've had to actually enhance upstream C code to
get it to be able to do things in a way that makes it easier to properly
package it.  Had to do it for fetchmail, Cyrus IMAPd, amavisd-new...

This is the Debian added-value.  We do what it takes to make it sane.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120701171023.gh2...@khazad-dum.debian.net

Bug#673096: RFS: figlet/2.2.5-1

[Henrique de Moraes Holschuh]

On Sat, 02 Jun 2012, Jonathan McCrohan wrote:
 [Whoops, missed this reply, it wasn't threaded properly.]
 On 02/06/12 20:26, Bart Martens wrote:
  Please remove the part (closes: #674844) from debian/changelog.  Bug 
  674844
  is for version 2.2.2-1 in stable.  That bug in stable is not solved by
  uploading version 2.2.5-1 to unstable.  Please keep 674844 open until 
  675167 is
  done.
 
 Fair enough. Will do.

The BTS is aware of versions, and as long as all relevant changelog entries
are kept as packages branch, it knows which version derives from which
version.

It will mark the bug fixed in unstable, and leave it unfixed in stable.

Jonathan, exactly why are you asking Bart to remove that closes in the
changelog?

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh



-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120603050124.ga9...@khazad-dum.debian.net

Bug#672394: RFS: ipset/6.12-1 -- administration tool for kernel IP sets

[Henrique de Moraes Holschuh]

On Tue, 15 May 2012, Neutron Soutmun wrote:
  * Are you sure about the location of the binary in the file system?
  iptables is in /sbin, why do you install ipset to /usr/sbin?
 
 The ipset depends on libmnl which it is installed in /usr/lib or
 /usr/lib/[arch triplet] if it willing support multiarch.

Please file a bug requesting that libmnl be moved to /

IMHO ipset can live in /usr/sbin until libmnl gets moved to /, but you
could also ship it already in /sbin from day one (and document in
readme.debian that it requires libmnl, which is currently in /usr/lib).

 I think, it's not appropriate to install ipset in /sbin when it's still
 depends on libmnl that installed in /usr.

That depends.  If it *is* going to get moved to /sbin, it is best to
already ship it in /sbin so that people don't start using
/usr/sbin/ipset or something...

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh



-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120515171326.ga14...@khazad-dum.debian.net

Re: Packaging where upstream only has a git repo

[Henrique de Moraes Holschuh]

On Sun, 22 Apr 2012, Michael van der Kolff wrote:
 Never mind, I found a real upstream.  Turned out the author moved
 development from github, but left no pointer :(

Write to him, introducing yourself as a downstream maintainer, and also tell
him the lack of a forwarding address in github is causing problems.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120422134904.gb10...@khazad-dum.debian.net

Re: Which git tool should I use?

[Henrique de Moraes Holschuh]

On Thu, 16 Feb 2012, Paul Elliott wrote:
 I am currently packaging several programs for debian. I would like to store 
 my 
 VCS stuff publicly. I have been granted access to collab-maint.
 
 Although previously I used svn I have been persuaded to use git.
 
 I have spent the last week reading git manuals, but I am a beginner.
 
 What tool should I use to create my git info? git-dpm? StGit?

I am a heavy user of stgit, and IMHO is only good for patch-based workflows
where you use git for acceleration.  It is really useful for kernel
development, for example.  And it would be useful for topic branches where
you're working on something that needs to be kernel-style patchset should
look perfect at submission time stuff to send upstream.

But it is *crap* for the branches you need to do cooperative development on.

I cannot comment on git-dpm, but it is probably best if you start with
straight git, with maybe a GUI tool on top (git-gui, etc).

Don't do development on your master branch, though.  Use a single devel
branch and merge that later if you're not yet ready for multiple topic
branches.  That lets you repair and rebase the devel branch during
development work with less fear of making a mess.   Just remember that
publishing to others a branch that is subject to rebase is not something
you should do except in very specific circunstances.

Something else you need to think about is the Debian changelog.  It *really*
is best if you use elaborate commit messages that can be used to construct
the changelog later, either manually or automatically.  Otherwise, you will
get annoying conflicts during development.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120218141938.gf20...@khazad-dum.debian.net

Re: RFS: ipset

[Henrique de Moraes Holschuh]

On Fri, 27 Jan 2012, Nikolai Lusan wrote:
 I guess the major issue at this point would be the kernel that will ship
 with the next release, if it is set to be a 3.0 or newer kernel then it
 shouldn't be an issue (similar to things like iptables itself or tools
 like vlan).

For the next Debian stable (wheezy) it will be either 3.2 or an even newer
kernel than that.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120127190639.ga25...@khazad-dum.debian.net

Re: RFS: ipset

[Henrique de Moraes Holschuh]

On Thu, 19 Jan 2012, Dmitry Smirnov wrote:
   I reckon you're aware that your package conflicts with
   xtables-addons-common?
  
  At this time, my ipset binary still conflicts as the
  xtables-addons-common also provides the binary in the same path.
 
 My concern is that overlapping is a big source of problems.
 Imagine one have ipset installed - he/she won't be able to use modules 
 provided by xtables-addons without uninstalling ipset first, etc.

ipset is distributed separately upstream, it has its own life upstream
(and git tree, etc), and all the functionality it requires is already
upstream (kernel).  Related functionality (iptables) is also upstream.

I'd actually ask why should ipset be packaged together with the rest of
the stuff in xtables-addons, which is composed mostly of stuff that did
not achieve upstream (as in kernel/iptables) inclusion yet for whatever
reason?

  IMO, if the next release (1.41) of xtables-addons will not build
  ipset, so, ipset package should set the Conflicts to only for
  xtables-addons-common (= 1.40) then no conflicts any more.
 
 This may work if we agree not to build ipset in the next xtables-addons 
 release and sponsor your package at the same time.

...

  Or setup the alternatives which users could select by him/her self.
 
 I don't like this idea because it is not an alternative but the very same 
 thing provided by two different packages. This should not be. :)

Indeed.  alternatives are not for this kind of use.

  Or ipset source package should build only libipset{2,-dev} and leave
  the ipset utility in xtables-addons as before.

That's a Bad Idea[tm].  Very bad, in fact.

 I hope you'll excuse me if I stay away from suggestions for some time.
 This discussion needs expertise of someone more experienced than me - a 
 someone familiar with resolution of conflicts between packages.
 We need comments from DDs.

Here is one DD commenting, with his I do use this stuff at work hat on,
and 10 years experience both as a Debian developer and sysadmin:

IMO it should be shipped separately, it has a separate life upstream and
it has been mainlined in the kernel and iptables side so it is now an
standard feature of an up-to-date Linux-based system.

 Personally I think this decision requires me to thoroughly review your 
 package 
 and prepare new xtables-addons. I'm overwhelmed with work for next several 
 weeks so I hardly will be able to do so soon.

I feel we could well wait a few weeks to get this done properly.

 Besides, I think you need to demonstrate the benefits of having separate 
 package for ipset. I'm not sure how/why this is better (if it is) or if it's 
 worth troubles to do for the marginal benefit, if any. 

To me, a separate ipset package does have advantages:

1. Ease of backporting.

2. No need to install stuff not yet ready/accepted on the kernel
   upstream/ipstables upstream to get standard stuff (ipset) to work.
   ipset is the kind of utility you install on routers and firewalls,
   where the less unused stuff, the better.

3. Reflects the reality upstream.

It does have an one-time drawback: the work required to remove/disable
ipset from xtables-addons*.

 What makes you think it worth the effort?

Well, FWIW, I do think it is worth the effort.  In fact I have a half-done
ipset package somewhere, which apparently I won't have to finish and take
care of now that someone else stepped up to do it :-p

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120119160813.gb9...@khazad-dum.debian.net

Re: How to pass CFLAGS to upstream's Makefile with debhlepler ?

[Henrique de Moraes Holschuh]

On Mon, 14 Nov 2011, Nicolas Bourdaud wrote:
 However is it not already too late to catch those warnings when the
 package is being built? IMO, they should have been taken care in
 upstream. Or do you consider to *massively* patch the source to fix the

Upstream usually doesn't have access to nearly as many arches as you, as
a DD, will.

IME, -Wall and proper review of the autobuild build logs can root out
some bugs upstream would not be warned about by gcc in the arch they
develop for.  We often use newer gcc versions than upstream as well, and
that also means you could get warnings they won't because they're still
using an older gcc.

IMHO, if you are able to, you should patch the source _and_ send the
changes upstream.  You should then decide whether you should ship the
Debian package with those patches or not, and when in doubt, wait for
upstream.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2014201428.gb31...@khazad-dum.debian.net

Re: email rejected bugs.debian.org

[Henrique de Moraes Holschuh]

On Sun, 23 Oct 2011, Paul Elliott wrote:
  Technical details of permanent failure:
  Google tried to deliver your message, but it was rejected by the recipient
  domain. We recommend contacting the other email provider for further
  information about the cause of this error. The error that the other server
  returned was: 550 550-Blacklisted URL in message. (blackpatchpanel.com) in
  [black]. See 550 http://lookup.uribl.com. (state 18).
 
 This is a small family domain. I control it. It goes thru google email. only 
 2 
 accounts in domain. All the computers on it use linux. It is extremely 
 unlikely any spam has ever been sent from this domain. 

Your domain is in an URI blacklist, so it doesn't mean it was used to
*send* spam: it likely was found *in* spam.  Usually that happens when
criminals are using a server under your domain to host artifacts...  but
you could have been joe-jobbed as well (someone used your domain in
their spam).

Just in case, maybe you should remove the useless parking of
blackpatchpanel.com as that parking server might be unsafe, and triple
check to make sure your DNS provider did not screw up and allowed
someone to create malicious subdomains of your domain behind your back
(yes, it has happened before to some DNS providers).

 Could someone white list this domain so that I can participate?

I am not sure that's possible, but even if it was, it would not be
effective: you really can't do a good job as a maintainer when your
email address is in a blacklist as it will cause communication problems.
Try to get the domain delisted, it should be quite straightforward with
uribl.

But please read this first: http://www.uribl.com/faq.shtml

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111024002833.ga13...@khazad-dum.debian.net

Re: Key update in annual ping?

[Henrique de Moraes Holschuh]

On Fri, 26 Aug 2011, Mats Erik Andersson wrote:
 Which route should I go for?
 
   A. Send ping using old key. Then update the key and send
  the updated key to the key server.
 
   B. Update the key now, then sending a ping using the new
  key, and send this new key to the server.

C. update the key and send a ping signed by the old key, and a ping signed
by the new key.  One of the two pings will be accepted, or both will.

But you don't need to do that at all.

 I do not intend to replace the key, only to update the pass
 phrase and the date of expiration in my present key.

This does not make any changes to the key that would cause problems
downstream.  In fact, it only invalidates the key self-signature, which
gpg will regenerate automatically for that exact reason.  You do have to
send the updated public key to relevant keyservers.

It also changes the encrypted binary blob that gets stored in your
private keyring, obviously.  But that REALLY must never be visible to
anyone but yourself.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110826205420.gb23...@khazad-dum.debian.net

Re: RFS: undo-closed-tabs-button

[Henrique de Moraes Holschuh]

On Thu, 26 May 2011, Ludwin Alduvi Hernández Vásquez wrote:
 * Package name : undo-closed-tabs-button

Check the policy for package naming for mozilla or xul extensions, and
follow it.

 It builds these binary packages:
 undo-closed-tabs-button - This add-on allows you to undo closed tabs via a
 toolbar button

Mention it is a xul/firefox/mozilla/whatever add-on in the description.

 My motivation for maintaining this package is: Contribute to debian project,
 and learn about of infrastructure.

This is a _REALLY_ weak reason to upload a package to Debian.

IMO you could contribute a lot more to the project by adopting any of the
hundreds of orphaned packages, which would be a lot more useful than
packaging browser extensions, as the browser already does a very good job of
managing them and updating them.  You can also look for more useful packages
that have been requested as RFP bugs (i.e. ones where it is non-trivial for
the user to use a non-packaged version).

 I would be glad if someone uploaded this package for me.

Please fix the package name and descriptions at least.  But I'd rather you
found a more useful package to take care of (note: this is not about how
useful the browser extension is, but rather the fact that we don't gain much
from getting the vast majority of the browser extensions packaged.  The
browser already does a very good job at making it easy for the users to
install/uninstall and keep extensions up-to-date).

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110527003135.gb6...@khazad-dum.debian.net

Re: Script to create pool mirror with more then one release

[Henrique de Moraes Holschuh]

On Sun, 10 Apr 2011, Michelle Konzack wrote:
 if I have a mirror whichcontain oldstable, stable, testing and unstable,
 is there a maintainer script to create  the  Packages/Source  files  for
 each release correctly?

Both debmirror and the official mirror scripts can handle this just fine,
and on the same pool (just like they are in the official mirrors).

Now, if you want to CREATE said files from a list of .debs, well, these
scripts won't do that.  I think apt-ftparchive can do that (from apt-utils).

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110411134810.ga28...@khazad-dum.debian.net

Re: On diverting an ITP to non-free

[Henrique de Moraes Holschuh]

On Wed, 23 Mar 2011, Paul Wise wrote:
 If it is just the documentation that is non-free and upstream refuses
 to drop the invariant sections, I would suggest to either drop it or
 split it out into a non-free source package.

Split it to a non-free source package, please.  Debian's quality
suffered a lot from the non-freeness of the GNU project documentation,
we lost a lot of documentation that really hampers offline work.

If it is in non-free, at least it is easy to install for offline work.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110323125452.ga23...@khazad-dum.debian.net

Re: Build-Depends-Indep, please review

[Henrique de Moraes Holschuh]

On Fri, 19 Nov 2010, Boyd Stephen Smith Jr. wrote:
 But hey, all the maintainer has to do is add 1, in words ONE, char to
 debian/rules. Just change build: to build%: and dpkg-buildpackage
 could use build-arch/indep targets instead of build. Aparently that is
 too much to ask.
 
 I volunteer to make /this/ fix to any package that is unmaintained or whose 
 maintainer is unresponsive, *if* Debian will change policy to /require/ build-
 arch/indep and make dpkg-buildpackage use them instead of build sometime 
 after 
 the Squeeze release and before the Wheezy freeze.

It can be done, but it must be done in at least two steps:

1. Make it SHOULD, start fixing packages.  You don't have to wait for the
   SHOULD to start fixing packages, either.

2. When almost everything is fixed, make it MUST.  Whatever doesn't get
   fixed after that, gets axed from the next stable.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101120183255.gf12...@khazad-dum.debian.net

Re: How to add dependencies that exist in another repository

[Henrique de Moraes Holschuh]

On Wed, 10 Nov 2010, Bob Proulx wrote:
 The packages for Debian there add a source.list.d file as you
 describe.  (And it really confused me until I figured out what it had

Which begs the question: why do we even have source.list.d/ suport in
the first place (or, if it is really useful to other users of apt, why
is it enabled by default) ?

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101110185048.ga7...@khazad-dum.debian.net

Re: How to add dependencies that exist in another repository

[Henrique de Moraes Holschuh]

On Wed, 10 Nov 2010, Henrique de Moraes Holschuh wrote:
 On Wed, 10 Nov 2010, Bob Proulx wrote:
  The packages for Debian there add a source.list.d file as you
  describe.  (And it really confused me until I figured out what it had
 
 Which begs the question: why do we even have source.list.d/ suport in
 the first place (or, if it is really useful to other users of apt, why
 is it enabled by default) ?

Answering my own question: it was done in response to a valid request for an
include directive for sources.list.

See #66325, which asks for, and provides reasonable reasons for a include
directive... but people got sources.list.d/ instead, which is a lot more
difficult to keep wraps on.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101110185734.gb7...@khazad-dum.debian.net

Re: RFS: flightgear, fgfs-base and simgear (updated packages) and 16 new flightgear related packages (attempt three)

[Henrique de Moraes Holschuh]

On Fri, 17 Sep 2010, Chris Baines wrote:
 The main reason for the number of packages is to allow customisation.
 The reasons are different for the individual packages, for instance the
 scenery package is not needed if the user wants to use terrasync for
 scenery and the fgfs-base-models package is separated from the fgfs-base
 package so that it can be removed separately when needed to avoid
 problems with terrasync. 

Hmm, if someone using terrasync (I don't know what that is) won't want any
of the models nor the terrain, you can still have flightgear-data (required
data files) and flightgear-data-basic (all default models and terrain), or
maybe one terrain package, and one package with all aircraft models, in
addition to the required -data package.

If there is really a good reason to keep them all separate, that works as
well, but still... 

 I am quite new to this, can you point me towards information about the
 freeze exceptions in Debian, I understand the concept and know about the

In this case, I think you'd need to justify why keeping the old version
around would be bad for the users of the package, in terms of:
  * compatibility with other users of the package (when netplay is possible)
  * compatibility with external data sets (models, terrain, this terrasync
thing...)
  * bugs fixed

And ask the release team if they'd provide a freeze exception should the new
packages get uploaded to unstable.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100917192652.ga24...@khazad-dum.debian.net

Re: RFS: flightgear, fgfs-base and simgear (updated packages) and 16 new flightgear related packages (attempt three)

[Henrique de Moraes Holschuh]

On Thu, 16 Sep 2010, Chris Baines wrote:
 I am looking for a sponsor or many sponsors for my new and updated
 FlightGear related packages. I have included a summary of all the
 information in one email to make it easier to read and understand. 
 
 The updated packages are flightgear, fgfs-base and simgear, all
 moving to the 2.0.0-1 version. 
 
 They build these binary packages:
 flightgear - Flight Gear Flight Simulator
 fgfs-base  - Flight Gear Flight Simulator - base files
 fgfs-base-models - Flight Gear Flight Simulator - base model files
 simgear-dev - Simulator Construction Gear -- development files
 simgear2.0.0 - Simulator Construction Gear -- shared libraries
 
 The new packages are,fgfs-scenery-w130n30 that provides the default
 FlightGear Scenery, fgrun, graphical FlightGear Launcher, fgo,
 graphical FlightGear Launcher and packages
 for the FlightGear Aircraft Models, of which there are 13, named
 fgfs-aircraft-X where X is the name of the aircraft.

That's a lot of packages, and they don't look like they'd be very big.
Is there a reason for not packaging them all in a single larger
flightgear-data arch-all package (source packages can now have several
.orig tarballs, so that shouldn't be a driving reason to have multiple
binary packages anymore)?

 I would be glad if someone uploaded these packages for me. This is the
 third time I have submitted this request, I understand completely how
 complex all these packages are, and thus probably why no one has yet
 sponsored them, but is there another approach I could pursue to get them
 in to Debian, as would hate to see my work go to waste?

It is past the first release cut date, it will probably help if you
offer some good convincing reasons why you should get a freeze exception
to replace the old flightgear packages with the new ones, and check it
with the release team.

If you do get a freeze exception, it would be easier to find a sponsor,
I think.  It is pointless to add new versions to unstable right now if
they're not going to be allowed in squeeze.

OTOH, you CAN target the packages to experimental (and provide backports
through backports.debian.org when squeeze is released).  Offering to do
that is might also help getting a sponsor.  There is certainly no reason
to waste the effort you put on the packaging.

I am sorry I cannot offer to be your sponsor at this time, I don't have
enough time to check packages (and it would be better to get someone
that plays flightgear, if possible).

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100917005911.ga20...@khazad-dum.debian.net

Re: RFS: oolite (updated package)

[Henrique de Moraes Holschuh]

On Sat, 24 Jul 2010, Nicolas Boulenguez wrote:
 The package can be found on mentors.debian.net:
 - URL: http://mentors.debian.net/debian/pool/main/o/oolite
 - Source repository: deb-src http://mentors.debian.net/debian unstable main 
 contrib non-free
 - dget http://mentors.debian.net/debian/pool/main/o/oolite/oolite_1.74.1-1.dsc
 
 I would be glad if someone uploaded this package for me.

Usually I cannot be counted upon to be a timely sponsor, but you can count
on me as a last resort.  If you find no-one to sponsor oolite, send me a
direct email.  Please make sure the package has been tested through lintian
and piuparts, first, and has no problems in that area. 

It goes without saying that you must test the upgrade path first by using
the old version of oolite, preferrably with some extensions, then upgrading
to the new one.

What happens to the savegames?  To the older extensions?  If it doesn't
just work, you need to add a NEWS.Debian entry at the very least.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100724154809.gb26...@khazad-dum.debian.net

Re: how to correct missing changelog information?

[Henrique de Moraes Holschuh]

On Wed, 21 Jul 2010, Nick Leverton wrote:
 On Wed, Jul 21, 2010 at 03:52:11PM -0300, Henrique de Moraes Holschuh wrote:
  On Tue, 20 Jul 2010, Eric Cooper wrote:
  
  It will break nothing.  If the bug report contains very important
  information which is not available in the changelog itself, it is
  actually a good idea to add the reference, as it could help someone
  analysing the changelog later.  Otherwise, don't bother.
 
 When I have had to modify a past changelog for whatever reason (in my
 case a DD asked me because I had stupidly Closed: a wrong bug number
 due to a transposition), I briefly commented the fact in the current
 changelog like any other change to the packaging.

That works :-)

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100724003245.gb9...@khazad-dum.debian.net

Re: how to correct missing changelog information?

[Henrique de Moraes Holschuh]

On Tue, 20 Jul 2010, Eric Cooper wrote:
 I recently uploaded a new version of a package and forgot to include a
 (closes: #NNN) line in the changelog for a bug that was closed.  I can
 easily close the bug using the mailserver, but what is the right way
 to correct the changelog file?
 
 Will it break anything if I simply revise history and change the
 earlier version's entry the next time I do an upload?

It will break nothing.  If the bug report contains very important
information which is not available in the changelog itself, it is
actually a good idea to add the reference, as it could help someone
analysing the changelog later.  Otherwise, don't bother.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100721185211.ga1...@khazad-dum.debian.net

Re: Realloc is blocking execution

[Henrique de Moraes Holschuh]

On Fri, 16 Oct 2009, Mats Erik Andersson wrote:
 4. The main process WM receives SIGHUP, and enters a signal handler.
The signal handler uses two calls: free_menuitems(), get_menuitems().

Since when are you allowed to malloc, let alone realoc, from inside a signal
handler?

http://www.gnu.org/s/libc/manual/html_node/Nonreentrancy.html#Nonreentrancy

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: RFS: fluid-soundfont -- Fluid (R3) General MIDI SoundFont

[Henrique de Moraes Holschuh]

On Wed, 20 Feb 2008, tim hall wrote:
 I have been burned by soundfonts before, does Frank Wen have a site or
 somesuch, describing how he made the soundfount, where he got the
 instruments, etc?

 I understand your concern, Henrique. However, the question still makes  
 me want to punch something. Do we really have to nit-pick a hundred or  
 more sets of samples to check whether each one is DFSG-free? Can we not  
 accept the upstream author's license so long as it remains unchallenged?  
 Would you subject a text font to such scrutiny?

Yes I would (and I do), but then, text fonts are MUCH easier.  Usually,
nobody goes around copying glyphs from here and there to make a frankenstein
:-)

I have tried to find more information on the FluidR3 soundfonts, and indeed
they are around since 2001.

I am *not* against its addition to Debian, but IMHO we should make at least
a token effort and ask the author if *he* has any reservations about it, and
also if he ever had any trouble over the issue.  If he doesn't, I suppose we
could add it.

 Please don't take my remarks personally, these are real questions. We've  
 been campaigning / waiting for a suitable soundfont candidate for  
 something like 5 years (CMIIW). FluidR3 is the obvious candidate, it is  
 pretty ancient and I wouldn't be at all surprised if Frank Wen has not  
 kept records of all sample sources.

So have I.  I was the timidity maintainer for a *LONG* time, and to date, I
have to use the completely undistributable EAW patchset (at least it is
*good*), because I couldn't find anything better and I was lucky enough to
be around while EAW was still easy to find on the net.

Frankly, the current freepats is useless, and the fact that the current
timidity maintainer decided to Depend on it (and I know for a fact that
timidity *doesn't* depend on it, and that apt will now install recommends by
default) aggravates me a LOT.  I would want nothing more than a real, good
patchset to make it to Debian ASAP.

 enough years, surely? OK, I know, assume nothing. So realistically, how  
 should we approach this? What real chance is there of getting it into  
 lenny / Hardy?

It has a good chance, if the author answers to emails.  Otherwise, I
wouldn't know, you'd have to ask a ftp-master.

 There are a couple of side issues here relating to recognition of  
 mimetypes. Nautilus thinks that SF2 files are video/x-msvideo, causing  

That we can fix, and we don't even have to wait for anything for it. Start
filing bugs...

 Please, please, please let's walk the extra mile for this package. How  
 can I help? I'm not a DD either. Are we ever going to be able to  
 distribute soundfonts? If not now, when?

You can help emailing the author about the patchset, and cc'ing the ML :)

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: RFS: fluid-soundfont -- Fluid (R3) General MIDI SoundFont

[Henrique de Moraes Holschuh]

On Thu, 21 Feb 2008, Paul Wise wrote:
 On Feb 21, 2008 12:28 AM, Toby Smithe [EMAIL PROTECTED] wrote:
  On Wed, Feb 20, 2008 at 3:22 PM, Paul Wise [EMAIL PROTECTED] wrote:
What made you choose /usr/share/sounds/sf2 for installing the
soundfont? I notice that freepats uses /usr/share/midi for this.
 
  This is the directory that awesfx, the SoundFont loader for emu10k1
  cards, defaults to.
 
 Perhaps suggest that package too?

It makes little sense to suggest awesfx on soundfont packages, but OTOH,
asking awesfx to suggest or recommend fluidr3, well, THAT would make a lot
of sense :-)

The same goes to timidity, as long as a timidity config file for fluidr3 is
added.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: RFS: fluid-soundfont -- Fluid (R3) General MIDI SoundFont

[Henrique de Moraes Holschuh]

On Wed, 20 Feb 2008, Toby Smithe wrote:
   The same goes to timidity, as long as a timidity config file for fluidr3 is
   added.
 
 I was thinking of updating timidity to look for config files in a
 /etc/timidity/cfg.d directory, then having fluid install a fluid.cfg
 file into it. Naturally, this would come with a later revision of the
 package.

Sounds good.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: RFS: fluid-soundfont -- Fluid (R3) General MIDI SoundFont

[Henrique de Moraes Holschuh]

On Wed, 20 Feb 2008, Toby Smithe wrote:
 I have heard back from Frank, and he has updated the README file to
 include a list of contributors, and details of the sources for his
 sounds.

Can you send it to us?

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: RFS: fluid-soundfont -- Fluid (R3) General MIDI SoundFont

[Henrique de Moraes Holschuh]

On Wed, 20 Feb 2008, Toby Smithe wrote:
 I am looking for a sponsor for my package fluid-soundfont.
 
 * Package name: fluid-soundfont
   Version : 3-1
   Upstream Author : Frank Wen [EMAIL PROTECTED]
 * URL :
 http://tsmithe.users.ubuntustudio.org/fluid-soundfont_r3.tar.gz
 * License : MIT
   Section : sound

I have been burned by soundfonts before, does Frank Wen have a site or
somesuch, describing how he made the soundfount, where he got the
instruments, etc?

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: How to set BTS tags nicely

[Henrique de Moraes Holschuh]

On Tue, 12 Feb 2008, David Paleino wrote:
 I usually do:
 To: [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]

Better change that cc to bcc.  That way, spammers (and people) replying to
your mail will not hammer the poor control bot.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: Bug#397939: Lintian: outdated-autotools-helper-file

[Henrique de Moraes Holschuh]

On Mon, 11 Feb 2008, Kapil Hari Paranjape wrote:
 Note that if the upstream's auto-generated files are deleted during
 the clean target, then the source *must* be re-packaged to avoid
 needless clutter in the .diff.gz which is of a negative nature.

Not so.  Deletions are ignored.  Ever tried it?

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: Lintian: outdated-autotools-helper-file

[Henrique de Moraes Holschuh]

On Sun, 10 Feb 2008, David Paleino wrote:
 I'm packaging gnome-translate (ITP #292909), and everything builds fine. A
 lintian check on the .changes file throws:
 
 E: gnome-translate source: outdated-autotools-helper-file config.guess
 2003-07-02
 N:
 N:   The referenced file has a time stamp older than year 2004 and the
 N:   package does not build-depend on autotools-dev or automake and
 N:   therefore apparently does not update it. This usually means that the
 N:   source package will not work correctly on all currently released
 N:   architectures.
 N:
 E: gnome-translate source: outdated-autotools-helper-file config.sub 
 2003-07-04
 
 What am I supposed to do? I believe that Build-Depending on autotools-dev |
 automake is not sufficient, as it seems that those files won't be updated
 anyways. Should I update them manually? This will introduce those changes in
 the .diff.gz outside the debian/ dir (and, AFAICT, keeping only debian/ into
 the .diff.gz is The Right Thing).
 
 Any suggestion is very welcome.

Read autotools-dev's README file, it has recipes for what you want (that
won't even increase diff size).

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: RFC/RFS: zerofree - zero free blocks from ext2/3 file-systems

[Henrique de Moraes Holschuh]

On Fri, 08 Feb 2008, Thibaut Paumard wrote:
 Description: zerofree - zero free blocks from ext2/3 file-systems
  Zerofree finds the unallocated, non-zeroed blocks in an ext2 or ext3
  file-system and fills them with zeroes. This is useful if the device 

I'd add umounted or mounted read-only somewhere.  It makes all the
difference: one can use zerofree for them, and dd for filesystems mounted
read-write.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: RFC/RFS: zerofree - zero free blocks from ext2/3 file-systems

[Henrique de Moraes Holschuh]

On Wed, 06 Feb 2008, Thibaut Paumard wrote:
  Zerofree finds the unallocated, non-zeroed blocks in an ext2 or ext3
  file-system and fills them with zeroes. This is useful if the device on

How does zerofree avoid race conditions of something trying to use a block
it wil zero in the time window (determine block is free, zero block]?

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: Multiple upstream changelog files

[Henrique de Moraes Holschuh]

On Tue, 30 Jan 2007, Daniel Leidert wrote:
 Dumb question: How this? debian/package.NEWS is (from man-page reading)
 just a different form for debian/NEWS and this file is installed
 as /usr/share/doc/package/NEWS.Debian.gz, which is not intended to
 contain the upstream NEWS file. Am I wrong?

You are correct.  And anyone using the NEWS.Debian file for upstream
changelog will get LARTed when someone notices the missuse.  NEWS.Debian is
supposed to be used only as a extremely high signal-to-noise ratio medium
for very important announcements about package/program behaviour changing,
and other very important information to package users.

If it doesn't need to be shown to every user of a package at upgrade, it
does not belong on NEWS.Debian.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: Opinions on CDBS amongst sponsors

[Henrique de Moraes Holschuh]

On Mon, 11 Dec 2006, Neil Williams wrote:
 What are the problems with CDBS (apart from debian/control automation)?

Badly-documented black-box on something that we have to understand well to
sponsor or work with.  This is Not Acceptable IMO.

 Which kinds of packages have the most trouble with a CDBS method?

Any.

I do not sponsor anything CDBS, nor would I co-maintain CDBS packages.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: Sponsoring gcc-h8300-hms

[Henrique de Moraes Holschuh]

On Thu, 26 Oct 2006, Michael Tautschnig wrote:
  On Thu, 26 Oct 2006, Michael Tautschnig wrote:
   Tests would be great; but I don't really get what you meant by The 
   orig.tar.gz
   there does not match.
  
  Delete what is in the URL you gave me and reupload the correct source
  package, with the correct orig.tar.gz, correct diff.gz and correct .dsc.
 
 I still don't really get it - I'm just preparing a fixed version of the
 changelog, but I don't really know what is so wrong about the .orig.tar.gz - 
 is

Whatever orig.tar.gz you used to build is NOT the one in that URL. That's
what is wrong with it.  Size and md5sum do not match what is in the .dsc.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: Sponsoring gcc-h8300-hms

[Henrique de Moraes Holschuh]

On Thu, 26 Oct 2006, Michael Tautschnig wrote:
 PS.: As before, the files can be found at 
 http://www.model.in.tum.de/~tautschn/debian/

This build differs on the old binutils-h8300-hms package in that the
binaries are called h8300-hitachi-coff-*, instead of h8300-hms-*.

I am not sure this is intended, but I do not object to it at all.  Still, I
think it deserves a note on a NEWS.Debian file, and maybe even a bunch of
extra symlinks in /usr/bin.

Also, it uses hardlinks between /usr/h8300-hitachi-coff/bin and the stuff in
/usr/bin, which is really not a good idea as explained by linitan.  Can you
make them symlinks?

I have the current packages built, and I will wait your reply to the
questions above before either uploading, or rebuilding from new packages.

The h8300-hitachi-as and -ld tested ok against the stuff I have here, btw,
producing byte-identical binaries to what they were expected to.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: Sponsoring gcc-h8300-hms

[Henrique de Moraes Holschuh]

On Wed, 25 Oct 2006, Michael Tautschnig wrote:
 Furthermore, I'd like to add some notes: Probably brickos and the Lego
 Mindstorms Kit is the only use of this and related packages. As such I wonder

Some embedded controller firmware out there are h8300-coff as well, so no,
Lego Mindstorms is not the only user.  But it is probably the major one.

 whether it is worth trying to upgrade to binutils 2.16.x and gcc-4.x, because
 this very outdated version of binutils and gcc just works for this very 
 special
 application.

I don't know about gcc, but to binutils 2.16.x, yes, it is worth it.  It is
also dead easy: get the latest binutils packages in sid, apply the
debian/ directory to 2.16.x, and tweak debian/rules a bit to instead of the
normal build, do a crosscompiler build.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: Sponsoring gcc-h8300-hms

[Henrique de Moraes Holschuh]

On Wed, 25 Oct 2006, Michael Tautschnig wrote:
 Ok, I'm working on that one - I've succeeded to build the package, but a
 proper Debian package still requires a bit of work, I'll try to manage
 that by tomorrow.

Ok. You did notice that debian/rules has a special entrypoint for
crosscompiling builds, and also one for cleaning the result of that up?

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: Sponsoring gcc-h8300-hms

[Henrique de Moraes Holschuh]

Hi Michael!

On Wed, 25 Oct 2006, Michael Tautschnig wrote:

  On Wed, 25 Oct 2006, Michael Tautschnig wrote:
   Ok, I'm working on that one - I've succeeded to build the package, but a
   proper Debian package still requires a bit of work, I'll try to manage
   that by tomorrow.
  
  Ok. You did notice that debian/rules has a special entrypoint for
  crosscompiling builds, and also one for cleaning the result of that up?
 
 Sure, this is what I've used, but I've not yet tweaked the rules to do that
 automagically.
 
 Thanks a lot for the pointers,
 Michael
 
 PS.: Do you think binutils-h8300-hitachi-coff is an appropriate package name?

binutils-h8300-coff is the proper name.  But don't rename the packages yet,
generate them with the old names in sid or you will get stuck in the NEW
queue, and that means *no* chance for Etch.

So, use binutils-h8300-hms and gcc-h8300-hms for now.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: Sponsoring gcc-h8300-hms

[Henrique de Moraes Holschuh]

On Thu, 26 Oct 2006, Michael Tautschnig wrote:
 Ok, finally it's done. You can find the binutils-h8300-hms packages at
 
 http://www.model.in.tum.de/~tautschn/debian/

Ok, but as you used the Sid package's stuff, better say that in the
changelog.  And better make them urgency=medium if the target is Etch.

I happen to have some h8s coff code, so I can test your packages,
but please upload a sane version of the source package first. The
orig.tar.gz there does not match.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: The situation of gcc-h8300-hms and related packages

[Henrique de Moraes Holschuh]

On Sat, 23 Sep 2006, Michael Tautschnig wrote:
 I've asked for sponsorship of gcc-h8300-hms 3 months ago [1], but couldn't 
 find
 anyone to do the NMU for me.

I can sponsor such packages for you, but I do have a biiig question:

h8300-hms (actually, h8300-coff) is dead upstream.  Nobody wrote a new gas
backend for h8300-coff, and it has been pulled from binutils.  What do you
intend to do about it?  The last binutils version that supports h8300-coff
is 2.16.x, I think.

h8300-elf still lives, though.

Also, maybe it is high time to rename h8300-hms to its proper name,
h8300-coff ?

 Now that the package has been orphaned [2], I'd hope for the situation to
 improve. Anyone willing to sponsor may find the package at [3].
 
 If there is any interest, I'd be willing to prepare new uploads for the 
 packages
 brickos and binutils-h8300-hms as well, which have been orphaned too.

Which binutils upstream did you use for H8/300 coff ?

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

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

[Henrique de Moraes Holschuh]

On Thu, 14 Sep 2006, Steve Langasek wrote:
  The BIG problem is how to get the next-version. Say you have version
  1.2-3. A binNMU would be 1.2-3+b1, a security release would be
  1.2-3etch1 (unless there was a binNMU).
 
 In the Great Scheme, these were supposed to become 1.2-3+etch1 instead of
 1.2-3etch1 so that security NMUs would sort higher than binNMUs...

And they didn't because?

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: RFC/RFS: jlhafrontend -- command-line lzh archiver written in Java

[Henrique de Moraes Holschuh]

On Tue, 05 Sep 2006, Ying-Chun Liu (PaulLiu) wrote:
 Henrique de Moraes Holschuh wrote:
  On Mon, 04 Sep 2006, Ying-Chun Liu (PaulLiu) wrote:
  jlhafrontend - command-line lzh archiver written in Java
 
  This package intends to become a free replacement of the lha package
  currently in Debian non-free section. It is command-line compatible to
  the lha package. Thus it works well with file-roller, ark,
  clamav, fkiss, and gnomekiss.
  
  Why it is named frontend, if it is in fact the entire tool and not just a
  wrapper to call lha, which is what lhafrontend implies?
 
 jlha is a library written in Java. It can be found at
 http://homepage1.nifty.com/dangan/Content/Program/Java/jLHA/jLHA.html
 
 jlhafrontend is just a wrapper to call jlha and provides
 command-line compatibility to the non-free lha.

Well, the name is correct, then. I was not aware of jlha as a library.

 If the package/project name is bad, I can change it. Please give me some
 idea, thanks.

I don't know if it is bad as there is a lib jlha.  But my personal
preference would be to name the *package* either jlha-utils (or
libjlha-utils, maybe) or jlha-bin/libjlha-bin, and name the tool itself jlha
(i.e. you get the jlha library, and if you call the jlha java binary, you
get the jlha tool).

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: RFC/RFS: jlhafrontend -- command-line lzh archiver written in Java

[Henrique de Moraes Holschuh]

On Mon, 04 Sep 2006, Ying-Chun Liu (PaulLiu) wrote:
 jlhafrontend - command-line lzh archiver written in Java
 
 This package intends to become a free replacement of the lha package
 currently in Debian non-free section. It is command-line compatible to
 the lha package. Thus it works well with file-roller, ark,
 clamav, fkiss, and gnomekiss.

Why it is named frontend, if it is in fact the entire tool and not just a
wrapper to call lha, which is what lhafrontend implies?

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: RFS: openmsx openmsx-catapult (updated package)

[Henrique de Moraes Holschuh]

On Thu, 03 Aug 2006, Joost Yervante Damad wrote:
 I am looking for a sponsor for the new version 0.6.1-1
 of my package openmsx, and the new version 0.6.1-R1-1 of it's companion 
 package openmsx-catapult
 
 It builds these binary packages:
 openmsx- the MSX emulator that aims for perfection
 openmsx-data - datafiles for openMSX, an MSX emulator

I told you you had a permanent offer of sponsorship from myself for OpenMSX.
Next time, please CC me.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: [RFS] OptiPNG - advanced PNG (Portable Network Graphics) optimizer

[Henrique de Moraes Holschuh]

On Sun, 18 Jun 2006, Nelson A. de Oliveira wrote:
 What have changed:
 - foo;
 - bar;
 - bla;
 - the last change.
 
 It's just a personal taste.

It is also how lists should be handled in certain languages (like Brazilian
Portuguses) ;-)

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: sponsored NMU's to be forbidden (Re: How can a non-DD fix broken packages?)

[Henrique de Moraes Holschuh]

On Wed, 31 May 2006, Bart Martens wrote:
 You sure do have a point here.  But that seems to apply to both DD's and

It would appply to those who can upload (i.e. DDs right now).

 non-DD's.  I still don't see why a sponsored NMU would be bad.

It is not that sponsored NMUs are bad, it is that they are about the same as
a normal NMU (the difference being who proposed the fix...).  Unless you are
talking about some DD which considers sponsoring to be upload in blind
faith, in which case please tell us who is doing that so we can see to
getting his upload rights revoked.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: How can a non-DD fix broken packages?

[Henrique de Moraes Holschuh]

On Tue, 30 May 2006, Steve Langasek wrote:
 The difference being that most of the time when someone sponsors an NMU,
 they're effectively shirking their own duty to follow up on the package and
 ensure that the NMU hasn't introduced any regressions.  Often, they're
 shirking their duty to even check the correctness of the provided patch
 themselves.

IMHO we really should have a global NMU blacklist (no, never per-package.
That way lies lameness) which we could ask the ctte to place maintainers in
for a few months when someone does the NMU-and-forget routine and that NMU
causes problems: screw up an NMU and don't clean up after yourself, get
punished by not being able to screw up through NMUs again for a while.

We should *also* have the pts auto-add anyone who does an NMU to receive all
bug reports.  If you NMU, you *are* responsible for it, and it is not nice
to make it so easy for one to forget he NMUed something, after all.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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