Re: Xen status in lenny?
]] maximilian attems | On Fri, Jul 18, 2008 at 12:45:21AM +0200, Bastian Blank wrote: | > On Thu, Jul 17, 2008 at 05:34:28PM +0300, Pasi Kärkkäinen wrote: | > > That SLES forward-port for 2.6.26 is not acceptable based on Debian kernel | > > patch policy: http://wiki.debian.org/DebianKernelPatchAcceptanceGuidelines | > | > Which is only the case for the main images. We have support for | > additional feature sets, which have less strict rules. | | right but still no excuse to bring in a patch set that is *known* | to not be merged upstream. Of course it is when it is to prevent a fairly substantial regression from etch. Whether etch should have shipped a dom0 or not is a different question and a little late to complain about now; we just have to do the best we can with what we have. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Xen status in lenny?
On Fri, Jul 18, 2008 at 09:57:29AM +0200, Tollef Fog Heen wrote: > > Of course it is when it is to prevent a fairly substantial regression > from etch. Whether etch should have shipped a dom0 or not is a > different question and a little late to complain about now; we just have > to do the best we can with what we have. an lenny+half with upstream merged version makes sense indeed. until then people can rely on etch + etch unofficial images. the regression would have been *huge* if we had no guest image support at all, but that got fixed and is tested. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Xen status in lenny?
On Fri, Jul 18, 2008 at 01:04:45AM +0200, maximilian attems wrote: > right but still no excuse to bring in a patch set that is *known* > to not be merged upstream. So OpenVZ is also out of reach. Bastian -- There is an order of things in this universe. -- Apollo, "Who Mourns for Adonais?" stardate 3468.1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Xen status in lenny?
On Fri, Jul 18, 2008 at 11:08:43AM +0200, Bastian Blank wrote: > On Fri, Jul 18, 2008 at 01:04:45AM +0200, maximilian attems wrote: > > right but still no excuse to bring in a patch set that is *known* > > to not be merged upstream. > > So OpenVZ is also out of reach. openvz is actively working on namespace merge and using the emerging bits. their patchsize is decreasing. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Xen status in lenny?
On Fri, Jul 18, 2008 at 11:23:19AM +0200, maximilian attems wrote: > On Fri, Jul 18, 2008 at 11:08:43AM +0200, Bastian Blank wrote: > > On Fri, Jul 18, 2008 at 01:04:45AM +0200, maximilian attems wrote: > > > right but still no excuse to bring in a patch set that is *known* > > > to not be merged upstream. > > So OpenVZ is also out of reach. > openvz is actively working on namespace merge and using the emerging > bits. their patchsize is decreasing. Which does not change the fact that the patch in this form will never be accepted. Bastian -- Each kiss is as the first. -- Miramanee, Kirk's wife, "The Paradise Syndrome", stardate 4842.6 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Xen status in lenny?
On Fri, Jul 18, 2008 at 11:44:53AM +0200, Bastian Blank wrote: > On Fri, Jul 18, 2008 at 11:23:19AM +0200, maximilian attems wrote: > > On Fri, Jul 18, 2008 at 11:08:43AM +0200, Bastian Blank wrote: > > > On Fri, Jul 18, 2008 at 01:04:45AM +0200, maximilian attems wrote: > > > > right but still no excuse to bring in a patch set that is *known* > > > > to not be merged upstream. > > > So OpenVZ is also out of reach. > > openvz is actively working on namespace merge and using the emerging > > bits. their patchsize is decreasing. > > Which does not change the fact that the patch in this form will never be > accepted. sure patchsets of such size are never gobed in *one* step. here you'll find a nice metric on their merge success: http://community.livejournal.com/openvz/22369.html -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Xen status in lenny? and vserver?
On Fri, 18 Jul 2008, maximilian attems wrote: On Fri, Jul 18, 2008 at 11:08:43AM +0200, Bastian Blank wrote: On Fri, Jul 18, 2008 at 01:04:45AM +0200, maximilian attems wrote: > right but still no excuse to bring in a patch set that is *known* > to not be merged upstream. So OpenVZ is also out of reach. openvz is actively working on namespace merge and using the emerging bits. their patchsize is decreasing. and whats about vserver? -- Florian Reitmeir -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#490805: ITP: txtreader -- text reader, mainly used for reading text originally novels
On Mon, Jul 14, 2008 at 08:23:27PM +0800, LI Daobing wrote: > Package: wnpp > Severity: wishlist > Owner: LI Daobing <[EMAIL PROTECTED]> > > * Package name: txtreader > Version : 0.4.4 > Upstream Author : [EMAIL PROTECTED] > * URL : http://www.minisrc.com/?q=taxonomy/term/2 > * License : GPL > Programming Lang: C++ > Description : text viewer, mainly used for reading text originally > novels Ummm, Do you mean: Description : text viewer, mainly used for reading text of original novels -- Chris. == "One, with God, is always a majority, but many a martyr has been burned at the stake while the votes were being counted." -- Thomas B. Reed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Xen status in lenny? and vserver?
Florian Reitmeir dijo [Fri, Jul 18, 2008 at 11:39:22AM +0200]: > >openvz is actively working on namespace merge and using the emerging > >bits. their patchsize is decreasing. > > and whats about vserver? vserver support is just fine. -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: libprojectM, new upstream version.
Il giorno gio, 17/07/2008 alle 17.30 -0500, William Pitcock ha scritto: > > audacious-plugins is already compatible with the new version of > > libprojectM... I've looked at the logs of buildd of > audacious-plugins > > and the projectM plugin isn't build from version 1.4.5-1, so the > update > > of libprojectM don't break anything, indeed I tried to compile with > > libprojectM 1.2 and it builds also the projectM plugin... So I'm > going > > to package the new library version... > > Then you cause a feature regression. *great*. no I don't cause any feature regression, because audacious-plugins doesn't build any projectM plugin. please check your buildd logs. contrary with the version 1.2.0 the plugin builds, so it's a feature enhancement, not a regression... signature.asc Description: Questa è una parte del messaggio firmata digitalmente
Re: Bug#480563: Doesn't strip binary NMU version (+b1, +bN etc.) when reporting bugs
Hello Developers! I would like to hear some suggestions about this (#480563) bug (trascript below): On Sun, May 11, 2008 at 11:48, Loïc Minier <[EMAIL PROTECTED]> wrote: >On Sun, May 11, 2008 at 01:44, Chris Lawrence <[EMAIL PROTECTED]> wrote: >> On Sat, May 10, 2008 at 4:48 PM, Loïc Minier <[EMAIL PROTECTED]> wrote: >>> reportbug uses the package version when reporting bugs, but this might >>> include a bin NMU extension, e.g. +b1. As debbugs/our BTS tracks bugs >>> at the source level, the bin NMU part should probably be stripped when >>> reporting bugs against Debian. >> >> I'm not sure this would be correct behavior, since a binNMU could >> quite plausibly introduce bugs that wouldn't be present before the >> binNMU. Perhaps debbugs should be smarter about binNMUs though. > > I wondered about this as well before filing the bug; on IRC > (#debian-devel-fr), the consensus was slightly in favor of reporting it > against reportbug, but I know it probably affects other bug reporting > tools. > > Changing debbugs to track binary version is really hard, I think we > shouldn't intermix this feature with the rewrite, however it might be > as simple to rewrite versions on the debbugs side of things rather than > coding it in all bug reporting clients. should we strip-off the binNMU extension from the package version in reportbug? I'm more inclined to Chris' position (not strip because binNMU can introduce bugs not present in previous version) but DDs more experienced than me can have a wider view and a different opinion. Thanks in advance, Sandro -- Sandro Tosi (aka morph, Morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-xen-devel] Xen status in lenny?
On Fri, Jul 11, 2008 at 08:37:01AM +0100, Ian Campbell wrote: [..snip..] > dom0 support is being worked on by Fedora people (I think) but there are > no patches upstream yet. We could recommend kvm+xenner+libvirt as "dom0" for people with hardware virtualization support: http://kraxel.fedorapeople.org/xenner/ I don't think we have this packaged yet though. If anybody wants to work on this I'd be happy to help. Cheers, -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#480563: Doesn't strip binary NMU version (+b1, +bN etc.) when reporting bugs
"Sandro Tosi" <[EMAIL PROTECTED]> writes: > I'm more inclined to Chris' position (not strip because binNMU can > introduce bugs not present in previous version) but DDs more > experienced than me can have a wider view and a different opinion. I'd tend to agree -- better to err on the side of sending extra information, which the BTS can presumably at least arrange to ignore for the time being if fully handling it is too involved. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#490805: ITP: txtreader -- text reader, mainly used for reading text originally novels
Quoth Chris Bannister <[EMAIL PROTECTED]>, on 2008-07-19 00:44:04 +1200: > On Mon, Jul 14, 2008 at 08:23:27PM +0800, LI Daobing wrote: > > Description : text viewer, mainly used for reading text originally > > novels > > Do you mean: > > Description : text viewer, mainly used for reading text of original novels I would more expect "text viewer, originally used for reading novels". "text viewer, mainly used for reading text" seems fairly redundant to me. ---> Drake Wilson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re: Include on first iso: m-a, build essential, kernel headers
On Wed, 2008-07-16 at 22:29 +0200, Mike Hommey wrote: > I'm wondering... do we have binary packages for all kernel modules we have > (free) -source packages for so that such kernel modules don't need to be > built by users ? No, but *most* of them are built by linux-modules-extra-2.6 or linux-modules-contrib-2.6. (Even non-free modules be auto-built by linux-modules-nonfree-2.6, and some firmware is packaged in firmware-nonfree. But those obviously must not be included on official CDs.) Ben. -- Ben Hutchings Nothing is ever a complete failure; it can always serve as a bad example. signature.asc Description: This is a digitally signed message part
Re: Bug#480563: Doesn't strip binary NMU version (+b1, +bN etc.) when reporting bugs
On Fri, 18 Jul 2008, Sandro Tosi wrote: > On Sun, May 11, 2008 at 11:48, Loïc Minier <[EMAIL PROTECTED]> wrote: > >On Sun, May 11, 2008 at 01:44, Chris Lawrence <[EMAIL PROTECTED]> wrote: > >> On Sat, May 10, 2008 at 4:48 PM, Loïc Minier <[EMAIL PROTECTED]> wrote: > >>> reportbug uses the package version when reporting bugs, but this might > >>> include a bin NMU extension, e.g. +b1. As debbugs/our BTS tracks bugs > >>> at the source level, the bin NMU part should probably be stripped when > >>> reporting bugs against Debian. No, it should not. The BTS knows how to resolve binary versions to source versions, and does all of this automatically. > > I wondered about this as well before filing the bug; on IRC > > (#debian-devel-fr), the consensus was slightly in favor of > > reporting it against reportbug, but I know it probably affects > > other bug reporting tools. > > > > Changing debbugs to track binary version is really hard, We don't currently; there was some discussion of allowing a bug to be associated with a particular set of binary versions, but that is a feature with relatively limited utility. [Such bugs would be fixed by any upload, and would have no automatic propogation.] Furthermore, the cases where a bug is associated with a particular binary, and not the source package as well is a fairly small minority of the bugs that are reported; only expert users and/or package maintainer would be making use of this feature anyway. > should we strip-off the binNMU extension from the package version in > reportbug? No. The BTS is more than capable of resolving binary versions to source versions, and knows far better what the source version of a particular binary version than an arbitrary regex in reportbug. Don Armstrong -- Personally, I think my choice in the mostest-superlative-computer wars has to be the HP-48 series of calculators. They'll run almost anything. And if they can't, while I'll just plug a Linux box into the serial port and load up the HP-48 VT-100 emulator. -- Jeff Dege, [EMAIL PROTECTED] http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#490805: ITP: txtreader -- text reader, mainly used for reading text originally novels
Drake Wilson <[EMAIL PROTECTED]> writes: > Quoth Chris Bannister <[EMAIL PROTECTED]>, on 2008-07-19 00:44:04 +1200: > > On Mon, Jul 14, 2008 at 08:23:27PM +0800, LI Daobing wrote: > > > Description : text viewer, mainly used for reading text originally > > > novels > > > > Do you mean: > > > > Description : text viewer, mainly used for reading text of original > > novels > > I would more expect "text viewer, originally used for reading novels". I would parse the text from LI Daobing as: Description: text viewer, mainly used for reading text that was originally the text of novels and would refine it as: Description: text viewer for reading novels > "text viewer, mainly used for reading text" seems fairly redundant to me. Agreed. -- \ “To save the world requires faith and courage: faith in reason, | `\and courage to proclaim what reason shows to be true.” | _o__)—Bertrand Russell | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ffmpeg2theora
Hello, I didn't get a response to the enclosed mail which was sent to [EMAIL PROTECTED] Is there some reason why a package will not be Installed even after a build succeeds? On Sun, 13 Jul 2008, Kapil Hari Paranjape wrote: > I uploaded ffmpeg2theora 0.21-0.1 to the archive on Jun 28th. > It was built the same day on the mipsel architecture. > > http://buildd.debian.org/fetch.cgi?pkg=ffmpeg2theora;ver=0.21-0.1;arch=mipsel;stamp=1214686479 > > The build appears to have been successful. > > For some reason it does not seem to have made it to the > Upload/Install stage ater that. > > Could you please check and let me know? Regards, Kapil. -- signature.asc Description: Digital signature
