Bug#564045: O: flashybrid
Informing -devel, just in case it is useful for anyone: On Thu, Jan 07, 2010 at 11:55:01AM +0200, Diego wrote: > Package: wnpp > Severity: normal > > I have lost interest in maintaining this package. Just pulling it out > of the repositories will vanish the code from the internet, which is a > bad bad thing. > > Since Linus is always right, I uploaded the full source + changes to > github, so anyone who wants will be able to maintain this package can > take over the project, and have the full history. The repository can > be found at: > http://github.com/elcuco/flashybrid > A few extra words about the package: it helps keeping most of the system read-only, while still allowing a read-write remount occasionally and such. A different (and nowadays more common) solution to a similar problem is to use union mounts. -- Tzafrir Cohen icq#16849755 jabber:tzafrir.co...@xorcom.com +972-50-7952406 mailto:tzafrir.co...@xorcom.com http://www.xorcom.com iax:gu...@local.xorcom.com/tzafrir -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
On Tue, 05 Jan 2010, Michael Gilbert wrote: > On Wed, 6 Jan 2010 11:01:01 +0800 Paul Wise wrote: > > On Wed, Jan 6, 2010 at 9:20 AM, Kees Cook wrote: > > > There is a maintained (by RedHat) patch for dealing with PIE. I already > > > > It is perfectly reasonable to reject patches until they are upstream. > > I personally will never add patches to Debian without either > > committing them upstream myself or some indication that they already > > have been or will be accepted upstream. IIRC the Debian kernel team > > has similar policies. Why hasn't RedHat upstreamed the patch? They are > > usually good about doing that. Perhaps you could push them to do so. > > While normally I would agree with your logic, when it comes to security > I think a more cautious logic must prevail. Remember that item 4 of It is exactly because of security that many of us frown *heavily* upon anything that is not submitted upstream. We _did_ learn our lesson from the OpenSSL problem. So, the question that needs an answer is: _why_ isn't it upstream yet? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Apparent portmap to rpcbind transition?
On Mon, Jan 04, 2010 at 02:45:27PM +, Mark Brown wrote: > I've not seen any discussion of how this is supposed to work, or any > mention of the planned transition before it broke my systems. There's > quite a few bugs in ONCRPC related packages related to the current state > but none of them seem to have a summary of what the intention is - does > anyone have any information here? The rpcbind package is fixed now as far as I can see, if you install it then it will remove portmap, and nfs-common and the kernel server seem to work on my systems (I use NFSv4 for all shares). I see that nfs-common depends on portmap | rpcbind. However, nis only depends on portmap, and can therefore not be installed at the same time as rpcbind. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Re: Switch on compiler hardening defaults
On Thu, 07 Jan 2010, Henrique de Moraes Holschuh wrote: > So, the question that needs an answer is: _why_ isn't it upstream yet? And that has been answered in another part of this thread. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Xen support on Squeeze
On Sun, 03 Jan 2010, William Pitcock wrote: > > That was opposed quite strongly by the kernel folks last time it was > > attempted. Were there any fundamental changes in the Xen dom0 patches > > since then? > > Only by the kernel folks which believe all of the crap that the KVM > guys say about Xen. There are plenty of kernel developers willing > to see the patches merged. Hmm, you have a problem there. Linus is very likely going to cheerfully tell the Xen and KVM developers to duke it out in a bloodbath, and to not forget to bring AlacrityVM into the fray either. He could care less for virtualization, and he is likely to refuse to merge anything non-trivial until the "virtualization crazy people" manage to reach a consensus on a sane API. Look for the AlacrityVM threads in LKML if you doubt me. Note: I am not defending KVM. I don't agree with their main ideology (that their hardware-emulating approach is the One True Way). But I can well see why Linus decided to take that instance. Xen's track record from hell on getting their act cleaned up for upstream merging is also going to get in the way. Some people have long memories. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Allow package bug scripts to unconditionally stop reportbug
Hello, since version 4.10, reportbug checks the return code of the package bug scripts and, it != 0, ask the user if to continue or stop. This is the way we decided to fix #382010 . But now I'm wondering if there could be a use case of allowing the scripts to unconditionally stop reportbug, for example using a "special" exit code (140 f.e.) . I don't have a strong feeling about it, and letting a program abort reportbug without a clear explanation to users might be bad, but I'd like to hear what do you think about it. If a relevant number of you prefers to have this "fast way out", I'm going and code it, else we can go on with the solution currently in place. Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Allow package bug scripts to unconditionally stop reportbug
On Thu, Jan 07, 2010 at 02:35:47PM +0100, Sandro Tosi wrote: > Hello, > since version 4.10, reportbug checks the return code of the package > bug scripts and, it != 0, ask the user if to continue or stop. This is > the way we decided to fix #382010 . > > But now I'm wondering if there could be a use case of allowing the > scripts to unconditionally stop reportbug, for example using a > "special" exit code (140 f.e.) . > > I don't have a strong feeling about it, and letting a program abort > reportbug without a clear explanation to users might be bad, but I'd > like to hear what do you think about it. > > If a relevant number of you prefers to have this "fast way out", I'm > going and code it, else we can go on with the solution currently in > place. What's the use case of this? I've read the bug report saying "my /usr/share/bug script"... but which one? -- http://www.debian.org - The Universal Operating System signature.asc Description: Digital signature
Re: Xen support on Squeeze
On Thu, Jan 07, 2010 at 11:06:56AM -0200, Henrique de Moraes Holschuh wrote: > On Sun, 03 Jan 2010, William Pitcock wrote: > > > That was opposed quite strongly by the kernel folks last time it was > > > attempted. Were there any fundamental changes in the Xen dom0 patches > > > since then? > > > > Only by the kernel folks which believe all of the crap that the KVM > > guys say about Xen. There are plenty of kernel developers willing > > to see the patches merged. > > Hmm, you have a problem there. > > Linus is very likely going to cheerfully tell the Xen and KVM developers to > duke it out in a bloodbath, and to not forget to bring AlacrityVM into the > fray either. He could care less for virtualization, and he is likely to > refuse to merge anything non-trivial until the "virtualization crazy people" > manage to reach a consensus on a sane API. Look for the AlacrityVM threads > in LKML if you doubt me. > Then again the KVM vs. AlacrityVM discussion is a bit different. AlacrityVM is a fork of KVM.. > Note: I am not defending KVM. I don't agree with their main ideology (that > their hardware-emulating approach is the One True Way). But I can well see > why Linus decided to take that instance. > > Xen's track record from hell on getting their act cleaned up for upstream > merging is also going to get in the way. Some people have long memories. > Linus has been happily accepting a lot of Xen pv_ops (domU) patches from Jeremy lately.. So it seems to be mostly about the 'quality' of the code. -- Pasi -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Apparent portmap to rpcbind transition?
On Thu, Jan 07, 2010 at 01:52:43PM +0100, Guus Sliepen wrote: > I see that nfs-common depends on portmap | rpcbind. However, nis only depends > on portmap, and can therefore not be installed at the same time as rpcbind. Yes, this is the root of the issue - if we're changing what we're doing with portmappers what's the plan for managing this. What should be the default, is the old portmap going away and so on. At the minute there's been no coordination at all, the first time I heard of rpcbind was when I was resolving the NFS breakage. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#564100: ITP: libtest-sharedfork-perl -- module to run tests in multiple processes and merge results
Package: wnpp Owner: Jonathan Yu Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libtest-sharedfork-perl Version : 0.11 Upstream Author : Tokuhiro Matsuno * URL : http://search.cpan.org/dist/Test-SharedFork/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : module to run tests in multiple processes and merge results Test::SharedFork is utility module for tests built using Test::Builder (which constitute the majority of test modules on CPAN). It allows developers to run tests in multiple processes, in parallel, and combine the results together. NOTE: this module is needed for packaging Plack -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Apparent portmap to rpcbind transition?
Mark Brown schrieb am Donnerstag, den 07. Januar 2010: Hi, > > I see that nfs-common depends on portmap | rpcbind. However, nis only > > depends > > on portmap, and can therefore not be installed at the same time as rpcbind. > > Yes, this is the root of the issue - if we're changing what we're doing > with portmappers what's the plan for managing this. What should be the > default, is the old portmap going away and so on. At the minute there's > been no coordination at all, the first time I heard of rpcbind was when > I was resolving the NFS breakage. Ehm, the reason was a bug. nfs-common was broken, if connecting to localhost it was only trying ::1, but without a fallback on 127.0.0.1. There wasn't any indication in the package that this breakage was on purpose. I guess it was just bad testing. The NMU is in delayed/1 and should hit unstable in a few hours. Alex -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Mixx: Your friend has invited you to join Mixx!
Your friend has invited you to join Mixx! To register, please click the following link, or paste it in your browser: http://www.mixx.com/user/invite/2f3836d650e8bdd4278416e4db228de75fc6fb89 - Your friends at Mixx -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Allow package bug scripts to unconditionally stop reportbug
On Thu, Jan 07, 2010 at 02:35:47PM +0100, Sandro Tosi wrote: > But now I'm wondering if there could be a use case of allowing the > scripts to unconditionally stop reportbug, for example using a > "special" exit code (140 f.e.) . I'm generally opposed to this. There are no use cases that I can think of, and a poorly-written bug script can basically prevent anyone but the most advanced users from reporting bugs. *However*, if you do decide to implement this, the error code should not be 126, 127, 128, or 255. It should probably be something like 128+_NSIG+1 (where _NSIG is included by signal.h), to avoid any accidental triggering of this functionality. Decimal 200 might be a decent choice. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Allow package bug scripts to unconditionally stop reportbug
> But now I'm wondering if there could be a use case of allowing the > scripts to unconditionally stop reportbug, for example using a > "special" exit code (140 f.e.) . 42 would be nicer. Besides, does that mean I just have to put a bugscript in all my packages exiting 42 and those bugs stop flowing in? (I dont think this should be without an override for the user) -- bye, Joerg Ganneff: Im confident in your ability to create flamewars. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Allow package bug scripts to unconditionally stop reportbug
Joerg Jaspert wrote:
>> But now I'm wondering if there could be a use case of allowing the
>> scripts to unconditionally stop reportbug, for example using a
>> "special" exit code (140 f.e.) .
>
> 42 would be nicer.
>
> Besides, does that mean I just have to put a bugscript in all my
> packages exiting 42 and those bugs stop flowing in?
>
It would certainly shorten the freeze period :)
--
Mehdi Dogguy مهدي الدڤي
me...@{dogguy.org,debian.org}
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Work-needing packages report for Jan 8, 2010
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 634 (new: 3) Total number of packages offered up for adoption: 122 (new: 0) Total number of packages requested help for: 55 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: flashybrid (#564045), orphaned today Description: automates use of a flash disk as the root filesystem Installations reported by Popcon: 90 purity (#564018), orphaned today Description: Automated purity testing software Reverse Depends: purity-off Installations reported by Popcon: 197 yafray (#564119), orphaned today Description: a modern, xml-speaking raytracing-based rendering system Installations reported by Popcon: 802 631 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. No new packages have been given up for adoption, but a total of 122 packages are awaiting adoption. See http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: apt-cross (#540341), requested 153 days ago Description: retrieve, build and install libraries for cross-compiling Reverse Depends: apt-cross emdebian-buildsupport emdebian-qa emdebian-rootfs emdebian-tools libemdebian-tools-perl Installations reported by Popcon: 316 ara (#450876), requested 788 days ago Description: utility for searching the Debian package database Installations reported by Popcon: 121 asymptote (#517342), requested 314 days ago Description: script-based vector graphics language inspired by MetaPost Installations reported by Popcon: 1114 athcool (#278442), requested 1899 days ago Description: Enable powersaving mode for Athlon/Duron processors Installations reported by Popcon: 169 boinc (#511243), requested 364 days ago Description: BOINC distributed computing Reverse Depends: boinc-app-milkyway boinc-app-seti boinc-dbg Installations reported by Popcon: 1649 cvs (#354176), requested 1414 days ago Description: Concurrent Versions System Reverse Depends: crossvc cvs-autoreleasedeb cvs-buildpackage cvs2cl cvs2html cvschangelogbuilder cvsconnect cvsd cvsps cvsservice (10 more omitted) Installations reported by Popcon: 24611 dctrl-tools (#448284), requested 803 days ago Description: Command-line tools to process Debian package information Reverse Depends: aptfs debian-goodies debtree dlocate haskell-devscripts libsbuild-perl linux-patch-debianlogo mlmmj simple-cdd ubuntu-dev-tools Installations reported by Popcon: 13163 dietlibc (#544060), requested 132 days ago Description: diet libc - a libc optimized for small size Reverse Depends: libowfat-dev Installations reported by Popcon: 237 dpkg (#282283), requested 1873 days ago Description: dselect: a user tool to manage Debian packages Reverse Depends: acct adacontrol advi advi-examples alien alqalam alsa-source am-utils-doc apt-build apt-cross (457 more omitted) Installations reported by Popcon: 87149 elvis (#432298), requested 913 days ago Description: powerful clone of the vi/ex text editor (with X11 support) Reverse Depends: elvis elvis-console elvis-tools Installations reported by Popcon: 413 emdebian-tools (#540333), requested 153 days ago Description: emdebian crossbuilding tool set Reverse Depends: emdebian-buildsupport emdebian-qa emdebian-rootfs emdebian-tools Installations reported by Popcon: 169 flightgear (#487388), requested 565 days ago Description: Flight Gear Flight Simulator Installations reported by Popcon: 659 fluxbox (#552328), requested 74 days ago Description: Highly configurable and low resource X11 Window manager Reverse Depends: bbmail Installations reported by Popcon: 3023 gentoo (#422498), requested 977 days ago Description: a fully GUI-configurable, two-pane X file manager Installations reported by Popcon: 215 gnat-4.4 (#539562), requested 637 days ago Description: help needed to execute test cases Reverse Depends: adabrowse adacontrol asis-programs gnat gnat-4.4 libahven1-dev libahven17.0 libasis2008 libasis2008-dev libaunit1-dev (40 more omitted) Installations reported by Popcon: 157 gnat-gps (#496905), requested 497 days ago Description: co-maintainer needed Installations reported by Popcon: 199
Re: Allow package bug scripts to unconditionally stop reportbug
On Thu, 2010-01-07 at 14:35 +0100, Sandro Tosi wrote: > Hello, > since version 4.10, reportbug checks the return code of the package > bug scripts and, it != 0, ask the user if to continue or stop. This is > the way we decided to fix #382010 . > But now I'm wondering if there could be a use case of allowing the > scripts to unconditionally stop reportbug, for example using a > "special" exit code (140 f.e.) . This is odd... it sounds like "You wanted to file a bug, well... don't!" How can a package script know what a user want to report? On what basis is it going to prevent the user from reporting a bug? I can think of lots of bad reasons to use such feature, but I can't think of any sensible one. Some bad reasons: * Your version isn't supported * Your version is outdated * Your configuration is broken * The package is half-installed * You are not using Debian * You have mixed distribution version* * PEBKAC > If a relevant number of you prefers to have this "fast way out", I'm > going and code it, else we can go on with the solution currently in > place. If you do implement it, please, provide a way to override it with a command line option. Thanks Franklin -- Can you master Open-source software? Prove it, write documentation. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
