completeness of the upg tests (was: test if primary group, with only implicit membership of the user?)

[C. Gatzemeier]

Thank you Harald for scrutinizing.

Am Fri, 28 May 2010 14:50:27 +0200
schrieb Harald Braumann:

> On Fri, May 28, 2010 at 11:30:25AM +0200, C. Gatzemeier wrote:
> > I'm not sure yet, if I do properly understand the point when/why
> > relaxing conditionally is a bad idea. To me, setting *fixed* umasks
> > with group permissions equaling user permissions seems worse,
> > especially because not all users of a system need to be set up with
> > UPGs.
> 
> Why would you create such a mixed system? I don't see a usecase for
> that. If the system is UPG it should be UPG for everyone.

Ideally yes. However we have to consider that non-upg users can be
preexisting (system users even) or get imported somehow. But more
importantly people can get into this situation simply by changing 
the adduser/useradd's UPG setting after some users have been created.

> if users are managed externally, then nothing is
> guaranteed. All the assumptions about name or id equalities are
> nothing more than that: assumption. 
> 
> Therefore this autodetection will fail for all systems that don't
> conform to pam-umask's idea about user and group set-up.

If that externel system means to have UPGs, but does not support
propper ID allignment (like debian, at least in the last releases), one
will have to fix it or set a fixed umask, yes.

Same can be true in cases where a custom site-wide UPG user database is
used. In this case, exactly as you wrote, manually setting a
default umask is an option, if the IDs are not alligned or the user is
explicitly added to his primary group.

> And in those
> cases where it fails, I'd expect it to fail only for specific cases
> that might go unnoticed for a long time and might be hard to analyse.

It's probably better if these are cases where the umask hasn't been
relaxed, than cases where a fixed 002 umask is to permissive. This is a
case for the 022 default with "usergroups" relaxation.
Then if one has UPGs, but notices the umask is not 002 for some
users, one checks login.defs and is informed about the checks and given
a way to set a fixed umask.

However in case the external System properly supports alligned IDs (RH,
etc.) I currently don't see where any rare cases of misbehaviour in
either way should come from. The tests should work equally well even
with "mixed usersgroups". Just like on the external system itself.

If the external user database is non-UPG, this is the case where the
tests prove most useful and provide security over setting a system wide
002 umask as a default. (Additionally it is a case where the admin can
choose to turn umask relaxation off for peace of mind.)

To shield against any cases of username==groupname (say a "vip" user
and group, or any other case of matching initials) where only
coincidently UID==GUID match, I asked to check if "vip" is the primary
group of the "vip" user and "vip" user is not an explicit member of the
"vip" group.

I believe this completes the checks (see below), while it supports user
private groups that consist of multiple members. An example can be
family members that can be fully trusted and one wants to give access to
almost everything in $HOME (which should not be a sgid directory), or
abstract sub-users (used by programs) like "accounting" which data is
accessable by members of the accounting department.

> So anyone with some conscience for security will immediately disable
> this source of indeterminism and set the umask to a fixed value. I
> know I will.

That is OK, by rather setting a system wide fixed 002 umask you can be
sure users authenticating against an external system will get a umask
that can be too permissive. It may still make sense, as you have more
knowledge/control about the local environment than the debian system.

 
> So one thing is the change of the default value.

Debian delivers a UPG scheme, and to deliver it functional umask
002 is required. But setting 002 as a _global_default_ is too
much. That's why the default umask stayed 022 when UPGs where
introduced in distros, and is only relaxed conditionally.

> I'd say keep the
> default at the most secure value. But the world won't end if it is
> changed.

Supporting the UPG features with a system wide umask would IMHO be a bad
idea. Even if the admin may allways think of changing it, a fixed
umask won't cut it for "mixed systems" where some (system) users do not
have UPGs.

> But the other thing
> is this auto detection that is only based on wishful thinking and just
> adds complexity and indeterminism. I'd really rather Debian wouldn't
> do this.

Then we just see things differently here, I would consider it wishful
thinking to rely on admins to be able to manually set the correct
umask for all individual users in all cases, and consider the rather
simple alignment and testing rules to be fully deterministic. What's
missing is just a test that completes set of tests.

Testing for an empty primary group will however reduce the UPG usage
scheme to not support shared $HO

Re: test if primary group, with only implicit membership of the user?

[Petter Reinholdtsen]

[Harald Braumann]
> Why would you create such a mixed system? I don't see a usecase for
> that.

You should not really allow your lack of imagination to limit what
computer systems can handle. :)

Here at the University of Oslo, the user database is probably 25 years
old, and some users have private groups as their primary group while
others have shared groups.  The origin of these different types of
users are partly historic and partly because different departments and
institutes have different ways of working and corresponding different
ways of setting up users. :)

I suspect it will stay like this for 25 more years, and the computer
systems introduced into the university will just have to cope with
it. :)

Happy hacking,
-- 
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2fliq66stqy@login1.uio.no

Re: lilo removal in squeeze (or, "please test grub2")

[Stephen Powell]

On Fri, 28 May 2010 16:44:11 -0400 (EDT), Peter Samuelson wrote:
> Stephen Powell wrote:
>> It *does* recognize lilo and has special logic to patch lilo after
>> the restore so that the machine will boot.
> 
> So can this software be fooled into thinking it is dealing with lilo?
> Would it be sufficient to rename /boot/extlinux/extlinux.sys to
> /boot/maps or something?

I wasn't going to post to this thread on debian-devel anymore, since
it is evident that they really don't want to hear about it.  But for
the sake of answering a specific question I will respond.

I'm afraid that won't work.  In the first place, renaming
/boot/extlinux/extlinux.sys to something else would interfere with
the correct operation of extlinux.  Second, this is the second stage
loader for extlinux.  It does not use a map file, as lilo does.
Third, the boot sector for extlinux has a different signature
than the lilo boot sector.  And there are probably more reasons
as well.

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/254055006.148047.1275142053121.javamail.r...@md01.wow.synacor.com

Re: RFH: bashisms in configure script

[Vincent Lefevre]

On 2010-05-26 00:18:23 +0200, David Weinehall wrote:
> You're getting things the wrong way around.  The version of dash that
> will be put in experimental will be the correct one, the one in unstable
> will be the crippled one.  The reason things fails isn't because of
> dash, but because of sloppy programming on behalf of people that still
> believe that bash is the say all and end all when it comes to shell
> scripts.

The problem is not programmers, but the system. It is well-known that
programmers make mistakes (FYI, == also comes from C/csh so that it is
easy to be wrong), and testing allows one to discover such mistakes.
But for that, one needs a POSIX-compliant /bin/sh with no extensions.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100529123206.ga15...@prunille.vinc17.org

Re: Let's write a system admin friendly mail server packaging system

[Thomas Goirand]

Mario 'BitKoenig' Holbe wrote:
> Thomas Goirand  wrote:
>> Mario 'BitKoenig' Holbe wrote:
>>> So far this is independent of third packages which is IMHO fine and
>>> desirable. So far, this could be solved by a postfix-conf.d-snippet
>>> shipped with the amavis package.
>> Quite not. You also need to configure the incoming and outgoing ports of
>> amavis the correct way.
> 
> Which of course will also be done by the amavis package itself. Still,
> no dependency on third packages so far.

I think you quite don't get it. Here's 3 configuration:

- postfix with dkimproxy
- postfix with amavis
- postfix with dkimproxy + amavis

In these 3 cases, you have different configuration for the ports for
both amavis, and the others.

>>> * postfix ships to amavis
>>> * amavis ships back to postfix
>>> * postfix ships to dkimproxy
>>> * dkimproxy ships back to postfix
>> No, it's not any cleaner, and it's slower. As I wrote previously, we
> 
> Cleaner from a dependency-perspective. Why isn't it?

Cleaner for using it, of course not for the packaging. There's no reason
why you should load postfix more, and have the message go 3 times by it,
if it can go there only twice.

> This way you are able to configure the whole integration within one
> package (i.e. amavis ships the amavis-postfix integration, dkimproxy
> ships the dkimproxy-postfix integration, etc. pp), you can just avoid
> any complex chaining-magic.
> 
> And slower? What are we talking about? Whole two percent?

Well, both you and me are doing wild guesses here! We wouldn't be able
to tell unless we bench it. But you must be right that the overhead
wouldn't be so big, considering how much CPU amavis with spamassassin
and clamav is taking.

>> Are you trying to say that we shall ship a not performing configuration
>> by default, because big ISP are capable of reconfiguring? If you are,
> 
> I'm trying to say that I would prefer a straight, clean dependency-
> minimizing approach over one that does and/or requires complex magic.
> And I'm aware that clean approaches are usually somewhat less performant
> than optimized setups, which, in turn, tend to be more complex.
> 
> And I think that a clean and simple approach would help more users than
> one that tries to squeeze the last cpu cycles out of your system for the
> price of being hard to understand.
> Don't get me wrong: I totally agree with you that what we have now is
> neither the one nor the other.

Cool. Then we agree! :)

Just one remark (which doesn't invalidate your point): you named few
percents of cpu cycle, but do not forget to also consider I/O here, as
postfix will also use your HDD when managing its queue. I believe that
the I/O wait is a bigger concern than any CPU load issue in this case.

>> I think we shall try to release the best distribution as we can, with
>> correct, performing values by default, and even, if possible, have a
>> default configuration that you never even need to edit, because it's
>> just right by default. We should at least have this goal in mind,
> 
> "those goals" - you named three: correctness, performance and useful
> defaults. Choose two of them :)

Here, you are proposing to trade a little bit of performance, so that we
have a correct, useful default, and with not too complex maintainer
scripts. If we don't trade too much performance, then I don't mind. When
having a server on the edge of collapsing because of the load, a bit
more or less wont mater: you need a faster server and that is it.

> I don't think it's bad to be idealistic. We just have different ideals
> probably :) Well, most likely we just weigh conflicting goals different.

In an ideal world, we wouldn't need such complex setup, as there
wouldn't be any SPAM or viruses! :)

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c012711.60...@goirand.fr

Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze

[Stephen Leake]

David Kalnischkies  writes:

> 2010/5/28 Stephen Leake :
>> Ludovic Brenta  writes:
>>
>>> Stephen Leake wrote:
 Ludovic Brenta  writes:
> The reason for all this is that when a package libX2-dev Conflicts:
>>> with
> and Replaces: a package libX1-dev, aptitude does not remove libX1-dev
> and install libX2-dev; instead, it marks libX1-dev as broken and leaves
> libX2-dev uninstalled.

 This seems like a clear bug in aptitude.
>
> The name libX1-dev suggests that it can be co-installed with libX2-dev and co
> as otherwise the version number wouldn't make much sense
> (yeah i know, in a few other cases… i said not much) - 
> automatic updates in which libX1-dev is killed for good by libX2-dev
> is absolutely not what i would expect as packages will (build-)depend
> on libX1-dev which obviously can not be satisfied by libX2-dev -- if
> it could it would be called libX1-dev also or even libX-dev and only
> the real library is called libX2 …

Yes, that is all true. It is also required by the rules of the Ada
language. Please read the Debian Ada policy [1] (in particular, section
3.2) for an explanation of this naming convention.

> This is normally done for Package renames and described in e.g.
> http://wiki.debian.org/Renaming_a_Package

That is an excellent suggestion; I'll try it.

> So i would recommend to describe more what you actually want and
> your specific problem 

That was done by Ludovic's original post in this thread.

[1] http://people.debian.org/~lbrenta/debian-ada-policy.html

-- 
-- Stephe


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/827hmmsrp6@stephe-leake.org

Re: Permission to NMU gcc-mingw32

[Ove Kaaven]

Den 23. mai 2010 15:47, skrev Ove Kaaven:

Is it okay if I go ahead and do such a NMU?


Well, since there have been no objections for a week, I guess I'll go ahead.

I had been ready for some feedback from the mingw32 maintainers like 
"we're working on an updated mingw32, just wait a bit", or "gcc-mingw32 
was a horrible idea, don't propagate it, help the real mingw32 package 
instead, here's what we need", or something along those lines. So I'll 
hope their stance is "we tolerate gcc-mingw32... for now".


Ove


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c012015.2010...@arcticnet.no

Re: Recent changes in dpkg

[Thomas Weber]

On Thu, May 27, 2010 at 07:45:30PM -0400, James Vega wrote:
> On Thu, May 27, 2010 at 10:47:47PM +0200, Thomas Weber wrote:
> > How many packages are we talking about here? Is there a way to get the
> > number of packages that have the same version in Lenny and Squeeze?
> 
> According to a quick query on UDD, there are 3169 source packages which
> have the same source version in Lenny and Squeeze.  746 when comparing
> Etch and Squeeze.

Following up on this (thanks James):

I would be grateful if someone could check the following queries (i.e.,
if they do what the comment says they do):


-- up-to-date packages with same version in lenny and squeeze
---
SELECT count(s1.source) FROM sources s1, sources s2, dehs dehs
WHERE s1.source  = s2.source
AND   s1.version = s2.version
AND   s1.release = 'lenny'
AND   s2.release = 'squeeze'
AND   s1.source  = dehs.source
AND   dehs.unstable_status = 'uptodate';

Result: 1059


-- Number of packages that didn't have any bugs ever, are uptodate and
-- not orphaned
---
SELECT count(*) FROM (
SELECT s1.source FROM sources s1, sources s2, dehs dehs
WHERE s1.source  = s2.source
AND   s1.version = s2.version
AND   s1.release = 'lenny'
AND   s2.release = 'squeeze'
AND   s1.source  = dehs.source
AND   dehs.unstable_status = 'uptodate'
) AS psources
WHERE psources.source NOT IN (SELECT bugs.source FROM bugs)
AND psources.source NOT IN (SELECT source FROM orphaned_packages)
;

Result: 634


-- Number of packages that have only closed bugs, are up-to-date and not
-- orphaned
---
SELECT count(*) FROM (
SELECT s1.source FROM sources s1, sources s2, dehs dehs
WHERE s1.source  = s2.source
AND   s1.version = s2.version
AND   s1.release = 'lenny'
AND   s2.release = 'squeeze'
AND   s1.source  = dehs.source
AND   dehs.unstable_status = 'uptodate'
) AS psources
WHERE psources.source IN (
SELECT bugs.source FROM bugs
WHERE bugs.status IN ('done', 'fixed')
)
AND psources.source NOT IN (SELECT source FROM orphaned_packages)
;

Result: 55
---



So, we are talking about 1000 packages which are up-to-date in
unstable currently. Bugs don't change that picture much. I consider this
manageable during a full cycle.

And frankly, arguing back and forth about this is an exercise in
futility: 
Is the new format worse than the old one? No. 
Does it offer advantages over the old one? Yes, maybe not for all
packages, but for some.
So, let's make life easier for the dpkg developers and convert our
packages. It's not that much of a burden (From my experience, it's far
less work than even the most trivial bug fix).

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100529121727.ga28...@atlan

Re: lilo removal in squeeze (or, "please test grub2")

[Marc Haber]

On Sun, 23 May 2010 16:26:48 +0200, Stefano Zacchiroli
 wrote:
>On Sun, May 23, 2010 at 02:08:59PM +0200, Marc Haber wrote:
>> This also means that the grub2 maintainers (both Debian and Upstream)
>> need to work on the regressions that exist in regard to moving from
>> lilo or grub "legacy" to grub2. There are too many bug reports in the
>> BTS which are completely unaddressed.
>
>Right, but also note that there's an open RFH on grub2 #248397
>(retitled/refreshed recently, despite the low bug number).

As long as there are tested-and-ready-to-apply[1] patches rotting away
in the BTS without any comments, I don't get the feeling that this
kind of help is really wanted.

Greetings
Marc

[1] at least they were at the time they were posted
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1oinnv-0004kv...@swivel.zugschlus.de

Re: Let's write a system admin friendly mail server packaging system

[Marc Haber]

On Wed, 26 May 2010 18:42:50 +0200, Michael Banck 
wrote:
>Eh, Debian can patch upstream software if it thinks it is necessary for
>inter-operation, that's the one of the major points of having a
>distribution.

This is not always liked by the upstream communities though.  For
example, the exim communities hates us for integrating exim with
debconf, and they don't even think a second whenever a Debian user
shows up on their mailing lists and direct them directly to us for
user support - even if it's a valid question that the community could
easily answer. We even take care to make our config as similiar as
possible to upstreams (we even follow changes in the _comments_ of
their example config), but to no avail.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1oinnw-0004kv...@swivel.zugschlus.de

Re: Re (2): lilo removal in squeeze (or, "please test grub2")

[Marc Haber]

On Tue, 25 May 2010 11:42:34 -0400 (EDT), Stephen Powell
 wrote:
>You're missing the point.  The main selling point to management
>is that Linux is free.  If they have to buy new backup software
>in order to accommodate Linux' backup requirements, that will
>kill it on the spot.  Whatever boot loader I use must not
>require new backup software or impose special backup requirements.

From what I guess, your backup scheme is highly hardware dependent
since lilo uses block lists in the MBR to find its later stages on
disk. So your restored system will only boot if you restore to a disk
with the exactly same geometry.

I would change the restore process to manually reinstall the boot
loader after the backup software finished with its restore job anyway,
or you might be surprised with an unbootable restored system if you
had to restore to different hardware.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1oinnw-0004kv...@swivel.zugschlus.de

Re: Recent changes in dpkg

[Marc Haber]

On Thu, 27 May 2010 21:36:17 +0200, Jean-Christophe Dubacq
 wrote:
>On 27/05/2010 21:17, Tollef Fog Heen wrote:
>> I wasn't around for the libc5 => libc6 transition, but my understanding
>> is it was larger than 20% of the archive.  I would guesstimate the
>> removal of /usr/X11R6 at being around the 20% mark (including binNMUs
>> and all).  So while they're uncommon, they're not unheard of.
>
>There is also the /usr/doc => /usr/share/doc transition.

This took four releases, iirc.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1oinnw-0004kv...@swivel.zugschlus.de

Re: The story behind UPG and umask.

[Marc Haber]

On Wed, 26 May 2010 23:43:12 +0100, Stephen Gran 
wrote:
>This one time, at band camp, Roger Leigh said:
>> How will adduser cope with group addition; does it skip UIDs until
>> it finds an unused unique UID/GID pair?
>
>That certainly is the only approach that makes sense - it has the
>benefit of simplicity, if not elegance.

I am not a very good friend of just counting. I would try to somehow
hash the user name into the UID since this will - at least on systems
with only a handful of users - enhance the chance that the same user
name will get the same UID on different systems.

I would love adduser to do that, but I can live without that.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1oinnw-0004kv...@swivel.zugschlus.de

Re: Permission to NMU gcc-mingw32

[Julien Cristau]

On Sat, May 29, 2010 at 16:09:25 +0200, Ove Kaaven wrote:

> Den 23. mai 2010 15:47, skrev Ove Kaaven:
> >Is it okay if I go ahead and do such a NMU?
> 
> Well, since there have been no objections for a week, I guess I'll go ahead.
> 
> I had been ready for some feedback from the mingw32 maintainers like
> "we're working on an updated mingw32, just wait a bit", or
> "gcc-mingw32 was a horrible idea, don't propagate it, help the real
> mingw32 package instead, here's what we need", or something along
> those lines. So I'll hope their stance is "we tolerate
> gcc-mingw32... for now".
> 
Did you actually contact ron?

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Permission to NMU gcc-mingw32

[Ove Kaaven]

Den 29. mai 2010 17:51, skrev Julien Cristau:

On Sat, May 29, 2010 at 16:09:25 +0200, Ove Kaaven wrote:


Den 23. mai 2010 15:47, skrev Ove Kaaven:

Is it okay if I go ahead and do such a NMU?


Well, since there have been no objections for a week, I guess I'll go ahead.

I had been ready for some feedback from the mingw32 maintainers like
"we're working on an updated mingw32, just wait a bit", or
"gcc-mingw32 was a horrible idea, don't propagate it, help the real
mingw32 package instead, here's what we need", or something along
those lines. So I'll hope their stance is "we tolerate
gcc-mingw32... for now".


Did you actually contact ron?


Directly? Unfortunately, no, not really. I only tried to directly notify 
the maintainer of the package I actually planned to NMU (Robert Millan). 
Hopefully anyone else with a strong opinion read debian-devel...



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c0145ac.2010...@arcticnet.no

Re: lilo removal in squeeze (or, "please test grub2")

[Andreas Barth]

* Stephen Powell (zlinux...@wowway.com) [100523 21:21]:
> On Sat, 22 May 2010 23:39:52 -0400 (EDT), William Pitcock wrote:
> > After some discussion about lilo on #debian-devel in IRC, it has pretty
> > much been determined that kernel sizes have crossed the line past where
> > lilo can reliably determine the payload size.

We're speaking about #505609 I assume?


I'm not sure this bug requires an removal of lilo (see below), however
I think this means we should strongly discourage usage of lilo.


> > (1) The release notes need to be updated to reflect that lilo is no
> > longer a bootloader option;

The release notes should be updated in case we keep lilo that we
recommend to move to another boot loader now.


> > (2) The debian-installer team needs to remove the lilo-installer udeb;

This should indeed happen - if someone activly requires lilo, then
doing it by hand should be ok-ish.



> I am not a Debian package maintainer or a Debian developer.  I am just an
> ordinary system administrator.  So I'm sure that my opinion will not count
> for much.  But I am opposed to the removal of lilo.  Both grub-legacy and
> grub-pc use sectors on the hard disk outside of the master boot record
> (cylinder 0, head 0, sector 1).  In other words they use cylinder 0, head 0,
> sector 2 and possibly subsequent sectors on cylinder 0 head 0.  This breaks
> the design of the backup software that my employer uses.  This backup software
> backs up the master boot record and all partitions; but since the extra
> sectors used by grub-legacy and grub-pc are outside the master boot record
> and are not part of any partition, they don't get backed up.  Consequently,
> if we have a hard drive failure and restore from a backup, we have an
> unbootable machine.  Lilo uses only the master boot record.  A lilo-booted
> machine can be backed up and restored with our existing backup software
> just fine.  Given these requirements, I wouldn't use grub-pc even if it
> were bug free and well documented.  (But neither is the case!)

Would it be possible to move (perhaps optionally) the extra grub sectors
into an (perhaps dummy) partition (this question is for the
grub2-people)? Would that be ok for you?


> As for the claims that kernels are too big now, I find that hard to
> believe, especially now that we have the large-memory option available.
> The standard stock Debian kernel image file that I use for Squeeze,
> vmlinuz-2.6.32-3-686, is currently 2234080 bytes.  Are you trying to tell
> me that there's no room for a 2M kernel below the start of the EBDA?
> 
> I am able to load *both* the kernel *and* the initial RAM filesystem
> below the EBDA (i.e. the large-memory option is not used) if I use
> MODULES=dep instead of MODULES=most in the initial RAM filesystem
> under Lenny.  I'll bet I can do it with Squeeze too.

This sounds like we should add an wrapper around lilo that warns that
lilo is deprecated and warns if the images are too large.



Andi


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100529184041.gk13...@mails.so.argh.org

Bug#583705: ITP: opencsg -- image-based CSG (Constructive Solid Geometry) library using OpenGL

[chrysn]

Package: wnpp
Severity: wishlist
Owner: chrysn 

* Package name: opencsg
  Version : 1.3.0
  Upstream Author : Florian Kirsch 
* URL : http://opencsg.org/
* License : GPL-2+
  Programming Lang: C++
  Description : image-based CSG (Constructive Solid Geometry) library using 
OpenGL

 OpenCSG is a library for CGS (Constructive Solid Geomet) that can combine
 geometric primitives to more complex objects, for example the difference
 between two primitives. Instead of explicitly calculating the shape of the
 resulting object, it uses OpenGL's z-buffer to render the image.

 OpenCSG implements both the Goldfeather and the SCS algorithm.

this library is required for the openscad program (itp at #583476).

as with openscad, i have a working package, but again, i'm new to
packaging libraries. the underlying software seems to be reasonably
simple from a packaging point of view (once you kick out the glew
library it wants to provide). it does not provide an installer on its
onw, so the current package has an overridden dh_auto_install which
handles that; apart from that, it's quite close to the default
dh_make/dh7 3-liner.

the current state of the packages is published on [1]. the package
builds cleanly in cowbuilder and ubuntu ppa (see [2]).

notable problems in the package are my lack of deep understanding of
shared libraries (as a result, i don't know what to do with lintian's
no-symbols-control-file), and the fact that i'll have to duplicate the
whole glew copyright file inside the opencsg copyright file.


unlike with openscad, i'm neither interested in this package itself nor
in contact with upstream. i'd maintain the package for keeping openscad
running, but am likely to orphan it if openscad drops the dependency, so
if anyone else wants to maintain this package, consider this an RFP with
patch.

[1] http://archive.amsuess.com/pool/main/o/opencsg/
[2] https://launchpad.net/~chrysn/+archive/openscad

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: Digital signature

Archive area for clamz (Amazon MP3 downloader)

[Felix Geyer]

clamz [1] has been rejected from Debian NEW [2] some time ago.
The FTP assistent that processed the package was of the
opinion that it belongs to contrib instead of main because it's
only useful to download non-free content.

The purpose of clamz is to download MP3 files after buying them
from Amazon. You can download MP3s with every browser though
and Debian even has many MP3 decoders in main.
I don't see why this is a problem.

There is another package in main that is similar in this
respect: youtube-dl.

So what is the reason that clamz can't be in main?

- Felix

[1] http://code.google.com/p/clamz/
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=545717#52


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c0167b0.50...@fobos.de

Re: Re (2): lilo removal in squeeze (or, "please test grub2")

[Stephen Powell]

On Sat, 29 May 2010 10:51:10 -0400 (EDT), Marc Haber wrote:
> On Tue, 25 May 2010 11:42:34 -0400 (EDT), Stephen Powell wrote:
>> 
>> You're missing the point.  The main selling point to management
>> is that Linux is free.  If they have to buy new backup software
>> in order to accommodate Linux' backup requirements, that will
>> kill it on the spot.  Whatever boot loader I use must not
>> require new backup software or impose special backup requirements.
> 
> From what I guess, your backup scheme is highly hardware dependent
> since lilo uses block lists in the MBR to find its later stages on
> disk.

Strictly speaking, the MBR points to the partition boot sector,
the partition boot sector points to the second stage loader,
the second stage loader points to the map file (/boot/map) and
the map file points to the kernel image blocks and the initial RAM
file system image blocks.  But yes, this is location-dependent
information.

> So your restored system will only boot if you restore to a disk
> with the exactly same geometry.

Not if the restore software understands the format of the boot loader
files and knows how to patch them.  Fortunately it does.  But only
for lilo.  And only under certain conditions.

> I would change the restore process to manually reinstall the boot
> loader after the backup software finished with its restore job anyway,
> or you might be surprised with an unbootable restored system if you
> had to restore to different hardware.

That is not an option.  When the restore completes it automatically
reboots the machine.  Besides, the restore software runs under DOS,
not under Linux.  The boot loader installation program won't run under
DOS.  If patching the boot loader files was not
successful, the machine won't boot.  Manual intervention is necessary
(i.e. boot from a rescue CD, chroot into the root file system, mount
the /boot partition, and re-run the boot loader installation program).

The only way around this problem (other than using smarter software)
is to create an image (sector by sector) backup and do an image restore.
That works with any boot loader.  But that has two major drawbacks.
(1) The technician has to remember to do it that way, and (2) it
prevents restoring individual files.  You either restore the whole
server or nothing.

As I've stated in other posts, we are aware of the deficiencies of
our backup software and are looking at alternatives.  But right now,
this is what we're stuck with.  Thanks for the suggestions, though.

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/225990742.152441.1275162416466.javamail.r...@md01.wow.synacor.com

Re: IPv4-capable XDMCP server in Debian squeeze?

[Per Lundberg]

On Sat, May 29, 2010 at 8:58 PM, Carl Johnson  wrote:

Hi Carl, and thanks for your reply!

(I'll include my full original email, since I extended the audience to
the debian-devel list as well)

> Per Lundberg  writes:
>
>> Isn't there any XDMCP-capable server available in squeeze that can
>> speak ipv4 any more?
>>
>> I read about the "net.ipv6.bindv6only" issue (in a bug report).
>> However, that setting is most assuredly set to 0 when I check with
>> sysctl -a.
>> I also forcibly disabled IPv6 support altogether (since I don't need
>> it), also by using a sysctl interface, but it still doesn't help me.
> It can't be binding to an interface that doesn't exist, so it sounds
> as though you haven't disabled it properly.  You can type
> '/sbin/ifconfig' and look for inet6 entries.  You shouldn't have any
> if IPv6 is disabled.  You can check for anything listening on IPv6
> with 'netstat -l6'.  Have you looked at the Debian wiki page at
> 'http://wiki.debian.org/DebianIPv6'?  If you have followed those
> directions for disabling, did you reboot afterwards?

Yes, the sysctl thing from the Wiki page is exactly the same method
I'm using. I just rebooted, and this is the output from netstat -l6
afterwards:

p...@terah:~$ netstat -l6
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address   Foreign Address State
tcp6   0  0 [::]:ssh[::]:*  LISTEN
tcp6   0  0 [::]:microsoft-ds   [::]:*  LISTEN
tcp6   0  0 [::]:netbios-ssn[::]:*  LISTEN
tcp6   0  0 [::]:57650  [::]:*  LISTEN
udp6   0  0 [::]:xdmcp  [::]:*

The sysctl is definitely in effect, though:

p...@terah:/etc/sysctl.d$ /sbin/sysctl -a | grep ipv6 | grep disable
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
net.ipv6.conf.eth1.disable_ipv6 = 1
net.ipv6.conf.eth2.disable_ipv6 = 1
net.ipv6.conf.eth0.disable_ipv6 = 1

...and ifconfig doesn't show any ipv6 addresses.

> I just looked at mine (kdm) and it only seems to be listening to IPv6,
> but I am pretty sure it will also connect to IPv4.  I just checked
> google and there are some similar problems listed and some suggestions
> on how to solve them.  One suggests using module aliases to prevent
> loading the IPv6 module
> (http://www.linux.com/community/blogs/disable-ipv6-on-debian-lenny-quick-howto.html).

Yeah, I read the idea about module aliases as well, but it seems
pointless since IPv6 isn't a module on my system (using the
2.6.32-3-amd64 kernel from squeeze).

It's interesting however that you say that you expect it to work with
IPv4 even though it has only bound the ipv6 socket. I guess you could
be right (depending on how the actual ipv4-to-ipv6 stuff works...). In
my case however, I can't get a working XMDCP login screen so I'm
suspecting this is the problem.

(Please, Cc any replies to my email address since I don't subscribe to
the mailing lists. Thanks)
-- 
Best regards,
Per Lundberg


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktikbzdjjfe0joda0hqxd4qfcfvibw_yhcfciw...@mail.gmail.com

Re: IPv4-capable XDMCP server in Debian squeeze?

[Julien Cristau]

On Sat, May 29, 2010 at 22:32:07 +0300, Per Lundberg wrote:

> >> Isn't there any XDMCP-capable server available in squeeze that can
> >> speak ipv4 any more?

I'm fairly sure xdmcp over ipv4 works just fine with both xdm and gdm in
squeeze, because I tested them (and made them work with the bindv6only=1
setting) a month or two ago.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Recent changes in dpkg

[James Vega]

On Sat, May 29, 2010 at 02:17:27PM +0200, Thomas Weber wrote:
> So, we are talking about 1000 packages which are up-to-date in
> unstable currently. Bugs don't change that picture much. I consider this
> manageable during a full cycle.
> 
> And frankly, arguing back and forth about this is an exercise in
> futility: 
> Is the new format worse than the old one? No. 
> Does it offer advantages over the old one? Yes, maybe not for all
> packages, but for some.
> So, let's make life easier for the dpkg developers and convert our
> packages.

There's no requirement to convert packages.  All that's being requested
is that the package be explicit about the source format.

There's no reason to perform an upload *just* to make that change.
There are currently 11.7k source packages which aren't explicitly
declaring their source format.  That's not going to change overnight and
the Dpkg developers have already stated that the deprecation of an
implied source format is a long term goal (likely Squeeze+2).

-- 
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega 


signature.asc
Description: Digital signature

Re: IPv4-capable XDMCP server in Debian squeeze?

[Julien Cristau]

On Sat, May 29, 2010 at 23:16:06 +0300, Per Lundberg wrote:

> On Sat, May 29, 2010 at 10:54 PM, Julien Cristau  wrote:
> 
> Hi Julien,
> 
> > I'm fairly sure xdmcp over ipv4 works just fine with both xdm and gdm in
> > squeeze, because I tested them (and made them work with the bindv6only=1
> > setting) a month or two ago.
> 
> OK, that's interesting... Just for the sake of it, I even tried
> enabling the bindv6only (net.ipv6.bindv6only=1) setting, to see if it
> would make any difference. Negative; it still only binds to the udp6
> socket.
> 
> p...@terah:/etc/sysctl.d$ sudo netstat -l -n -p | grep 177
> udp6   0  0 :::177  :::*
>  1632/xdm
> 
That's fine, bind() on in6addr_any lets you receive ipv4 packets when
IPV6_V6ONLY is turned off (which xdm does even if the system default is
backwards).

> Do you have any active XDM setup where you could try this yourself? As
> I hinted in my previous email, I'm not 100% sure of this, but doesn't
> the above udp6 line mean that it will *only* work from an ipv6-capable
> client...?

Sorry, I can't test right now, but no, as I said above an udp6 socket
can talk to ipv4 hosts.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze

[Ludovic Brenta]

David Kalnischkies  writes:
> No. Replaces is used to say to dpkg: It is okay that this package
> overrides files of the other package - otherwise dpkg would complain
> loudly for good reasons. It doesn't say something about the
> upgrade path.

I disagree with this particular part of your analysis.  What you say is
true of Conflicts, not of Replaces.  IMHO, Replaces really, clearly
suggests an upgrade path.  Why else would the package renaming procedure
require both Conflicts and Replaces?

I do agree with the rest of what you said.

Let me emphasize again that, for Ada, a new version of a -dev package
(i.e. libX2-dev) is *not* a complete replacement for libX1-dev,
therefore we must use neither a dummy transitional package nor a
Provides relationship.

-- 
Ludovic Brenta.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ljb279yb@ludovic-brenta.org

Re: Archive area for clamz (Amazon MP3 downloader)

[Ben Hutchings]

On Sat, 2010-05-29 at 21:14 +0200, Felix Geyer wrote:
> clamz [1] has been rejected from Debian NEW [2] some time ago.
> The FTP assistent that processed the package was of the
> opinion that it belongs to contrib instead of main because it's
> only useful to download non-free content.
> 
> The purpose of clamz is to download MP3 files after buying them
> from Amazon. You can download MP3s with every browser though
> and Debian even has many MP3 decoders in main.
> I don't see why this is a problem.
> 
> There is another package in main that is similar in this
> respect: youtube-dl.

Some material on YouTube may be under a free licence, e.g.
 (though this isn't explicitly
stated there).

> So what is the reason that clamz can't be in main?

There aren't any clearly DFSG-free tracks on the Amazon MP3 store.

This may be under CC BY-SA but it's not explicitly stated which licence
is used:


"These songs are creative commons protected; they are royalty-free
songs. So I encourage musicians to play, record, and sell your
performances of these songs, and send me mp3 files of them."

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part

Re: IPv4-capable XDMCP server in Debian squeeze?

[Per Lundberg]

On Sat, May 29, 2010 at 10:54 PM, Julien Cristau  wrote:

Hi Julien,

> I'm fairly sure xdmcp over ipv4 works just fine with both xdm and gdm in
> squeeze, because I tested them (and made them work with the bindv6only=1
> setting) a month or two ago.

OK, that's interesting... Just for the sake of it, I even tried
enabling the bindv6only (net.ipv6.bindv6only=1) setting, to see if it
would make any difference. Negative; it still only binds to the udp6
socket.

p...@terah:/etc/sysctl.d$ sudo netstat -l -n -p | grep 177
udp6   0  0 :::177  :::*
 1632/xdm

Do you have any active XDM setup where you could try this yourself? As
I hinted in my previous email, I'm not 100% sure of this, but doesn't
the above udp6 line mean that it will *only* work from an ipv6-capable
client...?
-- 
Best regards,
Per Lundberg


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktik_mqieqcabeulryw9r7josiyjxovib3ff28...@mail.gmail.com

Re: lilo removal in squeeze (or, "please test grub2")

[Stephen Powell]

On Sat, 29 May 2010 14:40:41 -0400 (EDT), Andreas Barth wrote:
> Stephen Powell wrote:
>> On Sat, 22 May 2010 23:39:52 -0400 (EDT), William Pitcock wrote:
>>> After some discussion about lilo on #debian-devel in IRC, it has pretty
>>> much been determined that kernel sizes have crossed the line past where
>>> lilo can reliably determine the payload size.
>>
>
> We're speaking about #505609 I assume?

I hope not.  Strictly speaking, 505609 is not a lilo bug.  The key is
that he was still able to boot his old kernel that had been de-installed.
That's a sure sign that lilo's map installer did not get run during the
kernel upgrade process.  It used to be that if

   do_bootloader = yes

was specified in /etc/kernel-img.conf that installing a new kernel would
cause lilo to be run.  That is no longer the case.  "update-initramfs -u ..." 
will cause lilo to be run if this option is set; but "update-initramfs -c ..."
(or mkinitramfs ...) which is what is run during installation of a new kernel,
will not.  I have created my own hook script to fix that problem on my system.
Strangely, though, "do_bootloader = yes" in /etc/kernel-img.conf still
causes zipl to be run during kernel installation on the s390 platform.
Something must have changed in the kernel maintainer script or in
update-initramfs that causes the lilo map installer to not be run anymore
under conditions that used to cause it to be run.

Look carefully at the console log.  There is no output from the map installer
until he manually runs lilo.  He apparently thinks that running lilo from
the command line simply lists the installed kernels.  No.  Running lilo
from the command line is what fixed the problem.

If there's a bug here, it's somewhere else in the kernel installation
process, not in lilo itself.  If this so-called bug in lilo is what
prompted the decision to drop lilo, then the decision was based on bad data.
lilo, at least in this case, is working as designed.  The problem is that
the lilo map installer did not get run during the kernel installation
process.  I've helped a number of people on debian-user with problems
like this, and in every case so far running lilo at the command line
fixed the problem.

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/267435255.153128.1275165812236.javamail.r...@md01.wow.synacor.com

Re: IPv4-capable XDMCP server in Debian squeeze?

[Per Lundberg]

On Sat, May 29, 2010 at 11:22 PM, Julien Cristau  wrote:
> On Sat, May 29, 2010 at 23:16:06 +0300, Per Lundberg wrote:
>> p...@terah:/etc/sysctl.d$ sudo netstat -l -n -p | grep 177
>> udp6       0      0 :::177                  :::*
>>          1632/xdm
>>
> That's fine, bind() on in6addr_any lets you receive ipv4 packets when
> IPV6_V6ONLY is turned off (which xdm does even if the system default is
> backwards).

You were right - thanks! It turned out that I needed to modify the
/etc/X11/xdm/Xaccess file to be able to give the client the right to
use the login daemon... Now, it worked better. :-)
-- 
Best regards,
Per Lundberg


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktimdsjlzwew4a8bry8flw2ezxyemadshlta0a...@mail.gmail.com

Re: Archive area for clamz (Amazon MP3 downloader)

[Ron Johnson]

On 05/29/2010 03:28 PM, Ben Hutchings wrote:

On Sat, 2010-05-29 at 21:14 +0200, Felix Geyer wrote:

clamz [1] has been rejected from Debian NEW [2] some time ago.
The FTP assistent that processed the package was of the
opinion that it belongs to contrib instead of main because it's
only useful to download non-free content.

The purpose of clamz is to download MP3 files after buying them
from Amazon. You can download MP3s with every browser though
and Debian even has many MP3 decoders in main.
I don't see why this is a problem.

There is another package in main that is similar in this
respect: youtube-dl.


Some material on YouTube may be under a free licence, e.g.
  (though this isn't explicitly
stated there).



So to get in main, an app isn't allowed to *touch* non-free data?

--
Dissent is patriotic, remember?


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c01b244.4080...@cox.net

Re: Archive area for clamz (Amazon MP3 downloader)

[Ben Hutchings]

On Sat, 2010-05-29 at 19:33 -0500, Ron Johnson wrote:
> On 05/29/2010 03:28 PM, Ben Hutchings wrote:
> > On Sat, 2010-05-29 at 21:14 +0200, Felix Geyer wrote:
> >> clamz [1] has been rejected from Debian NEW [2] some time ago.
> >> The FTP assistent that processed the package was of the
> >> opinion that it belongs to contrib instead of main because it's
> >> only useful to download non-free content.
> >>
> >> The purpose of clamz is to download MP3 files after buying them
> >> from Amazon. You can download MP3s with every browser though
> >> and Debian even has many MP3 decoders in main.
> >> I don't see why this is a problem.
> >>
> >> There is another package in main that is similar in this
> >> respect: youtube-dl.
> >
> > Some material on YouTube may be under a free licence, e.g.
> >   (though this isn't explicitly
> > stated there).
> >
> 
> So to get in main, an app isn't allowed to *touch* non-free data?

I think the policy being applied is that if a package is only useful in
conjunction with non-free data, it belongs in contrib (just as if it
depends on some non-free library).

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part

Re: Archive area for clamz (Amazon MP3 downloader)

[Paul Wise]

On Sun, May 30, 2010 at 10:47 AM, Ben Hutchings  wrote:

> I think the policy being applied is that if a package is only useful in
> conjunction with non-free data, it belongs in contrib (just as if it
> depends on some non-free library).

Should I move libwww-topica-perl to contrib?

Personally I think clamz belongs in main.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktik3rkauqeck6ecl4bb2lgeidyq5yjrsxlq3e...@mail.gmail.com

Re: Archive area for clamz (Amazon MP3 downloader)

[Kartik Mistry]

On Sun, May 30, 2010 at 8:41 AM, Paul Wise  wrote:
>> I think the policy being applied is that if a package is only useful in
>> conjunction with non-free data, it belongs in contrib (just as if it
>> depends on some non-free library).
>
> Should I move libwww-topica-perl to contrib?
> Personally I think clamz belongs in main.

I'm also agree here. clamz is not depending on any non-free library to
build or work. We have not exact defination that data/content should
be always dfsg free to use with application in main. (disclaimer: IANL
clause apply.)

-- 
 Cheers,
 Kartik Mistry
 Debian GNU/Linux Developer
 0xD1028C8D | Identica: @kartikm | IRC: kart_
 Blogs: {gu: kartikm, en: ftbfs}.wordpress.com


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktintn_zbb_-3qalebgbpb9utkj_b-qr8m_meo...@mail.gmail.com

Re: Bug#529974: RFP: rtmpdump -- download media streamed with the RTMP/RTMPE protocol

[Reinhard Tartler]

On Fr, Mai 28, 2010 at 22:49:43 (CEST), Ron Johnson wrote:

> On 05/28/2010 09:20 AM, Reinhard Tartler wrote:
>> On Fr, Mai 28, 2010 at 16:00:27 (CEST), Ron Johnson wrote:
>>
>>> On 05/28/2010 01:25 AM, Reinhard Tartler wrote:
 I'm going to package rtmpdump next week.

 On Fr, Mai 22, 2009 at 16:33:44 (CEST), Sam Morris wrote:

> * Package name: rtmpdump
> * URL : [hidden obsolete url]
> * License : GPL
> Programming Lang: C++
> Description : download media streamed with the RTMP/RTMPE protocol
>
> A small dumper for media content streamed over the RTMP/RTMPE protocol.
>>>
>>> How will this be different from the rtmpdump (currently at v2.2d-0.0) in
>>> d-m.o?
>>
>> I didn't look inside the source package nor do I intend to do so. I note
>> that it doesn't provide an librtmp-dev package, so it's useless for me.
>
> Even when you need to reinvent the wheel, it's usually useful to see how
> others built their wheels, and maybe -- just maybe -- add to their
> well-debugged wheel.

not in this case.

>>>   Some rights-restricted libraries stripped out?
>>
>> I didn't spot any restricted libraries included. What are you referring to?
>>
>
> Christian created d-m.o for useful packages that can't be the official
> Debian repositories; mainly for licensing issues.

what licensing issues do you see in rtmpdump, ffmpeg or mplayer?! they
are all (L)GPL which is perfectly DFSG compatible. Before you come up
with FUD about patents, DMCA, etc. - pretty please don't. there is
already enough FUD floating around.

> That's why, for example, mplayer and ffmpeg are in both Debian and
> d-m.o.

please do your homework. you are evading my question, probably because
you have no idea what you are talking about.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/87fx1agdpd@faui44a.informatik.uni-erlangen.de