Symbol files and C++ name mangling

[Michael Tautschnig]

Hi all,

I just added a symbols control file to the latest upload of the diagnostics
library. I started out with a single libdiagnostics0.symbols file, which caused
an FTBFS on all archs [0]. So we all know that C++ name mangling has its
downsides, but in this case it becomes a real PITA. Though, it is questionable
whether C++ name mangling is the issue, or symbol files are just broken by
design. Obviously I will now create arch-specific symbol files, but what if we
ever add a new symbol to diagnostics? Quite likely, things will FTBFS once
again.

Of course, I could add some wildcard, but this renders symbol files more or less
useless.

Michael.

[0] http://buildd.debian.org/build.php?pkg=diagnostics



pgpJApuG8n5pX.pgp
Description: PGP signature

Re: Pls help me

[Paul Wise]

On Sun, Jul 20, 2008 at 2:15 PM, Jithesh Chandran
<[EMAIL PROTECTED]> wrote:

> My acer aspire 5310 notebook doesn't perform good with the debian os..

You have emailed the Debian development list, if you are looking for
support, please read this page:

http://www.debian.org/support

In short, contact one of these:

irc://irc.debian.org/debian
http://forums.debian.net/
http://lists.debian.org/debian-user/

Also try searching the web:

http://www.google.com/search?q=debian+acer+aspire+5310

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [Pkg-xen-devel] Xen status in lenny?

[Aurelien Jarno]

Goswin von Brederlow a écrit :
> Gunnar Wolf <[EMAIL PROTECTED]> writes:
> 
>> Goswin von Brederlow dijo [Tue, Jul 15, 2008 at 11:10:30PM +0200]:
 I don't think that any of the alternatives are valid candidates yet:
 - Linux-Vserver, OpenVZ: clearly not the same use case.
 - Virtualbox, qemu: poor performance under some workloads.
>>> Unusable for production work. Emulation is just too slow. The group of
>>> people that can live with that much slow down compared to xen is
>>> miniscule.
>> Just to state the obvious: I understand your lines applie to
>> virtualbox and qemu, not to linux-vserver, which is completely usable
>> for production work - although it's a completely different approach,
>> completely useless to people who really want seemingly independent
>> full machines (i.e. different OSs or kernel features). 
> 
> yes, obviously. :)
> 
 - KVM: is very promising but is it really a valid alternative *now*
   for current Xen users?
>>> KVM needs hardware support and even then its I/O is slower. It also
>>> deadlocks the I/O under I/O load from time to time.
>>>
>>> I could live with the I/O slowdown but nothing will make hardware
>>> magically appear.
>> Please explain further on this. Do you mean that xen can run
>> paravirtualized hosts without the hardware features (i.e. the lesser
>> CPUs sold nowadays) while kvm does require VMX/SVM?
> 
> Yes, xen with paravirtualized hosts runs on cpus without hardware
> virtualization.
> 
>> I have not done extensive testing yet (I'm a newbie to both
>> approaches), but I don't feel the slowdown you mention when under kvm.
> 
> The "normal" kvm io uses the qemu device emulation and is dead slow
> and unsecure. As such it is pretty much out of the question for
> production work.
> 
> But kvm can also use the virtio drivers that raise the network speed
> to slightly over 40MB/s. Disk speed is slower but that might just be
> my laptops disk.

With latest kvm version (71), I am able to reach 174 MB/s throughput on
the virtio network interface, so it is now comparable to Xen.

> Now with xen on the other hand I get up to 180MB/s throughput on the
> network interface.
> 
>> Greetings,
> 
> MfG
> Goswin
> 
> 


-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Symbol files and C++ name mangling

[Raphael Hertzog]

On Sun, 20 Jul 2008, Michael Tautschnig wrote:
> I just added a symbols control file to the latest upload of the diagnostics
> library. I started out with a single libdiagnostics0.symbols file, which 
> caused
> an FTBFS on all archs [0]. So we all know that C++ name mangling has its
> downsides, but in this case it becomes a real PITA. Though, it is questionable
> whether C++ name mangling is the issue, or symbol files are just broken by
> design. Obviously I will now create arch-specific symbol files, but what if we
> ever add a new symbol to diagnostics? Quite likely, things will FTBFS once
> again.

It's the job of the maintainer to maintain the symbols files, if you don't
accept it (with all its complexity in your case), just don't use symbols
files.

But to correct you: newly added symbols do _not_ generate FTFBS by default
(though they will generate a lintian warning), only removed symbols result
in a FTBFS by default.

If new symbols appear, just add the new symbols to your symbols file. The
rules for symbol mangling depend on the architecture but they are "fixed"
for each architecture so one could write an helper script to update all
the symbols file.

And FYI, I have worked in the open with several rounds of review on -devel
when I developed the symbols files. The limitation of symbols in C++
binaries were exposed but I haven't had any concrete suggestion on how to
handle them better.

> Of course, I could add some wildcard, but this renders symbol files more or 
> less
> useless.

Wildcards are only meant for libraries using properly symbol versioning.
Using them as a catchup for possible future new symbols is WRONG.

Cheers,
-- 
Raphaël Hertzog

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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

glib inconsistencies in testing

[Frank Küster]

Hi,

since a couple of days ago, I keep getting this message on a lenny
system during the configure phase of (seemingly) arbitrary packages:

Setting up samba-common (2:3.0.31-1) ...
*** This build of Glib was compiled with glib 2.16.4, but is currently running 
with 2.16.3, which is too old.  We'll continue, but expect problems!

 findpkg -b -r -v libglib2.0-0

* unstable *

Package: libglib2.0-0
Version: 2.16.4-2
Package: libglib2.0-0-dbg
Version: 2.16.4-2

* testing *

Package: libglib2.0-0
Version: 2.16.3-2
Package: libglib2.0-0-dbg
Version: 2.16.3-2

It seems like some package which is frequently used in postinsts
declares insufficiently strict dependencies on libglib.  Before I start
playing around with postinst scripts, is this issue known and reported?

Regards, Frank


-- 
Frank Küster
Debian Developer (teTeX/TeXLive)


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: FHS and /var/www

[Carl Fürstenberg]

On Sun, Jul 20, 2008 at 08:58, Tollef Fog Heen <[EMAIL PROTECTED]> wrote:
> ]] Ben Finney
>
> | We could deal with this as we did for '/usr/share/doc' vs '/usr/doc';
> | that is, make '/srv/www/foo' the canonical location but allow a long
> | transition period where '/var/www/foo' is permitted as a symlink to
> | '/srv/www/foo'.
>
> You can't know the structure of /srv, see the FHS rationale:
>
>  The methodology used to name subdirectories of /srv is unspecified
>  as there is currently no consensus on how this should be done. One
>  method for structuring data under /srv is by protocol, eg. ftp,
>  rsync, www, and cvs. On large systems it can be useful to structure
>  /srv by administrative context, such as /srv/physics/www,
>  /srv/compsci/cvs, etc. This setup will differ from host to
>  host. Therefore, no program should rely on a specific subdirectory
>  structure of /srv existing or data necessarily being stored in
>  /srv. However /srv should always exist on FHS compliant systems and
>  should be used as the default location for such data.
>
> As long as the structure is unspecified, it is just about impossible
> to me to have a sane default pointing to anywhere in /srv (except
> directly at /srv itself) as that directory might very well not exist.
> I would argue shipping a /srv/www is a bug if the site does not use
> that layout.
>
> --
> Tollef Fog Heen
> UNIX is user friendly, it's just picky about who its friends are
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>
>

I just noticed in section 10.5 that /var/www should be used, so I have
filed an bug against the policy that 10.5 contradicts 9.1.


-- 
/Carl Fürstenberg <[EMAIL PROTECTED]>

Re: x11proto-core 7.0.13 will break Tk

[Florian Weimer]

* Sergei Golovan:

> Certainly affected packages are tk8.3, tk8.4, tk8.5, blt, tile. Also
> perl-tk and ruby are likely to break after possible upgrade of
> x11proto-core. (May be other packages which use Tk.)

What about statically-linked, proprietary applications?  Why hasn't this
happened in the past?

(I'm not saying that we should care much about proprietary apps, I'm
just trying to understand what's going on.)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: FHS and /var/www

[Charles Plessy]

Le Sun, Jul 20, 2008 at 01:43:12AM +0200, Carl Fürstenberg a écrit :
> FHS 2.3 specifies in
> http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM
> to use /srv for "Data for services provided by this system", for
> example /srv/www for web root.
> In the policy, the section
> 9.1.1(http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1.1)
> specifies that FHS 2.3 is mandatory, except for some exception, and
> the use of /var/www isn't included in that list.
> 
> Should we force all httpd:s to use /srv/www instead of /var/www, or
> should an exception to the policy be added? Per
> http://wiki.debian.org/Apache2LennyGoals it states that apache2 has
> support for /srv/www, but it's still defaulting to /var/www.

Hi Carl,

I think that there is an confusion between where the web servers that
are packaged for Debian should look for the sites to serve, and where
the sites packaged for Debian should install their files.

Be it /var/www or /srv/www, nothing guarantees that a package shipping a
file in these directories will not conflict with local data, similarly
to /usr/local: the local administrator may have already placed a file
with as similar name, which would make the package uninstallable. In
contrary, the local administrator is not supposed to add anything that
does not come from a package in /usr/share nor /usr/lib.

For this reason, packages containing websites should use paths such as
/usr/lib/cgi-bin and /usr/share/package for their files.

Of course, this complexifies the task for the packager, as the http
daemons will not look by default in /usr/share/package. Definitely, some
code factorisation for registering the files and reload the
configuration would be most welcome. Maybe it could be some kind of goal
for Lenny+1?

Have a nice day,

-- 
Charles Plessy
Debian-Med packaging team,
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Good communication with upstream is good idea

[Osamu Aoki]

Hi,

I found some of my packages are offered as a part of Ubuntu archive.
(Practically copied with minor adjustment.) That is good but I felt a
bit strange since I needed to use my time to find it out.

Then, I realized I am no better than the Ubuntu MOTU developers on how to
deal with upstream as Debian Developer.

I think we should encourage packager to contact upstream with simple
"hello!" message and he (or myself) should be part of active upstream ML.

After all, we all are human.  Friendly "hello" always helps people.

I know this is not something we need to have as policy but as a part of
best practice document, it is good to mention.  For Debian, "Developers
Reference".  If I miss it in "Developers Reference", I am sorry.

I also appreciate Ubuntu MOTU developers who port Debian packages to do
the same. (Or Ubuntu employees to encourage such action to their
volunteer.)

For Debian, please continue discussion on Debian list.  If you think
this is valid and have good English skill, please propose patch to
Developers reference.

For Ubuntu, please continue discussion on Ubuntu list while you may CC
me since I do not subscribe to it.

Please, do not flame.  That is not my intension of this posting.  Just a
thought and suggestion to improve human relations in general.

Osamu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: x11proto-core 7.0.13 will break Tk

[Sergei Golovan]

On 7/20/08, Florian Weimer <[EMAIL PROTECTED]> wrote:
> * Sergei Golovan:
>
>  > Certainly affected packages are tk8.3, tk8.4, tk8.5, blt, tile. Also
>  > perl-tk and ruby are likely to break after possible upgrade of
>  > x11proto-core. (May be other packages which use Tk.)
>
>
> What about statically-linked, proprietary applications?  Why hasn't this
>  happened in the past?

Tk adds its own X event numbers to a table of events. And puts it just
after the last existing event (the following is an excerpt from tk.h):

/*
 *---
 *
 * Extensions to the X event set
 *
 *---
 */
#define VirtualEvent(LASTEvent)
#define ActivateNotify  (LASTEvent + 1)
#define DeactivateNotify(LASTEvent + 2)
#define MouseWheelEvent (LASTEvent + 3)
#define TK_LASTEVENT(LASTEvent + 4)

#define MouseWheelMask  (1L << 28)

#define ActivateMask(1L << 29)
#define VirtualEventMask(1L << 30)
#define TK_LASTEVENT(LASTEvent + 4)

It looks that until the last month there were exactly 35 events
(LASTEvent equals 35), so the Tk core library, all extensions linked
to it (which use event numbers directly) and all statically linked
propriatory binaries were binary compatible.

Now X people have added another event number (GenericEvent), which
means that in the former excerpt LASTEvent changes to 36. So, if two
extensions use the same tk.h but different x11proto-core versions
(7.0.12 and 7.0.13) they will not be binary compatible. Statically
linked proprietory binaries should be fine if they never receive
GenericEvent from X (I'm not an expert, so I realy don't know if its
possible to receive X event if an application doesn't know about it).

-- 
Sergei Golovan


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: FHS and /var/www

[Stephen Gran]

This one time, at band camp, Carl Fürstenberg said:
> FHS 2.3 specifies in
> http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM
> to use /srv for "Data for services provided by this system", for
> example /srv/www for web root.
> In the policy, the section
> 9.1.1(http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1.1)
> specifies that FHS 2.3 is mandatory, except for some exception, and
> the use of /var/www isn't included in that list.
> 
> Should we force all httpd:s to use /srv/www instead of /var/www, or
> should an exception to the policy be added? Per
> http://wiki.debian.org/Apache2LennyGoals it states that apache2 has
> support for /srv/www, but it's still defaulting to /var/www.

Please no.  The layout of /srv/ is specifically said to be undetermined,
so we can't actually rely on any paths in /srv/.  I think the current
setup is fairly good, actually - by default simple site layouts work out
of the box, and don't interfere with more complicated setups that are
free to use arbitrary hierarchies in /srv.

Cheers,
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: glib inconsistencies in testing

[Steve Langasek]

On Sun, Jul 20, 2008 at 12:41:34PM +0200, Frank Küster wrote:

> since a couple of days ago, I keep getting this message on a lenny
> system during the configure phase of (seemingly) arbitrary packages:

> Setting up samba-common (2:3.0.31-1) ...
> *** This build of Glib was compiled with glib 2.16.4, but is currently
> running with 2.16.3, which is too old.  We'll continue, but expect
> problems!

If you're seeing this from samba-common, the culprit will have to be
debconf (-> libglib-perl).

> It seems like some package which is frequently used in postinsts
> declares insufficiently strict dependencies on libglib.  Before I start
> playing around with postinst scripts, is this issue known and reported?

Actually, the bug is that libglib-perl is second-guessing glib's package
dependencies and spitting out warnings that it shouldn't.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: glib inconsistencies in testing

[Frank Küster]

Steve Langasek <[EMAIL PROTECTED]> wrote:

> Actually, the bug is that libglib-perl is second-guessing glib's package
> dependencies and spitting out warnings that it shouldn't.

And it's already reported?

Thanks, Frank

-- 
Frank Küster
Debian Developer (teTeX/TeXLive)


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Good communication with upstream is good idea

[Florian Weimer]

* Osamu Aoki:

> I found some of my packages are offered as a part of Ubuntu archive.

Same here.  In my case (debsecan), it's a bit irresponsible because the
package doesn't really work on Ubuntu--but it's not readily apparent to
potential users.  Furthermore, it uses server resources provided to
Debian, and not to Ubuntu.

What's the correct way to get it out of Unbuntu (universe)?  I don't
want to relicense it, but if asking politely does not work, it seems to
be my only choice.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Good communication with upstream is good idea

[Scott Kitterman]

On Sunday 20 July 2008 12:05, Florian Weimer wrote:
> * Osamu Aoki:
> > I found some of my packages are offered as a part of Ubuntu archive.
>
> Same here.  In my case (debsecan), it's a bit irresponsible because the
> package doesn't really work on Ubuntu--but it's not readily apparent to
> potential users.  Furthermore, it uses server resources provided to
> Debian, and not to Ubuntu.
>
> What's the correct way to get it out of Unbuntu (universe)?  I don't
> want to relicense it, but if asking politely does not work, it seems to
> be my only choice.

The preferred way of 'asking politely' is a removal bug.  The process is 
described here:

https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive?highlight=%28archive%29#head-6a4a4d2ad0cc004c6199f465539e3bbc2239291e

or if you don't want to unwrap the long URL:

http://preview.tinyurl.com/5ce4jk

Other than reading the pacakge description just now, I'm not familiar with the 
package.  Would it make more sense for someone in Ubuntu to adapt the package 
to work in the Ubuntu context than to remove it?  It looks like it would be 
useful there too.

Scott K


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Good communication with upstream is good idea

[Joey Hess]

Osamu Aoki wrote:
> I think we should encourage packager to contact upstream with simple
> "hello!" message and he (or myself) should be part of active upstream ML.

When I had upstreams, I always used to do this.

Often though, I'd wait until I had some patches to go with the "hello",
to make the message have a bit more value.

-- 
see shy jo, downstream from noone


signature.asc
Description: Digital signature

Re: Good communication with upstream is good idea

[Neil Williams]

On Sun, 2008-07-20 at 18:05 +0200, Florian Weimer wrote:
> * Osamu Aoki:
> 
> > I found some of my packages are offered as a part of Ubuntu archive.

Have you found any that are not?

> Same here.  In my case (debsecan), it's a bit irresponsible because the
> package doesn't really work on Ubuntu--but it's not readily apparent to
> potential users.  Furthermore, it uses server resources provided to
> Debian, and not to Ubuntu.
> 
> What's the correct way to get it out of Unbuntu (universe)?  I don't
> want to relicense it, but if asking politely does not work, it seems to
> be my only choice.

How would you relicence it in a manner that prevents use in Ubuntu but
retains DFSG compatibility to remain in Debian main?

Trying to ban Ubuntu usage would, AFAICT, fall foul of "discrimination
against fields of endeavour".

I ask because emdebian-tools isn't intended for Ubuntu either. See [0] -
emdebian-tools also depends on server resources provided only by Debian
(in this case, the package repositories containing compatible packages
which I can use to generate cross-dependencies).

"emdebian-tools is not intended for Ubuntu but I don't have a way of
encoding that in the package. emdebian-tools is tightly integrated into
Debian (and Debian unstable in particular) and is, naturally, a Debian
native package (it was written to support Embedded Debian after all, not
UbuntuMobile). It isn't intended to work on Ubuntu because Ubuntu does
not provide the foreign packages needed for linking when cross building,
those come exclusively from Debian. Same with apt-cross, it is
exclusively designed for Debian, Debian mirrors and Debian buildd
configurations. How is emdebian-tools meant to cross-build for ARM on
Ubuntu when Ubuntu does not provide ARM packages and makes changes to
the equivalent Debian packages? To me it seems highly unlikely that
cross versions of Debian packages would install over a Ubuntu base,
especially when those packages are the typical debootstrap selection
that have a variety of changes in Ubuntu. I don't run Ubuntu, I have no
inclination to test for Ubuntu and as no-one else has offered, I cannot
support Ubuntu."

How many packages could be in this situation? I don't expect it to be
many. Some form of filter on the Ubuntu side may be necessary.
Alternatively, is there a package that I can list in Conflicts: that is
only present in Debian derivatives? Yes, any mechanism could be abused
but MOTU-people could always file bugs in the BTS about such usage.

[0] 
http://www.linux.codehelp.co.uk/serendipity/index.php?/archives/122-Migrating-Emdebian-changes-into-Debian,-not-Ubuntu.html

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/




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

Re: Good communication with upstream is good idea

[Caroline Ford]

2008/7/20 Florian Weimer <[EMAIL PROTECTED]>:
> * Osamu Aoki:
>
>> I found some of my packages are offered as a part of Ubuntu archive.
>
> Same here.  In my case (debsecan), it's a bit irresponsible because the
> package doesn't really work on Ubuntu--but it's not readily apparent to
> potential users.  Furthermore, it uses server resources provided to
> Debian, and not to Ubuntu.
>
> What's the correct way to get it out of Unbuntu (universe)?  I don't
> want to relicense it, but if asking politely does not work, it seems to
> be my only choice.

Packages are automatically synced from Debian as part of the
development process, if a package doesn't want to be in Ubuntu then as
far as I know there needs to be a manual override set up.

Relicensing your software to stop other people redistributing seems
like overkill to be honest, and no doubt would cause your package to
break the Debian Free Software Guidelines. You can't release under a
free license and keep 100% control over redistribution!

Caroline


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Good communication with upstream is good idea

[Florian Weimer]

* Neil Williams:

>> What's the correct way to get it out of Unbuntu (universe)?  I don't
>> want to relicense it, but if asking politely does not work, it seems to
>> be my only choice.
>
> How would you relicence it in a manner that prevents use in Ubuntu but
> retains DFSG compatibility to remain in Debian main?

Relicensing would involve moving the package to non-free, that's
correct.  I could try some trademark stunt, but I don't want to spend
any money on a trademark registration.

I don't see why such cases (including yours) can't be resolved amicably.
It's not rocket science, after all.

> How many packages could be in this situation? I don't expect it to be
> many. Some form of filter on the Ubuntu side may be necessary.
> Alternatively, is there a package that I can list in Conflicts: that is
> only present in Debian derivatives? Yes, any mechanism could be abused
> but MOTU-people could always file bugs in the BTS about such usage.

MOTU bugs should end up in the Canonical bug tracker.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Good communication with upstream is good idea

[Bernhard R. Link]

* Osamu Aoki <[EMAIL PROTECTED]> [080720 14:57]:
> I think we should encourage packager to contact upstream with simple
> "hello!" message and he (or myself) should be part of active upstream ML.
>
> After all, we all are human.  Friendly "hello" always helps people.
>
> I know this is not something we need to have as policy but as a part of
> best practice document, it is good to mention.  For Debian, "Developers
> Reference".  If I miss it in "Developers Reference", I am sorry.

Developers' Reference has only
http://www.debian.org/doc/developers-reference/developer-duties.html#upstream-coordination
but I guess saying hello is already implied in the title "Coordination with
upstream developers".

The New Maintainers' Guide has in the list of things to do when
packaging the first program:

"you should contact program's author(s) to check if they agree with
packaging it. It is important to be able to consult with author(s) about
the program in case of any program specific problems, so don't try to
package unmaintained pieces of software."

I think I saw it also in some instructions on how to ITP something but
I no longer find it.

But saying helo is not always easy. First of all one has to be able to
contact upstream (I once adopted a package where all email addresses of
upstream in the software and on the website there was none. Only behind
a link to another project was the mailinglist also for this package).

And then formulating such a mail is always a bit complicated. Not
everyone knows that package maintainers in Debian are really about
source modifications and saying helo can easily result in being offered
the upstream maintainer hat.

Hochachtungsvoll,
Bernhard R. Link
-- 
"Never contain programs so few bugs, as when no debugging tools are available!"
Niklaus Wirth


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Good communication with upstream is good idea

[Franklin PIAT]

On Sun, 2008-07-20 at 18:42 +0200, Bernhard R. Link wrote:
> * Osamu Aoki <[EMAIL PROTECTED]> [080720 14:57]:
> > I think we should encourage packager to contact upstream with simple
> > "hello!" message and he (or myself) should be part of active upstream ML.
> >
> > After all, we all are human.  Friendly "hello" always helps people.
> >
> > I know this is not something we need to have as policy but as a part of
> > best practice document, it is good to mention.  For Debian, "Developers
> > Reference".  If I miss it in "Developers Reference", I am sorry.
[..]
> And then formulating such a mail is always a bit complicated. Not
> everyone knows that package maintainers in Debian are really about
> source modifications and saying helo can easily result in being offered
> the upstream maintainer hat.

The mail to upstream could include a snipet like :

"If you are curious about what `Packaging for Debian' involves, you can
read : http://wiki.debian.org/GettingPackaged "


A lot of good work was done on that page, it could probably still be
improved and be migrated to www.d.o/doc/.

Franklin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: FHS and /var/www

[Carl Fürstenberg]

On Sun, Jul 20, 2008 at 16:34, Stephen Gran <[EMAIL PROTECTED]> wrote:
> This one time, at band camp, Carl Fürstenberg said:
>> FHS 2.3 specifies in
>> http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM
>> to use /srv for "Data for services provided by this system", for
>> example /srv/www for web root.
>> In the policy, the section
>> 9.1.1(http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1.1)
>> specifies that FHS 2.3 is mandatory, except for some exception, and
>> the use of /var/www isn't included in that list.
>>
>> Should we force all httpd:s to use /srv/www instead of /var/www, or
>> should an exception to the policy be added? Per
>> http://wiki.debian.org/Apache2LennyGoals it states that apache2 has
>> support for /srv/www, but it's still defaulting to /var/www.
>
> Please no.  The layout of /srv/ is specifically said to be undetermined,
> so we can't actually rely on any paths in /srv/.  I think the current
> setup is fairly good, actually - by default simple site layouts work out
> of the box, and don't interfere with more complicated setups that are
> free to use arbitrary hierarchies in /srv.
>
> Cheers,
>
>

So you "vote" for an exemption from FSH in this case, as per 9.1.1?


-- 
/Carl Fürstenberg <[EMAIL PROTECTED]>

Re: Good communication with upstream is good idea

[Neil Williams]

On Sun, 2008-07-20 at 12:16 -0400, Scott Kitterman wrote:
> On Sunday 20 July 2008 12:05, Florian Weimer wrote:
> > * Osamu Aoki:
> > > I found some of my packages are offered as a part of Ubuntu archive.
> >
> > Same here.  In my case (debsecan), it's a bit irresponsible because the
> > package doesn't really work on Ubuntu--but it's not readily apparent to
> > potential users.  Furthermore, it uses server resources provided to
> > Debian, and not to Ubuntu.
> >
> > What's the correct way to get it out of Unbuntu (universe)?  I don't
> > want to relicense it, but if asking politely does not work, it seems to
> > be my only choice.
> 
> The preferred way of 'asking politely' is a removal bug.  The process is 
> described here:

Which cannot be done without
yet-another-website-login-combo-to-use-once-and-lose-forevermore -
useless Ubuntu bug tracker. :-(

I do feed info upstream (via yet more website logins), I really can't
add yet another one.

That was the main point of my original blog entry linked from the
previous post. Having to ask the lazy web to sort out bugs in Ubuntu is
just daft, IMHO, but that's what LP requires. As I say, daft.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/




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

Re: Good communication with upstream is good idea

[Holger Levsen]

Hi,

On Sunday 20 July 2008 18:42, Florian Weimer wrote:
> Relicensing would involve moving the package to non-free, that's
> correct.

Ui, I dint expect you really would want that. Why not detect if the system is 
really Debian and if not output "system type unsupported"?


regards,
Holger


pgpwbE9WSk5WM.pgp
Description: PGP signature

Re: FHS and /var/www

[Stephen Gran]

This one time, at band camp, Carl Fürstenberg said:
> On Sun, Jul 20, 2008 at 16:34, Stephen Gran <[EMAIL PROTECTED]> wrote:
> > This one time, at band camp, Carl Fürstenberg said:
> >> FHS 2.3 specifies in
> >> http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM
> >> to use /srv for "Data for services provided by this system", for
> >> example /srv/www for web root.  In the policy, the section
> >> 9.1.1(http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1.1)
> >> specifies that FHS 2.3 is mandatory, except for some exception, and
> >> the use of /var/www isn't included in that list.
> >>
> >> Should we force all httpd:s to use /srv/www instead of /var/www, or
> >> should an exception to the policy be added? Per
> >> http://wiki.debian.org/Apache2LennyGoals it states that apache2 has
> >> support for /srv/www, but it's still defaulting to /var/www.
> >
> > Please no.  The layout of /srv/ is specifically said to be
> > undetermined, so we can't actually rely on any paths in /srv/.  I
> > think the current setup is fairly good, actually - by default simple
> > site layouts work out of the box, and don't interfere with more
> > complicated setups that are free to use arbitrary hierarchies in
> > /srv.
> 
> So you "vote" for an exemption from FSH in this case, as per 9.1.1?

http://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM

"Therefore, no program should rely on a specific subdirectory structure
of /srv existing or data necessarily being stored in /srv.

[...]

Distributions must take care not to remove locally placed files in these
directories without administrator permission."


I don't think there's any excemption needed.  The FHS already makes it
essentially impossible for distributors to place anything under /srv.
Not putting anything there means it's a fairly daft idea to have a
webroot pointing there and expect anything to work out of the box.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: Good communication with upstream is good idea

[Scott Kitterman]

On Sunday 20 July 2008 13:33, Neil Williams wrote:
> On Sun, 2008-07-20 at 12:16 -0400, Scott Kitterman wrote:
> > On Sunday 20 July 2008 12:05, Florian Weimer wrote:
> > > * Osamu Aoki:
> > > > I found some of my packages are offered as a part of Ubuntu archive.
> > >
> > > Same here.  In my case (debsecan), it's a bit irresponsible because the
> > > package doesn't really work on Ubuntu--but it's not readily apparent to
> > > potential users.  Furthermore, it uses server resources provided to
> > > Debian, and not to Ubuntu.
> > >
> > > What's the correct way to get it out of Unbuntu (universe)?  I don't
> > > want to relicense it, but if asking politely does not work, it seems to
> > > be my only choice.
> >
> > The preferred way of 'asking politely' is a removal bug.  The process is
> > described here:
>
> Which cannot be done without
> yet-another-website-login-combo-to-use-once-and-lose-forevermore -
> useless Ubuntu bug tracker. :-(
>
> I do feed info upstream (via yet more website logins), I really can't
> add yet another one.
>
> That was the main point of my original blog entry linked from the
> previous post. Having to ask the lazy web to sort out bugs in Ubuntu is
> just daft, IMHO, but that's what LP requires. As I say, daft.

Agreed.  There's a lot of stuff about Launchpad that is daft.  

If would put together the information requested in the removal bug, I'll file 
it.  That would avoid the need to make an account.  Feel free to follow-up 
offlist.

Scott K


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Good communication with upstream is good idea

[Neil Williams]

On Sun, 2008-07-20 at 19:57 +0200, Holger Levsen wrote:
> Hi,
> 
> On Sunday 20 July 2008 18:42, Florian Weimer wrote:
> > Relicensing would involve moving the package to non-free, that's
> > correct.
> 
> Ui, I dint expect you really would want that. Why not detect if the system is 
> really Debian and if not output "system type unsupported"?

I tried that - it generates a bug report within Ubuntu that I can't
close from within Debian but which shows up on the PTS page.
:-(

Plus it adds unnecessary code to the package without removing it from
the apt-cache search results in Ubuntu which only confuses people.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/




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

Re: FHS and /var/www

[Edward Allcutt]

On Sun, Jul 20, 2008 at 07:32:33PM +0200, Carl Fürstenberg wrote:
> On Sun, Jul 20, 2008 at 16:34, Stephen Gran <[EMAIL PROTECTED]> wrote:
> > This one time, at band camp, Carl Fürstenberg said:
> >> FHS 2.3 specifies in
> >> http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM
> >> to use /srv for "Data for services provided by this system", for
> >> example /srv/www for web root.
> >> In the policy, the section
> >> 9.1.1(http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1.1)
> >> specifies that FHS 2.3 is mandatory, except for some exception, and
> >> the use of /var/www isn't included in that list.
> >>
> >> Should we force all httpd:s to use /srv/www instead of /var/www, or
> >> should an exception to the policy be added? Per
> >> http://wiki.debian.org/Apache2LennyGoals it states that apache2 has
> >> support for /srv/www, but it's still defaulting to /var/www.
> >
> > Please no.  The layout of /srv/ is specifically said to be undetermined,
> > so we can't actually rely on any paths in /srv/.  I think the current
> > setup is fairly good, actually - by default simple site layouts work out
> > of the box, and don't interfere with more complicated setups that are
> > free to use arbitrary hierarchies in /srv.
> >
> > Cheers,
> >
> >
> 
> So you "vote" for an exemption from FSH in this case, as per 9.1.1?
I believe he's claiming that there is no exemption needed, and I agree.

Quoting from the URL you provided:


Purpose

/srv contains site-specific data which is served by this system. 


To me "site-specific" implies "not installed by the package manager".
I believe it's quite reasonable for apache, CVS, etc. to set up a
default location under /var so long as the local administrator can
configure them to use whichsoever path is preferred according to local
policy.

The footnote implying that distributions MAY install files under /srv is
very far from a SHOULD. I think by far the easiest way for Debian to
"take care not to remove locally placed files" is to never but things
there in the first place.


signature.asc
Description: Digital signature

Re: FHS and /var/www

[Carl Fürstenberg]

On Sun, Jul 20, 2008 at 19:58, Stephen Gran <[EMAIL PROTECTED]> wrote:
> http://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM
>
> "Therefore, no program should rely on a specific subdirectory structure
> of /srv existing or data necessarily being stored in /srv.
>
> [...]
>
> Distributions must take care not to remove locally placed files in these
> directories without administrator permission."
>
>
> I don't think there's any excemption needed.  The FHS already makes it
> essentially impossible for distributors to place anything under /srv.
> Not putting anything there means it's a fairly daft idea to have a
> webroot pointing there and expect anything to work out of the box.

I was refering to the use of /var/www, which isn't FHS valid, and no
excemption is made in the policy about that.

-- 
/Carl Fürstenberg <[EMAIL PROTECTED]>

Re: Good communication with upstream is good idea

[Reinhard Tartler]

Florian Weimer <[EMAIL PROTECTED]> writes:

> What's the correct way to get it out of Unbuntu (universe)?  


I'd suggest filing a bug, and perhaps advertise it on the relevant
developer mailing lists.

> I don't want to relicense it, but if asking politely does not work, it
> seems to be my only choice.

Relicensing would most probably make the package end up in multiverse
instead of univserse. In any case it would end up much confusion and
very litte benefit for all involved parties.

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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: FHS and /var/www

[Stephen Gran]

This one time, at band camp, Carl Fürstenberg said:
> On Sun, Jul 20, 2008 at 19:58, Stephen Gran <[EMAIL PROTECTED]> wrote:
> >
> > I don't think there's any excemption needed.  The FHS already makes it
> > essentially impossible for distributors to place anything under /srv.
> > Not putting anything there means it's a fairly daft idea to have a
> > webroot pointing there and expect anything to work out of the box.
> 
> I was refering to the use of /var/www, which isn't FHS valid, and no
> excemption is made in the policy about that.

The FHS is not an exhaustive list of every directory on the system, so
I'm not convinced that introducing a new directory needs an excemption
either.  We don't currently have an excemption for /etc/default, for
example.

But to short circuit this, I vote for leaving it alone, and not changing
anything in policy.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: glib inconsistencies in testing

[Steve Langasek]

On Sun, Jul 20, 2008 at 05:57:26PM +0200, Frank Küster wrote:
> Steve Langasek <[EMAIL PROTECTED]> wrote:

> > Actually, the bug is that libglib-perl is second-guessing glib's package
> > dependencies and spitting out warnings that it shouldn't.

> And it's already reported?

Well, I don't see it on , so I
guess it hasn't been reported, no.  Perhaps you would like to do so, since
you're seeing the bug in question?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: FHS and /var/www

[Steve Langasek]

On Sun, Jul 20, 2008 at 07:36:33PM +0100, Stephen Gran wrote:

> > I was refering to the use of /var/www, which isn't FHS valid, and no
> > excemption is made in the policy about that.

> The FHS is not an exhaustive list of every directory on the system, so
> I'm not convinced that introducing a new directory needs an excemption
> either.  We don't currently have an excemption for /etc/default, for
> example.

 "Applications must generally not add directories to the top level of /var.
  Such directories should only be added if they have some system-wide
  implication, and in consultation with the FHS mailing list."

FHS 2.3, Chapter 5.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: FHS and /var/www

[Steve Langasek]

On Sun, Jul 20, 2008 at 06:58:09PM +0100, Stephen Gran wrote:
> > So you "vote" for an exemption from FSH in this case, as per 9.1.1?

> http://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM

> "Therefore, no program should rely on a specific subdirectory structure
> of /srv existing or data necessarily being stored in /srv.

> [...]

> Distributions must take care not to remove locally placed files in these
> directories without administrator permission."

> I don't think there's any excemption needed.  The FHS already makes it
> essentially impossible for distributors to place anything under /srv.
> Not putting anything there means it's a fairly daft idea to have a
> webroot pointing there and expect anything to work out of the box.

I think it's perfectly in keeping with other parts of policy to ship our
webservers with /srv/www as the default webroot, and leave it up to the
administrator to symlink web applications into that root to enable them (or
change the web root, or use aliases, etc).  In particular, Policy 11.5.4
says that web applications should avoid storing files in the web document
root if possible.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#491597: ITP: magicmaze -- rescue the maiden while avoiding the monsters

[Joe Nahmias]

Package: wnpp
Severity: wishlist
Owner: Joseph Nahmias <[EMAIL PROTECTED]>

* Package name: magicmaze
  Version : 1.4.3.1
  Upstream Author : Kent "MenThal" Dahl <[EMAIL PROTECTED]>
* URL : http://magicmaze.rubyforge.org/
* License : "FREEWARE"
  Programming Lang: Ruby
  Description : rescue the maiden while avoiding the monsters

This is a simple game where you are a wizard searching the evil demon's
tower to try and rescue the beautiful maiden.  Inspired by Gauntlet II,
your goal is to avoid/kill the monsters while trying to find the exit
and, eventually, the big boss who is holding your girlfriend captive.
Includes support for playing in full-screen and with a joystick.

Note: The license needs clarification and the font included likely needs
to be substituted.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'stable')
Architecture: i386 (i686)



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Good communication with upstream is good idea

[Steve Langasek]

Hi Neil,

On Sun, Jul 20, 2008 at 05:32:31PM +0100, Neil Williams wrote:
> I ask because emdebian-tools isn't intended for Ubuntu either. See [0] -
> emdebian-tools also depends on server resources provided only by Debian
> (in this case, the package repositories containing compatible packages
> which I can use to generate cross-dependencies).

That doesn't seem particularly Debian-specific, though?  It's not out of the
question that Ubuntu could have an armel port later, and that's the only
thing I can think of that /should/ cause emdebian-tools to be incompatible
with Ubuntu.

> "emdebian-tools is not intended for Ubuntu but I don't have a way of
> encoding that in the package. emdebian-tools is tightly integrated into
> Debian (and Debian unstable in particular) and is, naturally, a Debian
> native package (it was written to support Embedded Debian after all, not
> UbuntuMobile). It isn't intended to work on Ubuntu because Ubuntu does
> not provide the foreign packages needed for linking when cross building,
> those come exclusively from Debian.

So if an armel port of Ubuntu becomes available, is there anything else that
stops emdebian-tools from working with it?

> Same with apt-cross, it is exclusively designed for Debian, Debian mirrors
> and Debian buildd configurations.

How does apt-cross have anything to do with the Debian buildds, at all?
Surely you're not using this as a build-dependency to force Debian
cross-builds on the Debian buildds, are you?

Nor do I see how apt-cross would be affected by differences between a Debian
vs. an Ubuntu mirror.  (Ubuntu main is smaller than Debian main, but is
still self-contained, to be sure.)

> How is emdebian-tools meant to cross-build for ARM on Ubuntu when Ubuntu
> does not provide ARM packages and makes changes to the equivalent Debian
> packages?

Hrm, what changes are at issue here?  The Debian maintainers also make
changes to Debian packages, all the time.  In what way do the Ubuntu changes
differ that makes emdebian-tools incompatible with Ubuntu?

> To me it seems highly unlikely that
> cross versions of Debian packages would install over a Ubuntu base,
> especially when those packages are the typical debootstrap selection
> that have a variety of changes in Ubuntu. I don't run Ubuntu, I have no
> inclination to test for Ubuntu and as no-one else has offered, I cannot
> support Ubuntu."

While the current absence of any official Ubuntu armel port seems like a
pretty good reason to omit emdebian-tools from Ubuntu for the moment, the
fact that the Debian package maintainer or upstream author doesn't support
Ubuntu would not generally be a reason for Ubuntu not to include the
package.  Debian also has any number of upstreams who don't "support"
Debian, after all.

> How many packages could be in this situation? I don't expect it to be
> many. Some form of filter on the Ubuntu side may be necessary.

Yes, there is a blacklist in Ubuntu to prevent certain packages from being
synced from Debian.  Scott Kitterman has already started the process now of
getting emdebian-tools added to that list.

BTW, in your cited blog post, I noticed that you wrote:

> I really don't like Launchpad (I have quite enough web-logins thank you very
> much) or the PTS link that shows Ubuntu bugs that I cannot close from
> Debian.

You can close Launchpad bugs in Ubuntu packages from Debian.  The "LP: ##"
syntax lets bugs get autoclosed when your package is synced to Debian, or
when it's merged by an Ubuntu developer.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: esound [was: Re: Non-related 'Recommends' dependencies - bug or not?]

[Jason D. Clinton]

On Sat, Jul 19, 2008 at 6:13 PM, Jason D. Clinton <[EMAIL PROTECTED]>
wrote:

> On Tue, Jun 17, 2008 at 9:21 AM, Loïc Minier <[EMAIL PROTECTED]> wrote:
>
>> On Tue, Jun 17, 2008, Martin Pitt wrote:
>> > That's interesting indeed! So you avoid that by using an OSS driver
>> > instead of the ALSA one? I can really not imagine how esound on top of
>> > a broken ALSA driver would sound better than just using the ALSA
>> > output directly?
>>
>>  It might normalize which sampling rate / sample width is used
>
>
> Loïc, you offered to NMU this package here:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=422590
>
> This vastly improves the Gnome sound situation. Hope we can get this in for
> Lenny.
>

Loïc has indicated that he doesn't have time to do this NMU. Can someone
else take this?

Re: FHS and /var/www

[Ben Finney]

Edward Allcutt <[EMAIL PROTECTED]> writes:

> 
> Purpose
> 
> /srv contains site-specific data which is served by this system. 
> 
> 
> To me "site-specific" implies "not installed by the package manager".
> I believe it's quite reasonable for apache, CVS, etc. to set up a
> default location under /var so long as the local administrator can
> configure them to use whichsoever path is preferred according to local
> policy.

I find this convincing, in combination with the rest of this thread.

I'm now in favour of '/srv' being out of bounds for the package
manager, like '/usr/local'.

-- 
 \  “He that would make his own liberty secure must guard even his |
  `\ enemy from oppression.” —Thomas Paine |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Good communication with upstream is good idea

[Ben Finney]

Neil Williams <[EMAIL PROTECTED]> writes:

> On Sun, 2008-07-20 at 19:57 +0200, Holger Levsen wrote:
> > Why not detect if the system is really Debian and if not output
> > "system type unsupported"?
> 
> I tried that - it generates a bug report within Ubuntu that I can't
> close from within Debian but which shows up on the PTS page.
> :-(

Yes, this is a good argument against the change to the PTS introduced
by bug#483179.

The Debian BTS should *only* report problems that can be solved from
within Debian, otherwise it's useless noise that leads to that section
being ignored even when it might have something important to say.

However, the above bug in the Debian BTS has been archived. Must we
open another bug to ask for the change to be reverted?

-- 
 \ “Two paradoxes are better than one; they may even suggest a |
  `\ solution.” —Edward Teller |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Good communication with upstream is good idea

[Neil Williams]

On Sun, 2008-07-20 at 13:43 -0700, Steve Langasek wrote:
> Hi Neil,
> 
> On Sun, Jul 20, 2008 at 05:32:31PM +0100, Neil Williams wrote:
> > I ask because emdebian-tools isn't intended for Ubuntu either. See [0] -
> > emdebian-tools also depends on server resources provided only by Debian
> > (in this case, the package repositories containing compatible packages
> > which I can use to generate cross-dependencies).
> 
> That doesn't seem particularly Debian-specific, though?  It's not out of the
> question that Ubuntu could have an armel port later, and that's the only
> thing I can think of that /should/ cause emdebian-tools to be incompatible
> with Ubuntu.

emdebian-tools supports all the architectures currently supported by
Debian and a few that are pending (like uclibc ones - once the
well-known problems in uClibc are sorted out and uclibc returns to
Debian after Lenny). To support emdebian-tools properly, Ubuntu would
have to support all the Debian architectures with appropriate buildds
and repositories. This is more than a little pointless.

The other problem is that emdebian-tools is working towards getting
cross-building support into Debian packages but currently needs patches
to cross-build all current packages (even those that have closed the
relevant cross-building support bugs) due to issues in CDBS and
debhelper etc. Those patches are constantly updated against the versions
of the packages in Debian Sid - e.g. I've just updated the patches for
pam, pcre3 and a few others that allow me to upload a usable cross-built
package in advance of a solution compatible with the Debian package
itself. With the newly created cross-building autobuilder for Emdebian,
[0] I will now have more time to file such bugs to get the next round of
cross-building support into packages. I was concentrating on getting the
basic support into at least some packages for Lenny and that is now
done. All the time, the tools themselves are developing and becoming
more powerful. As support improves, patches change. It's a lot of work
and I am not about to make those patches compatible with the versions in
Ubuntu (or any other derivative) - the only solution for non-Debian
usage is to wait until the changes are made in the appropriate Debian
packages that remove the need for the patches. That is a slow process
and in the meantime, Emdebian needs packages to test and those need the
patches.

Even when the patches are folded into Debian, the lack of suitable
architecture repositories will prevent emdebian-tools being useful on
Ubuntu, especially when compared with running the tools inside a Debian
chroot on Ubuntu.

> > "emdebian-tools is not intended for Ubuntu but I don't have a way of
> > encoding that in the package. emdebian-tools is tightly integrated into
> > Debian (and Debian unstable in particular) and is, naturally, a Debian
> > native package (it was written to support Embedded Debian after all, not
> > UbuntuMobile). It isn't intended to work on Ubuntu because Ubuntu does
> > not provide the foreign packages needed for linking when cross building,
> > those come exclusively from Debian.
> 
> So if an armel port of Ubuntu becomes available, is there anything else that
> stops emdebian-tools from working with it?

mips, mipsel, ARM, uclibc-arm, uclibc-mips . . . .

Currently, emdebian-tools only has prebuilt binary packages for ARM (not
armel) but adding more is supported (although not particularly trivial
at this time).

For Ubuntu to support emdebian-tools, Ubuntu would have to become Debian
which would be pointless (and futile).

Those who want to do things with Emdebian on Ubuntu are simply advised
to create a Debian chroot - Lenny or better - and run things from there.

> > Same with apt-cross, it is exclusively designed for Debian, Debian mirrors
> > and Debian buildd configurations.
> 
> How does apt-cross have anything to do with the Debian buildds, at all?
> Surely you're not using this as a build-dependency to force Debian
> cross-builds on the Debian buildds, are you?

The Emdebian autobuilder uses apt-cross, yes. There is no other way of
downloading ARM packages on amd64 and converting them to -arm-cross
packages for use in /usr/arm-linux-gnu/lib/ etc and reconciling all the
dependencies to be compatible with dpkg. emdebian-tools uses a
debootstrap wrapper to create a disposable chroot cross-building
environment with emdebian-tools installed and configured inside
(including a cross-building toolchain for the desired arch). Yes, this
is a larger .tgz than a standard pbuilder but it works. i.e. for
Emdebian build-essential, in effect, includes emdebian-tools (which in
turn depends on apt-cross).

Debian buildds don't support cross-building, I'm using emdebian-tools
autobuilder support. (We also have an autobuilder for the toolchains.)
The autobuilders grew organically from the basic scripts due to the
inevitable need to let packages cross-build unattended whilst I get on
with the rest of my life. The autobuilde

Bug#491626: ITP: mina -- Java network application framework

[Damien Raude-Morvan]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

 Package name: mina
 Version: 1.1.17
 Upstream Author: Apache Software Foundation
 URL: http://mina.apache.org
 License: APL 2.0
 Description:  Java network application framework

Apache MINA is a network application framework which helps users develop high 
performance and high scalability network applications easily. It provides an 
abstract - event-driven - asynchronous API over various transports such as 
TCP/IP and UDP/IP via Java NIO
 .
 Some of the features of Apache Mina are:
 * Unified API for various transport types: TCP/UDP/RS232/In-VM
 * Filter interface as an extension point; similar to Servlet filters 
 * Low-level and high-level API
 * Highly customizable thread model: 
 * Out-of-the-box SSL / TLS and StartTLS support using Java 5 SSLEngine
 * Overload shielding & traffic throttling
 * Unit testability using mock objects
 * JMX managability
 * Stream-based I/O support via StreamIoHandler




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: FHS and /var/www

[Brendan]

On Sunday 20 July 2008, Steve Langasek wrote:
> On Sun, Jul 20, 2008 at 06:58:09PM +0100, Stephen Gran wrote:

> I think it's perfectly in keeping with other parts of policy to ship our
> webservers with /srv/www as the default webroot, and leave it up to the

I think that this is a terrible idea. Leave well-enough alone.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: FHS and /var/www

[Stephen Gran]

This one time, at band camp, Steve Langasek said:
> On Sun, Jul 20, 2008 at 06:58:09PM +0100, Stephen Gran wrote:
> > > So you "vote" for an exemption from FSH in this case, as per
> > > 9.1.1?
> 
> > http://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM
> 
> > "Therefore, no program should rely on a specific subdirectory
> > structure of /srv existing or data necessarily being stored in /srv.
> 
> I think it's perfectly in keeping with other parts of policy to ship
> our webservers with /srv/www as the default webroot, and leave it up
> to the administrator to symlink web applications into that root to
> enable them (or change the web root, or use aliases, etc).  In
> particular, Policy 11.5.4 says that web applications should avoid
> storing files in the web document root if possible.

So you think it's a good idea to ignore the the sentence above?  I agree
that it's a bad idea for applications to store things under the webroot
in general, but that's a seperate issue altogether to changing what the
default webroot points to.  If we could keep the seperate issues seperate
for the moment, I think it would be helpful.

a) applications installing random files under web root - bad
b) Changing httpds to ship a web root that either doesn't exist or would
   be wildly inappropriate on every system I admin - also bad.

Doing the change you recommend also has the downside of guaranteeing
that no web application that has to ship files under the web root can
work out of the box.  Admittedly these applications are probably silly,
but not currently buggy.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Bug#486250: buildd.emdebian.org: gnupg fails to crossbuild - problem with curl?

[Michael Bienia]

On 2008-06-14 18:23:07 +0100, Neil Williams wrote:

Hello,

> *** ../emdebian-tail.log
> .../../keyserver/gpgkeys_curl.c:304: error: ?typeof? applied to a bit-field
> .../../keyserver/gpgkeys_curl.c:304: error: ?typeof? applied to a bit-field
> .../../keyserver/gpgkeys_curl.c:304: error: ?typeof? applied to a bit-field
> .../../keyserver/gpgkeys_curl.c:304: error: ?typeof? applied to a bit-field
> .../../keyserver/gpgkeys_curl.c:304: error: ?typeof? applied to a bit-field
> .../../keyserver/gpgkeys_curl.c:304: error: ?typeof? applied to a bit-field
> .../../keyserver/gpgkeys_curl.c:304: error: ?typeof? applied to a bit-field
> .../../keyserver/gpgkeys_curl.c:304: error: ?typeof? applied to a bit-field
> .../../keyserver/gpgkeys_curl.c:304: error: ?typeof? applied to a bit-field
> .../../keyserver/gpgkeys_curl.c:304: error: ?typeof? applied to a bit-field
> .../../keyserver/gpgkeys_curl.c:304: error: ?typeof? applied to a bit-field
> .../../keyserver/gpgkeys_curl.c:304: error: ?typeof? applied to a bit-field

I've run into the same problem while merging gnupg for Ubuntu intrepid.
This is a problem how gnupg passes its arguments to libcurl. It was
already discussed on the gnupg-devel mailing list[0] and contains also a
patch for it[1].

Regards,
Michael

0: http://lists.gnupg.org/pipermail/gnupg-devel/2008-April/024334.html
1: http://lists.gnupg.org/pipermail/gnupg-devel/2008-April/024344.html



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#491634: ITP: libbsd-arc4random-perl -- CPAN module BSD::arc4random

[Thorsten Glaser]

Package: wnpp
Severity: wishlist
Owner: Thorsten Glaser <[EMAIL PROTECTED]>

* Package name: libbsd-arc4random-perl
  Version : 1.30
  Upstream Author : Thorsten Glaser <[EMAIL PROTECTED]>
* URL : http://www.mirbsd.org/man3/arc4random
* License : MirOS Licence (same as package mksh)
  Programming Lang: C, Perl
  Description : CPAN module BSD::arc4random

I've prepared a package of a Perl module wrapping the arc4random(3)
family of functions into ithreads-safe Perl functions and adding some
syntactic sugar. The libbsd package’s implementation of arc4random(3)
is used instead of the included convenience copy. This package makes
access to a self-seeding PRNG easy, for example in programmes that can
be extended by Perl plugins, such as irssi.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (990, 'testing'), (800, 'stable'), (700, 'unstable'), (500, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.25-2-686 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/mksh



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Good communication with upstream is good idea

[Ben Finney]

Ben Finney <[EMAIL PROTECTED]> writes:

> The Debian BTS should *only* report problems that can be solved from
> within Debian, otherwise it's useless noise that leads to that
> section being ignored even when it might have something important to
> say.

That should of course say “The Debian PTS should …”.

-- 
 \ “Some mornings, it's just not worth chewing through the leather |
  `\ straps.” —Emo Philips |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: FHS and /var/www

[Steve Langasek]

On Mon, Jul 21, 2008 at 01:14:05AM +0100, Stephen Gran wrote:
> This one time, at band camp, Steve Langasek said:
> > On Sun, Jul 20, 2008 at 06:58:09PM +0100, Stephen Gran wrote:
> > > > So you "vote" for an exemption from FSH in this case, as per
> > > > 9.1.1?

> > > http://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM

> > > "Therefore, no program should rely on a specific subdirectory
> > > structure of /srv existing or data necessarily being stored in /srv.

> > I think it's perfectly in keeping with other parts of policy to ship
> > our webservers with /srv/www as the default webroot, and leave it up
> > to the administrator to symlink web applications into that root to
> > enable them (or change the web root, or use aliases, etc).  In
> > particular, Policy 11.5.4 says that web applications should avoid
> > storing files in the web document root if possible.

> So you think it's a good idea to ignore the the sentence above?

No, I don't think that using it as a default webroot is "rely[ing] on a
specific subdirectory structure of /srv existing or data necessarily being
stored in /srv", because the web server can be reconfigured to look
elsewhere.

> I agree that it's a bad idea for applications to store things under the
> webroot in general, but that's a seperate issue altogether to changing
> what the default webroot points to.  If we could keep the seperate issues
> seperate for the moment, I think it would be helpful.

If your objection to using /srv/www as the default web root isn't about
applications storing files there, then why do you object to it?  Is it
because it would be "wildly inappropriate" on your systems?

> a) applications installing random files under web root - bad
> b) Changing httpds to ship a web root that either doesn't exist or would
>be wildly inappropriate on every system I admin - also bad.

Does "wildly inappropriate" mean that shipping such a default would
incorrectly expose data to the network that wasn't meant to be exposed?

> Doing the change you recommend also has the downside of guaranteeing
> that no web application that has to ship files under the web root can
> work out of the box.  Admittedly these applications are probably silly,
> but not currently buggy.

Well, I consider that an upside rather than a downside; I don't think
there's any excuse for a package enabling a web app by default, and would be
happy to see such packages declared buggy - which I agree could be handled
separately from /srv/www.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Good communication with upstream is good idea

[Russ Allbery]

Ben Finney <[EMAIL PROTECTED]> writes:
> Ben Finney <[EMAIL PROTECTED]> writes:

>> The Debian BTS should *only* report problems that can be solved from
>> within Debian, otherwise it's useless noise that leads to that section
>> being ignored even when it might have something important to say.
>
> That should of course say “The Debian PTS should …”.

Adding an alternative data point here... I was happy to see the Ubuntu bug
count added to the PTS since it uncovered Ubuntu bugs in several of my
packages, many of which I could easily comment on and recommend closing
and some of which were legitimate bugs.

I would have preferred to have gotten those bug reports more directly, but
given the choice between having to log on to Launchpad and check or
subscribe to each package I maintain and looking in the PTS, I prefer the
latter, even if I don't have as a goal getting the Ubuntu bug count to 0.

-- 
Russ Allbery ([EMAIL PROTECTED])   


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: FHS and /var/www

[Stephen Gran]

This one time, at band camp, Steve Langasek said:
> On Mon, Jul 21, 2008 at 01:14:05AM +0100, Stephen Gran wrote:
> > This one time, at band camp, Steve Langasek said:
> > > On Sun, Jul 20, 2008 at 06:58:09PM +0100, Stephen Gran wrote:
> > > > > So you "vote" for an exemption from FSH in this case, as per
> > > > > 9.1.1?
> 
> > > > http://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM
> 
> > > > "Therefore, no program should rely on a specific subdirectory
> > > > structure of /srv existing or data necessarily being stored in /srv.
> 
> > > I think it's perfectly in keeping with other parts of policy to ship
> > > our webservers with /srv/www as the default webroot, and leave it up
> > > to the administrator to symlink web applications into that root to
> > > enable them (or change the web root, or use aliases, etc).  In
> > > particular, Policy 11.5.4 says that web applications should avoid
> > > storing files in the web document root if possible.
> 
> > So you think it's a good idea to ignore the the sentence above?
> 
> No, I don't think that using it as a default webroot is "rely[ing] on a
> specific subdirectory structure of /srv existing or data necessarily being
> stored in /srv", because the web server can be reconfigured to look
> elsewhere.

If the apache or other httpd debs ship the directory and then set it as
the default webroot, surely that is 'relying' on the directory existing?
Unless you don't think that packages need to ship with sane working
defaults, which strikes me as not the sort of argument you normally make.
/srv/ is, AIUI, the admin's playground to structure as they see fit,
much like /usr/local.  I am fairly sure you wouldn't advocate a webroot
of /usr/local/www, so I'm having a hard time seeing why this is this better.

> > I agree that it's a bad idea for applications to store things under the
> > webroot in general, but that's a seperate issue altogether to changing
> > what the default webroot points to.  If we could keep the seperate issues
> > seperate for the moment, I think it would be helpful.
> 
> If your objection to using /srv/www as the default web root isn't about
> applications storing files there, then why do you object to it?  Is it
> because it would be "wildly inappropriate" on your systems?

My objection is because the FHS tells us that we can't rely on a
particular layout of /srv/ - making the webroot be /srv/www is relying on
a particular layout of /srv.  This is an obvious contradiction to me,
but I see that you disagree.  I'm just not sure how you can reconcile
"we want to ship applications that work out of the box" and "we have no
idea what the directory structure will be on the target system".

I happen to have an incompatible layout on my webservers, so it would
seriously annoy me to have this suddenly be the default, but that's a
personal, rather than a policy, issue.

> > a) applications installing random files under web root - bad
> > b) Changing httpds to ship a web root that either doesn't exist or would
> >be wildly inappropriate on every system I admin - also bad.
> 
> Does "wildly inappropriate" mean that shipping such a default would
> incorrectly expose data to the network that wasn't meant to be exposed?

Yes.  My webservers tend to use something like
/srv/www//{config,cgi-bin,htdocs,lib,logs,blah,blah}/ as the
normal layout.  Exposing /srv/www as a document root would give access to
lots of things that are not public in many cases - we tend to not bother
with .htaccess files since config/ and so on are not under the webroot.

However, as I said, it being wrong for me is personal - the fact that
the FHS tells us that /srv/ is the domain of the local admin to reorder
however they feel like is enough to argue against relying on /srv for
anything packaged.

> > Doing the change you recommend also has the downside of guaranteeing
> > that no web application that has to ship files under the web root can
> > work out of the box.  Admittedly these applications are probably silly,
> > but not currently buggy.
> 
> Well, I consider that an upside rather than a downside; I don't think
> there's any excuse for a package enabling a web app by default, and would be
> happy to see such packages declared buggy - which I agree could be handled
> separately from /srv/www.

Agreed.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: Good communication with upstream is good idea

[Charles Plessy]

Le Sun, Jul 20, 2008 at 01:43:13PM -0700, Steve Langasek a écrit :
> 
> You can close Launchpad bugs in Ubuntu packages from Debian.  The "LP: ##"
> syntax lets bugs get autoclosed when your package is synced to Debian, or
> when it's merged by an Ubuntu developer.

Interesting...

Does it work exactly like for the Debian BTS: i.e. it must be part of
the .changes files? I ask the question because for the primer3 package,
a Ubuntu user contacted Upstream for LP:191053, Upstream released a new
version that I packaged, but the Ubuntu user did not close the Launchpad
bug. In the next Debian upload, I can add a LP: 191053 tag in the
changelog, but if it is not associated with the upload that actually
corrected the bug it will be messy. If I add it deeper in the Debian
changelog, will it do its magic?

(Or maybe the simplest is simply to notify MOTU science? Hello, MOTU
science :)

Have a nice day,

-- 
Charles Plessy
Debian-Med packaging team,
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Good communication with upstream is good idea

[William Pitcock]

Hi,

On Mon, 2008-07-21 at 11:45 +0900, Charles Plessy wrote:
> Le Sun, Jul 20, 2008 at 01:43:13PM -0700, Steve Langasek a écrit :
> > 
> > You can close Launchpad bugs in Ubuntu packages from Debian.  The "LP: 
> > ##"
> > syntax lets bugs get autoclosed when your package is synced to Debian, or
> > when it's merged by an Ubuntu developer.
> 
> Interesting...
> 
> Does it work exactly like for the Debian BTS: i.e. it must be part of
> the .changes files? I ask the question because for the primer3 package,
> a Ubuntu user contacted Upstream for LP:191053, Upstream released a new
> version that I packaged, but the Ubuntu user did not close the Launchpad
> bug. In the next Debian upload, I can add a LP: 191053 tag in the
> changelog, but if it is not associated with the upload that actually
> corrected the bug it will be messy. If I add it deeper in the Debian
> changelog, will it do its magic?

It has to be in the .changes file. It works exactly like DAK's behaviour
for bug closing.

William



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

What to do with new upstream releases before Lenny is out ?

[Charles Plessy]

Le Sat, Jul 19, 2008 at 03:35:35PM +0200, Luk Claes a écrit :
> __
>< We freeze next week! >
> --
> \   ^__^
>  \  (oo)\___
> (__)\   )\/\
> ||w |
> || ||

Hi again,

basically, freezing next week means that uploads with a low urgency will
not be part of Lenny (unless hinted).

In the next 1~2 monthes that separate us from the release, there will be
new upstream releases for the packages I maintain and I am undecided
what to do:

 - Ignore them and dedicate only to Lenny.
 - Package them only if requested by users.
 - Upload them to experimental.
 - Upload them to unstable.

For the moment I did one upload to experimental, but I am not convinced
by my own choice. If somebody has wise comments, I will be grateful to
listen them.

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: What to do with new upstream releases before Lenny is out ?

[Barry deFreese]

Charles Plessy wrote:


In the next 1~2 monthes that separate us from the release, there will be
new upstream releases for the packages I maintain and I am undecided
what to do:

 - Ignore them and dedicate only to Lenny.
 - Package them only if requested by users.
 - Upload them to experimental.
 - Upload them to unstable.

For the moment I did one upload to experimental, but I am not convinced
by my own choice. If somebody has wise comments, I will be grateful to
listen them.

Have a nice day,

  

Just help get ctsim to build with wx2.8 so we can drop 2.4. ;-)

Thanks,

Barry deFreese


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Good communication with upstream is good idea

[Kartik Mistry]

On Mon, Jul 21, 2008 at 2:13 AM, Steve Langasek <[EMAIL PROTECTED]> wrote:
> You can close Launchpad bugs in Ubuntu packages from Debian.  The "LP: ##"
> syntax lets bugs get autoclosed when your package is synced to Debian, or
> when it's merged by an Ubuntu developer.

Thanks Steve, for this.
I can now close bugs without worrying and not having LP account!

-- 
 Cheers,
 Kartik Mistry | 0xD1028C8D | IRC: kart_
 Blogs: {ftbfs,kartikm}.wordpress.com


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: What to do with new upstream releases before Lenny is out ?

[Russ Allbery]

Charles Plessy <[EMAIL PROTECTED]> writes:

> In the next 1~2 monthes that separate us from the release, there will be
> new upstream releases for the packages I maintain and I am undecided
> what to do:
>
>  - Ignore them and dedicate only to Lenny.
>  - Package them only if requested by users.
>  - Upload them to experimental.
>  - Upload them to unstable.
>
> For the moment I did one upload to experimental, but I am not convinced
> by my own choice. If somebody has wise comments, I will be grateful to
> listen them.

I've been pondering the same thing and have been tenatively planning to
upload to experimental just to ensure that I don't entangle any library
transitions that need to migrate with packages that don't.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#455292: (no subject)

[Timothy G Abbott]

owner 455292 !
retitle 455292 ITP: sagemath -- Mathematics software written in Python
thanks

* Package name: sagemath
  Version : 3.0.5
* URL : http://www.sagemath.org/
* License : GPL
  Programming Lang: C, Python
  Description : Mathematics software written in Python

 Sage is a mathematical software package with support for a wide range
 of mathematics, including algebra, calculus, elementary to very
 advanced number theory, cryptography, numerical computation,
 commutative algebra, group theory, combinatorics, graph theory, and
 exact linear algebra.
 .
 Sage integrates several dozen mathematical software packages, making
 it possible to combine the best algorithms from several different
 packages together in a single Sage program.
 .
 Much of the Sage core and the Sage interfaces are implemented in
 Cython, helping Sage avoid the usual performance problems associated
 with Python.
 .
 Sage has a friendly command-line interface based on iPython and a
 web-based notebook interface which can run locally or connect to a
 remote Sage server over the network.

-Tim Abbott



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Good communication with upstream is good idea

[Thomas Viehmann]

Ben Finney wrote:
> The Debian BTS should *only* report problems that can be solved from
> within Debian, otherwise it's useless noise that leads to that section
> being ignored even when it might have something important to say.
> 
> However, the above bug in the Debian BTS has been archived. Must we
> open another bug to ask for the change to be reverted?
No. It has been discussed on debian-qa and the outcome is the present.
Unless there are some brand new reasons it makes no sense to revisit
this issue every month.

If it hurts you that much, use
  http://people.debian.org/~tviehmann/debian-pts.user.js
or something similar.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]