Bug#476909: suggestions on reorganisation of the stardict package.
Package: stardict
Severity: normal
Hi, Andrew Lee and Anthony Fok!
I use stardict, I like this dictionary very much, but there is a great
discomfort: at every new installation it is necessary to download the
dictionaries from the site http://stardict.sourceforge.net by hand and
to install them.
It would be nice if the deb-package included the dictionaries from this
site, however it is most likely impossible because mostly they will not
correspond to DFSG.
I have a proposal to you:
to modify the package thus it has configure and template scripts for
debconf, which would allow users to choose and install the dictionaries
automatically (dpkg-reconfigure).
I've written a small script (it is attached) which creates a list of
what to download and where from: according to the results of the work of
this script one may generate the menu for choosing). Some time later I
would be able to complete the work on this system [1].
However now I have to choose whether to make a fake package only for
automatisation of downloading the dictionaries for stardict or to work
further on the stardict package.
Here I need your agreement or disagreement about working on the stardict
package: in the first case you'll include the results of my work into
package and add me to the Uploaders group and in the second one I'll
make a retitle of this bug in ITP: staridct-dicts [1].
Please inform me what is your opinion on this subject.
Sincerely yours, Dmitry
PS: notes:
[1] _example_ of staridct-dicts.deb uploaded to:
http://uvw.ru/debian/unstable/stardict/
#!/usr/bin/perl
use warnings;
use strict;
package MechUTF8;
use base qw(WWW::Mechanize);
use Encode qw(encode decode);
sub content
{
my $self=shift;
my $content=$self->SUPER::content(@_);
$self->response->header('Content-Type')=~/charset=([\w\d\-]+)/
and $content=encode(utf8=>decode($1=>$content));
return $content;
}
package main;
use URI;
use File::Basename qw(basename);
use Getopt::Std qw(getopts);
my $server="http://stardict.sourceforge.net";;
my $durl="$server/Dictionaries.php";
sub die_if_error($$)
{
my ($browser, $errtxt)[EMAIL PROTECTED];
$browser->success and return;
die sprintf "$errtxt, server status: %s\n",
$browser->status;
}
sub usage()
{
print <', $opts{o}
or die "Can not create file $opts{o}: $!\n";
$|=1;
}
$|=1; select STDERR; $|=1; select STDOUT;
my $browser=new MechUTF8;
$opts{v} and print STDERR "Getting $durl ...\n";
$browser->get($durl);
die_if_error $browser, "Can not get categories list from $server";
my %ans=
map { m{href="(.*?)".*?>\s*(.*?)\s*<}s; ($2, "$server/$1") }
$browser->content=~m{()}sgi;
for (sort keys %ans)
{
unless ($ans{$_}=~m{$server/Dictionaries_})
{
delete $ans{$_};
next;
}
$opts{v} and print STDERR "\tGetting $ans{$_} ...\n";
$browser->get($ans{$_});
die_if_error $browser, "Can not get category `$_'";
my $content=$browser->content;
for ($content)
{
s[][]sig;
s[<\s*(?:/)?\s*(?:font|span|strong|b|b|br).*?>][ ]sig;
}
my %dlist=
map { $$_[0]=~s[\s*(.*?)\s*<.*][$1]; ($$_[0], $$_[1]) }
grep { $$_[1] !~ /rpm$/i }
map { $$_[1]=~s/\?.*//s; $_ }
map { ($$_[1]=~m[.*\s*tarbal]si)?[$$_[0], $1]:() }
map { [ $$_[0], "$$_[1] $$_[2]" ] }
grep { @$_ == 4 or @$_ == 3 }
map { [ m[()]sig ] }
$content=~m{()}sig;
for my $url (values %dlist)
{
my $basename=basename(URI->new($url)->path);
$url={file=>$basename, url=>$url, section=>$_};
}
$opts{v} and
printf STDERR "\t\tfound %d tarbal-links for download\n",
scalar keys %dlist;
unless (%dlist)
{
delete $ans{$_};
next;
}
printf "%s\n",
join "\t",
$dlist{$_}{section},
$_,
$dlist{$_}{file},
$dlist{$_}{url} for sort keys %dlist;
}
keys %ans or
die "Can not find categories list in $durl\n";
exit 0;
signature.asc
Description: Digital signature
Re: Please think and test before setting a mailing list as "Maintainer:"
On Sun, Apr 20, 2008 at 08:25:06AM +0200, Christian Perrier wrote: > As a kind of example, let me post what Steve and I did set for the > samba package maintenance ML, run by mailman: Thanks a lot for this snippets! Can you please add them on the wiki somewhere and point them to from the Alioth documentation pages? It would help a lot. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],cs.unibo.it,debian.org} -<%>- http://upsilon.cc/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: Heads up: ffmpeg transition (SONAME Change!)
On Sat, Apr 19, 2008 at 11:28:24AM +0200, Reinhard Tartler wrote: > Currently debian/testing ships a very old copy of ffmpeg, dated from > 0.cvs20070307. We, the ffmpeg maintainers (Fabian Greffrath and myself) > do not consider that version of ffmpeg acceptable for release in debian > lenny. Many newer applications of ffmpeg (like mplayer) require a newer > ffmpeg to build, others (like xine) are waiting for debian to update the > ffmpeg package. On a related note, what are the plans for ffmpeg encoding? As it is, the current lenny package seems to have stripped away most everything, leaving the transcoding support of VLC (among others) near-useless (try using MPEG-1 to stream low-bitrate video...). /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#476923: ITP: python-weberror -- Python web error handling and exception catching module
Package: wnpp Severity: wishlist Owner: Christoph Haas <[EMAIL PROTECTED]> * Package name: python-weberror Version : 0.8a Upstream Author : Ben Bangert <[EMAIL PROTECTED]>, Ian Bicking <[EMAIL PROTECTED]>, Mark Ramm <[EMAIL PROTECTED]> * URL : http://pypi.python.org/pypi/WebError * License : (GPL, LGPL, BSD, MIT/X, etc.) Programming Lang: (C, C++, C#, Perl, Python, etc.) Description : Python web error handling and exception catching module This Python module provides error handling and exception catching functinality for WSGI web applications. It is primarily used by Pylons (python-pylons). -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-2-686 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#476924: ITP: python-webob -- Python module providing WSGI request and response objects
Package: wnpp Severity: wishlist Owner: Christoph Haas <[EMAIL PROTECTED]> * Package name: python-webob Version : 0.9.1 Upstream Author : Ian Bicking <[EMAIL PROTECTED]> * URL : http://pythonpaste.org/webob/ * License : MIT Programming Lang: Python Description : Python module providing WSGI request and response objects WebOb provides wrappers around the WSGI request environment, and an object to help create WSGI responses. The objects map much of the specified behavior of HTTP, including header parsing and accessors for other standard parts of the environment. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-2-686 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please think and test before setting a mailing list as "Maintainer:"
On 11361 March 1977, Christian Perrier wrote: > I happen to often send mails to @packages.debian.org while > conducting my NMU campaigns for l10n bugs hunting. > From time to time, I still get such mails rejected because the said > package uses a mailing list as "Maintainer:". I did hate that too, and in the end it lead to the alioth admins implementing the Debian whitelist. That helps for about 95% of the packages using a mailinglist and currently allows all ftpteam members, debbugs, dak and lucas ddpomail as well as Hennings "migrated to testing" mails. Im sure that, if you send your stuff from one defined address only, this address could be added to the whitelist too. Of course it then should be one that you normally not use, ie. not [EMAIL PROTECTED], but something like [EMAIL PROTECTED] or maybe restricted to one host, like [EMAIL PROTECTED] Then you bypass all the usual filters on alioth lists. -- bye, Joerg 2.5 million B.C.: OOG the Open Source Caveman develops the axe and releases it under the GPL. The axe quickly gains popularity as a means of crushing moderators heads. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#476927: ITP: haskell-dataenc -- Data encoding library for Haskell
Package: wnpp Severity: wishlist Owner: Magnus Therning <[EMAIL PROTECTED]> * Package name: haskell-dataenc Version : 0.10.2 Upstream Author : Magnus Therning <[EMAIL PROTECTED]> * URL : http://hackage.haskell.org/cgi-bin/hackage-scripts/package/dataenc * License : LGPL Programming Lang: Haskell Description : Data encoding library for Haskell Data encoding library currently providing Uuencode, Base64, Base64Url, Base32, Base32Hex, and Base16. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Heads up: ffmpeg transition (SONAME Change!)
removing debian-release, as this discussion is not relevant for the next debian release. "Steinar H. Gunderson" <[EMAIL PROTECTED]> writes: > On a related note, what are the plans for ffmpeg encoding? As it is, the > current lenny package seems to have stripped away most everything, leaving > the transcoding support of VLC (among others) near-useless (try using MPEG-1 > to stream low-bitrate video...). I just added a note about that to README.Debian: http://svn.debian.org/viewsvn/pkg-multimedia/experimental/ffmpeg/debian/README.Debian?view=markup Quoting from that: Disabled MPEG encoders == On Debconf 7, the ffmpeg maintainers had a conversation with James Troup from the ftpteam about mpeg encoders in the ffmpeg package. The ftpteam was pretty surprised about the accepted encoders, and admitted that they were accepted by accident. We therefore had no choice but removing them. We agreed on a plan that rather disables than removes the encoders, for details see debian/strip.sh, rendering those encoders unusable. In order to make this fact visible, the source package was renamed from ffmpeg to ffmpeg-free. The plan is to provide a source package called 'ffmpeg' (without the -free) suffix, which builds drop-in replacement binary package with the mpeg encoders enabled. Ideally, we would be allowed to include those mpeg encoders enabled in non-free, but we haven't heared back from the ftpteam about that idea. -- Reinhard Tartler <[EMAIL PROTECTED]>, Sun, 20 Apr 2008 08:43:23 +0200 Help on that is desperately needed. Either by working on creating/packaging/testing/distributing unstripped ffmpeg binary packages or by asking the ftpteam to make an official statement if such a package would be accepted in debian/non-free. I was told that there was an ftpteam internal discussion about that, and even a vote about exactly this topic, but I was not told the result of that vote. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Heads up: ffmpeg transition (SONAME Change!)
On Sun, Apr 20, 2008 at 11:18:13AM +0200, Reinhard Tartler wrote: > On Debconf 7, the ffmpeg maintainers had a conversation with James Troup > from the ftpteam about mpeg encoders in the ffmpeg package. The ftpteam > was pretty surprised about the accepted encoders, and admitted that they > were accepted by accident. We therefore had no choice but removing > them. We agreed on a plan that rather disables than removes the > encoders, for details see debian/strip.sh, rendering those encoders > unusable. For those of us not living in jurisdictions where software patents appear very enforceable, is there currently any way to build our own, unstripped packages? (Sort of like the DVD-CSS "example" script downloading and building the right modules for you.) /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please think and test before setting a mailing list as "Maintainer:"
* Christian Perrier <[EMAIL PROTECTED]> [2008-04-20 08:25]: > As a kind of example, let me post what Steve and I did set for the > samba package maintenance ML, run by mailman: > > [snip] Thanks for the configuration example, it is really helpful. I also set the following for all mailing-lists-as-maintainers that I administer at Alioth: General options -> respond_to_post_requests (general): Send mail to poster when their posting is held for approval? No This avoids the irritating "your mail has been held for moderation" notifications. Note that this works better when the list moderator is reactive. We usually have more than one person acting as list moderators. -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Newest fad of Mass bug closings
On 20/04/08 at 03:55 +0200, Frans Pop wrote:
> On Sunday 20 April 2008, Frans Pop wrote:
> > I assume that in _all_ [1] cases an attempt is made to contact the
> > maintainers first?
> >
> > I also assume that this is only done after a package is also no longer in
> > stable or, as long as it is supported, in oldstable?
The closing doesn't mark the bug as fixed in stable, it only allows the
bug to be archived (and they can be unarchived if needed).
> Maybe in general it would be good to announce such actions on d-devel
> (and/or d-qa) before they are executed. After all, we also announce mass
> bug filings.
There's nothing new about those actions. Martin Michlmayr used to close
bugs in removed packages. But he stopped after BTS version-tracking was
introduced. Then he posted a RFH on [EMAIL PROTECTED], and Barry proposed to
help.
Now, a mistake was made in with nurd{5,6}. It's easy to fix it, just
reopen all the bugs, and mark them as notfound in the version used in
their -close message. It would have been a lot more helpful and less
demotivating to contact the one who closed the bugs instead of mailing
-devel@ with accusatory terms.
[1] http://lists.debian.org/debian-qa/2008/04/msg5.html
--
| Lucas Nussbaum
| [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |
signature.asc
Description: Digital signature
Re: Please think and test before setting a mailing list as "Maintainer:"
On 20/04/08 at 12:04 +0200, Rafael Laboissiere wrote: > Note that this works better when the list moderator is > reactive. We usually have more than one person acting as list moderators. The "listadmin" package is great if you want to moderate mailing lists without using mailman's web interface. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Package maintenance in $HOME os an NFS share? (best practices survey)
Fellow devs, I'm encountering a lot of bitching with using svn-inject (from svn-buildpackage) over an NFS share. A quick survey of fellow DDs told me that they don't build packages on an NFS share anyway but instead use their local disks. And - voila - svn-inject finally worked from a local disk. So I was generally questioning how I use NFS here. Of course it's faster to work from a completely local disk. No network latency (even though it's a LAN). My disks transport ~30 MB/sec whereas my 100 Mbps networks is limited to ~10 MB/sec. But it's convenient to have the files backed up to tape automatically on the server. And I can work on my laptop in the living room as well as on my workstation in the basement. So I'm wondering what other developers do. Are you using NFS at all? Are you putting all your work under repository control and check the files out to a local disk and back in to the server? I consider keeping $HOME on NFS but symlink $HOME/debian to /mnt/localdisk/debian or something like that. I'd love to learn how other developers handle this. Cheers Christoph -- When you do things right people won't be sure you've done anything at all. signature.asc Description: This is a digitally signed message part.
Re: Package maintenance in $HOME os an NFS share? (best practices survey)
Christoph Haas <[EMAIL PROTECTED]> writes: > So I'm wondering what other developers do. Are you using NFS at all? > Are you putting all your work under repository control and check the > files out to a local disk and back in to the server? I choose Bazaar http://bazaar-vcs.org/> where possible for version control of my software projects. It has many features, one of which is apropos here: "checkout" allows the best of both centralised-style VCS workflow when available and distributed repository workflow when offline. http://bazaar-vcs.org/Tutorials/CentralizedWorkflow> This allows me to work in checkouts on local hard drives whichever machine I happen to be working on, yet Bazaar keeps the central branch in sync (at each commit to the branch) with the local branch across the network, whenever it's available. When it's not, I commit locally, knowing that I can sync with the central branch later. So, it's almost what you say above, except that Bazaar takes care of the "out to a local disk and back in to the server" automatically, without losing the full benefits of distributed VCS. -- \ "I like to fill my bathtub up with water, then turn the shower | `\on and pretend I'm in a submarine that's been hit." -- Steven | _o__) Wright | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Package maintenance in $HOME os an NFS share? (best practices survey)
Hi Christoph,
> So I'm wondering what other developers do. Are you using NFS at all? Are
> you putting all your work under repository control and check the files out
> to a local disk and back in to the server? I consider keeping $HOME on NFS
> but symlink $HOME/debian to /mnt/localdisk/debian or something like that.
All the stuff I'm working on is on a server somewhere in the net (either
on alioth, sf.net, berlios,. or my own server), and whereever I want
to work on something I get a checkout and commit before switching
computers. To checkout things like the DPMT/PAPT repositories I have
small scripts, as I have a checkout of all trunks on my disk usually.
Here is an example snippet:
=schnipp==
URL=svn+ssh://svn.debian.org/svn/python-modules/packages
svn ls ${URL} | sed 's,/$,,' | while read dir; do
if [ -d ${dir} ]; then
svn up ${dir}
else
svn co ${URL}/${dir}/trunk ${dir}
fi
done
=schnapp==
NFS is something I avoid if possible.
Hope that helps,
Bernd
--
Bernd Zeimetz Debian GNU/Linux Developer
GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFH: Multiarch capable toolchain as release goal
> Why did I guess the name of binutils' maintainer correctly _before_ > looking into the PTS? You're not alone. > I bet that multiarch gets included into Ubuntu about two weeks after > we released lenny without multiarch. That's indeed the way the maintainer seems to work, and he keeps sitting on way too many packages, stopping progress in Debian. Thanks for the fish. Multiarch should indeed go into Lenny, please consider an exception for it. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Heads up: ffmpeg transition (SONAME Change!)
On Sun, Apr 20, 2008 at 12:29:20PM +0200, Steinar H. Gunderson wrote: > > [ffmpeg] > > For those of us not living in jurisdictions where software patents appear > very enforceable, is there currently any way to build our own, unstripped > packages? (Sort of like the DVD-CSS "example" script downloading and building > the right modules for you.) While requests for reviving non-US (non-JP non-DE) are heard from time to time, it's still not there :( For now, the best choice is the good old "debian-non-legal" repository available at http://debian-multimedia.org, thanks to great work by Christian Marillat. I don't think there is a reason to have downloaders for perfectly free software if you can have it properly packaged, with both binaries and source, at a place where the patent lobby doesn't rule. Too bad, that repository mixes free but patented pieces of software with outright undistributable ones (hence the "debian-non-legal" nickname), but unlike most repositories you don't need to worry about quality of packaging. And there's still hope for non-US-JP-DE... -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFH: Multiarch capable toolchain as release goal
On Sun, Apr 20, 2008 at 05:28:23PM +0200, Bernd Zeimetz wrote: > > I bet that multiarch gets included into Ubuntu about two weeks after > > we released lenny without multiarch. > > That's indeed the way the maintainer seems to work, and he keeps sitting > on way too many packages, stopping progress in Debian. Thanks for the fish. > > Multiarch should indeed go into Lenny, please consider an exception for it. Before you bring this to the tech ctte and such, don't you need a refusal by the maintainer? I mean, AFAIK on this issue the only response has been silence. And the usual way to deal with silence is to interpret it as lack of time rather than refusal (and accordingly send a polite offer to NMU). -- Robert Millan "The technological evasion of the license is as unacceptable as the legal evasion of the license [...]. That's the provision in section 1 regarding keys. [...] We say one thing: when you sell somebody a home... give him the keys" -- Eben Moglen on GPLv3 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
separate package for iotop?
Hi all, I was going to package iotop: http://guichaz.free.fr/misc/#iotop It is a simple Python script for displaying a top-like listing of the amount of I/O each process on the system is doing. I'm not sure if it warrants its own package or if there is another package it should be added to. Any thoughts? -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Heads up: ffmpeg transition (SONAME Change!)
"Steinar H. Gunderson" <[EMAIL PROTECTED]> writes: > For those of us not living in jurisdictions where software patents appear > very enforceable, is there currently any way to build our own, unstripped > packages? Yes, there is! The ffmpeg-free source package in experimental now ships a get-orig-source target, which respects the DEB_BUILD_OPTIONS variable. If you set that to 'risky' it will skip the 'stripping' part, and creates you a perfectly clean tarball without any disabled encoders. Moreover, if you build the source package with DEB_BUILD_OPTIONS set to 'risky', it will enable additional codecs. Too bad that ftpmaster doesn't consider such a tarball acceptable for non-free. If someone is willing to maintain, host and distribute such packages, please contact me privately. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: separate package for iotop?
Hi Paul, * Paul Wise <[EMAIL PROTECTED]> [2008-04-20 19:37]: > I was going to package iotop: > > http://guichaz.free.fr/misc/#iotop > > It is a simple Python script for displaying a top-like listing of the > amount of I/O each process on the system is doing. > > I'm not sure if it warrants its own package or if there is another > package it should be added to. As we already for example itop in the archive and I have no idea in which package this could be included I'd say go ahead and package it. Kind regards Nico -- Nico Golde - http://www.ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF For security reasons, all text in this mail is double-rot13 encrypted. pgpAIFyLyvHS5.pgp Description: PGP signature
Bug#475971: This is caused by LDFLAGS being set in the environment (by dpkg-buildpacakge)
After a bit of inspection, the root of this FTBFS seems to be dpkg-buildpackage having set LDFLAGS in the environment (even to an empty value, mind you). The generated Makefiles set 'LDFLAGS = -z,defs', and as LDFLAGS was previously in the environment, this new value is exported to processes spawned from make. Python's distutils honour LDFLAGS, and when building the python extension passes -z,defs to the linker, and the build obviously bombs. I guess the solution is to accept LDFLAGS is to be exported, and to make the part that builds python be robust against that. CCing -devel as a generic place so that reading it may save somebody somewhere some work some day. ;) Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
Re: separate package for iotop?
[Paul Wise] > I'm not sure if it warrants its own package or if there is another > package it should be added to. > > Any thoughts? Perhaps along with top in procps? Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#475971: This is caused by LDFLAGS being set in the environment (by dpkg-buildpacakge)
Adeodato Simó wrote: > After a bit of inspection, the root of this FTBFS seems to be > dpkg-buildpackage having set LDFLAGS in the environment (even to an > empty value, mind you). Two of my packages were affected by this uglyness, too. If you use LDFLAGS as _make_ variable to build up the linker flags you need, for some reason this _make_ variable is now exported into the environment, resulting in this weirdness. I'm not sure where the sense behind all this is - I prety much know when I want to have such flags in the environment or not, there's no need that dpkg helps me with that. For one package I used unset on all this environment nonsense in the build target, for one LDFLAGS was renamed to LINKER_FLAGS. I'm pretty much annoyed that those hacks are necesary at all. Just another, untested change in dpkg which resulted in a lot of unnecessary FTBFSs. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFH: Multiarch capable toolchain as release goal
Robert Millan <[EMAIL PROTECTED]> writes: > On Sun, Apr 20, 2008 at 05:28:23PM +0200, Bernd Zeimetz wrote: >> > I bet that multiarch gets included into Ubuntu about two weeks after >> > we released lenny without multiarch. >> >> That's indeed the way the maintainer seems to work, and he keeps sitting >> on way too many packages, stopping progress in Debian. Thanks for the fish. >> >> Multiarch should indeed go into Lenny, please consider an exception for it. > > Before you bring this to the tech ctte and such, don't you need a > refusal by the maintainer? I mean, AFAIK on this issue the only > response has been silence. And the usual way to deal with silence > is to interpret it as lack of time rather than refusal (and > accordingly send a polite offer to NMU). It is normally polite to ask. However, there are (as I'm sure we are all aware) a number of developers who don't communicate with the rest of the project *at all*, bar the occasional announcement. Trying to discuss or collaborate with these few is nigh on impossible--and I have in some cases been trying for several years, and have yet to get even *one* reply to my mail and patches! It's like chucking them into a black hole! If you do want to wait for permission/refusal, you might find you never get a reply and end up waiting forever. So, why not wait long enough for a reply, say a fortnight, and then go ahead and hijack it after that if you have no response (and tell them in the mail that this is what you will do). Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. pgpfwU9L7JIoo.pgp Description: PGP signature
Re: Bug#475971: This is caused by LDFLAGS being set in the environment (by dpkg-buildpacakge)
* Bernd Zeimetz [Sun, 20 Apr 2008 22:03:54 +0200]: > Adeodato Simó wrote: > > After a bit of inspection, the root of this FTBFS seems to be > > dpkg-buildpackage having set LDFLAGS in the environment (even to an > > empty value, mind you). > If you use LDFLAGS as _make_ variable to build up the linker flags you > need, for some reason this _make_ variable is now exported into the > environment Because it was *previously* in the environment, and make just changes its value. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org As scarce as truth is, the supply has always been in excess of the demand. -- Josh Billings -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477080: ITP: omnicodec -- data encoding and decoding command line utilities
Package: wnpp Severity: wishlist Owner: Magnus Therning <[EMAIL PROTECTED]> * Package name: omnicodec Version : 0.1 Upstream Author : Magnus Therning <[EMAIL PROTECTED]> * URL : http://hackage.haskell.org/cgi-bin/hackage-scripts/package/omnicodec * License : GPL Programming Lang: Haskell Description : data encoding and decoding command line utilities Two simple command line tools for encoding and decoding data. The following data encodings are implemented: Uuencode, Base64, Base64Url, Base32, Base32Hex, and Base16. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Augmentez votre pouvoir d achat - Etude en ligne gratuite
( "_blank" ) ( "_blank" ) Carte de Crédit, Prêt Personnel, Prêt Voiture, Prêt Travaux, Prêt Immobilier, Dette Familiale, Découvert Bancaire, Impôt et autres ( "_blank" ) Exemple détaillé d'une proposition Partners Finances, cliquez ici ( "_blank" ) ( "_blank" ) ( "_blank" ) ( "_blank" ) Aucun versement de quelque nature que ce soit, ne peut être exigé dun particulier, avant lobtention dun ou de plusieurs prêts dargent. 1) Prêt hypothécaire BNPII sur une durée prévisionnelle de 20 ans, le taux sera fixe pendant les 12 premiers mois pour une mensualité de 876,09 , puis sera révisable et indexé sur lEuribor 3 mois (taux interbancaire offert en Europe) + partie fixe (marge Invest Immo). Possibilité à la fin de la période dopter pour un taux fixe. Le TEG annuel prévisionnel (à la date démission de loffre de prêt) sera de 5,46 % et le coût total prévisionnel du crédit de 82511,60 (frais de dossier, frais dacte et frais de mandat inclus, hors assurance facultative). Taux en vigueur le 01/07/2007. Durée possible de 8 à 30 ans. 2) Sous réserve dacceptation de votre dossier par BNPII. Tout document publicitaire ou tout document d'information remis à l'emprunteur et portant sur l'une des opérations visées à l'article L 312-2 doit mentionner que lemprunteur dispose dun délai de réflexion de 10 jours. La vente est subordonnée à lobtention du prêt ; si celui-ci nest pas obtenu, le vendeur doit lui rembourser les sommes versées. Conformément à la loi « informatique et liberté » du 6 janvier 1978, vous disposerez d'un droit d'accès, de rectification, de suppression et d'opposition sur les données personnelles vous concernant. Il vous suffit pour lexercer, de nous écrire à ladresse suivante : MB Finances, 16 rue Victor Hugo BP 70583 54000 Nancy. 3) Les frais représentent les indemnités de remboursement anticipé, les frais de notaire, les frais de dossier et la commission de courtage. PARTNERS FINANCES : RCS Nancy B 404 681 496 Intermédiaire en opérations bancaires. Mandants : CGI Lille. BNP Paribas Invest Immo Puteaux. GE Money Bank La Défense Paris. Protection des données personnelles: Vous êtes légalement enregistré dans un fichier déclaré à la CNIL (n° 806690) Vous bénéficiez d'un droit d'accès aux données vous concernant et vous pouvez demander à ne plus figurer dans ce fichier sur simple demande par email en précisant si possible la liste des emails à désabonner. (adresse e-mail inscrite: "debian-devel@lists.debian.org") Pour vous desinscrire : cliquez ici ( "http://www.champ-reduit.com/remove2.htm"; )
Re: RFH: Multiarch capable toolchain as release goal
[Roger Leigh] > If you do want to wait for permission/refusal, you might find you > never get a reply and end up waiting forever. So, why not wait long > enough for a reply, say a fortnight, and then go ahead and hijack it > after that if you have no response (and tell them in the mail that > this is what you will do). I agree that this is the way to handle such situations. It is not acceptable to be in a situation where one might need to wait indefinitely, so a deadline for responses should be stated and the resulting action that will be taken if no response is received should be explained. Silence should not be able to block progress. But it is also a good idea to try to get a response, to avoid confusion and potential conflicts. I believe this is the reason the hijack procedure states that one need to announce ones intention on [EMAIL PROTECTED] :) Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: separate package for iotop?
In article <[EMAIL PROTECTED]> you wrote: >> I'm not sure if it warrants its own package or if there is another >> package it should be added to. >> >> Any thoughts? > > Perhaps along with top in procps? The python dependency should not be introduced - so if we dont have a python based system management package, it might be good to start one. Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFH: Multiarch capable toolchain as release goal
Le Sun, Apr 20, 2008 at 05:49:07PM +0200, Robert Millan a écrit : > > Before you bring this to the tech ctte and such, don't you need a refusal > by the maintainer? Hello, It reminds me when I had to deal with a DD who thought he orphaned a package, but did not. It lead to a situation where a few monthes were lost: the maintainer was not answering because he thought he was not the maintainer, and I had to wait for the answer of the maintainer because of Policy 10.1 (conflict over binary file names). Luckily, the package was removed... I think that the morale of the story is that when enough time passed with no anwer, sticking to the rules might not help. (alternatively, it could be that the rules need to define a timeout...) Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477106: ITP: codecgraph -- generate a routing graph for an Intel-HDA codec
Package: wnpp Severity: wishlist Owner: William Pitcock <[EMAIL PROTECTED]> * Package name: codecgraph Version : 20080406 Upstream Author : Eduardo Habkost <[EMAIL PROTECTED]> * URL : http://helllabs.org/codecgraph/ * License : GPLv2 Programming Lang: Python Description : generate a routing graph for an Intel-HDA codec codecgraph is a utility used to generate an SVG graph of an HDA codec's routing paths. It is useful for debugging audio problems relating to Intel-HDA codecs. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
cupsddk - stolen WNPP - policy violation
Hello, I am concerned about 'cupsddk' which recently passed NEW. On 25th of march I contacted pkg-cups for joining the team and working on cupsddk [1] since I am about to repackage 'splix' (a driver for samsung laser printers). Martin Pitt did not accept my request for NO reason and told me to work together with the Ubuntumaintainer of the package. Since Till Kamppeter did not respond and since his Ubuntu package was more like a hack than a debian-like package as far as quality and policy is concerned, I started to work on the package. Now, I was just about to upload it to mentors but then realized that it has been uploaded to sid already. Not just that the uploader/sponsor (probably Mark Purcell) turned a blind eye to the WNPP and _my_ response that I'll take it *[2]* ... the package also violates debian policy as far as the copyright file is concerned (which is a RC-bug which I am going to file soon). And even not to mention that it is mainly the Ubuntu package which is rather crappy as far as 'packaging style' is concerned. But - back to the actual topic: Is this common sense in debian? Not respecting responses to WNPP's and even ignoring volunteers work? I am gutted! *[1]* - http://lists.alioth.debian.org/pipermail/pkg-cups-devel/2008-March/005113.html *[2]* - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=468911 regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cupsddk - stolen WNPP - policy violation
Patrick Ringl wrote: But - back to the actual topic: Is this common sense in debian? Not respecting responses to WNPP's and even ignoring volunteers work? I am gutted! It is common practice to retitle the RFP (request for packaging) to ITP (intend to package) and changing the owner of the ITP to your email address, if you want to take over the packaging. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: separate package for iotop?
On 20-Apr-08, 16:33 (CDT), Bernd Eckenfels <[EMAIL PROTECTED]> wrote: > In article <[EMAIL PROTECTED]> you wrote: > >> I'm not sure if it warrants its own package or if there is another > >> package it should be added to. > >> > >> Any thoughts? > > > > Perhaps along with top in procps? > > The python dependency should not be introduced - so if we dont have a python > based system management package, it might be good to start one. But it could be a Suggests, since it's only one of several utilities in the package. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Package maintenance in $HOME os an NFS share? (best practices survey)
Hi Christoph, On Sun, Apr 20, 2008 at 03:47:38PM +0200, Christoph Haas wrote: > I'm encountering a lot of bitching with using svn-inject (from > svn-buildpackage) over an NFS share. A quick survey of fellow DDs told me of which kind? Personally I do use svn-buildpackage on a NFSv4 mounted home directory and I don't have serious problems (except that it is badly slow, but thats the fault of the underlying RAID which has a write performance problem, because the controller (3ware 9550SX) is obviously not the best you can buy). It works fine, as far as I am concerned. > So I'm wondering what other developers do. Are you using NFS at all? Are > you putting all your work under repository control and check the files out > to a local disk and back in to the server? I consider keeping $HOME on NFS > but symlink $HOME/debian to /mnt/localdisk/debian or something like that. I do so for very large checkouts, because a checkout to my HOME is very slow (about 10 minutes for a ~ 200MB working copy where the checkout to /tmp (which is on local disk) takes about 2 minutes) due to our RAID problems. Otherwise I just use the NFS home and its fine. Best Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFH: Multiarch capable toolchain as release goal
On Sun, Apr 20, 2008 at 09:06:15PM +0100, Roger Leigh wrote: > Robert Millan <[EMAIL PROTECTED]> writes: > > > On Sun, Apr 20, 2008 at 05:28:23PM +0200, Bernd Zeimetz wrote: > >> > I bet that multiarch gets included into Ubuntu about two weeks after > >> > we released lenny without multiarch. > >> > >> That's indeed the way the maintainer seems to work, and he keeps sitting > >> on way too many packages, stopping progress in Debian. Thanks for the fish. > >> > >> Multiarch should indeed go into Lenny, please consider an exception for it. > > > > Before you bring this to the tech ctte and such, don't you need a > > refusal by the maintainer? I mean, AFAIK on this issue the only > > response has been silence. And the usual way to deal with silence > > is to interpret it as lack of time rather than refusal (and > > accordingly send a polite offer to NMU). > > It is normally polite to ask. However, there are (as I'm sure we are > all aware) a number of developers who don't communicate with the rest > of the project *at all*, bar the occasional announcement. Trying to > discuss or collaborate with these few is nigh on impossible--and I > have in some cases been trying for several years, and have yet to get > even *one* reply to my mail and patches! It's like chucking them into > a black hole! > > If you do want to wait for permission/refusal, you might find you > never get a reply and end up waiting forever. So, why not wait long > enough for a reply, say a fortnight, and then go ahead and hijack it > after that if you have no response (and tell them in the mail that > this is what you will do). > > > Regards, > Roger Is there a guideline or policy for such hard-to-reach Developers with regard to hi-jacking or NMU? -K -- | .''`. == Debian GNU/Linux == | my web site: | | : :' : The Universal |mysite.verizon.net/kevin.mark/| | `. `' Operating System| go to counter.li.org and | | `-http://www.debian.org/ |be counted! #238656 | | my keyserver: subkeys.pgp.net | my NPO: cfsg.org | |join the new debian-community.org to help Debian! | |___ Unless I ask to be CCd, assume I am subscribed ___| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
