Re: File descriptor hard limit is now bumped to the kernel max

[Mike Hommey]

On Thu, Jun 06, 2024 at 06:39:15PM +0200, Marco d'Itri wrote:
> On Jun 06, Simon McVittie  wrote:
> 
> > I believe the change Luca describes is increasing rlim_max (hard limit)
> > but not rlim_cur (soft limit), and the code touched by that patch is
> > looking at rlim_cur, so it should be unaffected anyway - unless some larger
> > component is raising rlim_cur.
> Something did, because inn would start reporting ~1G available fds and 
> then explode, and that patch solved the issue. :-)

There are conditions under which the 1024 limit doesn't apply, like
running in a docker container.

Mike

Re: Ubuntu discussion at planet.debian.org

[Mike Hommey]

On Sat, Oct 23, 2004 at 12:14:45PM -0500, Manoj Srivastava wrote:
> On Sat, 23 Oct 2004 14:23:48 +0900, Mike Hommey <[EMAIL PROTECTED]> said: 
> 
> > And why not, instead of freezing unstable, make it build against
> > testing, when er try to freeze testing ?
> 
>   Libraries. If you build against a library version that is no
>  longer in unstable, then you may have issues in testing when a new
>  library tries to migrate into testing -- cause nowhere would there be
>  packages built against the new library version.

I don't see the point. If you build against what is in testing, there's
no issue when migrating to testing.
One particular issue would be when libraries change ABI, and new
packages would need to be built against them, but still, at that
particular time, the purpose being mainly to freeze testing, these 
ABI changes should be candidates for experimental.

>   Not to mention that unstable would become unviable as a
>  distribution -- the run time libs may not be the ones that are needed
>  by the packages in unstable.

At that particular time, isn't frozen-testing the one that is supposed
to be a distribution ?

> > Okay, that's what t-p-u is roughly for, but the fact is that it's
> > quite painful.
> 
>   Could you elaborate on that? Why is it so painful?

On top of the problems mentionned by the other replies, the fact that
autobuilders have to be set up for t-p-u... can you remind me how long
sarge has been planned for freeze ? and for how long autobuilders are
required for alpha and mips for t-p-u ?

Mike

Re: Ubuntu discussion at planet.debian.org

[Mike Hommey]

On Sun, Oct 24, 2004 at 12:11:51AM -0500, Manoj Srivastava wrote:
[...]
>   If unstable is not a distribution, what the hell is the point
>  of having all the paraphernalia of unstable around?  The whole point
>  of uploading to unstable is to have people test packages in
>  unstable. 

If people test unstable, then it's unstable we should release, not
testing. As somebody said in this thread not enough people are trying
testing, and that's one of our problems in the release cycle.

[...backwards a bit...]
>   In other words, stop all development dead, since experimental
>  is never ever used as a default ditribution by anyone sane.

Stop all development ? See the situation for gnome 2.8. It is in
experimental. It is compiled for several architectures, and is maybe
soon ready to be put in unstable. Do you really call that stopping all
development ?

>   This is incorrect, t-p-u is indeed supported by buildds --
>  though this paragraph seems to be more like a rant than anything
>  else.

Okay, it's a month old, but there hasn't been any since.
http://lists.debian.org/debian-devel-announce/2004/09/msg5.html
"We are also still missing official autobuilders for
testing-proposed-updates on alpha and mips.  All other architectures
appear to be keeping up with t-p-u uploads."

And vorlon told me not so long ago that it was still the case, and that
it was the reason why the NMU by Frank Lichtenheld for kxmleditor[1]
through t-p-u still hasn't made it to sarge... and you may know that all
KDE applications updates have to go through t-p-u, since unstable is
"polluted" with KDE 3.3 which won't make it for sarge.

Take it as a rant if you want, but I'm just noticing.

Mike

1. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=265680&msg=35

Re: non-free firmware: driver in main or contrib?

[Mike Hommey]

On Sun, Oct 24, 2004 at 03:41:13AM +0100, Matthew Garrett wrote:
> Is this the case even if the firmware is in a flash chip attached to the
> device? If the total amount of non-free software on a user's system is
> the same regardless, why are we concerned about how it's packaged?

'kay, this has already been debated earlier, but let me rephrase it.
If some driver depend on *loading* a non-free firmware, i.e. being
*totally* useless without, it goes into contrib.
Same applies to any software in debian, right ?

Mike

Re: non-free firmware: driver in main or contrib?

[Mike Hommey]

On Sun, Oct 24, 2004 at 04:20:16AM +0100, Matthew Garrett wrote:
> Argh. Sorry, I shouldn't be allowed to post while drunk. That was meant
> to go to -legal, not -devel.

And i shouldn't have replied without looking at the To: field.

Mike

Re: Ubuntu discussion at planet.debian.org

[Mike Hommey]

On Sun, Oct 24, 2004 at 07:53:27AM +0200, Martin Schulze wrote:
> Err...  experimental ABI changes are for experimental.  Confirmed ABI
> and API changes are for unstable (or whatever you want to call the
> development branch).  We must not hide those changes from the future
> stable distribution since it was done and confirmed upstream.

Are you saying you would go with a (for instance) gcc ABI change right
now (i.e. while trying to release) in unstable if there was one ?

Mike

Re: Release-critical Bugreport for May 14, 2004

[Mike Hommey]

On Sun, Oct 24, 2004 at 12:34:54PM +0200, Wouter Verhelst wrote:
> They are; I received one just last week.
> 
> If they're not reaching you, I suggest you check your d-d-a subscription
> and/or your spam filter.

How did you receive a mail to d-d-a which is not even in the archive ?
http://lists.debian.org/debian-devel-announce/2004/10/index.html
http://lists.debian.org/debian-devel-announce/2004/09/index.html

Mike

Re: software updates file in /usr -- policy bug?

[Mike Hommey]

On Mon, Oct 25, 2004 at 07:44:19PM +0200, Santiago Vila wrote:
> Even if the file is updated only by the postinst, it is useful to know
> that you can recover a broken system from scratch by having:
> 
> * A backup copy of /etc, /var, /home, /usr/local, etc. (but not /usr).
> * The list of installed packages.
... which can, anyway, got back from files in /var

Mike

Re: An important lesson

[Mike Hommey]

On Thu, Oct 28, 2004 at 03:40:48PM +0100, Matthew Garrett wrote:
> Developers, do not allow 
> 
> http://www.google.com/search?q=inurl%3Asecring.gpg
> 
> to happen to you.

And it's better to repeat it three times:
http://debian-amd64.alioth.debian.org/pure64/wanna-build/secring.gpg
http://ftp.belnet.be/linux/debian-amd64/wanna-build/secring.gpg
http://ftp.belnet.be/pub/mirror/debian-amd64.alioth.debian.org/wanna-build/secring.gpg

Mike

ITP: mozilla-venkman - Javascript debugger for Mozilla and Firefox

[Mike Hommey]

reassign 230874 wnpp
retitle 230874 ITP: mozilla-venkman - Javascript debugger for Mozilla and 
Firefox
thanks

Venkman being not really sync'ed in firefox or mozilla, I'm proposing to
package the venkman package which will conflict with mozilla-js-debugger
(venkman provided by the mozilla source package) and will provide venkman
for both mozilla and firefox.

* Package name: mozilla-venkman
  Version : 0.9.84
  Upstream Author : Robert Ginda <[EMAIL PROTECTED]>
* URL : http://update.mozilla.org/extensions/moreinfo.php?id=216
* License : Dual-licensed GPL/MPL
  Description : Javascript debugger for Mozilla and Firefox
 
  Venkman is the JavaScript debugger for Mozilla based browsers, such as
  Mozilla 1.x and Phoenix/Firebird/Firefox.
  It can be used to debug either Javascript embedded in web pages, or
  even Mozilla's interface and extensions.

Mike

Re: mozilla-firefox-locale package with all language translations

[Mike Hommey]

On Thu, Nov 11, 2004 at 06:47:15AM +0100, Cesar Martinez Izquierdo wrote:
> Hi! Sometimes a package with all the firefox translations has been proposed.
> With the arrival of Firefox 1.0, localization has been normalized and now 
> this 
> package seems quite suitable.
> 
> As a proof of concept, I have packaged "mozilla-firefox-locale-all", 
> containing all the available translations at the moment.
> 
> You can download the package at:
> 
> 
> The "rules" file includes an "wget" rule that can download the available XPI 
> files with the translations.
> After download new XPI files, if you regenerate the package then you get all 
> the required files for these new XPIs.
> 
> The currently built package contains the XPI files downloaded from 
> .
> Maybe it would be better to use 
> , 
> which contains less translations but they are supposed to be tested and 
> complete. Anyway the nightly XPIs seem to work fine for me.
> 
> Opinions and testing is welcome.

You're not lucky, with the 1.0 package that just got uploaded to
unstable, your package is useless, 'cause support for
/var/lib/mozilla-firefox/chrome.d has been dropped.

Anyways, I'd suggest to make a multi-binary package so that it produces
several mozilla-firefox-locale-* packages.

As for how to make the thing work with new firefox package, I'm working
on an HTML version of what I sent to extensions packages maintainers 2
days ago about the new scheme. I'll send the URL here when it's done.
In the meanwhile, you can still guess what's going on by taking a look
at extensions and locales available in
http://glandium.org/debian/unstable/.

Mike

Re: mozilla-firefox-locale package with all language translations

[Mike Hommey]

On Thu, Nov 11, 2004 at 03:50:51PM +0900, Mike Hommey wrote:
> As for how to make the thing work with new firefox package, I'm working
> on an HTML version of what I sent to extensions packages maintainers 2
> days ago about the new scheme. I'll send the URL here when it's done.

And here it is:
http://glandium.org/debian/packages/mozilla-firefox/New_scheme_for_extensions/current.html

Mike

Re: How to handle libssl support?

[Mike Hommey]

On Thu, Nov 11, 2004 at 10:27:08AM -0500, Daniel Burrows wrote:
> On Thursday 11 November 2004 04:11 am, Juergen Salk wrote:
> > It seems in Sarge at least some of the crypto crippled versions
> > have just vanished into thin air.
> 
>   ...which is going to silently leave users running old versions of some 
> software.  links-ssl seems to have been replaced with a dummy upgrade 
> package, but other *-ssl packages (eg, fetchmail-ssl) were just dropped.  It 
> seems to me that any crypto-enhanced package that was moved to main and 
> renamed should have a dummy upgrade package in sarge.

It is not necessary. Look at fetchmail, for instance:
Replaces: popclient, fetchmail-ssl, fetchmail-common
Provides: popclient, fetchmail-ssl, fetchmail-common
Conflicts: popclient, fetchmail-ssl, fetchmail-common, logcheck (<< 1.1.1-9)

I don't know and didn't check for the others *-ssl packages, though.

Mike

Re: mozilla-firefox-locale package with all language translations

[Mike Hommey]

On Fri, Nov 12, 2004 at 04:56:27AM +0100, Cesar Martinez Izquierdo wrote:
> El Jueves 11 Noviembre 2004 07:50, Mike Hommey escribió:
> > You're not lucky, with the 1.0 package that just got uploaded to
> > unstable, your package is useless, 'cause support for
> > /var/lib/mozilla-firefox/chrome.d has been dropped.
> 
> Ok, no problem, I've uploaded a new package, updated for firefox 1.0 and that 
> uses the new method:
> http://users.evtek.fi/~k0400388/debian/mozilla-firefox-locale-all/mozilla-firefox-locale-all_1.0-1_all.deb

I'd also suggest to drop the ja-JPM locale, in favour of the ja-JP one.
The reason why is explained here:
http://www.mozilla-japan.org/jp/l10n/faq/#what_is_ja-JPM
(Sorry I didn't take the time to find a resource in english)
Basically, it says that the ja-JPM locale is the one using the same kind
of vocabulary as MacOSX. The ja-JP locale is the one for windows/unix.

Mike

Re: Debian menu and GNOME (request for help)

[Mike Hommey]

On Thu, Nov 11, 2004 at 08:55:12PM -0600, Graham Wilson wrote:
> On Fri, Nov 12, 2004 at 02:43:44AM +, Scott James Remnant wrote:
> > On Fri, 2004-11-12 at 00:22 +0100, Bill Allombert wrote:
> > > 1) Current gnome-panel do *not* support XDG menus (only KDE does).
> > > (Debian menu has XDG menu support through menu-xdg.)
> > 
> > It's very much in the works, check out gnome-menus in CVS.  It'll
> > probably be in the next GNOME release, as I understand it.
> 
> I think by `current' Bill meant sarge, which, if I understand correctly,
> is what were concerned about. It is, however, good that future versions
> of GNOME will use XDG.

(and will drop support for distro menu)

Mike

Re: mozilla-firefox-locale package with all language translations

[Mike Hommey]

On Fri, Nov 12, 2004 at 10:52:35AM +0100, Nikolai Prokoschenko wrote:
> On Thu, Nov 11, 2004 at 03:50:51PM +0900, Mike Hommey wrote:
> 
> > Anyways, I'd suggest to make a multi-binary package so that it produces
> > several mozilla-firefox-locale-* packages.
> 
> A stupid question from my side: do we have any code in the mozilla-*
> wrappers to automatically select the right language according to the
> current locale?

There is one in firefox. I'm not sure mozilla supports the -UIlocale and
-contentLocale we can use on firefox to do the trick...

Mike

Re: Accepted xmlstarlet 0.9.3-2 (i386 source)

[Mike Hommey]

On Sat, Nov 13, 2004 at 02:55:42AM -0500, Alex Mauer wrote:
>  xmlstarlet (0.9.3-2) unstable; urgency=low
>Description: Command Line XML Toolkit
>(...)
> The toolkit's feature set includes options to:
> Check or validate XML files (simple well-formedness check, DTD, XSD, RelaxNG)
> Calculate values of XPath expressions on XML files (such as running sums, etc)
> Search XML files for matches to given XPath expressions
> Apply XSLT stylesheets to XML documents (including EXSLT support, and passing
> parameters to stylesheets)
> Query XML documents (ex. query for value of some elements of attributes,
> sorting, etc)
> Modify or edit XML documents (ex. delete some elements)
> Format or "beautify" XML documents (as changing indentation, etc)
> Fetch XML documents using http:// or ftp:// URLs
> Browse tree structure of XML documents (in similar way to 'ls' command for
> directories)
> Include one XML document into another using XInclude
> XML c14n canonicalization
> Escape/unescape special XML characters in input text
> Print directory as XML document
> Convert XML into PYX format (based on ESIS - ISO 8879), and vice versa

Out of curiosity, what is its advantage over libxml2-utils and xsltproc ?

Mike

Re: Accepted xmlstarlet 0.9.3-2 (i386 source)

[Mike Hommey]

On Wed, Nov 17, 2004 at 05:13:28PM +0900, Mike Hommey wrote:
> Out of curiosity, what is its advantage over libxml2-utils and xsltproc ?

Okay, I found out by myself, it is built *on top* of libxml2 and
xsltproc, but the package not depending on it i was wondering.
And the fact is it is compiled statically.

Filing a bug.

Mike

Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor

[Mike Hommey]

On Wed, Dec 01, 2004 at 07:34:06PM -0600, John Goerzen <[EMAIL PROTECTED]> 
wrote:
[... nonsense ...]

Where did you see someone asking for inclusion of child porn ?

Mike

Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor

[Mike Hommey]

On Thu, Dec 02, 2004 at 07:53:41AM +0100, Christian Perrier <[EMAIL PROTECTED]> 
wrote:
> As already written in -women, this is the point which saddens me the
> most in this thread. I'm really disappointed by seeing most
> contributors just not realize why this package, as proposed, is likely
> to hurt the feelings of several women (probably not all, I don't know)
> as well as, indirectly or not, some men.
> 
> I have indeed no intention for objection this package in any
> matter. I'd just hope that the maintainer proposing it realizes that,
> though he personnally doesn't think so, his work may hurt some people.

Yeah, as some other things in Debian hurt some other people. It's a
matter of opinion and inclusion in Debian is not decided on opinion.

Period.

Mike

Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor

[Mike Hommey]

On Wed, Dec 01, 2004 at 06:18:35PM +0100, Goswin von Brederlow <[EMAIL 
PROTECTED]> wrote:
> Steve Langasek <[EMAIL PROTECTED]> writes:
> 
> > On Wed, Dec 01, 2004 at 04:01:06AM -0600, Ron Johnson wrote:
> >> Then, Disk 1 (which is very full-featured, after all) can be
> >> passed out where ever and to who ever, without any fear of
> >> possible problems.
> >
> > Hard-coding a list of "unacceptable" packages into the CD building scripts
> > is a waste of time, because the location of a package on a CD set is
> > primarily determined by its importance to the system and by its popularity.
> > Most of these packages are in danger of ending up on the first CD any time
> > soon -- and, if they were, why should we be overriding the overwhelming
> > preferences expressed by our users just to pander to the childish
> > sensibilities of people who *aren't* our users?
> 
> Even worse with dvd images where nearly everything is on disc1.

Are you kidding ? disc 2 is almost as big as disc 1. And with 2 discs,
you get no source, this is ridiculous. We should take the advantage of
the space available on a DVD to provide binary AND source of the
packages we put on a DVD.

Mike

Re: Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor

[Mike Hommey]

On Wed, Dec 01, 2004 at 04:06:13PM +, Helen Faulkner <[EMAIL PROTECTED]> 
wrote:
> I think that is the main issue here.  I would like to believe that Debian 
> is capable of showing more respect for other people than including hotbabe 
> in the distribution would indicate.

Yeah, i would like Debian to show more respect for me, by removing
emacs and kde.

Ah, the guy next door says he wants respect as well, and asks removal of
vim and gnome.

I'm pushing the thing to the absurd, but do you realise what you are saying
is absolutely ridiculous ?

Mike

Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor

[Mike Hommey]

On Thu, Dec 02, 2004 at 02:44:22AM -0600, Ron Johnson <[EMAIL PROTECTED]> wrote:
> "lewd exhibition of the genitals"

genitals: A sex organ, or primary sexual characteristic, narrowly
  defined, is any of those parts of the body (which are not always bodily
  organs according to the strict definition) which are involved in sexual
  reproduction and constitute the reproductive system in an complex
  organism; namely:

 * Male: penis (notably the glans and its covering the foreskin),
   testicles, scrotum, prostate, seminal vesicles, epididymis, Cowper's
   glands
 * Female: vulva (notably the clitoris and its covering the clitoral
   hood), vagina (notably the cervix), labia, uterus, Fallopian tubes,
   ovaries, Skene's glands, Bartholin's glands.


Now you have to tell me where you see genitals in hot-babe... I barely
see pubic hair.

Mike

Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor

[Mike Hommey]

On Thu, Dec 02, 2004 at 09:03:18AM -0600, John Goerzen <[EMAIL PROTECTED]> 
wrote:
> Indeed, and this is also why Manoj's vi/KDE argument is not relevant.
> 
> vi serves a useful purpose for an operating system.
> 
> Porn/nudes/whatever don't.

What about the bible, then ?

Mike

Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor

[Mike Hommey]

On Thu, Dec 02, 2004 at 12:28:20PM -0200, Fernanda Giroleti Weiden <[EMAIL 
PROTECTED]> wrote:
> Hi all,
> 
> Em Qui, 2004-12-02 às 07:46, Tollef Fog Heen escreveu:
> > * Helen Faulkner 
> > 
> > | Pornography is widely regarded as being demeaning and insulting to women.
> > 
> > - A lot of people don't think the cartoon is pornography.
> 
> A lot of men don't think the cartoon is pornography.

1. Please don't think for other women than yourself, thanks for the
   others.
2. Please take a look into a dictionary for the definition of
   pornography.

Mike

Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor

[Mike Hommey]

On Fri, Dec 03, 2004 at 01:26:50AM +0100, Michelle Konzack <[EMAIL PROTECTED]> 
wrote:
> Am 2004-12-02 18:11:03, schrieb Manoj Srivastava:
> 
> > The Bible is illegal to distribute in the most populous nation
> >  in the world.
> 
> Not only this, because the "Old Testament" glorifies the genocide...
> The Thora too. But not the Quran :-)

True, the Koran just invites to kill your ennemy bloodily, that's very
different...

Mike

Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor

[Mike Hommey]

On Thu, Dec 02, 2004 at 07:29:53PM -0500, William Ballard <[EMAIL PROTECTED]> 
wrote:
> On Thu, Dec 02, 2004 at 04:28:11PM -0800, Steve Langasek wrote:
> > Because he's an idiot.  Can we move on to something on-topic?
> 
> Fuck you.

You're being offensive, you should not be included in Debian.

Mike

Bug#284189: ITP: xul-runner -- XUL/XPCOM application runner

[Mike Hommey]

Package: wnpp
Severity: wishlist

* Package name: xul-runner
  Version : 0.0.0
  Upstream Author : The Mozilla Project
* URL : http://www.mozilla.org/
* License : GPL/LGPL/MPL
  Description : XUL/XPCOM application runner

 The goal of the XUL Runner application is to provide a lightweight
 container application that can be used to bootstrap XUL+XPCOM
 applications that are as rich as Firefox and Thunderbird.

Note that it has not yet been released and is only available in the
mozilla.org cvs. Also note it is planned to be the central point for
Firefox/Thunderbird/Mozilla, finally leaving a much less important
memory footprint when running 2 or more of them at the same time, and
avoiding the huge source duplication we currently have in all their
.orig.tar.gz.

PS: The description is temporary.

Re: charsets in debian/control

[Mike Hommey]

On Mon, Dec 06, 2004 at 09:54:36AM +1100, Paul Hampson <[EMAIL PROTECTED]> 
wrote:
> Isn't there a proposal around for
> Description#en: 
> Description#ja: 

And you'd advocate to write the English text in latin1 and the japanese
text in euc-jp ?
Let's make it clear: 1 text file, 1 encoding.

Mike

Re: Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor

[Mike Hommey]

On Sun, Dec 05, 2004 at 08:50:25PM -0600, Ron Johnson <[EMAIL PROTECTED]> wrote:
> Be real, man.  Steve Greenland said it perfectly: "Choosing not 
> to distribute a given package is NOT censorship.  ...  This is not
> a subtle difference."

Allowing the package with the provision it doesn't contain the original
so-called pornographic (make me laugh) drawings would be censorship.
Allowing the package with the provision it does provide some random
pictures instead of the so-called pornographic (make me laugh again)
drawings would be stupid.
Allowing the package with the provision it does provide the so-called
pornographic drawings plus some others of a man, for equality purpose
would be hypocrisy.

On the other hand, not allowing the package would definitely not be the
former of the three, but could be considered to be stupid and/or
hypocrisy. 

Mike

Re: Debian's status as a legal entity and how it could effect a potential defense.

[Mike Hommey]

On Sun, Dec 05, 2004 at 09:38:51PM -0800, Thomas Bushnell BSG <[EMAIL 
PROTECTED]> wrote:
> Anibal Monsalve Salazar <[EMAIL PROTECTED]> writes:
> 
> > For one, the Australian laws prohibite any web site in Australia to host
> > pornographic material.
> > 
> > See http://www.efa.org.au/Issues/Censor/cens1.html
> 
> Do we have evidence--actual evidence--that this provision applies to
> cartoons?  Keep in mind that the images in question are *not*
> photographs.

Neither are they pornography.
This is a non-flamewar about a non-case about non-photographs of 
non-pornography.

Mike

PS: This was a non-mail.

Re: Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor

[Mike Hommey]

On Sun, Dec 05, 2004 at 09:13:29PM -0600, Ron Johnson <[EMAIL PROTECTED]> wrote:
> No.  "We" are not calling on the Morality Police to take the
> particular web site down.  "We" are not saying, "you can not
> install that app on your computer".
> 
> There's a *fundamental* difference between "don't want hot-babe
> in Debian" and "don't want hot-babe to *exist*".

That doesn't contradict the fact that this could be considered stupid
and/or hypocritic, while *not* censorship.

Mike

Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor

[Mike Hommey]

On Mon, Dec 06, 2004 at 12:26:17AM -0600, Manoj Srivastava <[EMAIL PROTECTED]> 
wrote:
>   Umm, only if it is indeed deemed to be illegal. So far, there
>  has been just FUD about this issue. I am not sure that artistic work
>  qualifies as porn, which seems to be the case here.

Artistic or not, the pictures in hot-babe are *not* porn.

Mike

Re: Debian's status as a legal entity and how it could effect a potential defense.

[Mike Hommey]

On Mon, Dec 06, 2004 at 01:11:10AM -0600, Manoj Srivastava <[EMAIL PROTECTED]> 
wrote:
>   Seems more like there is a more of a minority of uber right
>  wingers trying to batten down art that offends their sensibility. The
>  actual project members seem to be more or less taking the sensible
>  approach, in that this is a mountain being made out of a small
>  molehill. 
> 
>   And if you have done the legal homework to prove that the
>  package is illegal, please do presernt it. In the meanwhile, I'll
>  continue to trust my gut that  it is innocent, until proven guilty.

I'd go further and say that if we don't allow hot-babe in while it is
*unproven* to be illegal, then we should remove all the patented stuff
that are unproven to be enforced, and the stuff that is said patented
with unproven patent claims.

Now we're back to 42 packages and no kernel, i think we can release
sarge in 2 hours.

Mike

Re: Duelling banjos or how a sane community goes crazy

[Mike Hommey]

On Mon, Dec 06, 2004 at 08:12:50AM +0100, Andreas Tille <[EMAIL PROTECTED]> 
wrote:
> Hi fellow developers,
> 
> I failed in ending this thread when I posted
> 
>   http://lists.debian.org/debian-devel/2004/12/msg00016.html
> 
> instead I caused two trolls making even more noise.
> 
> I hope all you people are aware that you are causing a new duelling banjo
> case and helping out Google to connect Debian with hot-babes.

Waw, 20th hit on google:hot babe for the german article.

Mike

Re: Debian's status as a legal entity and how it could effect a potential defense.

[Mike Hommey]

On Sun, Dec 05, 2004 at 11:42:15PM -0800, Bruce Perens <[EMAIL PROTECTED]> 
wrote:
> Thomas Bushnell BSG wrote:
> 
> >But it seems that now you're telling me that you know better than the
> >mirror operators which packages will violate their internal policies.
> > 
> >
> Certainly a good guess is better than nothing. Upon such a list it would 
> be possible to err on the side of caution and allow them to decide what 
> /not /to reject.

What happens if they change their policy ? What if it gets even stricter
? Do we have to delete packages because they're acting crazy ?
If a mirror hoster has stupid policies, why just don't change mirror
hoster ? We can't be guarantor that every entity that mirrors debian
(and there are a lot more than the official mirrors) are strictly
following their local policies, especially dumb ones.

Mike

Re: Debian's status as a legal entity and how it could effect a potential defense.

[Mike Hommey]

On Mon, Dec 06, 2004 at 12:24:29PM +0100, Wouter Verhelst <[EMAIL PROTECTED]> 
wrote:
> On Mon, Dec 06, 2004 at 04:34:54PM +1100, Anibal Monsalve Salazar wrote:
> > On Sun, Dec 05, 2004 at 09:06:23PM -0800, Thomas Bushnell BSG wrote:
> > >Bruce Perens <[EMAIL PROTECTED]> writes:
> > >
> > >>It strikes me that some of the material in question would be in
> > >>violation of the Internet policies of most institutions or companies
> > >>that host our mirrors, as well as the applicable national laws.
> > >
> > >Can you please provide some concrete evidence of this claim, or else
> > >stop making it?
> > 
> > For one, the Australian laws prohibite any web site in Australia to host
> > pornographic material.
> 
> Have you taken a look at the material in question before this post?

The answer is obviously no. And if you asked the same question to all the
"contributors" of this thread, i'm pretty sure you'd end up with a 80%
no.

Mike

Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor

[Mike Hommey]

On Tue, Dec 07, 2004 at 12:42:05AM +1100, Hamish Moffatt <[EMAIL PROTECTED]> 
wrote:
> On Mon, Dec 06, 2004 at 04:13:54PM +0900, Mike Hommey wrote:
> > On Mon, Dec 06, 2004 at 12:26:17AM -0600, Manoj Srivastava <[EMAIL 
> > PROTECTED]> wrote:
> > >   Umm, only if it is indeed deemed to be illegal. So far, there
> > >  has been just FUD about this issue. I am not sure that artistic work
> > >  qualifies as porn, which seems to be the case here.
> > 
> > Artistic or not, the pictures in hot-babe are *not* porn.
> 
> To quote Manoj, "And you are who, the culture police?"
> 
> I think it's a matter of opinion. I agree with you, but state
> your opinion as such rather than fact please.

Give me *one* authoritative definition of pornography that applies to
this picture. Until you give me one, I'll consider all the ones I've
seen so far to be the accurate ones, and none of them say these pictures
are pornography.

Mike

Re: charsets in debian/control

[Mike Hommey]

On Mon, Dec 06, 2004 at 06:53:42PM -0800, Steve Langasek <[EMAIL PROTECTED]> 
wrote:
> But yes, non-ASCII Latin-1 chars should not be given special status over
> the national chars found in other languages spoken by project members.
> Debian should be using either ASCII, or Unicode; standardizing on Latin-1
> makes no sense in a global project.

Actually Latin-9 would be better, it doesn't contain the useless Â.

Mike

Re: charsets in debian/control

[Mike Hommey]

On Mon, Dec 06, 2004 at 07:10:21PM -0800, Steve Langasek <[EMAIL PROTECTED]> 
wrote:
> On Tue, Dec 07, 2004 at 12:04:56PM +0900, Mike Hommey wrote:
> > On Mon, Dec 06, 2004 at 06:53:42PM -0800, Steve Langasek <[EMAIL 
> > PROTECTED]> wrote:
> > > But yes, non-ASCII Latin-1 chars should not be given special status over
> > > the national chars found in other languages spoken by project members.
> > > Debian should be using either ASCII, or Unicode; standardizing on Latin-1
> > > makes no sense in a global project.
> 
> > Actually Latin-9 would be better, it doesn't contain the useless Â

Re: SVG icons

[Mike Hommey]

On Wed, Dec 08, 2004 at 11:49:49PM +0100, Bill Allombert <[EMAIL PROTECTED]> 
wrote:
> The authoritative document is the menu _manual_:
> (/usr/share/doc/menu/menu.txt.gz), section 3.7
> 
> An extract from that section:
> 
>  Debian package maintainers should ensure that any icons they include
>  for use in the Debian menus conform to the following points:
> 
>  1.   The icons should be in xpm format.
> 
>  2.   The icons may not be larger than 32x32 pixels, although smaller
>   sizes are ok.

Note that's a "may" and a "should", not a "must". IIRC they only trigger
lintian warnings, not errors.

Mike

Re: dpkg-reversion: how about debedit?

[Mike Hommey]

On Wed, Dec 08, 2004 at 09:56:23PM +0100, martin f krafft <[EMAIL PROTECTED]> 
wrote:
> retitle 284642 ITP: debedit -- script to edit DEB files with hooks or 
> interactively
> thanks
> 
> Together with Goswin, I have now given dpkg-reversion the ability to
> invoke a hook on the unpacked binary package. He is now using it to
> test moving /lib64 from base-files to libc6 on amd64 and to change
> the debian/control:Architecture field on packages like OO.o -- for
> amd64.
> 
> The script could be used as a generic DEB file editor with automated
> versioning. I only need it for the version change, but the
> possibilities are endless.
> 
> Thus I propose to rename this ITP/package to debedit. What do you
> say?

Sounds good.
Could it be used for dh_striping the content of a package ?

Mike

Re: SVG icons

[Mike Hommey]

On Wed, Dec 08, 2004 at 09:16:06PM -0600, Ron Johnson <[EMAIL PROTECTED]> wrote:
> > Note that's a "may" and a "should", not a "must". IIRC they only trigger
> > lintian warnings, not errors.
> 
> If I tell my son, "You may not go play in the rain.", he knows 
> that he can't go play in the rain.


If you tell your som, "You must not go play in the rain", it's the best
way to be sure he'll be doing it ;)


> Thus, "may" in this context is ambiguous.  "Should" is only slightly
> less so.

See RFC 2119. I think usages of may, should, must and stuff should
follow these explanations.

Mike

Re: SVG icons

[Mike Hommey]

On Thu, Dec 09, 2004 at 12:56:23AM -0600, Ron Johnson <[EMAIL PROTECTED]> wrote:
> > See RFC 2119. I think usages of may, should, must and stuff should
> > follow these explanations.
> 
> There's an RFC for words???

Yes, there is one, to make sure everybody use the words for the same
thing, especially when people in a project doesn't share the same mother
tongue. For instance, mine is french, and distinction between "may" and
"should" is sometimes awkward to me.

Mike

Re: dpkg-reversion: how about debedit?

[Mike Hommey]

On Thu, Dec 09, 2004 at 09:29:57AM +0100, martin f krafft <[EMAIL PROTECTED]> 
wrote:
> also sprach Mike Hommey <[EMAIL PROTECTED]> [2004.12.09.0359 +0100]:
> > Sounds good.
> > Could it be used for dh_striping the content of a package ?
> 
> It is an unpacked DEB file, not a Debian source package, so I am not
> sure how much use the debhelper suite will be.

Well, let's say strip, then, wrapped in a little script. If i understood
correctly what your tool aims at, it would be possible to do that.

Mike

Re: list what's in the NEW queue?

[Mike Hommey]

On Thu, Feb 03, 2005 at 08:39:10PM +0100, Joerg Jaspert <[EMAIL PROTECTED]> 
wrote:
> Its just not out of NEW atm.

And now we're back to the original subject ;)

Mike


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

Re: [Ipw2100-devel] debian, ipw2200 and wlan0

[Mike Hommey]

On Mon, Feb 07, 2005 at 03:34:22PM +0100, Wichert Akkerman <[EMAIL PROTECTED]> 
wrote:
> Previously Mike Hommey wrote:
> > On Mon, Feb 07, 2005 at 03:11:28AM +0100, Henrik Brix Andersen <[EMAIL 
> > PROTECTED]> wrote:
> > > The default interface name of the ipw2X00 driver is, has always been and
> > > will continue to be, eth%d.
> > 
> > It is and has always been eth%d for a stupid reason. That's why I
> > changed it to wlan%d in the debian official package.
> 
> And here I thought Debian was a distribution which did not needlessly
> change upstream policies.

Debian is a distribution which tries to provide good software, implying
changes if necessary. Wireless interfaces should be called wlan%d, not
eth%d, and upstream doesn't want to change because "There are fewer
compatability issues with existing distributions by defaulting to eth%d
vs. wlan%d." [1]
Debian does support wlan%d interfaces without any known problem. If
there were any, I'd have gotten bug reports about it.
On the other hand, i know some people annoyed by the eth%d default for
wireless interfaces.

> You are aware that a) that will mean all existing documentation on the
> ipw2100 and ipw2200 drivers will not work for Debian users

The ipw2200 documentation in Debian is updated to fit Debian's
parameter.

> and b) that when the drivers is merged into the mainline kernel people will
> no longer use the seperate ipw2100/ipw2200 packages and suddenly have their
> system break because the device will use its standard name again?

I'll encourage Debian kernel maintainers to make the adequate changes.
As I said earlier, Debian is also about providing good software, making
additional changes from upstream if necessary, and I think Debian should
generally push the use of wlan%d name for wireless interfaces instead of
the upstream defaults, and try to push upstream to make the changes as
well.

Mike

PS: Why bringing that on debian-devel instead of filing a bug first, if
you're so annoyed ?

[1] http://sourceforge.net/mailarchive/message.php?msg_id=9651220 ;
there also have been numerous messages asking for a change of the
default value on the list.


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

Re: Bug#294491: RFA: povray -- Persistence of vision raytracer

[Mike Hommey]

On Thu, Feb 10, 2005 at 08:03:02PM +0900, Miles Bader <[EMAIL PROTECTED]> wrote:
> Pascal Hakim <[EMAIL PROTECTED]> writes:
> >> That would be cool.  At least one of the povray maintainers has a
> >> giant stick up his butt about Debian, something along the lines of
> >> "The version of povray in Debian stable is old, so DEBIAN SUX0RS IN
> >> EVERY IMAGINABLE WAY!@&* YARGH#(*!!! LOL!"
> >
> > Would this be the same povray that's not in Debian?
> 
> It's in non-free:

Thus not in Debian.

Mike


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

Re: "The Debian exim 4 packages suck badly" on exim-users@exim.org

[Mike Hommey]

On Fri, Feb 18, 2005 at 02:15:16PM -0600, Steve Greenland <[EMAIL PROTECTED]> 
wrote:
(...)
> And yes, it does belong there. It could easily add the something like:
> 
>The single monolithic file is the normal upstream configuration,
>while the other choice is a Debian innovation that works better with
>large installations or ISPs needing to support many virtual domains.
> 
> For newbies, this is the first MTA installation they will have ever
> seen. Help 'em out, for Pete's sake.

Do newbies understand the concept of "upstream" ?

Mike


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

Re: Shouldn't kernel-image-2.6.x-y-z depend on alsa-base ?

[Mike Hommey]

On Wed, Mar 09, 2005 at 05:46:22PM -0800, Steve Langasek <[EMAIL PROTECTED]> 
wrote:
> Considering you're talking about solutions that require updates to
> kernel-image packages *anyway*, why has no one suggested adding the
> necessary blacklist entries to these packages?  Far better than removing a
> bunch of modules from the kernel-image at this late stage, IMHO.

It doesn't work properly with several kernel-images installed.

Mike


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

Re: Serious kernel problems on new i386 hardware

[Mike Hommey]

On Thu, Mar 10, 2005 at 03:10:12PM +0100, Andreas Tille <[EMAIL PROTECTED]> 
wrote:
>   ERROR: Removing 'trm290': Device or resource busy
>   ERROR: Removing 'vis82cxxx': Device or resource busy
>   pivot_root: No such file or directory
>   /sbin/init: 432: cannot open dev/console: No such file
>   Kernel panic - not syncing: Attempt to kill init!

Let me guess... you are using devfs in 2.4, and /dev is empty if devfs
is not mounted.

Mike


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

Bug#298941: ITP: ext3rminator -- recover deleted files from an ext3 filesystem

[Mike Hommey]

Package: wnpp
Severity: wishlist
Owner: Mike Hommey <[EMAIL PROTECTED]>

* Package name: ext3rminator
  Version : 0.3.0
  Upstream Author : Mike Hommey <[EMAIL PROTECTED]>
* URL : http://glandium.org/debian/repository/experimental/
* License : GPL
  Description : recover deleted files from an ext3 filesystem

 Ext3rminator is a last chance program when you just unthoughtfully deleted
 several megabytes of data on an ext3 (or ext2) partition. It goes through all
 free blocks in the filesystem to look for what can look like data.
 .
 It is only able to recover files where the 48 first KB (actually, 12 blocks,
 a block usually being 4096 bytes) are contiguous.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.10-1-686
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8)


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

Re: Bug#276871 acknowledged by developer (Bug#276871: fixed in gdm 2.8.0.6-1)

[Mike Hommey]

reopen 276871 309224 258934 327464 261979 290916 304027 314449
thanks

On Thu, Nov 17, 2005 at 04:03:08AM -0800, Debian Bug Tracking System <[EMAIL 
PROTECTED]> wrote:
> This is an automatic notification regarding your Bug report
> #276871: Date shown in gdm is correctly localized, but only for a minute.,
> which was filed against the gdm package.
[...]
>* New upstream release (closes: #313200, #309224, #258934, #327464, 
> #261979,
>  #290916, #276871, #304027, #314449)

I'm happy to see that my bug, and many others, have been considered as a request
for new upstream, which #313200 is, by the way.

When will people just stop doing that ?!?

Mike


Sidenote:
>* Pass -dpi 96 to the X Server by default (closes: #285029)
That sucks badly. You just broke configuration of people who actually have a
correct configuration of their X Server.


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

Re: Bug#276871 acknowledged by developer (Bug#276871: fixed in gdm 2.8.0.6-1)

[Mike Hommey]

On Thu, Nov 17, 2005 at 11:12:22AM -0500, Roberto C. Sanchez <[EMAIL 
PROTECTED]> wrote:
> I looked at all the bugs for gdm and the bugs you reopened were tagged
> as upstream and/or fixed-upstream.

And as the bug reporter, you never get the message that says that the
bug has been tagged. *That* could be subject to a bug report to b.d.o.

> I don't think that the bug closures
> were meant to imply that you requested a new upstream version, just that
> the bug has now been fixed in the upstream release.
> 
> Personally, I will list multiple bugs in the new upstream release line
> in my changelog, if they are actually fixed.

I don't want to repeat what has been said over and over each time such
issues has been raised, but basically, i'd expect the changelog to at
least say what kind of bug is fixed or even better what has been done so
that the bug was fixed, instead of just closing in this way. The Closes:
facility in changelogs is not a bare replacement for the bts close command
line.

Cheers,

Mike


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

Re: [RFC] xulrunner, shlibs, and dependencies.

[Mike Hommey]

On Fri, Dec 02, 2005 at 05:52:03PM -0800, Steve Langasek <[EMAIL PROTECTED]> 
wrote:
> On Fri, Dec 02, 2005 at 08:47:47PM +0100, Mike Hommey wrote:
> 
> > As you may or may not know, I'm currently working on packaging
> > xulrunner, which is ought to be the central point for all future mozilla
> > technology, meaning that at more or less long term, all mozilla products
> > (firefox, thunderbird, etc.) will be built on top of it.
> > That will be indeed a great improvment in both memory (who really wants
> > to have libraries loaded twice just because you run 2 of their programs)
> > and security management.
> 
> I think this question is more suited for debian-devel than for
> debian-release, fwiw.  Library packaging is not the exclusive responsibility
> of the release team. :)

Moving there.

> > So my idea is the following :
> > - First, I want to provide the libs with a correct soname. It won't be
> > compatible with upstream until some people use clue sticks, but i'll do
> > my best for them to improve on that point. Having a correct soname will
> > enable us to actually use the shlibs mecanism.
> 
> > - Now, the problem is that we can't really use the sonames correctly,
> > because if we succeed in the clue stick batting, we'll have different
> > sonames, which, in the long term, would be painful. So, I'd like to
> > provide a dummy gecko-x.y-serial or such package, which would correctly
> > depend on the libxul package (with strict version if necessary), and the
> > .shlibs in the libxul-dev package would say to depend on the
> > gecko-x.y-serial package.
> 
> If you don't want to make up sonames (and I think having debian-specific
> sonames is fine, personally), I think that having libxul provide a virtual
> package to use in dependencies is the best option (whether that's
> gecko-x.y-serial, or libxul1debianX, makes no real difference).

Will all the tools resolving the dependencies be fine with a dependency
on a virtual package without one an a real package ? (like for
zlib1g-dev | libz-dev)

> There are two advantages to managing sonames even when upstream does not:
> it lets you interface better with un-packaged software (but *only* if that
> software is built against the Debian version!), and it allows
> co-installability of different library versions.  You need to decide whether
> these features are important enough for your application to warrant spinning
> your own sonames.  (My guess is no.)

My concern is more about what it becomes when we hopefully get upstream
to use sonames. Someone suggested me to use specific sonames like
libxul.so.d1. Does that really work ? Do shlibs work as well with that ?

If this is the case, I think i have my solution...

Mike


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

Re: [RFC] xulrunner, shlibs, and dependencies.

[Mike Hommey]

On Sat, Dec 03, 2005 at 12:28:36AM -0800, Steve Langasek <[EMAIL PROTECTED]> 
wrote:
> On Sat, Dec 03, 2005 at 08:58:45AM +0100, Mike Hommey wrote:
> > > > So my idea is the following :
> > > > - First, I want to provide the libs with a correct soname. It won't be
> > > > compatible with upstream until some people use clue sticks, but i'll do
> > > > my best for them to improve on that point. Having a correct soname will
> > > > enable us to actually use the shlibs mecanism.
> 
> > > > - Now, the problem is that we can't really use the sonames correctly,
> > > > because if we succeed in the clue stick batting, we'll have different
> > > > sonames, which, in the long term, would be painful. So, I'd like to
> > > > provide a dummy gecko-x.y-serial or such package, which would correctly
> > > > depend on the libxul package (with strict version if necessary), and the
> > > > .shlibs in the libxul-dev package would say to depend on the
> > > > gecko-x.y-serial package.
> 
> > > If you don't want to make up sonames (and I think having debian-specific
> > > sonames is fine, personally), I think that having libxul provide a virtual
> > > package to use in dependencies is the best option (whether that's
> > > gecko-x.y-serial, or libxul1debianX, makes no real difference).
> 
> > Will all the tools resolving the dependencies be fine with a dependency
> > on a virtual package without one an a real package ? (like for
> > zlib1g-dev | libz-dev)
> 
> Yes.  See apt's Provides for an example of this.

So why do we keep providing transition packages, then ?

> > > There are two advantages to managing sonames even when upstream does not:
> > > it lets you interface better with un-packaged software (but *only* if that
> > > software is built against the Debian version!), and it allows
> > > co-installability of different library versions.  You need to decide 
> > > whether
> > > these features are important enough for your application to warrant 
> > > spinning
> > > your own sonames.  (My guess is no.)
> 
> > My concern is more about what it becomes when we hopefully get upstream
> > to use sonames. Someone suggested me to use specific sonames like
> > libxul.so.d1. Does that really work ? Do shlibs work as well with that ?
> 
> > If this is the case, I think i have my solution...
> 
> Yes, sonames can be more or less arbitrary strings.  You can certainly use
> sonames with "debian" in them with a fairly high degree of confidence that
> upstream won't collide with them.

THAT is cool.

Mike


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

Re: [RFC] xulrunner, shlibs, and dependencies.

[Mike Hommey]

> > Yes, sonames can be more or less arbitrary strings.  You can certainly use
> > sonames with "debian" in them with a fairly high degree of confidence that
> > upstream won't collide with them.
> 
> THAT is cool.

FWIW, FYI, I did some work on that and managed to build xulrunner with
basic sonames through quite clean additions to the mozilla build system
for the base tree and the nspr tree. I still need to do similar work for
the security tree (being the libnss and friends), though (their build
system is really brain damaged, and i'm not even talking about the fact
they include libjpeg, libcairo, libbz2, (...) sources).

The good thing is that shlibs work correctly now :)

I also managed to build epiphany on top of it, but that required a few
adjustments I'll submit in the BTS when the package will be uploaded,
which I believe might occur in 10 days or so.

Cheers,

Mike


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

Re: [RFC] xulrunner, shlibs, and dependencies.

[Mike Hommey]

On Tue, Dec 06, 2005 at 09:04:57PM +0100, Josselin Mouette <[EMAIL PROTECTED]> 
wrote:
> Le mardi 06 décembre 2005 à 20:43 +0100, Mike Hommey a écrit :
> > > THAT is cool.
> > 
> > FWIW, FYI, I did some work on that and managed to build xulrunner with
> > basic sonames through quite clean additions to the mozilla build system
> > for the base tree and the nspr tree. I still need to do similar work for
> > the security tree (being the libnss and friends), though (their build
> > system is really brain damaged, and i'm not even talking about the fact
> > they include libjpeg, libcairo, libbz2, (...) sources).
> 
> BTW, did you get it to build against the Debian versions of these
> libraries? That would be even cooler ;)

That's done ; they actually provide a way to use the system libraries,
except for libbz2, for which i sent them a patch for. I'm actually
trying to get the most patches possible applied upstream...

Cheers,

Mike

> -- 
>  .''`.   Josselin Mouette/\./\
> : :' :   [EMAIL PROTECTED]
> `. `'[EMAIL PROTECTED]
>   `-  Debian GNU/Linux -- The power of freedom



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

Re: Bug#345160: ITP: libgpod -- a library to read and write songs and artwork to an iPod

[Mike Hommey]

On Fri, Dec 30, 2005 at 10:54:25AM +0100, Christian Marillat <[EMAIL 
PROTECTED]> wrote:
> Felipe Sateler <[EMAIL PROTECTED]> writes:
> 
> > There is already a libgpod0 package on Christian Marillat's archive, so I 
> > guess there must be an issue regarding this package's relation with debian.
> 
> No issues for this package. I simply did these packages because this is
> more fast to me, instead of waiting for an official package. Nice to play
> with artworks and videos :)

Something troubles me. You make unofficial packages while waiting for official
packages. Aren't you DD ? Wouldn't uploading these unofficial packages
in unstable make them official ?

Mike


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

Does it sometimes happen that people send mails before NMU ?

[Mike Hommey]

There have been 2 NMUs on libxml2 in a week and I never got a message
beforehand. Now I wonder if that practice has disappeared somehow.

I admit I've not spent enough time for libxml2 recently, but still, I
wouldn't have been bothered by some poking beforehand.

Moreover, I'm not exactly sure the second NMU has indeed removed all
problematic content but the bug is closed, so the NMUer may be happy.
Ah, by the way, the bug was not even a problem for package propagation
to testing, so that doesn't make the propagation an argument for a quick
upload.

No thanks

Mike


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

Re: Does it sometimes happen that people send mails before NMU ?

[Mike Hommey]

On Sun, Jan 15, 2006 at 11:31:10PM -0800, Steve Langasek <[EMAIL PROTECTED]> 
wrote:
> Hi Mike,
> 
> On Mon, Jan 16, 2006 at 07:47:52AM +0100, Mike Hommey wrote:
> > There have been 2 NMUs on libxml2 in a week and I never got a message
> > beforehand. Now I wonder if that practice has disappeared somehow.
> 
> > I admit I've not spent enough time for libxml2 recently, but still, I
> > wouldn't have been bothered by some poking beforehand.
> 
> > Moreover, I'm not exactly sure the second NMU has indeed removed all
> > problematic content but the bug is closed, so the NMUer may be happy.
> > Ah, by the way, the bug was not even a problem for package propagation
> > to testing, so that doesn't make the propagation an argument for a quick
> > upload.
> 
> The first bug shows a message from the NMUer apologizing for not sending his
> patch beforehand.  The second bug shows a patch sent by the NMUer prior to
> the NMU.  Did you not receive these mails?

The patch was 8 minutes prior to the NMU.

> > Moreover, I'm not exactly sure the second NMU has indeed removed all
> > problematic content but the bug is closed, so the NMUer may be happy.
> > Ah, by the way, the bug was not even a problem for package propagation
> > to testing, so that doesn't make the propagation an argument for a quick
> > upload.
> 
> Well, no, but the fact that it's a longstanding release-critical bug, with
> no maintainer response, means that it does warrant NMUer attention.  If some
> non-free files have been missed in the process, that would be bad, but that
> doesn't seem to be a reason to not try?  Of course, it's your prerogative as
> maintainer to review the contents of the NMU for correctness before
> acknowledging the bug closure.

Yes, it's my fault i didn't tag the bug or sent any feedback, but I'm
actually trying to find a better solution than removing the files, with
upstream cooperation, considering that upstream adds new testcases quite
often, and that any addition is likely to have the same problem.

Fixing RC bugs just for the sake of making the RC bug count down is not
the best thing to do IMHO. Some might even only be important bugs tagged
as grave or serious for some wrong reasons.

Mike


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

Re: Does it sometimes happen that people send mails before NMU ?

[Mike Hommey]

On Mon, Jan 16, 2006 at 08:34:07PM +1000, Anthony Towns 
 wrote:
> On Mon, Jan 16, 2006 at 09:41:12AM +0100, Mike Hommey wrote:
> > > Well, no, but the fact that it's a longstanding release-critical bug, with
> > > no maintainer response, means that it does warrant NMUer attention.  If 
> > > some
> > > non-free files have been missed in the process, that would be bad, but 
> > > that
> > > doesn't seem to be a reason to not try?  Of course, it's your prerogative 
> > > as
> > > maintainer to review the contents of the NMU for correctness before
> > > acknowledging the bug closure.
> > Yes, it's my fault i didn't tag the bug or sent any feedback, but I'm
> > actually trying to find a better solution than removing the files, with
> > upstream cooperation, considering that upstream adds new testcases quite
> > often, and that any addition is likely to have the same problem.
> 
> Then you should reopen the bug (or remove the fixed tag), retitle it
> to "Previous non-free content should be reincluded under a free list"
> and set the severity to wishlist.
> 
> Having an NMU that removes the files doesn't stop you from readding them
> later when you and upstream have come to a conclusion.
> 
> > Fixing RC bugs just for the sake of making the RC bug count down is not
> > the best thing to do IMHO. 
> 
> Putting a temporary fix in place while a permanent one continues to be
> worked out is /exactly/ the right thing to do.

Putting a fix that solves partially the problem so that we can say the
RC bug is closed is not exactly the right thing to do.
There are much more than the removed files whose content is doubtful
license-wise. On the other hand, some of the removed files (the slashdot
rss feeds, for instance), are not exactly the kind of document that
ought to have licensing issues, but IANAL.
The "right" temporary fix, then, would have been to remove *all* the test
files.
But the files listed in the RC bug have been removed, the RC bug is
"fixed", the RC bug count going down, so everything is fine.

Mike


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

Re: Does it sometimes happen that people send mails before NMU ?

[Mike Hommey]

On Mon, Jan 16, 2006 at 11:35:17PM +1000, Anthony Towns 
 wrote:
> If you've got more information than is in the bug report, that's fine; add
> it to the bug report, and do whatever else is appropriate to fix the problem.
> 
> Closing reports without fixing real bugs isn't "fine", but there's no
> point I can see to moping about it on -devel -- especially when the bug
> report didn't have all the information.

The point is: fixing RC bugs without going a bit further than what is
written in the bug report (which actually stated "At least the
following files", implying further investigation necessary) is the result
of the "let's fix RC bugs so that the RC bugs count goes down" attitude.

I just got pissed by the does-not-fix-anything
second-in-a-row-without-notice NMU.

I will, indeed, reopen the bug and document it.

End of thread.


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

Re: For those who care about their packages in Ubuntu

[Mike Hommey]

On Tue, Jan 17, 2006 at 09:45:13PM +1000, Anthony Towns 
 wrote:
>  * for changes that are likely to be useful in Debian or generally, submit
>the change upstream, by filing a bug with a minimal patch included to
>bugs.debian.org, or by the appropriate mechanism further upstream.

s/or/and/.

There's no reason that should prevent the ubuntu maintainer to forward
his patch to upstream AND debian.

Mike


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

Re: when and why did python(-minimal) become essential?

[Mike Hommey]

On Sat, Jan 21, 2006 at 02:21:34PM -0600, Joe Wreschnig <[EMAIL PROTECTED]> 
wrote:
> Python is the "official" language of Ubuntu. If we want to merge work
> they're doing (Anthony Towns mentioned their work on boot speed, for
> example) it's a good idea to structure our Python like theirs is. This
> (...)

Boot speed and python does not really sound a match...


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

Re: Pre-Depends for Xorg 7.0

[Mike Hommey]

On Mon, Jan 23, 2006 at 12:48:24AM -0500, David Nusinow <[EMAIL PROTECTED]> 
wrote:
> Right. The everything that you'd expect to go in to /usr/bin and /usr/lib
> will install there, at least as far as Xorg goes. An example of that is
> that the new xterm package installs to /usr/bin rather than /usr/X11R6/bin.
> I haven't finished the packaging of everything, but it seems that some of
> the header files are put in to differenct dirs of /usr/include. I'll
> investigate the reasoning for this further. As for /usr/lib/X11, data files
> like fonts currently go in there.

Shouldn't the fonts ans other such files go in /usr/*share*/X11, instead ?

Mike


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

Re: Bug#349693: ITP: gst-fluendo-mp3 -- MP3 decoder plugin for GStreamer

[Mike Hommey]

On Tue, Jan 24, 2006 at 06:58:14PM +0100, Loïc Minier <[EMAIL PROTECTED]> wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Loic Minier <[EMAIL PROTECTED]>
> 
> * Package name: gst-fluendo-mp3
>   Version : 0.10.0
>   Upstream Author : Jan Schmidt <[EMAIL PROTECTED]>
> * URL : http://www.fluendo.com/resources/fluendo_mp3.php
> * License : MIT
>   Description : Fluendo mp3 decoder GStreamer plugin
>  This GStreamer plugin permits decoding of MPEG 1 audio layer III
>  streams.  It is derived from the ISO MPEG dist10 reference package.
>  .
>  This plugin differs from the GStreamer MAD plugin in that it doesn't
>  depend on a GPL library.
>  .
>  http://www.fluendo.com/resources/fluendo_mp3.php

What about the "redistribution contract" that "any distribution or Unix
maker out there who want to include the Fluendo MP3 plug-in with their
distribution" have to sign "to become an official redistributor" ?

Mike


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

Re: when and why did python(-minimal) become essential?

[Mike Hommey]

On Thu, Jan 26, 2006 at 04:12:35PM +0100, Josselin Mouette <[EMAIL PROTECTED]> 
wrote:
> Le samedi 21 janvier 2006 à 21:52 +0100, Mike Hommey a écrit :
> > On Sat, Jan 21, 2006 at 02:21:34PM -0600, Joe Wreschnig <[EMAIL PROTECTED]> 
> > wrote:
> > > Python is the "official" language of Ubuntu. If we want to merge work
> > > they're doing (Anthony Towns mentioned their work on boot speed, for
> > > example) it's a good idea to structure our Python like theirs is. This
> > > (...)
> > 
> > Boot speed and python does not really sound a match...
> 
> Surprisingly, python is often faster than perl for the same task.

Boot speed and perl does not really sound a match either.

Mike


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

Re: Bug#350982: ITP: slimscrobbler -- SlimServer plugin that submits listening data to Last.FM

[Mike Hommey]

On Thu, Feb 02, 2006 at 09:41:55PM -0500, Kevin Mark <[EMAIL PROTECTED]> wrote:
> Hi Josselin,
> I have read many descriptions that made no sense to me and it was
> mentioned that you either know what the jargon/terms are because they
> are in your area of expertise or else if you dont know the terms/jargon,
> you probably wouldn't be interested in the package. So I guess either
> you know what last.fm is, or you don't. If you don't, no one seem to want
> to explain it to you. This is but one example from many in the archive.
> Should I file some kind of minor bug with a certain usertag for each of
> these and will it be labeled wontfix?

Actually, you may not know what last.fm is, and still get interested in
it if someone gives you an explanation of what it is...

Mike


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

Re: Bug#353277: ndiswrapper in main

[Mike Hommey]

On Sat, Feb 18, 2006 at 05:04:54PM +0100, Goswin von Brederlow
> The availability to do this is enough even if there are other
> (possibly better) ways to do the same. One free driver _in_ Debian and
> the package should stay in main.
> 
> But does the cipe-source build or ship the windows driver for use with
> ndiswraper? I doubt that.
> 
> Which means you need some software (even if it is free) from outside
> Debian for ndiswraper. That makes it contrib imho.

Are there any free MSWord files in main ? No ? Then please move
antiword and similar tools to contrib.

Mike


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

Re: Bug#353277: ndiswrapper in main

[Mike Hommey]

On Sun, Feb 19, 2006 at 11:11:32AM +0100, Robert Millan <[EMAIL PROTECTED]> 
wrote:
> On Sat, Feb 18, 2006 at 05:36:37PM +0100, Mike Hommey wrote:
> > On Sat, Feb 18, 2006 at 05:04:54PM +0100, Goswin von Brederlow
> > > The availability to do this is enough even if there are other
> > > (possibly better) ways to do the same. One free driver _in_ Debian and
> > > the package should stay in main.
> > > 
> > > But does the cipe-source build or ship the windows driver for use with
> > > ndiswraper? I doubt that.
> > > 
> > > Which means you need some software (even if it is free) from outside
> > > Debian for ndiswraper. That makes it contrib imho.
> > 
> > Are there any free MSWord files in main ? No ? Then please move
> > antiword and similar tools to contrib.
> 
> You're turning this into non-sense.  An NDIS wrapper is OBVIOUSLY for the
> exclussive purpose of using non-free Windows drivers.  It is so obvious
> because nobody has written [1] free GPLed NDIS drivers.  EVER.  It has nothing
> to do with Wine and MSWord [2].
> 
> So, stop throwing unrelated points to this matter.  Just fix the bug.  Move 
> this
> to contrib, with all the other warez wrappers.

Some people obviously think that to qualify for main, there has to be
stuff in main that can be used with the program. Which I think is not
the point at all. If there were no MSWord file in main (which is not the
case, cf. my previous mail today), would we ask for antiword and friends
to be moved into contrib ?
The NDIS wrapper issue has nothing to do with the fact that there is no
NDIS driver in main.

Mike


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

Re: Bug#353277: ndiswrapper in main

[Mike Hommey]

On Sun, Feb 19, 2006 at 11:51:51AM +0100, Eduard Bloch <[EMAIL PROTECTED]> 
wrote:
> #include 
> * Mike Hommey [Sun, Feb 19 2006, 11:07:33AM]:
> 
> > I checked all these 141 packages (see attachment).
> > There are 12 MSWord files out of 1022 .doc/.doc.gz files.
> 
> HOW LAME! A 70kB message with 0.0001 percent of usefull content is not
> enough to impress debian-devel readers. Next time send a 7MiB large one,
> thanks.

Yeah, I should've send it in Word format.

Mike


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

Re: Bug#355849: ITP: gcin -- a input method platform, supports GTK/QT immodule and XIM

[Mike Hommey]

On Wed, Mar 08, 2006 at 05:22:57PM +0800, Tetralet <[EMAIL PROTECTED]> wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Tetralet <[EMAIL PROTECTED]>
> 
> 
> * Package name: gcin
>   Version : 1.1.7
>   Upstream Author : Edward Liu <[EMAIL PROTECTED]>
> * URL : http://www.csie.nctu.edu.tw/~cp76/gcin/
> * License : LGPL
>   Description : a input method platform, supports GTK/QT immodule and XIM
> 
> (Include the long description here.)
> 
>  Gcin is a input method platform, which supports GTK/QT immodule and XIM.
>  Gcin is focused mainly on Traditional Chinese. However, it is also very 
> useful
>  for Simplified Chinese, Japanese, and many other languages.
>  
>  Input method table format of gcin is almost as same as those of xcin and 
> scim.
>  
>  This package contains GTK immodules. If you want to use QT immodule, please
>  install gcin-qt3-immodule package.

What is the advantage over uim or scim ? Do we really need yet another
input method ?

Mike


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

Re: Adding dependencies to e2fsprogs: libdevmapperr, libselinux and libsepoll

[Mike Hommey]

On Wed, Mar 08, 2006 at 03:36:12PM -0500, Theodore Ts'o <[EMAIL PROTECTED]> 
wrote:
> 
> I have recently received a patch which allows the blkid library to
> properly handle device mapper partitions.  The problem is in order to do
> this, I have to link in libdevmapper, and by extension libselinux and
> libsepoll.  Since these libraries would depend on the blkid library,
> which is used by fsck, e2fsck, and other e2fsprogs programs, this
> essentially would drag in these libraries into everybody's systems.
> 
> Is there any objections to my uploading a new e2fsprogs package which
> does this?

libselinux1 is already pulled by (at least) cron and coreutils.
libdevmapper1.02 by lvm2 and lilo.
That's not that much more than what it already pulled, isn't it ?

Mike


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

Re: For those who care about stable updates

[Mike Hommey]

On Thu, Mar 09, 2006 at 07:05:24PM +0100, Josselin Mouette <[EMAIL PROTECTED]> 
wrote:
> Le jeudi 09 mars 2006 ? 16:39 +0100, Amaya a ?crit :
> > > but when will we try to solve some of the real problems we have
> > 
> > Hey! It's DPL election time! Lobby around. I really am biting my tongue,
> > but you don't have to.
> 
> Who are you going to lobby? The candidates who are playing an active
> role in "the problem", or the ones who are just claiming there is no
> problem and that we should all be friends?

Maybe the one with the Plan 9 ? /o\

Mike


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

libxml2 and libxslt uploads to sid, soon

[Mike Hommey]

Hi fellow developpers,

I just want you to make you aware that I'm planning to upload new
upstream versions of libxml2 and libxslt into sid soon.
Since the number of reverse dependencies on them are quite significant,
and since shlibs are going to be bumped, I'm posting this warning on
-release and -devel.
Both versions that will be uploaded into sid are targetted for sarge,
and will actually be the ones currently in experimental (or maybe latest
upstream for libxml2 if the change-set is not too significant comparing
to the one in experimental).
I'm planning the upload for early february (I'd say on the 1st or the
2nd). If you have any comment or need some delay for some reason, feel
free to answer this message. Just don't forget that these uploads mean
that all reverse depending packages, and some more indirect reverse
dependencies, will be stuck in sid the time for the packages to migrate
into sarge, which will be 10 days (urgency: low, except if someone has
an objection).

Thanks for listening.

Mike


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

Re: Bug#300993: ITP: nvu -- Nvu is a complete Web Authoring System based on the Mozilla Composer engine

[Mike Hommey]

On Mon, Mar 21, 2005 at 03:09:48PM -0600, Nick Price <[EMAIL PROTECTED]> wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Nick Price <[EMAIL PROTECTED]>
> 
> 
> * Package name: nvu
>   Version : 0.90 
>   Upstream Author : Linspire, Inc. <[EMAIL PROTECTED]>
> * URL : http://www.nvu.com/
> * License : MPL/LGPL/GPL tri-license
>   Description : Nvu is a complete Web Authoring System based on the 
> Mozilla Composer engine

Somebody already filed an ITP for nvu, see http://bugs.debian.org/231025
You might want to contact him to decide what you want to do.

Mike


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

Re: Bug#300993: ITP: nvu -- Nvu is a complete Web Authoring System based on the Mozilla Composer engine

[Mike Hommey]

On Wed, Mar 23, 2005 at 07:26:53PM +0100, Mike Hommey <[EMAIL PROTECTED]> wrote:
> On Mon, Mar 21, 2005 at 03:09:48PM -0600, Nick Price <[EMAIL PROTECTED]> 
> wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Nick Price <[EMAIL PROTECTED]>
> > 
> > 
> > * Package name: nvu
> >   Version : 0.90 
> >   Upstream Author : Linspire, Inc. <[EMAIL PROTECTED]>
> > * URL : http://www.nvu.com/
> > * License : MPL/LGPL/GPL tri-license
> >   Description : Nvu is a complete Web Authoring System based on the 
> > Mozilla Composer engine
> 
> Somebody already filed an ITP for nvu, see http://bugs.debian.org/231025
> You might want to contact him to decide what you want to do.

I should even have read the bug earlier, it is actually already sitting
in the NEW queue.

Mike


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

Re: why allow broken packages to get all the way to mirrors?

[Mike Hommey]

On Sun, Apr 03, 2005 at 02:28:36PM +0200, Bernd Eckenfels <[EMAIL PROTECTED]> 
wrote:
> In article <[EMAIL PROTECTED]> you wrote:
> > It seems there are only minimal checks, so developers can unwittingly
> > upload broken packages.
> 
> Any numbers where you can proof your claim? Developers are required to test
> the packages before upload, and I havent noticed any uninstallable package
> in years.
> 
> > Even if the package is only "broken until tomorrow, whereupon the
> > upload will be complete", that too should not be allowed to propagate
> > to the mirrors until ready.
> 
> This cannot happen, what do you mean? Uploads are integrity checked.
> Besides, thats what unstable is for, a package does not propagate to testing
> or stable it has bugs.

I think he's talking about mirrored Packages files being updated before
all the packages get mirrored and/or arch all packages reaching the
archive before arch specific builds (except the maintainer's arch),
because of buildd queue.

Mike


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

Re: why allow broken packages to get all the way to mirrors?

[Mike Hommey]

On Tue, Apr 05, 2005 at 08:18:25AM +0200, Andreas Barth <[EMAIL PROTECTED]> 
wrote:
> * Mike Hommey ([EMAIL PROTECTED]) [050403 14:55]:
> > I think he's talking about mirrored Packages files being updated before
> > all the packages get mirrored and/or arch all packages reaching the
> > archive before arch specific builds (except the maintainer's arch),
> > because of buildd queue.
> 
> For the first, there are well working mirror scripts that prevent that,

Why on earth aren't they in place on official mirrors ? I *always* get
404 errors for new packages at the time Packages has been updated on
ftp.fr.debian.org, at least.

Mike


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

Re: What does dh_strip --dbg-package do if two binary packages contain the same file?

[Mike Hommey]

On Fri, Jul 28, 2006 at 06:23:46PM +0200, Marc Haber <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> I would like to add a -dbg package to exim4. However, I doubt that
> dh_strip is doing the right thing here.
> 
> The Debian exim4 source package builds a number of binary packages.
> Two of them are exim4-daemon-light and exim4-daemon-heavy, both of
> with containing (different!) versions of /usr/sbin/exim4.
> 
> In the -dbg package created by dh_strip, I only have a single file
> /usr/lib/debug/usr/sbin/exim4. Which debug information does this
> contain? Does it contain debug information for both versions of the
> binary? How do I find out which binary the debug information contained
> inside belongs to?

You will need to create 2 -dbg packages. And use the -p option to
dh_strip in addition to --dpkg-package.

Mike


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

Re: Centralized darcs

[Mike Hommey]

On Wed, Aug 02, 2006 at 04:16:30PM -0500, John Goerzen <[EMAIL PROTECTED]> 
wrote:
> On Wed, Aug 02, 2006 at 08:31:29PM +0200, Eduard Bloch wrote:
> > > Really, I think that getting patches in darcs from people that are using
> > > "darcs send" is not only easier for me as a maintainer, but also easier
> > 
> > Much easier as storing the mail attachment under debian/patches? I doubt.
> 
> Yes, indeed it is.  darcs send will send each original darcs record as a
> discrete change.  darcs apply can run in an interactive mode to let the
> person approve (or not) each individual patch.  The full commit log from
> the original person also comes along automatically.
> 
> AND, there's no need to hack the Debian build infrastructure.
> 
> > > for them as contributors.  Plus it is really easy for people that don't
> > > grok darcs to just use normal tools to edit Debian source packages,
> > > create diffs, NMU packages, or whatever -- and for me to integrate their
> > > changes later.  This is not the case for the other special-purpose patch
> > > tools.
> > 
> > This does not really differ from the scenarios with patch management system.
> 
> Yes it does.  If I don't understand patch tool X, I have to learn how to
> use patch tool X before I can even begin hacking.
> 
> Nobody has to learn Darcs to hack on my packages.

Well if someone has to work on a "which of the applied patch broken
the package is such a way" kinda issue, he will have to, in order to
have access to the patches.
dpatch, quilt and others, in this case, make life easier (especially for
security support).

Mike


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

Re: Stuff the installer does which isn't done on upgrade....

[Mike Hommey]

On Thu, Aug 03, 2006 at 12:24:09AM -0400, Nathanael Nerode <[EMAIL PROTECTED]> 
wrote:
> So upgraded systems don't get the benefits of certain changes to the 
> installer's 
> defaults, or defaults in programs used by the installer.
> 
> I first thought of this when I noticed the change in the default tuning for
> ext2 partitions created by mke2fs.  Notably, dir_index and filetype are turned
> on by default now; this was not always the case.

I don't know about the installer, but all filesystems I created with
mke2fs recently also have resize_inode, which isn't even in the tune2fs
manpage.

Mike


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

[HELP] FTBFS on alpha for xulrunner

[Mike Hommey]

tag 381662 + help
thanks

Hi,

xulrunner is failing to build on alpha, and with both escher and goedel
being locked down, I have no access to an alpha machine to at least
understand the issue.

The error itself is
make[5]: Entering directory 
`/build/buildd/xulrunner-1.8.0.4/extensions/python/xpcom/src'
ErrorUtils.cpp
c++ -o ErrorUtils.o -c -fvisibility=hidden -DMOZILLA_INTERNAL_API 
-DOSTYPE=\"Linux2.6.14\" -DOSARCH=\"Linux\" -DBUILD_ID=00 
-I/usr/include/python2.3 -I../../../../dist/include/xpcom 
-I../../../../dist/include/string -I../../../../dist/include/pyxpcom 
-I../../../../dist/include -I../../../../dist/include/nspr   -fPIC   
-fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align 
-Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor 
-Wno-long-long -mieee -fshort-wchar -pthread -pipe  -DNDEBUG -DTRIMMED -O2 
-fno-strict-aliasing -g   -DMOZILLA_CLIENT -include 
../../../../mozilla-config.h -Wp,-MD,.deps/ErrorUtils.pp ErrorUtils.cpp
PyGBase.cpp
c++ -o PyGBase.o -c -fvisibility=hidden -DMOZILLA_INTERNAL_API 
-DOSTYPE=\"Linux2.6.14\" -DOSARCH=\"Linux\" -DBUILD_ID=00 
-I/usr/include/python2.3 -I../../../../dist/include/xpcom 
-I../../../../dist/include/string -I../../../../dist/include/pyxpcom 
-I../../../../dist/include -I../../../../dist/include/nspr   -fPIC   
-fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align 
-Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor 
-Wno-long-long -mieee -fshort-wchar -pthread -pipe  -DNDEBUG -DTRIMMED -O2 
-fno-strict-aliasing -g   -DMOZILLA_CLIENT -include 
../../../../mozilla-config.h -Wp,-MD,.deps/PyGBase.pp PyGBase.cpp
PyGBase.cpp: In member function 'nsresult 
PyG_Base::InvokeNativeGetViaPolicy(const char*, PyObject**)':
PyGBase.cpp:613: error: no matching function for call to 
'PyG_Base::InvokeNativeViaPolicyInternal(char [256], PyObject**&, int, int)'
PyGBase.cpp:563: note: candidates are: nsresult 
PyG_Base::InvokeNativeViaPolicyInternal(const char*, PyObject**, const char*, 
va_list)
make[5]: *** [PyGBase.o] Error 1

The code at PyGBase.cpp:613 reads:
 ret = InvokeNativeViaPolicyInternal(buf, ppResult, nsnull, nsnull);

which seems to indicate that the compiler is considering nsnull as an int.

nsnull is defined in xpcom/base/nscore.h as:
#define nsnull 0

It'd look like a int vs. pointer size difference, but in such a case,
I'd assume it would also fail to build on ia64, amd64... which is not
the case. Moreover, NULL is defined as 0 as well in system headers, so
it shouldn't be a problem.
Maybe it's the va_args implementation on alpha that somehow differs ?

I'd have liked to try to reproduce the problem with a simple testcase
but without access to an alpha machine... and I don't really want to
waste buildd time with successive uploads until i somehow find a fix.

So, if someone could either take a look at the issue or give me an
access to an alpha machine, that would be appreciated.

Thanks

Mike


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

Re: Setting up pbuilder or sbuild like experimental buildds

[Mike Hommey]

On Tue, Aug 08, 2006 at 07:30:14PM +0200, Loïc Minier <[EMAIL PROTECTED]> wrote:
> Hi there,
> 
>  I'd like to setup a pbuilder or sbuild (preferably pbuilder, but I'm
>  not sure it's possible) in the way I understand experimental buildds
>  are setup: to only pull experimental software when it's required by the
>  build-deps, but keep only unstable software when possible.  I would
>  also like experimental software purged after builds of course.
> 
>  Would someone share an APT + pbuilder / sbuild config to achieve this?

Wouldn't pbuilder with a basic apt pinning setup be enough ?

Mike


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

Re: [HELP] FTBFS on alpha for xulrunner

[Mike Hommey]

On Tue, Aug 08, 2006 at 10:11:15AM +0200, Bastian Blank <[EMAIL PROTECTED]> 
wrote:
> On Tue, Aug 08, 2006 at 07:57:40AM +0200, Mike Hommey wrote:
> > PyGBase.cpp: In member function 'nsresult 
> > PyG_Base::InvokeNativeGetViaPolicy(const char*, PyObject**)':
> > PyGBase.cpp:613: error: no matching function for call to 
> > 'PyG_Base::InvokeNativeViaPolicyInternal(char [256], PyObject**&, int, int)'
> > PyGBase.cpp:563: note: candidates are: nsresult 
> > PyG_Base::InvokeNativeViaPolicyInternal(const char*, PyObject**, const 
> > char*, va_list)
> > make[5]: *** [PyGBase.o] Error 1
> > 
> > The code at PyGBase.cpp:613 reads:
> >  ret = InvokeNativeViaPolicyInternal(buf, ppResult, nsnull, nsnull);
> 
> This is not valid. va_list is no pointer, it is an opaque type
> 
> > Maybe it's the va_args implementation on alpha that somehow differs ?
> 
> Exactly. Alpha implements it as a struct.

Thanks, that confirms my doubts and gave me a hint for a fix. Though,
after looking at the surrounding code, it seems the function which the
error occured in is not used. I asked upstream if it is safe to just
remove it.

Mike


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

Re: Bug#382531: ITP: furl -- a small utility for displaying the HTTP headers returned by Web servers

[Mike Hommey]

On Fri, Aug 11, 2006 at 06:35:42PM +0200, Marco Bertorello <[EMAIL PROTECTED]> 
wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Marco Bertorello <[EMAIL PROTECTED]>
> 
> 
> * Package name: furl
>   Version : 2.1
>   Upstream Author : Kidney Bingos <[EMAIL PROTECTED]>
> * URL : http://www.gumbynet.org.uk/software/furl.html
> * License : GPL v2 (or later)
>   Programming Lang: C
>   Description : a small utility for displaying the HTTP headers returned 
> by Web servers
> 
>  furl is a small utility for displaying the HTTP headers
>  returned by Web servers in response to client requests
>  .
>  It can impersonate two different browser: Internet Explorer
>  and Mozilla

Is there a real benefit over lynx -dump -head and similar things ?

Mike


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

Re: dh_python and python policy analysis

[Mike Hommey]

On Fri, Aug 25, 2006 at 10:22:10PM +0200, Josselin Mouette <[EMAIL PROTECTED]> 
wrote:
> Le vendredi 25 août 2006 à 13:01 +0200, Wouter Verhelst a écrit :
> > > I can't speak for others, but python-support provides
> > > pysupport-movemodules and pysupport-parseversions to separate the
> > > debhelper snippet from the actual abstraction code.
> > 
> > That is still not what is required. Unless these tools become part of
> > the dpkg-dev package, it should be documented in policy how they (are
> > supposed to) do their job.
> 
> If you want to stick a "policy" label on the python-support
> documentation, that's fine with me, but this is the least of my
> concerns. The important point is for this documentation to exist.
> 
> Also, my concern is to make the developer's life easier. I don't think
> writing gazillions of policies will help the developer. We have first to
> provide tools that implement this policy, after which we have plenty of
> time to write up formal documents. The whole point of free software is
> to re-use other people's tools and code.

The problem with the python policy is that there is no policy as to
where the modules are supposed to be installed. Depending on the tool
you are using (python-support or python-central), the directory is
different. Where is someone using none of these supposed to put them ?

Mike


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

Re: dh_python and python policy analysis

[Mike Hommey]

On Fri, Aug 25, 2006 at 11:34:51PM +0200, Josselin Mouette <[EMAIL PROTECTED]> 
wrote:
> Le vendredi 25 août 2006 à 23:11 +0200, Mike Hommey a écrit :
> > The problem with the python policy is that there is no policy as to
> > where the modules are supposed to be installed. Depending on the tool
> > you are using (python-support or python-central), the directory is
> > different. Where is someone using none of these supposed to put them ?
> 
> You can put them wherever you want as long as this complies with the FHS
> and that a set of .rtupdate/.rtinstall/.rtremove scripts take care of
> them. This is one of the only things that are currently standardized.

Wasn't it possible to have only one implementation of these provided by
python itself, the policy relying on those and only one location for
python modules ?

Mike


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

Re: dh_python and python policy analysis

[Mike Hommey]

On Sat, Aug 26, 2006 at 11:21:26AM +0200, Josselin Mouette <[EMAIL PROTECTED]> 
wrote:
> Le samedi 26 août 2006 à 00:16 +0200, Mike Hommey a écrit :
> > > You can put them wherever you want as long as this complies with the FHS
> > > and that a set of .rtupdate/.rtinstall/.rtremove scripts take care of
> > > them. This is one of the only things that are currently standardized.
> > 
> > Wasn't it possible to have only one implementation of these provided by
> > python itself, the policy relying on those and only one location for
> > python modules ?
> 
> This was the original plan proposed back in January. Until the python
> maintainer forced its cancellation (#347758), then came up with a
> broken, incompatible implementation.

Great

Mike


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

Re: Why does Ubuntu have all the ideas?

[Mike Hommey]

On Sun, Aug 27, 2006 at 01:05:56AM -0400, Theodore Tso <[EMAIL PROTECTED]> 
wrote:
> I agree that it would be nice if ifplugd or laptop-net were installed
> by default, but last I checked Debian didn't install either by
> default, either.  So what's your point?

Aren't they part of the laptop task, nowadays ?

Mike


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

Re: The bigger issue is badly licensed blobs (was Re: Firmware poll

[Mike Hommey]

On Tue, Aug 29, 2006 at 07:17:47PM -0700, Steve Langasek <[EMAIL PROTECTED]> 
wrote:
> On Tue, Aug 29, 2006 at 08:48:00PM -0400, Nathanael Nerode wrote:
> 
> > Debian needs to make a decision on how it will deal with this legal
> > minefield.  That is higher priority than the entire discussion going on
> > right now, because it determines whether Debian will distribute these 53
> > BLOBs *at all*, in 'main' or in 'non-free'.
> 
> > Oddly enough nobody has proposed a GR addressing this,
> 
> Because voting is an absurd means of settling questions of legal liability.
> It's the domain of the ftp team to determine whether we can legally
> distribute a package on our mirrors.

So, all in all, all this fuss for seven blobs ? waw, what a waste of
time.

Mike


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

Re: The bigger issue is badly licensed blobs (was Re: Firmware poll

[Mike Hommey]

On Wed, Aug 30, 2006 at 09:00:27AM +0200, Raphael Hertzog wrote:
> On Wed, 30 Aug 2006, Mike Hommey wrote:
> > On Tue, Aug 29, 2006 at 07:17:47PM -0700, Steve Langasek <[EMAIL 
> > PROTECTED]> wrote:
> > > On Tue, Aug 29, 2006 at 08:48:00PM -0400, Nathanael Nerode wrote:
> > > 
> > > > Debian needs to make a decision on how it will deal with this legal
> > > > minefield.  That is higher priority than the entire discussion going on
> > > > right now, because it determines whether Debian will distribute these 53
> > > > BLOBs *at all*, in 'main' or in 'non-free'.
> > > 
> > > > Oddly enough nobody has proposed a GR addressing this,
> > > 
> > > Because voting is an absurd means of settling questions of legal 
> > > liability.
> > > It's the domain of the ftp team to determine whether we can legally
> > > distribute a package on our mirrors.
> > 
> > So, all in all, all this fuss for seven blobs ? waw, what a waste of
> > time.
> 
> 53 + 7 = 60.

Re-read Nathanael's mail. The blobs that are concerned by all the discussion
that has happened so far, and wasted a lot of time, are 7.

The 53 are those that have licenses that technically don't allow
redistribution.

> Please Mike, you have lately a tendency to inflame discussions for
> nothing. You've used me to expect better from you.

I'm just pissed about all this waste of time discussing in the void while
a release is "supposed" to happen in 3 months. And here I'm not only talking
about this particular thread.

Mike

PS: Don't worry, you won't hear a lot from me since I'll be on vacation from
saturday for almost 3 weeks.


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

Re: Bug#385793: -dev packages should not be architecture all

[Mike Hommey]

On Sun, Sep 03, 2006 at 10:27:27AM +0200, Matthias Klose <[EMAIL PROTECTED]> 
wrote:
> Mike Hommey writes:
> > On Sun, Sep 03, 2006 at 09:21:36AM +0200, Matthias Klose <[EMAIL 
> > PROTECTED]> wrote:
> > > Package: xulrunner
> > > Version: 1.8.0.5-3
> > > 
> > > With every upload, the libmozjs-dev, libnspr4-dev, libnss3-dev
> > > packages become uninstallable until the package has been rebuilt on
> > > all architectures.  Please consider changes these to architecture any,
> > > this saves developer's and buildd admin time to look at the current
> > > state of xulrunner, if a package can be uploaded without asking for
> > > requeueing on the buildd's later.
> > 
> > Problem is that it will waste quite some archive space... maybe relaxing
> > the dependencies would be better. I made them tight because I was adding
> > some APIs back in the 1.8.0.1 days, but that is not very likely to
> > happen any more...
> 
> relaxation on libxul-common is needed as well.

M that'd need special care to avoid libxul-common from a new upstream
being installed with an older libxul0d
Maybe it'd also be time to solve once and for all this arch:all issue.
It's not the first time it happens, and it won't be the last. Maybe it's
time that the archive keeps the old arch:all version until all arch:any
packages are in.

Ccing to debian-devel for that matter.

Mike


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

Re: Bug#385793: -dev packages should not be architecture all

[Mike Hommey]

On Sun, Sep 03, 2006 at 11:24:22AM +0200, Mike Hommey <[EMAIL PROTECTED]> wrote:
> On Sun, Sep 03, 2006 at 10:27:27AM +0200, Matthias Klose <[EMAIL PROTECTED]> 
> wrote:
> > Mike Hommey writes:
> > > On Sun, Sep 03, 2006 at 09:21:36AM +0200, Matthias Klose <[EMAIL 
> > > PROTECTED]> wrote:
> > > > Package: xulrunner
> > > > Version: 1.8.0.5-3
> > > > 
> > > > With every upload, the libmozjs-dev, libnspr4-dev, libnss3-dev
> > > > packages become uninstallable until the package has been rebuilt on
> > > > all architectures.  Please consider changes these to architecture any,
> > > > this saves developer's and buildd admin time to look at the current
> > > > state of xulrunner, if a package can be uploaded without asking for
> > > > requeueing on the buildd's later.
> > > 
> > > Problem is that it will waste quite some archive space... maybe relaxing
> > > the dependencies would be better. I made them tight because I was adding
> > > some APIs back in the 1.8.0.1 days, but that is not very likely to
> > > happen any more...
> > 
> > relaxation on libxul-common is needed as well.
> 
> M that'd need special care to avoid libxul-common from a new upstream
> being installed with an older libxul0d

An example of a too lax dependency of this kind is #383867 where ecj-bootstrap
(arch: all) is version 3.2 and ecj-bootstrap-gcj (arch: any) is 3.1.2 on
arm, and guess what, this setup fails to work at all.

Mike


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

Re: Bug#385793: -dev packages should not be architecture all

[Mike Hommey]

On Sun, Sep 03, 2006 at 11:24:22AM +0200, Mike Hommey <[EMAIL PROTECTED]> wrote:
> On Sun, Sep 03, 2006 at 10:27:27AM +0200, Matthias Klose <[EMAIL PROTECTED]> 
> wrote:
> > Mike Hommey writes:
> > > On Sun, Sep 03, 2006 at 09:21:36AM +0200, Matthias Klose <[EMAIL 
> > > PROTECTED]> wrote:
> > > > Package: xulrunner
> > > > Version: 1.8.0.5-3
> > > > 
> > > > With every upload, the libmozjs-dev, libnspr4-dev, libnss3-dev
> > > > packages become uninstallable until the package has been rebuilt on
> > > > all architectures.  Please consider changes these to architecture any,
> > > > this saves developer's and buildd admin time to look at the current
> > > > state of xulrunner, if a package can be uploaded without asking for
> > > > requeueing on the buildd's later.
> > > 
> > > Problem is that it will waste quite some archive space... maybe relaxing
> > > the dependencies would be better. I made them tight because I was adding
> > > some APIs back in the 1.8.0.1 days, but that is not very likely to
> > > happen any more...
> > 
> > relaxation on libxul-common is needed as well.
> 
> M that'd need special care to avoid libxul-common from a new upstream
> being installed with an older libxul0d
> Maybe it'd also be time to solve once and for all this arch:all issue.
> It's not the first time it happens, and it won't be the last. Maybe it's
> time that the archive keeps the old arch:all version until all arch:any
> packages are in.

(in the Packages file, I mean)

Mike


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

Re: Debian cares more about documents than people

[Mike Hommey]

On Thu, Sep 21, 2006 at 10:45:06AM -0500, alfredo diega <[EMAIL PROTECTED]> 
wrote:
> On 9/21/06, Ben Armstrong <[EMAIL PROTECTED]> wrote:
> >
> >-
> >I can see you're frustrated.  You've invested a lot of energy into
> >writing this note to us about a problem you see in Debian.  Now, if it
> >really does pain you to write it, the least you could do is tell us
> >what your hardware is.  Otherwise, how do you expect us to make things
> >better for you?
> >
> >Regards,
> >Ben
> >
> 
> Okay:  Intel PRO/Wireless 3945ABG.  According to this message at
> bugs.debian.org/cgi-bin/bugreport.cgi?bug=363967 it isn't packaged because:

Note that this driver requires a "binary user space regulatory
daemon", and thus will never be in debian. At most, in non-free.

Mike


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

Re: Media players in Debian

[Mike Hommey]

On Fri, Sep 22, 2006 at 01:12:02PM +0200, Reinhard Tartler <[EMAIL PROTECTED]> 
wrote:
> "Andrew Donnellan" <[EMAIL PROTECTED]> writes:
> 
> > It would be great if upstream would actually care about legal issues,
> > licenses and patents in particular.
> 
> Upstream does care for legal issues, and patents in particular. Check
> the mplayer development mailing list archive for the last months.
> 
> > This is pretty much the only thing stopping Debian from distributing
> > it - it may actually be illegal [...]
> 
> The problematic parts regarding patents are mostly in ffmpeg, which is
> already in debian for some time. There seem to be no problem for debian
> redistributing ffmpeg.

Note that debian's ffmpeg doesn't include encoding support for aac or
mp3...

Mike


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

Starting daemons after install not always what the user wants, but what/how to do ?

[Mike Hommey]

Some programs may be used as system daemons, but can also be used by a
user for some other purpose. For example, fetchmail can be used as a
system-wide mail fetcher, but can be used and configured by a user to
fetch his own mail, through his own setting.

Now, let's say someone creates some gnome-fetchmail program that would
take care of the configuration and the daemon starting/killing in sync
with gnome-session. This gnome-fetchmail package would indeed depend on
the fetchmail package.

IIRC, fetchmail asks the user if he wants to run fetchmail as a system
daemon when the fetchmail package is installed. Now, if the user wants
gnome-fetchmail, he will be asked that question, while actually, he
doesn't care at all. He just wants gnome-fetchmail, doesn't need
fetchmail as a system daemon, but doesn't necessarily have a clue what
he is supposed to choose for use with gnome-fetchmail.

If the fetchmail install script didn't ask the user, the maintainer
would have the choice between enabling it by default, or not enabling
it. For fetchmail the choice would probably be to not enable it, but for
some other services, probably to enable it.

And the problem is actually happening, it's not hypothetical.

There is gnome-user-share, that uses apache2 to set up a web dav share
on some random high port and make it available as a zeroconf service
through avahi. The package depends on apache2. Thus, when installing
gnome-user-share, while the user only wants to have the ability to share
his own files through a gnome interface, he also gets a full http server
running on port 80 of his computer, which he didn't really intend.

Expecting the user to disable apache by himself is not a solution.
Desktop users are not all that clueful.

I could have filed a bug to apache2, but it is more of a general issue
that needs a general solution, i think. A similar situation may already
exist with some other packages, actually.

Now, the big question is, what do you, fellow DDs, think would be a
solution for that problem of programs depending on other programs rather
than the service they provide.

Mike


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

Re: Starting daemons after install not always what the user wants, but what/how to do ?

[Mike Hommey]

On Mon, Sep 25, 2006 at 07:03:03PM +, Sam Morris <[EMAIL PROTECTED]> wrote:
> IMO, packages where there is a need for this functionality should be
> split as above. For example, fetchmail-daemon (containing the init script)
> which depends on fetchmail; spamassassin-spamd depending on spamassassin;
> bittorrent-tracker depending on bittorrent; and so on.

The problem with that kind of approach is that it adds packages for
basically one file, and that it doesn't necessarily provide a clean
upgrade path.

I'm beginning to think about some less intrusive solution, but I need to
word it correctly, so I'll come back with that later ;)

Mike


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