Re: lilo removal in squeeze (or, "please test grub2")
On 2010-05-24, Florian Zagler wrote: > Don't drop lilo in squeeze but mark it orphaned. Leave it in Squeeze and > schedule the removal for Squeeze+1. Orphaned packages in a release are a pain if nobody steps up to fix RC bugs suddenly popping up in stable. 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/slrnhvka69.ml7.tr...@kelgar.0x539.de
Re: Possible boot ordering issues with the packages in Sid
[Christian PERRIER]
> I wonder what in keymap.sh is triggerring this. TTBOMK,
> /etc/init.d/keymap.sh is meant to work without /usr being mounted
This part of the script matches the /usr/s?bin regex:
unicode_start_stop()
{
# Switch unicode mode by checking the locale.
# This will be needed before loading the keymap.
[ -x /usr/bin/unicode_start ] || [ -x /bin/unicode_start ] || return
[ -x /usr/bin/unicode_stop ] || [ -x /bin/unicode_stop ] || return
No idea if it is a false positive or not. Note that one need to be
careful with scripts started from rcS.d/, to make sure no dependency
loop is created. Scripts that need to start before mountall.sh or
mountnfs.sh can't depend on $local_fs or $remote_fs without creating a
loop.
But then again, I believe a lot of scripts currently started in rcS.d/
should be moved out of there. :)
> samba is not using syslog by default in Debian. Still, I understand
> this might be a problem for users who want to activate logging
> through syslog. I don't really see any problem adding $syslog to
> dependencies
It is probably the best option, yeah. I believe it best to start most
services after the syslog collector, to make sure any kernel messages
generated are collected at the correct time.
Happy hacking,
--
Petter Reinholdtsen
--
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/2fl7hmtzrm9@login1.uio.no
Re: Parallel booting enabled by default
On Fri, May 21, 2010 at 09:42:42PM +0200, Petter Reinholdtsen wrote: > > [Kurt Roeckx] > > And they should probably also be removed from /etc/rc1.d/ in that > > case because it also uses sendsigs. Lintian warns about this as far > > as I know. > > Perhaps. I am not quite sure how that will interact with runlevel > switching to and from runlevel 1. I am sure it is safe for runlevels > 0 and 6, as it is not possible to switch away from those and back to > runlevels 1-5. It is important to make sure services are restarted > > We want to make sure services stopped when switching to runlevel 1 are > started when switching back to runlevel 2. I don't see why you think that would be a problem. Either the init script in runlevel 1 is going to stop the service, or it gets killed. And going back to runlevel 2 should start the same services as started otherwise in that runlevel. Kurt -- 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/20100524083359.ga13...@roeckx.be
Re: Possible boot ordering issues with the packages in Sid
> warning: script watchdog/init.d/watchdog possibly missing dependency on > $syslog This one's a false positive because watchdog depends on $all. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber mes...@jabber.org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- 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/20100524091620.ga12...@feivel.credativ.lan
Bug#582864: RFP: uwsgi -- uWSGI is a fast, self-healing, developer-friendly WSGI server
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org --- Please fill out the fields below. --- Package name: uwsgi Version: 0.9.5.1 Upstream Author: Roberto De Ioris robe...@unbit.it URL: http://projects.unbit.it/uwsgi/wiki License: GPL Description: fast, self-healing, developer-friendly WSGI server uWSGI is a fast (pure C), self-healing, developer-friendly WSGI server, aimed for professional python webapps deployment and development. . Over time it has evolved in a complete stack for networked/clustered python applications, implementing message/object passing, RPC and process management. There is some work done in this ppa https://launchpad.net/~stevecrozz/+archive/ppa -- Riccardo Magliocchetti -- 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/4bfa4654.9020...@gmail.com
Re: lilo removal in squeeze (or, "please test grub2")
Kurt Roeckx writes: > On Sun, May 23, 2010 at 01:11:48PM +0200, Cyril Brulebois wrote: >> William Pitcock (22/05/2010): >>> This means that users should *test grub2 extensively* before Squeeze >>> is released so that any issues can be resolved now. >> >> There should also be some folks fixing the discovered issues. > > grub2 currently seems to be having 18 RC bugs, plus a whole bunch > of merged bugs, while lilo only has 1 RC bug. I chatted about this with the grub upstream a couple of days ago. According to Vladimir, most of those bugs are already fixed, but there's nobody around to do a new upload. Both grub maintainers (Felix Zielke and Robert Millan) unexpectedly disappeared some time ago. -- Regards, Feri. -- 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/878w791w0v@tac.ki.iif.hu
Bug#582867: RFP: pocketsphinx -- a small-footprint continuous speech recognition system
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org --- Please fill out the fields below. --- Package name: pocketsphinx Version: 0.6 Upstream Author: David Huggins-Daines URL: http://cmusphinx.sourceforge.net/ License: BSD Description: a small-footprint continuous speech recognition system PocketSphinx is a small-footprint continuous speech recognition system, freely licensed under a simplified BSD license, suitable for handheld and desktop applications. It features: . * Support for semi-continuous, phonetically-tied, and fully continuous acoustic models * Model footprint on disk of about 10MB per language * Memory footprint under 20MB for medium-vocabulary continuous recognition * Trigram language models and JSGF finite-state grammars * Acoustic models for English and Mandarin * Small language models for English and Mandarin (simplified and traditional characters) * Python language bindings * GStreamer multimedia framework integration Upstream already provides some packages that builds fine in debian here https://launchpad.net/~dhuggins -- Riccardo Magliocchetti -- 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/4bfa499d.60...@gmail.com
Re: lilo removal in squeeze (or, "please test grub2")
Stephen Powell writes: > Both grub-legacy and grub-pc use sectors on the hard disk outside of > the master boot record [...] This breaks the design of the backup > software that my employer uses. This backup software backs up the > master boot record and all partitions; but since the extra sectors > used by grub-legacy and grub-pc are outside the master boot record and > are not part of any partition, they don't get backed up. > Consequently, if we have a hard drive failure and restore from a > backup, we have an unbootable machine. Lilo uses only the master boot > record. A lilo-booted machine can be backed up and restored with our > existing backup software just fine. You may want to try extlinux, it works much like LILO in this respect. It lacks a convenient configuration system, but that of grub-legacy would be easy to adapt, and I actually plan to work on this. -- Regards, Feri. -- 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/87d3wl1wbv@tac.ki.iif.hu
Bug#582884: ITP: usb-creator -- Live USB creator
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-devel@lists.debian.org, usb-creator-hack...@lists.launchpad.net, ubuntu-instal...@lists.ubuntu.com Owner: Dmitrijs Ledkovs * Package name : usb-creator Version : 0.2.23 Upstream Author : Evan Dandrea * URL : http://launchpad.net/usb-creator * License : GPL-2, GPL-3 Programming Lang: Python Description : Live USB creator Utility for converting Live Linux CDs into bootable USB sticks for example Ubuntu and Kubuntu. This utility can partition USB stick to allow storing user files in persistence mode. -- 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/aanlktikfwteinx22glcre7v2u1nvug3dtgznud1be...@mail.gmail.com
Bug#582897: ITP: wiki2beamer -- Tool to create LaTeX beamer presentations in wiki syntax
Package: wnpp Severity: wishlist Owner: Jan Hauke Rahm -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: wiki2beamer Version : 0.8.1 Upstream Author : Michael Rentzsch (http://www.repc.de), Kai Dietrich (m...@cleeus.de) * URL : http://www-user.tu-chemnitz.de/~mren/wiki2beamer/doku.php * License : GPL-2 Programming Lang: Python Description : Tool to create LaTeX beamer presentations in wiki syntax wiki2beamer is a small tool to create LaTeX Beamer presentations from text files with a wiki-like syntax. Thus, it enables the user to create beamer presentations in a less time-consuming way. . Written in Python it's very small and portable. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iFYEAREKAAYFAkv6bowACgkQGOp6XeD8cQ1G0ADfeiQSClfuNiPhRdwQEs2swF73 7PlqiMboS+FqKADfS/aV35b8QtBBPAY/plIC+MpJt62BDrW4/Z/6/w== =uXE1 -END PGP SIGNATURE- -- 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/20100524121820.12741.41488.report...@ca.home.jhr-online.de
Re: Parallel booting enabled by default
[Kurt Roeckx] > I don't see why you think that would be a problem. Either the > init script in runlevel 1 is going to stop the service, or it > gets killed. And going back to runlevel 2 should start the same > services as started otherwise in that runlevel. The reason is that I remember some bugs with packages related to runlevel 1, and I did not remember the details. :) Now I have had time to test a bit, and believe I remember the details. The problem is with packages starting in runlevels 1-5 and starting a daemon that is killed by killprocs. Such setup is broken, as the daemon will not be started again when switching away from runlevel 1 to runlevels 2-5. I tested switching from runlevel 2 to 1 using debug=echo PREVLEVEL=2 /etc/init.d/rc 1 | grep -v splash I also tested with scripts missing in runlevel 1, and they are started when switching from runlevel 1 to runlevel 2. This is most interesting for scripts that need to run once at boot. For scripts that do nnot need to run when booting into single user mode (and thus should not start in rcS.d/), this setting would be most correct: # Default-Start: 2 3 4 5 # Default-Stop: Runlevel 1 should be equivalent to single user, so there is no need to start in runlevel 1, and there is no need to stop either For scripts that start a daemon and need to do some cleanup when stopping it, this setting would be most correct # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 Not sure if I managed to write this in a clear matter. I find it a bit hard at the moment to wrap my head around all the possibilities. There are at least the following set of transitions to consider: rcS.d -> single user mode -> rc[2-5].d rcS.d -> rc1.d -> single user mode -> rc[2-5].d rcS.d -> rc1.d -> single user mode -> rc[06].d rc[2-5].d -> rc1.d -> single user mode -> rc[2-5].d rc[2-5].d -> rc1.d -> single user mode -> rc[06].d Note that single user mode is not the same as runlevel 1. Runlevel 1 is just one of two ways to end up in single user mode. The other way is booting with 's' or 'single' as a kernel argument. Also note that rcS.d/ is not the single user runlevel (it is not used when switching to single user after boot), and is more accurately called rc.boot in other distributions. Happy hacking, -- Petter Reinholdtsen -- 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/2fl1vd1zca9@login1.uio.no
when to split a package into architecture: all and architecture: any halves
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I have a package of bup - a git-based backup tool - sitting in the NEW queue. bup is 99% python, with a small .so module for some speed-critical code. I decided to have an architecture: all bup-common package for the majority of the program, and a small architecture: any package for the .so module, which depends on the -common package. I did this mostly to see how hard it was, and to see whether it would save mirror space. On my system, the -common package ends up being 76K and the architecture dependent package 12K. By my calculation: 12K * 12 release architectures + 76K = 225K total As appose to, (76K + 12K) * 12 release architectures = 1M total So the savings are quite significant, in terms of the total package size (which is relatively small). Is this worth the added complexity of two binary packages? Are there other advantages/disadvantages to consider? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkv6etMACgkQFotOcXAy8jjFBQCfUGN+tDNgqIMr+ycfbaegBlMT ejYAoIsARMvB4NqwN115pi3MKyc4LWef =RZ5F -END PGP SIGNATURE- -- 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/4bfa7ad7.9000...@debian.org
Re: Too much disruptive NMUs
Hi, On Sun, May 23, 2010 at 07:33:48PM +0200, Lucas Nussbaum wrote: > On 24/05/10 at 01:15 +0900, Osamu Aoki wrote: > > Really, issue is "Debian does not have reasonable rule for hijacking or > > automatic orphaning". > > I fully agree. There are many packages that are staying with totally > outdated upstream versions simply because the maintainer went inactive, > and MIA was not able to orphan his packages (because the maintainer, > despite being inactive, might still reply "I will come back in a month > and fix everything"). > > > If some maintainer is totally quiet on BTS report for over 2 months, > > he should loose maintainer-ship. The same goes if the maintainer has > > not uploaded new upload after reminded by bug report for 2 months > > without reply, he should loose maintainer-ship. If he had "I am > > maintaining this" without clear technical reason not-to-package new > > version, this should apply too. (If he has real reason, of course he > > should keep it.) > > ... but I disagree with having a strict rule that allows everybody to > hijack a package. I think that it should be the responsibility of the > hijacker to prove that he made enough efforts to contact the maintainer, > and that he is qualified to maintain the package. I share your concern too. > For example, the candidate hijacker could send an "intend to hijack foo" > email to debian-devel@, with the reasons why he thinks the package > should be hijacked (date of last maintainer upload, list of open bugs > without any response from the maintainer, new upstream versions which > were not packaged, MIA status, etc). > That email would send receive public review, and if nobody objects after > some time, the hijacker could proceed. This is good procedure. What I wanted is additional general guide line for such an action. Without it, I bet thee will be some personal encounters. (More detailed guide line may be needed.) Osamu -- 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/20100524135434.gc4...@osamu.debian.net
Re: lilo removal in squeeze (or, "please test grub2")
On Mon, 24 May 2010 05:36:32 -0400 (EDT), Ferenc Wagner wrote: > Kurt Roeckx wrote: >> On Sun, May 23, 2010 at 01:11:48PM +0200, Cyril Brulebois wrote: >>> William Pitcock (22/05/2010): This means that users should *test grub2 extensively* before Squeeze is released so that any issues can be resolved now. >>> >>> There should also be some folks fixing the discovered issues. >> >> grub2 currently seems to be having 18 RC bugs, plus a whole bunch >> of merged bugs, while lilo only has 1 RC bug. > > I chatted about this with the grub upstream a couple of days ago. > According to Vladimir, most of those bugs are already fixed, but there's > nobody around to do a new upload. Both grub maintainers (Felix Zielke > and Robert Millan) unexpectedly disappeared some time ago. What about Jordi Mallach and Colin Watson? The package page for grub-pc http://packages.debian.org/squeeze/grub-pc lists them as maintainers too. Have they disappeared as well? Or are they no longer maintainers for this package? In which case their names should be removed from the web page. Somehow I feel a dip in motivation. -- .''`. Stephen Powell : :' : `. `'` `- -- 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/1054400013.5379.1274709588267.javamail.r...@md01.wow.synacor.com
Re: lilo removal in squeeze (or, "please test grub2")
On moandei 24 Maaie 2010, Christian PERRIER wrote: > yes, keeping lilo in the > archive is a burden for some other people (security team, I would like to correct the suggestion that the security team would oppose keeping lilo in squeeze. There is currently no such objection, and in the past the security team has only voiced objections or asked for removal of packages with a security risk that is deemed significantly larger than average, for example based on past experience. That is not the case for lilo. The security team should not be used as an argument pro/contra lilo. Cheers, Thijs signature.asc Description: This is a digitally signed message part.
Re: lilo removal in squeeze (or, "please test grub2")
On Mon, 24 May 2010 05:29:56 -0400 (EDT), Ferenc Wagner wrote: > Stephen Powell writes: >> >> Both grub-legacy and grub-pc use sectors on the hard disk outside of >> the master boot record [...] This breaks the design of the backup >> software that my employer uses. This backup software backs up the >> master boot record and all partitions; but since the extra sectors >> used by grub-legacy and grub-pc are outside the master boot record and >> are not part of any partition, they don't get backed up. >> Consequently, if we have a hard drive failure and restore from a >> backup, we have an unbootable machine. Lilo uses only the master boot >> record. A lilo-booted machine can be backed up and restored with our >> existing backup software just fine. > > You may want to try extlinux, it works much like LILO in this respect. > It lacks a convenient configuration system, but that of grub-legacy > would be easy to adapt, and I actually plan to work on this. Thanks for the tip. That may be an option. I looked at the documentation online, and there does not appear to be an option equivalent to lilo's vga option, though, which I use a lot, especially since svgatextmode has already been pulled from squeeze. As of right now, if lilo was pulled from the distribution, I think I'd be inclined to build my own lilo package from source before switching to any other bootloader. To the best of my knowledge, it is the *only* bootloader which supports setting an initial text video mode *and* does not use any sectors outside the master boot record and outside of a partition. If I'm wrong about that, someone please correct me. As for a "convenient configuration system", editing a plain text file is plenty good enough for me. Your time is yours to use as you see fit; but if you have the requisite skills to become the equivalent of lilo upstream, I think there's a lot of people who would rather that you do that, myself included. I'd do it myself if I had the necessary skills and knowledge. But I don't. Thanks again for the tip. -- .''`. Stephen Powell : :' : `. `'` `- -- 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/1012155825.7010.1274712448896.javamail.r...@md01.wow.synacor.com
Re: lilo removal in squeeze (or, "please test grub2")
[Please Cc: replies, I'm not subscribed to debian-devel ] Stephen Powell wrote: > What about Jordi Mallach and Colin Watson? The package page for grub-pc > lists them as maintainers too. Have they disappeared as well? Or are > they no longer maintainers for this package? In which case their names > should be removed from the web page. The main reason for being listed as an Uploader for GRUB was helping out with PowerPC support; a task which isn't critical for squeeze nor I can really keep doing as my G4 box is dead. Colin added himself to the Uploaders field when I requested him to do so, as he's been in charge of Ubuntu's switch to GRUB2 for Ubuntu and after the "disappearance" of Felix and Robert, he's the Debian person with more experience to do uploads of the package. He did know he wouldn't be able to track upstream as Felix and Robert were (ie, uploading several snapshots every two weeks or so). I can try to work with Vladimir and Colin to get things shaped out a little, but honestly I don't think I'd be in a position to do this before the 22th of June, when exams finish. Jordi -- Jordi Mallach Pérez -- Debian developer http://www.debian.org/ jo...@sindominio.net jo...@debian.org http://www.sindominio.net/ GnuPG public key information available at http://oskuro.net/ signature.asc Description: Digital signature
RFA: several packages
Hi, for the reasons I've outlined on -private, I'd like to give away my packages: apache2-redirtoservname This package comes with upstream duties as well, since I wrote it. It is unlikely that for the actual functionality bits you'll ever need to do more than trigger a rebuild, but the package is severely lacking documentation. It is in use by a few sites, so I wouldn't like to see it gone. asio This is a header-only C++ library which has also been accepted into Boost some time ago, but remained around as a standalone version as some programs still use the "old" names outside the Boost namespace. It may be worth investigating (together with upstream) whether this package can be replaced by something that pulls in Boost.Asio. Other than that, the package is fairly low-maintenance, but you will require strong C++ skills. asterisk-prompt-it asterisk-prompt-se I've packaged these ages ago, and they are horribly outdated. The packages aren't overly complicated, as they just contain a tree of data files (so they are ideal for a beginner), but since they are artistic works, adressing bugs is bound to be difficult as you are essentially dependent on upstream. ctapi This is a tricky one, and you need experience with smartcards. The package exists only because that API is so old and "simple" that everyone has their own implementation now, which leads to file conflicts. This package is supposed to be the common definition, which means that as maintainer, you'll need to coordinate with the maintainers of other packages that have conflicting definitions. iptables-persistent Again, a very small package that does just one thing, load firewall rules at startup. Since some systems rely on this package for security, you should know what you are doing, and there are a few open wishlist bugs that need to be addressed. libopenusb This is a fairly straightforward library+plugin package with a difficult upstream bug and a mostly inactive corporate upstream. Also, porting is required for FreeBSD support, so it might be a good idea for someone using FreeBSD to pick this up. misdn-kernel misdn-user Both of these are fairly outdated, as the software wasn't ready for real world use outside of tightly controlled environments (i.e. embedded systems) back then, and getting it to work without it falling over on every upgrade is going to be hard. Upstream is fairly responsive, but the package still hasn't stabilized to the point where I'd give it to end users. Most of the kernel drivers are in the mainline kernel now, although the version in upstream's git repository are often newer and have a different ABI -- so expect stuff to break fairly often. python-imaging-doc-handbook It would be nice to have a newer version of this package, but AFAIK the newer versions of the handbook have a different licence that makes this difficult. The package is less of a technical than a legal challenge. redshift An interesting gadget, fairly new, but stable. Some python knowledge would be beneficial for the Gtk bits, otherwise, only basic packaging knowledge required and ideal for a beginner. towitoko This is related to chipcards again, and is one of the candidates to use the common "ctapi-dev" package; this should happen in your first upload as the versioned Replaces: in ctapi-dev will only work against the current version of the package. Also, there are some l10n patches outstanding, which are blocked by the ctapi "transition". uclibc This is a very tricky one, and is probably best with the emdebian project. On the regular Debian architectures, only a single arch:all binary package containing a copy of the source package is built, but on several "uclibc-linux-" architectures, we build (or at least try to) several library packages. As these architectures aren't fully bootstrapped yet, the package will need to crosscompile cleanly, and lots of people will have different use cases requiring different configurations, which should then be distinguished via the "DEB_VENDOR" variable. I'm still going to be available to answer questions about any of those packages as I know them fairly well, but I'd like to drop the responsibility for maintaining them soon. Proper RFA/O bugs will be forthcoming for all packages not taken over in a week. Simon signature.asc Description: Digital signature
Re: lilo removal in squeeze (or, "please test grub2")
On Mon, May 24, 2010 at 06:13:13PM +0200, Jordi Mallach wrote:
> Colin added himself to the Uploaders field when I requested him to do so,
> as he's been in charge of Ubuntu's switch to GRUB2 for Ubuntu and after
> the "disappearance" of Felix and Robert, he's the Debian person with more
> experience to do uploads of the package. He did know he wouldn't be able
> to track upstream as Felix and Robert were (ie, uploading several
> snapshots every two weeks or so).
>
> I can try to work with Vladimir and Colin to get things shaped out a
> little, but honestly I don't think I'd be in a position to do this before
> the 22th of June, when exams finish.
In the meantime, it would be terribly useful if some of you can inform
us of whether you think things can get in shape for Squeeze or not,
considering the currently available manpower. If not, we probably ought
to be more "communicative" on the fact we really need help on grub2
(e.g. Colin can blog about that *g*).
Many thanks for your feedback!
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: lilo removal in squeeze (or, "please test grub2")
On Mon, 24 May 2010, Stephen Powell wrote: To the best of my knowledge, it is the *only* bootloader which supports setting an initial text video mode *and* does not use any sectors outside the master boot record and outside of a partition. If I'm wrong about that, someone please correct me. grub2 supports loading its core.img from a dedicated partition instead of embedding it in the first "cylinder". This does require switching to the GPT partitioning scheme which may or may not be acceptable to you. -- Edward Allcutt -- 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/alpine.deb.2.00.1005241244200.1...@emallcut-x.pc.teamgleim.com
Re: lilo removal in squeeze (or, "please test grub2")
Stephen Powell writes: > On Mon, 24 May 2010 05:36:32 -0400 (EDT), Ferenc Wagner wrote: >> Kurt Roeckx wrote: >>> On Sun, May 23, 2010 at 01:11:48PM +0200, Cyril Brulebois wrote: William Pitcock (22/05/2010): > This means that users should *test grub2 extensively* before Squeeze > is released so that any issues can be resolved now. There should also be some folks fixing the discovered issues. >>> >>> grub2 currently seems to be having 18 RC bugs, plus a whole bunch >>> of merged bugs, while lilo only has 1 RC bug. >> >> I chatted about this with the grub upstream a couple of days ago. >> According to Vladimir, most of those bugs are already fixed, but there's >> nobody around to do a new upload. Both grub maintainers (Felix Zielke >> and Robert Millan) unexpectedly disappeared some time ago. > > What about Jordi Mallach and Colin Watson? I really don't know, I just echoed what I heard on the #grub IRC channel. I saw articles from Colin Watson recently, so he's around, but I don't know how he feels about Grub maintenance. -- Regards, Feri. -- 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/87y6f9z0il@tac.ki.iif.hu
Re: lilo removal in squeeze (or, "please test grub2")
Stephen Powell writes: > On Mon, 24 May 2010 05:29:56 -0400 (EDT), Ferenc Wagner wrote: > >> Stephen Powell writes: >>> >>> Both grub-legacy and grub-pc use sectors on the hard disk outside of >>> the master boot record [...] >> >> You may want to try extlinux, it works much like LILO in this respect. > > Thanks for the tip. That may be an option. I looked at the documentation > online, and there does not appear to be an option equivalent to lilo's > vga option, though, which I use a lot, especially since svgatextmode > has already been pulled from squeeze. I'm not sure what you're after, I haven't used LILO for ages. But typing vmlinuz-2.6.32 vga=0xf07 at the pxelinux boot prompt gives me a 80x60 console. The other variants use the same code. >> It lacks a convenient configuration system, but that of grub-legacy >> would be easy to adapt, and I actually plan to work on this. > > if you have the requisite skills to become the equivalent of lilo > upstream, I think there's a lot of people who would rather that you do > that, myself included. Sorry, I don't trust in the future of LILO myself. If there's anything which only LILO can do, I recommend you start complaining on the Syslinux and the Grub mailing lists. I suppose it will be heard. -- Regards, Feri. -- 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/87typxyzbk@tac.ki.iif.hu
Re: Parallel booting enabled by default
On Mon, May 24, 2010 at 02:58:54PM +0200, Petter Reinholdtsen wrote: > > [Kurt Roeckx] > > I don't see why you think that would be a problem. Either the > > init script in runlevel 1 is going to stop the service, or it > > gets killed. And going back to runlevel 2 should start the same > > services as started otherwise in that runlevel. > > The reason is that I remember some bugs with packages related to > runlevel 1, and I did not remember the details. :) > > Now I have had time to test a bit, and believe I remember the details. > The problem is with packages starting in runlevels 1-5 and starting a > daemon that is killed by killprocs. Such setup is broken, as the > daemon will not be started again when switching away from runlevel 1 > to runlevels 2-5. I think we're discussing 2 things here, while I was only thinking about one of them: - Move scripts from rcS.d to rc[1-5].d - Removing rc[016].d/K* scripts As far as I know, the only daemon we currently start in rcS.d (that keeps running) is udev. udev might be something we want to run in single user mode too, so it might make sense to also start it in runlevel 1. killprocs is probably going to kill it, so it would need to be restarted after that. I think it's going to be hard to move udev away from rcS.d, and I don't see the point. It could make sense to move things from rcS.d to rc[1-5].d, but for daemons it doesn't make sense to start in 1-5, it should probably always be 2-5. But my question was when it makes sense to stop a daemon in runlevel 1 via the init script when you don't do it for 0 and 6. killprocs is going to stop it for runlevel 1 anyway, just like sendsigs does it for runlevel 0 and 6. I still don't get why you think something might not be started when going from 1 to 2-5. > For scripts that do nnot need to run when booting into single user > mode (and thus should not start in rcS.d/), this setting would be most > correct: > > # Default-Start: 2 3 4 5 > # Default-Stop: > > Runlevel 1 should be equivalent to single user, so there is no need to > start in runlevel 1, and there is no need to stop either > > For scripts that start a daemon and need to do some cleanup when > stopping it, this setting would be most correct > > # Default-Start: 2 3 4 5 > # Default-Stop: 0 1 6 Which was kind of my point. This doesn't make sense (for a daemon): # Default-Start: 2 3 4 5 # Default-Stop: 1 So I'm trying to think of examples where a script that doesn't stop a daemon might be useful to run when going to runlevel 1, but not to 0 or 6. I guess you can probably come up with something. Kurt -- 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/20100524180105.ga7...@roeckx.be
Re: lilo removal in squeeze (or, "please test grub2")
On Mon, 24 May 2010 13:01:30 -0400 (EDT), Edward Allcutt wrote: > On Mon, 24 May 2010, Stephen Powell wrote: >> To the best of my knowledge, lilo is the *only* bootloader which supports >> setting an initial text video mode *and* does not use any sectors outside >> the master boot record and outside of a partition. If I'm wrong about >> that, someone please correct me. > > grub2 supports loading its core.img from a dedicated partition instead > of embedding it in the first "cylinder". This does require switching to > the GPT partitioning scheme which may or may not be acceptable to you. No, the backup software assumes the traditional MS-DOS hard disk partitioning scheme. One can get around this by requiring an image backup, but that has three substantial drawbacks: (1) The entire disk, including free space and extended partition free space, must be backed up. This takes a lot more time. (2) A restore can only be done to a disk of the exact same size as the one backed up. Often, a larger disk must be used because the model that failed is no longer available on the market. (3) The need for special backup requirements will be used by the opponents of Linux at my place of employment to oppose further deployments of Linux, which I wish to avoid at all costs. But thanks for the info anyway. -- .''`. Stephen Powell : :' : `. `'` `- -- 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/1081731293.13454.1274723918397.javamail.r...@md01.wow.synacor.com
Re: Parallel booting enabled by default
[Kurt Roeckx] > I think we're discussing 2 things here, while I was only thinking > about one of them: > - Move scripts from rcS.d to rc[1-5].d > - Removing rc[016].d/K* scripts Could be. > As far as I know, the only daemon we currently start in rcS.d > (that keeps running) is udev. There are more of them. I'm aware of portmap and some NFS related daemons. I believe most of of them should be moved from rcS.d/ to rc[2-5].d/, along with networking and several others. :) > udev might be something we want to run in single user mode too, so > it might make sense to also start it in runlevel 1. I do not believe it is needed to add start symlinks in rc1.d/ for udev as long as it isn't killed by killprocs. Not sure what the current status is there. Both runlevel 1 and single user mode in Debian is so broken it is hard to know where to start to make them work properly. At the moment the only safe and sane thing to do after working in single user mode is to reboot to recover. :( > killprocs is probably going to kill it, so it would need to be > restarted after that. If killprocs kills it in rc1.d/, udev can not have a start symlink in rc1.d/, as this will cause init.d/rc to not start udev when switching from runlevel 1 to runlevel 2. > I think it's going to be hard to move udev away from rcS.d, and I > don't see the point. I agree. > It could make sense to move things from rcS.d to rc[1-5].d, but for > daemons it doesn't make sense to start in 1-5, it should probably > always be 2-5. If you keep udev out of this, I agree. :) > But my question was when it makes sense to stop a daemon in runlevel > 1 via the init script when you don't do it for 0 and 6. killprocs > is going to stop it for runlevel 1 anyway, just like sendsigs does > it for runlevel 0 and 6. > > I still don't get why you think something might not be > started when going from 1 to 2-5. I tried to explain in my previous email, that there probably is no such case. Either the daemon need special code to stop, and it need to have stop symlinks in runlevels 0, 1 and 6, or it do not, and do not need stop symlinks in any of runlevels 0, 1 and 6. Now I believe the problem I remembered was with start symlinks in runlevel 1, which can be problematic as the daemon will be killed by killprocs and not start again when switching from runlevel 1 to runlevel 2. > This doesn't make sense (for a daemon): > # Default-Start: 2 3 4 5 > # Default-Stop: 1 > > So I'm trying to think of examples where a script that doesn't stop > a daemon might be useful to run when going to runlevel 1, but not to > 0 or 6. I guess you can probably come up with something. I suspect you are right, that such setup do not make sense. Happy hacking, -- Petter Reinholdtsen -- 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/2flaarpxi63@login1.uio.no
Re: lilo removal in squeeze (or, "please test grub2")
On 05/24/2010 11:29 AM, Ferenc Wagner wrote: > You may want to try extlinux, it works much like LILO in this respect. > It lacks a convenient configuration system, but that of grub-legacy > would be easy to adapt, and I actually plan to work on this. sometime ago i've added extliux-install and update-extlinux. if fits my setups well, however, any other/better ideas how to improve it are very welcome, see #573042 for more information. -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: daniel.baum...@panthera-systems.net Internet: http://people.panthera-systems.net/~daniel-baumann/ -- 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/4bfac975.1070...@debian.org
Re: lilo removal in squeeze (or, "please test grub2")
On Mon, 24 May 2010 13:38:55 -0400 (EDT), Ferenc Wagner wrote: > Stephen Powell writes: >> On Mon, 24 May 2010 05:29:56 -0400 (EDT), Ferenc Wagner wrote: >>> Stephen Powell writes: Both grub-legacy and grub-pc use sectors on the hard disk outside of the master boot record [...] >>> >>> You may want to try extlinux, it works much like LILO in this respect. >> >> Thanks for the tip. That may be an option. I looked at the documentation >> online, and there does not appear to be an option equivalent to lilo's >> vga option, though, which I use a lot, especially since svgatextmode >> has already been pulled from squeeze. > > I'm not sure what you're after, I haven't used LILO for ages. But > typing vmlinuz-2.6.32 vga=0xf07 at the pxelinux boot prompt gives me a > 80x60 console. The other variants use the same code. Interesting. At one point, the kernel itself had de-supported the vga boot option, relying on the boot loader to set the video mode before transferring control to the kernel. And now you're saying it's back. Hmm. According to Documentation/svga.txt in the kernel source tree: This small document describes the "Video Mode Selection" feature which allows the use of various special video modes supported by the video BIOS. Due to usage of the BIOS, the selection is limited to boot time (before the kernel decompression starts) and works only on 80X86 machines. Note the wording "before the kernel decompression starts". That to me implies "done by the bootloader", because the bootloader decompresses the kernel (if it is compressed) before transferring control to it, does it not? The vga option is a separate option in lilo. You can't include it in the append variable without lilo generating an error. You've got my curiosity up now. I'll have to try this. I do have a spare computer with which to test. I'm going to have to try installing Squeeze using extlinux as the boot loader. (No doubt I'll have to change bootloaders after installation, as the Debian Installer won't offer that option.) Then I'll see if I can pass it the vga option and have it work. And if that works, then I'll try the backup, nuke, and restore scenario. And if that works, then I may have a viable alternative to lilo. I'll let you know how it goes. -- .''`. Stephen Powell : :' : `. `'` `- -- 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/158609809.14709.1274725819037.javamail.r...@md01.wow.synacor.com
Re: lilo removal in squeeze (or, "please test grub2")
Stephen Powell writes: > On Mon, 24 May 2010 13:38:55 -0400 (EDT), Ferenc Wagner wrote: >> Stephen Powell writes: >>> On Mon, 24 May 2010 05:29:56 -0400 (EDT), Ferenc Wagner wrote: Stephen Powell writes: > Both grub-legacy and grub-pc use sectors on the hard disk outside of > the master boot record [...] You may want to try extlinux, it works much like LILO in this respect. >>> >>> Thanks for the tip. That may be an option. I looked at the documentation >>> online, and there does not appear to be an option equivalent to lilo's >>> vga option, though, which I use a lot, especially since svgatextmode >>> has already been pulled from squeeze. >> >> I'm not sure what you're after, I haven't used LILO for ages. But >> typing vmlinuz-2.6.32 vga=0xf07 at the pxelinux boot prompt gives me a >> 80x60 console. The other variants use the same code. > > Interesting. At one point, the kernel itself had de-supported the > vga boot option, relying on the boot loader to set the video mode > before transferring control to the kernel. And now you're saying > it's back. Hmm. According to Documentation/svga.txt in the kernel > source tree: > >This small document describes the "Video Mode Selection" feature which >allows the use of various special video modes supported by the video BIOS. >Due to usage of the BIOS, the selection is limited to boot time (before >the kernel decompression starts) and works only on 80X86 machines. > > Note the wording "before the kernel decompression starts". That to me > implies "done by the bootloader", because the bootloader decompresses > the kernel (if it is compressed) before transferring control to it, > does it not? It does not, the kernel is sort of a self-decompressing binary. However, the vga= parameter is indeed parsed by the bootloader and passed to the kernel by a special protocol. It's then used before the kernel parses its command line. > I'm going to have to try installing Squeeze using extlinux as the boot > loader. (No doubt I'll have to change bootloaders after installation, > as the Debian Installer won't offer that option.) Yes, you'll have to back out of Grub installation, start a shell, chroot into /target, and install exlinux. Take care to have /boot on an ext2 partition. -- Good luck! Feri. -- 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/87iq6dytpl@tac.ki.iif.hu
Re: Permission to NMU gcc-mingw32
[Ove Kaaven] > Anyway, for me, the easiest way to be able to build an updated Wine > package would be to NMU gcc-mingw32. Doing so seems to be just a > matter of putting in a new gcc tarball in the source package, and > I've confirmed that updating it to gcc 4.4.4 seems to work for what > Wine needs. *Nod.* > Is it okay if I go ahead and do such a NMU? I think so. Especially since you announced your intention a week ago in bug 573756. Sure, #573756 is 'wishlist', but given it apparently is blocking wine-unstable, I'm thinking it should be a 'normal' or even 'important' bug. Of course, I have no authority here, just an opinion. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- 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/20100524195739.ga18...@p12n.org
Re: lilo removal in squeeze (or, "please test grub2")
Le dimanche 23 mai 2010 à 20:48 -0400, Stephen Powell a écrit : > I do understand why a Debian package maintainer does not wish to become > "upstream". And I hope that someone who is both willing and able to do > so steps up to the plate. But withdrawing it from the distribution seems > like overkill to me, especially since you want to withdraw it from Squeeze > and not Squeeze+1. Lilo, as it exists today, works just fine for my > purposes. And apparently it works just fine for a lot of other people too. Debian stable releases are not here to serve as a repository for orphaned packages. We are supposed to keep them in shape for the lifetime of the release. > The Lord bless you, William. May His noodly appendage touch you. Ramen, -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
Re: lilo removal in squeeze (or, "please test grub2")
Le lundi 24 mai 2010 à 20:46 +0200, Daniel Baumann a écrit : > On 05/24/2010 11:29 AM, Ferenc Wagner wrote: > > You may want to try extlinux, it works much like LILO in this respect. > > It lacks a convenient configuration system, but that of grub-legacy > > would be easy to adapt, and I actually plan to work on this. > > sometime ago i've added extliux-install and update-extlinux. if fits my > setups well, however, any other/better ideas how to improve it are very > welcome, see #573042 for more information. Could this also be eventually added as an alternative to grub2 in the installer? -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
Re: Possible boot ordering issues with the packages in Sid
Le dimanche 23 mai 2010 à 15:55 -0400, Joey Hess a écrit : > Josselin Mouette >gdm (U) > warning: script gdm/init.d/gdm possibly missing dependency on $syslog >gdm3 (U) > warning: script gdm3/init.d/gdm3 possibly missing dependency on $syslog AFAICT gdm uses its own logging system. However, PAM will log authentication requests themselves through syslog, but I don’t think we should hold the loading of gdm for that. -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
Re: lilo removal in squeeze (or, "please test grub2")
Daniel Baumann writes: > On 05/24/2010 11:29 AM, Ferenc Wagner wrote: > >> You may want to try extlinux, it works much like LILO in this respect. >> It lacks a convenient configuration system, but that of grub-legacy >> would be easy to adapt, and I actually plan to work on this. > > sometime ago i've added extliux-install and update-extlinux. if fits my > setups well, however, any other/better ideas how to improve it are very > welcome, see #573042 for more information. Heh, yes, that's me again. :) I got distracted, but didn't give up work on this. Now I'm nosing around the current Grub2 method for ideas. Meanwhile, the unconditional destroying of extlinux.conf on update gave me the grief again. :-/ -- Cheers, Feri. -- 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/87d3wlyt1a@tac.ki.iif.hu
Re: lilo removal in squeeze (or, "please test grub2")
On 05/24/2010 10:07 PM, Josselin Mouette wrote: > Could this also be eventually added as an alternative to grub2 in the > installer? i've talked with otavio about this already a year ago, as i'm much in favour[0] of extlinux over grub2 anyway, but i didn't got arround to finally push it. if anyone has time before debconf/debcamp, that would be great. otherwise, i hope to have a look together with otavio at debconf/debcamp (if he accepts my bribes with chocolate :). [0] http://blog.daniel-baumann.ch/2009/11/30#20091130_extlinux-as-alternative-bootloader -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: daniel.baum...@panthera-systems.net Internet: http://people.panthera-systems.net/~daniel-baumann/ -- 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/4bfadee4.5080...@debian.org
Bug#582950: ITP: geronimo-osgi-support -- Java libraries providing OSGi lookup support for Geronimo projects
Package: wnpp Severity: wishlist Owner: Miguel Landaeta * Package name: geronimo-osgi-support Version : 1.0 Upstream Author : Apache Software Foundation (ASF) * URL : http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-osgi-support-1.0/ * License : Apache-2.0 Programming Lang: Java Description : Java libraries providing OSGi lookup support for Geronimo projects These Java libraries allow the use of OSGi framework with Geronimo existing projects. They allow lookup and registration of components. . - geronimo-osgi-locator.jar: Allow performing class and components lookups with OSGi support. . - geronimo-osgi-registry.jar: Facilitate the use of Geronimo specs providers (components typically plugged in to the JRE through META-INF/services resources) like geronimo-validation-1.0-spec (Geronimo JSR-303 Bean Validation Spec API). . The service created by this library will maintain a registry of factory class that can be used by the spec bundles to locate factory classes that reside in other bundles. This package is needed to package geronimo-validation-1.0-spec, which in turn, it is needed to package OpenJPA library and Spring Framework 3.0. -- Miguel Landaeta, miguel at miguel.cc secure email with PGP 0x7D8967E9 available at http://keyserver.pgp.com/ "Faith means not wanting to know what is true." -- Nietzsche -- 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/20100524195502.ga25...@miguel.cc
Bug#582959: ITP: gentle -- suite to plan genetic cloning
Package: wnpp Severity: wishlist Owner: Steffen Moeller * Package name: gentle * URL : http://gentle.magnusmanske.de * License : GPL Description : suite to plan genetic cloning GENtle is a software for DNA and amino acid editing, database management, plasmid maps, restriction and ligation, alignments, sequencer data import, calculators, gel image display, PCR, and much more. -- 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/20100524215650.31190.36491.report...@toshiba.siemens
Re: lilo removal in squeeze (or, "please test grub2")
I demand that Ferenc Wagner may or may not have written... [snip] > You may want to try extlinux, it works much like LILO in this respect. It > lacks a convenient configuration system, but that of grub-legacy would be > easy to adapt, and I actually plan to work on this. Given an upload of a 4.00 RC to unstable or experimental (for the ext4 support), I'd have a look... -- | Darren Salt| linux at youmustbejoking | nr. Ashington, | Toon | using Debian GNU/Linux | or ds,demon,co,uk| Northumberland | back! | + At least 4000 million too many people. POPULATION LEVEL IS UNSUSTAINABLE. I'd like to, but my bathroom tiles need grouting. -- 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/51220d2c30%li...@youmustbejoking.demon.co.uk
Re: when to split a package into architecture: all and architecture: any halves
On Mon, May 24, 2010 at 9:10 PM, Jon Dowland wrote: > I have a package of bup - a git-based backup tool - sitting in the NEW > queue. bup is 99% python, with a small .so module for some > speed-critical code. > > I decided to have an architecture: all bup-common package for the > majority of the program, and a small architecture: any package for the > .so module, which depends on the -common package. I did this mostly to > see how hard it was, and to see whether it would save mirror space. I would do the packages the other way around; bup with python stuff and bup-something for the .so. I did that for fonttools and I think it makes more sense. > Is this worth the added complexity of two binary packages? Are there > other advantages/disadvantages to consider? >From the ftp-master REJECT FAQ[1]: Package split You split a package too much or in a broken way. Well, broken or too much is a wide definition, so this is a case-by-case thing, but you should really think about a split before you do it. For example it doesn't make any sense to split a 50k arch:all package from a 250k arch:any one. Or splitting a package for only one file, depending on the main package. Yes, big dependency chains can be a reason. Or big documentation splitted into one -doc package. The point there is big. Personally I base my splitting on lintian's warning. http://ftp-master.debian.org/REJECT-FAQ.html -- 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/aanlktilowclrualloeo7chzknslfyo7fmutbwxlmg...@mail.gmail.com
mini-dinstall possibly leading to lots of 'Failed to fetch http://xyx/abd_1.2-3.deb Size mismatch'
We are running a service that automatically converts the 2300+ R packages from CRAN (http://cran.r-project.org) into Debian binaries for both amd64 and i386 on testing. This is joint work with Charles Blundell (CC'ed), which we started when it was his GSoC 2008 gig. We use a Xen instance which is running testing that is being made available to us at WU Vienna. Every now and then mini-dinstall throws us a curve ball. Right now I am seeing the errors below on my testing box (which is otherwise current). What can we do to fix the index file? I have removed Packages*, Release*, Sources*, the Berkeley db file testing.db and others but I can't seem to find a reliable fix. I also run apt-cacher-ng locally but that does not seem to be the issue as we also get mismatches on the build machine itself which is not running any caches. Any hints? We looked into replacing mini-dinstall with reprepro. Is that the best solution? Are there better reference docs that the one or two hits Google finds? I can supply more details if that helped. Many thanks, Dirk e...@ron:~> wajig dist-upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages will be upgraded: r-cran-accuracy r-cran-actuar r-cran-ape r-cran-bit r-cran-chron r-cran-coin r-cran-digest r-cran-doby r-cran-e1071 r-cran-ff r-cran-filehash r-cran-fints r-cran-gbm r-cran-gdata r-cran-geometry r-cran-ggplot2 r-cran-gsl r-cran-gsubfn r-cran-gwidgetsrgtk2 r-cran-igraph r-cran-kernlab r-cran-latticeextra r-cran-lme4 r-cran-maptree r-cran-mgcv r-cran-msm r-cran-mvtnorm r-cran-pcapp r-cran-pmml r-cran-portfolio r-cran-portfoliosim r-cran-quantreg r-cran-r.oo r-cran-rbgl r-cran-rcpp r-cran-rcurl r-cran-rgl r-cran-robustbase r-cran-rsqlite r-cran-runjags r-cran-sandwich r-cran-sparsem r-cran-spatial r-cran-suppdists r-cran-svmisc r-cran-timedate r-cran-timeseries r-cran-tseries r-cran-xts 49 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 45.2MB of archives. After this operation, 1,733kB disk space will be freed. Do you want to continue [Y/n]? y WARNING: The following packages cannot be authenticated! r-cran-accuracy r-cran-actuar r-cran-ape r-cran-bit r-cran-chron r-cran-mvtnorm r-cran-coin r-cran-digest r-cran-doby r-cran-e1071 r-cran-ff r-cran-filehash r-cran-fints r-cran-gbm r-cran-gdata r-cran-geometry r-cran-ggplot2 r-cran-gsl r-cran-gsubfn r-cran-gwidgetsrgtk2 r-cran-igraph r-cran-kernlab r-cran-latticeextra r-cran-lme4 r-cran-maptree r-cran-mgcv r-cran-msm r-cran-pcapp r-cran-pmml r-cran-portfolio r-cran-portfoliosim r-cran-sparsem r-cran-quantreg r-cran-r.oo r-cran-rbgl r-cran-rcpp r-cran-rcurl r-cran-rgl r-cran-robustbase r-cran-rsqlite r-cran-runjags r-cran-sandwich r-cran-spatial r-cran-suppdists r-cran-svmisc r-cran-timedate r-cran-timeseries r-cran-tseries r-cran-xts Install these packages without verification [y/N]? y Get:1 http://debian.cran.r-project.org testing/ r-cran-accuracy 1.35-1cran1 [1,746kB] Get:2 http://debian.cran.r-project.org testing/ r-cran-actuar 1.1-0-1cran1 [1,108kB] Get:3 http://debian.cran.r-project.org testing/ r-cran-ape 2.5-2-1cran1 [943kB] Get:4 http://debian.cran.r-project.org testing/ r-cran-bit 1.1-4-1cran1 [131kB] Get:5 http://debian.cran.r-project.org testing/ r-cran-chron 2.3-35-1cran1 [98.0kB] Get:6 http://debian.cran.r-project.org testing/ r-cran-mvtnorm 0.9-9-1cran1 [209kB] Get:7 http://debian.cran.r-project.org testing/ r-cran-coin 1.0-11-1cran1 [3,326kB] Get:8 http://debian.cran.r-project.org testing/ r-cran-digest 0.4.2-1cran1 [40.4kB] Get:9 http://debian.cran.r-project.org testing/ r-cran-doby 4.0.6-1cran1 [251kB] Get:10 http://debian.cran.r-project.org testing/ r-cran-e1071 1.5-24-1cran1 [450kB] Get:11 http://debian.cran.r-project.org testing/ r-cran-ff 2.1-2-1cran1 [606kB] Get:12 http://debian.cran.r-project.org testing/ r-cran-filehash 2.1-1cran1 [232kB] Get:13 http://debian.cran.r-project.org testing/ r-cran-fints 0.4-4-1cran1 [5,610kB] Get:14 http://debian.cran.r-project.org testing/ r-cran-gbm 1.6-3.1-1cran1 [333kB] Get:15 http://debian.cran.r-project.org testing/ r-cran-gdata 2.8.0-1cran1 [759kB] Get:16 http://debian.cran.r-project.org testing/ r-cran-geometry 0.1-7-1cran1 [436kB] Get:17 http://debian.cran.r-project.org testing/ r-cran-ggplot2 0.8.7-1cran1 [2,444kB] Get:18 http://debian.cran.r-project.org testing/ r-cran-gsl 1.9-3-1cran1 [371kB] Get:19 http://debian.cran.r-project.org testing/ r-cran-gsubfn 0.5-2-1cran1 [353kB] Get:20 http://debian.cran.r-project.org testing/ r-cran-gwidgetsrgtk2 0.0-65-1cran1 [621kB] Get:21 http://debian.cran.r-project.org testing/ r-cran-igraph 0.5.3-1cran1 [1,596kB] Get:22 http://debian.cran.r-project.org testing/ r-cran-kernlab 0.9-10-1cran1 [1,788kB] Get:23 http://debian.cran.r-project.org testing/ r-cran-latticeextra 0.6-11-1cran1 [2,032kB] Get:24 http://debian.cran.r-project.org testing/ r-
Re: mini-dinstall possibly leading to lots of 'Failed to fetch http://xyx/abd_1.2-3.deb Size mismatch'
Dirk Eddelbuettel writes: > We are running a service that automatically converts the 2300+ R packages > from CRAN (http://cran.r-project.org) into Debian binaries for both amd64 and > i386 on testing. This is joint work with Charles Blundell (CC'ed), which we > started when it was his GSoC 2008 gig. We use a Xen instance which is running > testing that is being made available to us at WU Vienna. > > Every now and then mini-dinstall throws us a curve ball. Right now I am > seeing the errors below on my testing box (which is otherwise current). > > What can we do to fix the index file? I have removed Packages*, Release*, > Sources*, the Berkeley db file testing.db and others but I can't seem to find > a reliable fix. I also run apt-cacher-ng locally but that does not seem to be > the issue as we also get mismatches on the build machine itself which is not > running any caches. > > Any hints? We looked into replacing mini-dinstall with reprepro. Is that the > best solution? Are there better reference docs that the one or two hits > Google finds? > > I can supply more details if that helped. > > Many thanks, Dirk Maybe just avoid the problem by using reprepro. 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/87wrus37c2@frosties.localdomain
