Bug#613016: ITP: phpunit-dbunit -- DbUnit port for PHP/PHPUnit
Package: wnpp Severity: wishlist Owner: Olivier Berger * Package name: phpunit-dbunit Version : 1.0.1 Upstream Author : Sebastian Bergmann * URL : https://github.com/sebastianbergmann/dbunit/ * License : BSD Programming Lang: PHP Description : DbUnit port for PHP/PHPUnit DBUnit is an extension to phpunit, that "has been created to provide an easy way to place your database in a known state, execute your database-affecting code, and ensure that the expected data is found in the database.", quoting the PHPUnit manual. Note that this upstream program is now managed in an independant PEAR package from the rest of PHPUnit, hence, a separate Debian package. See #607393 for a discussion about the PHPUnit re-packaging. I'm open for collaborative maintenance on this one too, in the frame of the pkg-php team. Best regards, -- 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/20110212092722.8348.90427.report...@inf-8657.int-evry.fr
Bug#613018: ITP: phpunit-mock-objects -- Mock Object library for PHPUnit
Package: wnpp Severity: wishlist Owner: Olivier Berger * Package name: phpunit-mock-objects Version : 1.0.8 Upstream Author : Sebastian Bergmann * URL : https://github.com/sebastianbergmann/phpunit-mock-objects/ * License : BSD Programming Lang: PHP Description : Mock Object library for PHPUnit PHPUnit_MockObject is a PHPUnit extension that provides Mock Objects for PHPUnit. According to the the PHPUnit manual "The practice of replacing an object with a test double that verifies expectations, for instance asserting that a method has been called, is refered to as mocking.". Note that this upstream program is now managed in an independant PEAR package from the rest of PHPUnit, hence, a separate Debian package. See #607393 for a discussion about the PHPUnit re-packaging. I'm open for collaborative maintenance on this one too, in the frame of the pkg-php team. Best regards, -- 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/20110212093740.8536.72173.report...@inf-8657.int-evry.fr
Re: Upcoming FTPMaster meeting
On 2011-02-11, Hideki Yamane wrote: > On Fri, 4 Feb 2011 08:20:02 +0100 > Raphael Hertzog wrote: >> I have not seen any word about XZ support. >> When you deployed support for new source package formats, you forbid >> lzma because xz was coming along and you mentioned that wheezy could have >> xz enabled. >> I would like to see xz allowed both for source package and for binary >> packages. > I want XZ support too, at least it reduce size for some font packages. > e.g. Do we have an idea how much more memory xz needs for decompression? I guess it wouldn't be feasible to switch dpkg's default on package builds on those architectures where we assume some more beefyness? I'd imagine that our CD1s would also get more useful if we'd compress those in any case. But then that probably also concerns our core packages where memory usage might matter. Kind regards Philipp Kern -- 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/slrnild203.9tn.tr...@kelgar.0x539.de
Re: Upcoming FTPMaster meeting
On Sat, Feb 12, 2011 at 01:15:47PM +, Philipp Kern wrote: > On 2011-02-11, Hideki Yamane wrote: > > On Fri, 4 Feb 2011 08:20:02 +0100 > > Raphael Hertzog wrote: > >> I have not seen any word about XZ support. > > I want XZ support too, at least it reduce size for some font packages. > > e.g. The numbers you quoted (1/3 reduction) are actually on the small side -- although consistent with my estimates for the archive as a whole. You can expect 50% gains on most packages, it's some bulky data ones that are incompressible that jack down the average. > Do we have an idea how much more memory xz needs for decompression? I guess > it wouldn't be feasible to switch dpkg's default on package builds on those > architectures where we assume some more beefyness? On ARM, it's 90MB, I guess MIPS should be similar. The man page says 65MB even in -9, but I guess they didn't count in the code, libc, buffers and the likes. Trying to run unmodified Debian on 64MB is a suicide, I'd say the weakest type that are going to run stock Debian are chroots on n900, which, with 256MB, can handle all the phony stuff together with decompression just fine. If you allow for everything but the decompression to be swapped out, even 128MB would work reasonably. Anything lower and you go into emdebian, which repacks all the packages anyway. Thus, I think there are no problems with enabling XZ on all architectures. > I'd imagine that our CD1s would also get more useful if we'd compress those > in any case. But then that probably also concerns our core packages where > memory usage might matter. Memory during upgrades, not during actual operation. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- 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/20110212135759.ga4...@angband.pl
Re: Upcoming FTPMaster meeting
On Sat, Feb 12, 2011 at 02:57:59PM +0100, Adam Borowski wrote: > Trying to run unmodified Debian on 64MB is a suicide, I'd say the weakest > type that are going to run stock Debian are chroots on n900, which, with > 256MB, can handle all the phony stuff together with decompression just fine. > If you allow for everything but the decompression to be swapped out, even > 128MB would work reasonably. I think that VPS'es with 128Mb RAM are still sold, not to mention existing installations. -- WBR, wRAR signature.asc Description: Digital signature
Re: Upcoming FTPMaster meeting
On Sat, Feb 12, 2011 at 9:57 PM, Adam Borowski wrote: > On ARM, it's 90MB, I guess MIPS should be similar. > The man page says 65MB even in -9, but I guess they didn't count in the > code, libc, buffers and the likes. > > Trying to run unmodified Debian on 64MB is a suicide, I'd say the weakest > type that are going to run stock Debian are chroots on n900, which, with > 256MB, can handle all the phony stuff together with decompression just fine. > If you allow for everything but the decompression to be swapped out, even > 128MB would work reasonably. > > Anything lower and you go into emdebian, which repacks all the packages > anyway. > > Thus, I think there are no problems with enabling XZ on all architectures. My OpenMoko FreeRunner phone is an ARM device that has 128Mb RAM and runs pure Debian armel. Only time I need to kill things to during an upgrade is when I'm upgrading the locales package or lintian, creating locales files seems to take a lot of memory and the process gets killed sometimes. -- bye, pabs http://wiki.debian.org/PaulWise -- 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/aanlktikjo2u4ez+yz_nupeqdu0bro9i3hioquupsj...@mail.gmail.com
Re: Upcoming FTPMaster meeting
On Sat, Feb 12, 2011 at 3:06 PM, Andrey Rahmatullin wrote: >> 128MB would work reasonably. > I think that VPS'es with 128Mb RAM are still sold, not to mention existing > installations. May enable it on x64 first (those 128 mb VPSs are unlikely to run x64) and then see about other archs later. -- Olaf -- 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/AANLkTi=Gpi+w_VfAEvp1wPS3=5vzz5qpstazdrv6p...@mail.gmail.com
Re: Upcoming FTPMaster meeting
Na grupie linux.debian.devel napisałe(a)ś: > Trying to run unmodified Debian on 64MB is a suicide, I'd say the weakest > type that are going to run stock Debian are chroots on n900, which, with > 256MB, can handle all the phony stuff together with decompression just fine. > If you allow for everything but the decompression to be swapped out, even > 128MB would work reasonably. No, it's not: #v+ [jarek@archeress ~]% free -m total used free sharedbuffers cached Mem:60 58 2 0 10 16 -/+ buffers/cache: 31 29 Swap: 511 55456 #v- Lenny with (by memory usage): bind, openssh, snmpd, postfix, cups, dhcp3, ntpd, upnpd, hostapd, mt-daapd, ... works just fine. I could reduce the memory requirements even more by throwing away some services and replacing bind with something lighter, but it wasn't necessary. -- pozdr(); // Jarek -- 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/20110212141232.ga30...@vilo.eu.org
Re: Upcoming FTPMaster meeting
On Sat, 12 Feb 2011, Philipp Kern wrote: > Do we have an idea how much more memory xz needs for decompression? I guess > it wouldn't be feasible to switch dpkg's default on package builds on those > architectures where we assume some more beefyness? It depends on what compression level we use, this is in the manpage: The following table summarises the features of the presets: Preset DictSize CompCPU CompMem DecMem -0 256 KiB 03 MiB1 MiB -1 1 MiB 19 MiB2 MiB -2 2 MiB 2 17 MiB3 MiB -3 4 MiB 3 32 MiB5 MiB -4 4 MiB 4 48 MiB5 MiB -5 8 MiB 5 94 MiB9 MiB -6 8 MiB 6 94 MiB9 MiB -7 16 MiB 6 186 MiB 17 MiB -8 32 MiB 6 370 MiB 33 MiB -9 64 MiB 6 674 MiB 65 MiB "DecMem" is the memory needed to decompress (i.e. install the package), "CompMem" is the memory needed to compress (i.e. create the package). I think we could use -6 on all architectures without much problem. It's also the default setting used by xz if you don't specify anything. > I'd imagine that our CD1s would also get more useful if we'd compress those > in any case. Yeah, it's those discussions about our CD1 that led me to push this forward again. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- 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/20110212160218.ge23...@rivendell.home.ouaza.com
Re: chromium-browser is taking over all URLs
On Fr, 11 Feb 2011, Josh Triplett wrote:
> See http://bugs.debian.org/612876 for the bug report. I encountered the
> same issue, and finally found the culprit through reading the
> chromium-browser changelog.
Umpf, I have removed the x-scheme-handler/http and x-scheme-handler/https
ffrom the chromium-browser.desktop and called update-desktop-database,
now midori starts.
Then I edited midori.desktop, now epiphany-browser starts,
where does that end???
I checked xdg-open, and it calls gvfs-open, which in turn (checking the
sources) calls
g_app_info_launch_uris
from gio/gappinfo.h which belongs to libglib2.0-dev. There I tried
to read the code but gave up.
I suggest to raise the severity to serious, and reassign to
libglib2.0*whatever*.
WDYT?
Best wishes
Norbert
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
ACLE (n.)
The rouge pin which shirtmakers conceal in the most improbable fold of
a new shirt. Its function is to stab you when you don the garment.
--- Douglas Adams, The Meaning of Liff
--
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/20110212160759.ge4...@gamma.logic.tuwien.ac.at
Re: Upcoming FTPMaster meeting
Hi! On Fri, 2011-02-11 at 11:33:10 +0800, Paul Wise wrote: > On Fri, Feb 11, 2011 at 5:58 AM, Ben Hutchings wrote: > > Since there is no support for auto-building arch-independent binaries > > I would hope that throwing away developer built debs would also apply > to arch-independent packages, IIRC that was part of the proposal. > There was talk of a Build-Architecture field for Architecture: all > stuff that can only be built on certain architectures (firmware, > bootloaders etc where there is no cross-compiler available). Using Build-Architecture would be a workaround, it should not be needed once multiarch is in place and those packages are built for their respective architectures. regards, guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110212162230.gb27...@gaara.hadrons.org
Re: Upcoming FTPMaster meeting
Hi! On Sat, 2011-02-12 at 13:15:47 +, Philipp Kern wrote: > On 2011-02-11, Hideki Yamane wrote: > > On Fri, 4 Feb 2011 08:20:02 +0100 > > Raphael Hertzog wrote: > >> I have not seen any word about XZ support. > >> When you deployed support for new source package formats, you forbid > >> lzma because xz was coming along and you mentioned that wheezy could have > >> xz enabled. > >> I would like to see xz allowed both for source package and for binary > >> packages. > > I want XZ support too, at least it reduce size for some font packages. > > e.g. > Do we have an idea how much more memory xz needs for decompression? We changed the default compression level for lzma to -6, and set it as the default for xz on the initial addition to dpkg-deb in 1.15.6, exactly for the memory reasons, taking into account small systems and to open the possibility of a possible future default switch. I think xz and lzma memory usage might vary slightly but for xz -6 the man page says 9 MiB on decompression, which should be fine everywhere. > I guess it wouldn't be feasible to switch dpkg's default on package builds > on those architectures where we assume some more beefyness? It would be possible, but I'd rather not do that, as even if some architectures are prone to have more memory generally, that's an exclusive charecteristic of the system, and the decisions to exclude specific architectures would seem somehow arbitrary (I'm sure there's still people using Debian on i486), and Debian specific. When changing the dafault for dpkg-deb, it should be changed for everything. regards, guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110212161904.ga27...@gaara.hadrons.org
Re: Upcoming FTPMaster meeting
On Sat, Feb 12, 2011 at 10:17:59PM +0800, Paul Wise wrote: > On Sat, Feb 12, 2011 at 9:57 PM, Adam Borowski wrote: > > > On ARM, it's 90MB, I guess MIPS should be similar. > > The man page says 65MB even in -9, but I guess they didn't count in the > > code, libc, buffers and the likes. > > > My OpenMoko FreeRunner phone is an ARM device that has 128Mb RAM and > runs pure Debian armel. Only time I need to kill things to during an > upgrade is when I'm upgrading the locales package or lintian, creating > locales files seems to take a lot of memory and the process gets > killed sometimes. Decompression and generation of locale files never go together, so this shouldn't be a problem. As others have noticed, reducing the compression level can reduce memory requirement to a single digit, and that dpkg-dev already uses -6 rather than -9 by default. I believe it might be a good idea to go back to -9 on big architectures, but this is a detail that can be changed later. For now, it's important to know if it's save to enable xz everywhere, and it appears it is. If indeed xz -6 takes only 9MB to decompress, even Jarek's machine with 64MB should handle it without a swappeathon. I didn't check this myself, but I'm told that when xz has to swap (and not merely evict other processes away), its memory usage pattern is so bad that a file normally processed in ten seconds can take an hour. Thus, using 9MB vs 90 makes quite a difference. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- 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/20110212170423.ga9...@angband.pl
Bug#613080: ITP: jebl2 -- Java Evolutionary Biology Library
Package: wnpp Severity: wishlist Owner: andr...@an3as.eu * Package name: jebl2 Version : SVN R6 Upstream Author : Andrew Rambaut * URL : http://code.google.com/p/jebl2/ * License : LGPL Programming Lang: Java Description : Java Evolutionary Biology Library A Java library for evolutionary biology and bioinformatics, including objects representing biomolecular sequences, multiple sequence alignments and phylogenetic trees. . This is a branch of the original JEBL on http://sourceforge.net/projects/jebl/ to develop a new API and class library. This package will be maintained in the Debian Med team at svn://svn.debian.org/svn/debian-med/trunk/packages/libjebl2-java/trunk/ -- System Information: Debian Release: squeeze/sid APT prefers oldstable APT policy: (500, 'oldstable'), (50, 'unstable') Architecture: i386 (i686) -- 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/20110212171151.8875.48721.report...@mail.an3as.eu
Re: RFA: sonata, mpdscribble,...
Alexander Wirt schrieb am Friday, den 11. February 2011: > Michal Čihař schrieb am Friday, den 11. February 2011: > > > Hi > > > > as I don't use MPD for quite a long time now, it somehow does not make > > sense to maintain MPD related packages anymore. Simply I don't > > have environment to test them. > > > > The packages given for adoption are: > > > > mpdris > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612907 > > > > mpdscribble > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612908 > > > > python-mpd > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612909 > > > > sonata > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612910 > In general it would be good if all those package would be maintained under > the "to be formed" new mpd team. I'll request a new alioth project for mpd > later. It would be nice to have all mpd related packages in that team. I created https://alioth.debian.org/projects/pkg-mpd/ and if you are interested in an mpd team please join pkg-mpd-maintain...@alioth.debian.org. Alex signature.asc Description: Digital signature
Re: Upcoming FTPMaster meeting
Adam Borowski wrote: > Trying to run unmodified Debian on 64MB is a suicide The NSLU2 is still a supported platform, it runs in 32 mb. More or less happily IME. > Thus, I think there are no problems with enabling XZ on all architectures. I see little benefit to enabling it on arm. Size of arm CDs is rarely a concern, since basically nobody ever uses those CDs. -- see shy jo signature.asc Description: Digital signature
Re: Upcoming FTPMaster meeting
* Don Armstrong [110211 23:01]: > 3) uniform, known build environments I think is a major disadvantage of this suggestion. Free Software is about being able to modify what you run. The day a user can no longer simply do a apt-get build-dep name apt-get source name dpkg-source -x name*.dsc cd name-* edit some files dpkg-buildpackage -rfakeroot -us -uc sudo dpkg -i ../*.deb would be a very sad day. If the packages used are only ever built in unnatural virgin environments, there is basically no testing if building them on a real user machine works. And things not tested usually just stop working after some time... Bernhard R. Link -- 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/20110212192239.ga4...@pcpool00.mathematik.uni-freiburg.de
Re: Upcoming FTPMaster meeting
On la, 2011-02-12 at 20:22 +0100, Bernhard R. Link wrote: > If the packages used are only ever built in unnatural virgin > environments, there is basically no testing if building them on > a real user machine works. And things not tested usually just stop > working after some time... Right now, such testing of such build environments is pretty haphazard already. Developers presumably build things with debuild on their development machines, but that's a very small test. If we wanted to be serious about this, it would be nice for someone to set up a maximal build chroot: something with as many packages installed as possible. Then do test builds of all packages, and report problems. (Then upgrade the chroot, install as many new packages as possible, and rebuild everything. Repeat forever.) On the other hand, I don't see that this is all that important. Most packages will build fine in a dirty environment, and if there's trouble, users can report problems, and then they can get fixed. Meanwhile, having uniform, known build environments is good for reproducing builds, and that should be good for reproducing some bugs. -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- 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/1297539475.3105.90.ca...@havelock.lan
Re: Upcoming FTPMaster meeting
]] Lars Wirzenius | If we wanted to be serious about this, it would be nice for someone to | set up a maximal build chroot: something with as many packages installed | as possible. Then do test builds of all packages, and report problems. | (Then upgrade the chroot, install as many new packages as possible, and | rebuild everything. Repeat forever.) Steinar H. Gunderson and Joey Hess started something like this during debconf 7, but I don't believe it took off or went anywhere. | On the other hand, I don't see that this is all that important. Most | packages will build fine in a dirty environment, and if there's trouble, | users can report problems, and then they can get fixed. Meanwhile, | having uniform, known build environments is good for reproducing builds, | and that should be good for reproducing some bugs. You'll want to flag packages gaining dependencies as well as packages changing contents significantly. (Defining significantly is of course part of the challenge.) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wrl5t3mn@qurzaw.varnish-software.com
Re: Branching changelogs or not
Andreas Tille writes: > [Reply-To set to debian-devel] > > Hi, > > on the Debian Med list a discussion about handling changelogs was started[1] > which addressed the following questions: > > 1. What to do with pre-Debian-Release changelogs (if packaging > needed some time and went through several intermediate steps > before it was uploaded to ftp.d.o (with the special case of > releases in other distros). > There was the conclusion to basically keep this changelog > entries. My opinion here is that it depends. There are basically 2 cases: 1) local developement builds that don't leave the house I often compile several versions of a package till I'm satisfied. Sometimes I ask others to test them but in a verry controlled enviroment. The package isn't spread. None the less it helps to bump the version for every build to keep them straight when discussing errors. But when releasing the final version for upload all those intermediate versions are best collapsed into one changelog entry. No need to mention all the in-house, so to speak, testing. 2) intermittant versions that the public might get hold of If I upload a version to e.g. mentors it becomes public. If the sponsor then finds some bug in the upload, usualy days later, I tend to bump the version and keep the changelog entry. People might have grabed it from mentors and installed it and still have it installed weeks or month later. They might also report bugs on it. If the intermittant versions are removed from the changelog the version tracking in the BTS can't work. On the other hand this means the sponsor has to include multiple changelog entries in the changes file (important for closing bugs). So it is a balaning act. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r5bd6l6c.fsf@frosties.localnet
Re: Ideas for object-based git-like storage on Linux
Roger Leigh writes: > On Sun, Feb 06, 2011 at 10:23:00PM -0400, Joey Hess wrote: >> Roger Leigh wrote: >> > There are lots of Debian people out there using git, and some of them >> > have expressed interest over the years in having the ability to use >> > git as a filesystem in its own right (#477942 is an example of one >> > in a package I maintain). >> > >> > I've finally got down to it and written all my thoughts on the topic >> > down in a mostly-organised form, which you can find at >> > >> > http://www.codelibre.net/~rleigh/hashlink.pdf >> > >> > This paper looks at the concept of object-based storage, and the >> > creation of "hashlinks", essentially symlinks which use hashes >> > rather than pathnames to refer to a file. >> >> You may be interested in my git-annex program, which implements just >> such a thing, although in user space, not kernel space. >> http://git-annex.branchable.com/ > > I've been meaning to give git-annex a whirl for a while, but I'm > afraid I've lacked the time to get intimately acquainted with it. > From what I understand, in terms of what a single user could do with > it, it's looking pretty equivalent, the major difference being that > it's entirely in userspace. It's definitely on my TODO list. > > I wanted to look at if it was possible to make multi-user store and > provide a lightweight kernel interface to access it. It might well > be possible to use git-annex as the storage backend for an initial > implementation! All you need is a little bit of fuse code. There really is no need to invent a new kernel interface for this and something like this is best kept in userspace to keep the complexity managable. > Following the suggestion to look at log structured filesystems, I > took a look at things like Plan9's Venti. It's good stuff; my main > objection to most being that they are append-only, with no provision > for GC of no longer referenced data. I would consider that a > requirement for a general purpose store with rapid turnover of data, > especially if you're going to store working copies as well as things > of "commit quality", and even things you commit can be temporary for > rebasing etc. > > > Regards, > Roger MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mxm16kyq.fsf@frosties.localnet
Re: Branching changelogs or not (Was: debian/changelogs, legacy work on packages and other distros)
On Sun, Feb 6, 2011 at 16:51:26 +0100, Andreas Tille wrote: > 3. Whether changelogs should be branched for different Debian > releases, be it testing-proposed-updates, backports or even > derivatives as Ubuntu or others. > As the package itself is branched, the changelog should be, too. Cheers, Julien -- 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/20110212204722.gl3...@radis.liafa.jussieu.fr
Re: Upcoming FTPMaster meeting
On Sat, Feb 12, 2011 at 07:37:55PM +, Lars Wirzenius wrote: > On la, 2011-02-12 at 20:22 +0100, Bernhard R. Link wrote: > > If the packages used are only ever built in unnatural virgin > > environments, there is basically no testing if building them on > > a real user machine works. And things not tested usually just stop > > working after some time... > > Right now, such testing of such build environments is pretty haphazard > already. Developers presumably build things with debuild on their > development machines, but that's a very small test. > > If we wanted to be serious about this, it would be nice for someone to > set up a maximal build chroot: something with as many packages installed > as possible. Then do test builds of all packages, and report problems. > (Then upgrade the chroot, install as many new packages as possible, and > rebuild everything. Repeat forever.) > > On the other hand, I don't see that this is all that important. Most > packages will build fine in a dirty environment, and if there's trouble, > users can report problems, and then they can get fixed. Meanwhile, > having uniform, known build environments is good for reproducing builds, > and that should be good for reproducing some bugs. The other side to this is that fixing such bugs gains us very litle. If we have a guaranteed clean build environment + package build deps, we have as complete consistency as is practicable. If we have a random build environment + package build deps, we might occasionally find something that needs a build-conflict, but we are never going to get complete coverage, and we aren't even considering that the conflicts might get outdated as the system evolves, and they will bitrot and potentially cause more problems down the line. The former situation is simple, robust and maintainable. But the latter, it's a virtually intractable problem, and given the lack of concern about it up to now, it's not a major worry for most people, and from a cost/benefit POV it doesn't look practical. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
armhf: mass bug filing, NMU and sprints
Hello, There has been on-going work to port Debian on ARM devices with later instruction set (armv7) and floating point support. New port [1] is named 'armhf' after discussion on public debian-arm lists [2]. Debian-ports.org holds new port which it is almost at 90% of the archive built [3]. Konstantinos Margaritis has been doing great work and filing bug reports against packages to add support for such new architecture [4]. Debian Installer is being ported as well. In a week time, some of the Debian ARM and Embedded folks are meeting in Cambridge, UK for a Debian sprint [5] to help push 'armhf' into Debian main archive as well as discuss future work for next release to be able to improve our support for ARM and Embedded devices. Following up by another sprint in San Antonio, TX [6]. During following sprint or after we might NMU some packages when it makes sense and maintainer has not been responsive. I would like to ask for comments, advise or whatever useful thoughts you might want to share. There is also a presentation [7] available done during past FOSDEM 2011 at Brussels which might be somehow useful to try to understand ARM history and why do we want another port optimized for netbooks, nettops and other mobile devices with network connectivity. Thanks very much to Genesi [8] Debian partner for hardware and man power support, as well as Toby Churchill, ARM and Linaro. Best regards [1] http://wiki.debian.org/ArmHardFloatPort [2] http://lists.debian.org/debian-arm/2010/07/msg00019.html [3] http://buildd.debian-ports.org/stats/armhf.txt [4] http://wiki.debian.org/ArmHardFloatTodo [5] http://wiki.debian.org/Sprints/2011/EmdebianSprint [6] http://wiki.debian.org/Sprints/2011/GenesiSprintSanAntonio [7] http://people.debian.org/~zumbi/talks/fosdem2011-arm/ (best view on iceweasel) [8] http://www.debian.org/partners/ #Genesi -- Héctor Orón "Our Sun unleashes tremendous flares expelling hot gas into the Solar System, which one day will disconnect us." -- Day DVB-T stop working nicely Video flare: http://antwrp.gsfc.nasa.gov/apod/ap100510.html -- 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/AANLkTi=ZUpm9e6KqXJ0BdpONDGUiDvehwqqp93...@mail.gmail.com
Re: Upcoming FTPMaster meeting
Lars Wirzenius wrote: > > If we wanted to be serious about this, it would be nice for someone to > set up a maximal build chroot: something with as many packages installed > as possible. Then do test builds of all packages, and report problems. > (Then upgrade the chroot, install as many new packages as possible, and > rebuild everything. Repeat forever.) http://lists.debian.org/debian-devel/2008/01/msg00869.html Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- 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/ij6u37$24o$1...@dough.gmane.org
Detecing missing Build-Conflicts (Re: Upcoming FTPMaster meeting)
Roger Leigh wrote: > The other side to this is that fixing such bugs gains us very litle. > > If we have a guaranteed clean build environment + package build deps, > we have as complete consistency as is practicable. > > If we have a random build environment + package build deps, we might > occasionally find something that needs a build-conflict, but we are > never going to get complete coverage [...] > The former situation is simple, robust and maintainable. But the > latter, it's a virtually intractable problem, and given the lack of > concern about it up to now, it's not a major worry for most people, > and from a cost/benefit POV it doesn't look practical. I've built packages from source before, found missing build-conflicts, reported the bugs and seen them fixed. The whole experience was pleasant. I don't think I'm the only one. This can be taken as a vote for or against automated testing for such problems; feel free to pick your favorite and run with it. :) -- 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/20110212214404.GA12775@elie
Re: Upcoming FTPMaster meeting
On Sat, Feb 12, 2011 at 08:57:12PM +, Roger Leigh wrote: > If we have a guaranteed clean build environment + package build deps, > we have as complete consistency as is practicable. > > If we have a random build environment + package build deps, we might > occasionally find something that needs a build-conflict, but we are > never going to get complete coverage, and we aren't even considering > that the conflicts might get outdated as the system evolves, and they > will bitrot and potentially cause more problems down the line. > > The former situation is simple, robust and maintainable. But the > latter, it's a virtually intractable problem, and given the lack of > concern about it up to now, it's not a major worry for most people, > and from a cost/benefit POV it doesn't look practical. My concern is that even if Debian builds all its packages in a clean chroot environment, others may not. If I'm trying to reproduce a problem on sparc or if I'm trying to fix a bug in some package, I'm not going to set up a clean build environment just to do that. If I encounter a problem that is not reproducible in a clean environment[0], I don't want to be told that that problem isn't a bug. Don't get me wrong: I'm fine with autobuilding all packages in a clean environment. But it's simply not practical to do that in many porting or bug-fixing situations[1] and we shouldn't ignore or lessen the severity of bugs that occur in such "dirty" environments. [0] For example, packages that fail to clean properly and hence fail to build the second time around. [1] Or situations where the user may need to apply a patch that has been sent to the BTS but has not found its way to an uploaded version. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Bug#613123: ITP: reptyr -- A tool for moving running programs between ptys
Package: wnpp Severity: wishlist Owner: Evan Broder * Package name: reptyr Version : 0.1+git.20110212t183758.d51bfc2d Upstream Author : Nelson Elhage * URL : http://github.com/nelhage/reptyr * License : MIT/X Programming Lang: C Description : A tool for moving running programs between ptys reptyr is a utility for taking an existing running program and attaching it to a new terminal, and is particularly useful for moving a long-running process into a GNU screen session. reptyr does a more thorough job of transferring programs than many other tools, including the popular "screenify" shell script, because it changes the program's controlling terminal. This means that actions such as window resizes and interrupts are sent to the process from the new terminal. -- 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/20110213000959.6027.77099.reportbug@mingo
Re: Upcoming FTPMaster meeting
On Sat, 2011-02-12 at 15:12 +0100, Jarek Kamiński wrote: > Na grupie linux.debian.devel napisałe(a)ś: > > Trying to run unmodified Debian on 64MB is a suicide, I'd say the weakest > > type that are going to run stock Debian are chroots on n900, which, with > > 256MB, can handle all the phony stuff together with decompression just fine. > > If you allow for everything but the decompression to be swapped out, even > > 128MB would work reasonably. > > No, it's not: > #v+ > [jarek@archeress ~]% free -m > total used free sharedbuffers cached > Mem:60 58 2 0 10 16 > -/+ buffers/cache: 31 29 > Swap: 511 55456 > #v- > > Lenny with (by memory usage): bind, openssh, snmpd, postfix, cups, > dhcp3, ntpd, upnpd, hostapd, mt-daapd, ... works just fine. I could > reduce the memory requirements even more by throwing away some services > and replacing bind with something lighter, but it wasn't necessary. For example: ijc@sarnath:~$ free -m total used free sharedbuffers cached Mem:28 25 2 0 5 9 -/+ buffers/cache: 10 17 Swap: 61 21 39 Lenny firewall (shorewall based) i586 machine + bind, openssh, snmpd, ntpd, openvpn. Been running fine since I installed it with Sarge years ago, the biggest problem is lack of diskspace during dist-upgrade... Ian. -- Ian Campbell you are baked Espy: only half so signature.asc Description: This is a digitally signed message part
Re: there is /usr/lib64 symlink but no /usr/local/lib64
On Fri, Feb 04, 2011 at 07:02:33PM +0100, Tollef Fog Heen wrote: > ]] Yaroslav Halchenko > | please do not slap me too hard (only so that I feel your warm carrying > | touch): > | is there a rationale for: on amd64 Debian systems having > | /lib64 -> /lib > Yes, it's required by the ABI, unfortunately. > | /usr/lib64 -> /usr/lib > Not really, apart from some broken software that will look for stuff > there and be confused if it doesn't exist. I think we should drop it. How do we square that with the FHS, then? The FHS says: If directories /lib or /usr/lib exist, the equivalent directories must also exist in /usr/local. That seems to require /usr/local/lib64 even if we *don't* include /usr/lib64, right? Should we amend policy to take this exception to the FHS? Please open a bug report on policy if you think we should. /me goes back to making lib64 obsolete ;) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#613133: ITP: python-simplemediawiki -- extremely low-level wrapper to the MediaWiki API
Package: wnpp Severity: wishlist Owner: Benjamin Mako Hill * Package name: python-simplemediawiki Version : 1.0.2 Upstream Author : Ian Weller * URL : http://github.com/ianweller/python-simplemediawiki * License : LGPL Programming Lang: Python Description : extremely low-level wrapper to the MediaWiki API A Python module that provides a set of interfaces to the MediaWiki API. You can use this to read, write, and query a remote instance of MediaWiki easily from within a Python application. -- 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/20110213013810.13776.12860.report...@istek.yukidoke.org
Re: [Insight-developers] ITK 3.20.0 python WrapITK wrappers fail to build: too big?
On Wed, Feb 09, 2011 at 10:15:12AM +0100, Ga?tan Lehmann wrote: > > Steve, Luis, > > Splitting ImageToImageFilterB into smaller modules seems to be the > way to go in ITK v3. The attached patch should help! Thanks, Gaetan! I'm building ITK with this patch now for upload to Debian so we'll know in a few days whether it does the trick. Thanks again, -Steve signature.asc Description: Digital signature
patch removal of --unified-reject-files breaks quilt
Hi,
Suddenly, I can't apply my quilt patches:
steve@riemann{insighttoolkit-3.20.0}quilt push -a
Applying patch metaio-test-vtk_source.patch
patch: unrecognized option '--unified-reject-files'
patch: Try `patch --help' for more information.
Patch metaio-test-vtk_source.patch does not apply (enforce with -f)
Patch 2.6.1 has removed this "lenny compatibility option" deliberately.
How can we get quilt working again?
(for now, I've downgraded back to patch 2.6)
Thanks,
-Steve
signature.asc
Description: Digital signature
Re: patch removal of --unified-reject-files breaks quilt
On Sat, 12 Feb 2011 20:17:35 -0600, Steve M. Robbins wrote:
> Suddenly, I can't apply my quilt patches:
>
> steve@riemann{insighttoolkit-3.20.0}quilt push -a
> Applying patch metaio-test-vtk_source.patch
> patch: unrecognized option '--unified-reject-files'
> patch: Try `patch --help' for more information.
> Patch metaio-test-vtk_source.patch does not apply (enforce with -f)
>
> Patch 2.6.1 has removed this "lenny compatibility option" deliberately.
> How can we get quilt working again?
In my case by fixing ~/.quiltrc:
#QUILT_PATCH_OPTS="--unified-reject-files"
Since commenting out the option quilt works again :)
Cheers,
gregor
--
.''`. http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4
: :' : Debian GNU/Linux user, admin, & developer - http://www.debian.org/
`. `' Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
`-NP: Queen: Is This The World We Created..
signature.asc
Description: Digital signature
Re: patch removal of --unified-reject-files breaks quilt
On Sun, Feb 13, 2011 at 03:53:34AM +0100, gregor herrmann wrote:
> On Sat, 12 Feb 2011 20:17:35 -0600, Steve M. Robbins wrote:
>
> > Suddenly, I can't apply my quilt patches:
> >
> > steve@riemann{insighttoolkit-3.20.0}quilt push -a
> > Applying patch metaio-test-vtk_source.patch
> > patch: unrecognized option '--unified-reject-files'
> > patch: Try `patch --help' for more information.
> > Patch metaio-test-vtk_source.patch does not apply (enforce with -f)
> >
> > Patch 2.6.1 has removed this "lenny compatibility option" deliberately.
> > How can we get quilt working again?
>
> In my case by fixing ~/.quiltrc:
>
> #QUILT_PATCH_OPTS="--unified-reject-files"
>
> Since commenting out the option quilt works again :)
Aha! I have the same option in .quiltrc. Thanks, I'll remove
it and try again.
Cheers,
-Steve
signature.asc
Description: Digital signature
Re: Upcoming FTPMaster meeting
On 12/02/11 at 15:29 -0600, Raphael Geissert wrote: > Lars Wirzenius wrote: > > > > If we wanted to be serious about this, it would be nice for someone to > > set up a maximal build chroot: something with as many packages installed > > as possible. Then do test builds of all packages, and report problems. > > (Then upgrade the chroot, install as many new packages as possible, and > > rebuild everything. Repeat forever.) > > http://lists.debian.org/debian-devel/2008/01/msg00869.html As Raphael pointed out, I did some work on this in the past. But I consider it mostly a waste of time, since the benefits are very little. Also, there are many areas where automated testing is interesting / useful, but where we don't do everything we could yet, like the use of test suites, or installation/upgrades testing in setups that are more complex than piuparts'. I would rather see someone work on this. - Lucas -- 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/20110213074101.ga1...@xanadu.blop.info
