maybe ITP of lib DomainKeys

[Russell Coker]

http://domainkeys.sourceforge.net/license/softwarelicense1-1.html

I've packaged libdomainkeys for internal use and am considering adding a 
package that depends on it to Debian/Unstable.  Is the domainkeys license 
suitable for inclusion in Debian?

-- 
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: Introduction to multiarch: What maintainers must do

[Cyril Brulebois]

Goswin von Brederlow  (29/07/2009):
> Thoughts from the maintainer?

You may want to read #468209, which is kind of related.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Introduction to multiarch: What maintainers must do

[Cyril Brulebois]

Charles Plessy  (30/07/2009):
> I have three questions about Multi-arch:
> 
> 1) […]
> 
> 2) […]

3) Where is the third question? :)

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: maybe ITP of lib DomainKeys

[Cyril Brulebois]

Russell Coker  (30/07/2009):
> http://domainkeys.sourceforge.net/license/softwarelicense1-1.html
> 
> I've packaged libdomainkeys for internal use and am considering adding a 
> package that depends on it to Debian/Unstable.  Is the domainkeys license 
> suitable for inclusion in Debian?

Hint, try -legal@, quoting the full license text in your mail.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: maybe ITP of lib DomainKeys

[sean finney]

On Thu, Jul 30, 2009 at 05:01:12PM +1000, Russell Coker wrote:
> I've packaged libdomainkeys for internal use and am considering adding a 
> package that depends on it to Debian/Unstable.  Is the domainkeys license 
> suitable for inclusion in Debian?

seems to meet all the critera, doesn't it?  there's some wacky patent
stuff in there but it doesn't really seem to be restrictive, rather granting
additional benefits for users who stay within a particular use case of the
software.

but that's just my 0.15 SEK :)


sean


signature.asc
Description: Digital signature

Re: Automatic Debug Packages

[Stefano Zacchiroli]

On Wed, Jul 29, 2009 at 02:18:49PM +0200, Emilio Pozuelo Monfort wrote:
> I've written down the details in the wiki [2], and I'll appreciate
> it if you could give some feeback. I don't want to trash this
> completely though, so no drastic changes preferred :)

I wonder how C-specific is your proposal. In particular, I wonder if
other compilers / interpreters which might provide debugging symbols
can benefit from it. My specific case is OCaml, where we can build
libraries with debugging information even though we usually don't do
that. While I guess the archive part of the infrastructure (.ddeb
handlings) is pretty independent from .ddeb content, I'm not sure
about the helpers, but we can of course provide our own extra
helpers. Can you comment on that?

Thanks for the initiative!

-- 
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: multiarch: dependency-oriented vs package-oriented

[Eugene V. Lyubimkin]

Goswin von Brederlow wrote:
> "Eugene V. Lyubimkin"  writes:
>>> 2) Tagging package relationships instead of packages means extending
>>> the syntax of package relationsships, trusting the binary packages to
>>> get the depends right
>> You'll have to do it sooner or later. At least for already mentioned perl,
>> python and others. Or no?
> 
> Yes, but how many are there. Perl for example has 2627 reverse
> depends. How many of those are plugins?
Don't matter. If even there is literally one package, the new syntax has to be
defined. Once you add it, it doesn't matter - one package uses it or thousand
of ones.

> I did draw some graphs about all the different package relationships
> because I couldn't keep them all straight myself. Unfortunaetly I was
> traveling and my battery was dead so I did it on dead wood. I guess I
> should transefere them to bits and ask them to be included in the
> proposal.
Would be nice.

-- 
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Maintainer



signature.asc
Description: OpenPGP digital signature

Re: Introduction to multiarch: What maintainers must do

[Samuel Thibault]

Charles Plessy, le Thu 30 Jul 2009 13:13:59 +0900, a écrit :
> 1) What is the advantage of adding a new field over simply using something 
> like
>‘Arch: multi’?

Err, I believe it makes sense to mark an i386/amd64-only library as
multiarch-capable.

Samuel


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

Re: Re: Introduction to multiarch: What maintainers must do

[Hendrik Sattler]

Zitat von sthiba...@debian.org:


My first thought was "Err. Won't moving all the shared libs into a
different location kinda screw things up?" And then I looked, and found

  | ==> /etc/ld.so.conf.d/x86_64-linux-gnu.conf <==


Yes, but however pkg-config won't yet find things in
/usr/lib/x86_64-linux-gnu/pkgconfig, so take care of putting .pc files
in /usr/lib/pkgconfig.


Please don't as those files can be different on different  
architectures. Change PKG_CONFIG_PATH or PKG_CONFIG_LIBDIR instead.


pkg-config has a win32-only feature to derive the prefix variable from  
the location of the .pc file. Removing the ifdef would also enable  
this on Linux and make pkg-config multiarch-usable.
Alternative: install pkg-config as ${DEB_HOST_GNU_TYPE}-pkg-config for  
each arch (each with the correct default search path) and link the  
default arch pkg-config to it. Autotools will automatically handle it,  
cmake currently won't.


HS



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

Re: Re: Introduction to multiarch: What maintainers must do

[Samuel Thibault]

Hendrik Sattler, le Thu 30 Jul 2009 10:35:38 +0200, a écrit :
> Zitat von sthiba...@debian.org:
> 
> >>My first thought was "Err. Won't moving all the shared libs into a
> >>different location kinda screw things up?" And then I looked, and found
> >>
> >>  | ==> /etc/ld.so.conf.d/x86_64-linux-gnu.conf <==
> >
> >Yes, but however pkg-config won't yet find things in
> >/usr/lib/x86_64-linux-gnu/pkgconfig, so take care of putting .pc files
> >in /usr/lib/pkgconfig.
> 
> Please don't as those files can be different on different  
> architectures.

Yes, but for now multi-arch support for -dev packages won't be done so
it's not a problem.

> Change PKG_CONFIG_PATH or PKG_CONFIG_LIBDIR instead.

Don't ask the user to do it ;)

> pkg-config has a win32-only feature to derive the prefix variable from  
> the location of the .pc file. Removing the ifdef would also enable  
> this on Linux and make pkg-config multiarch-usable.

Yes, to get -dev packages multi-arch support such kind of thing will be
needed.

Samuel


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

Re: Introduction to multiarch: What maintainers must do

[Santiago Vila]

On Wed, 29 Jul 2009, Goswin von Brederlow wrote:

> > However, you *can* share the same .mo files on each platform, since the
> > gettext code copes with endianness issues at runtime if need be.
> 
> So we would have to define a default endianness for creating such
> files. A patch to gettext to create them allways little endian (or the
> other way) seems in order.
>
> Thoughts from the maintainer?

I have very good news :-) There is already a default for that, as
msgfmt always creates little endian .mo files by default.

In fact, lots of source packages have pre-built .mo files, which are
just copied when doing "make install".

So, as far as we don't try to change msgfmt behaviour, we will not
need to patch it at all.

As noted by Cyril, there is a small discussion about this in Bug#468209.

Thanks.


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

Re: multiarch: dependency-oriented vs package-oriented

[Goswin von Brederlow]

"Eugene V. Lyubimkin"  writes:

> Goswin von Brederlow wrote:
>> "Eugene V. Lyubimkin"  writes:
 2) Tagging package relationships instead of packages means extending
 the syntax of package relationsships, trusting the binary packages to
 get the depends right
>>> You'll have to do it sooner or later. At least for already mentioned perl,
>>> python and others. Or no?
>> 
>> Yes, but how many are there. Perl for example has 2627 reverse
>> depends. How many of those are plugins?
> Don't matter. If even there is literally one package, the new syntax has to be
> defined. Once you add it, it doesn't matter - one package uses it or thousand
> of ones.

Sure. But do you want to alter 10 plugin packages or 2627 packages?
Considering how hard it is to transition has gone into the
considerations too.

MfG
Goswin


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

Re: Introduction to multiarch: What maintainers must do

[Goswin von Brederlow]

Steve Langasek  writes:

> On Wed, Jul 29, 2009 at 07:38:22PM -0500, Peter Samuelson wrote:
>> We have mostly settled the /usr/share/locale question, and apparently
>> /usr/share/doc is a special exception anyway
>
> No, it is not.  The ubiquity of /usr/share/doc provides the *rationale* for
> multiarch handling /usr/share in a way that doesn't require splitting out
> common packages, but dpkg will not handle /usr/share/doc differently than
> any other files.

Well, the execption is for /usr/share. So locale, docs, whatever is
covered there.

MfG
Goswin


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

Re: dash pulled on stable when APT::Default-Release is used

[Philipp Kern]

On 2009-07-29, Michael S. Gilbert  wrote:
> it is a bug in the sense that stable's behavior is being unduly
> influenced by unstable's "essential packages" list.  i would suggest
> submitting a report to the bts so the problem can be tracked and
> eliminated in future releases.

That's somewhat by definition, sorry.  If you have unstable packages
activated they may be relying on essential packages from unstable to
work.  So they have to be installed.  No bug there.

Kind regards,
Philipp Kern



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

Re: Introduction to multiarch: What maintainers must do

[Goswin von Brederlow]

Charles Plessy  writes:

> Le Wed, Jul 29, 2009 at 03:57:31PM +0200, Goswin von Brederlow a écrit :
>> 
>> I got some good feedback from my previous Introduction to multiarch
>> post and some good questions. I'm singling out Manoj Srivastava here
>> because he was the most recent to ask this on irc but there where
>> others with the same or simmilar question.
>> 
>> The full multiarch proposal can be read on:
>>   https://wiki.ubuntu.com/MultiarchSpec
>
> Dear Goswin,
>
> thank you very much for your vulgarisation efforts. Multi-architecture 
> settings
> will be very useful for scientific computing, where we only want the
> applications that really need 64 bits to use this, as there can be a
> performance cost to use 64 bits in cases where 32 would be enough (which 
> means:
> spending taxpayer money to heat the atmosphere).
>
> I have three questions about Multi-arch:
>
> 1) What is the advantage of adding a new field over simply using something 
> like
>‘Arch: multi’?

Then how you you know what architecture the package actualy is?

> 2) On the Ubuntu page I read: “It is worth noting that existing package
>management tools will be unable to interpret and satisfy package 
> relationships
>of this format, even when the desired package is available. Consequently, 
> it is
>recommended to defer use of such package relationships in the archive for a
>full release cycle following the package management implementation.” 
> Does it
>mean that we need to postpone the implementation of multi-arch in perl 
> packages
>containing compiled code until Squeeze + 2, to keep our promise to support
>upgrades from Lenny?

Depending wether squeeze has support for the new syntax or not, yes,
it would mean that. Unless we can show that it will be possible to
upgarde the package management to squeeze+2 prior to updating perl and
that the new syntax will only make package uninstallable but not cause
parse errors. I don't think requiring people to upgrade dpkg/apt
before upgrading the rest of the system when skipping a release would
be too much of a burden. But it wouldn't be as nice as it could be.

One large question that should be answered first is: Do we desperately
need a multiarch perl? Are there reverse dependencies on perl where
one must be i386 and the other amd64? If it just a "would be nice"
feature then putting it off some might be better than making upgrades
more complex.

> 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: Re: Introduction to multiarch: What maintainers must do

[Gabor Gombas]

On Thu, Jul 30, 2009 at 11:04:46AM +0200, Samuel Thibault wrote:

> > >Yes, but however pkg-config won't yet find things in
> > >/usr/lib/x86_64-linux-gnu/pkgconfig, so take care of putting .pc files
> > >in /usr/lib/pkgconfig.

$ pkg-config --list-all --debug
[...]
Cannot open directory '/usr/local/lib/pkgconfig' in package search path: No 
such file or directory
Cannot open directory '/usr/local/lib/pkgconfig/x86_64-linux-gnu' in package 
search path: No such file or directory
Scanning directory '/usr/lib/pkgconfig'
[...]
Cannot open directory '/usr/lib/pkgconfig/x86_64-linux-gnu' in package search 
path: No such file or directory
[...]

So pkg-config already has some support for multi-arch, it just uses
different directories than the current proposal. That can be fixed with
either a single symlink, or by modifying the --with-pc-pass=... argument
in pkgconfig's debian/rules. Neither will allow building stuff for a
different architecture, but as you note below that's not a requirement
for now.

Later pkg-config should be extended to have an "--arch" command-line
option (or env. variable) that is substituted into the default search
path at run time rather than at build time, but that can wait.

> > Please don't as those files can be different on different  
> > architectures.
> 
> Yes, but for now multi-arch support for -dev packages won't be done so
> it's not a problem.

But if it can be fixed with a simple change to pkg-config, then why not
move the .pc files now? Esp. if that means less work for the library
package maintainers.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


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

Re: Please test eglibc 2.9-23+multiarch.1

[Sven Joachim]

On 2009-07-29 22:12 +0200, Aurelien Jarno wrote:

> On Wed, Jul 29, 2009 at 04:10:27PM +0200, Aurelien Jarno wrote:
>> In short it looks like a Pre-Depends is overkill, and that a Depends is 
>> enough. I'll upload a new version soon to experimental to fix that.
>> 
>
> eglibc version 2.9-23+multiarch.1 is now in incoming and will be on the
> mirrors soon. Please test and report problems.

It still fails in my Lenny chroot:

,
| # LANG=C apt-get dist-upgrade
| Reading package lists... Done
| Building dependency tree   
| Reading state information... Done
| Calculating upgrade... Done
| The following NEW packages will be installed:
|   libc-bin libc-dev-bin
| The following packages will be upgraded:
|   libc6 libc6-dev locales
| 3 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
| Need to get 0B/14.1MB of archives.
| After this operation, 6377kB of additional disk space will be used.
| Do you want to continue [Y/n]? y
| WARNING: The following packages cannot be authenticated!
|   libc-dev-bin libc6-dev locales libc-bin libc6
| Install these packages without verification [y/N]? y
| E: Internal Error, Could not perform immediate configuration (2) on libc-bin
`

This may be due to apt wanting to configure required packages
immediately (the right order would be to unpack everything first).
Any idea what to do now?

Sven


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

Re: multiarch: dependency-oriented vs package-oriented

[Eugene V. Lyubimkin]

Goswin von Brederlow wrote:
> "Eugene V. Lyubimkin"  writes:
> 
>> Goswin von Brederlow wrote:
>>> "Eugene V. Lyubimkin"  writes:
> 2) Tagging package relationships instead of packages means extending
> the syntax of package relationsships, trusting the binary packages to
> get the depends right
 You'll have to do it sooner or later. At least for already mentioned perl,
 python and others. Or no?
>>> Yes, but how many are there. Perl for example has 2627 reverse
>>> depends. How many of those are plugins?
>> Don't matter. If even there is literally one package, the new syntax has to 
>> be
>> defined. Once you add it, it doesn't matter - one package uses it or thousand
>> of ones.
> 
> Sure. But do you want to alter 10 plugin packages or 2627 packages?
> Considering how hard it is to transition has gone into the
> considerations too.
The best I would imagine is to alter 'Arch: any' to 'Arch: multi' (as
Charles suggested) or insert 'Multi-Arch: yes' automatically by the some
tool (dak?), as checking co-installableness can be done automatically by
simply diffing 'dpkg -c package.deb' for produced arches (one and tricky
way), or add them manually to the ~200 libraries you want to transition
in the first round - not very hard. For thousand of Perl libraries
inserting 'Depends: perl:foreign' could be inserted by ${perl:Depends}
substitute requiring binNMUs only. I am not sure for python modules or
modules for other interpreters though.

I would still want that multi-arch dependencies would be specified at
one straight place, not two.

-- 
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Maintainer



signature.asc
Description: OpenPGP digital signature

Emacs 23.1 released

[Adrian Perez]

I'd like to see this in unstable ASAP.


 Forwarded Message 
> From: Chong Yidong 
> To: emacs-de...@gnu.org
> Subject: Emacs 23.1 released
> Date: Wed, 29 Jul 2009 23:01:22 -0400
> 
> GNU Emacs 23.1 has been released.  It is available on the GNU ftp site
> at ftp.gnu.org/gnu/emacs/.  See http://www.gnu.org/order/ftp.html for a
> list of mirrors.
> 
> The MD5 check-sums for the tarballs are:
> 
>   a620d4452769d04ad8864d662f34f8dd  emacs-23.1.tar.gz
>   17f7f0ba68a0432d58fa69d05a2225be  emacs-23.1.tar.bz2
> 
> Here are some new features of Emacs 23.  See etc/NEWS for a complete
> list.
> 
>  - Improved Unicode support (the internal character representation is
>now based on UTF-8).
> 
>  - Font rendering with Fontconfig and Xft.
> 
>  - Support for using X displays and text terminals in one session,
>and for running as a daemon.
> 
>  - Shift-selection.
> 
>  - Smarter minibuffer completion.
> 
>  - Per-buffer text scaling.
> 
>  - Directory-local variables.
> 
>  - New packages for:
> * viewing PDF and postscript files (Doc view mode)
> * connecting to processes via D-Bus (dbus)
> * using the GNU Privacy Guard (EasyPG)
> * displaying line numbers in the fringe (Linum mode)
> * editing XML documents with on-the-fly validation (nXML mode)
> * editing Ruby programs (Ruby mode)
> * display-based word wrapping (Visual Line mode)
> 
> Please send bug reports to bug-gnu-em...@gnu.org.  You can use the
> function M-x report-emacs-bug to do this.  Mac OS X users should note
> that the Carbon port has been removed; see the file nextstep/README for
> information about the new Cocoa port.
> 
> Many thanks to the rest of the Emacs development team for their hard
> work; and to the numerous users who contributed suggestions and bug
> reports.  Happy hacking.
> 
> 
> ___
> GNU Announcement mailing list 
> http://lists.gnu.org/mailman/listinfo/info-gnu
-- 
Best regards, 

Adrian Perez 


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

Re: Emacs 23.1 released

[Cyril Brulebois]

Adrian Perez  (30/07/2009):
> I'd like to see this in unstable ASAP.

Get to work?

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Emacs 23.1 released

[Adrian Perez]

Sure, but emacs is a complex package, and I'm working in something else
by now, if I understood you right. If you mean you're going to work on
it that's great. I've been using emacs-snapshot for a long time by now,
I'm pretty excited about this release.

On Thu, 2009-07-30 at 15:31 +0200, Cyril Brulebois wrote:
> Adrian Perez  (30/07/2009):
> > I'd like to see this in unstable ASAP.
> 
> Get to work?
> 
> Mraw,
> KiBi.
-- 
Best regards, 

Adrian Perez 


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

Re: Emacs 23.1 released

[Kumar Appaiah]

On Thu, Jul 30, 2009 at 09:38:12AM -0400, Adrian Perez wrote:
> 
> Sure, but emacs is a complex package, and I'm working in something else
> by now, if I understood you right. If you mean you're going to work on
> it that's great. I've been using emacs-snapshot for a long time by now,
> I'm pretty excited about this release.

What Cyril meant was, that, the way your initial mail sounded a tad
authoritative ("I'd like to see this in unstable" vis-a-vis a
request). Since Debian is chiefly a volunteer driven project, you'll
probably get better results if you either wait patiently for the
maintainer, make a (more gently sounding) request do the maintainer
(directly, preferably), or do the work yourself and send it to the
maintainer. :-)

HTH.

Kumar


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

Re: Switching /bin/sh to dash without dash essential

[Frans Pop]

Steve Langasek wrote:
> On Sun, Jul 26, 2009 at 05:10:59PM +0200, Frans Pop wrote:
>> You're correct of course. If we want to go this way there should be two
>> questions: one for the system shell to use and one for the default user
>> shell, each with per-arch defaults.
> 
> Do you really think that the latter warrants a question?  Admins can set
> their own policies by wrapping adduser; derivers can set their own
> policies by modifying the adduser package.

I'm not sure. I merely wanted to explore the options. But it does seem to 
me that the ability to select the system and user shell at installation 
time could be a nice feature for advanced users.

I think that quite a few sites may want to stick with the "single shell to 
avoid the risk of incompatibilities" option that Manoj put forward. So 
selecting the system shell makes a lot of sense to me.

I'm less sure whether the option of selecting the user shell is really 
needed as well, but if you do one then supporting the other as well is 
probably not all that much more work.
 
>> From the discussion there seem to be three groups:
>> - embedded: want to have only a single, lightweight shell installed for
>>   both system and users;
>> - generic: want a fast system shell, but a more powerful shell for
>>   users; 
>> - conservative: don't want to run any risk with script
>>   incompatibilities and thus want to have the same, powerful shell for
>>   system and users. 
> 
>> It seems to me all three are valid.
> 
> Has anyone actually said in this thread that "I'm developing an embedded
> system and I want the user shell to be dash"?  dash is a terrible user
> shell, after all.

No, they have said "I'm developing an embedded system and I only want dash
installed". Whether that means the system has no users (or at least shell 
using ones) at all, or they'll use dash for the (probably limited) tasks, 
or they want to use some other shell as user shell I don't know.
But in all three cases they want the option of not installing bash as user 
shell, which could be facilitated by a question.
 
> Otherwise, yes, these are all valid cases, but I don't think that's
> really  been a point of contention here; the only contention has been:
> 
> - which configuration is the default?
> - do we need to generalize beyond dash and bash to meet these use cases?

That is indeed the discussion. My thoughts regarding D-I and debootstrap 
are IMO an extention of the first question: how flexible do we want the 
default to be.

Cheers,
FJP


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

Re: Emacs 23.1 released

[Kartik Mistry]

On Thu, Jul 30, 2009 at 7:16 PM, Kumar Appaiah wrote:
> do the work yourself and send it to the
> maintainer. :-)

File a `wishlist' bug against package with reportbug --kudos is good :)

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


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

Processed: Re: initscripts: Fix to allow falsified cpu information in /proc/cpuinfo

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 506481 general
Bug #506481 [initscripts] initscripts: Fix to allow falsified cpu information 
in /proc/cpuinfo
Bug reassigned from package 'initscripts' to 'general'.
Bug #506481 [general] initscripts: Fix to allow falsified cpu information in 
/proc/cpuinfo
Ignoring request to alter found versions of bug #506481 to the same values 
previously set
Bug #506481 [general] initscripts: Fix to allow falsified cpu information in 
/proc/cpuinfo
Ignoring request to alter fixed versions of bug #506481 to the same values 
previously set
> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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

Re: Emacs 23.1 released

[Ben Finney]

Adrian Perez  writes:

> I'd like to see this in unstable ASAP.

A message to this list isn't going to do anything to help that happen.

Rather, you should consider whether the maintainer of the Debian package
might be unaware of the new version, and if in your estimation they
might have overlooked the version, file a Debian BTS bug report of
“wishlist” severity against the package.

In this case, though, I think it's pretty likely the maintainer is
already well aware of this new version, and doesn't need reminding.

-- 
 \ “Anyone can do any amount of work provided it isn't the work he |
  `\  is supposed to be doing at the moment.” —Robert Benchley |
_o__)  |
Ben Finney


pgpWpo288jamu.pgp
Description: PGP signature

Status of new source formats project

[Raphael Hertzog]

Hello,

I updated the wiki page listing the status of this project:
http://wiki.debian.org/Projects/DebSrc3.0

During debconf I used part of my time to push this project forward.

1/ Lucas did again a rebuild of the archive to discover problems that will
appear if all packages are converted to 3.0 (quilt) format. I processed
200 failed build logs and filed some new wishlist bugs to prepare for a
global transition (and fixed a sid-only bug in dpkg-source detected thanks
to this rebuild).
http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=hert...@debian.org;tag=3.0-quilt-by-default

2/ I prepared some test source packages covering most interesting cases
to try out with various tools, I checked the most important ones (apt-get
source, sbuild) and they do cope with it. I encourage you to test all
other tools and report your success/failures here (and please file bug for
the failures).
http://people.debian.org/~hertzog/packages/debsrc3.0/

3/ I discussed with Jörg Jaspert and Mark Hymers the status of my patch
against dak. Currently they plan to merge my patch after they have
finished to update dak to use sqlalchemy, but given that this is an
intrusive change they will have to test it carefully and Jörg expected
that it will still be 2 to 3 months until they can integrate my patch. :-(

Both patches/branches are going to conflict so someone will have to handle
the merge conflict whatever the merge order is. I offered them to handle
it myself even if my patch is merged now (without conflicting with
anything since the sqlalchemy one is not yet ready/merged). The sqlalchemy
rewrite is not yet public but Mark hopes to publish it this week-end (1-2
Aug). After my upcoming vacation, and if I still can't convince ftpmasters
to merge my working branch immediately I'll create a new branch of my
patch merged with the new sqlalchemy branch so that they have a chance
to push both changes at the same time (or in the order that they want).

This dak modification is the main blocker point for this project to go
forward (and has been so for quite some time already).

4/ I discussed with Luk Claes if anything had to be done on the buildd
side. There's not much to be done there since the new sbuild is working
well with new source formats but there are still some buildd using the old
version. Those have to be updated to the new sbuild and this process has
been ongoing for quite some time already. I pinged some of the concerned
buildd maintainers and provided sample buildd logs generated by the new
sbuild with the new source formats so that they can adapt their build logs
processing scripts immediately.

5/ In all cases, I hope we will enable support of new source formats in
squeeze so that individual packages can switch to it (in particular bigger
packages that would benefit from the multi-tarball thingie). But depending
on the time left before the freeze, we might not start a global transition
to the new formats (i.e. I would not modify dpkg-source to produce newer
source formats when there's no debian/source/format).

Cheers,
-- 
Raphaël Hertzog


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

Re: RFC round 4: DEP-3: Patch Tagging Guidelines

[Emilio Pozuelo Monfort]

Raphael Hertzog wrote:
> Hello,
> 
> one more turn for this DEP, after all. Recent changes are not numerous
> but there are some.
> 
> Current version: http://dep.debian.net/deps/dep3/

Would it be possible to make Origin optional if Bug is present? I feel that when
Description and Bug are present, Origin shouldn't really be required.

Cheers,
Emilio



signature.asc
Description: OpenPGP digital signature

Re: Please test eglibc 2.9-23+multiarch.1

[Aurelien Jarno]

On Thu, Jul 30, 2009 at 02:00:18PM +0200, Sven Joachim wrote:
> On 2009-07-29 22:12 +0200, Aurelien Jarno wrote:
> 
> > On Wed, Jul 29, 2009 at 04:10:27PM +0200, Aurelien Jarno wrote:
> >> In short it looks like a Pre-Depends is overkill, and that a Depends is 
> >> enough. I'll upload a new version soon to experimental to fix that.
> >> 
> >
> > eglibc version 2.9-23+multiarch.1 is now in incoming and will be on the
> > mirrors soon. Please test and report problems.
> 
> It still fails in my Lenny chroot:
> 
> ,
> | # LANG=C apt-get dist-upgrade
> | Reading package lists... Done
> | Building dependency tree   
> | Reading state information... Done
> | Calculating upgrade... Done
> | The following NEW packages will be installed:
> |   libc-bin libc-dev-bin
> | The following packages will be upgraded:
> |   libc6 libc6-dev locales
> | 3 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
> | Need to get 0B/14.1MB of archives.
> | After this operation, 6377kB of additional disk space will be used.
> | Do you want to continue [Y/n]? y
> | WARNING: The following packages cannot be authenticated!
> |   libc-dev-bin libc6-dev locales libc-bin libc6
> | Install these packages without verification [y/N]? y
> | E: Internal Error, Could not perform immediate configuration (2) on libc-bin
> `
> 
> This may be due to apt wanting to configure required packages
> immediately (the right order would be to unpack everything first).
> Any idea what to do now?
> 

Except saying "apt sucks", I currently do not have more idea. Someone
else maybe?

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net


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

Re: RFC round 4: DEP-3: Patch Tagging Guidelines

[Raphael Hertzog]

On Thu, 30 Jul 2009, Emilio Pozuelo Monfort wrote:
> Would it be possible to make Origin optional if Bug is present? I feel that 
> when
> Description and Bug are present, Origin shouldn't really be required.

The bug entry is not the same as the patch URL.

It's true that in many cases you will find the patch in the bug log but
there are also cases where you have multiple patches in the bug log so
it's best to point the patch actually used.

Cheers,
-- 
Raphaël Hertzog


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

Re: Please test eglibc 2.9-23+multiarch.1

[Eugene V. Lyubimkin]

Aurelien Jarno wrote:
> Except saying "apt sucks", I currently do not have more idea. Someone
> else maybe?
> 
/me suggests to try cupt and hides

-- 
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Maintainer



signature.asc
Description: OpenPGP digital signature

Re: Emacs 23.1 released

[Adrian Perez]

Sorry about the tone, you misunderstood me. 
What I'm actually saying is that I'm willing to do anything to get this
quickly in unstable. I'll file the wishbug. Thanks for everything.

On Fri, 2009-07-31 at 00:39 +1000, Ben Finney wrote:
> Adrian Perez  writes:
> 
> > I'd like to see this in unstable ASAP.
> 
> A message to this list isn't going to do anything to help that happen.
> 
> Rather, you should consider whether the maintainer of the Debian package
> might be unaware of the new version, and if in your estimation they
> might have overlooked the version, file a Debian BTS bug report of
> “wishlist” severity against the package.
> 
> In this case, though, I think it's pretty likely the maintainer is
> already well aware of this new version, and doesn't need reminding.
> 
-- 
Best regards, 

Adrian Perez 


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

Re: multiarch: dependency-oriented vs package-oriented

[Steve Langasek]

On Wed, Jul 29, 2009 at 11:20:20PM +0200, Goswin von Brederlow wrote:
> You raise an interesting point there with -dbg packages. Esspecially
> considering the Google SoC project that wants to automatically build
> -dbg packages for everything in debian. Those .ddeb packages. Too me
> it seems that .ddeb packages seem like a really good idea and teaching
> the package management system that .ddeb packages must match the
> architecture no matter what the .deb says seems like the solution to
> your example. The -dbg packages could be handled all in one go
> magically. So do you have another example besides -dbg packages?

In the specific case of external .ddeb packages, there are additional
options available to us.  In particular, since .ddeb archives don't exist
today for Debian, and would presumably not be subject to the same sort of
archive consistency checks, then if dpkg adds support for
architecture-constrained dependencies (Depends: fwibble:i386) in the squeeze
time frame, these could be used for ddebs immediately in squeeze even though
they're not supported in the main archive.

> I myself am not yet happy with the "Multi-Arch: allowed" feature as
> solution. And I haven't heard all the rational behind it. Why it is
> better than other suggestions from the past. It is something that has
> been added to the specs recently and I think you make a point that
> maybe it needs to be thought of or explained some more. The existing
> -dbg packages certainly make a point for allowing "Depends: foo:same"
> or "Depends: foo:arch" no matter what foo has as "Multi-Arch: ...".

Which past suggestions are you referring to?  Ephemeral ideas that no one
saw fit to record aren't of much help.

I think the rationale is already laid out in the spec.

I also think that -dbg packages are a wart on our archive and our packaging,
and am not overly concerned about whether these packages remain consistent
on transition to multiarch - unlike interpreters, which need to be handled
right for the sanity of our users.

> Another option would be for foo to
>   Provides: foo-$(DEB_HOST_GNU_TYPE)-${binary:version}
> and for foo-dbg to depend on that. Or for plugins
>   Provides: foo-$(DEB_HOST_GNU_TYPE)-$(PLUGIN_ABI).

I don't think that's acceptable.

-- 
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: Please test eglibc 2.9-23+multiarch.1

[Aurelien Jarno]

On Thu, Jul 30, 2009 at 06:58:45PM +0300, Eugene V. Lyubimkin wrote:
> Aurelien Jarno wrote:
> > Except saying "apt sucks", I currently do not have more idea. Someone
> > else maybe?
> > 
> /me suggests to try cupt and hides
> 

We have the constraints that we should support upgrades from Lenny, so
we are stuck with apt/aptitude from lenny...

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net


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

Reminder: /usr/share/doc/${PACKAGE}/examples/

[Mario Lang]

Hi.

A comment from Martin F. Krafft in his talk today at DebConf9
reminded me that many of our binary packages do actually not include
the example files which are included in the source package.

I've been anoyed by this several times in the past already, and
wheenever I stumble across a binary package missing available example
files I file a bug.  I just did a quick check and found 2 out of
5 packages I looked at to have examples in the source package which are
not shipped with any binary package.

I will probably try to automate this process somewhat and file a lot
more bugs soon, but before I start this effort I'd like to remind
individual package maintainers to look at their packages and check if
they are providing example files that are not shipped yet.

As Martin said today, many of us actually like to start from some simple
templates, instead of creating something new completely from scratch.
I very very much agree with this.

So, please, remember policy 12.6, thank you.

http://www.debian.org/doc/debian-policy/ch-docs.html#s12.6

-- 
CYa,
  ⡍⠁⠗⠊⠕


pgpqpK9n7Ol0I.pgp
Description: PGP signature

check to detect non packaged examples from upstream

[Stefano Zacchiroli]

Package: lintian
Version: 2.2.13
Severity: wishlist

On Thu, Jul 30, 2009 at 06:56:30PM +0200, Mario Lang wrote:
> I will probably try to automate this process somewhat and file a lot
> more bugs soon, but before I start this effort I'd like to remind
> individual package maintainers to look at their packages and check if
> they are providing example files that are not shipped yet.

It looks like more sensible to have a lintian test that checks that,
rather then automating a process to find this out a posteriori.

I guess the lintian check can implement a semantics like the following
one:

- check whether the unpacked debianized source tree contains somewhere
  an examples/ directory (find -d ?)

- if it does, check whether at least one of the binary package ships
  it under /usr/share/doc/PACKAGE/examples/

- if there is no such package, emit a warning with a medium certainty

I'm filing the corresponding wishlist bug report with this post.

Thanks for the idea!
Cheers.

PS we discussed how lintian is one of the best way to push
   acceptance in Debian, remember? :-)

-- 
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: Bits from the release team and request for discussion

[Cyril Brulebois]

(Torn between replying to -project for the former, -devel for the
latter.)

Luk Claes  (30/07/2009):
> Adam D. Barratt (adsb), Felipe Augusto van de Wiel (faw) and Jurij
> Smakov (jurij) joined us as release assistants. Let's welcome them in
> our team.

Welcome!

> Architectures
> =
> 
> As some of you might have noticed, we added the architectures
> kfreebsd-i386 and kfreebsd-amd64 to testing. This is not a promise
> that they will be part of Squeeze, but we consider it realistic.
> Adding them early to testing makes it easier for us to get testing
> into shape. As of now, these architectures don't have any effect on
> the testing migration.  Bugs specific to these architectures are not
> release critical.

We try to direct user questions/bugreporting to our mailinglist[0], but
you might receive a GNU/kFreeBSD-specific bug report anyway. Feel free
to contact us, we'll look into those issues as time permits.

 0. debian-...@lists.debian.org

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Bits from the release team and request for discussion

[Aurelien Jarno]

On Thu, Jul 30, 2009 at 07:28:58PM +0200, Luk Claes wrote:
> The following goals for Squeeze have been identified up to now:
>  * multiarch
>  * boot performance
>  * high quality packages (piuparts clean and other QA subgoals)
>  * prepare for the new package formats
>  * remove obsolete libraries
>  * add kfreebsd-amd64 and kfreebsd-i386
>  * full IPv6 support
>  * large file support

And according to the press release: 
|  * Move of packages' long descriptions into a separate "translated 
|package list", which will facilitate their translation and also 
|provide a smaller footprint for embedded systems thanks to smaller 
|Packages files.
|  * Better integration of debtags, a system to tag packages with multiple
|attributes for easier package selection
|  * Discard and rebuild of binary packages uploaded by maintainers, 
|leaving only packages build in a controlled environment 

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: Digital signature

How to check why a package is in contrib

[Bastien ROUCARIES]

Hi,

I was trying to check why a package was in contrib (jabref), and I could not 
find a means to do that automatically. 

Could we add an automatic mechanism based on package description, for getting 
the reason, like for instance, why-contrib: reason

It will ease the move to main in case of for instance a nonfree build lib that 
go to main :)

Bastien


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

Re: Bits from the release team and request for discussion

[Ondřej Surý]

Hi,

> The following goals for Squeeze have been identified up to now:
>  * multiarch
>  * boot performance
>  * high quality packages (piuparts clean and other QA subgoals)
>  * prepare for the new package formats
>  * remove obsolete libraries
>  * add kfreebsd-amd64 and kfreebsd-i386
>  * full IPv6 support
>  * large file support

with root being signed[1] really soon (TM), could we add DNSSEC
support to this list? Since I have recently switched position in my
company (which took a lot of time), it looks like I will have now
plenty of time for DNSSEC (since I can put DNSSEC in Debian to my top
priorities).

Ondrej
1. as in DNSSEC signed
-- 
Ondřej Surý 
http://blog.rfc1925.org/


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

Re: How to check why a package is in contrib

[Cyril Brulebois]

Bastien ROUCARIES  (30/07/2009):
> I was trying to check why a package was in contrib (jabref), and I
> could not find a means to do that automatically. 
> 
> Could we add an automatic mechanism based on package description, for
> getting the reason, like for instance, why-contrib: reason
> 
> It will ease the move to main in case of for instance a nonfree build
> lib that go to main :)

I would guess that one might expect a reason in changelog, first upload
to contrib, and copyright file.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Bits from the release team and request for discussion

[Jonathan Wiltshire]

On Thu, Jul 30, 2009 at 07:28:58PM +0200, Luk Claes wrote:
> time-based freezes
> ==
> 
> For the squeeze release (and future releases), we are considering a
> time-based freeze, meaning that the freeze will happen at a predictable
> and predetermined time with the release happening at a later time once
> the release requirements are met.  We think that having a time-based

The press team are still announcing [1] this as a "decision to adopt the
policy of timed release freezes beginning with the next release", while
RT maintain that it is under consideration. Which is true?

(note: I'm not shooting any messengers, I just want to understand.)

1: http://lists.debian.org/debian-announce/2009/msg00010.html

-- 
Jonathan Wiltshire

1024D: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3  A903 CA6B EA3E DB80 0B52
4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51


signature.asc
Description: Digital signature

Re: Bits from the release team and request for discussion

[Marc Haber]

Hi,

On Thu, Jul 30, 2009 at 07:28:58PM +0200, Luk Claes wrote:
> sorry for sending out this mail so late. It should have gone out a bit
> earlier, but the delay allowed us to update our views on the timeline
> based on the feedback we received by the community - see below for
> details.

Was it really necessary to solicit this feedback by putting out a
Press Release, which has been picked up by non-Debian media and even
by corporate entities running Debian?

> For the squeeze release (and future releases), we are considering a
> time-based freeze,

Noted, that this is a consideration.

> Based on feedback of the community on the plan to freeze in December
> 2009 and  the ambituous Release Goals we set for ourselves, we are
> revisiting the decision to freeze December 2009.

Now you are revisiting the decision to freeze time-based. So you first
decided on freezing in December and then considered freezing
time-based? This sounds like backwards. Please explain the rationale
chain that led to these events.

I am kind of missing an explanation for Ubuntu's role in this
mess^wevent. Since Mark Shuttleworth seemed to know about your
consideration (see his recent interview with derstandard.at) well
before the rest of the world including your fellow developers was
informed, I'd like to inquire about these as well. Is it your
intention to sync up with Ubuntu's LTS releases, and why? What
advantages do you expect from this sync, and which disadvantages have
you decided to accept for having Debian stable synced to Ubuntu LTS?

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190


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

Re: Bits from the release team and request for discussion

[Samuel Thibault]

Cyril Brulebois, le Thu 30 Jul 2009 19:41:42 +0200, a écrit :
> > Architectures
> > =
> > 
> > As some of you might have noticed, we added the architectures
> > kfreebsd-i386 and kfreebsd-amd64 to testing. This is not a promise
> > that they will be part of Squeeze, but we consider it realistic.
> > Adding them early to testing makes it easier for us to get testing
> > into shape. As of now, these architectures don't have any effect on
> > the testing migration.  Bugs specific to these architectures are not
> > release critical.
> 
> We try to direct user questions/bugreporting to our mailinglist[0], but
> you might receive a GNU/kFreeBSD-specific bug report anyway. Feel free
> to contact us, we'll look into those issues as time permits.
> 
>  0. debian-...@lists.debian.org

Also, please remember that such issues are often not only for
GNU/kFreeBSD, but also for GNU/Hurd, GNU/OpenSolaris, GNU/whatever, so
please rather think "non-linux issue" than "BSD issue".

Samuel


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

Re: How to check why a package is in contrib

[Chris Lamb]

Cyril Brulebois wrote:

> I would guess that one might expect a reason in changelog, first upload
> to contrib, and copyright file.

Also check http://nonfree.alioth.debian.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org
   `-


signature.asc
Description: PGP signature

Re: Bits from the release team and request for discussion

[Manoj Srivastava]

Hi,

I would like to set up a selinux related release goal for
 Squeeze.

 Developer assiociated:  Manoj Srivastava (Perhaps also Russell Coker,
 but I have not discussed this with him)
 Issues to be solved:
   (a) Get all Debian patches to the reference security policy merged in
   upstream.  Status: In progress, we have all patches submitted,
   some need to be tweaked and resubmitted based on feedback
Time line: 1-2 months, depending on free tie I have
   (b) Update reference security policy to allow standard machines to be
   in enforcing mode.
   Status: It is possible to run minimal virtual machines in
   enforcing mode, but real machines are somewhat crippled; these
   denials need to be inspected, and determination needs to be made
   for how to resolve them (no not want security holes enshrined in
   policy)
  Time line: 6-8 months (can be done in tandem with a, if here were
  more people working on it)
   (c) Make it easier to run in struct (no unconfined.pp module)
   mode. This needs firstly documentation, and secondly, additional
   tweaks to policy to make it work. Russell has a play machine
   where it all works, but those changes are not in the reference
   policy -- and some of them might not be fit to be in ref policy
   at all.
  Time line: 9-12 months

The actual non-policy packages are now well in sync with
 upstream,  so the weak point is the security policy.

Ideally, the goal would be to have Squeeze certifiable at EAL-4,
 at least the "standard" install (no optional packages), if someone with
 deep pockets were willing to actually pay for the certification, and be
 willing to push through the process.

manoj
-- 
The Public is merely a multiplied "me." Mark Twain
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Bits from the release team and request for discussion

[Gustavo Franco]

On Thu, Jul 30, 2009 at 11:16 AM, Manoj Srivastava wrote:
> Hi,
>
>        I would like to set up a selinux related release goal for
>  Squeeze.
>
>  Developer assiociated:  Manoj Srivastava (Perhaps also Russell Coker,
>                         but I have not discussed this with him)
>  Issues to be solved:
>   (a) Get all Debian patches to the reference security policy merged in
>       upstream.  Status: In progress, we have all patches submitted,
>       some need to be tweaked and resubmitted based on feedback
>        Time line: 1-2 months, depending on free tie I have
>   (b) Update reference security policy to allow standard machines to be
>       in enforcing mode.
>       Status: It is possible to run minimal virtual machines in
>       enforcing mode, but real machines are somewhat crippled; these
>       denials need to be inspected, and determination needs to be made
>       for how to resolve them (no not want security holes enshrined in
>       policy)
>      Time line: 6-8 months (can be done in tandem with a, if here were
>      more people working on it)
>   (c) Make it easier to run in struct (no unconfined.pp module)
>       mode. This needs firstly documentation, and secondly, additional
>       tweaks to policy to make it work. Russell has a play machine
>       where it all works, but those changes are not in the reference
>       policy -- and some of them might not be fit to be in ref policy
>       at all.
>      Time line: 9-12 months
>
>        The actual non-policy packages are now well in sync with
>  upstream,  so the weak point is the security policy.
>
>        Ideally, the goal would be to have Squeeze certifiable at EAL-4,
>  at least the "standard" install (no optional packages), if someone with
>  deep pockets were willing to actually pay for the certification, and be
>  willing to push through the process.

Which parts of the work you described above would be needed to Squeeze
be certifiable at EAL-4? All of them?

Based on your timeline, it seems A is on track to make Squeeze, we
should get more people to work with you on B (setting as a goal) and C
would be a no go for this release, jmo. Am I wrong?

regards,
-- Gustavo "stratus" Franco


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

Re: Bits from the release team and request for discussion

[Alexander Reichle-Schmehl]

Hi!

Aurelien Jarno schrieb:
> On Thu, Jul 30, 2009 at 07:28:58PM +0200, Luk Claes wrote:
>> The following goals for Squeeze have been identified up to now:
[ some stuff ]

> And according to the press release: 
[ some more stuff ]

The press release not only mentions release goals but also
"infrastructure goals" ftpmaster would like to have done by then.

Best regards,
  Alexander


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

Re: Introduction to multiarch: What maintainers must do

[Tollef Fog Heen]

]] 

| > My first thought was "Err. Won't moving all the shared libs into a
| > different location kinda screw things up?" And then I looked, and found
| > 
| >   | ==> /etc/ld.so.conf.d/x86_64-linux-gnu.conf <==
| 
| Yes, but however pkg-config won't yet find things in
| /usr/lib/x86_64-linux-gnu/pkgconfig, so take care of putting .pc files
| in /usr/lib/pkgconfig.

As long as you're using pkg-config newer than 0.16.0-1 which was
uploaded in February 2005, it'll look in
/usr/lib/pkgconfig/x86_64-linux-gnu .

I guess I should change that to /usr/lib/x86_64-linux-gnu/pkgconfig, but
you can actually multiarchify packages with .pc files already.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


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

Re: Introduction to multiarch: What maintainers must do

[Tollef Fog Heen]

]] Gabor Gombas 

| Later pkg-config should be extended to have an "--arch" command-line
| option (or env. variable) that is substituted into the default search
| path at run time rather than at build time, but that can wait.

This has been considered before, and I'm not yet convinced it's a better
idea than to just have a /usr/bin/x86_64-linux-gnu-pkg-config.
pkg-config has a bit too much magic already, I'd rather not make it
even more magic.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


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

Re: Bits from the release team and request for discussion

[Anthony Towns]

On Thu, Jul 30, 2009 at 07:28:58PM +0200, Luk Claes wrote:
> Architectures
> =
> As some of you might have noticed, we added the architectures
> kfreebsd-i386 and kfreebsd-amd64 to testing. [...]
> However, two architectures also have issues we need to bring to your
> attention: We sent mails to the porters of both alpha and hppa [...]

So, http://release.debian.org/squeeze/arch_qualify.html lists kfreebsd-*
and m68k as not release candidates, and arm, ia64, mips and powerpc as
"at risk" in addition to alpha and hppa. Only m68k is listed as having
RM concerns.  Is that page actually reflecting the release team's view
of architecture status at all, and could it be made to correspond a bit
more closely either way?

> About freeze timing we think that DebConf should definitely not fall
> into a freeze

Past freezes were:

potato  2000/01 - 2000/08   (DebConf 0 was early 2000/07)
woody   2001/07 - 2002/07   (DebConf 1 was immediately after the
 policy freeze started, DebConf 2 happened
 a week or two before woody released)
sarge   2005/05 - 2005/06   (DebConf 5 was a month after release)
etch2006/12 - 2007/04   (DebConf 7 was three months after release)
lenny   2008/07 - 2009/02   (DebConf 8 was in 2008/08, a month into the 
freeze)

How you relate DebConf 3 and DebConf 4 to sarge's "freeze" is up for
debate, I suppose; while sarge "officially" froze a month before release,
that's not necessarily "real".

I really don't see what the big deal with having debconf during a freeze
is though...

> and that we should leave time after DebConf to integrate
> the possibly disruptive changes we introduced by doing cool stuff at
> DebConf. 

Fixing RC bugs is pretty cool...

> We noticed that releases in the first quarter of the year
> worked out quite well in the past like both Etch and Lenny. Taking these
> into consideration we think it would be best to freeze in December.

Etch was intended to freeze in October, with a release in December; the freeze
was delayed because of a high bug count (250 RC bugs). I think there was pretty
heavy peer pressure to have any transitions and major uploads done well before
December for etch. And lenny, of course, was frozen in July...

> We'll be consulting all key teams within Debian to see how their plans
> and schedules can fit into a new timeline. Before the end of August we
> hope to have finished this process of consultation and be able to
> present the new plan to you.

Why not have a developer poll as to what month(s) would most suit
people for the freeze, rather than limiting it to "key teams"? Also, how
about soliciting input from our users, just in case they have something
interesting to add? Maybe LTS-syncing will turn out to be something users
really do/don't want, or maybe there are other priorities they have that
are worth considering.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Bits from the release team and request for discussion

[Aurelien Jarno]

On Thu, Jul 30, 2009 at 08:58:14PM +0200, Alexander Reichle-Schmehl wrote:
> Hi!
> 
> Aurelien Jarno schrieb:
> > On Thu, Jul 30, 2009 at 07:28:58PM +0200, Luk Claes wrote:
> >> The following goals for Squeeze have been identified up to now:
> [ some stuff ]
> 
> > And according to the press release: 
> [ some more stuff ]
> 
> The press release not only mentions release goals but also
> "infrastructure goals" ftpmaster would like to have done by then.
> 

Then, maybe the ftpmasters should communicate through
debian-devel-announce *in addition* to the press releases.

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net


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

Re: Emacs 23.1 released

[Romain Francoise]

Adrian Perez  writes:

> I'd like to see this in unstable ASAP.

http://lists.debian.org/debian-emacsen/2009/07/msg4.html

-- 
Romain Francoise 
http://people.debian.org/~rfrancoise/


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

Re: Emacs 23.1 released

[Ben Finney]

Adrian Perez  writes:

> What I'm actually saying is that I'm willing to do anything to get
> this quickly in unstable.

Perhaps contact the maintainer — or, in the case of Emacs, the
‘debian-emacsen’ forum — and ask directly what you can do to help.

> I'll file the wishbug. Thanks for everything.

Again, you should only do that if your research into how the Debian
package maintainer is handling it leads you to believe they are not
already aware of the new version.

-- 
 \   “bash awk grep perl sed, df du, du-du du-du, vi troff su fsck |
  `\ rm * halt LART LART LART!” —The Swedish BOFH, |
_o__)alt.sysadmin.recovery |
Ben Finney


pgpw3txLJYReZ.pgp
Description: PGP signature

Bug#506481: initscripts: Fix to allow falsified cpu information in /proc/cpuinfo

[Kurt Roeckx]

On Thu, Jul 30, 2009 at 04:21:44PM +0200, Petter Reinholdtsen wrote:
> reassign 506481 general
> thanks
> 
> [Matthias Klose]
> >> Right.  This seem to be a problem that need to be solved by the
> >> compiler, and not by initscripts.  Reassigning to gcc.
> >
> > this has nothing to do with the compiler, which is built for a fixed 
> > arch/tune setting.
> 
> Right.  If the compiler is not the entity deciding what architecture
> and CPU feature set a program is build for, I have no idea what is.
> It is definitely not the initscripts package, so I reassign this to
> 'general' in the hope that someone know more about this than me.

This is most likely a bug in the package.  Some configure scripts
and simular tools tried to detect the cpu at build time and
pass options to gcc to change the default.  This is always wrong
for a Debian package.  If this is about a Debian package you should
file a bug against the package that has this problem.


Kurt




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

Work-needing packages report for Jul 31, 2009

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 373 (new: 8)
Total number of packages offered up for adoption: 125 (new: 1)
Total number of packages requested help for: 55 (new: 1)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   etl (#538966), orphaned 2 days ago
 Description: Extended Class and Template Library
 Reverse Depends: libsynfig-dev
 Installations reported by Popcon: 16

   filterproxy (#538451), orphaned 5 days ago
 Description: Unmaintained upstream and pretty unused
 Installations reported by Popcon: 9

   pynetsnmp (#538261), orphaned 6 days ago
 Installations reported by Popcon: 27

   pysnmp-se (#538255), orphaned 6 days ago
 Reverse Depends: python-twisted-snmp
 Installations reported by Popcon: 47

   synfig (#538964), orphaned 2 days ago
 Description: vector-based 2D animation renderer
 Reverse Depends: libsynfig-dev libsynfigapp0 synfig synfig-dbg
   synfigstudio
 Installations reported by Popcon: 290

   synfigstudio (#538965), orphaned 2 days ago
 Description: vector-based 2D animation package (graphical user
   interface)
 Reverse Depends: synfigstudio synfigstudio-dbg
 Installations reported by Popcon: 264

   trac-bzr (#538511), orphaned 5 days ago
 Installations reported by Popcon: 55

   wxwidgets2.8 (#539170), orphaned yesterday
 Reverse Depends: amule amule-daemon amule-utils amule-utils-gui
   audacity bibus bitpim bittornado-gui boinc-manager crystalspace (50
   more omitted)
 Installations reported by Popcon: 13706

365 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   serpentine (#538409), offered 5 days ago
 Description: An application for creating audio CDs
 Installations reported by Popcon: 17360

124 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

[NEW] wxwidgets2.8 (#539170), requested yesterday
 Reverse Depends: amule amule-daemon amule-utils amule-utils-gui
   audacity bibus bitpim bittornado-gui boinc-manager crystalspace (50
   more omitted)
 Installations reported by Popcon: 13706

   apache2 (#470795), requested 504 days ago
 Description: Co-maintainer wanted
 Reverse Depends: ampache apache2 apache2-dbg apache2-mpm-event
   apache2-mpm-itk apache2-mpm-prefork apache2-mpm-worker
   apache2-prefork-dev apache2-suexec apache2-suexec-custom (163 more
   omitted)
 Installations reported by Popcon: 44675

   ara (#450876), requested 627 days ago
 Description: utility for searching the Debian package database
 Installations reported by Popcon: 111

   asymptote (#517342), requested 153 days ago
 Description: script-based vector graphics language inspired by
   MetaPost
 Installations reported by Popcon: 618

   athcool (#278442), requested 1738 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 177

   boinc (#511243), requested 203 days ago
 Description: BOINC distributed computing
 Reverse Depends: boinc-app-milkyway boinc-app-seti boinc-dbg
 Installations reported by Popcon: 1614

   cvs (#354176), requested 1253 days ago
 Description: Concurrent Versions System
 Reverse Depends: crossvc cvs-autoreleasedeb cvs-buildpackage cvs2cl
   cvs2html cvschangelogbuilder cvsconnect cvsd cvsps cvsservice (10
   more omitted)
 Installations reported by Popcon: 20652

   dctrl-tools (#448284), requested 642 days ago
 Description: Command-line tools to process Debian package
   information
 Reverse Depends: aptfs debian-goodies dlocate haskell-devscripts
   hg-buildpackage ia32-archive ia32-libs-tools libsbuild-perl mlmmj
   simple-cdd
 Installations reported by Popcon: 12207

   dpkg (#282283), requested 1712 days ago
 Description: dselect: a user tool to manage Debian packages
 Reverse Depends: alien alqalam alsa-source apt-build apt-cross
   apt-src asymptote asymptote-doc autoconf-doc avrdude-doc (253 more
   omitted)
 Installations reported by Popcon: 84265

   elvis (#432298), requested 752 days ago
 Description: powerful clone of the vi/ex text editor (with X11
   support)
 Reverse Depends: elvis elvis-console elvis-tools
 Installations reported by Popcon: 355

   fglrx-driver (#454993), 

Re: waf into NEW, please test it with your packages

[Ryan Niebur]

Hi!

On Mon, Jul 27, 2009 at 09:56:19AM +0200, Luca Falavigna wrote:
> Ryan Niebur ha scritto:
> > It doesn't work with midori apparently...
> 
> Right, I prepared a patch to build with 0.1.7, but I noticed new
> upstream version (0.1.8) builds correctly. If you plan to upgrade to the
> new version, you should not have any issue with waf Debian package.
> Thanks for testing!
> 

would you mind providing a .deb of that so that I can test and update
my dh build system patch to use it?

Cheers,
Ryan

-- 
_
Ryan Niebur
ryanrya...@gmail.com


signature.asc
Description: Digital signature

Re: Bits from the release team and request for discussion

[Manoj Srivastava]

On Thu, Jul 30 2009, Gustavo Franco wrote:

> On Thu, Jul 30, 2009 at 11:16 AM, Manoj Srivastava wrote:
>> Hi,
>>
>>        I would like to set up a selinux related release goal for
>>  Squeeze.
>>
>>  Developer assiociated:  Manoj Srivastava (Perhaps also Russell Coker,
>>                         but I have not discussed this with him)
>>  Issues to be solved:
>>   (a) Get all Debian patches to the reference security policy merged in
>>       upstream.  Status: In progress, we have all patches submitted,
>>       some need to be tweaked and resubmitted based on feedback
>>        Time line: 1-2 months, depending on free tie I have
>>   (b) Update reference security policy to allow standard machines to be
>>       in enforcing mode.
>>       Status: It is possible to run minimal virtual machines in
>>       enforcing mode, but real machines are somewhat crippled; these
>>       denials need to be inspected, and determination needs to be made
>>       for how to resolve them (no not want security holes enshrined in
>>       policy)
>>      Time line: 6-8 months (can be done in tandem with a, if here were
>>      more people working on it)
>>   (c) Make it easier to run in struct (no unconfined.pp module)
>>       mode. This needs firstly documentation, and secondly, additional
>>       tweaks to policy to make it work. Russell has a play machine
>>       where it all works, but those changes are not in the reference
>>       policy -- and some of them might not be fit to be in ref policy
>>       at all.
>>      Time line: 9-12 months
>>
>>        The actual non-policy packages are now well in sync with
>>  upstream,  so the weak point is the security policy.
>>
>>        Ideally, the goal would be to have Squeeze certifiable at EAL-4,
>>  at least the "standard" install (no optional packages), if someone with
>>  deep pockets were willing to actually pay for the certification, and be
>>  willing to push through the process.
>
> Which parts of the work you described above would be needed to Squeeze
> be certifiable at EAL-4? All of them?

Making a Debian release EAL-4 certifiable would go beyond
 (perhaps far beyond) just making strict policy work, but all three
 above would be a minimal requirement.

> Based on your timeline, it seems A is on track to make Squeeze, we
> should get more people to work with you on B (setting as a goal) and C
> would be a no go for this release, jmo. Am I wrong?

Well, that would depend on when the freeze happens. If we freeze
 a year from now, I think there is a fighting chance all these can be
 accomplished. 

manoj
-- 
The shortest measurable interval of time is the time between the moment
I put a little extra aside for a sudden emergency and the arrival of
that emergency.
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: How to check why a package is in contrib

[Charles Plessy]

Le Thu, Jul 30, 2009 at 07:44:08PM +0200, Bastien ROUCARIES a écrit :
> 
> I was trying to check why a package was in contrib (jabref), and I could not 
> find a means to do that automatically. 
> 
> Could we add an automatic mechanism based on package description, for getting 
> the reason, like for instance, why-contrib: reason

Dear Bastien,

starting from version 3.8.0, our Policy states:

  ‘Packages in the contrib or non-free archive areas should state in the
  copyright file that the package is not part of the Debian GNU/Linux
  distribution and briefly explain why.’

Since jabref has a Standards-Version of 3.8.0, I think that you can submit a
bug report to ask the maintainers to add this information.

For the packages using a machine-readable Debian copyright file, I propose to
put this kind of information in a field that can for instance be called
‘Disclaimer’. If this format gets popular, a Lintian check will be trivial to
write, to ensure that contrib and non-free packages include the statement
recommended by the Policy. 

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


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

Re: Bits from the release team and request for discussion

[Russell Coker]

On Fri, 31 Jul 2009, Manoj Srivastava  wrote:
>  Developer assiociated:  Manoj Srivastava (Perhaps also Russell Coker,
>  but I have not discussed this with him)

I will be involved in this, but I find it difficult to get enough free time.

>  Issues to be solved:
>(a) Get all Debian patches to the reference security policy merged in
>upstream.  Status: In progress, we have all patches submitted,
>some need to be tweaked and resubmitted based on feedback
> Time line: 1-2 months, depending on free tie I have

Great work!

>(b) Update reference security policy to allow standard machines to be
>in enforcing mode.
>Status: It is possible to run minimal virtual machines in
>enforcing mode, but real machines are somewhat crippled; these
>denials need to be inspected, and determination needs to be made
>for how to resolve them (no not want security holes enshrined in
>policy)
>   Time line: 6-8 months (can be done in tandem with a, if here were
>   more people working on it)

That shouldn't be difficult.  Incidentally it would really help me with 
working on this if you could get the policy to build with -j2...

>(c) Make it easier to run in strict (no unconfined.pp module)
>mode. This needs firstly documentation, and secondly, additional
>tweaks to policy to make it work. Russell has a play machine
>where it all works, but those changes are not in the reference
>policy -- and some of them might not be fit to be in ref policy
>at all.
>   Time line: 9-12 months

My Play Machine runs the same policy as every other SE Linux machine I run 
which is also the same as the policy in my repository (a newer version than 
the policy in Lenny).  There is a single extra module of policy which allows 
read-only and read-append file types so that guest users can't mess with each 
other so easily.

The basic strict functionality works without any changes to policy.

Solving B plus writing a tiny amount of documentation will solve C.

> Ideally, the goal would be to have Squeeze certifiable at EAL-4,
>  at least the "standard" install (no optional packages), if someone with
>  deep pockets were willing to actually pay for the certification, and be
>  willing to push through the process.

The EAL number is a matter of how well you meet your profile targets.  We can 
meet the requirements to be certifiable (*) with CAPP and RBACPP at EAL-4 if 
we continue on the current course.  Meeting LSPP will be a lot harder, I've 
never even tried that on Debian.  Not that out users are likely to mind - 
very few people use LSPP configurations.

(*) Getting certified requires a lot of time, paperwork, and money.  Expect to 
spend the best part of $1,000,000 to get it.

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