Re: RFS: miredo
On Fri, 29 Jan 2010, Rémi Denis-Courmont wrote: Hello, Asheesh Laroia wrote: On Wed, 27 Jan 2010, Remi Denis-Courmont wrote: Package: wnpp Severity: normal Hello, I request assistance with maintaining the miredo package. The last update has unfortunately introduced a severe regression. That bug was upstream, but that's hardly an excuse since I am upstream too. In the mean time, I have lost contact of my sponsor (no answer from emails and IRC), and haven't been able to get a new on debian-mentors. miredo is awesome. I'm paulprot...@debian.org and paulproteus on IRC and I would love to sponsor uploads and make sure miredo in Debian is as good as possible. Great, thanks! Could you check if http://mentors.debian.net/debian/pool/main/m/miredo/miredo_1.2.2-1.dsc is OK? Yves-Alexis Perez wrote: What exactly do you need? Sponsorship, testing, or more active packaging stuff? I just need a new sponsor or a DD co-maintainer. Packaging is OK. Testing is always welcome but I don't particularly need it at this point. Hey! Looks pretty good. A few questions: * What's with the patch to src/main.c? It'd be nice if you'd explain it in debian/changelog or something. * What's the regression that "upstream" introduced that you were concerned about? * Have you tried building it in a clean pbuilder? That doesn't work for me. Here's the log: gpgv: keyblock resource `/tmp/buildd/.gnupg/trustedkeys.gpg': file open error gpgv: Signature made Wed Jan 20 17:36:51 2010 UTC using DSA key ID DD6D12BD gpgv: Can't check signature: public key not found dpkg-source: warning: failed to verify signature on ./miredo_1.2.2-1.dsc dpkg-source: info: extracting miredo in miredo-1.2.2 dpkg-source: info: unpacking miredo_1.2.2.orig.tar.gz dpkg-source: info: applying miredo_1.2.2-1.diff.gz dpkg-source: info: upstream files that have been modified: miredo-1.2.2/src/main.c I: Building the package dpkg-buildpackage: set CFLAGS to default value: -g -O2 dpkg-buildpackage: set CPPFLAGS to default value: dpkg-buildpackage: set LDFLAGS to default value: dpkg-buildpackage: set FFLAGS to default value: -g -O2 dpkg-buildpackage: set CXXFLAGS to default value: -g -O2 dpkg-buildpackage: source package miredo dpkg-buildpackage: source version 1.2.2-1 dpkg-buildpackage: source changed by Rémi Denis-Courmont dpkg-buildpackage: host architecture i386 fakeroot debian/rules clean test -x debian/rules dh_testroot /usr/bin/make -C . -k distclean make[1]: Entering directory `/tmp/buildd/miredo-1.2.2' make[1]: *** No rule to make target `distclean'. make[1]: Leaving directory `/tmp/buildd/miredo-1.2.2' make: [makefile-clean] Error 2 (ignored) rm -f debian/stamp-makefile-build for i in ./admin/config.guess ./admin/config.sub ./admin/config.rpath ; do \ if test -e $i.cdbs-orig ; then \ mv $i.cdbs-orig $i ; \ fi ; \ done rm -f debian/cdbs-install-list debian/cdbs-package-list dh_clean rm -f debian/stamp-autotools-files rm -f stamp-autoreconf dpkg-source -b miredo-1.2.2 dpkg-source: info: using source format `1.0' dpkg-source: info: building miredo using existing miredo_1.2.2.orig.tar.gz dpkg-source: info: building miredo in miredo_1.2.2-1.diff.gz dpkg-source: warning: the diff modifies the following upstream files: src/main.c dpkg-source: info: use the '3.0 (quilt)' format to have separate and documented changes to upstream files, see dpkg-source(1) dpkg-source: info: building miredo in miredo_1.2.2-1.dsc debian/rules build test -x debian/rules mkdir -p "." autoreconf -fi autopoint: *** cvs program not found autopoint: *** Stop. autoreconf: autopoint failed with exit status: 1 make: *** [stamp-autoreconf] Error 1 dpkg-buildpackage: error: debian/rules build gave error exit status 2 E: Failed autobuilding of package I: unmounting dev/pts filesystem I: unmounting proc filesystem I: cleaning the build env I: removing directory /var/cache/pbuilder/build//17397 and its subdirectories So I guess you're missing a build dependency. Weird, though, since it looks more like autoreconf is the one missing the build dependency? If you'd like help with any of this, e.g. setting up a pbuilder, let me know! -- Asheesh. -- If you really want pure ASCII, save it as text... or browse it with your favorite browser... -- Alexandre Maret
Bug#567954: RFH: debtags -- Enables support for package tags
Package: wnpp Severity: normal I request assistance with maintaining the debtags package. What I would like is a comaintainer who takes care of the everday packaging chores (for example, redoing the fetch script to fix #481634 and #478590, or fixing the manpage in #542525). I am looking for someone who already has packaging experience. The package description is: debtags provides a system to download a database of package tags and keep it up to date. A package tag is a small label that gets attached to a Debian package to represent one of its qualities. . A package tag database in the system can enable advanced package search techniques, and advanced package browsing functions in programs that support it. . This package has been made as a way to deploy and test package tags support until it gets integrated in the normal Debian workflow. Ciao, Enrico -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#567955: RFH: apt-xapian-index -- maintenance tools for a Xapian index of Debian packages
Package: wnpp Severity: normal I request assistance with maintaining the apt-xapian-index package. What I would like is a comaintainer who takes care of the everday packaging chores (for example, testing and applying the patch for #547074 and fixing #562078). I am looking for someone who already has packaging experience. The package description is: This package provides update-apt-xapian-index, a tool to maintan a Xapian index of Debian package information in /var/lib/apt-xapian-index. . update-apt-xapian-index allows plugins to be installed in /usr/share/apt-xapian-index to index all sorts of extra information, such as Debtags tags, popcon information, package ratings and anything else that would fit. . The index generated by update-apt-xapian-index is self-documenting, as it contains an autogenerated README file with information on the index layout and all the data that can be found in it. Ciao, Enrico -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debian policy update (3.8.4.0)
(Please cc me on this thread, I'm not subscribed to debian-devel.)
Goswin wrote:
> Looks fine from here. How does your -dev package look? The .so link, .la
> and .pc files (if any) are specifically important.
The -dev package has no Multi-Arch field, which seems to be how the multiarch
spec on the Ubuntu wiki intends things to be done? As such, I'm still using
/usr/lib for the -dev part.
It'd be somewhat more complex to rearrange things for a multiarch -dev package,
but could be done; I assume the recommended way to do that would be to use
"./configure --libdir=/usr/lib/${DEB_HOST_GNU_TYPE}"?
libdbus is probably an interesting example if you want to do that because it
has one architecture-dependent header file, which it places in ${libdir}, and
keeps the rest of /usr/include architecture-independent.
For the actual change I made, please see pkg-utopia svn or this commit mail:
http://lists.alioth.debian.org/pipermail/pkg-utopia-commits/2010-January/003534.html
The -dev package currently contains:
> /.
> /usr
> /usr/share
> /usr/share/doc
> /usr/share/doc/libdbus-1-dev
> /usr/share/doc/libdbus-1-dev/AUTHORS [and other docs]
> /usr/lib
> /usr/lib/libdbus-1.a
> /usr/lib/pkgconfig
> /usr/lib/pkgconfig/dbus-1.pc
> /usr/lib/dbus-1.0
> /usr/lib/dbus-1.0/include
> /usr/lib/dbus-1.0/include/dbus
> /usr/lib/dbus-1.0/include/dbus/dbus-arch-deps.h
> /usr/include
> /usr/include/dbus-1.0
> /usr/include/dbus-1.0/dbus
> /usr/include/dbus-1.0/dbus/dbus-bus.h [and other headers]
> /usr/lib/libdbus-1.so
There's no .la file.
Development symlink:
> lrwxrwxrwx 1 root root 38 Jan 27 23:49 /usr/lib/libdbus-1.so ->
> /lib/i486-linux-gnu/libdbus-1.so.3.4.0
.pc file:
> prefix=/usr
> exec_prefix=${prefix}
> libdir=${exec_prefix}/lib
> includedir=${prefix}/include
> system_bus_default_address=unix:path=/var/run/dbus/system_bus_socket
> sysconfdir=/etc
> session_bus_services_dir=/usr/share/dbus-1/services
> daemondir=/usr/bin
>
> Name: dbus
> Description: Free desktop message bus
> Version: 1.2.16
> Libs: -L${libdir} -ldbus-1 -lpthread -lrt
> Cflags: -I${includedir}/dbus-1.0 -I${libdir}/dbus-1.0/include
I'd also be happy to multiarchify libgfshare (a small library using autotools
and debhelper 7) if that would make a useful example of how to do the simple
case; it's in collab-maint bzr, and you're welcome to commit there if that
would help. I'd also be happy to migrate it to collab-maint git (which
I've considered doing anyway) if that's easier for you to deal with.
Regards,
Simon
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#566586: policykit-1: Please ship with a new empty group granted all permissions on console
On Sun, Jan 24, 2010 at 02:54:07AM +0100, Michael Biebl wrote: > On 24.01.2010 00:39, Josh Triplett wrote: > > Package: policykit-1 > > Version: 0.96-1 > > Severity: wishlist > > > > policykit-1 supports specifying permissions for groups, not just > > individual users. > > > > Thus, please consider shipping policykit-1 with a .pkla file granting > > all permissions (when on the console) to a new empty group. > > The administrator can add users to this group to let them authenticate > > via policykit without a password. > > > > (Arguably, users in the "sudo" group, as root-equivalent users, ought to > > have this permission, but it seems safest to have a unique group > > specific to policykit-1.) > > I agree that something like this would be nice. > > Ubuntu traditionally uses a system group "admin" for this kind of purpose. > Maybe this concept of a global group of "priviledged" is something we might > want > in Debian as well and warrrants some wider discussion? Quite possibly. I don't think it makes sense to introduce such a concept without it meaning "root-equivalent", though; otherwise, it becomes very difficult to figure out whether members of that group should have any particular permission. Saying that the group should mean "root-equivalent" means it ought to have any and all permissions, though in some cases with an additional step required before getting dangerous ones. I seem to recall past discussions in Debian that didn't particularly favor the concept, though I don't recall the reasons. > Are you interested in starting such a discussion (e.g. on debian-devel) and > get > further input on this topic from a wider audience? Done. :) - Josh Triplett -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Better tracebacks for C/C++ (and probably Ada & Fortran, too)
* Daniel Jacobowitz: > On Sun, Jul 26, 2009 at 12:42:46AM +0200, Florian Weimer wrote: >> I've built a small proof-of-concept library which creates Java-style >> tracebacks for C and C++ programs. In contrast to libc's backtrace() >> function, it uses DWARF debugging information when available, so the >> output is generally quite useful. Debugging information is extracted >> from the main executable and any loaded DSOs, or from the shadow debug >> tree in /usr/lib/debug. > > Can't you do this just by forking addr2line and providing a shim layer > that knows shared library load offsets? That saves you the really > grotty bits. Thanks for the suggestion. At least for tracebacks on crashes, this seems to be an approach which works really well. addr2line can even generate virtual frames for inlined functions. There are some drawbacks, though: addr2line doesn't print a separator if it generates multiple frames, so it is necessary to invoke it with a single address if you want to use the inlining data. Resolving symbols in libstdc++ doesn't work automatically for some reason (I have to pass the /usr/lib/debug file as a workarond). addr2line on libstdc++ locations is quite slow, it adds a noticeable delay to the traceback printing. The build root/relative path distinction sometimes present in the DWARF debugging information is not preserved. There does not seem to be much control over the demangling; for instance, I would rather use the plain, fully-qualified function name (without argument types) if source line information is also available. And there's the fundamental issue of spawning a child process from a library inside a multi-threaded program. If this happens due to a globally unhandled exception, this does not matter, but it also means that this facility is not as a general-purpose as I'd want. But all in all, addr2line is a win. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bits from the Mozilla Extension Packaging Team
Hi, This mail targets all developers, which maintain Mozilla extensions. Source package name === The source package name for extension should not contain the name of the enhanced application. These prefixes should be dropped from the source name: firefox- iceape- icedove- iceweasel- mozilla- thunderbird- If the remaining string is too generic (for example, notify or sage), the source package name should append -extension. For example, firefoxnotify was renamed to notify-extension. Binary package name === The Mozilla extension packaging team decided to use xul-ext- (instead of mozilla-, iceweasel-, etc.) as prefix for all Mozilla extensions [1]. This will group the extensions visually. There are currently 18 extensions that use this naming scheme already. Please rename the binary package if not already done. Use mozilla-devscripts == To make packaging extensions dead simple we have mozilla-devscripts. In most cases debian/rules can be reduces to three or four lines (shebang, two includes and maybe one variable). We highly recommend using it. An additional benefit of using mozilla-devscripts is that derived distribution can use the source code without modifying it. mozilla-devscripts take care of the distributions specialities. The usage is explained in the Wiki [2]. Joining our team You are welcome to join our team. We maintain all packages in git in the pkg-mozext group. You can contact us via email or IRC [3]. Please let us know, if you need help implementing the above mentioned items. Work needing package Here is a list of source package that need to updated. Please let me know, if I missed some packages. beagle biofox ctxextensions diggler firegpg foxyproxy icedove-attachmentreminder icedove-gcontactsync icedove-quotecolors iceweasel-downthemall imagezoom livehttpheaders mozilla-dom-inspector mozilla-noscript mozvoikko nostalgy nukeimage vimperator [1] http://wiki.debian.org/Mozilla/ExtensionsPolicy [2] http://wiki.debian.org/mozilla-devscripts [3] http://wiki.debian.org/Teams/DebianMozExtTeam -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: correct/ideal way to obtain root from a shell script
On Mon, Feb 01, 2010 at 07:30:23PM +, Jon Dowland wrote: > gdp, by default, invokes dpkg to install the generated .deb > file. > > > I’ve been asking to move su-to-root to xdg-utils or > > debianutils, but the situation is still stuck. > > That sounds sensible. Is there anything I can do to help? Simply depends on the menu package which provide su-to-root, or manage to convince xdg-utils upstream to provide xdg-su instead of asking everyone to switch to policykit ? > It looks like there might need to be a bit more > join-the-dots between su-to-root and d-i's "disable root" > question (to prime $SU_TO_ROOT_SU properly) We need a solution that still works if user enable root password and disable sudo after installation. Shadow will note tell you whether root has a password or not. Maybe menu should have a debconf question (do you use sudo ?) that will be prefilled by d-i. Technical advices and patches welcome. Cheers, (Please CC me if you want an answer). -- Bill. Imagine a large red swirl here. signature.asc Description: Digital signature
Re: Debian policy update (3.8.4.0)
Simon McVittie writes:
> (Please cc me on this thread, I'm not subscribed to debian-devel.)
>
> Goswin wrote:
>> Looks fine from here. How does your -dev package look? The .so link, .la
>> and .pc files (if any) are specifically important.
>
> The -dev package has no Multi-Arch field, which seems to be how the multiarch
> spec on the Ubuntu wiki intends things to be done? As such, I'm still using
> /usr/lib for the -dev part.
Initialy yes. But esspecially for cross compiles multiarch dev packages
would be nice. But that will need more developement.
> It'd be somewhat more complex to rearrange things for a multiarch -dev
> package,
> but could be done; I assume the recommended way to do that would be to use
> "./configure --libdir=/usr/lib/${DEB_HOST_GNU_TYPE}"?
How do you get the libs into /usr/lib/${DEB_HOST_GNU_TYPE} currently? If
your library uses any plugins then you need to compile it for
/usr/lib/${DEB_HOST_GNU_TYPE} and not just move the files there post
build.
> libdbus is probably an interesting example if you want to do that because it
> has one architecture-dependent header file, which it places in ${libdir}, and
> keeps the rest of /usr/include architecture-independent.
Architecture dependent header files belong under
/usr/include/triplet/
That directory is searched by default in gcc so it works without extra
-I option. Preferable to ${libdir}. But dbus screws that up as well as
it uses a subdir for its files.
> .pc file:
>> prefix=/usr
>> exec_prefix=${prefix}
>> libdir=${exec_prefix}/lib
>> includedir=${prefix}/include
>> system_bus_default_address=unix:path=/var/run/dbus/system_bus_socket
>> sysconfdir=/etc
>> session_bus_services_dir=/usr/share/dbus-1/services
>> daemondir=/usr/bin
>>
>> Name: dbus
>> Description: Free desktop message bus
>> Version: 1.2.16
>> Libs: -L${libdir} -ldbus-1 -lpthread -lrt
>> Cflags: -I${includedir}/dbus-1.0 -I${libdir}/dbus-1.0/include
Cflags: -I${includedir}/dbus-1.0 -I${includedir}/i486-linux-gnu/dbus-1.0
Would be better but your solution is policy conform too I think.
> I'd also be happy to multiarchify libgfshare (a small library using autotools
> and debhelper 7) if that would make a useful example of how to do the simple
> case; it's in collab-maint bzr, and you're welcome to commit there if that
> would help. I'd also be happy to migrate it to collab-maint git (which
> I've considered doing anyway) if that's easier for you to deal with.
>
> Regards,
> Simon
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the Mozilla Extension Packaging Team
Benjamin Drung wrote the following on 01.02.2010 20:34 Hello I would like to ask 2 question as user regarding your proposal. -- -- > Binary package name > === > > The Mozilla extension packaging team decided to use xul-ext- (instead of > mozilla-, iceweasel-, etc.) as prefix for all Mozilla extensions [1]. > This will group the extensions visually. There are currently 18 > extensions that use this naming scheme already. Please rename the binary > package if not already done. -- -- > Joining our team > > > You are welcome to join our team. We maintain all packages in git in the > pkg-mozext group. You can contact us via email or IRC [3]. Please let us > know, if you need help implementing the above mentioned items. Question 1: You propose to use the prefix "xul-ext-" which is more generic i guess but the itself is called "pkg-mozext". Is that "moz" in the team name for historic reasons? Or is it planed to rename it "pkg-xul-ext" Team? It just sounds strange because these two are contradictory to your proposal. > Work needing package > > > Here is a list of source package that need to updated. Please let me > know, if I missed some packages. > > beagle > biofox > ctxextensions > diggler > firegpg > foxyproxy > icedove-attachmentreminder > icedove-gcontactsync > icedove-quotecolors 2nd question: In the good old days (when ever these were) someone like a short sighted person like me could search via apt or aptitude for *compatible* extentions to his application. Now does it mean, that all those xulrunner based apps can make use the same extensions? e.g. does ist make sens to use "xul-ext-quotecolors" with iceweasle? Realy i don't get so please explain a bit more deeply. regards -- bye Thilo 4096R/0xC70B1A8F 721B 1BA0 095C 1ABA 3FC6 7C18 89A4 A2A0 C70B 1A8F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
[RFC] Collecting changelog entries in projectb
Hi, FTP team and I are currently writing a new feature in dak which will collect changelog entries and store them in projectb, to be later used for other purposes (e.g. to write point release changelogs, see [1]). Collecting every changelog entry takes lots of space (the whole past adds up to 7GB), so we thought to limit that to policy queues only (right now stable-proposed-uploads and oldstable-proposed-uploads), unless there is a valid reason to do for every upload in the archive. Can you imagine a useful thing that is worth having every entry in projectb? If so, here's your chance :) [1] http://ftp.debian.org/debian/dists/lenny/ChangeLog -- .''`. : :' : Luca Falavigna `. `' `- signature.asc Description: PGP signature
Re: Bits from the Mozilla Extension Packaging Team
On Mon, Feb 1, 2010 at 3:34 PM, Thilo Six wrote: > Benjamin Drung wrote the following on 01.02.2010 20:34 >> icedove-quotecolors > > 2nd question: > In the good old days (when ever these were) someone like a short sighted > person like me could search via apt or aptitude for *compatible* extentions > to his application. > Now does it mean, that all those xulrunner based apps can make use the same > extensions? > e.g. does ist make sens to use "xul-ext-quotecolors" with iceweasle? It does make sense to use xul-ext-quotecolors with iceape, even though the current package forces icedove usage. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the Mozilla Extension Packaging Team
Am Montag, den 01.02.2010, 21:34 +0100 schrieb Thilo Six: > Question 1: > You propose to use the prefix "xul-ext-" which is more generic i guess but > the itself is called "pkg-mozext". > Is that "moz" in the team name for historic reasons? Yes, it's only for historic reasons. > Or is it planed to rename it "pkg-xul-ext" Team? There is currently no plans to rename the team, but it's worth thinking about it. What do the other team member think about it? > 2nd question: > In the good old days (when ever these were) someone like a short sighted > person like me could search via apt or aptitude for *compatible* extentions > to his application. > Now does it mean, that all those xulrunner based apps can make use the same > extensions? > e.g. does ist make sens to use "xul-ext-quotecolors" with iceweasle? The extension must support the xulrunner based apps. quotecolors will support the same amount of xulrunner based apps after the rename. According to upstream it does not work with iceweasel. > Realy i don't get so please explain a bit more deeply. When using mozilla-devscripts, the extension will enhance the supported xulrunner apps and provide xulapt-extname. In the case of xul-ext-quotecolors, it will enhance icedove and provide icedove-quotecolors. So are still able to run "apt-get install icedove-quotecolors" or "apt-get install iceweasel-adblock-plus". -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Bits from the Mozilla Extension Packaging Team
Am Montag, den 01.02.2010, 15:48 -0500 schrieb James Vega: > On Mon, Feb 1, 2010 at 3:34 PM, Thilo Six wrote: > > Benjamin Drung wrote the following on 01.02.2010 20:34 > >> icedove-quotecolors > > > > 2nd question: > > In the good old days (when ever these were) someone like a short sighted > > person like me could search via apt or aptitude for *compatible* extentions > > to his application. > > Now does it mean, that all those xulrunner based apps can make use the same > > extensions? > > e.g. does ist make sens to use "xul-ext-quotecolors" with iceweasle? > > It does make sense to use xul-ext-quotecolors with iceape, even though > the current package forces icedove usage. With mozilla-devscripts, the package would recommend "icedove | iceape" on Debian (and "thunderbird | seamonkey" on Ubuntu). So you wouldn't be forced to install icedove. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Bits from the Mozilla Extension Packaging Team
Benjamin Drung wrote the following on 01.02.2010 21:50 Thanks both Benjamin and James for your replys. I gone a live with it. -- bye Thilo 4096R/0xC70B1A8F 721B 1BA0 095C 1ABA 3FC6 7C18 89A4 A2A0 C70B 1A8F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
SCALE 8x Debian Booth 2/20-21/2010 (Los Angeles, at Westin LAX)
[This isn't really on topic for -user or -devel; please send followup mail to me privately or to debian-events...@lists.debian.org. I'm only sending it to those lists to get a wider audience than -events-na.] Debian has a booth at the SCALE 8x conference in Los Angeles at the Westin LAX from the 20th to the 21st of February. I'm organizing the booth again, but I need additional people to help answer questions and participate in the booth. I plan on having some burned DVDs and CDs to hand out, but additional ideas for demos and/or presentations would be really awesome. If you can help out (even for just a few hours), please mail me privately giving your name, your association with Debian,[1] the times that you can work, and your registration number from filling out a "Full Access Pass" at https://www.socallinuxexpo.org/reg7/ [I'll complete the process, so don't pay for your ticket.] Don Armstrong 1: Anyone is welcome to help, but the exhibitor passes I have will go preferentially to those who are DDs or otherwise contribute to Debian and can dedicate the most time to helping in the booth. -- G: If we do happen to step on a mine, Sir, what do we do? EB: Normal procedure, Lieutenant, is to jump 200 feet in the air and scatter oneself over a wide area. -- Somewhere in No Man's Land, BA4 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-events-na-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debian policy update (3.8.4.0)
On Mon, 01 Feb 2010 at 20:46:18 +0100, Goswin von Brederlow wrote:
> > Goswin wrote:
> >> Looks fine from here. How does your -dev package look? The .so link, .la
> >> and .pc files (if any) are specifically important.
> >
> > The -dev package has no Multi-Arch field, which seems to be how the
> > multiarch
> > spec on the Ubuntu wiki intends things to be done? As such, I'm still using
> > /usr/lib for the -dev part.
>
> Initialy yes. But esspecially for cross compiles multiarch dev packages
> would be nice. But that will need more developement.
In the meantime, is there consensus that shuffling the development files into
/usr/lib/triplet too is at least harmless, and that Multi-Arch: same is
appropriate for -dev packages where all the arch-dependent files are in
arch-specific directories? I'd rather not break future work if -dev packages
aren't really settled yet.
> > It'd be somewhat more complex to rearrange things for a multiarch -dev
> > package,
> > but could be done; I assume the recommended way to do that would be to use
> > "./configure --libdir=/usr/lib/${DEB_HOST_GNU_TYPE}"?
>
> How do you get the libs into /usr/lib/${DEB_HOST_GNU_TYPE} currently?
Currently, with dh_install - libdbus happens to not hard-code paths, and thus
work correctly when it's just moved around (Michael already moved it from
/usr/lib to /lib for Upstart's benefit, so this definitely does work). I
realise this doesn't generalize to all libraries, in particular those that
hard-code paths (generally to load plugins, like you said).
> Architecture dependent header files belong under
>
> /usr/include/triplet/
Is there consensus that that's the right place? I don't see any mention on
, which is the nearest I've seen to
a canonical description of the current state of multiarch (no pun intended).
For packages like libdbus that already split out arch-dep headers to ${libdir}
there doesn't seem any point in trying to override that, but for packages
that don't necessarily make sure their headers are arch-indep, would it be
appropriate to use --includedir=/usr/include/triplet, i.e. pessimistically
assume that every header is arch-specific?
In particular, generic tools that run configure automatically, like
dh_auto_configure and cdbs, would probably have to assume that every package
contains arch-specific headers unless told otherwise; am I right?
(Some concrete examples: GLib and GDK also have one arch-specific header in
${libdir} each; expat is one of several with a version of config.h in
/usr/include; Python has pyconfig.h in a /usr/include subdirectory.)
Regards,
Simon
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: GPL-licensed software linked against libssl on buildds!
On Wed, Jan 20, 2010 at 10:37:48PM +1300, Lucas Nussbaum wrote: > On 20/01/10 at 00:48 -0800, Steve Langasek wrote: > > On Wed, Jan 20, 2010 at 02:22:33PM +1300, Lucas Nussbaum wrote: > > > > > Why spend a lot of time on tasks that provide little benefit, and also > > > some disadvantages (in some cases, the fixes might be non-obvious, and > > > requires changes to the packaging that tend to obscure it, for example > > > by using --disable-foo for each and every option we don't want)? > > > > I'm not asking anyone to spend time on this task, but I still consider > > missing build-conflicts a bug. Ignoring these bugs by insisting on clean > > chroot environments for all official package builds is no solution - what if > > one of your build-dependencies pulls in one of these other packages, > > resulting in an undistributable (license-incompatible) misbuild? If the > > build-conflicts had been declared, or if the --without-foo option had been > > passed, we would not have to worry about such a misbuild. > > If the chroot env is clean, I hate to break the news, but no build environment (look, full word) is ever clean. There are environment variables, other processes running on the same system, and various other things that can influence it. Granted, rogue environment variables are rarely going to be a problem on a buildd host, but clock skew or rogue processes from previous builds might not be. Okay, that's a stretch. Still. At any rate, here are some facts: - A package that builds differently because something is (or is not) installed on the build system is buggy. Period. It has nothing to do with the build system, it's the package. - When a package has a buggy debian/rules and/or debian/control file, and it gets built on 11 architectures, surely one of those architectures is going to hit that bug. - A clean chroot takes time and processing power. You need to drop and recreate the chroot between builds, upgrade the same Build-Essential packages every time you do an upgrade, copy the apt cache in and out of the chroot (or keep downloading the same packages over and over), and various other things. LVM snapshots fix some, though not all, of those problems, and introduce a few of their own. I don't know about you, but I'd rather have the buildd spend processing power on building packages. Having it fail at producing a good package because the maintainer didn't do a good enough job is nothing new -- they do that all the time. As such, I'm rather unconvinced of the merits of this LVM snapshot thing... -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#568037: ITP: kgmailnotifier -- Gmail notifier applet for KDE
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org --- Please fill out the fields below. --- Package name: kgmailnotifier Version: 0.5.1-1 Upstream Author: [Marcel Hasler ] URL: [http://www.kde- apps.org/content/show.php/KGmailNotifier?content=55375] License: [GPL] Description: [When a new mail has arrived in your inbox a small window will pop up, showing author and subject of the newest mail. The underlined link will take you right to your inbox (using your preferred browser). It also provides some additional features such as audio notification and support for LEDs on notebooks and multimedia keyboards.] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#568039: ITP: gatling -- a small, high performance http and ftp server
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org A small, high performance http and ftp server Package name: gatling Version: latest Upstream Author: Felix von Leitner URL: http://www.fefe.de/gatling License: GPL Description: a small, high performance http and ftp server <>
Bug#568040: ITP: kcm-touchpad -- KDE configuration module for laptop touchpad configuration
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org --- Please fill out the fields below. --- Package name: kcm-touchpad Version: 0.3.1 Upstream Author: [Michał Żarłok] URL: [http://kde-apps.org/content/show.php?content=113335] License: [GPL] Description: This is a configuration module for System Settings for configuring laptop touchpads. With it the user can configure sensitivity, scrolling settings, as well as enable "Smart Mode", which disables the touchpad while typing. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
upload lost ???
Hi everyone,
can someone explain me how to track down a lost upload? Yesterday I
uploaded maildir-util 0.6-1 and got the email
Uploaded successfully
but since then nothing has happened, and I don't see it in the archive,
in the "to be installed", in the NEW queue, qa system.
Is there something I should do at that point but wait for that
mystery to resolve?
Best wishes
Norbert
Norbert Preiningprein...@{jaist.ac.jp, logic.at, debian.org}
JAIST, JapanTU Wien, Austria Debian TeX Task Force
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Pkg-mozext-maintainers] Bits from the Mozilla Extension Packaging Team
On Mon, Feb 01, 2010 at 08:34:31PM +0100, Benjamin Drung wrote: > Hi, > > This mail targets all developers, which maintain Mozilla extensions. > > Source package name > === > > The source package name for extension should not contain the name of the > enhanced application. These prefixes should be dropped from the source > name: > > firefox- > iceape- > icedove- > iceweasel- > mozilla- > thunderbird- > > If the remaining string is too generic (for example, notify or sage), > the source package name should append -extension. For example, > firefoxnotify was renamed to notify-extension. I don't remember this has been discussed, and i certainly disagree with this naming scheme. Also, existing extensions sources shouldn't be renamed. > Binary package name > === > > The Mozilla extension packaging team decided to use xul-ext- (instead of > mozilla-, iceweasel-, etc.) as prefix for all Mozilla extensions [1]. > This will group the extensions visually. There are currently 18 > extensions that use this naming scheme already. Please rename the binary > package if not already done. Note the policy proposal has not been updated with the latest propositions (for which i was hoping more feedback, btw). See the team list archives. > Use mozilla-devscripts > == > > To make packaging extensions dead simple we have mozilla-devscripts. In > most cases debian/rules can be reduces to three or four lines (shebang, > two includes and maybe one variable). We highly recommend using it. An > additional benefit of using mozilla-devscripts is that derived > distribution can use the source code without modifying it. > mozilla-devscripts take care of the distributions specialities. The > usage is explained in the Wiki [2]. > > Joining our team > > > You are welcome to join our team. We maintain all packages in git in the > pkg-mozext group. You can contact us via email or IRC [3]. Please let us > know, if you need help implementing the above mentioned items. > > Work needing package > > > Here is a list of source package that need to updated. Please let me > know, if I missed some packages. I have a lintian check that checks most of the policy, except it was written before lintian 2.3 and doesn't work anymore. If someone has the time to update the script before me, I'll send it to them. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: GPL-licensed software linked against libssl on buildds!
On 02/02/10 at 01:07 +0100, Wouter Verhelst wrote: > At any rate, here are some facts: > - A package that builds differently because something is (or is not) > installed on the build system is buggy. Period. It has nothing to do > with the build system, it's the package. ... but I question that it is a bug that we want to spend time fixing. > - A clean chroot takes time and processing power. You need to drop and > recreate the chroot between builds, upgrade the same Build-Essential > packages every time you do an upgrade, copy the apt cache in and out > of the chroot (or keep downloading the same packages over and over), > and various other things. LVM snapshots fix some, though not all, of > those problems, and introduce a few of their own. > I don't know about you, but I'd rather have the buildd spend > processing power on building packages. Having it fail at producing a > good package because the maintainer didn't do a good enough job is > nothing new -- they do that all the time. I think that the question is whether we would rather have the maintainer spend time fixing those issues, or the buildd spend time dealing with the consequences of using LVM snapshots. I personally think that if we have a way to use CPU time to solve a problem that would require maintainer time otherwise, we should use it. (I am fully aware that putting more load on the buildds might require adding buildds. However, I have the impression that the time required to maintain several identical buildds doesn't grow linearly, so it wouldn't be a too big problem.) -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: upload lost ???
On 02/02/2010 03:37, Norbert Preining wrote: > Hi everyone, > > can someone explain me how to track down a lost upload? Yesterday I > uploaded maildir-util 0.6-1 and got the email > Uploaded successfully > but since then nothing has happened, and I don't see it in the archive, > in the "to be installed", in the NEW queue, qa system. > > Is there something I should do at that point but wait for that > mystery to resolve? For the record, “Uploaded” doesn't mean “ACCEPTED” so the package has not yet been accepted into the archive. I see no trace of that upload, for that matters. Cheers, -- Yves-Alexis signature.asc Description: OpenPGP digital signature
Re: upload lost ???
Yves-Alexis Perez wrote: > On 02/02/2010 03:37, Norbert Preining wrote: >> Hi everyone, >> >> can someone explain me how to track down a lost upload? Yesterday I >> uploaded maildir-util 0.6-1 and got the email >> Uploaded successfully >> but since then nothing has happened, and I don't see it in the archive, >> in the "to be installed", in the NEW queue, qa system. >> >> Is there something I should do at that point but wait for that >> mystery to resolve? > > For the record, “Uploaded” doesn't mean “ACCEPTED” so the package has > not yet been accepted into the archive. > > I see no trace of that upload, for that matters. The upload was rejected as you can see on merkel in /srv/ftp.debian.org/queue/rejected/*.reason Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
