Re: Cedilla removed from sid, users complain

[Luca Capello]

Hi there!

Juliusz, it is better to point your question to the *maintainer* of the
package, not to debian-devel@ (which is not a mandatory mailing list for
all the maintainers).  Adding the Debian Common Lisp team to the loop.

On Tue, 25 Jan 2011 22:25:19 +0100, Philip Hands wrote:
> It seems that there are no outstanding bugs against the package, so
> there should be no problem with using the existing package, and I see
> that 0.6 is still the current version so I presume that it's not a fast
> moving package, so should really only need uploads as bugs are reported,
> or once every release to keep up with relevant policy changes.

The package is bug-free, yes, and I would say it is even less that "a
fast moving package", the latest upstream release being the one we had
in main (plus some patches from one year and a half ago).

NB, I have not checked the full darcs repositories, but only the NEWS
file on it.

I am not saying that the package is not anymore interesting because
upstream seems dead.  And if you read the email I linked from #610903,
you can see that I have checked for alternatives, missing paps, however:

  Message-ID: <87fwt921lt@gismo.pca.it>
  URL: 


> I'd imagine that Luca would be willing to hold your hand for the first
> upload if that helps (assuming that he's still up to speed on the
> package).  Luca?

No problem in re-doing an upload, but this is the *last* action I will
do for this package.  Really, I do not even remember why I started
maintaining it, I think it was when we switched to team maintenance in
the Debian Common Lisp team.  And given that I have abandoned all my
Common Lisp work, I do not see the point in keeping myself in the
Uploaders: field...

FYI, I do not use cedilla.

Another possibility would be to have cedilla added to clbuild
, which is officially supported
in the common-lisp-controller package since version 7.0 (clc-build
wrapper), and in some way also before starting from version 6.19.

On Tue, 25 Jan 2011 23:12:01 +0100, Juliusz Chroboczek wrote:
>> There is always the option of either recruiting one of those
>> disappointed users to maintain the package, or doing it yourself.
>
> Thanks for the suggestion -- but I'm already spending all of my
> proverbial Copious Free Time on upstream work.

Well, to be clear I am already out of time, not only for my Debian work.

>> It seems a shame to lose a bug-free package when you apparently have
>> users that are going to miss it.
>
> I think so too.  But I cannot be doing everything.

FWIW, me neither.

I thought about keeping cedilla and actually orphaning it, as you can
read in one of my emails (the one linked from #610903):

  Message-ID: <87fwt921lt@gismo.pca.it>
  URL: 


But please note that after having waited one month and a half, no one
From the Debian Common Lisp team replied to my request for help:

  Message-ID: <8762uvjimb@gismo.pca.it>
  URL: 


I know about the "correct" procedure when orphaning packages, but I
thought that if someone was interested she/he should have shown up way
before my call for help.  And I do not think having more than 300
packages maintained by the QA team is a good thing:

  

So, to summarise, what I can do is: I upload the same version which was
removed from main (plus the maintainer set to the QA team), ask for a
fast review to pass NEW (hi, Alexander!)  and to the Release team to
have it quickly migrated into testing.  Then I orphan the package with a
bug to wnpp and I *forget* about it.

Peter, you performed the last upload, what do you think?

Thx, bye,
Gismo / Luca


pgp6KfdInfCqo.pgp
Description: PGP signature

Re: Cedilla removed from sid, users complain

[Philip Hands]

On Tue, 25 Jan 2011 23:12:01 +0100, Juliusz Chroboczek  
wrote:
> > There is always the option of either recruiting one of those
> > disappointed users to maintain the package, or doing it yourself.
> 
> Thanks for the suggestion -- but I'm already spending all of my
> proverbial Copious Free Time on upstream work.

That's why I was primarily suggesting that you contact the people that
are telling you that they will miss it, and ask if they are willing to
do the packaging work.

Debian is primarily built by people for their own use, so if any of the
people that have got in touch with you care about it enough to do the
relatively small amount of work to build and upload the package, then it
will be in Debian.

On the other hand, if none of the users care that much, then the package
fails to pass the not very rigorous bar to entry for Debian -- we
require that at least one user cares enough to maintain each package.

> I think so too.  But I cannot be doing everything.

I was only really suggesting that you pass on the suggestion to those
that have contacted you.  You should mention to them the version that
was ready to go for Squeeze mentioned by Carsten Hey:

  http://snapshot.debian.org/package/cedilla/0.6%2B20090614-1/

which means that for the first upload, they need to do almost nothing.

Cheers, Phil.
-- 
|)|  Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/
|-|  HANDS.COM Ltd.http://www.uk.debian.org/
|(|  10 Onslow Gardens, South Woodford, London  E18 1NE  ENGLAND


pgpCCxMz0CnD3.pgp
Description: PGP signature

Bug#611167: ITP: libfpdi-php -- PHP library for importing existing PDF documents into FPDF

[Sebastian Harl]

Package: wnpp
Severity: wishlist
Owner: Sebastian Harl 

* Package name: libfpdi-php
  Version : 1.4
  Upstream Author : Jan Slabon
* URL : http://www.setasign.de/products/pdf-php-solutions/fpdi/
* License : Apache License, Version 2.0
  Programming Lang: PHP
  Description : PHP library for importing existing PDF documents into FPDF


FPDI is a collection of PHP classes facilitating developers to read
pages from existing PDF documents and use them as templates in FPDF.
This allows for dynamic generation of PDF files.

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#611168: ITP: libfpdf-tpl-php -- PHP library to use PDF templates with FPDF

[Sebastian Harl]

Package: wnpp
Severity: wishlist
Owner: Sebastian Harl 

* Package name: libfpdf-tpl-php
  Version : 1.2
  Upstream Author : Jan Slabon
* URL : http://www.setasign.de/products/pdf-php-solutions/fpdi/
* License : Apache License, Version 2.0
  Programming Lang: PHP
  Description : PHP library to use PDF templates with FPDF

This script adds the possibility to use PDF templates in a PDF document
as explained in the PDF specifications 1.3 (4.9 Form XObjects). This
allows for dynamic creation of PDF files. It supports recursive
templates.

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Re: Safe file update library ready (sort of)

[Goswin von Brederlow]

Ian Jackson  writes:

> Shachar Shemesh writes ("Re: Safe file update library ready (sort of)"):
>> I'm sorry, it might be me, but I fail to see the overlap between the 
>> functionalities of safewrite vs. userv. The premises for safewrite is 
>> that a program wants to make sure data integrity is maintained when 
>> writing files. Userv seems to be about trust and a user level tool. The 
>> two seem to revolve around two completely different interpretations to 
>> the word "safe", as well as two completely different use scenarios.
>> 
>> Am I missing something here?
>
> Sorry, I replied to the wrong message.  I meant to reply to Adam
> Borowski's comment, where he wrote:
>
> ] There's a race condition:
> ] 
> ] while [ 1 ]; do ln -s /etc/passwd somefile.tmp; done
> ] "Hey root, could you please use this program using libsafewrite on
> ] 'somefile'?"
>
> Having said that, I don't think the concept behind your library is
> sound, because it presupposes that all previous programs which update
> files are buggy.
>
> Just because some wrongheaded Linux kernel filesystem developers think
> that almost all previously written Unix programs are buggy, doesn't
> mean that it's true or that the right fix is to rewrite every program.
>
> Ian.

I think you are dead wrong there Ian. Even if every single program is
dead right (and we know a lot aren't) that means every one of them has
a safe file update function somewhere in it.

A function doing exactly the same thing in many programms. Doesn't that
just scream for a shared library?

Add to that the number of programs that don't yet do file updates in a
safe way and need to be fixed I think the project is a verry good
idea. The unexpected behaviour of ext4 is just a minor implementation
detail to take care for a general safe update function.

So Shachar don't get discuraged by the ocassional nay sayer.

MfG
Goswin


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

Re: Safe file update library ready (sort of)

[Goswin von Brederlow]

Shachar Shemesh  writes:

> Hi all,
>
> I've promised to get a library out there, and here it is. The base URL
> is https://github.com/Shachar/safewrite, and the actual code is at
> https://github.com/Shachar/safewrite/blob/master/safewrite.c
>
> This is not a formal release just yet (plus one function is still
> missing an implementation, trivial though it might be). It's just that
> the list obviously has a few people knowledgeable on the subject who
> can give my code a second look and see whether there is anything I
> have missed.
>
> I'll probably make an official release over the next couple of
> days. Feedback most appreciated.
>
> Shachar

Some things I noticed:

safewrite.h:
- missing headers, e.g. for mode_t
- no 'extern "C" {'


I don't like how your functions are destructive to the path argument. I
get that you need to cerate the real path and return that. But maybe you
could use

tyepdef char * path_t;

int safe_open( const char *name, path_t *path, int flags, mode_t mode )
int safe_close( const path_t *path, int fd )
int safe_close_sync( char path_t *path, int fd)

That way one could use

path_t path;
int fd = safe_open(".myapp.rc", &path, ...);

OR

typedef struct {
int fd;
char buffer[PATH_MAX];
} safe_t;

safe_t * safe_open( const char *name, int flags, mode_t mode );
int safe_close( const safe_t *object);
int safe_close_sync( safe_t *object) ;
static inline int safe_fd(const safe_t *object) {
   if (object == NULL) {
  return -1;
   } else {
  return object->fd;
   }
}

Just some thoughts,
 Mrvn


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

Re: squeeze will have googleearth-package

[Goswin von Brederlow]

Petter Reinholdtsen  writes:

> [Ben Hutchings]
>> I think the plan was that any firmware package that is available
>> during installation and that satisfies a firmware request will get
>> installed.  However, I have not worked on this and I don't know what
>> has actually been implemented.
>
> At the moment hw-detect as part of d-i will look in CDROM/firmware/
> for .debs providing the files requested by a kernel module, and
> install any such .deb into the installed system.  The correct .deb is
> found by unpacking the deb and looking at its content.  hw-detect will
> not detect which firmware to install from APT sources, as there is
> currently no way to figure out which packages contain firmware and it
> is out of the question to unpack all packages to look for firmware
> packages.
>
> We should find a better way to identify firmware packages, allowing
> hw-detect to find the correct ones without unpacking.
>
> Happy hacking,

Isn't that a non-issue (for now)?

Here's my reasoning:

1) The non-free deb is only in apt if non-free is in sources.list.
2) AN earlier mail stated that the kernel recommends the non-free firmware deb.
3) Recommends are to be installed by default.

Shouldn't the non-free firmware deb end up installed just from that?


For the general case of firmware debs how specific do you want to
be. Should they just add "Provides: linux-firmware-x.y" or a new field
"Firmware: yes" or something? Or do you want each firmware deb to
somehow export hardware info so hw_detect can see if the relevant
hardware is present before installing firmware?

MfG
Goswin


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

Re: Safe file update library ready (sort of)

[Adam Borowski]

On Wed, Jan 26, 2011 at 12:03:52PM +0100, Goswin von Brederlow wrote:
> Shachar Shemesh  writes:
> > I've promised to get a library out there, and here it is. The base URL
> > is https://github.com/Shachar/safewrite, and the actual code is at
> > https://github.com/Shachar/safewrite/blob/master/safewrite.c
> 
> Some things I noticed:
> 
> That way one could use
[..]
> typedef struct {
> int fd;
> char buffer[PATH_MAX];
> } safe_t;

Except, you can't rely on PATH_MAX on any modern system.  It's defined in
Linux headers to an arbitrary value to make old code compile, but for
example Hurd folks decided to not define it altogether to make buggy code
fail during compilation rather than on runtime.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110126112229.ga29...@angband.pl

Re: Safe file update library ready (sort of)

[Olaf van der Spek]

On Wed, Jan 26, 2011 at 12:22 PM, Adam Borowski  wrote:
>> typedef struct {
>>         int fd;
>>         char buffer[PATH_MAX];
>> } safe_t;
>
> Except, you can't rely on PATH_MAX on any modern system.  It's defined in
> Linux headers to an arbitrary value to make old code compile, but for
> example Hurd folks decided to not define it altogether to make buggy code
> fail during compilation rather than on runtime.

That's easily solved by a dynamic allocation.

Olaf


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

Re: How to build a 32-bit package in Debian?

[Goswin von Brederlow]

Adam Borowski  writes:

> On Mon, Jan 17, 2011 at 11:49:17AM +0800, Paul Wise wrote:
>> On Mon, Jan 17, 2011 at 11:25 AM, Steve M. Robbins  wrote:
>> 
>> > What is the recommended course of action for such a package?
>> 
>> For now: build on a 32-bit system or in a 32-bit chroot.
>> 
>> Other options in increasing order of preference:
>> 
>> Add deps to ia32-libs.
>> 
>> Add lib32 packages for the deps.

Actually you need ia32-libs-dev and also gcc-multilib when you COMPILE a
32bit package. ia32-libs itself is only sufficient for building non-free
32bit packages with prebuild binaries.

Please file wishlist bugs about any missing libs.
 
>> Help fix squeeze RC bugs then start work on multi-arch when the wheezy
>> cycle starts.
>
> There's a wonderful thing called "xapt", aka "multi-arch working today". 
> Sadly, it can't be integrated into build-depends like real multi-arch will
> be, but getting all libraries you need is a matter of typing:
>
> # xapt -a pdp11 liblossage1 liblossage-dev

Please don't use xapt. That tool is so far purely for use in chroots
(for pbuilder) and for cross compiling. It does not handle any
dependencies between 32bit libs and the native packages. E.g. for shared
files, conffiles, scripts that need to call other binaries. So using it
to execute 32bit binaries will give verry poor results.

The right tool for this would be the old ia32-apt-get or the revised
apt-ma-emu. Saddly the squeeze freeze hit before apt-ma-emu was ready
for upload so it won't be in squeeze.

MfG
Goswin


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

Bug#611178: ITP: undertaker -- static code analysis tool checking preprocessor directives

[Christoph Egger]

Package: wnpp
Severity: wishlist
Owner: Christoph Egger 

Homepage: http://vamos.informatik.uni-erlangen.de/trac/undertaker
License:  GPL-2 GPL-3+
Version:  1.0
Prograaming Language: C++

Package: undertaker
Description: static code analysis tool checking preprocessor directives
 The undertaker is an preprocessor and configuration analyser. It can
 check the structure of your preprocessor directives against different
 configuration models to find blocks than can't be selected or
 deselected.

Package: undertaker-el
Description: emacs integration for undertaker
 undertaker-mode allows you to get the preprocessor condition under
 which the selected line of source code is built optionally incuding
 restrictions from a external configuration model



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

Re: binNMU for Arch: all packages.

[Goswin von Brederlow]

Bastian Blank  writes:

> On Sat, Jan 15, 2011 at 01:23:01PM +0100, Julien Cristau wrote:
>> On Sat, Jan 15, 2011 at 12:21:52 +0100, Stéphane Glondu wrote:
>> > Le 15/01/2011 11:29, Philipp Kern a écrit :
>> > > Arch:all binNMUing will only work if you keep the invariant of
>> > > version(arch:all) = version(source) in some way.
>> > Why is this needed?
>> If ${source:Version} is not version(arch:all) you've got yourself an
>> uninstallable package.  If ${source:Version} is not version(source)
>> things become slightly confusing.
>
> Only if it is used. However the packages in question _don't_ have
> versioned relations at all:
>
> | Package: libghc6-zip-archive-doc
> | Priority: extra
> | Section: doc
> | Installed-Size: 252
> | Maintainer: Debian Haskell Group 
> 
> | Architecture: all
> | Recommends: ghc6-doc
> | Suggests: libghc6-zip-archive-dev
>
>>Again.  We've had enough of that with
>> ${Source-Version}.  And it'll probably break some other stuff as well.
>
> Well. Who spoke about a change of source:Version at all?
>
> Bastian

Bringing up package relationships raises an interesting point.

If the generated docs don't work with different ghc versions then they
need to depend on the right ghc version, break the wrong version or ghc
needs to break them. I think the best would be a versioned provides
(when will they finally be usable?) like this:

Package: libghc6-zip-archive-doc
Provides: ghc6-docs (x.y)

Package: ghc6
Breaks: ghc6-docs (<< x.y), ghc6-docs (>> x.y)


But having some generated html files depend on the exact ghc version
seems extrem. So splitting out the version dependent .haddoc files into
the -dev packages (as mentioned in another mail in this thread) seems
the right, or at least the sanest, thing to do.

Am I right that with that split the -dev package depends on the right
ghc version (which is needs to anyway) while the -doc remains
independent? And with the -dev package being arch:any the whole issue of
arch:all binNMUs becomes mood?

MfG
Goswin


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

Re: Safe file update library ready (sort of)

[Olaf van der Spek]

On Wed, Jan 26, 2011 at 11:36 AM, Goswin von Brederlow
 wrote:
> I think you are dead wrong there Ian. Even if every single program is
> dead right (and we know a lot aren't) that means every one of them has
> a safe file update function somewhere in it.
>
> A function doing exactly the same thing in many programms. Doesn't that
> just scream for a shared library?

If the kernel supported it properly, it'd be even easier and you
wouldn't have all regressions.
Lacking that, a lib is the next best thing.

> Add to that the number of programs that don't yet do file updates in a
> safe way and need to be fixed I think the project is a verry good
> idea. The unexpected behaviour of ext4 is just a minor implementation
> detail to take care for a general safe update function.

Some instrumentation to detect such unsafe behaviour would be helpful too.

Olaf


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

Re: Safe file update library ready (sort of)

[Goswin von Brederlow]

Adam Borowski  writes:

> On Wed, Jan 26, 2011 at 12:03:52PM +0100, Goswin von Brederlow wrote:
>> Shachar Shemesh  writes:
>> > I've promised to get a library out there, and here it is. The base URL
>> > is https://github.com/Shachar/safewrite, and the actual code is at
>> > https://github.com/Shachar/safewrite/blob/master/safewrite.c
>> 
>> Some things I noticed:
>> 
>> That way one could use
> [..]
>> typedef struct {
>> int fd;
>> char buffer[PATH_MAX];
>> } safe_t;
>
> Except, you can't rely on PATH_MAX on any modern system.  It's defined in
> Linux headers to an arbitrary value to make old code compile, but for
> example Hurd folks decided to not define it altogether to make buggy code
> fail during compilation rather than on runtime.

Right, so

typedef struct { 
int fd; 
char buffer[0];
} safe_t; 

and allocating the struct as big as needed.

MfG
Goswin


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

Re: Bits from the Security Team (for those that care about bits)

[Goswin von Brederlow]

Thijs Kinkhorst  writes:

> * Issues in specific packages
>
> We further discussed some specific problematic packages. One example is
> ia32-libs, which is difficult because it includes 100+ other source
> packages. This will be handled better for Squeeze: we'll have to ensure
> it's as up to date as possible at time of release, and will keep
> updating it in stable point updates to include newer package versions
> from the security archive (or the stable release itself).

A while back I looked into making the detection of security bugs in
ia32-libs (which is all just code duplication of other packages)
automatic. But the config for that detection would have needed 100+
config entries, which would ahve become verry ugly to maintain.

Has there been any change for this?

MfG
Goswin


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

Re: How to build a 32-bit package in Debian?

[Adam Borowski]

On Wed, Jan 26, 2011 at 12:44:02PM +0100, Goswin von Brederlow wrote:
> Adam Borowski  writes:
> > On Mon, Jan 17, 2011 at 11:49:17AM +0800, Paul Wise wrote:
> >> Add lib32 packages for the deps.
> 
> Actually you need ia32-libs-dev and also gcc-multilib when you COMPILE a
> 32bit package. ia32-libs itself is only sufficient for building non-free
> 32bit packages with prebuild binaries.

Aren't ia32-libs on their way out, together with rest of the bi-arch stuff?

> >> Help fix squeeze RC bugs then start work on multi-arch when the wheezy
> >> cycle starts.
> >
> > There's a wonderful thing called "xapt", aka "multi-arch working today". 
> > Sadly, it can't be integrated into build-depends like real multi-arch will
> > be, but getting all libraries you need is a matter of typing:
> >
> > # xapt -a pdp11 liblossage1 liblossage-dev
> 
> Please don't use xapt. That tool is so far purely for use in chroots
> (for pbuilder) and for cross compiling.

Like, building i386 binaries on an amd64?

> It does not handle any dependencies between 32bit libs and the native
> packages.  E.g.  for shared files, conffiles, scripts that need to call
> other binaries.  So using it to execute 32bit binaries will give verry
> poor results.

It seems to work just fine for me, even for completely foreign architectures
with no qemu-user installed (in this case you won't be able to run the
binaries but building works).  Not handling dependencies well means just
that you may have to install them manually.

> The right tool for this would be the old ia32-apt-get

Except, xapt works for all architectures, not just the specific case of i386
on amd64.

> or the revised apt-ma-emu.  Saddly the squeeze freeze hit before
> apt-ma-emu was ready for upload so it won't be in squeeze.

At a glance, it appears to do the same thing as xapt except that it doesn't
require manual selection of packages to install and can do upgrades
automatically.  Which are good things, thanks for telling us about this
tool.  It would be nice to have it in experimental.

xapt is there, apt-ma-emu is not (and I didn't know about it).  The results
are awesome -- example build times:
* native:  115 minutes
* qemu-system: 133 minutes
* distcc:   16 minutes
* xapt: 44 seconds
And that with a build-dependency chain of over 50 packages, of which I had
to specify only those directly depended upon.

The best we can hope for, though, is apt-ma-emu being already obsolete by
wheezy.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110126135203.gc29...@angband.pl

Re: Safe file update library ready (sort of)

[Hendrik Sattler]

Zitat von "Goswin von Brederlow" :


Adam Borowski  writes:


On Wed, Jan 26, 2011 at 12:03:52PM +0100, Goswin von Brederlow wrote:

Shachar Shemesh  writes:
> I've promised to get a library out there, and here it is. The base URL
> is https://github.com/Shachar/safewrite, and the actual code is at
> https://github.com/Shachar/safewrite/blob/master/safewrite.c

Some things I noticed:

That way one could use

[..]

typedef struct {
int fd;
char buffer[PATH_MAX];
} safe_t;


Except, you can't rely on PATH_MAX on any modern system.  It's defined in
Linux headers to an arbitrary value to make old code compile, but for
example Hurd folks decided to not define it altogether to make buggy code
fail during compilation rather than on runtime.


Right, so

typedef struct {
int fd;
char buffer[0];
} safe_t;

and allocating the struct as big as needed.


Maybe don't recommend invalid C? Bad habits don't have to live on forever...

HS


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110126153957.18702pqz49ugq...@v1539.ncsrv.de

Re: binNMU for Arch: all packages.

[Marco Túlio Gontijo e Silva]

Hi Goswin.

Excerpts from Goswin von Brederlow's message of Qua Jan 26 11:28:59 -0200 2011:
(...)
> But having some generated html files depend on the exact ghc version
> seems extrem.

Yes, I don't see the need of adding a Depends: field to -doc packages.

> So splitting out the version dependent .haddoc files into
> the -dev packages (as mentioned in another mail in this thread) seems
> the right, or at least the sanest, thing to do.

This is the current approach, and it's not good, in my opinion, because it
makes the index be created, with broken links.  The .haddock file is used by
ghc6-doc to know which packages should be listed in
/usr/share/doc/ghc6-doc/html/libraries/index.html .  If the -dev package is
installed, but not the -doc, the links for the modules in this package are
listed in this file, but they're broken.

(...)
> And with the -dev package being arch:any the whole issue of
> arch:all binNMUs becomes mood?

There are two issues.  The first one is that the links in the index are not
generated with old .haddock files.  The other one is that new versions of
haddock will produce different HTML files, and it's a good thing to have all
documentation using the latest format haddock produces.

I still think arch:all binNMU would be the exact solution, but I'm thinking
about using sourceful uploads instead, since that seems to cause problems.

Greetings.
(...)


signature.asc
Description: PGP signature

Bug#611189: ITP: libmodule-metadata-perl -- Gather package and POD information from perl module files

[Dominique Dumont]

Package: wnpp
Owner: Dominique Dumont 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libmodule-metadata-perl
  Version : 1.03
  Upstream Author : David Golden , 
Ken Williams , 
  Matt S Trout (mst)  ,
Randy W. Sims 
* URL : http://search.cpan.org/dist/Module-Metadata/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Gather package and POD information from perl module files

Module::Metadata provides routines to gather information about
perl modules, like name, version, list of packages, list of pod sections...

This module is required to update Dist::Zilla::Plugins::CJM

Dominique Dumont
--
http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/
http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201101261614.03467.domi.dum...@free.fr

Re: squeeze will have googleearth-package

[Petter Reinholdtsen]

[Goswin von Brederlow]
> Isn't that a non-issue (for now)?
>
> Here's my reasoning:
>
> 1) The non-free deb is only in apt if non-free is in sources.list.
> 2) AN earlier mail stated that the kernel recommends the non-free
>firmware deb.
> 3) Recommends are to be installed by default.
>
> Shouldn't the non-free firmware deb end up installed just from that?

I'm not sure.  But I know hw-detect discover what file the kernel
module is asking for, and want it to be possible to map from this file
to the package providing this file in an automated matter.

Happy hacking,
-- 
Petter Reinholdtsen


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

Re: Safe file update library ready (sort of)

[Goswin von Brederlow]

"Hendrik Sattler"  writes:

> Zitat von "Goswin von Brederlow" :
>
>> Adam Borowski  writes:
>>
>>> On Wed, Jan 26, 2011 at 12:03:52PM +0100, Goswin von Brederlow wrote:
 Shachar Shemesh  writes:
 > I've promised to get a library out there, and here it is. The base URL
 > is https://github.com/Shachar/safewrite, and the actual code is at
 > https://github.com/Shachar/safewrite/blob/master/safewrite.c

 Some things I noticed:

 That way one could use
>>> [..]
 typedef struct {
 int fd;
 char buffer[PATH_MAX];
 } safe_t;
>>>
>>> Except, you can't rely on PATH_MAX on any modern system.  It's defined in
>>> Linux headers to an arbitrary value to make old code compile, but for
>>> example Hurd folks decided to not define it altogether to make buggy code
>>> fail during compilation rather than on runtime.
>>
>> Right, so
>>
>> typedef struct {
>> int fd;
>> char buffer[0];
>> } safe_t;
>>
>> and allocating the struct as big as needed.
>
> Maybe don't recommend invalid C? Bad habits don't have to live on forever...
>
> HS

Would you use

typedef struct { 
int fd; 
char buffer[];
} safe_t;

or what do you mean by invalid C?

MfG
Goswin


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

Re: Safe file update library ready (sort of)

[Olaf van der Spek]

On Wed, Jan 26, 2011 at 5:09 PM, Goswin von Brederlow  wrote:
> typedef struct {
>        int fd;
>        char buffer[];
> } safe_t;
>
> or what do you mean by invalid C?

Zero length arrays are not valid C AFAIK.
-- 
Olaf


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

Re: Bits from the Security Team (for those that care about bits)

[Michael Gilbert]

On Wed, 26 Jan 2011 14:47:52 +0100, Goswin von Brederlow wrote:
> Thijs Kinkhorst  writes:
> 
> > * Issues in specific packages
> >
> > We further discussed some specific problematic packages. One example is
> > ia32-libs, which is difficult because it includes 100+ other source
> > packages. This will be handled better for Squeeze: we'll have to ensure
> > it's as up to date as possible at time of release, and will keep
> > updating it in stable point updates to include newer package versions
> > from the security archive (or the stable release itself).
> 
> A while back I looked into making the detection of security bugs in
> ia32-libs (which is all just code duplication of other packages)
> automatic. But the config for that detection would have needed 100+
> config entries, which would ahve become verry ugly to maintain.
> 
> Has there been any change for this?

I think it will be easier to just track the issues in the security
tracker manually.  I'm already tracking all of the packages in
ia32-libs as embedded code copies, and I wrote a script that inserts
code copy info into the CVE list automatically.  Anyway, I think this
can be left up to the security team.

Best wishes,
Mike


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

Re: Safe file update library ready (sort of)

[Hendrik Sattler]

Zitat von "Goswin von Brederlow" :


"Hendrik Sattler"  writes:


Zitat von "Goswin von Brederlow" :


Adam Borowski  writes:


On Wed, Jan 26, 2011 at 12:03:52PM +0100, Goswin von Brederlow wrote:

Shachar Shemesh  writes:
> I've promised to get a library out there, and here it is. The base URL
> is https://github.com/Shachar/safewrite, and the actual code is at
> https://github.com/Shachar/safewrite/blob/master/safewrite.c

Some things I noticed:

That way one could use

[..]

typedef struct {
int fd;
char buffer[PATH_MAX];
} safe_t;


Except, you can't rely on PATH_MAX on any modern system.  It's defined in
Linux headers to an arbitrary value to make old code compile, but for
example Hurd folks decided to not define it altogether to make buggy code
fail during compilation rather than on runtime.


Right, so

typedef struct {
int fd;
char buffer[0];
} safe_t;

and allocating the struct as big as needed.


Maybe don't recommend invalid C? Bad habits don't have to live on forever...

HS


Would you use

typedef struct {
int fd;
char buffer[];
} safe_t;

or what do you mean by invalid C?


"char buffer[0];" is veeery gcc-specific as the storage size of buffer  
is 0. According to the C99 standard:

"6.7.5.2 Array declarators
 Constraints
 1 In addition to optional type qualifiers and the keyword static, the [ and
   ] may delimit an expression or *. If they delimit an expression (which
   specifies the size of an array), the expression shall have an integer type.
   If the expression is a constant expression, it shall have a value greater
   than zero."

Either make this "char buffer[1];" and live with the fact that e.g.  
cppcheck will yell at you (better not), or use "safe_t x= ...; char  
*buffer = x + 1;" with or without explicit reference in safe_t (if you  
want to allocate in one block) or simply allocate it seperately.


BTW: KDE4 is a very good example for failure with modern filesystems.  
I regularly loose configuration files when suspend-to-ram fails even  
if the configuration of the running programs were not changed. Yay :-(  
And this is with XFS, not Ext4! Filed a bug a looong time ago in  
KDE BTS. Reaction: none!


HS


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110126173619.185277zxg7ixv...@v1539.ncsrv.de

Re: binNMU for Arch: all packages.

[Ian Jackson]

Marco Túlio Gontijo e Silva writes ("Re: binNMU for Arch: all packages."):
> Excerpts from Goswin von Brederlow's message of Qua Jan 26 11:28:59 -0200 
> 2011:
> (...)
> > But having some generated html files depend on the exact ghc version
> > seems extrem.
> 
> Yes, I don't see the need of adding a Depends: field to -doc packages.

More, it would be quite wrong because it makes perfect sense to
install _just_ the documentation.

If you think having the programs of one version and the docs of a
different version installed is too badly confusing, then the programs
could declare Breaks against the other docs versions.

Ian.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/19776.20754.886051.771...@chiark.greenend.org.uk

Re: Safe file update library ready (sort of)

[Olaf van der Spek]

On Wed, Jan 26, 2011 at 5:36 PM, Hendrik Sattler
 wrote:
> BTW: KDE4 is a very good example for failure with modern filesystems. I
> regularly loose configuration files when suspend-to-ram fails even if the
> configuration of the running programs were not changed. Yay :-( And this is
> with XFS, not Ext4! Filed a bug a looong time ago in KDE BTS. Reaction:
> none!

Maybe complain to the Linux kernel people instead.


-- 
Olaf


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

Re: binNMU for Arch: all packages.

[Goswin von Brederlow]

Marco Túlio Gontijo e Silva  writes:

> Hi Goswin.
>
> Excerpts from Goswin von Brederlow's message of Qua Jan 26 11:28:59 -0200 
> 2011:
> (...)
>> But having some generated html files depend on the exact ghc version
>> seems extrem.
>
> Yes, I don't see the need of adding a Depends: field to -doc packages.
>
>> So splitting out the version dependent .haddoc files into
>> the -dev packages (as mentioned in another mail in this thread) seems
>> the right, or at least the sanest, thing to do.
>
> This is the current approach, and it's not good, in my opinion, because it
> makes the index be created, with broken links.  The .haddock file is used by
> ghc6-doc to know which packages should be listed in
> /usr/share/doc/ghc6-doc/html/libraries/index.html .  If the -dev package is
> installed, but not the -doc, the links for the modules in this package are
> listed in this file, but they're broken.

Then have -dev recommend -doc. Then users get the docs installed by
default and have woking links and autobuilders don't.

Or put the .haddock file somewhere private where ghc6-doc doesn't see it
and put a link into the -doc package that ghc6-doc does see. Then -doc
has to depend on -dev.

> (...)
>> And with the -dev package being arch:any the whole issue of
>> arch:all binNMUs becomes mood?
>
> There are two issues.  The first one is that the links in the index are not
> generated with old .haddock files.  The other one is that new versions of
> haddock will produce different HTML files, and it's a good thing to have all
> documentation using the latest format haddock produces.

I'm hoping the haddock output does not change drsatically on every
upload. On updates where it changes a full sourcefull upload can be done
or arch:all binNMUs. But that would be a rare(r) occurance.

> I still think arch:all binNMU would be the exact solution, but I'm thinking
> about using sourceful uploads instead, since that seems to cause problems.

In a perfect world ...

> Greetings.
> (...)

MfG
Goswin


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

Re: How to build a 32-bit package in Debian?

[Goswin von Brederlow]

Adam Borowski  writes:

> On Wed, Jan 26, 2011 at 12:44:02PM +0100, Goswin von Brederlow wrote:
>> Adam Borowski  writes:
>> > On Mon, Jan 17, 2011 at 11:49:17AM +0800, Paul Wise wrote:
>> >> Add lib32 packages for the deps.
>> 
>> Actually you need ia32-libs-dev and also gcc-multilib when you COMPILE a
>> 32bit package. ia32-libs itself is only sufficient for building non-free
>> 32bit packages with prebuild binaries.
>
> Aren't ia32-libs on their way out, together with rest of the bi-arch stuff?

Since sarge, yes. Nothing is as permanent as a quick temporary hack.

>> >> Help fix squeeze RC bugs then start work on multi-arch when the wheezy
>> >> cycle starts.
>> >
>> > There's a wonderful thing called "xapt", aka "multi-arch working today". 
>> > Sadly, it can't be integrated into build-depends like real multi-arch will
>> > be, but getting all libraries you need is a matter of typing:
>> >
>> > # xapt -a pdp11 liblossage1 liblossage-dev
>> 
>> Please don't use xapt. That tool is so far purely for use in chroots
>> (for pbuilder) and for cross compiling.
>
> Like, building i386 binaries on an amd64?

Yes and no. He wants to build amd64 PACKAGES containing i486-linux-gnu
binaries. With xapt the resulting binary would depend on libc6 instead
of libc6-i386, on libacl1 instead of ia32-libs and so on.

xapt is used when you want to cross build armel packages containing
armel binaries on another arch for later use on armel. That way works.

>> It does not handle any dependencies between 32bit libs and the native
>> packages.  E.g.  for shared files, conffiles, scripts that need to call
>> other binaries.  So using it to execute 32bit binaries will give verry
>> poor results.
>
> It seems to work just fine for me, even for completely foreign architectures
> with no qemu-user installed (in this case you won't be able to run the
> binaries but building works).  Not handling dependencies well means just
> that you may have to install them manually.

And dpkg-shlibdebs outputs the dependencies for the foreign arch and not
the local arch so the resulting debs can be installed on the foreign
arch. Not what he wants.

>> The right tool for this would be the old ia32-apt-get
>
> Except, xapt works for all architectures, not just the specific case of i386
> on amd64.
>
>> or the revised apt-ma-emu.  Saddly the squeeze freeze hit before
>> apt-ma-emu was ready for upload so it won't be in squeeze.
>
> At a glance, it appears to do the same thing as xapt except that it doesn't
> require manual selection of packages to install and can do upgrades
> automatically.  Which are good things, thanks for telling us about this
> tool.  It would be nice to have it in experimental.

It might appear so at a glance and you probably looked at an earlier
version. The differences are quite large though in practice. It tries to
emulate what multiarch will do as much as possible and will phase out
its meddling as packages actualy become truely multiarch.

1) Packages for all configured archs are entered in the apt
database. Apt-get, apt-cache, aptitude, synaptic, ... all see the
packages and their own dependency resolvers do all neccessary work to
install the right packages. Dpkg also sees all packages at once so
dependencies between archs are possible.

2) It knows (heuristically from a conffile) which packages should be
Multi-Arch: same (libraries) and which Multi-Arch: foreign
(binaries). Through that it knows that if something depends on gawk it
will install gawk:amd64 (on amd64) while if a i386 package depends on
libfoo it will install install libfoo:i386.

3) The same works for sources too. A Build-Depends: gawk, libfoo-dev
will install gawk:amd64 and libfoo-dev:armel when asked for the source
for armel.

4) apt-ma-emu allows the installation of binaries (xapt calls dpkg-cross
which removes everything that isn't a library). Maintainer scripts are
also run, esspecially important for binary packages. That allows
installing i386 packages on amd64 and run them (as opposed to installing
libs for cross-compiles).

> xapt is there, apt-ma-emu is not (and I didn't know about it).  The results
> are awesome -- example build times:
> * native:  115 minutes
> * qemu-system: 133 minutes
> * distcc:   16 minutes
> * xapt: 44 seconds
> And that with a build-dependency chain of over 50 packages, of which I had
> to specify only those directly depended upon.

With apt-ma-emu you have: apt-get build-dep -armel (will become
:arch eventually I guess). No need to specify anything
manually.

> The best we can hope for, though, is apt-ma-emu being already obsolete by
> wheezy.

That would indeed be the best. I doubt all packages (don't forget 3rd
party) will be converted to multiarch by then though. The aim of
apt-ma-emu is to seemlesly blend in with multiarch and only handle the
packages that lack behind. I've only tested this with the 6, at last
count, packages in Debian that are multiarch already but results so far
seem promising.

MfG

Re: binNMU for Arch: all packages.

[Joachim Breitner]

Hi,

Am Samstag, den 15.01.2011, 10:29 + schrieb Philipp Kern:
> On 2011-01-15, Marco Túlio Gontijo e Silva  wrote:
> > The best option to fix this issue I can see is if it was possible to do 
> > binNMUs
> > for Arch: all packages.  There are some options to workaround the fact that 
> > we
> > can't binNMUs Arch: all packages, which are: change the -doc package to 
> > Arch:
> > any; do sourceful uploads instead of binNMUs.  Both options are not ideal, 
> > but
> > I prefer the first, because sourceful uploads for a 200 package stack would
> > need a lot of work.
> 
> If the packages are team-maintained, nothing is stopping you from bumping the
> revision with dch and do a build, sign, upload cycle.  Indeed without 
> source-only
> uploads you need to build it once.  But that's scriptable.  (And you can even
> cache the key's passphrase through gpg-agent.)

it would be ok if we were allowed to do "dch; dpkg-buildpackage -d -S;
debrelease". But actually building these 200 package manually on ones
own workmachine, getting the order of building correct, installing
dependencies and so on, without actually changing the package and just
so that they are rebuild is quite a nuisance and thus a slight waste of
developer resources and motivation. The buildds handle this much better
due to BD-Uninstallable and not blocking someones’s laptop. And if there
were autosigning in place (it is not yet, right?), the amount of human
time required would drop to almost zero.

(I know that I’m not actually helping to solve the problem, but I want
to give a better picture of the work involved and how much the buildd
infrastructure is relied upon by the Haskell team – thanks for that!)

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Re: Safe file update library ready (sort of)

[Hendrik Sattler]

Zitat von "Olaf van der Spek" :


On Wed, Jan 26, 2011 at 5:36 PM, Hendrik Sattler
 wrote:

BTW: KDE4 is a very good example for failure with modern filesystems. I
regularly loose configuration files when suspend-to-ram fails even if the
configuration of the running programs were not changed. Yay :-( And this is
with XFS, not Ext4! Filed a bug a looong time ago in KDE BTS. Reaction:
none!


Maybe complain to the Linux kernel people instead.


"suspend-to-ram fails" is the same situation as a sudden power loss.  
In this case, it's not a kernel bug. I don't know how KDE4 handles its  
configuration files but something is wrong there when I loose config  
data without changing any settings in this scenario...


HS




--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110126192542.91195o63nouch...@v1539.ncsrv.de

Bug#611207: ITP: libperl-ostype-perl -- map perl operating system names to generic types

[Nicholas Bamber]

Package: wnpp
Severity: wishlist
Owner: Nicholas Bamber 


* Package name: libperl-ostype-perl
  Version : 1.002
  Upstream Author : David Golden 
* URL : http://search.cpan.org/dist/Perl-OSType/
* License : Perl
  Programming Lang: Perl
  Description : map perl operating system names to generic types

This is needed for the latest version of Module::Build



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110126182940.20740.45160.reportbug@leonhartsberger.periapt

Re: Safe file update library ready (sort of)

[Olaf van der Spek]

On Wed, Jan 26, 2011 at 7:25 PM, Hendrik Sattler
 wrote:
> Zitat von "Olaf van der Spek" :
>
>> On Wed, Jan 26, 2011 at 5:36 PM, Hendrik Sattler
>>  wrote:
>>>
>>> BTW: KDE4 is a very good example for failure with modern filesystems. I
>>> regularly loose configuration files when suspend-to-ram fails even if the
>>> configuration of the running programs were not changed. Yay :-( And this
>>> is
>>> with XFS, not Ext4! Filed a bug a looong time ago in KDE BTS.
>>> Reaction:
>>> none!
>>
>> Maybe complain to the Linux kernel people instead.
>
> "suspend-to-ram fails" is the same situation as a sudden power loss. In this
> case, it's not a kernel bug. I don't know how KDE4 handles its configuration
> files but something is wrong there when I loose config data without changing
> any settings in this scenario...

I know. It's about a(nother) use case for O_ATOMIC, but the kernel
guys prefer workarounds.
-- 
Olaf


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/AANLkTi=+2Dffvgg5=bucrwfy7qrrjuwso-q7awf0w...@mail.gmail.com

Bug#611209: ITP: libcpan-meta-yaml-perl -- Read and write a subset of TAML for cPAN meta files

[Nicholas Bamber]

Package: wnpp
Severity: wishlist
Owner: Nicholas Bamber 


* Package name: libcpan-meta-yaml-perl
  Version : 0.003
  Upstream Author : David Golden 
* URL : http://search.cpan.org/dist/CPAN-Meta-YAML/
* License : Perl
  Programming Lang: Perl
  Description : Read and write a subset of YAML for CPAN meta files

Needed for Module::Build



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110126184923.20771.73692.reportbug@leonhartsberger.periapt

Where does the update-initramfs hook get the kernel name from?

[Philip Ashmore]

Hi there.

I've got a multi-boot system for which I maintain my own (Grub2) grub.cfg.

I've got Debian Lenny, Debian Squeeze and Ubuntu partitions inside an 
encrypted LVM2 logical volume,

a booting nicely.

I just have to watch out if one of them tries to "update" grub.cfg, 
completely trashing it.


Anyway, this puts me under the radar regarding submitting a bug report, 
so here I am, writing this.


I just did an apt-get upgrade in Squeeze and one of the deferred hooks 
failed:

   Processing triggers for initramfs-tools ...
   /boot/initrd.img-26.32.5-amd64.squeeze does not exist. Cannot update.

The initrd image I have for Squeeze is "2.6.32-5-amd64.squeeze" and the 
only way I can update it is to use


   update-initramfs -t -u -v -k 2.6.32-5-amd64

and then rename it.

The grub.cfg entry for Squeeze is

linux   /vmlinuz-2.6.32-5-amd64 root=/dev/mapper/VgCompaq-squeeze 
resume=/dev/mapper/VgCompaq-swap ro quiet vga=0x317 
cryptopts=target=sda4_crypt,source=UUID=41d45178-c0d4-4d8f-a190-1c56b6328318,key=none,rootdev,lvm=VgCompaq-squeeze

initrd  /initrd.img-2.6.32-5-amd64.squeeze

Where does the update-initramfs hook get the kernel name from?

Philip

Bug#611223: ITP: node-expat -- fast XML parser library for Node

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

* Package name: node-expat
  Version : 1.2.0
  Upstream Author : Stephan Maka 
* URL : https://github.com/astro/node-expat
* License : Expat
  Programming Lang: C++
  Description : fast XML parser library for Node

 Node is an event-based server-side JavaScript engine.
 .
 node-expat is a fast XML parser library for Node.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110126221936.15033.272.reportbug@localhost.localdomain

Bug#611224: ITP: node-xmpp -- idiomatic XMPP library for Node

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

* Package name: node-xmpp
  Version : 0.2.3
  Upstream Author : Stephan Maka 
* URL : https://github.com/astro/node-xmpp
* License : GPL-3
  Programming Lang: Node
  Description : idiomatic XMPP library for Node

 Node is an event-based server-side JavaScript engine.
 .
 node-xmpp is an XMPP library for Node.
 .
 Objectives of node-xmpp:
  * Uses Node conventions, especially 'EventEmitter', ie. for write
buffer control.
  * Fast parsing, 'node-expat' was written with this library in mind.
  * Client support for both XMPP clients and components.
  * Optional server infrastructure with 'Router'.
  * After authentication, leave trivial protocol bits to the user (later
we could offer helpers for entity capabilities hashing, etc.).



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/2011012626.15346.37299.reportbug@localhost.localdomain

Re: How to build a 32-bit package in Debian?

[Adam Borowski]

On Wed, Jan 26, 2011 at 06:46:33PM +0100, Goswin von Brederlow wrote:
> Adam Borowski  writes:
> > Aren't ia32-libs on their way out, together with rest of the bi-arch stuff?
> 
> Since sarge, yes. Nothing is as permanent as a quick temporary hack.

With no multiarch on horizon, there wasn't anything to replace them with.
Since the libraries there are all prominent and maintained, it's plausible
transitioning them will be done quickly.

Especially if done in the toolchain rather than individual packages.

> >> or the revised apt-ma-emu.  Saddly the squeeze freeze hit before
> >> apt-ma-emu was ready for upload so it won't be in squeeze.
> >
> > At a glance, it appears to do the same thing as xapt except that it doesn't
> > require manual selection of packages to install and can do upgrades
> > automatically.  Which are good things, thanks for telling us about this
> > tool.  It would be nice to have it in experimental.
> 
> It might appear so at a glance and you probably looked at an earlier
> version. The differences are quite large though in practice. It tries to
> emulate what multiarch will do as much as possible and will phase out
> its meddling as packages actualy become truely multiarch.

Is apt-ma-emu 0.3 supposed to be working already?

It's not in the archive yet, so I wonder whether we should:
a) report bugs to you, or
b) refrain from using it for now

Problem one:
It seemed to work when installing thing needed for binutils/gcc, but now any
attempt to install a cross package results in:

  dpkg: error processing
/var/cache/apt/archives/libpng12-0-armel-cross_1.2.44-1~0.3_amd64.deb
(--unpack): no package information in `/var/lib/dpkg/tmp.ci/control'
configured to not write apport reports
  dpkg: error processing
/var/cache/apt/archives/zlib1g-dev-armel-cross_1%3a1.2.3.4.dfsg-3~0.3_amd64.deb
(--unpack): no package information in `/var/lib/dpkg/tmp.ci/control'
configured to not write apport reports

Problem two:
Cross packages seem to conflict with native ones, even though all are either
libfoo1 or libfoo-dev.  I did not investigate where the problem comes from,
mostly due to 1., it worked ok with xapt.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110126230915.ga6...@angband.pl

Re: squeeze will have googleearth-package

[Ben Hutchings]

On Wed, 2011-01-26 at 12:19 +0100, Goswin von Brederlow wrote:
[...]
> Isn't that a non-issue (for now)?
> 
> Here's my reasoning:
> 
> 1) The non-free deb is only in apt if non-free is in sources.list.
> 2) AN earlier mail stated that the kernel recommends the non-free firmware 
> deb.
[...]

Of course it doesn't, because that would violate policy.

Ben.

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


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

Re: Where does the update-initramfs hook get the kernel name from?

[Ben Hutchings]

On Wed, 2011-01-26 at 19:50 +, Philip Ashmore wrote:
> Hi there.
> 
> I've got a multi-boot system for which I maintain my own (Grub2)
> grub.cfg.
> 
> I've got Debian Lenny, Debian Squeeze and Ubuntu partitions inside an
> encrypted LVM2 logical volume,
> a booting nicely.
> 
> I just have to watch out if one of them tries to "update" grub.cfg,
> completely trashing it.
> 
> Anyway, this puts me under the radar regarding submitting a bug
> report, so here I am, writing this.
[...]
> Where does the update-initramfs hook get the kernel name from?

See .

Ben.

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


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

package testing, autopkgtest, and all that

[Stefano Zacchiroli]

On Mon, Jan 24, 2011 at 12:19:32AM +0100, Iustin Pop wrote:
> First, tests run during a package build are good, but they do not
> ensure, for example, that the package as installed is working OK. I've
> been thinking that (also) providing tests to be run after the package is
> installed (and not on the build results) would be most useful in
> ensuring that both the build process and the packaging is correct. 

We clearly, and badly, need something like that. Going that direction is
the only way we could reasonably claim, in the near future, that we care
about quality in Debian: doing test rebuilds as we do is good, but won't
be enough pretty soon.

Regarding this specific point (tests run on packages as if they were
installed), IIRC Ian Jackson worked a bit on the matter, producing some
code (autopkgtest---as mentioned elsewhere in this thread) and a
specification of the interaction among tests and packages.  Ian: would
you mind summarizing the status of that effort and comment on whether,
in your opinion, people interested on this topic should continue from
there or start over?

Having a specification and some code to run the tests early on in the
Wheezy release cycle would be amazing, as it will enable maintainers to
add tests to their packages during the expected package updates for
Wheezy.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, |  .  |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams


signature.asc
Description: Digital signature

Results of the App Installer Meeting

[Stefano Zacchiroli]

JFYI.

Debian has been represented at the meeting by Enrico Zini (who has
blogged about various aspects of the meeting as well [1,2,3]) and David
Kalnischkies. In the end, quite some pieces of Debian technologies have
attracted interest and are on their way to be part of the proposed
solution. Well done!

Cheers.

[1] http://www.enricozini.org/2011/debian/appinstaller2011/
[2] http://www.enricozini.org/2011/debian/pkgshelf/
[3] http://www.enricozini.org/2011/debian/distromatch/

- Forwarded message from Vincent Untz  -

Date: Wed, 26 Jan 2011 13:57:41 +0100
From: Vincent Untz 
To: distributi...@lists.freedesktop.org
Subject: Results of the App Installer Meeting

Hi all,

The cross-distro App Installer Meeting that was announced a few weeks
ago took place last week. It was a very productive meeting, with people
from Debian, Fedora, Mageia, openSUSE and Ubuntu attending.

We wanted to see how we can collaborate on the creation of a good user
experience for installing applications, and we reached concrete
results: we agreed on an architecture to achieve this, with specific
technologies to be used.

A quick foreword: with this project, the user experience is what matters
to us. This means that our approach is application-centric instead of
being package-centric. We do not want the end users we target here to
have to learn about packages: they already know what an application is,
and this is what they actually care about ("I want Inkscape"). It is in
no way an attempt to kill packages; on the contrary, we'll build on top
of them. But this application-centric focus has several impacts on the
design of the architecture, from the user interface to metadata that we
want to display to users.


Architecture


The overall architecture of the project is described at:
  http://distributions.freedesktop.org/wiki/AppStream/Implementation

We aim for getting a working implementation as soon as possible by
tying together existing projects. The architecture allows different
implementations, though. In particular, there is no reason why other
client implementations shouldn't exist or the data shouldn't be accessed
by the existing, distribution-specific tools.

Here's a very high-level summary:

  + On the client side:
- Use the Ubuntu Software Center as the reference UI (it should be
  possible to implement other UI since everything is open)
- Access apps metadata through xapian
- Access additional metadata through OCS (Open Collaboration
  Services)
- Access screenshots, possibly through screenshots.debian.net (using
  a per-distro proxy) or similar services

  + On the server side:
- Generate apps metadata, based on information coming from upstream
  .desktop files
- Make this metadata (as well as icons and more) available, ideally
  in the distribution repositories, on the mirrors

  + Per-distribution work:
- The tool to generate the apps metadata will possibly be per-distro
- Each distro can decide on some policy wrt OCS:
  . Use a distro-specific server or not
  . Display comments/ratings/screenshots from other distros or not
  . etc.

While we do welcome comments, it's worth pointing out that it's easy to
get stuck on trying to plan the best architecture ever, and we'll avoid
this: this architecture is our plan, and we will implement it :-)


Additional architectural bits
=

There are additional bits that we looked at, but that did not fit into
to overall architecture yet. It is our intention to integrate these
bits, though.

a) Matching packages between distributions
   This may become handy if we want to share data like screenshots,
   comments or ratings. The decision to use such data from other
   distributions should be up to each distribution, but we want to
   enable this possibility.
   This has other uses for the contributor communities, like easily
   browsing patches from other distributions.

b) The Debian tagging system (debtags)
   Tagging applications can help users find the applications they look
   for. The meeting was too short to think about reaching a full
   agreement on this, but there was interest in the debtags system. If
   most distributions are interested in adopting this system, we will
   integrate debtags into the overall architecture.


Where do we go now?
===

To keep us moving, we established a schedule for the development of this
project:
  http://distributions.freedesktop.org/wiki/AppStream/ActionItems

Let me quickly summarize the timeline we're targetting (skipping some
details from the wiki page):

  + April: "Publish metadata / Port UI"
- Publish app metadata as part of the distros repos
- Make this app metadata available via xapian in all distros
- Port Ubuntu Software Center to non-Debian-based systems

  + July: "Integrate non-static metadata"
- Setup OCS servers for distros
- Use OCS from the Application Center

  + November: "Deli

Bug#611236: ITP: ttm -- TeX/LaTeX to HTML converter

[Ian Maclaine-cross]

Package: wnpp
Severity: wishlist
Owner: "Ian Maclaine-cross" 


* Package name: ttm
  Version : 4.01
  Upstream Author : Ian Hutchinson 
* URL : https://tth.svn.sourceforge.net/svnroot/tth/trunk
* License : GPL-2
  Programming Lang: C, lex
  Description : TeX/LaTeX to MathML converter

LaTeX is popular for specifying complex printed documents. TtM
translates Plain TeX or LaTeX documents into MathML. It quickly
produces web documents that are compact, editable and fast viewing.
TtM translates almost all equations instead of converting them into
images. TtM is a sister to TtH in package tth which translates
TeX/LaTeX to HTML.

Both tth and ttm formerly had non-free licenses and complete source
code was unavailable. Version 4.01 was downloaded using:

 $ svn co https://tth.svn.sourceforge.net/svnroot/tth/trunk tth

and made into a tarball on 27th January 2011 at 0:40 UTC using:

 $ tar -cvzf tth_4.01.orig.tar.gz --exclude-vcs tth

by Ian Maclaine-cross . Two Debian packages are
being prepared from the GPL-2 tarball, a revised tth and a new
ttm.

--
Regards,
Ian Maclaine-cross 



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110127042725.10588.24350.report...@thunder.home