Bug#714212: general: Screen goes to sleep after authentication (Wheezy)
Package: general Severity: normal After upgrading to Wheezy, the resolution randomly change at boot causing screen goes to sleep just after authentication. AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ × 2 Gallium 0.4 on NV84 -- System Information: Debian Release: 7.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2013062621.5203.69698.report...@maison.home
Re: what about Netplan?
Lukas Märdian (2024-07-11): > Additional benefits of Netplan: > * Already used on Debian Bookworm [cloud] images by default Having started to toy with cloud images these last few days, and learning about the various components in there, I'm not exactly sure where /etc/netplan/90-default.yaml is coming from but it's 644 in at least Debian 12 and Debian sid “nocloud” amd64 images (QCOW format), leading netplan to complain about these too-wide permissions. I'm not sure where this file is coming from, but it'd be great to have those permissions fixed/those warnings go away. I'd be glad if someone could take it up from here, I've burned up all the time I had to spend on Netplan on the short term. Thanks already! Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: what about Netplan?
Simon McVittie (2024-07-14): > On Sun, 14 Jul 2024 at 17:09:48 +0100, Steve McIntyre wrote: > > Sorry, but no. Networking clearly is *not* changing that fast, in > > software terms. Many old tools still continue to work just fine > > after a decade or more. > > Yes, I think I agree with Luca's conclusion, but not so much with this > argument: the parts of networking that are relevant for a default > choice that lets users get started (approximately the subset supported > by d-i) don't move that fast. Having finally “fixed” ifupdown support in d-i during the last cycle, unless I missed an obvious solution at the time (but then I didn't get a lot of feedback when I asked), a simple “I'd like auto-IPv4 and IPv6 on a WPA connection” configuration was harder to express than I thought… I ended up with the following, unconvincingly: https://salsa.debian.org/installer-team/netcfg/-/commit/815cdfccaa5567fdf53594d47545d97c235de68e Maybe it's just a matter of storing/splitting the configuration differently, but at least at the time it seemed to be a limitation of the design. Roughly at the same time, we hit some major ifupdown regression, which led to no networking at all after a default (automatic networking, no firmware, everything trivial) installation, which led me to reopen #1022843. While trying to improve the “restart” case, the much simpler “network at bootup” broke entirely, oopsy! https://bugs.debian.org/1022843#42 This is not to put any blame on ifupdown or its maintainer(s), I just meant to share than even “easy-peasy use cases” can be tricky with “good old tools that have been known to work reliably”: that doesn't quite match my experience. :( Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#344991: ITP: dotproject -- Web-based project management tool
Package: wnpp Severity: wishlist * Package name: dotproject Version : 2.0.1 Upstream Author : Adam Donnison <[EMAIL PROTECTED]> * URL or Web page : http://www.dotproject.net/ * License : GNU General Public License version 2 or later Description : Web-based project management tool -- Cyril Bouthors pgpxqwaaAQwBM.pgp Description: PGP signature
Bug#317569: ITP: drbdlinks -- Manages links into a shared DRBD partition
Package: wnpp Severity: wishlist * Package name: drbdlinks Version : 1.03 Upstream Author : Sean Reifschneider <[EMAIL PROTECTED]> * URL or Web page : http://www.tummy.com/Community/software/drbdlinks/ * License : GNU GENERAL PUBLIC LICENSE version 2 Description : Manages links into a shared DRBD partition -- Cyril Bouthors pgpxsj6fqXkB0.pgp Description: PGP signature
Bug#383913: RFA: xdiskusage -- Displays a graphic of your disk usage with du
Package: wnpp Severity: normal I'm asking for someone else to maintain xdiskusage because I'm not using it anymore because I've switched to fsview (package konq-plugins). -- Cyril Bouthors pgpITfCDyLs0z.pgp Description: PGP signature
Bug#388176: ITP: graphthing -- a tool to create, manipulate, and study graphs
Package: wnpp Severity: wishlist Owner: Cyril Brulebois <[EMAIL PROTECTED]> * Package name: graphthing Version : 1.3.1 Upstream Author : David Symonds <[EMAIL PROTECTED]> * URL : http://graph.seul.org/ * License : GPL Programming Lang: C++ Description : a tool to create, manipulate, and study graphs The supported graphs are simple graphs and digraphs, which means no multiple edges or loops. . Main features: * Adding, deleting and moving of vertices and edges. * Loading and saving of graphs. * Graph complements, induced subgraphs and line graphs. * Quick creation of many common graphs: complete, cycle, null, star, etc. * Determination of shortest path, connectivity and Eulericity. * BFS, DFS and Minimum Spanning Tree. * Adjacency matrix (including exponents) and degree sequence. * Chromatic polynomial and chromatic number. * Network algorithms: Maximum network flow. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#397040: ITP: python-pygraphviz -- python interface to the graphviz graph layout and visualization package
Package: wnpp Severity: wishlist Owner: Cyril Brulebois <[EMAIL PROTECTED]> * Package name: python-pygraphviz Version : 0.32 Upstream Author : Aric Hagber <[EMAIL PROTECTED]> * URL : https://networkx.lanl.gov/wiki/pygraphviz * License : BSD Programming Lang: C, Python Description : python interface to the graphviz graph layout and visualization package Pygraphviz is a Python interface to the Graphviz graph layout and visualization package. . With Pygraphviz you can create, edit, read, write, and draw graphs using Python to access the Graphviz graph data structure and layout algorithms. . Homepage: https://networkx.lanl.gov/wiki/pygraphviz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proper way of closing *old* bugs
On 9 Apr 2006, Adam Majer wrote: > My question is, is it now appropriate to use the changelog as a > crutch to close bugs that have nothing to do with the upload? Adam, Apparently you still haven't understood my changelog nor my email: I haven't closed any bug that have nothing to do with the upload. -- Cyril Bouthors pgpawg32cFh3r.pgp Description: PGP signature
Re: Proper way of closing *old* bugs
Adam, Here is what I meant, clearly: I took over the gnuplot package last week but I've only fixed 2 bugs out of 40. It's a shame because I'm supposed to handle them all when taking over the package and I did not. I'll do that as soon as possible but in the meanwhile, I've uploaded that package to put update the maintainer field and fix the easiest bugs. Depending on the situation, I'll handle the bugs that way : - if the bug is not reproducible anymore with the current Debian version, I'll close it directly with the BTS - if the bug is still reproducible, I'll ask the upstream to handle it and tag the bug as "forwarded upstream" - if the bug is still reproducible and has a known patch to fix it, I'll apply it to the Debian version, ask the upstream to merge and close the bug through the changelog during the next upload I think most bugs are not reproducible anymore because they are aged. I initially wrote this changelog header to apology for my lack of time regarding those bugs. I hope this time it's clear enough and that this would close the conversation now because I prefer spending more time on the fixes and less on the mailing lists. If you'd like to spend more time on the packages too, I'll be glad to welcome you as a co-maintainer. Please let me know. Thanks. -- Cyril Bouthors pgpbADWgnEmVQ.pgp Description: PGP signature
Bug#367893: ITP: digitools -- A set of tools to control ASUS Digimatrix embedded hardware
Package: wnpp Severity: wishlist Owner: Cyril Lacoux <[EMAIL PROTECTED]> * Package name: digitools Version : 1.0 Upstream Author : Andrew Calkin <[EMAIL PROTECTED]>, Richard Taylor <[EMAIL PROTECTED]>, Ben Potter <[EMAIL PROTECTED]> * URL : http://members.iinet.net.au/~mcalkin/ * License : GPL Description : A set of tools to control ASUS Digimatrix embedded hardware This package is a combination of the previous programs asusfan and setpanel. Included in this package are the following tools: digifan: allows fan speed control (formerly asusfan) digipanel: allows control of the LED display, and volume knob controls the soundcard master mixer channel (formerly part of setpanel) digiradio: allows control of the in-built radio (formerly part of setpanel) digiwake: allows for Wake-On-CIR (wake on remote) with existing versions of LIRC that support the digimatrix. This program just needs to be run after lircd, and the digimatrix will power on when pressing the music/(on/off) button on the remote control. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.16-1-k7 Locale: LANG=C, LC_CTYPE=C (charmap=ISO-8859-15) (ignored: LC_ALL set to [EMAIL PROTECTED]) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#323629: ITP: smarty-gettext -- provides gettext support for smarty
Package: wnpp Severity: wishlist * Package name: smarty-gettext Version : 1.0b1 Upstream Author : Sagi Bashari * URL or Web page : http://sf.net/projects/smarty-gettext/ * License : GPL Description : provides gettext support for smarty -- Cyril Bouthors pgpRmr5zqMMub.pgp Description: PGP signature
Bug#461486: ITP: luxrender -- rendering system for physically correct 3D image synthesis
Package: wnpp Severity: wishlist Owner: Cyril Brulebois <[EMAIL PROTECTED]> * Package name: luxrender Version : 0.1~rc4 Upstream Authors: PHARR Matt <[EMAIL PROTECTED]> HUMPHREYS Greg <[EMAIL PROTECTED]> VERGAUWEN Terrence <[EMAIL PROTECTED]> ROMANG Jean-Francois <[EMAIL PROTECTED]> BIENKOWSKI Peter <[EMAIL PROTECTED]> BECH Tom <[EMAIL PROTECTED]> et al. * URL : http://luxrender2.org/ * License : GPL (v3 or later) Programming Lang: C++ Description : rendering system for physically correct 3D image synthesis LuxRender is a rendering system for physically correct, unbiased 3D image synthesis. By calculating complex light interactions and using physically accurate cameras and materials, LuxRender is capable of simulating light exactly as in the real world. . Luxrender is directly usable by artists, with the tools and features they need to produce high-quality photorealistic images, especially in areas like architectural visualization, product design, and prototyping. . It also provides with a Blender exporter, a GUI, and a C API that allows programmers to use LuxRender in their own programs. Cheers, -- Cyril Brulebois PS: Sorry if that generates a duplicate for d-d, I put the list in the pseudoheader to ensure the bug gets Cc'd there. /me hopes reportbug will handle that nicely. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Gnome 2.21???
Hi all, A few months ago, I switched from Gentoo to Debian. I used to install/test the development version of Gnome when it reached the API/UI freeze. Gentoo has the "Gentoo Gnome Overlay" [1] where Gnome packages are tested before going into the main Portage repository. Is there something similar with Debian? I have not seen any 2.21 packages in experimental yet. "Debian GNOME Packaging" [2] does not seem to have them yet. Thank you. Regards, Cyril Jaquier P.S. Please, do not forget to CC me as I did not subscribe to the list. [1] http://overlays.gentoo.org/proj/gnome/wiki [2] http://pkg-gnome.alioth.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re: Gnome 2.21???
Hi Loïc, > We currently maintain a little amount of GONME 2.21 modules in > experimental, mostly platform stuff, lacking the manpower to follow > the full set, send bugs upstream etc. Sad :( But why don't you "backport" Ubuntu packages? Please, could you CC me next time? Thanks. Regards, Cyril Jaquier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Gnome 2.21???
Hi Julien, >>> We currently maintain a little amount of GONME 2.21 modules in >>> experimental, mostly platform stuff, lacking the manpower to follow >>> the full set, send bugs upstream etc. >> Sad :( But why don't you "backport" Ubuntu packages? >> > How would that solve the lack of manpower? > It won't solve the lack of manpower but could help a bit. I know this is probably a way too simple but: - take Ubuntu source packages. - remove Ubuntu specific patches, adapt dependencies, etc. But packaging is probably not the most time consuming task ;) How could I help? Regards, Cyril -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: late at night... can't think -- why is my bugs are not closed?
On 24/01/2008, Lucas Nussbaum wrote: > Wasn't m68k supposed to be ignored by the BTS, since it's no longer a > released arch? It's already ignored by testing transitions AFAIK. ISTR that it's the case for hurd-i386 (and it might be “only for”). Ah, references: <[EMAIL PROTECTED]> [1] and below. 1. http://lists.debian.org/debian-devel/2007/12/msg00221.html -- Cyril Brulebois pgpPXp0mfHnhy.pgp Description: PGP signature
Re: How to cope with patches sanely
On 25/01/2008, Vincent Danjean wrote: > If someone has an example of how to use quilt + cdbs (or even quilt + > standard debhelper debian/rules file) to patch the *clean* system of > the software, I would be interested. Usually, patches are early > removed (or not applied) when running "debian/rules clean". Does anything prevent you from doing something like the following in the clean target? (In addition to the usual patch/unpatch dependencies as suggested when using quilt.make.) | quilt push 00_fix_upstream_clean | # $(MAKE) clean or so | quilt pop So you could keep that patch as the first of the series, so that only this one is applied when running upstream's clean, and unapplied afterwards? (You may want to use “quilt pop -a” to be sure.) -- Cyril Brulebois pgprNL2hNJVCp.pgp Description: PGP signature
Re: How to deal with bugs from removed packages?
On 25/01/2008, Frank Küster wrote: > I don't think these bugs should be closed without considering the type > of the removed package. If it's just gotten useless or uninteresting, > no problem. But if there's some kind of successor (like foo2 in a new > source package, iceweasel to firefox, or TeXLive to teTeX) then the > maintainer should check whether the old bug still applies to the new > package. Speaking of which, would it make sense somehow to track these successors? One might think of an additional source field for the control file. I know it's quite easy to remember firefox -> iceweasel, but that might help tracking successors over years, even if they aren't as famous as that one. Cheers, -- Cyril Brulebois pgpmBXtcHwYHv.pgp Description: PGP signature
Re: The meaning of Vcs-* fields
On 26/01/2008, Teemu Likonen wrote: > About these new Vcs-* fields in debian/control: it's not clear to me > where the URLs should be pointing at. Are they meant to point to the > upstream VCS where the actual development happens, so that users can > checkout the upstream trunk (?) directory easily? Or should the Vcs-* > URLs point to the Debian _metadata_ which is maintained by the > package's official Debian maintainer? (Basically by 'metadata' I mean > the 'debian' directory.) See for yourself: | $ PAGER=cat man debcheckout | grep -A1 ^NAME | NAME |debcheckout - checkout the development repository of a Debian package Cheers, -- Cyril Brulebois pgp0YCoIRxXZt.pgp Description: PGP signature
Re: The meaning of Vcs-* fields
On 26/01/2008, Stefano Zacchiroli wrote: > If I were you I would have tried "fakeroot debian/rules > get-orig-source", which is the policy mandated target to retrieve > orig.tar.gz. I guess that trying uscan first might be a good rules of thumb (as well as bugging the maintainer if no (usable) watch file is available). Note that the get-orig-source target isn't really mandated, but optional (Policy 4.9), and usually implemented when a repack is needed (Devref 6.7.8.2). Whether a repack happened is easily detected by looking at the Debian changelog (through the presence of a “dfsg” string). Cheers, -- Cyril Brulebois pgpfo6sfWt2Mx.pgp Description: PGP signature
Re: Sources of dak ?
On 27/01/2008, Charles Plessy wrote: > I wanted to check if dak was case-sensitive when parsing the > DM-Upload-Allowed field […] What about checking the archive itself? $ for i in yes Yes YES ; do grep Dm-Upload-Allowed /var/lib/apt/lists/*Sources | grep $i$ | wc -l ; done 129 16 0 Cheers, -- Cyril Brulebois pgprIbcQkPJZx.pgp Description: PGP signature
Re: Is the DM-Upload-Allowed case-sensitive ?
On 27/01/2008, Charles Plessy wrote: > Thanks a lot! I am affraid that I did not manage to find the answer by > myself. Does anybody know if the DM-Upload-Allowed is case-sensitive, > i.e if 'Yes' is not a correct value to enable DM uploads ? It's not, comparing the packages having such a “Yes” value and [1]. 1. http://ftp-master.debian.org/dm-uploaders.html FTPmasters, would it make sense to reject packages with a Dm-Upload-Allowed flag set, but not set to “yes”, so that this is clear to everyone at once? Cheers, -- Cyril Brulebois pgpw0eCPXAVMO.pgp Description: PGP signature
Re: The meaning of Vcs-* fields
On 27/01/2008, Lars Wirzenius wrote: > Roberto already pointed out that get-orig-source is optional, not > mandatory, but I'm wondering about the fakeroot. Why should the > get-orig-source target be run as root, or even as a fake root? I guess it only comes from an habit, when one is testing/hacking on packages without using the -nc switch, that is: using “fakeroot debian/rules $target”, where $target needs (fake)root rights, hence the “fakeroot”. Cheers, -- Cyril Brulebois pgpIVCsGe9DWd.pgp Description: PGP signature
Re: dpatch -> quilt (Was: How to cope with patches sanely)
On 28/01/2008, Paul Wise wrote: > maybe edit debian/patches/*.patch to remove all the dpatch comments > and just leave the patch descriptions and other human-readable info. > > QUILT_REFRESH_ARGS="-p0 --no-timestamps --no-index" Agreed on --no-index, not convinced by --no-timestamps and -p0. FWIW, I use: | QUILT_NO_DIFF_INDEX=true | QUILT_DIFF_ARGS="--color=auto -p ab" | QUILT_REFRESH_ARGS="-p ab" > quilt push and quilt refresh each patch to update them. No need to walk through them all, filterdiff is your friend. * --strip 0, if you want to keep -p0. * --remove-timestamps, if you want --no-timestamps. * dpatch stuff will be stripped. Cheers, -- Cyril Brulebois pgpeD34ElH1X1.pgp Description: PGP signature
Re: The meaning of Vcs-* fields
On 28/01/2008, Andreas Tille wrote: > There are other reasons for repackaging (for instance large chunks of > precompiled binary data that would just bloat the archive even if > everything is DFSG free). I'm not aware of a default extension for > the tarball name in case of repackaged tarballs. I already pointed to Devref 6.7.8.2, now quoting it: | A repackaged .orig.tar.gz: | … | 4. should use -.orig as the name of the | top-level directory in its tarball. This makes it possible to | distinguish pristine tarballs from repackaged ones. -- Cyril Brulebois pgpvlmjcnGgmA.pgp Description: PGP signature
Re: rebuilding the archive in a dirty chroot: results
On 28/01/2008, Lucas Nussbaum wrote: > Build-Conflicts: libwxgtk2.6-dev? I thought we were moving away from wx 2.4, not from 2.6. ;-) -- Cyril Brulebois pgpLO4s4mwjfE.pgp Description: PGP signature
Re: CDBS cmake.mk class
On 28/01/2008, Salvatore Ansani wrote: > Hi guys I've a strange behaviour compiling a kde4 package with > cmake.mk CDBS class. (And gales?) > Investigating I found variable who cause error: > -DCMAKE_C_COMPILER="cc". > > Other Question: How I tell debian/rule to modify some variables ? If I > redefine CMAKE_C_COMPILER with "" I don't have any > changes http://bugs.debian.org/cdbs will lead you to #450901. http://bugs.debian.org/cmake will lead you to #459207. Since it's not being fixed right now, I personally embed a copy of cmake.mk, without setting the two (C and CXX) offending variables. Cheers, -- Cyril Brulebois pgpq40lfbcfZy.pgp Description: PGP signature
Standard to indicate repacking in version numbers?
On 28/01/2008, Andreas Tille wrote: > ... which describes the _content_ of the tarball, but not the _name_ > (or extension) of the tarball. So there is no clarification whether > to use 'dfsg', 'debian', 'ds' or something else in the tarball name to > my knowlwedge. How are “dfsg”, “debian”, or “ds” extensions? It's in the very middle of the tarball name, and the extension would rather be “((orig.)tar.)gz” (there's the revision in the way, also). It'd be clearer to talk about the string to include in version numbers, and I agree that having a common pattern in the policy or the devref would make sense. There are several combinations of the above, mixed together with the use of ‘+’, ‘~’ and ‘.’, and getting a standard for that couldn't hurt. Cc'ing -policy. Cheers, -- Cyril Brulebois pgp38jPLnd6TN.pgp Description: PGP signature
Re: Standard to indicate repacking in version numbers?
On 28/01/2008, Russ Allbery wrote: > We went back and forth on this several times on debian-mentors and I > think everyone finally agreed that debian/copyright is the correct > place to explain any repackaging of the upstream source. Since > debian/copyright is the standard place to explain where the upstream > source came from, it's the logical place for that information to go. Agreed. First (and that's why I keep -policy, and even add -doc to Cc), it might be interesting to remove the README.Debian-source suggestion in devref 6.7.8.2 and specify debian/copyright there. Second, I'm now wondering whether some modifications/additions to the copyright format proposal[1] should be done so as to make it easy to specify which files/directories were removed and for which reason (no sources, no license, unsuitable license, etc.). 1. http://wiki.debian.org/Proposals/CopyrightFormat Cheers, -- Cyril Brulebois pgptBO9Ki7Bk3.pgp Description: PGP signature
Re: How to cope with patches sanely
On 29/01/2008, Daniel Leidert wrote:
> svn-buildpackage is not a framework to create or edit patches. So how
> should it compare to quilt? It "merges" the contents of the
> .orig.tar.gz with the content in SVN and then it builds the package by
> using dpkg-buildpackage/debuild/pbuilder/pdebuild/sbuild/whatever.
From what you've described, it looks like you use dpatch to fetch the
content of the tarball and work on it. That is: sparing a “tar” call.
> Because I don't want to store the whole source in a VCS just to be
> able to maintain a package collaboratively. So quilt should be able to
> do the same for me dpatch does or it is not an alternative. I do not
> consider putting the whole source under VCS as an alternative - it
> increases space needs of the VCS and the checkout size - simply a
> waste of time and resources. Upstream normally has its own VCS to
> store the history of files. Why should we do this on e.g. svn.d.o too?
> If I want to have a look at the history of the file, I can take a look
> into upstreams VCS.
I'm only keeping debian/ under $VCS (svn for pkg-{games,python}, git for
all others) and I only have to invoke tar. uscan is my friend (and
probably later pristine-tar to get any version of the upstream tarball
easily).
Just call tar to extract the tarball, work on your patches using your
preferred patch management system, commit your patches in $VCS and
you're done.
> Yes, I like the debian/-only layout svn-buildpackage offers.
Me too… although you don't need *-buildpackage at all to achieve that.
tar is very sufficient.
--
Cyril Brulebois
pgp5U8emGfE2o.pgp
Description: PGP signature
linux-kernel-headers???
Hi all, I'm new to Debian so sorry for this newbie question ;) Why do not the linux-source-2.6.* packages provide linux-kernel-headers? Regards, Cyril Jaquier P.S. Please, do not forget to CC me because I am not subscribed to the list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: List of packages shipping shell scripts with bashisms + MBF proposal
On 30/01/2008, Paul Wise wrote: > Has there been any bashisms checks on maintainer scripts (postinst/etc)? There's already: http://lintian.debian.org/reports/Tpossible-bashism-in-maintainer-script.html Cheers, -- Cyril Brulebois pgpu6gpae1W7J.pgp Description: PGP signature
Re: linux-kernel-headers???
First of all, linux-kernel-headers has been replaced by linux-libc-dev. Ok. But linux-kernel-headers is still a virtual package. Isn't it? But either way, the answer is the same: those packages install them in /usr/include, which is unpacked and accessible to any program being compiled. linux-source-2.6.* (AFAIK) is not unpacked by default, and even when it is unpacked, the headers are not accessible under /usr/include. linux-source-2.6.* is not unpacked by default (at least on my system). If it was the case, a symlink from /usr/src/linux-source-2.6.*/include to /usr/include/linux wouldn't do the trick? Mmmhhh... maybe /usr/include/linux must point to the headers which were used to compile glibc? Thank you. Cyril P.S. Please CC me if you reply to this e-mail. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The 30 most popular packages missing in Debian
On 30/01/2008, Andrew M.A. Cater wrote: > > 7 virtualbox > In sid, at least in part IIRC Called virtualbox-ose, but present indeed and also in testing. > > 28sun-j2sdk1.5 > Wrong Java licence - packaged before Sun went "free": I think only > Java 7 will be fully free IIRC FWIW: 2008/01/22: icedtea-java7 7~b24-1.5-2 landed in NEW http://ftp-master.debian.org/new/icedtea-java7_7~b24-1.5-2.html Cheers, -- Cyril Brulebois pgpxv3ealxknc.pgp Description: PGP signature
Re: Library versioning
On 30/01/2008, David Paleino wrote: > I'm packaging a software for the Debian-Med group (CCed), and found > that, even if the library is at version 2.2.1, the compilation makes a > libfoo.so.2.0.2 [1]. > Is there any solution to this? If not, is it that important that the > filename has the same version number as the package? Hi, please check libpkg-guide [2] and read about what SONAME, ABI, and API are. The version number of the package has *nothing* to do with that. Random example: graphviz has libgraphviz4 (.so.4.0.0), version is 2.16. 2. http://www.netfort.gr.jp/~dancer/column/libpkg-guide/ Cheers, -- Cyril Brulebois pgpPdAaYTnWTB.pgp Description: PGP signature
Re: How to cope with patches sanely
(Note: I've just discovered (read: started using) pristine-tar. I'm no expert at all.) On 31/01/2008, Daniel Leidert wrote: > > You're wrong, I don't store the whole orig.tar.gz, I keep its > > content, and the delta (often less than 2kb). > > Then I seem to misunderstand you. What does "content" mean, if you do > not store the whole .orig.tar.gz? Do you just store the diffs between > upstream versions? The idea isn't to store “foo_bar.orig.tar.gz” in $VCS, rather to store its content, that is: all files created by e.g. the following: tar xfz foo_bar.orig.tar.gz --strip 1 Keeping track of gzipped tarballs wouldn't make sense. The point is: you're losing some details when doing so (timestamp stuff, permissions or whatever), that's why the deltas generated by pristine-tar are needed to then generate back bit-identical gzipped tarballs. > Can you show me a public example? To be honest, I have some problems > to understand your workflow. A package maintained by Pierre (pdnsd). I'll try not to forget any command (and not pasting the whole output of every command, that's not relevant here): | # Clone the repo. | $ git-clone git://git.madism.org/pdnsd.git pdnsd.git | … | $ cd pdnsd.git | | # Create a local branch out of a remote one, and switch to it. | $ git-checkout -b pristine-tar origin/pristine-tar | … | | # Examine the delta (4kB). | $ ls -l | -rw-r--r-- 1 kibi kibi 4921 2008-01-31 16:44 pdnsd_1.2.6-par.orig.tar.gz.delta | | # Switch back to the debian branch (a local one has been created out | # of origin/debian since the latter is the default one on the remote). | $ git-checkout debian | … | | # Here is the magic. | $ ./debian/rules check-tarball | Regenerating pdnsd_1.2.6-par.orig.tar.gz. The check-tarball target is a quick hack by Pierre to automate the use of the delta file (in the pristine-tar branch) to generate back the original tarball from what is contained in git. No need to uscan or apt-get source, and you don't rely on anything but your repository. You can also keep things separated: debian/ only stored in unstable, experimental, and so on branches. An independent pristine-tar one (as above). And an independent upstream one, where you only import the original tarball (and eventually tagging them with their version so that the above check-tarball hack can be extended). To give you an idea of the extra cost of storing original tarballs (their content, rather) in git: graphviz's unpacked sources are around 30MB. Gzipped, around 5MB. After having imported 7 such tarballs in git (and still with my whole debian/-only packaging), I'm now reaching 10MB. For everything. Hope it clarifies a bit. Cheers, -- Cyril Brulebois pgpcPQdTzELbx.pgp Description: PGP signature
Re: Bug#463973: ITP: deejayd -- A media player daemon
On 04/02/2008, Christian Perrier wrote: > Yes. Apparently what's special about this is that it can be > controlled over the network. Probably not the only one but > noticeable enough to be mentioned in a short description. mpd also supports that (tcp/6600). Cheers, -- Cyril Brulebois pgpARDt4RZ7TJ.pgp Description: PGP signature
Re: rebuilding the archive in a dirty chroot: results
On 05/02/2008, Lucas Nussbaum wrote: > I did another rebuild. Thanks to the Debian GNU/kFreeBSD cabal, \o/ > debcmp is an home-made script I use to compare packages, looking > more deeply than what debdiff does. It's available from > http://svn.debian.org/wsvn/collab-qa/tools/debcmp/ , if you want to > double-check the results. Having a look at some packages of mine, some suggestions: - Please blacklist .pdf at least, timestamps stuff and so on are likely to be at fault here. - You could eventually no longer take the order of entries in shlibs file into account. I'm not sure this order matters anyway. - Harder, but you could try and ignore hunks where only a line changed, which contains “Generated on $date”, that's likely to be doxygen or a friend of its. Maybe ignoring .html files would do? There's also docbook-to-man. - I didn't check your script but I guess it might be enhanced WRT file type detection, see for example synfigstudio log in debcmp/. I really suggest you postprocess your logs for the shlibs problem, it would make it trivial to spot actual problem, also preventing from missing some, hidden in an order modification. > Or maybe someone has an NM, and doesn't know what he should do for > T&S? ;) Not yet, already passed, too late. :p -- Cyril Brulebois pgp2lM64Vk7g9.pgp Description: PGP signature
Re: rebuilding the archive in a dirty chroot: results
On 05/02/2008, Alexander Schmehl wrote: > Why that? Both, the diff.gz and the .dsc, are part of the source > package, so why did they change at all? See the build log: , | gpg: Signature made Tue Jan 29 21:33:22 2008 CET using DSA key ID 00D8CD16 | gpg: Can't check signature: public key not found | dpkg-source: extracting fillets-ng in fillets-ng-0.8.0 | dpkg-source: unpacking fillets-ng_0.8.0.orig.tar.gz | dpkg-source: applying ./fillets-ng_0.8.0-2.diff.gz | dpkg-buildpackage: source package fillets-ng | dpkg-buildpackage: source version 0.8.0-2 | dpkg-buildpackage: source changed by Alexander Schmehl <[EMAIL PROTECTED]> | dpkg-buildpackage: host architecture i386 | /usr/bin/fakeroot debian/rules clean | QUILT_PATCHES=debian/patches quilt --quiltrc /dev/null pop -a -R || test $? = 2 | No patch removed | rm -rf .pc debian/stamp-patched | dh_testdir | dh_testroot | rm -f build-stamp | # Add here commands to clean up after the build process. | [ ! -f Makefile ] || /usr/bin/make distclean | dh_clean debian/fillets-ng.png | dpkg-source -b fillets-ng-0.8.0 | dpkg-source: building fillets-ng using existing fillets-ng_0.8.0.orig.tar.gz | dpkg-source: building fillets-ng in fillets-ng_0.8.0-2.diff.gz | dpkg-source: building fillets-ng in fillets-ng_0.8.0-2.dsc | debian/rules build ` There you are. -b/-B aren't used, the source package gets (re)built, and due to gzip magic, the diff. Cheers, -- Cyril Brulebois pgpl07dlnpJBV.pgp Description: PGP signature
Re: Copyright question
On 06/02/2008, Jean Parpaillon wrote: > 3. All advertising materials mentioning features or use of this > software must display the following acknowledgement: > This product includes software developed at the University of > Tennessee, Knoxville, Innovative Computing Laboratories. > > 4. The name of the University, the name of the Laboratory, or the > names of its contributors may not be used to endorse or promote > products derived from this software without specific written > permission. > > > I've read DFSG and I'm not sure if items 3 and 4 are problematic. Can > someone help me ? If it's not ok, may it be in contrib ? See http://wiki.debian.org/DFSGLicenses, BSD-3 (without point 3.) isn't a problem. The advertising requirement (3.) is a problem, though. Note that if a package isn't DFSG-free, it can't go to contrib either. Contrib is for DFSG-free material depending on non-free (or contrib in turn) stuff, see Policy 2.2.2. Cheers, -- Cyril Brulebois pgpCQ2mURhche.pgp Description: PGP signature
Re: Copyright question
On 06/02/2008, Sebastian Harl wrote: > Just to make this clear […] Yep, thank you (all) for clarifying that, sorry for the inconvenience. Cheers, -- Cyril Brulebois pgpFkxYGMPJdq.pgp Description: PGP signature
Re: Re: dash bug which is affecting release goal
On 11/02/2008, Mike Bird wrote: > Debian should ensure that millions of Debian users around the world > who have written and tested millions of tiny shell scripts with no > thought to the possibility that /bin/sh may one day become not-bash > will not suffer millions of hours of down time (or worse - bad data) > due to a Debian change. If those users are running unstable or testing, that's their job to track such changes. If they are running stable, that's where Release Notes can be used. > On *production* Debian systems, saving 30 seconds in a boot which > may occur once a year for a kernel security update is not worth a > single broken script, nor a single failed backup, nor a single lost > data bit. Since you're talking about *production* systems, “stable” case above, so “not a problem”. Cheers, -- Cyril Brulebois pgpgIoQn5TCta.pgp Description: PGP signature
Re: Meaning of the "Altering package upload rules"
On 13/02/2008, Stefano Zacchiroli wrote: > The architecture for which a DD is initially uploading a package is > already lacking a build log on buildd.debian.org and the > corresponding build has no guarantee to be reproducible. > > So if these are good arguments for not doing (massive) binary > uploads, they are also good arguments for not allowing > binary-uploads at all (thousands DDs making binary uploads are > hardly worst than 1 DD doing massive binary uploads). Or, if you > prefer, they are good arguments for throwing away the .debs uploaded > by DDs and rebuilding them from scratch. > > SCNR, really. I just made the same remark to Raphaël on IRC, thanks for summing it up here. Cheers, -- Cyril Brulebois pgp2DcNLCmqq4.pgp Description: PGP signature
Re: Tcl/Tk release goals
On 13/02/2008, Francesco P. Lovergine wrote: > [A] Removing /usr/lib in $auto_path [3]. That has been already > announced in the past message with motivations for that, and > experimental packages are available in experimental for testing. > We are going to release a non-/usr/lib Tcl/Tk in unstable… Any timeframe for that? I noted the “ASAP” some words later, but having an idea of the #days might help coordinating uploads. > … and preparing a few NMUs for packages which need fixed > pkgIndex.tcl for that. That will happen as soon as possible. What about first reporting bugs (with eventually the NMU patches that are already prepared)? See gcc folks' advanced warnings, that looks like the way to go, instead of NMUing in the wild. Cheers, -- Cyril Brulebois pgpSNgxYPUiRI.pgp Description: PGP signature
Re: QUESTION: Debian Policy: Manual pages
On 14/02/2008, Russ Allbery wrote: > I thought that tag in lintian already had a note that you should add > an override if the man pages are shipped in a different package on > which this package has a dependency. Apparently I was just imagining > things. ISTR it's the case for icons in desktop/menu files. -- Cyril Brulebois pgpGmD9xFI6pW.pgp Description: PGP signature
Re: the new style "mass tirage" of bugs
On 22/02/2008, Michael Tautschnig wrote: > Do you think that there is a chance we find a group of people who > really like mentoring/training others? If so, we could maybe set up > kind of a bug-frontdesk taking over _all_ new bug reports for a > moment and checking them for a the bit of information that seems > crucial to fix/reproduce the bug. You might find some people usually trying to help others on -mentors (and/or on #-mentors). Helping bug-workers figure out where to use gdb, strace, and the like isn't that complicated. Of course, there are hard bugs, and those might take more time. But helping others learn basic tool might help, if they're able to provide a backtrace by themselves, check that reported crashes aren't just PEBCAK's and so on. Although the timeslots I reserved to Debian until last months are going to be reduced soon, I would be interested in being part of such a group. Cheers, -- Cyril Brulebois pgprVSIa57DEf.pgp Description: PGP signature
Re: How to cope with patches sanely
On 25/02/2008, Pierre Habouzit wrote: > I'm planning to write a textual version of what I demonstrated at > FOSDEM, with some more ideas that I had talking with Julien Cristau > on the grass after. Please, pretty please, include graphics. Be it ASCII art-like drawings, or gitk screenshots, with some additional arrows and other comments. Not that I need it, but that would (have been|be) nice. Cheers, -- Cyril Brulebois pgpITYEH0ADJu.pgp Description: PGP signature
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
On 25/02/2008, Pierre Habouzit wrote: > What you want him to do is using: > > git rebase -i Probably with -p. -- Cyril Brulebois, who tried, w/o prior knowledge of the code. pgpi79bZt6Ty5.pgp Description: PGP signature
Re: Google Summer of Code 2008
On 27/02/2008, Lucas Nussbaum wrote: > Many of the students that were selected were already well-known > Debian contributors or developers. The first problem with that is > that some of those students used their GSOC time to work on their > usual Debian tasks instead of their GSOC project, leading to > disapointing results, unsuccessful projects, less projects being > accepted the next year, etc. Nice claims. Pointers? > (1) Forbid DDs and people in the NM process waiting for FD/DAM to > apply as students. How is this distinction relevant? Isn't that possible to be waiting-for-that-never-coming-DAM-review, student, but also working on various opensource projects, as well as maintaining packages, alone or within teams, working on various areas of the Debian project (e.g. QA, by providing with patches, NMUing packages; or mentoring people with their new or updated packages), at the very same time? I believe it's possible. And I believe you'll find a trivial example. Now. How come it wouldn't be possible to apply for a GSOC slot, lowering the involvement in one (or more) of the above-mentioned areas, and concentrating on a specific project? -- Cyril Brulebois pgpYW2fuA7IMK.pgp Description: PGP signature
Re: Google Summer of Code 2008
On 28/02/2008, Lucas Nussbaum wrote: > > Nice claims. Pointers? > > I agree that this is mainly based on personal perception (but that's > not really my fault: no final report about what students did (in > detail) are available). OK. So you lack info, thus assume people failed. Nice. Steve already answered about this, anyway. > > How is this distinction relevant? Isn't that possible to be > > waiting-for-that-never-coming-DAM-review, student, but also > > working on various opensource projects, as well as maintaining > > packages, alone or within teams, working on various areas of the > > Debian project (e.g. QA, by providing with patches, NMUing > > packages; or mentoring people with their new or updated packages), > > at the very same time? > > > > I believe it's possible. And I believe you'll find a trivial > > example. > > GSOC != "get funding for existing DDs to do $DEBIAN_WORK". If GSOC > is only DuncTank 2.0, I think that we could have a nice > thread^Hflamewar about whether it's good or evil. GSOC is considered > good by many people because one of its stated goals is to bring > fresh blood to free software. I'm not saying that GSOC is about getting funded to do $USUAL_DEBIAN_WORK, I'm just saying that it's possible to work on very different areas, and to keep a separation before “usual work” and “GSOC work”, and that your distinction (early-NM, waiting-forever-NM, and so on) is totally irrelevant. BTW, it might be relevant to check GSOC's FAQ to see what it is about. , | Google Summer of Code has several goals: | | * Get more open source code created and released for the benefit of | all; | * Inspire young developers to begin participating in open source | development; | * Help open source projects identify and bring in new developers and | committers; | * Provide students in Computer Science and related fields the | opportunity to do work related to their academic pursuits during | the summer (think "flip bits, not burgers"); | * Give students more exposure to real-world software development | scenarios (e.g., distributed development, software licensing | questions, mailing-list etiquette). ` Source: http://code.google.com/soc/2008/faqs.html#0.1_goals Please note that it's not only about “bringing fresh blood to free software”. > Now, I agree that "fresh blood" is difficult to define. Is someone > that has been involved a bit in Debian for 1-2 months "fresh blood"? Again, that's not the (only) point. > Someone who submitted some bug reports, but never got involved? Submitting bug reports is IMHO a way to get involved. At least in my experience, FTWC. > someone who is very involved in GNOME, but not involved in Debian? > So my distinction sucks, but I couldn't come up with something > better that fitted in a line. There's no line to fit. > > Now. How come it wouldn't be possible to apply for a GSOC slot, > > lowering the involvement in one (or more) of the above-mentioned > > areas, and concentrating on a specific project? > > Past years show that this is very hard to do, Pointers? Ahah, no, you already said you haven't got any. > but of course it's possible. But that also means that we are > shooting ourselves in the foot: we are asking someone to lower his > involvement in some areas of Debian, where we might be depending on > him. Many Debian teams might not be able to afford to lose an active > contributor during the summer (just before the lenny release!) so he > can work on his GSOC project. Huh? You know about libre arbitre, right? If people apply to GSOC, their choice. I really don't know why you would forbid them to apply. So that they keep doing the dirty job before a release? -- Cyril Brulebois pgpSjKxjhcWxG.pgp Description: PGP signature
Re: Google Summer of Code 2008
On 28/02/2008, Lucas Nussbaum wrote: > 2) | * Inspire young developers to begin participating in open >| source development; > 3) | * Help open source projects identify and bring in new >| developers and committers; > 5) | * Give students more exposure to real-world software >| development scenarios (e.g., distributed development, >| software licensing questions, mailing-list etiquette). > Points 2,3 and 5 can be summarized as "goal of GSOC is get fresh > blood". Only point 1 is about "goal of GSOC is to get code written". > This is too ambiguous to conclude anything from it. No. 2) is about *development*. Development is not necessarily a part of the usual job of Debian packagers. 5) is also about development. And I really believe that there's a very large gap between packaging and developping. Of course that depends on the packages, the packagers, and so on. But in the cases you try to address, it looks like glibc or X hackers aren't concerned. You also don't speak about 4) at all. > > Pointers? Ahah, no, you already said you haven't got any. > > It would be a good idea to ask jvm, ana, marga, tincho and lamby > about their opinion on that topic. Looks to me like the very first thing you should have done. > > Huh? You know about libre arbitre, right? If people apply to GSOC, > > their choice. I really don't know why you would forbid them to > > apply. So that they keep doing the dirty job before a release? > > Gah, you discovered my evil plans :-) I don't find that funny. At all. -- Cyril Brulebois pgpoGJUuUPPma.pgp Description: PGP signature
Re: Google Summer of Code 2008
On 28/02/2008, Lucas Nussbaum wrote: > Who said I didn't? But maybe it was in private IRC > discussions/mails. And maybe I didn't talk to all of them about that > neither, so I'm biaised. Because you said that your previous claims were based on your personal impressions rather than anything else? Why didn't you provide us with info/pointers, then, instead of “It would be a good idea…”? It would be nice to stop using maybe's. > I understand that you are frustrated by the current state of DAM > (Cyril has been waiting for DAM to review his application for more > than 3 months). > I am, too (in fact, I think that our inability to give accounts to > some of our most active contributors is one of the biggest problem > in Debian currently). > But please don't let this reflect too badly on your state of mind. My state of mind is “nothing too dramatic”. > I think that your tone in some mails of this thread has been > unnecessarily agressive. I think that your trying to keep almost-DD's out of GSOC for bogus reasons has been unnecessarily aggressive. -- Cyril Brulebois pgpc67crjt6XN.pgp Description: PGP signature
Re: NMU - remove or just let be superceded
On 01/03/2008, Kevin Coyner wrote: > Should I remove it manually, or just let it go as the version > numbers will ensure that it will not be installed? Wait until it moves to DELAYED/0, and gets REJECTED since there's a newer version in the archive. Cheers, -- Cyril Brulebois pgpiqZDc1WH4s.pgp Description: PGP signature
Re: RFH: wireshark, libgphoto2, exif, etc.
On 07/03/2008, Frederic Peters wrote: > Hello all, Hi Frederic, > I have been on the http://wiki.debian.org/LowThresholdNmu list for a > long time and I want to encourage you all to consider this and step > for NMU, or team-maintenance (especially for wireshark and libgphoto2, > I should have done this earlier). I am all for alioth but no news yet > about my request for a pkg-wireshark project. I'd be pleased to welcome your photo-related packages (libgphoto, exif, etc.) into the pkg-phototools group. I'm currently lacking time a bit, but I should be able to step in during the next week. Cheers, -- Cyril Brulebois pgpQ03SHu9ckH.pgp Description: PGP signature
Re: dpkg semi-hijack - an announcement (also, triggers)
On 09/03/2008, Mike Bird wrote: > Ian hijacked his own program back from the people who had been > blocking updates for six months - including the triggers enhancement > which is needed for boot time improvements Is dpkg handling the boot sequence? Or are you confusing that with dependency-based initscripts? -- Cyril Brulebois pgpO4ipOJOweh.pgp Description: PGP signature
Re: Timeline for normal buildd operation on MIPS ?
On 10/03/2008, Charles Plessy wrote: > Dear MIPS porters, Dear Charles, > Despite the hard work you made for your buildds, the backlog is stil > stabilizing to a level that blocks into unstable the packages that > evolve at the periphery of the Debian galaxy, such as scientific > applications. despite the words you're trying to use to mask it, you're really harrassing them for no valid reasons. > In order to help the people maintaining such packages to organize > themselves, can you publish a timeline of your works and goals for the > MIPS infrastructure? It has been more than three months that the > backlog is there; this is more than half the time left before the > freeze. In order to keep the noise on this (these) list(s) at a suitable level, can you please stop that? It's been more than three weeks that you're ranting. > Please be assured of the sympathy I have for your project, Please be assured of the sympathy I have for your trying to have your packages into testing at all costs, -- Cyril Brulebois pgpZwLabADZMj.pgp Description: PGP signature
Re: Steffen Joeris (while@) is wanted ;)
On 12/03/2008, Dmitry E. Oboukhov wrote: > Does anybody know where Steffen Joeris is? > > He has not answered my mails for a month+ already. > Is everything OK with him? Maybe he could answer if you try and contact white@, rather than [EMAIL PROTECTED] Anyway, he gave away some of his packages, because of his being busy, which might explain a lag (in case your typo was only in this Subject:). Cheers, -- Cyril Brulebois pgpfhH5CmHVeG.pgp Description: PGP signature
Re: package upload rejected - no email
On 15/03/2008, Kevin Coyner wrote: > Question: how do I get the newer, correct version of the > .orig.tar.gz into the archives (replacing the earlier version > uploaded previously that does not match upstream's)? You can't replace a .orig.tar.gz in the archive. You have to bump the version (I'm not talking about incrementing the Debian revision here) to upload e new .orig.tar.gz Cheers, -- Cyril Brulebois pgpUudGCzJgsH.pgp Description: PGP signature
Re: broken .orig.tar.gz (Re: package upload rejected - no email)
On 16/03/2008, Bernhard R. Link wrote: > But is there a way to know who the sponsor of rhinote_0.7.0-1 was? Besides the “lynx -dump”-based solutions mentioned in this thread, there's far easier: | $ who-uploads rhinote # from devscripts | Uploads for rhinote: | 0.7.0-2 to unstable: Kevin Coyner <[EMAIL PROTECTED]> | 0.7.0-1 to unstable: Neil McGovern <[EMAIL PROTECTED]> You'll sometimes need to use --max-uploads=N (N defaults to 3). Cheers, -- Cyril Brulebois pgpcMT3b3A0Wh.pgp Description: PGP signature
Re: corrupt zip/tar archives in the repository?
On 28/03/2008, Simon Josefsson wrote: > What do you think about reporting these as wishlist bugs? Hi, thanks for the report; but that won't be needed (although of course I wouldn't mind) for the following package: > Masayuki Hatta (mhatta) <[EMAIL PROTECTED]> >blender >blender (U) > > Cyril Brulebois <[EMAIL PROTECTED]> >blender (U) > > Wouter van Heyst <[EMAIL PROTECTED]> >blender (U) I'm on my way to report it to upstream already (which already ships some .svn/ in the tarball). Cheers, -- Cyril Brulebois pgpYvLqGphsi9.pgp Description: PGP signature
Re: triggers wishlist
On 30/03/2008, Michael Biebl wrote: > I don't understand, why it shouldn't be possible, that a single > update-rc.insserv run, reoders *all* init scripts in one go. You could > still skip the ones, which will cause loops or have no dependency > information. I guess the algo is currently “there's no loop; try and add foo; if a loop is introduced, foo is guilty; otherwise, be happy”. If you don't have the “we're trying to add foo” bit, I guess it's hard (if possible at all) to find which package(s) is/are guilty. -- Cyril Brulebois pgpl0qzvelLLA.pgp Description: PGP signature
Re: Bug#473998: ITP: debian-faq -- The Debian FAQ
On 02/04/2008, Joost van Baal wrote: > In this package you will find the Debian GNU/Linux FAQ, which gives > frequently asked questions (with their answers!) about the Debian > distribution Debian GNU/Linux and others) and about the Debian project. ^ mismatched parenthesis? > You'll find out that some answers assume some knowledge of Unix-like ^^^ I'm not sure this is welcome... > operating systems. We'll try to assume as little prior knowledge as ^^ ... but that certainly is not. > The document is supplied in HTML, PDF, PostScript and plain ascii. ^ ASCII? Cheers, -- Cyril Brulebois pgpGrENNN5l9x.pgp Description: PGP signature
Re: Restart automatic build
On 06/04/2008, Ludovico Cavedon wrote: > automatic build of wengophone [1] on arm failed because of a GCC > internal compiler error. Who should I ask to request a retry of the > build? [EMAIL PROTECTED] Cheers, -- Cyril Brulebois pgpLEaHFaZMAE.pgp Description: PGP signature
Re: Bug#474699: ITP: python-mpd -- Python MPD client library
On 07/04/2008, Michal Čihař wrote: > Package: wnpp > Severity: wishlist > Owner: "Michal Čihař" <[EMAIL PROTECTED]> > > * Package name: python-mpd > Version : 0.2 > Upstream Author : J. Alexander Treuman <[EMAIL PROTECTED]> > * URL : http://www.musicpd.org/~jat/python-mpd/ > * License : GPL > Programming Lang: Python > Description : Python MPD client library > > An MPD (Music Player Daemon) client library written in pure Python. Hi, how does it compare to python-mpdclient? Cheers, -- Cyril Brulebois pgpss3SRhJIKJ.pgp Description: PGP signature
Re: Restart automatic build
On 07/04/2008, Wouter Verhelst wrote: > However, if the reason it failed was an internal compiler error, then > unless the bug in the compiler has been fixed, such a rebuild will not > serve any purpose; the package will fail to build on exactly the same > place. Build failures can be due to lack of RAM, which especially happens on arm buildds. The only way to get the package built is then to ask for a rebuild, which hopefully will hit another box. I've already asked Aurélien for several give-backs, following his own instructions. No need to Cc me, thank you. -- Cyril Brulebois pgpv0EjFl9AWl.pgp Description: PGP signature
Re: libcwd in Debian unstable
On 10/04/2008, Carlo Wood wrote: > It was added 16 March, that is 3+ weeks ago! :/ > So, debian-devel@lists.debian.org: can someone tell me why > libcwd was added as amd64 package, but still doesn't exist > as x86 package please? Because there are additional requirements for non-free packages to be autobuilt. See the following announcement for more info. http://lists.debian.org/debian-devel-announce/2006/11/msg00012.html Cheers, -- Cyril Brulebois pgpHiQC2uFJJZ.pgp Description: PGP signature
Reviewing http://wiki.debian.org/ArchitectureSpecificsMemo
Hi, I'm wondering whether the ArchitectureSpecificsMemo[1] wiki page is (well-)known, and whether its content got reviewed, esp. by porters of each architecture, who could fix obvious errors or typos, or eventually add special-cases, exceptions, and the like. 1. http://wiki.debian.org/ArchitectureSpecificsMemo Looking at its history, the number of commits is rather low, so it might be interesting to have some couples of eyes checking that page. Mraw, KiBi. pgpy0wEHuCkK7.pgp Description: PGP signature
Re: building a package two times
On 03/05/2008, Marco d'Itri wrote: > DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH) > ifeq ($(DEB_HOST_ARCH),amd64) > FLAVORS := std > else ifeq ($(DEB_HOST_ARCH),ia64) > FLAVORS := std > else ifeq ($(DEB_HOST_ARCH),ppc64) > FLAVORS := std > else ifeq ($(DEB_HOST_ARCH),s390x) > FLAVORS := std > else > FLAVORS := std lfs > endif Since you have “FLAVORS := std” in every case but the last one, why not using findstring, so as to factorize a bit? Mraw, KiBi. pgpUT1PHDwphK.pgp Description: PGP signature
Re: How to handle Debian patches
On 17/05/2008, Charles Plessy wrote: > Other idea: when the package is produced through a workflow that uses > debian/patches, shipping them in /usr/share/doc/package/patches. Do you really want that? openoffice.org_2.4.0-6.diff.gz 82,595.1 kB Not to mention all packages where an autoreconf run is stored as a patch, I'm not sure it'll help much to install it on each and every system. Mraw, KiBi. pgpYW8aznIxvp.pgp Description: PGP signature
Re: divergence from upstream as a bug
On 18/05/2008, Pierre Habouzit wrote: > oh boy, are we really "fighting" over a dupe of a mail ? wasting 4k of > data and two keystrokes ? (in mutt, D~=\n will remove dupes, kmail has > the same functionnality, and most decent MUA do to). CoC is meant to > reduce rudeness, not technical issues from another century. Oh boy, are you really “fighting” over wasting one half second to type ‘L’ instead of ‘r’ when you reply to a list? (In mutt, there’s a list-reply function, why not use it in the first place? Most decent MUAs have that feature as well.) Mraw, KiBi. pgpPdSwa6xk0H.pgp Description: PGP signature
Re: How to build only linux-image-2.6.18-6-686
Hamish Moffatt <[EMAIL PROTECTED]> (13/06/2008): > Ideally the .config files used to build the standard Debian kernels > would be available in a light-weight package. I think the only > solution currently is to install that package and get the > configuration from /boot/config-. You may play around with linux-support-$version, which contains global, per-arch, per-flavour configuration files, as well as the tools to combine them. From the notes I took a tiny while ago, you could try e.g. “kconfig.py /tmp/combined-config config i386/config i386/config.686” I might have missed some bits, but that's basically what's done during the kernel build. Mraw, KiBi. signature.asc Description: Digital signature
Re: How to build only linux-image-2.6.18-6-686
Cyril Brulebois <[EMAIL PROTECTED]> (13/06/2008): > Hamish Moffatt <[EMAIL PROTECTED]> (13/06/2008): > > Ideally the .config files used to build the standard Debian kernels > > would be available in a light-weight package. I think the only > > solution currently is to install that package and get the > > configuration from /boot/config-. > > [hackish stuff] More trivially, the .config are available in linux-headers-*. I guess they also qualify for the “light-weight” bits, since: $ for i in headers image ; do \ apt-cache show linux-$i-2.6.25-2-amd64 ; done | grep Installed-Size Installed-Size: 8844 Installed-Size: 79736 Mraw, KiBi. signature.asc Description: Digital signature
Re: terminfo files getting installed executable, but how? (was: Failing daily D-I builds?)
Frans Pop <[EMAIL PROTECTED]> (20/06/2008): > $ sudo aptitude reinstall ncurses-base > $ ls -l /lib/terminfo/*/* > -rwxrwxrwx 1 root root 1481 2008-06-16 22:40 /lib/terminfo/a/ansi > -rwxrwxrwx 1 root root 1502 2008-06-16 22:40 /lib/terminfo/c/cons25 > -rwxrwxrwx 1 root root 1529 2008-06-16 22:40 /lib/terminfo/c/cygwin > -rwxrwxrwx 1 root root 308 2008-06-16 22:40 /lib/terminfo/d/dumb > [...] Maybe you could provide us with the part of your dpkg.log relative to that particular “aptitude reinstall” run, maybe there are some leads there. You could also strace it, following its childs. Mraw, KiBi. signature.asc Description: Digital signature
Re: Is Florent Bayle MIA?
"Artur R. Czechowski" <[EMAIL PROTECTED]> (28/06/2008): > Possibly libpano12 could be removed from Debian after taking care > about hugin. Correct. libpano13 is packaged already, and I've been waiting for a hugin release for some months. I've finally to pick up an svn snapshot since there's still no release in sight. I'll take care of asking for the removal of libpano12 when it's relevant. Mraw, KiBi. signature.asc Description: Digital signature
Re: ia32-libs depends on ia32-apt-get ?
Josselin Mouette (29/06/2009): > All existing frontends use the same dependency resolution engine, > except for aptitude. Installing a package with synaptic, apt-get, > adept or gnome-app-install should give the same result. cupt! cupt! cupt! Mraw, KiBi. signature.asc Description: Digital signature
Re: Bug#535501: ITP: roxterm -- A multi-tabbed GTK terminal emulator
Tony Houghton (02/07/2009): > Package: wnpp > Severity: wishlist > Owner: Tony Houghton > > > * Package name: roxterm > Version : 1.15.1 > Upstream Author : Tony Houghton > * URL : http://roxterm.sourceforge.net/ > * License : GPL > Programming Lang: C > Description : A multi-tabbed GTK+2 terminal emulator application > > ROXTerm is a terminal emulator intended to provide similar features to > gnome-terminal, based on the same VTE library, but with a smaller footprint > and quicker start-up time. It achieves this by not using the Gnome libraries > and by using a separate applet to provide the configuration GUI. It can be > used as a ROX application, as the name implies, or in any other X environment. $ rmadison roxterm roxterm | 1.11.1-1.1 |stable | source, alpha, amd64, arm, armel, hppa, i386, ia64, mipsel, powerpc roxterm | 1.11.1-1.1+b1 |stable | mips, s390, sparc roxterm | 1.12.2-1 | testing | source, alpha, amd64, armel, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc roxterm | 1.12.2-1 | unstable | source, alpha, amd64, armel, hppa, hurd-i386, i386, ia64, mips, mipsel, powerpc, s390, sparc Closing this bug. Mraw, KiBi. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
Philipp Kern (05/07/2009): > How could one help to get multiarch happen by the way? Or does it currently > depend on Guillem coding up the foundation in dpkg anyway? Maybe we could have a bug against general about multiarch support, blocked by bugs against each and every component that needs tweaking. This way, one should be able to follow the progress in each area? Mraw, KiBi. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#536245: RFH: graphviz -- rich set of graph drawing tools
Package: wnpp Severity: normal Heya folks. I request assistance with maintaining the graphviz package. That might also move to an RFA later on. Given I'm slowly drifting to more porting, I'm currently lacking time to maintain graphviz properly. If you're interested, you may want to be aware of some points: - Upstream is very nice, but now ships a bundled debian/ directory in its tarball, and will continue to do so. Repacking is/will be needed. - There are libraries, with different sonames, and plugins. I guess there's very little point in splitting the current libgraphviz4 library in more libraries (given it only has 3 rdeps last I checked) but you'll need to understand the library packaging issues here, and try hard not to break anything. - There are bindings for several languages, and some bugs open against them. These bindings were requested presumably for Ubuntu, and given that some aren't really used, or buggy, it might make sense to drop some. Note that obviously, upstream doesn't know how to use each of them, given they're swig-generated. That's all I can think of right now. Packaging is in collab-maint's git (debian-only, but I'm not opposed to seeing this evolve in some other setup), patches can be pushed there in some branches, or even in “unstable” if you know what you're doing. The package description follows: Graph drawing addresses the problem of visualizing structural information by constructing geometric representations of abstract graphs and networks. Automatic generation of graph drawings has important applications in key technologies such as database design, software engineering, VLSI and network design and visual interfaces in other domains. Situations where these tools might be particularly useful include: . * you would like to restructure a program and first need to understand the relationships between its types, procedures, and source files * you need to find the bottlenecks in an Internet backbone - not only individual links, but their relationships * you're debugging a protocol or microarchitecture represented as a finite state machine and need to figure out how a certain error state arises * you would like to browse a database schema, knowledge base, or distributed program represented graphically * you would like to see an overview of a collection of linked documents * you would like to discover patterns and communities of interest in a database of telephone calls or e-mail messages Thanks in advance. Mraw, KiBi. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Running a 32bits on debian amd64 system
Mathieu Malaterre (13/07/2009): > I'd suggest you reread it: > > http://alioth.debian.org/docman/view.php/30192/21/debian-amd64-howto.html#id292437 Let's quote it further: | So, when will it be released? | The first planned official Debian release of 64bit userland for AMD64 will be Etch (Sarge+1). > There is no mention to chroot -H option whatsoever > > You do not need to be rude when I explicitly quote the actual doc I am > reading, which obviously should not recommend the use of chroot Which obviously hadn't been updated in *years*. RT*appropriate*FM. Mraw, KiBi. signature.asc Description: Digital signature
Re: Bug#536888: ITP: tlock -- Terminal locker
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ryan Kavanagh (14/07/2009): > This package will also provide the library packages librpass0 and > librpass0-dev, > with long description: > > Static library installed with tlock, it provides a function readpass() that > reads in a password string from standard input of process and returns it > back, > AS IS, to the calling application. While fetching password from standard > input, readpass first turns off the echo of input characters and the > generation of signals through keystrokes, reads in the password, turns the > character echo and signal generation back on, and returns to the calling > application a character pointer pointing at the password string. Do we really need this standalone library?! And please, pretty please, stop putting the SONAME in the -dev package name when it isn't needed. (Also, the first word of the description for this dynamic library is “static”?) Mraw, KiBi. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkpciBIACgkQeGfVPHR5Nd1zYgCgi03WEmF9a38XSRhHorE8SWHP eQsAn0qnwB4i8HJl5VkB1F6F6qu5gqhx =C7x4 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: The wider implications of debhelper/dbus breakage
Steffen Moeller (17/07/2009): > Wouter's comment aside, checks at buildd level would be too late. Yes, sure. It'd rather be time for critical packages (say: dpkg-dev, debhelper, cdbs) to have proper non-regression testsuites. Mraw, KiBi. signature.asc Description: Digital signature
Re: Bug#537492: menu: Binary without execution bits.
Hello -devel, I need a tiny wider audience for that one. Bill Allombert (18/07/2009): > On Sat, Jul 18, 2009 at 09:35:57PM +0200, Cyril Brulebois wrote: > > Package: menu > > Version: 2.1.41 > > Severity: grave > > Justification: Fucks up upgrades. > > > > Sounds like some bits are missing: > > | -rw-r--r-- root/root122920 2008-10-24 21:03 ./usr/bin/update-menus > > > > Which leads to: > > | install/elserv: Deleting /tmp/elc_eXSJx7.log > > | install/devscripts-el: Handling emacs21, logged in /tmp/elc_U0zTnA.log > > | install/devscripts-el: Deleting /tmp/elc_U0zTnA.log > > | /var/lib/dpkg/info/emacs21.postinst: line 24: /usr/bin/update-menus: > > Permission denied > > | dpkg : erreur de traitement de emacs21 (--configure) : > > | le sous-processus script post-installation installé a retourné une > > erreur de sortie d'état 1 > > | Des erreurs ont été rencontrées pendant l'exécution : > > | emacs21 > > | E: dpkg returned non-zero status: 256 > > | E: error performing command 'full-upgrade' > > > > (Sorry about the French bits, but heh.) > > > > No surprise, chmod is used in menu's postinst. WTF? > > /var/lib/dpkg/info/emacs21.postinst is broken, not menu. I'm repeating here what I said on the bugreport, because I think that (Houston) we've got a problem. It's quite classical to use the following bit to test for a binary to call: | if [ -x "`which invoke-rc.d 2>/dev/null`" ] See debhelper's sources: | git grep -e '-x.*which'|wc -l | 12 But: | $ if [ -x `which icanhazfailure 2>/dev/null` ] ; then echo FAIL ; fi | FAIL And also, under zsh: | $ which doublefailure 2>/dev/null | doublefailure not found Leading to: | if [ -x `which icanhazfailure 2>/dev/null` ] ; then echo FAIL ; fi | [: too many arguments I guess we need a plan to fix some maintainer scripts, or am I grossly overlooking things here? Mraw, KiBi. signature.asc Description: Digital signature
Re: Bug#537492: menu: Binary without execution bits.
Sven Joachim (18/07/2009): > This looks strange, it seems that the test found update-menus > executable, but it no longer is. Namely, the shell has apparently > hashed it, since otherwise you would "update-menus: command not found" > instead of "permission denied". > > This may be because the dpkg trigger for update-menus had been > activated. Can you examine your dpkg.log entries of the failed > upgrade? (No sign of triggers, it's just that emacs21 gets configured before menu.) That one might be arch-related: | kbsd:/home/kibi# which update-menus | /usr/bin/update-menus | kbsd:/home/kibi# ls -l /usr/bin/update-menus | -rw-r--r-- 1 root root 113028 jun 8 13:13 /usr/bin/update-menus That's on GNU/kFreeBSD. I still have to investigate why, but it looks like if [ -x /usr/bin/update-menus ] returns true even with the above-mentioned conditions. Cc'ing -bsd. > > And also, under zsh: > > | $ which doublefailure 2>/dev/null > > | doublefailure not found > > > > Leading to: > > | if [ -x `which icanhazfailure 2>/dev/null` ] ; then echo FAIL ; fi > > | [: too many arguments > > This is missing the double quotes that are present in the debhelper > script snippet. Thanks to them, there is only one argument for [ -x . Indeed, thanks. /me gets back to fixing (real) bugs. Mraw, KiBi. signature.asc Description: Digital signature
Re: Intend to create an -fPIC library package...
Raphael Hertzog (22/07/2009): > Yes. Check "man dpkg-gensymbols" and see how some nice tools > […propaganda…] FSVO “nice”. #536034. In case a maintainer of a shared lib never did this, I strongly advise playing around with a simple combo of diff, find, and nm, in order to have a look at what symbols are becoming between two releases. I always thought it was something *needed* so that depending packages don't suddenly stop working. But oh well. Mraw, KiBi. signature.asc Description: Digital signature
Re: The wider implications of debhelper/dbus breakage
Raphael Hertzog (17/07/2009): > At least dpkg-dev has one and it's run at build-time. I thought the goal of dpkg-dev was to actually build other packages. I don't know how dpkg-dev developers see this, but maybe having a few packages rebuilt using the new dpkg-dev package would help spotting breakages? I dunno, but especially eglibc and other important packages would be quite good candidates. I guess that a loop for getting the source packages, pushing them through sbuild once with the old dpkg-dev package and once with the new dpkg-dev packages, then debdiffing (and whatever interesting diff tests might come to mind) would help and wouldn't be very hard to implement. That also holds for debhelper, cdbs, . > Of course the test was added when the bug got fixed (we're speaking of > #536034 for those wondering). I know. Guess what, I checked the facts. ;p > Speaking for dpkg-dev, any help is always welcome to enhance the > test-suite but it's a huge job that is not so rewarding. See above for a trivial idea. Mraw, KiBi. signature.asc Description: Digital signature
Re: Intend to create an -fPIC library package...
Raphael Hertzog (23/07/2009): > > In case a maintainer of a shared lib never did this, I strongly > > advise playing around with a simple combo of diff, find, and nm, in > > order to have a look at what symbols are becoming between two > > releases. > > Why is that better than comparing both symbols files and having the > build actually fail if a symbol is removed? Why are you trying to second-guess me? > Using nm/find/diff is more complicated and I don't see a clear > advantage to it. I mean it may help people figure out what a shared library looks like in terms of symbols, library dependencies and so on. Mraw, KiBi. signature.asc Description: Digital signature
Re: Switching /bin/sh to dash without dash essential
Goswin von Brederlow (24/07/2009): > Give me the freedom to choose. It looks like we just reached the “Linux is about choice” Goswin point. Mraw, KiBi. signature.asc Description: Digital signature
Re: dash pulled on stable when APT::Default-Release is used
Vincent Danjean (29/07/2009): > kooot:/home/vdanjean# aptitude why dash > i linux-image-2.6.30-1-amd64 Depends initramfs-tools (>= 0.55) | yaird (>= > 0.0.13) | linux-initramfs-tool > p yaird Depends dash Got a winner here, I believe: | -(cy...@talisker pts/8)-(~) | $ rmadison -s stable yaird | -(cy...@talisker pts/8)-(~) | $ So I guess you either have installed the version from oldstable or from unstable. Both versions depend on dash. Time to cleanup obsolete/locally installed packages? Mraw, KiBi. signature.asc Description: Digital signature
Re: Automatic Debug Packages
Michael Banck (29/07/2009): > At that time, either you have thrown away the debugging information > already (via dh_strip, e.g.), or not. > > This is all AIUI. There are some environment variables set by dpkg-buildpackage already, I guess debhelper stuff could be set accordingly. Meh. :) Mraw, KiBi. signature.asc Description: Digital signature
Re: Automatic Debug Packages
Manoj Srivastava (29/07/2009): > Coming up with a standard and policy after the fact, with 97% of > the archive not quite following policy would be a nightmare, no? 97% of the archive using yada? Mraw, KiBi. signature.asc Description: Digital signature
Re: Introduction to multiarch: What maintainers must do
Goswin von Brederlow (29/07/2009): > Thoughts from the maintainer? You may want to read #468209, which is kind of related. Mraw, KiBi. signature.asc Description: Digital signature
Re: Introduction to multiarch: What maintainers must do
Charles Plessy (30/07/2009): > I have three questions about Multi-arch: > > 1) […] > > 2) […] 3) Where is the third question? :) Mraw, KiBi. signature.asc Description: Digital signature
Re: maybe ITP of lib DomainKeys
Russell Coker (30/07/2009): > http://domainkeys.sourceforge.net/license/softwarelicense1-1.html > > I've packaged libdomainkeys for internal use and am considering adding a > package that depends on it to Debian/Unstable. Is the domainkeys license > suitable for inclusion in Debian? Hint, try -legal@, quoting the full license text in your mail. Mraw, KiBi. signature.asc Description: Digital signature
Re: Emacs 23.1 released
Adrian Perez (30/07/2009): > I'd like to see this in unstable ASAP. Get to work? Mraw, KiBi. signature.asc Description: Digital signature
Re: Bits from the release team and request for discussion
(Torn between replying to -project for the former, -devel for the latter.) Luk Claes (30/07/2009): > Adam D. Barratt (adsb), Felipe Augusto van de Wiel (faw) and Jurij > Smakov (jurij) joined us as release assistants. Let's welcome them in > our team. Welcome! > Architectures > = > > As some of you might have noticed, we added the architectures > kfreebsd-i386 and kfreebsd-amd64 to testing. This is not a promise > that they will be part of Squeeze, but we consider it realistic. > Adding them early to testing makes it easier for us to get testing > into shape. As of now, these architectures don't have any effect on > the testing migration. Bugs specific to these architectures are not > release critical. We try to direct user questions/bugreporting to our mailinglist[0], but you might receive a GNU/kFreeBSD-specific bug report anyway. Feel free to contact us, we'll look into those issues as time permits. 0. debian-...@lists.debian.org Mraw, KiBi. signature.asc Description: Digital signature
Re: How to check why a package is in contrib
Bastien ROUCARIES (30/07/2009): > I was trying to check why a package was in contrib (jabref), and I > could not find a means to do that automatically. > > Could we add an automatic mechanism based on package description, for > getting the reason, like for instance, why-contrib: reason > > It will ease the move to main in case of for instance a nonfree build > lib that go to main :) I would guess that one might expect a reason in changelog, first upload to contrib, and copyright file. Mraw, KiBi. signature.asc Description: Digital signature
Re: waf into NEW, please test it with your packages
Ryan Niebur (30/07/2009): > would you mind providing a .deb of that so that I can test and update > my dh build system patch to use it? waf deb? Check first mail in the thread. Mraw, KiBi. signature.asc Description: Digital signature
Re: Installation of packages in home directories.
Charles Plessy (01/08/2009): > I would really love to have such a functionality in apt. reportbug cupt (Seems to be an interesting challenge. Not sure it's worth the pain though.) Mraw, KiBi. signature.asc Description: Digital signature
What to do with (packages like) Blender?
Hi folks. It's been a while and I'm now really wondering what to do with Blender. So that everyone can understand, I'm going to try and sum up what I'm facing. Please note it's not intended to be a rant, rather a summary of what I've to deal with. * Upstream doesn't really care about being distributed. The philosophy is rather "unzip and run". And by trying to distribute it, one might disable or even break some features (see below), which upstream doesn't like. * Similarly, when it comes to Release Candidates, the main idea is to get builds for every platform, meaning that between the first build and any other build, many patches get committed to fix various FTBFSes on Windows, Linux, and OS X (and even more?) platforms. No tag, people are supposed to use trunk when they see fit to give it a try. And what really matters is the availability of binaries. * Upstream doesn't really care about security. For example, there is a long standing patch to prevent using predictable filenames in /tmp (by moving the temporary directory to something like ~/.blender/tmp). Fortunately, other distributors seemed to care about sharing the patches and sdiscussing them. * Upstream uses a lot of embedded code copies. Most of them with patches. That means that one has to get rid of them, tweak the sources so as to be able to use system-wide libraries, and most importantly, deal with any breakages that may happen. That's my main problem: they have their own copy of ffmpeg, which is a huge, fast-moving library, and trying to ensure blender is usable at any time after ffmpeg updates isn't trivial (obvious API breakages are still OK, but subtle ones aren't). It looks like I was able to restore the broken sound output, but not the broken video output (not to mention it's been quite some time, like several weeks/months, and I'm quite feeling guilty about that). [I should note there's another upstream bugfix release (2.49a, Debian is at 2.49), which I didn't investigate yet. Maybe that particular bug was noted by upstream and fixed, but I think my point stands anyway.] Which makes me wonder if there's a point in keeping blender as it is. Maybe with someone able to dedicate a lot of time to it, that might be feasible; but for one, I'm not really keen on spending lots of time on problems upstream doesn't even care about (I've been kind of flamed for posting a patch to add support for using system-wide libraries). So: what should I do? I'm thinking about orphaning the package as a first step, and if nobody takes care of it as much as it is needed, just remove it from the distribution. Packaging would still be available in a git repository, so if someone sometime picks it up, it should be quite easy not to start from scratch again. Thanks for any insights. Mraw, (kind-of-lost-) KiBi. signature.asc Description: Digital signature
