Re: dpkg-buildpackage now sets DEB_BUILD_HOST etc for you?

[Neil Williams]

On Fri, 30 Mar 2012 08:06:56 +0200
Raphael Hertzog  wrote:

> On Thu, 29 Mar 2012, Wookey wrote:
> > Well, perhaps I shouldn't (and indeed I'd like us to get to a point
> > where we don't), but currently, in practice, non-native builds need
> > other things setting in the environment anyway so even using
> > dpkg-buildpackage isn't necessarily sufficient, whereas for a native
> > build it always is. 
> 
> OK but this should ideally be integrated in common layers such as
> CDBS and debhelper.

The bits needed for cross-builds vary on a package-by-package basis,
have little in common between packages and are only discovered when
someone tries to cross-build that particular package. The list of
values needed by a package or the ways in which the package can
discover the values it needs can vary between package versions.

Generally, there are two kinds of values:

0: architecture-specific extensions - values which are directly related
to the specific architecture and change between architectures but which
aren't sufficiently "common" or "general" to be provided as the default
for all packages on that architecture. (Indeed, supplying these
values to packages which do not normally check for them can cause
build failures due to side-effects within the ./configure scripts.)
These values are currently provided by dpkg-cross as package-specific
extensions to the list of common values (like the size of an int or
void pointer, endianness etc.) which were always part of dpkg-cross.
[0] These values are typically picked up by the ./configure script and
need to be provided for cross-builds solely because otherwise that
specific package will try to discover the value by compiling something
for the HOST architecture and then executing it, which is fatal for a
cross-build.

1: package-breakage prevention values - things which can go into
debian/rules or as patches to the upstream code to supply or prevent
attempted detection of architecture-neutral values or conditionals
around parts of the package build which need to be done using the build
compiler instead of the cross compiler. These values or conditionals
are the same whatever the HOST architecture, they just differ between
native builds vs cross builds. i.e. these are perfect to go inside the 
ifneq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE)) conditional in
debian/rules.

[0] http://packages.debian.org/sid/all/dpkg-cross/filelist 

So in the second case, it is clear that debian/rules can and should
contain these conditionals and values and the only problem with that is
when the code bit rots because it's not the default build of the
package and the maintainer doesn't get to test that version when
something upstream has changed how it works.

The long term aim for the first case would be for -dev packages to
provide files in a /path/cross.d/$arch/ directory which are generated
during the build of the package for that architecture and which declare
the values which that package had to discover by executing a compiled
test binary. That could be automated, possibly as a "filter" on the full
list of values logged by ./configure. There is a role here for a
debhelper tool.

Both of these changes would be much easier to design, implement, test
and maintain once we have the combination of MultiArch -dev packages and
cross-compilers built by Debian. (Then we could even look at a
cross-piuparts infrastructure to report issues with these mechanisms.)

> > Now if everyone is happy that debian/rules remains the canonical
> > interface even for cross-builds and that they should work without
> > dpkg-buildpackage help then I should start testing on that basis. I
> > have not done that to date. 
> 
> Honestly I have never seen anyone doing cross-builds and calling
> debian/rules manually.

... only because it *always* fails 

I have longed for such support myself at times. It is incredibly
frustrating to see a cross-build fail 90% of the way through and then
be faced within having to run the clean target after putting in a test
fix to an .install file or similar...

Yes, once all the fixes are in, the actual build is done with
dpkg-buildpackage. In the meantime, we do need support to be able to
run individual debian/rules targets within the cross-build environment
and without having to delete everything you've just cross-compiled.

> So while I believe that cross-build should
> not make different assumptions from native builds (i.e. we want to
> converge), I would also not bother testing this explicitly.
> 
> "dpkg-buildpackage -a" is what people are using (and should be using).

For build runs / packages for upload, yes - absolutely. 

For actual development and testing, no.

Just as the buildd infrastructure must rely on dpkg-buildpackage but
maintainers need to be able to run debian/rules targets manually
sometimes. For exactly the same reasons, cross-build maintainers also
need to be able to run specific debian/rules targets sometimes too.
Except we can't and that should be fi

Standard C Library complance test suite

[Peter Miller]

Hi Folks,

I'm looking for a Standard C Library compliance test suite.  I'd prefer
an open source one, preferably with a license more liberal than GPL,
e.g. BSD or MIT, which is why I can't just use the tests in the glibc
sources.

Can anyone suggest projects that I should look at?

-- 
Regards
Peter Miller 
/\/\*http://miller.emu.id.au/pmiller/

PGP public key ID: 1024D/D0EDB64D
fingerprint = AD0A C5DF C426 4F03 5D53  2BDB 18D8 A4E2 D0ED B64D
See http://www.keyserver.net or any PGP keyserver for public key.

"Get the facts first.  You can distort them later." -- Mark Twain


--
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/1333098152.2227.55.camel@hawk

Re: On init in Debian

[Samuel Thibault]

Russ Allbery, le Thu 29 Mar 2012 23:41:40 -0700, a écrit :
> systemd's goal wasn't to become a standard that supported things
> people were already doing.

There must be a misunderstanding somewhere, then, and that needs further
explanation: the feature comparison page produced by Lenhart says
exactly the converse, i.e. that systemd supports a lot of things that
people were already doing (console configuration, socket listening,
etc.).

> The maintenance of systemd is actually quite the opposite of a standard.

That sentence is quite frightening.

> It's focused on being clean, supportable, and fully integrated with Linux
> capabilities, *not* to solving everyone's use case, even to the detriment
> of being universal.

So that directly conflicts with making it a default init implementation.

I have to say I'm now quite a bit lost as to what systemd is supposed to
be.

Samuel


-- 
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/20120330091158.ga4...@type.bordeaux.inria.fr

Re: gconftool

[Thomas Goirand]

On 03/30/2012 03:38 AM, Philipp Kern wrote:
> On Fri, Mar 30, 2012 at 12:13:55AM +0800, Thomas Goirand wrote:
>> On 03/24/2012 07:17 AM, Michael Banck wrote:
>>> This is a development list, please discuss user support issues or
>>> general usage questions on debian-user.
>> I don't see his rant against the gnome settings as
>> a "support issue" or "general usage".
>>
>> By the way, I agree with him about the fact gnome settings
>> are as stupid as the windows registry, and not user friendly
>> at all.
> 
> And what useful contribution should this be to this list?

The point is that we should try to keep things simple,
understandable, and maintainable by most. I agree with that,
but I don't know systemd and can't tell if that's not the case.

Thomas

P.S: Please don't Cc: me.


-- 
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/4f757c04.4000...@goirand.fr

Re: On init in Debian

[Vincent Lefevre]

On 2012-03-29 13:07:56 -0700, Russ Allbery wrote:
> Well, it seems like you should file bugs if you can, because a lot of
> these are not universal problems and therefore probably aren't known
> issues.

I did several months ago:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=637267
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638591

where I provided logs. But no answers for these bugs.

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


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

Re: [OT] NM vs. wicd (was: Re: On init in Debian)

[Vincent Lefevre]

On 2012-03-29 23:23:52 -0400, Chris Knadle wrote:
> On Thursday, March 29, 2012 04:09:57, Vincent Lefevre wrote:
> > Well, wicd has its own bugs, such as preventing a laptop from
> > suspending.
> 
> Hmm.  That sucks.  I'd like to debug why you're running into this.  However  
> I've been using wicd for over two years and never had this problem, but I'm 
> also running a custom-built kernel (and have been for a long time).
> 
> Any idea why wicd would prevent your laptop from suspending?  The best first 
> guess I have is perhaps a bug with the wireless card driver or firmware such 
> that it won't enter the suspend state.

I reported the problem (with wicd and system logs) several months
ago:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=637267

I don't know what's going on exactly, but from the logs, it seems
that when suspending, the connection is ended (as expected), but
then, wicd tries to reconnect, and this may interrupt the suspend.

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


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

Re: On init in Debian

[Vincent Lefevre]

On 2012-03-30 08:39:38 +0200, Salvo Tomaselli wrote:
> > Well, wicd has its own bugs, such as preventing a laptop from
> > suspending.
> are you talking about a bug from 2008 that has been fixed for ages?
> https://bugs.launchpad.net/wicd/+bug/306210

No, this is not the same bug (in my case, wicd is used). It occurred
in August 2011 on an up-to-date Debian/unstable machine.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=637267

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


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

Re: mosh ITP not done, just package name taken over

[Goswin von Brederlow]

Andrei POPESCU  writes:

> On Ma, 27 mar 12, 08:36:58, David Banks wrote:
>> 
>> In the specific case of mosh, I have posted three RFS messages to
>> debian-mentors since filing the ITP, in addition to the creation of the
>> RFS bug after the sponsorship-requests procedure was announced, so the
>> package was certainly being worked on.  However I did not CC the RFS
>> messages to the ITP bug, so they weren't recorded there.  Would this be
>> a recommended practice?  How should it interact with the new
>> sponsorship-requests process?
>
> Block the ITP bug by the RFS bug?
>
> Kind regards,
> Andrei

+1. Since RFS are also bugs that seems to be the natural way to connect
the two.

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/87fwcq9t3o.fsf@frosties.localnet

Re: usefulness of ITPs (Re: mosh ITP not done, just package name taken over)

[Goswin von Brederlow]

Ansgar Burchardt  writes:

> Jean-Christophe Dubacq  writes:
>> What about a dev. script that would be run in debian/ and would parse
>> debian/control and send the ITP? I can write that!

Yes please.

> The Perl group already has a script that does this: examples/get-itp
> in git.debian.org:/git/pkg-perl/scripts.git.  I don't use it myself and
> it might not work that well with non-pkg-perl packages.
>
> Regards,
> Ansgar

Please integrate this with reportbug. It should be possible to report an
ITP with reportbug and have it look up most of the information
automatically in debian/control and debian/copyright.

Even better would be if it supports RFS as well.

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/87bone9swi.fsf@frosties.localnet

Re: Preinstalled package manager(s) for PCs (wheezy)

[Goswin von Brederlow]

Jon Dowland  writes:

> On 27/03/12 17:09, Filipus Klutiero wrote:
>> So what do others think?
>
> I think that we need to separate the notion of a debian desktop from
> the GNOME or KDE desktops.  Synaptic is probably quite rightly not
> part of either, but I agree that a "default desktop" via install
> should provide a GUI package manager.
>
> A Debian "desktop" should be a superset of KDE-desktop | GNOME-desktop
> | LXDE-desktop etc. + things such as a GUI package manager.
>
> I doubt this is something that could be achieved in time for wheezy.

Shouldn't there rather be a base-desktop that both KDE-desktop and
GNOME-desktop depend on? A meta package that depends on everything any
desktop should have.

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/877gy29spe.fsf@frosties.localnet

Re: dpkg-buildpackage now sets DEB_BUILD_HOST etc for you?

[Goswin von Brederlow]

Wookey  writes:

> +++ Raphael Hertzog [2012-03-29 21:06 +0200]:
>> Hi,
>> 
>> On Thu, 29 Mar 2012, Wookey wrote:
>> > Anyone know when this happened and what if any, the limitations are?
>> > It's certainly true in wheezy, squeeze, precise and oineiric. 
>> 
>> This has always been the case ever since dpkg-architecture has been
>> introduced.
>
> OK, shows how much I know :-)
>
>> But you should not rely on this because calling debian/rules directly
>> must be supported.
>
> Hmm, but if a package cannot use the variables set by
> dpkg-buildpackage and must set them itself, what is the point of
> dpkg-buildpackage setting them? To save the package exporting the
> variables?

There is no point. Packages must use dpkg-architecture,
dpkg-buildflags,... or the respective makefile sniplets in
/usr/share/dpkg/ in case debian/rules is called directly, they must not
rely of dpkg-architecture setting them.

Hopefully dpkg-buildpackage will stop setting those varibales at some
point so sources that wrongfully depend on the variables being set
actualy break.

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/87398q9s9g.fsf@frosties.localnet

Re: Preinstalled package manager(s) for PCs (wheezy)

[Jon Dowland]

On Fri, Mar 30, 2012 at 02:30:37PM +0200, Goswin von Brederlow wrote:
> Shouldn't there rather be a base-desktop that both KDE-desktop and
> GNOME-desktop depend on? A meta package that depends on everything any
> desktop should have.

I'm not sure if that's the right direction of dependency, conceptually.

The philosophy of (at least) the GNOME metapackages is (I think: but I
am not (yet) a Debian/GNOME team member) that they provide what upstream
GNOME provides.  So depending on a 'base-desktop' package would work
against that philosophy.

(It might turn out to be the most pragmatic thing to do.)


-- 
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/20120330125146.GL3706@debian

Re: dpkg-buildpackage now sets DEB_BUILD_HOST etc for you?

[Roger Leigh]

On Thu, Mar 29, 2012 at 09:58:41PM +0200, Julien Cristau wrote:
> On Thu, Mar 29, 2012 at 19:10:05 +0100, Wookey wrote:
> 
> > Should a package depending on this behaviour build-dep on a particular
> > dpkg version? As it already works in build-essential in stable do the
> > same rules apply as essential packages in stable (i.e no explicit
> > dependency required)? That would be consistent. Maybe it's been doing
> > it since forever?
> > 
> A package may not depend on this behaviour.  The interface to build a
> package is still debian/rules, not dpkg-buildpackage.

While this might be the formal policy, isn't dpkg-buildpackage the
/de-facto/ interface?  AFAIK we don't actually test that building
via debian/rules alone works, while we do test that building via
dpkg-buildpackage works since this is what most packages build for
upload, and all packages built on the autobuilders, use.

Would there not be some advantage to making dpkg-buildpackge the
interface for building?  (Not dropping the debian/rules interface,
of course.)  This would permit the automatic setting of all the
host- and build-related variables without requiring every package
to also set them by hand.  It would of course still be possible
to build using debian/rules directly, but it wouldn't be required
to set the flags.

Without commenting on whether or not this is a good idea, isn't
this basically the status quo already, given that most packages
don't test direct usage of debian/rules, and manual setting of
the various arch- and build-related variables is inconsistent?


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
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/20120330130833.gj30...@codelibre.net

Re: dpkg-buildpackage now sets DEB_BUILD_HOST etc for you?

[James McCoy]

On Mar 30, 2012 8:40 AM, "Goswin von Brederlow"  wrote:
>
> Hopefully dpkg-buildpackage will stop setting those varibales at some
> point so sources that wrongfully depend on the variables being set
> actualy break.

Already happened in version 1.16.1 (#560070).

Re: dpkg-buildpackage now sets DEB_BUILD_HOST etc for you?

[Raphael Hertzog]

On Fri, 30 Mar 2012, Neil Williams wrote:
> > Honestly I have never seen anyone doing cross-builds and calling
> > debian/rules manually.
> 
> ... only because it *always* fails 
> 
> I have longed for such support myself at times. It is incredibly
> frustrating to see a cross-build fail 90% of the way through and then
> be faced within having to run the clean target after putting in a test
> fix to an .install file or similar...
> 
> Yes, once all the fixes are in, the actual build is done with
> dpkg-buildpackage. In the meantime, we do need support to be able to
> run individual debian/rules targets within the cross-build environment
> and without having to delete everything you've just cross-compiled.

Since Peter Green also said something similar, let me point out that
dpkg-buildpackage has a "-nc" option which avoids "debian/rules clean"
and thus give similar results to calling "debian/rules build" (or binary) 
directly.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/


-- 
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/20120330131334.gh18...@rivendell.home.ouaza.com

Re: dpkg-buildpackage now sets DEB_BUILD_HOST etc for you?

[Wookey]

+++ peter green [2012-03-29 20:06 +0100]:
> >Now, you can build packages without using dpkg-buildpackage by calling
> >rules directly, and in that case the rules file would need to call
> >dpkg-architecture, but someone would have to convince me that that was
> >an interface worth supporting for non-native builds
> The big reason it's worth supporting IMO is that with most packages you
> can "resume" after a failld build by manually running debian/rules
> build. When fixing compile errors in a large package I don't want to
> have to restart the build from scratch after every file I fix.

That is indeed a very useful use case (and the only one I use rules
for directly, apart from 'clean' quite often). 

But it's not hard to do 'dpkg-buildpackage -Tbuild' to get exactly the
same effect but with the dpkg-buildpackage environement set-up done
too. So if we decided that cross-building was only expected to work
via dpkg-buildpackage -a, you wouldn't be unduly inconvenienced,
would you?

Is there some important subtle difference here that I am missing? 

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


-- 
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/20120330130636.gb15...@dream.aleph1.co.uk

Re: On init in Debian

[Tollef Fog Heen]

]] Samuel Thibault 

> > The maintenance of systemd is actually quite the opposite of a standard.
>
> That sentence is quite frightening.

Is it?  It's not like the maintenance of the kernel, KDE or GNOME is
done in the manner you maintain a standard.  Heck, probably just about
no software in Debian is maintained in a manner that would be suitable
for a standard.

> > It's focused on being clean, supportable, and fully integrated with
> > Linux capabilities, *not* to solving everyone's use case, even to
> > the detriment of being universal.
>
> So that directly conflicts with making it a default init
> implementation.

For Linux?  Not particularly.  For non-Linux ports?  Sure.  Nobody has
seriously argued against that.

-- 
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
Archive: http://lists.debian.org/871uoa2om0@qurzaw.varnish-software.com

Re: usefulness of ITPs (Re: mosh ITP not done, just package name taken over)

[Wookey]

+++ Neil Williams [2012-03-26 09:17 +0100]:
> Therefore packaging takes no time at all, it is always fully complete
> before the code itself is even worth evaluating as useful to Debian.
> The packaging is part of my test harness.

You are only looking at this from the upstream's point of view. Most
packaging is someone else's software. And getting it into a
decently-package state can take a _long_ time. I've got one here I've
been working on from time to time for over a year: (first waiting for
upstream to provide a licence, then finding out how to package ocaml
stuff, then waiting for some promised docs - which I eventually wrote
myself after nothing happened for months, and now it's stalled because
something changed in ocaml worlkd and it doesn't build). That's been
about 18 months so far. It _will_ be uploaded very soon. (misery).

I have about 6 other packages here which get attention from time to
time and should eventually reach an uploadable state.

Yes. I should file more ITP bugs and keep them updated, and mostly I
don't bother and may find I wasted my or someone else's time as a
result, but I'm just pointing out why your argument is wrong, due to
taking a narrow, and unrepresentative, viewpoint.

> > > The appropriate thing to do when confronted with a months-old ITP
> > > for a package with the same content or name as your package is almost
> > > certianly to ignore old "intent" and get on with it.
> > 
> > Absolutely disagree. Hijacking the ITP and/or package name without
> > saying a single word about that to the ITP bug thread is just plain
> > rude.
> 
> If an ITP remains open without comment for
> more than a month, the chances that there will ever be an upload to
> close it are close to zero. 

That may be true in an 'averages' sense, but there are old open ITPs
with a lot of work behind them and uploads will eventually arise, if
only because someone takes over that work to finish it off. 

> ITP bugs must not be allowed to block actual work. It's equivalent to
> domain-squatting and just as distasteful.

Yes, sometimes the claim of ownership they imply is too strong, but
it's not domain-squatting, and nor is it distateful. That's a silly
thing to say.

I've found ITPs very useful to find other people who have worked on
stuff, and then used or updated their work (OWFS is a good example,
where I made updated packages and arm packages available for a year or
two before it finally hit the archive).

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


-- 
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/20120330133917.gc15...@dream.aleph1.co.uk

Re: usefulness of ITPs (Re: mosh ITP not done, just package name taken over)

[Jon Dowland]

On Fri, Mar 30, 2012 at 02:39:17PM +0100, Wookey wrote:
> > If an ITP remains open without comment for
> > more than a month, the chances that there will ever be an upload to
> > close it are close to zero. 
> 
> That may be true in an 'averages' sense, but there are old open ITPs
> with a lot of work behind them and uploads will eventually arise, if
> only because someone takes over that work to finish it off. 

I'm actually considering trying to write some UDD queries to answer some
questions about ITPs, such as success rates, average gestation time, etc.; if
anyone has any other particular questions that it might be worth answering,
please let me know.


-- 
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/20120330144714.GA30827@debian

Bug#666410: ITP: sdic-inline-el -- Emacs inline interface for Japanese dictionary

[YOSHIDA Tomohiro]

Package: wnpp
Owner: YOSHIDA Tomohiro 
Severity: wishlist

* Package name: sdic-inline-el
  Version : 0.4.5.1
  Upstream Author : khiker 
* URL or Web page : http://www.emacswiki.org/emacs/sdic-inline.el
* License : GPL3
  Description : Emacs inline interface for Japanese dictionary

The minor-mode for show the meaning of word under the point to minibuffer.



-- 
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/20120331.06.1315138803473231373.tomoh...@sep.email.ne.jp

Re: On init in Debian

[Carlos Alberto Lopez Perez]

On 30/03/12 08:18, Tollef Fog Heen wrote:
> ]] Carlos Alberto Lopez Perez 
> 
>> > On 20/03/12 07:14, Tollef Fog Heen wrote:
>>> > > FWIW, I have a proposal for a GSoC task this year to write a
>>> > > systemd-to-initscript converter,
>>> > > http://wiki.debian.org/SummerOfCode2012/Projects#SysV-init_file_creator_from_systemd_service_files
>>> > > 
>>> > > The systemd service files are covered by the «interface guarantee»,
>>> > > meaning they won't change incompatibly in a future release of systemd,
>>> > > so I think having that as the base format would be fairly reasonable,
>>> > > though probably just a subset so it's portable to other kernels and init
>>> > > systems.
>> > 
>> > And instead of this... why not simply improving metainit to support also
>> > systemd files?
> I doubt you'll get upstreams to write metainit files.  I think we'll
> have upstreams providing systemd files and so I think metainit will
> basically be #15 in http://xkcd.com/927/.

Good point.



What you think about extending this GSoC project to also implement the
translation from systemd unit files to upstart ones? it is worth ?

I am afraid that if everybody switches to systemd only ubuntu will
remain using upstart. And this weird canonical contributor agreement
don't makes thing easier for them

http://thepcspy.com/read/ubuntu-and-the-canonical-contributor-agreement/


Best Regards!

-- 
~~~
Carlos Alberto Lopez Perez   http://neutrino.es
Igalia - Free Software Engineeringhttp://www.igalia.com
~~~



signature.asc
Description: OpenPGP digital signature

Re: On init in Debian

[Russ Allbery]

Samuel Thibault  writes:
> Russ Allbery, le Thu 29 Mar 2012 23:41:40 -0700, a écrit :

>> It's focused on being clean, supportable, and fully integrated with
>> Linux capabilities, *not* to solving everyone's use case, even to the
>> detriment of being universal.

> So that directly conflicts with making it a default init implementation.

On Linux?  Why?

It's not trying to be a *standard*, which would imply that Solaris would
use it, Mac OS X would use it, AIX would use it, NetBSD would use it
But I don't think that being a standard in that way is a horribly
compelling feature that Debian cares about.  It is sort of nice to have
everything use the same init script format, and it used to be that was
kind of, sort of the case, but it's not been true for years.  Solaris is
now using SMF, Mac OS X has its own thing that's completely different,
etc.

For better or worse, there is no standard for init scripts, and neither
systemd nor upstart (nor, for that matter, sysvinit) are really trying to
become that.

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


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

Re: [OT] NM vs. wicd

[Carlos Alberto Lopez Perez]

On 30/03/12 12:29, Vincent Lefevre wrote:
> I don't know what's going on exactly, but from the logs, it seems
> that when suspending, the connection is ended (as expected), but
> then, wicd tries to reconnect, and this may interrupt the suspend.

Check that you don't have GLAN/WLAN or something like that enabled on
/proc/acpi/wakeup

If you have it disable it either with acpitool or simply writing on this
procfile the device name that you want to switch its state.

Note that this settings are reset at reboot, so you will have to write
an init script to set it again.

Regards!

-- 
~~~
Carlos Alberto Lopez Perez   http://neutrino.es
Igalia - Free Software Engineeringhttp://www.igalia.com
~~~



signature.asc
Description: OpenPGP digital signature

Re: On init in Debian

[Russ Allbery]

Vincent Lefevre  writes:
> On 2012-03-29 13:07:56 -0700, Russ Allbery wrote:

>> Well, it seems like you should file bugs if you can, because a lot of
>> these are not universal problems and therefore probably aren't known
>> issues.

> I did several months ago:

>   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=637267

This is the one that no one else who's using wicd seems to be able to
duplicate.  I agree with other people that this is probably something
specific to your hardware.

>   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638591

I don't think your diagnosis of this is correct, in that I don't think
wicd is what's doing this.  I was getting things like that with Network
Manager as well, and usually rebooting my wireless router makes this
behavior stop.  I always wrote this one off to crappy consumer wireless
routers, which have all sorts of strange failure modes when they're not
rebooted regularly.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/878viivva0@windlord.stanford.edu

Re: On init in Debian

[Tollef Fog Heen]

]] Carlos Alberto Lopez Perez 

Hi,

> What you think about extending this GSoC project to also implement the
> translation from systemd unit files to upstart ones? it is worth ?

My interest in translating systemd units to sysvinit scripts is because
it'll enable us to have higher-quality init scripts and enable us to use
systemd as the default, if we so wish, without it impeding our non-Linux
ports.  I'm not particularly interested in making it possible to convert
systemd units to upstart jobs, as it won't help with that goal.

This means I'm not going to invest time in it, but if somebody shows up
with working, tested patches, they'll of course be taken into
consideration.

cheers,
-- 
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
Archive: http://lists.debian.org/87d37t2abr@qurzaw.varnish-software.com

Re: dpkg-buildpackage now sets DEB_BUILD_HOST etc for you?

[Julien Cristau]

On Fri, Mar 30, 2012 at 14:08:33 +0100, Roger Leigh wrote:

> Would there not be some advantage to making dpkg-buildpackge the
> interface for building?  (Not dropping the debian/rules interface,
> of course.)  This would permit the automatic setting of all the
> host- and build-related variables without requiring every package
> to also set them by hand.  It would of course still be possible
> to build using debian/rules directly, but it wouldn't be required
> to set the flags.
> 
I'm not sure how you reconcile "make dpkg-buildpackage the interface for
building" and "not dropping the debian/rules interface".  If you say
packages are allowed to use variables they don't set, then that means
"debian/rules build" is allowed to fail, which would be a pain when
working on a package, and effectively means "dropping the debian/rules
interface" AFAICT.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: usefulness of ITPs (Re: mosh ITP not done, just package name taken over)

[Goswin von Brederlow]

Wookey  writes:

> +++ Neil Williams [2012-03-26 09:17 +0100]:
>> Therefore packaging takes no time at all, it is always fully complete
>> before the code itself is even worth evaluating as useful to Debian.
>> The packaging is part of my test harness.
>
> You are only looking at this from the upstream's point of view. Most
> packaging is someone else's software. And getting it into a

By now it should be clear that packaging takes a variable amount of
time ranging from 0 to month.

Nobody said ITPs are never usefull, far from it.

But are they always usefull? Does a package that is ready for upload
already need an ITP? That is the question.

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/87bond26k3.fsf@frosties.localnet

Re: Preinstalled package manager(s) for PCs (wheezy)

[Goswin von Brederlow]

Jon Dowland  writes:

> On Fri, Mar 30, 2012 at 02:30:37PM +0200, Goswin von Brederlow wrote:
>> Shouldn't there rather be a base-desktop that both KDE-desktop and
>> GNOME-desktop depend on? A meta package that depends on everything any
>> desktop should have.
>
> I'm not sure if that's the right direction of dependency, conceptually.
>
> The philosophy of (at least) the GNOME metapackages is (I think: but I
> am not (yet) a Debian/GNOME team member) that they provide what upstream
> GNOME provides.  So depending on a 'base-desktop' package would work
> against that philosophy.
>
> (It might turn out to be the most pragmatic thing to do.)

Gnome-desktop, not gnome. Gnome-desktop would depend on base-deskop and
gnome and maybe a few more gnome-ish things that aren't in gnome.

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/877gy126hk.fsf@frosties.localnet

Re: On init in Debian

[Samuel Thibault]

Tollef Fog Heen, le Fri 30 Mar 2012 15:40:55 +0200, a écrit :
> > > The maintenance of systemd is actually quite the opposite of a standard.
> >
> > That sentence is quite frightening.
> 
> Is it?  It's not like the maintenance of the kernel, KDE or GNOME is
> done in the manner you maintain a standard.  Heck, probably just about
> no software in Debian is maintained in a manner that would be suitable
> for a standard.

That depends what is meant by "standard". Linux, KDE and Gnome at least
take some care to follow LFS, and define sensible interfaces, with
sensible names, etc. which is part of defining a standard.

> > > It's focused on being clean, supportable, and fully integrated with
> > > Linux capabilities, *not* to solving everyone's use case, even to
> > > the detriment of being universal.
> >
> > So that directly conflicts with making it a default init
> > implementation.
> 
> For Linux?  Not particularly.

If it's *not* for solving everyone's use case, then it's not good for
making it a default init implementation.

> For non-Linux ports?  Sure.  Nobody has seriously argued against that.

I'm not talking about that.

Samuel


-- 
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/20120330221820.gg4...@type.famille.thibault.fr

Re: On init in Debian

[Samuel Thibault]

Russ Allbery, le Fri 30 Mar 2012 10:41:05 -0700, a écrit :
> Samuel Thibault  writes:
> > Russ Allbery, le Thu 29 Mar 2012 23:41:40 -0700, a écrit :
> 
> >> It's focused on being clean, supportable, and fully integrated with
> >> Linux capabilities, *not* to solving everyone's use case, even to the
> >> detriment of being universal.
> 
> > So that directly conflicts with making it a default init implementation.
> 
> On Linux?  Why?
> 
> It's not trying to be a *standard*,

It is apparently trying to be a *Linux* standard, being adopted by all
distributions.  That does mean things which, even if not talking about
unix but just Linux, means you have to take some care, in the same vein
as when you define a Unix standard.

> But I don't think that being a standard in that way is a horribly
> compelling feature that Debian cares about.  It is sort of nice to have
> everything use the same init script format, and it used to be that was
> kind of, sort of the case, but it's not been true for years.

The current init standard boils down to /etc/init.d/foo start/stop, and
it has been true for years. The particular content being another matter.

I'm not saying it was a good standard. The deviation of the content of
the init scripts really is a matter.

> For better or worse, there is no standard for init scripts, and neither
> systemd nor upstart (nor, for that matter, sysvinit) are really trying to
> become that.

If they are to be adopted widely, it'd be better for them to sort of
being one, so that upstreams could ship configuration snippets, instead
of seeing all distributions defining its own ones, bringing small
discrepancies here and there, which can be a pain when going from one to
the other.

Samuel


-- 
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/20120330222417.gh4...@type.famille.thibault.fr

Re: On init in Debian

[David Weinehall]

On Sat, Mar 31, 2012 at 12:18:20AM +0200, Samuel Thibault wrote:
> If it's *not* for solving everyone's use case, then it's not good for
> making it a default init implementation.

You cannot ever solve everyone's use cases.  What systemd (and upstart)
aim to do is to solve all use cases that sysvinit can solve plus a lot
of things that it doesn't (or can't, by design).


Regards: David
-- 
 /) David Weinehall  /) Rime on my window   (\
//  ~   //  Diamond-white roses of fire //
\)  http://www.acc.umu.se/~tao/(/   Beautiful hoar-frost   (/


-- 
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/20120330223324.gh17...@suiko.acc.umu.se

Re: On init in Debian

[Russ Allbery]

Samuel Thibault  writes:

> It is apparently trying to be a *Linux* standard, being adopted by all
> distributions.

That's not at all clear to me.  It seems more to be trying to be a good
init system used by Fedora, and beyond that it's left to people to make up
their own minds, although of course the author thinks it's good and more
people should use it.  Most people like the things they've written.  :)

> The current init standard boils down to /etc/init.d/foo start/stop, and
> it has been true for years. The particular content being another matter.

Which is insufficient to the point of being nearly useless.  Every
UNIX-like system has requirements that go beyond that; an init script that
only honored those options and implemented no other interfaces wouldn't be
usable on just about any environment, including Debian.

All the upstreams that I know of that have to ship init scripts have, even
before upstart and systemd, been shipping separate init scripts for each
OS that they support.  The Red Hat one had chkconfig comments, the Debian
one used start-stop-daemon, the Solaris one then ended up being converted
to SMF, and so forth.  systemd certainly didn't make this any worse.

> If they are to be adopted widely, it'd be better for them to sort of
> being one, so that upstreams could ship configuration snippets, instead
> of seeing all distributions defining its own ones, bringing small
> discrepancies here and there, which can be a pain when going from one to
> the other.

Sure, that would be great.  But that's not the situation now, and hasn't
been the situation for as long as I've been working on UNIX-like systems.
(Before things like LSB started, there were other UNIXes that only did
rc.local, or that didn't use SysV-style priorities, etc.)

My point here is that I think you're putting an unreasonable burden on
init systems by asking them to become a standard.  We effectively have no
standard now, and the init package we're using now certainly doesn't
constitute standard that everyone is using along the lines that you
describe (if nothing else, Fedora is using systemd and Ubuntu is using
upstart!).  It would be great to have a standard, but I don't think it's
very likely that's going to happen, and we still have to decide what init
system we're going to use in the interim.

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


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

Re: [OT] NM vs. wicd

[Vincent Lefevre]

On 2012-03-30 19:43:48 +0200, Carlos Alberto Lopez Perez wrote:
> On 30/03/12 12:29, Vincent Lefevre wrote:
> > I don't know what's going on exactly, but from the logs, it seems
> > that when suspending, the connection is ended (as expected), but
> > then, wicd tries to reconnect, and this may interrupt the suspend.
> 
> Check that you don't have GLAN/WLAN or something like that enabled on
> /proc/acpi/wakeup

xvii:~> cat /proc/acpi/wakeup
Device  S-state   Status   Sysfs node
PCI0  S4*disabled  no-bus:pci:00
PCIE  S4*disabled  pci::00:1e.0
USB1  S0*enabled   pci::00:1d.0
USB2  S0*enabled   pci::00:1d.1
USB3  S0*enabled   pci::00:1d.2
USB4  S0*enabled   pci::00:1a.0
USB5  S0*enabled   pci::00:1a.1
USB6  S0*enabled   pci::00:1a.2
EHC2  S0*enabled   pci::00:1a.7
EHCI  S0*enabled   pci::00:1d.7
AZAL  S3*disabled  pci::00:1b.0
RP01  S4*disabled  pci::00:1c.0
RP02  S4*disabled  pci::00:1c.1
RP03  S4*disabled  pci::00:1c.2
RP04  S3*disabled  
RP05  S3*disabled  
RP06  S5*disabled  
LID   S3*enabled   
PBTN  S4*enabled   

It seems OK.

BTW, if a GLAN/WLAN in /proc/acpi/wakeup were the cause, I suppose
something should be written in the logs, but there were no such
things.

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


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

Re: On init in Debian

[Vincent Lefevre]

On 2012-03-30 10:44:07 -0700, Russ Allbery wrote:
> Vincent Lefevre  writes:
> > On 2012-03-29 13:07:56 -0700, Russ Allbery wrote:
> 
> >> Well, it seems like you should file bugs if you can, because a lot of
> >> these are not universal problems and therefore probably aren't known
> >> issues.
> 
> > I did several months ago:
> 
> >   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=637267
> 
> This is the one that no one else who's using wicd seems to be able to
> duplicate.  I agree with other people that this is probably something
> specific to your hardware.

It could be related to many things (in particular configuration),
but the problem is purely software, as seen in the logs.

> >   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638591
> 
> I don't think your diagnosis of this is correct, in that I don't think
> wicd is what's doing this.  I was getting things like that with Network
> Manager as well, and usually rebooting my wireless router makes this
> behavior stop.  I always wrote this one off to crappy consumer wireless
> routers, which have all sorts of strange failure modes when they're not
> rebooted regularly.

The router may be a bit bad, but the kernel apparently could handle
it, and that's wicd that chose to force the disconnection. So, this
is a 100% wicd bug.

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


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

Re: Standard C Library complance test suite

[John D. Hendrickson and Sara Darnell]

Hi I'm not a DD but ...

I thought on Gnu site if you get and compile the compiler it already has a test suite, for C anyway 
  (i have not tried it personally).


Peter Miller wrote:

Hi Folks,

I'm looking for a Standard C Library compliance test suite.  I'd prefer
an open source one, preferably with a license more liberal than GPL,
e.g. BSD or MIT, which is why I can't just use the tests in the glibc
sources.

Can anyone suggest projects that I should look at?




--
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/4f763ef8.40...@cox.net

Re: On init in Debian

[Vincent Lefevre]

On 2012-03-31 01:16:42 +0200, Vincent Lefevre wrote:
> On 2012-03-30 10:44:07 -0700, Russ Allbery wrote:
> > I don't think your diagnosis of this is correct, in that I don't think
> > wicd is what's doing this.  I was getting things like that with Network
> > Manager as well, and usually rebooting my wireless router makes this
> > behavior stop.  I always wrote this one off to crappy consumer wireless
> > routers, which have all sorts of strange failure modes when they're not
> > rebooted regularly.
> 
> The router may be a bit bad, but the kernel apparently could handle
> it, and that's wicd that chose to force the disconnection. So, this
> is a 100% wicd bug.

and I use a Nokia N900 with the same modem-router every day, and
I've never had such a disconnection problem with it.

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


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

Re: Standard C Library complance test suite

[Jonathan Yu]

Hi,

On Fri, Mar 30, 2012 at 7:17 PM, John D. Hendrickson and Sara Darnell <
johnandsa...@cox.net> wrote:

> I thought on Gnu site if you get and compile the compiler it already has a
> test suite, for C anyway   (i have not tried it personally).
>

He mentions in the message that he's looking for one with a more liberal
license than GPL, so this seems like a no go.

Re: [OT] NM vs. wicd

[Carlos Alberto Lopez Perez]

On 31/03/12 01:03, Vincent Lefevre wrote:
> On 2012-03-30 19:43:48 +0200, Carlos Alberto Lopez Perez wrote:
>> On 30/03/12 12:29, Vincent Lefevre wrote:
>>> I don't know what's going on exactly, but from the logs, it seems
>>> that when suspending, the connection is ended (as expected), but
>>> then, wicd tries to reconnect, and this may interrupt the suspend.
>>
>> Check that you don't have GLAN/WLAN or something like that enabled on
>> /proc/acpi/wakeup
> 
> xvii:~> cat /proc/acpi/wakeup
> Device  S-state   Status   Sysfs node
> PCI0  S4*disabled  no-bus:pci:00
> PCIE  S4*disabled  pci::00:1e.0
> USB1  S0*enabled   pci::00:1d.0
> USB2  S0*enabled   pci::00:1d.1
> USB3  S0*enabled   pci::00:1d.2
> USB4  S0*enabled   pci::00:1a.0
> USB5  S0*enabled   pci::00:1a.1
> USB6  S0*enabled   pci::00:1a.2
> EHC2  S0*enabled   pci::00:1a.7
> EHCI  S0*enabled   pci::00:1d.7
> AZAL  S3*disabled  pci::00:1b.0
> RP01  S4*disabled  pci::00:1c.0
> RP02  S4*disabled  pci::00:1c.1
> RP03  S4*disabled  pci::00:1c.2
> RP04  S3*disabled  
> RP05  S3*disabled  
> RP06  S5*disabled  
> LID   S3*enabled   
> PBTN  S4*enabled   
> 
> It seems OK.
> 
> BTW, if a GLAN/WLAN in /proc/acpi/wakeup were the cause, I suppose
> something should be written in the logs, but there were no such
> things.
> 

Try to disable everything except PBTN (power button) and check if this
solves your problem.

I had problems with my laptop also waking up mysteriously randomly on
unknown events and I managed to solve it just disabling all wakeup
events except PBTN



-- 
~~~
Carlos Alberto Lopez Perez   http://neutrino.es
Igalia - Free Software Engineeringhttp://www.igalia.com
~~~



signature.asc
Description: OpenPGP digital signature

Bug#666490: O: svgalib -- console SVGA display libraries

[Guillem Jover]

Package: wnpp
Severity: normal

I've just orphaned svgalib by uploading 1.4.x and 1.9.x packages with
pending changes to unstable and experimental. I recently contacted
upstream to send patches back, but was offered taking over upstream
maintainership instead because he is not interested in it anymore,
and while I've never considered this an issue, right now I cannot be
bothered spending that time maintaining this for Debian...

Whoever takes this, should ideally have at least notions of low-level
graphics programming, x86 assembler and shared libraries.

Also during my maintainership, got the packages to build from just
i386 to linux-any and kfreebsd-any, but there's still reverse
depedencies which only build for i386 or i386 and amd64. The new
maintainer might want to handle such transition, which might also
require taking a look at Packages-arch-specific.


The package description is:
 svgalib provides graphics capabilities to programs running on the
 system console, without going through the X Window System. It uses
 direct access to the video hardware to provide low-level access to
 the standard VGA and SVGA graphics modes. Only works with some
 video hardware; use with caution.
 .
 This package contains the shared libraries and config files.


regards,
guillem



-- 
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/2012033104.ga16...@gaara.hadrons.org

Re: Standard C Library complance test suite

[Peter Miller]

On Fri, 2012-03-30 at 20:02 +1100, Peter Miller wrote:
> I'm looking for a Standard C Library compliance test suite.  I'd prefer
> an open source one, preferably with a license more liberal than GPL,
> e.g. BSD or MIT, which is why I can't just use the tests in the glibc
> sources.

newlib, used by Cygwin, has a test suite, and is liberally licensed.
It is neither systematic nor comprehensive (much less than 10%
coverage).


-- 
Regards
Peter Miller 
/\/\*http://miller.emu.id.au/pmiller/

PGP public key ID: 1024D/D0EDB64D
fingerprint = AD0A C5DF C426 4F03 5D53  2BDB 18D8 A4E2 D0ED B64D
See http://www.keyserver.net or any PGP keyserver for public key.

"No matter how slick the demo is in rehearsal, when you do it in front
of a live audience the probability of a flawless presentation is
inversely proportional to the number of people watching, raised to the
power of the amount of money involved." -- Mark Gibbs


--
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/1333171445.2227.64.camel@hawk