Re: Upcoming Section changes in the archive

[Paul Wise]

On Sat, Feb 28, 2009 at 4:22 PM, Josselin Mouette  wrote:
> Le vendredi 27 février 2009 à 21:40 +0100, Joerg Jaspert a écrit :
>> Select one of cli-mono or ecma-cli and please also get me a short
>> description :)
>
> How about:
>
> cli-mono -- The Common Language Infrastructure, the Mono implementation
>            and packages containing Common Intermediate Language code
>
> Or, if it’s too long:
>
> cli-mono -- Everything about Mono and the Common Language Infrastructure

Hmm, what about other CLI implementations - DotGNU for instance?

ecma-cli -- development tools and libraries for ECMA-335, the Common
Language Infrastructure.

-- 
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

Re: Upcoming Section changes in the archive

[Stefano Zacchiroli]

On Fri, Feb 27, 2009 at 09:31:25PM +0100, Joerg Jaspert wrote:
> >> Get me a short description for it.
> > "Compiler, libraries, and tools for OCaml: a static typed ML language
> > implementation supporting functional, imperative, and object-oriented
> > programming styles".
> You have an interesting definition of short, i stopped after : for
> now. :)

Eh :-)

> (Its a different thing what packages.d.o will show later, for example,
> but for me the part before the : is more than enough)

FWIW, my source of inspiration was this page
http://packages.debian.org/stable/, where something of the length I
gave you I think can be useful for users, but I'm fine with the
uber-short version too.

Thanks!

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: Transition: krb5 to drop Kerberos IV (libkrb53 restructuring)

[Julien BLACHE]

Sam Hartman  wrote:

Hi,

> It turns out this fails impressively.  The problem is that the library
> packages depend on each other.  So, for example, libk5crypto3 is
> needed by libkrb5-3.  If I make the shlibs file for libk5crypto3 point
> to libkrb53 instead of libk5crypto3, then libkrb5-3 depends on
> libkrb53.  But libkrb53 depends on libkrb5-3 because that is the point
> of libkrb53 in the new layout.
>
> I probably could hack something that would work: use symbols files
> that point at the split library packages internally and just before
> the debs are constructed run a sed script on symbols and shlibs.

debian/shlibs.local should help for that.

JB.

-- 
 Julien BLACHE   |  Debian, because code matters more 
 Debian & GNU/Linux Developer|   
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


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

Re: handling group membership in and outside d-i

[Christian Perrier]

Quoting Jon Dowland (jon+debian-de...@alcopop.org):

> I did several subsequent installs and my user never ended
> up in powerdev (nor netdev for that matter). It's my belief
> (yet to check d-i code to confirm) that the user gets added
> to powerdev if you select the desktop task: for each of my

Not really. It *should* be added to that group.

The package responsible for this in D-I is "user-setup"
(svn+ssh://svn.debian.org/svn/d-i/trunk/packages/user-setup)

The first user is created with the "user-setup-apply" script:

if [ -x $ROOT/usr/sbin/adduser ]; then
$log $chroot $ROOT adduser --disabled-password --gecos "$RET" 
$UIDOPT "$USER" >/dev/null || true
else
$log $chroot $ROOT useradd -c "$RET" -m "$USER" $UIDOPT 
>/dev/null || true
fi

# Clear the user password from the database.
db_set passwd/user-password-crypted ''
db_set passwd/user-password ''
db_set passwd/user-password-again ''
setpassword "$USER" "$USER_PW" "$USER_PW_CRYPTED"

if [ "$HOME_EXISTED" ]; then
# The user's home directory already existed before we called
# adduser. This often means that a mount point under
# /home/$USER was selected in (and thus created by) partman,
# and the home directory may have ended up owned by root.
$log $chroot $ROOT chown "$USER:$USER" "/home/$USER" >/dev/null 
|| true
fi

if [ -n "$USER" ]; then
db_get passwd/user-default-groups
for group in $RET; do
$log $chroot $ROOT adduser "$USER" $group >/dev/null 
2>&1 || true
done
fi



passwd/user-default-groups is a debcof setting that's preseedable and
for which the default is:

# Allow preseeding the groups to which the first created user is added
Template: passwd/user-default-groups
Type: string
Default: audio cdrom dialout floppy video plugdev netdev powerdev
Description: for internal use only


In shortthe first created user *should* be in powerdev. If it is
notthen there's a bug in user-setup (or somewhere else...).


(CC'ing Colin Watson who's well aware about that part of the code,
IIRC)




signature.asc
Description: Digital signature

Re: CC Attribution ShareALike (CC-by-sa) 3.0

[Cyril Brulebois]

Luca Capello  (28/02/2009):
> This does not match everything, since some packages can list the full
> license name only, e.g. Hunchentoot: […]

Never said it would. The idea was just to point to an obvious example
showing ftpmasters' acceptance of such a package.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Upcoming Section changes in the archive

[Enrico Zini]

On Fri, Feb 27, 2009 at 10:03:55PM -0800, Steve Langasek wrote:

> There are tools that understand the special meaning of the 'oldlibs' section
> and treat it specially; at least deborphan comes to mind, there may be
> others.  I don't see the necessity for such a section rename, but if it
> happens I think it needs to be announced in advance and coordinated.

Indeed.  It shouldn't be anything harder than adding 'deprecated'
(non-library, deprecated software) to complement oldlibs, ask tools to
treat them equally, and when we're satisfied that they do, just get rid
of oldlibs.


Ciao,

Enrico

-- 
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini 


signature.asc
Description: Digital signature

Re: Proposed release goal: fix debian/rules build-arch

[Goswin von Brederlow]

Kari Pahula  writes:

> On Mon, Feb 16, 2009 at 11:21:42AM -0800, Russ Allbery wrote:
>> Such a requirement unfortunately still won't mean that Lintian can use
>> that option to do a check of debian/rules.  As long as make is willing to
>> run such code, we can't just rely on a Policy statement saying that you're
>> not supposed to do that.  It is, among other things, a security problem.
>
> That's a good point, but not running debian/rules means that you'd be
> making it a requirement to write debian/rules files in a stylised way,
> to make it greppable.  Conventions are one thing, that'd be another.
> That'd have a human cost too.  But this is somewhat coincidental to
> this.  Coming up with a test, even an imperfect one, could help push
> changes forwards.
>
>> I have to admit that I'm tempted by this approach, mostly because it's not
>> clear to me that the build-arch vs. build-indep separation actually gains
>> us anything that useful.  The point, so far as I can tell, is to save
>> buildd time by not building the architecture-independent packages.  How
>> much time would we actually be saving?  Is it worth putting a lot of human
>
> Ask buildd admins.  They could start downloading and installing B-D-I
> along with B-D today.  Deprecating B-D-I and -arch and -indep would be
> a small step after that.

No, buildds do not install B-D-I contrary to what policy says they
must. Which is part of the problem the proposal wants to fix.

It also isn't so much the building itself, most arch-indep stuff
builds pretty quick. The bigger saving is not having to download,
unpack, configure and remove all the B-D-I packages. Installing for
example latex and updating the font cache takes forever. And you have
to do that for every single package with tex docs again and again and
again.

>> effort into making that situation possible?  Generally CPU cycles are far,
>> far cheaper than human cycles.
>
> Another thing that B-D-I is good for: breaking dependency cycles.  An
> example from the upcoming version of ghc6: ghc6 uses haddock to build
> API docs.  Haddock needs to be built with the same version of ghc6 it
> generates docs for.  Putting haddock in ghc6's B-D-I avoids that
> cycle.

Any such cycle would result in all its packages being stuck in
dep-wait forever if buildds would follow the current policy and
install B-D-I.

MfG
Goswin


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

Re: Transition: krb5 to drop Kerberos IV (libkrb53 restructuring)

[Raphael Hertzog]

On Sat, 28 Feb 2009, Julien BLACHE wrote:
> Sam Hartman  wrote:
> > I probably could hack something that would work: use symbols files
> > that point at the split library packages internally and just before
> > the debs are constructed run a sed script on symbols and shlibs.
> 
> debian/shlibs.local should help for that.

Except symbols files have priority over shlibs and there's no
symbols.local.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


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

Re: Proposed release goal: fix debian/rules build-arch

[Goswin von Brederlow]

Charles Plessy  writes:

> Le Tue, Feb 17, 2009 at 07:51:14PM +0100, Cyril Brulebois a écrit :
>> 
>> Does “build reproducibility” mean something to you?
>
> Hi Cyril,
>
> Build reproduciblitity means to me that two instances package built in the 
> same
> environment should be reasonably identical (things like timestamps or random
> numbers will never be reproducible).
>
> Interestingly, the Debian packages are built in an environment where
> reproducibility is only transient as Sid is constantly updated. This is even a
> feature in the case of binNMUs.

The packageversions used are listed in the buildd log file and thanks
to snapshots you can recreate and identical build environment and
reproduce the build perfectly (timestamps and random numbers excepted).

> I do not think that anybody proposes a Build-Recommend field that can result 
> in
> binary differences in the context of the Debian buildd network. However, since
> I agree with the persons who question the usefulness of distinguishing
> Build-Indep dependancies, because dropping this distinction would make my work
> easier and therefore more robust, I try to figure out a possible alternative.

If any buildd ever installs any build-recommends then the builds
become random. Builds on different architectures or times will use
different sets of packages and result in different features being
availabale. You can never have anything optional in the build process
without introducing random variations.

> For the purpose of skipping documentation building and test making, be it
> locally or remotely, Build-Recommends can be a useful alternative to
> Build-Depends-Indep. In particular, the use of Build-Depends-Indep to emulate 
> a
> "nodoc" option is only possible if the documentation is separated from the 
> main
> package in an Arch:all package. For some packages, for instance altree, it
> would mean to make a -doc package with a single PDF file in, for the sake of
> removing TeX and LaTeX from the build-dependancies.

We already have the perfectly names Build-Depends-Indep (things needed
to build indep stuff) field for that. You are proposing to create not
only a method to properly utilize that information but on top of that
rename the field to a totaly unsuitable name? How is that ever going
to help?

The Build-Depends-Indep are not recommended, they are REQUIRED when
building the indep stuff.

> I hope that this also anwers to Steve.
>
> Have a nice day,

MfG
Goswin


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

Re: Build-indep as a way to not build doc.

[Goswin von Brederlow]

Steve Langasek  writes:

> On Tue, Feb 17, 2009 at 02:39:59PM +0900, Charles Plessy wrote:
>
>> > If we can ever settle on a suitable implementation, I would expect the
>> > savings of both human and CPU cycles to be sizeable, and worth the effort.
>
>> If the problem is limited to local building of packages without their
>> documentation, maybe we can consider push forward the DEB_BUILD_OPTION 
>> "nodoc".
>
> It doesn't solve the problem that anything needed for the build target has
> to be listed in Build-Depends instead of Build-Depends-Indep, so these
> packages need to be downloaded/installed unless you start hand-hacking
> around this in the package or in the build tools.[1]  But then again,
> there's no metadata to tell you which build-dependencies you can ignore when
> you're not building docs, so you get to do this by trial and error, which
> rather neutralizes the intended time-saving benefits.
>
> Whereas Build-Depends-Indep was always intended to be used for precisely
> this, and only the "build-arch" detection problem prevents it being used
> this way.

Plus nodoc does not mean no docs are build ever. For example nodoc can
turn of the extensive html, pdf and postscript doc generation from
latex but leave the manpages intact in a package. The docs would
shrink noticably to a reasonable size without disapearing completly.

MfG
Goswin


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

Re: Transition: krb5 to drop Kerberos IV (libkrb53 restructuring)

[Julien BLACHE]

Raphael Hertzog  wrote:

Hi,

>> debian/shlibs.local should help for that.
>
> Except symbols files have priority over shlibs and there's no
> symbols.local.

I sense a lack of flexibility in this symbols file feature, hmm.

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer -  
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


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

Re: Transition: krb5 to drop Kerberos IV (libkrb53 restructuring)

[Raphael Hertzog]

On Sat, 28 Feb 2009, Julien BLACHE wrote:
> Raphael Hertzog  wrote:
> 
> Hi,
> 
> >> debian/shlibs.local should help for that.
> >
> > Except symbols files have priority over shlibs and there's no
> > symbols.local.
> 
> I sense a lack of flexibility in this symbols file feature, hmm.

shlibs.local was initially a poor solution for a less than ideal
dpkg-shlibdeps that couldn't cope with shlibs just produced by the
packages being built.

You can certainly obtain a similar result nowadays by putting the
dependency that you want in debian/control directly and by using
the -x option of dpkg-shlibdeps to strip the dependency that you did not
want.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


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

Re: xcdroast does no longer work with wodim: Who to blame?

[Goswin von Brederlow]

Brett Parker  writes:

> On 26 Feb 15:47, Joerg Schilling wrote:
>> It seems that you are spreding FUD. Everybody who is interested in working
>> CD/DVD creating uses the original software. There are nearly 100 Bug Reports 
>> against the fork in the bug tracking systems from Debian, Ubuntu and Redhat, 
>> none of the reports applies to the original software.
>
> Interesting - so, in your (somewhat naive) opinion - the *only* cd
> burning software worth mentioning is your very own pet project... weird
> that you would be so biased on that isn't it?

No. He is saying that all the many Debian, Ubuntu and RedHat users
that use wodim and find and report bugs are not interested in creating
working CD/DVD. We obvisously only burn CD/DVD to be used as coasters
or they would be using the original software.

I've just added a set of Debian Lenny amd64 and i386 DVDs to my
coaster collection.

> Does this mean that you're also blissfully unaware of the cdskin and
> libburn projects? Apparently not everyone that is interesting in working
> CD/DVD creation wants to use your software - apparently not everyone in
> the world agrees with your view point. Now, kindly drop the FUD
> spreading that your software is the only working software in the world
> (there are plenty, for example, of free CD/DVD creation tools for the
> Windows operating system, I suppose you'll claim all of those are using
> your code? Yeah. Right.).
>
> I'm very interested in *working* CD/DVD creation, and I've been very
> happy with cdrkit - if you're telling me that the CDs/DVDs that I have
> created (and used) with wodim don't work, then I'm *amazed*!

They don't work. You didn't use them successfully. You didn't even
burn them as wodim is totaly broken. He told me the same about the
about 1000 dvds I've burned under Debian.

These are not the droids you are looking for. *hand wave*

MfG
Goswin

PS: If I burn a Windows CD with wodim do I violate the copyright?
After all Schilli assured me it won't work so I can't be pirating,
right?


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

Re: xcdroast does no longer work with wodim: Who to blame?

[Goswin von Brederlow]

Reinhard Tartler  writes:

> Kalle Kivimaa  writes:
>
>> If you feel that the SFLC's opinion is wrong, you are of course free
>> to provide us with competent legal advice countering SFLC's opinion.
>
> opinions can only be proven right or wrong in court. It seems that Sun's
> opinion is that the combination doesn't impose redistribution problems,
> whereas SFLC's opinion differs. Debian's arguments pretty much match
> SFLC's.
>
> The main problem here is that Joerg seems to be more interested in
> having proved that opinion wrong than in actually getting his software
> packaged and distributed in Linux distributions.

No. He is not interested in proving it one way or the other or he
would go to court. He just wan't to write about it.

MfG
Goswin


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

Re: Is the FHS dead ?

[Josh Hurst]

On 2/24/09, Theodore Tso  wrote:
> On Tue, Feb 24, 2009 at 08:20:31AM -0600, Gunnar Wolf wrote:
>  >
>  > Interesting. And yes, illustrative of the historically (and, should I
>  > add, ridiculous? No, I'd better not ;-) ) rivality between Linux and
>  > the *BSDs, big egos included.
>
>
> Well, the last time we tried to make reasonable accomodations for
>  *BSD's, some of the biggest biggest whiners^H^H^H^H^H^H^H complaints
>  came from Debian.  In fact, some later complaints from Debianites
>  about the lack of /usr/libexec is largely the fault of Ian Jackson,
>  who ***strenuously*** opposed /usr/libexec on the mail thread which I
>  quoted.  In fact, as I recall, he threatened to rally all of Debian
>  NOT to support the FSSTND/FHS if we didn't drop /usr/libexec from the
>  draft spec.   Ah, history.
>
>  The painful fact of the matter is that anytime a draft like the FHS
>  forces any distribution or OS to change, there will be opposition.  In
>  some cases it will be principled and constructive.  In other cases, it
>  will question the spec writers' technical judgement, ethics, and even
>  their paternity.
>
>
>  > However, Linux's position WRT the commercial Unixes has radically
>  > shifted in the last decade. Linux is no longer considered a toy, and
>  > is taken seriously into account. So, even with the big inertia that
>  > might hamper more than one initiative, perhaps the FHS could be pushed
>  > in collaboration with their respective companies? At least, I'd be
>  > surprised if -say- the Solaris or HPUX people weren't open to
>  > discussion leading to better interoperability.
>
>
> Last I heard, HPUX is on maintenance life-support, and they don't have
>  enough engineers to make sure their userspace is uptodate.
>
>  And as far as Solaris is concerned, they currently have a project to
>  update to a 16-year-old shell (ksh93) in their distribution.

FYI the latest version of ksh93 is from Feb 2009.
ksh93 was picked by Sun as new system shell in Solaris with a
competition between bash 3, bash 4, dash, ksh93, mksh, pdksh and zsh.
ksh93 is between 2 and 68 times faster than all other shells, conforms
to posix without the extra options such as the POSIXLY_CORRECT junk
and has a stable programming interface since 1993 (hence the name).

Josh


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

Az első fórum alapú közösség!

[FreeForum]

Szia!

Szeretnénk neked bemutatni Magyarország első fórum alapú közösségét!

Csinálj nálunk magadnak saját fórumot!

Amit adunk: 

* A fórumodhoz jár egy általad választott aldomain 
* A fórumodon létrehozott témákért és hozzászólásokért illetve regisztrált 
felhasználókért nem kell aggódj hiszen korlátlan számú hozzászólás és téma 
hozható létre, és korlátlan számú regisztráció lehetséges. 
* Biztosítunk egy webes felületet a fórumod "átalakításához". 
* A fórumod gyors beindítását a közös rendszer segíti, ugyanis ha valaki 
regisztrál bármelyik fórumunkra, egybol regisztrált tag lesz minden fórumon. Ez 
egy olyan kényelmet nyújt a felhasználóknak, amit eddig más oldalakon nem 
igazán kaphattak meg. 


Egyenlore ennyi, a további információk megtekinthetok az oldalon. 
Az oldal elérési címe: http://freeforum.try.hu  

Figyelem! Az oldal egyenlore még BETA verzióban van, azaz még a kinézet és a 
rendszer is fog változni heteken belül, illetve sok új hasznos funkcióval lesz 
ellátva a közeljövoben! 

Néhány fórum, amit már most ajánlunk (tekintsd meg a weboldalon):

iLoad
Crazy-Warez  

Reméljük végre neked is lesz egy saját fórumod amin jól érzed magad és a TE 
ízlésed szerint alakítasz ki! 

Üdvözlettel: 
Anonymus

Ui.: Elnézésedet kérjük, ha a levéllel megzavartuk nyugalmadat, nem állt 
szándékunkban! 

  

Re: Transition: krb5 to drop Kerberos IV (libkrb53 restructuring)

[Sam Hartman]

> "Julien" == Julien BLACHE  writes:

Julien> Sam Hartman  wrote: Hi,

>> It turns out this fails impressively.  The problem is that the
>> library packages depend on each other.  So, for example,
>> libk5crypto3 is needed by libkrb5-3.  If I make the shlibs file
>> for libk5crypto3 point to libkrb53 instead of libk5crypto3,
>> then libkrb5-3 depends on libkrb53.  But libkrb53 depends on
>> libkrb5-3 because that is the point of libkrb53 in the new
>> layout.
>> 
>> I probably could hack something that would work: use symbols
>> files that point at the split library packages internally and
>> just before the debs are constructed run a sed script on
>> symbols and shlibs.

Julien> debian/shlibs.local should help for that.

There does not seem to be a symbols file override.  The package now
uses symbols files not shlibs files.  (Well, obvious/ly shlibs files
are generated for old dpkg-shlibdeps)


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

Re: xcdroast does no longer work with wodim: Who to blame?

[Arthur de Jong]

On Sat, 2009-02-28 at 12:43 +1100, Russell Coker wrote:
> http://en.wikipedia.org/wiki/Joerg_Schilling
> 
> I notice that Joerg's Wikipedia page is rather bare.
> 
> Instead of spending time covering all the old arguments on this list,
> perhaps some people could add links (such as the ones you cited) to
> Joerg's Wikipedia page.  A Wikipedia page about Joerg that is remotely
> complete and also neutral requires a reference to these issues (the
> current page only has two paragraphs).

Have a look at the cdrtools page:
http://en.wikipedia.org/wiki/Cdrtools

The cdrkit page also has some info:
http://en.wikipedia.org/wiki/Cdrkit

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --



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

Please test krb5 from experimental--even if you don't use Kerberos

[Sam Hartman]

Folks, I'd appreciate it if  people could try and test version 
1.6.dfsg.4~beta1-8 from experimental of the krb5 package.

The biggest change is a packaging reorganization.  So, while I'm
certainly interested in Kerberos users testing the packages, I'm most
interested in people other than me confirming that they don't break
your system.

This really works best from an unstable system.  Make sure
experimental is in your apt sources.
(Note these are only built for i386 now; I'll upload an amd64 build shortly)

aptitude update
aptitude -t experimental install  libkrb53  


If that works, then test reverse depenndencies of krb5 such as ssh,
the bind9 host command, etc.

If they don't give shared library load errors, then things look good;
drop me a note.  If you notice problems, then please file bugs.


If you either want to downgrade or need to downgrade, here are downgrade 
instructions.
They are a bit tricky because of  the transition involved.

  * Downgrading from this version to a previous version can  be
difficult because of library name changes.  Please follow these
instructions:
  - Get the libkrb53 and libkadm55 debs you want to downgrade to
  -dpkg --force-depends --remove  libkrb5-3 libkrb5support0 libdes425-3
libgssapi-krb5-2 libgssrpc4 libkadm5clnt5 libkadm5srv5 libkdb5-4
libk5crypto3
  -  At this point your system has broken Kerberos libraries
  - dpkg -i libkrb53*deb libkadm55*deb (using the debs you got above)
  - aptitude -f install to fix any other packages that may be broken

(N.B. a similar version of these instructions is included in the
NEWS.debian file.  There are two types.  There should be a space
between --force-depends and --remove.  ALso it is libk5crypto3 not
libkrb5crypto3; that will be corrected in the next upload)


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

Bug#508644: mass bugfiling (against 8 packages) and/or new package default-mta

[Giacomo Catenazzi]

Steve Langasek wrote:
> On Fri, Feb 27, 2009 at 09:46:15AM +0100, Giacomo A. Catenazzi wrote:
>>> Given that m-t-a is mentioned explicitly in policy, and that "default-mta"
>>> will be a virtual package, I think this should be recorded in policy as well
>>> - though if a clear consensus emerges on debian-devel, there's no need to go
>>> through the policy process before filing bugs.
> 
>> Hmmm. I partially agree, but then we have an unnecessary exception:
>> such virtual packages must have only one "provider", or else there
>> will be problems (IIRC) on dpkg, apt or ddbuild, if such dependency
>> is declared as first dependency [1].
> 
>>From the definition of the virtual package in question, it should have only
> one provider at a time.

And this is an exception, which I want to avoid. So let try to work
around with "normal package". If we fail, I agree with the virtual package.


>> I would prefer to create a real empty package:
>> default-mta (maybe in a source package debian-defaults), which depends
>> on exim.
> 
> This unavoidably couples Debian's choice of a default MTA for users who
> install the new release, to the behavior for users who are upgrading from a
> previous release, because users who have such a 'default-mta' package
> installed will find their MTA changed on dist-upgrade.

What about an other level of indirection:
package debian-mta: Depends: exim | mta-mail-transfer-agent
I think this case will solve upgrades, and changing easily the mta
(without causing a failed dependency).

ciao
cate





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

Re: Making some tags mandatory

[Jörg Sommer]

Hi Enrico,

Enrico Zini  wrote:
>  * The proposal
>
> At the end of this mail is the list that I propose: it's 138 of them,
> but grouped as they are, they should be quite clear to grasp.  I
> consider these groups of tags (debtags calls them facets) to be mature
> and uncontroversial enough to be made official and to ask maintaners to
> take care of them.

Which tag should I choose if no tag matches? Should you provide a tag
::other for each facet?

Bye, Jörg.
-- 
Freiheit heißt, die Wahl zu haben, wessen Sklave man ist.


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

Re: Upcoming Section changes in the archive (deborphan)

[Carsten Hey]

On Sat, Feb 28, 2009 at 01:03:39PM +0100, Enrico Zini wrote:
> On Fri, Feb 27, 2009 at 10:03:55PM -0800, Steve Langasek wrote:
> > There are tools that understand the special meaning of the 'oldlibs'
> > section and treat it specially; at least deborphan comes to mind,
> > there may be others.  I don't see the necessity for such a section
> > rename,

Actually he also talks about adding deprecated non-library packages, so
this is more than just a "section rename".

> > but if it happens I think it needs to be announced in advance and
> > coordinated.

Per default deborphan assumes that libraries are in libs or oldlibs.
This is necessary to find orphaned libraries but prevent packages like
libpam* or libapache* to be displayed as orphans.  The upcoming section
changes will break this assumption and thus there will be many false
negatives (orphaned libraries that are not found anymore) until large
parts of deborphan have been adapted or rewritten.

In comparison to the other proposed changes the removal of oldlibs is
only a minor issue for deborphan.  With my deborphan upstream/maintainer
hat on:  Given that no non-library packages will be added to oldlibs,
and this change happens at the same time as the other section changes,
the removal of oldlibs is ok for me and I do not feel the need to
further coordinate this.  Additionally no non-library packages must be
added to libs or libdevel at any time, I guess nobody had such plans
anyway.

> It shouldn't be anything harder than adding 'deprecated'
> (non-library, deprecated software) to complement oldlibs,

Adding non-library packages to oldlibs would cause these to be handled
like a library by deborphan and thus possibly being falsely displayed as
orphaned libraries.  Since people tend to run aptitude purge `deborphan`
in loops [1] or use similar constructs I saw in the past this would lead
to unintended package removals.

> ask tools to treat them equally,

The two sections are not exactly equal and handling them equal would be
wrong (see above).

> and when we're satisfied that they do, just get rid of oldlibs.

No, deborphan will be adapted after all section related changes in the
archive are done.  Ad interim, conservative defaults and algorithms in
deborphan ensure that additional or missing sections do not cause false
positives.

Deborphan will support both section layouts until the next change
related to sections happens, at least unless the new section layout will
be messed up in a, from the viewpoint of deborphan, non-backwards
compatible way.


Regards
Carsten

[1] http://debaday.debian.net/2007/10/21/deborphan-find-packages-you-dont-want/


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

Bug#508644: mass bugfiling (against 8 packages) and/or new package default-mta

[Steve Langasek]

On Sat, Feb 28, 2009 at 06:32:45PM +0100, Giacomo Catenazzi wrote:
> >> Hmmm. I partially agree, but then we have an unnecessary exception:
> >> such virtual packages must have only one "provider", or else there
> >> will be problems (IIRC) on dpkg, apt or ddbuild, if such dependency
> >> is declared as first dependency [1].

> >>From the definition of the virtual package in question, it should have only
> > one provider at a time.

> And this is an exception,

No, it isn't.

> >> I would prefer to create a real empty package:
> >> default-mta (maybe in a source package debian-defaults), which depends
> >> on exim.

> > This unavoidably couples Debian's choice of a default MTA for users who
> > install the new release, to the behavior for users who are upgrading from a
> > previous release, because users who have such a 'default-mta' package
> > installed will find their MTA changed on dist-upgrade.

> What about an other level of indirection:
> package debian-mta: Depends: exim | mta-mail-transfer-agent
> I think this case will solve upgrades, and changing easily the mta
> (without causing a failed dependency).

I believe that would also work, but it seems unnecessarily complex compared
to the use of a virtual package.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org



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

Re: Proposed release goal: fix debian/rules build-arch

[Russ Allbery]

Goswin von Brederlow  writes:

> No, buildds do not install B-D-I contrary to what policy says they
> must. Which is part of the problem the proposal wants to fix.

> It also isn't so much the building itself, most arch-indep stuff builds
> pretty quick. The bigger saving is not having to download, unpack,
> configure and remove all the B-D-I packages. Installing for example
> latex and updating the font cache takes forever. And you have to do that
> for every single package with tex docs again and again and again.

For the record in the thread, since I was originally wondering if this is
worth it, you and Steve have convinced me that it is.

-- 
Russ Allbery (r...@debian.org)   


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

Re: handling group membership in and outside d-i

[Joey Hess]

> In shortthe first created user *should* be in powerdev. If it is
> notthen there's a bug in user-setup (or somewhere else...).

The powerdev group only exists if hal is installed, which is only the
case if one of the desktop tasks is installed. If the group does not
exist, the initial user will silently not be added to it.

Jon's idea of having a list of primary users, which packages could then
add to groups at install time seems like a sort of good idea. But, it
doesn't solve the problem of wanting to add a new primary user and
having to manually put them in all the groups.

user-setup would also have to be refactored to create the initial user
_before_ installing tasks. And since the initial user probably can't be
sanely created before running debootstrap, packages installed in that
step still couldn't add the user to groups.

Seems like ideally there should be:

- A way to add the set of existing primary users to a newly created group.
- A way to create a new primary user, who would automatically become a
  member of the set of primary user groups.

-- 
see shy jo


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

Re: Transition: krb5 to drop Kerberos IV (libkrb53 restructuring)

[Loïc Minier]

On Sat, Feb 28, 2009, Raphael Hertzog wrote:
> You can certainly obtain a similar result nowadays by putting the
> dependency that you want in debian/control directly and by using
> the -x option of dpkg-shlibdeps to strip the dependency that you did not
> want.

 I had a case recently where this wasn't too convenient with the ffmpeg
 package: it depends on a bunch of libs split in their own packages in
 the same source.  The goal was to have a =binary:Version dep for ffmpeg
 on these libs, and use a relaxed version for the shlibs for other
 programs (ffmpeg calls into private ABI).

 In this particular case, it was simpler to use a shlibs.local with
 stricter deps during this build, while shipping relaxed shlibs.

 You could argue we should have used a stricter version on the
 semi-private symbols in a .symbols file, but it's more maintenance to
 distinguish between the two types of symbols and it's not guaranteed to
 be true in all cases (you might need =binary:version deps even if
 you're not using more symbols than the public ones).

-- 
Loïc Minier


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

Bug#517614: ITP: blueman -- A Graphical bluetooth manager

[Christopher Schramm]

Package: wnpp
Severity: wishlist
Owner: Christopher Schramm 

* Package name: blueman
  Version : 1.02
  Upstream Author : Valmantas Palikša 
* URL : http://blueman-project.org/
* License : GPL
  Programming Lang: Python
  Description : A Graphical bluetooth manager

Blueman is designed to provide simple, yet effective means for
controlling BlueZ API and simplifying bluetooth tasks such as:
 Connecting to 3G/EDGE/GPRS via dial-up
 Connecting to/Creating bluetooth networks
 Connecting to input devices
 Connecting to audio devices
 Sending/Receiving/Browsing files via OBEX
 Pairing
..
Blueman also integrates with Network Manager 0.7, so any Dialup/Network
connections will be made available (via HAL) to Network Manager.


-- System Information:
Debian Release: 5.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)



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

Re: Making some tags mandatory

[Ben Finney]

Jörg Sommer  writes:

> Which tag should I choose if no tag matches?

If no existing tag is appropriate, then either the facet does not
apply to that package, or a new tag is required for that facet.

> Should you provide a tag ::other for each facet?

That suggests that the package is properly tagged that way; I don't
think that's true for any package. Instead, if a package needs a tag
that does not yet exist, that tag should be created.

The editing interface for debtags uses ‘foofacet::TODO’ (with the
description “Need an extra tag”) for this purpose. A package so
tagged needs a new tag in ‘foofacet’ to be created.

I don't know the mechanism by which ‘foofacet::TODO’ triggers creation
of a new tag, but the meaning is clearer at least.

-- 
 \  “Progress might have been all right once, but it's gone on too |
  `\long.” —Ogden Nash |
_o__)  |
Ben Finney


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

Re: Upcoming Section changes in the archive

[Axel Beckert]

Hi,

On Fri, Feb 27, 2009 at 10:59:27AM +, Enrico Zini wrote:
> I propose 'oldlibs' to be renamed to 'deprecated'.
> 
> That would also fit, for example, packages abandoned upstream, or
> packages that have a better alternative, but that still have users.

I would expect to have so called transitional or dummy packages which
pull in renamed packages or packages which have been replaced, in such
a section, too.

Regards, Axel
-- 
Axel Beckert - a...@deuxchevaux.org, a...@noone.org - http://noone.org/abe/


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

Re: xcdroast does no longer work with wodim: Who to blame?

[Russell Coker]

On Sun, 1 Mar 2009, Goswin von Brederlow  wrote:
> > The main problem here is that Joerg seems to be more interested in
> > having proved that opinion wrong than in actually getting his software
> > packaged and distributed in Linux distributions.
>
> No. He is not interested in proving it one way or the other or he
> would go to court. He just wan't to write about it.

http://en.wikipedia.org/wiki/Jörg_Schilling

Could you please find some references to support your claims and use them to 
update the above Wikipedia page?

-- 
russ...@coker.com.au
http://etbe.coker.com.au/  My Main Blog
http://doc.coker.com.au/   My Documents Blog


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

Re: xcdroast does no longer work with wodim: Who to blame?

[William Pitcock]

On Sat, 2009-02-28 at 17:54 +0100, Arthur de Jong wrote:
> On Sat, 2009-02-28 at 12:43 +1100, Russell Coker wrote:
> > http://en.wikipedia.org/wiki/Joerg_Schilling
> > 
> > I notice that Joerg's Wikipedia page is rather bare.
> > 
> > Instead of spending time covering all the old arguments on this list,
> > perhaps some people could add links (such as the ones you cited) to
> > Joerg's Wikipedia page.  A Wikipedia page about Joerg that is remotely
> > complete and also neutral requires a reference to these issues (the
> > current page only has two paragraphs).
> 
> Have a look at the cdrtools page:
> http://en.wikipedia.org/wiki/Cdrtools
> 
> The cdrkit page also has some info:
> http://en.wikipedia.org/wiki/Cdrkit
> 

We should take information from those pages and copyedit them into
something suitable for inclusion on Joerg's page. The best part is Joerg
will probably try to delete it, but it will be reverted due to
"vandalism".

William


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

Re: Making some tags mandatory

[Carsten Hey]

Deborphan needs a way to detect shared libraries like the ones currently
in section libs and distinguish them from packages which are technically
shared libraries but can not assumed to be orphaned when no other
package depends on them.  The obvious examples for such packages are
modules (role::module?), e.g. those used by pam, apache or roxen.
Examples for less known module (or is role::backend better in this
case?) packages include libdspam7-drv-*.

I'm not sure if there are other, non-module shared library packages that
can not be removed safely.  Someone who knows how to use tags should be
able to go through a list of packages which are not in section libs or
oldlibs and tagged role::shared-lib to find out whether additional tags
might be needed or if the remaining packages are just placed in the
wrong section.


On Fri, Feb 27, 2009 at 11:48:30AM +, Enrico Zini wrote:
>   role::shared-lib - Shared Library

This tag alone is not sufficient:

$ apt-cache show libapache2-mod-mono | grep -o role::shared-lib
role::shared-lib

$ apt-cache show libpam-runtime | grep -o role::shared-lib 
role::shared-lib


Regards
Carsten


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

changes in pam: automatic configuration of PAM modules

[Steve Langasek]

Dear developers,

I'm happy to announce that with the latest upload of pam to unstable, we at
last have an interface that allows both automatic and interactive
configuration of system authentication, using that staple of the Debian
system, debconf.

It's unfortunate that this wasn't ready to go in time for the lenny freeze,
but in the meantime the new design has been getting some exercise in Ubuntu,
so the integration into unstable should be fairly painless - sorry to
disappoint the bleeding edge masochists. :)  You can read the
pam-auth-update(8) manpage for an explanation of the tool itself.
Maintainers of PAM modules that would want to make use of this interface
should also read ,
much of which will eventually find its way into the package as developer
documentation.

As a result of the prototyping work done on this within Ubuntu, patches are
already available for several module packages (libpam-krb5, libpam-ldap,
libpam-smbpass, ecryptfs-utils, libpam-ck-connector) which I will work on
submitting to the Debian maintainers over the next week or so.  If
maintainers of other PAM module packages have questions about implementing
pam-auth-update support, I'm happy to assist - and of course if you find the
documentation lacking, suggestions for improvement are welcome.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


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

Re: xcdroast does no longer work with wodim: Who to blame?

[Russell Coker]

On Sun, 1 Mar 2009, William Pitcock  wrote:
> > Have a look at the cdrtools page:
> > http://en.wikipedia.org/wiki/Cdrtools
> >
> > The cdrkit page also has some info:
> > http://en.wikipedia.org/wiki/Cdrkit
>
> We should take information from those pages and copyedit them into
> something suitable for inclusion on Joerg's page. The best part is Joerg
> will probably try to delete it, but it will be reverted due to
> "vandalism".

There is no requirement of "we" for editing Wikipedia.  If you believe that 
something needs doing then go ahead and give it your best shot.  If you 
believe that you can't quite nail it then do the best you can and ask for 
assistance in polishing it.

As for Joerg trying to delete it, there is no evidence so far of him being a 
wiki vandal.  It should be possible to create a version of his page which 
captures all the essential facts in a neutral tone that doesn't offend him.

Speaking for myself, if you were to create a Wikipedia page about me that 
included quotes from some of my best arguments in support of a topic that 
mattered to me then I would be quite happy with that.  I don't think that I'm 
notable enough - just in case anyone is considering doing so.

-- 
russ...@coker.com.au
http://etbe.coker.com.au/  My Main Blog
http://doc.coker.com.au/   My Documents Blog


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