Bug#639868: ITP: chado -- Chado is a relational database schema that underlies many GMOD installations.
Package: wnpp Severity: wishlist Owner: Olivier Sallou * Package name: chado Version : 1.11 Upstream Author : GMOD * URL : http://gmod.org/wiki/Chado_-_Getting_Started * License : Artistic License 2.0 Programming Lang: Perl,SQL Description : Chado is a relational database schema that underlies many GMOD installations. It is capable of representing many of the general classes of data frequently encountered in modern biology such as sequence, sequence comparisons, phenotypes, genotypes, ontologies, publications, and phylogeny. It has been designed to handle complex representations of biological knowledge and should be considered one of the most sophisticated relational schemas currently available in molecular biology. -- 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/20110831070947.9443.37605.report...@debiansid.genouest.org
Re: Maintainers, porters, and burden of porting
On 08/31/2011 07:34 AM, Lucas Nussbaum wrote: > I've always wondered what was the point of having some architectures > part of stable releases as official architectures. Sure, they are very > useful as experimental architectures, and very fun to work on, but it's > unlikely that people will use them on production machines because the > hardware is too old & slow, or some key piece of software is too > unstable. That is not necessarily true, there are a lot of people who need to work with old, probably sponsored hardware. Also there are a lot of embedded systems which run Debian or derivates of Debian. So looking at the list of architectures, the only one I could imagine to get rid of at some point would be sparc, maybe powerpc and ia64. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- 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/4e5df2cb.6070...@bzed.de
Where can I found resource to make very simple Debian package like doc-linux-html… ?
Hi, I would like to make very simple Debian package to install very simple file on my system, only static file, like documentation. I've look "doc-linux-html" package to understand how it's builded. Where can I found some resources (url) to make this kind of package ? I've found only resource about build package with compiled project… I've already make a package for autotools… project. Thanks for your help, Stephane -- Stéphane Klein blog: http://stephane-klein.info Twitter: http://twitter.com/klein_stephane pro: http://www.is-webdesign.com -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/j3kpbl$dgc$1...@dough.gmane.org
Re: Maintainers, porters, and burden of porting
On 31/08/11 at 10:37 +0200, Bernd Zeimetz wrote: > On 08/31/2011 07:34 AM, Lucas Nussbaum wrote: > > I've always wondered what was the point of having some architectures > > part of stable releases as official architectures. Sure, they are very > > useful as experimental architectures, and very fun to work on, but it's > > unlikely that people will use them on production machines because the > > hardware is too old & slow, or some key piece of software is too > > unstable. > > That is not necessarily true, there are a lot of people who need to work > with old, probably sponsored hardware. Also there are a lot of embedded > systems which run Debian or derivates of Debian. So looking at the list > of architectures, the only one I could imagine to get rid of at some > point would be sparc, maybe powerpc and ia64. Note that I'm not saying that we should get rid of them. Only that we should move them out of the "critical path". If there are active buildd admins, I don't see why they couldn't continue to use Debian infrastructure. Also, in the case of architectures targetted at embedded systems (I'm thinking about mips and mipsel), what is important is that Debian infrastructure supports the development of those architectures, but I don't think that there's much to gain by being officially supported if it's only used in production through derivatives that can provide the official support. hurd-i386, kfreebsd-i386 and kfreebsd-amd64 are probably too experimental to be used on production systems. For kfreebsd, my main problem (with my Ruby hat) is the linuxthreads-based thread library, but there might be other problems. Lucas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110831085626.ga28...@xanadu.blop.info
Re: Where can I found resource to make very simple Debian package like doc-linux-html… ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Stéphane, On 31.08.2011 09:54, Stéphane Klein wrote: > Where can I found some resources (url) to make this kind of package ? > I've found only resource about build package with compiled project… I've > already make a package for autotools… project. Its not implied to compile something in a Makefile. Its equally fine just to install your documentation through a Makefile, after generating it eventually in the build target. Generally you should read the New Maintainer's Guide [1]. Alternatively you can use debhelper(7) to install your documentation, e.g. through dh_installdocs(1). Also, reading dh(1) is helpful for the debian/rules short form. If you care about policy compliant packages (read: those who are supposed to enter Debian, and not targeted for your private use) you may want to read the policy [2] sooner or later. For very quick and dirty ad-hoc packaging, have a look to Lucas' packaging tutorial [3][4]. Finally please note, that you should direct such questions to the debian-mentors mailing list. Thanks. :) [1] http://www.debian.org/doc/manuals/maint-guide/ [2] http://www.debian.org/doc/debian-policy/ [3] http://git.debian.org/?p=collab-maint/packaging-tutorial.git;a=blob_plain;f=packaging-tutorial.pdf;hb=refs/heads/pdf [4] http://git.debian.org/?p=collab-maint/packaging-tutorial.git;a=summary - -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOXfmhAAoJEMcrUe6dgPNtl4sP/R9vDqOfk51pdE0RxKZYVUz3 hyQLcH+L86d3TnYE/qHYOT5Y5ZCnxFBnVJNiP8YdkANITU6Y+v0vG7beE/QQ50ee fxE6mOQX2Tow16JMN06Hj0rDfitMz9NvAqLr6mCB4bw1rOlp4JLSHQhRnSY9O1Qw N/mTywkDN1VQIdtL6SkBr6mAFrdFyst3g7ocOT5aYER21MOya272mxD9PmAygPpP S4Cqwqc/WEtvQNtdjbk6Fl/mX5wqa/NXa9BbG/urUwKN08glNtIbwbpWXE6fnLXu CzNhUbqApZMY+D8wqcdOa17TEdXFsS01FZvO9wIjkBtVRlwlURCvANX1X4N0DsHI ii8/rCi8V8sQ6+HHqcff0Oqc4aLSrjE984+rO64JWsFdK5neHnR5iLvdwyEQ4pL7 nKFKax6O32uyBtTAHLHSFepW1iQMNzhBDwFpGjOJq9NCvxEC8krDfiny7D3eoipU UKXS0LF5TG8Xh3WkzIRzFNX7VN538F4sAFvSS6Qtt1mrQw3Q90JStjf613JHJGlt yXBS1HZAXnFK73UUFqsZU0lex3OZfJGDbnBybxeQw7JAtPIJ115aBHy2EeZzn11E lshFni6sjuWpZzDWtJaPZcSYDSsimVrYLwPzTJuMoCydiA9mOmSoWPr9w6eyupFW iGPbjAAwK8Fubdaxpj4f =38TG -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/4e5df9a1.7090...@toell.net
Re: Where can I found resource to make very simple Debian package like doc-linux-html… ?
On Wed, Aug 31, 2011 at 09:54:28AM +0200, Stéphane Klein wrote: > Hi, > > I would like to make very simple Debian package to install very > simple file on my system, only static file, like documentation. The only difference between a project with static files and a project with software is usually in the existence of some build scripts (Makefile, autotools etc.) in the second case. If the project with static files only contains a proper Makefile too, there is no difference at all. If you need to build a package that doesn't provide any means to install its files, you need to install them manually. Usually it is done with dh_install(1) (in simple cases) or by writing custom code in the install target (or in override_dh_auto_install in tiny rules). > I've look "doc-linux-html" package to understand how it's builded. This package looks quite sophisticated, I don't recommend using it as a reference. -- WBR, wRAR signature.asc Description: Digital signature
Re: Maintainers, porters, and burden of porting
* Lucas Nussbaum [110831 10:56]: > Note that I'm not saying that we should get rid of them. Only that we > should move them out of the "critical path". If there are active buildd > admins, I don't see why they couldn't continue to use Debian > infrastructure. And let the software in Debian rot more and more because we do not care to catch all kinds of bugs in them that we get hinted at by using those architectures as first class citizens? Supporting more architectures means getting robuster software and being able to catch bugs before they hit everyone's pet architectures. It also means that software is robust enough that compiler have a chance to implement more optimisations, libraries can switch to faster implementations, because software is actually tested a bit wider. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110831091540.ga12...@pcpool00.mathematik.uni-freiburg.de
Re: Maintainers, porters, and burden of porting
* Kurt Roeckx [110831 00:01]: > On Mon, Aug 29, 2011 at 01:06:15PM +0200, Lucas Nussbaum wrote: > I think to have a useful discussion we need to start with the > different kind of failures we can actually see that are arch > dependend. Some of those shows up on only 1 or 2 arches, some > show up on all but 1 or 2 arches: > 1) The source package just bails out because it never heard >of that port, or needs to know that it's 32 or 64 bit, or >that it's needs assembler, or it's just missing $arch in >the control file somewhere, or has a broken configure script >that checks the wrong thing, or whatever. > 2) It has some undefined behaviour, it works on some arches >and fails on others. But it's not a problem with the port >or toolchain. But porters might know that those show up >from time to time. There's nothing in "being porter" that makes one better at handling those, that's just general "know what you do", which of course will usually be more often found with porters than with the random DD hardly knowing the difference between compiler and interpreter. > 3) Packages that assume that some implementation defined behaviour >is the same on all arches like that a char is signed on some >ports and unsigned on others, that a size_t and long are the >same size, that a pointer fits in an integer, ... Some of >those cause a compiler error or warning only on a few arches. > 4) Packages that have arch specific code that does the wrong >thing. 4b) Packages that have some arch-specific code and some fallback code for unknown architectues, with the fallback code utterly broken. > 5) Packages where the author only uses Linux and are just not >written with portability in mind. This might include things >like using Linux specific APIs and header files, using various >extention without checking that they're available, not working >on big endian machines, ... "only uses Linux" and "not working on big endian machines" look quite unrelated. > 6) Packages that have timing problems that only show up on some >arches or buildds because they're faster or slower. Or because the buildd use a different filesystem, or some slightly different kernel, or or or ... Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110831092202.gb12...@pcpool00.mathematik.uni-freiburg.de
Re: Maintainers, porters, and burden of porting
Lucas Nussbaum (31/08/2011): > hurd-i386, kfreebsd-i386 and kfreebsd-amd64 are probably too > experimental to be used on production systems. For kfreebsd, my main > problem (with my Ruby hat) is the linuxthreads-based thread library, but > there might be other problems. http://lists.debian.org/87r55kzz6d@windlord.stanford.edu Mraw, KiBi. signature.asc Description: Digital signature
Re: Maintainers, porters, and burden of porting
* Lucas Nussbaum (lu...@lucas-nussbaum.net) [110831 10:56]: > Also, in the case of architectures targetted at embedded systems (I'm > thinking about mips and mipsel), what is important is that Debian > infrastructure supports the development of those architectures, but I > don't think that there's much to gain by being officially supported if > it's only used in production through derivatives that can provide the > official support. You are aware that there are mipsel netbooks? And arm tablets? There is hardware running standard Debian, and that's one of the large advantages of Debian. I don't want to give that up. > hurd-i386, kfreebsd-i386 and kfreebsd-amd64 are probably too > experimental to be used on production systems. For kfreebsd, my main > problem (with my Ruby hat) is the linuxthreads-based thread library, but > there might be other problems. I know people who put kbsd on edge firewalls because it's way easier for a standard linux / debian admin. And please don't put hurd-i386 in the same camp as kbsd. They're not. Andi -- 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/20110831093558.gj15...@mails.so.argh.org
Re: Maintainers, porters, and burden of porting
* Lucas Nussbaum (lu...@lucas-nussbaum.net) [110831 07:34]: > Regarding architectures, we made releases with a semi-official status on > two occasions at least (etch-m68k and kfreebsd in squeeze). I hope you see the difference between etch-m68k and kbsd. Kbsd is "too new", whereas etch-m68k was (at least for some time) the last release with m68k. > Being in the second set would be fine, and would not be a step towards > being thrown out of Debian. Maintainers should still help porters get > their packages ported, etc. But it would allow to relieve some of the > pressure regarding testing migrations, for example. This doesn't work. If the architecture isn't considered anymore for testing migration, we'll soon end up in a state where packages are too broken (just consider library transitions where a random package gets build delayed). However, good news is that we are currently improving our testing migration scripts to allow some overlap during library transitions on all arches in most parts of the release cycle. > I've always wondered what was the point of having some architectures > part of stable releases as official architectures. Sure, they are very > useful as experimental architectures, and very fun to work on, but it's > unlikely that people will use them on production machines because the > hardware is too old & slow, or some key piece of software is too > unstable. You mean like arm tablets, mipsel laptops, kbsd routers? Andi -- 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/20110831094043.gk15...@mails.so.argh.org
Re: Maintainers, porters, and burden of porting
On 08/31/2011 11:35 AM, Andreas Barth wrote: > * Lucas Nussbaum (lu...@lucas-nussbaum.net) [110831 10:56]: >> Also, in the case of architectures targetted at embedded systems (I'm >> thinking about mips and mipsel), what is important is that Debian >> infrastructure supports the development of those architectures, but I >> don't think that there's much to gain by being officially supported if >> it's only used in production through derivatives that can provide the >> official support. > > You are aware that there are mipsel netbooks? And arm tablets? There > is hardware running standard Debian, and that's one of the large > advantages of Debian. I don't want to give that up. Strong ack. Not to forget various NAS and embedded boxes like the Sheevaplug which are shipped with Debian (or Ubuntu..). >> hurd-i386, kfreebsd-i386 and kfreebsd-amd64 are probably too >> experimental to be used on production systems. For kfreebsd, my main >> problem (with my Ruby hat) is the linuxthreads-based thread library, but >> there might be other problems. > > I know people who put kbsd on edge firewalls because it's way easier > for a standard linux / debian admin. And please don't put hurd-i386 in > the same camp as kbsd. They're not. Hurd is far away from being useful while kfreebsd offers a great mic of a good kernel and a usable userland (instead of the imho slightly annoying FreeBSD userland). Definitely not a playground. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- 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/4e5e0697.30...@bzed.de
Re: Maintainers, porters, and burden of porting
Andreas Barth, le Wed 31 Aug 2011 11:35:59 +0200, a écrit : > I know people who put kbsd on edge firewalls because it's way easier > for a standard linux / debian admin. We are considering this in our ISP, as well. Samuel -- 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/20110831100333.gb4...@type.u-bordeaux.fr
Re: Maintainers, porters, and burden of porting
On 31/08/11 at 11:24 +0200, Cyril Brulebois wrote: > Lucas Nussbaum (31/08/2011): > > hurd-i386, kfreebsd-i386 and kfreebsd-amd64 are probably too > > experimental to be used on production systems. For kfreebsd, my main > > problem (with my Ruby hat) is the linuxthreads-based thread library, but > > there might be other problems. > > http://lists.debian.org/87r55kzz6d@windlord.stanford.edu I know that there's a lot of good stuff in the FreeBSD kernel, such as ZFS, PF, DTrace (though I'm not sure if it's available on amd64 now?). And I also know that the Debian userland (esp. package management) is much better than the FreeBSD one. I used FreeBSD on my desktop between 2000 and 2002, and when I installed FreeBSD this week-end to debug a kfreebsd issue, it seemed that userland had not made much progress. But a different thread library that has clear POSIX compliance bugs[*] is the kind of things that make me fear that many more packages than we see currently are broken on kfreebsd. And I'm not sure that it's where we want to spend our manpower. [*] due to linuxthreads: #639658 [kfreebsd] waitpid from a thread does not work for child processes created by other threads. there's also some signals+thread fun. Lucas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110831095724.ga2...@xanadu.blop.info
Re: Maintainers, porters, and burden of porting
On 31/08/11 at 11:40 +0200, Andreas Barth wrote: > * Lucas Nussbaum (lu...@lucas-nussbaum.net) [110831 07:34]: > > Being in the second set would be fine, and would not be a step towards > > being thrown out of Debian. Maintainers should still help porters get > > their packages ported, etc. But it would allow to relieve some of the > > pressure regarding testing migrations, for example. > > This doesn't work. If the architecture isn't considered anymore for > testing migration, we'll soon end up in a state where packages are too > broken (just consider library transitions where a random package gets > build delayed). However, good news is that we are currently improving > our testing migration scripts to allow some overlap during library > transitions on all arches in most parts of the release cycle. First, if we are not supporting stable releases on a given arch, it also means that we don't need to release with exactly the same versions as on the other architectures. I think that it's what we did for etch-m68k. I understand that it's a lot of work to re-add architectures to testing transitions, but then, on the other hand, you get the benefit that transitions no longer get blocked by this architecture during the rest of the release cycle. > > I've always wondered what was the point of having some architectures > > part of stable releases as official architectures. Sure, they are very > > useful as experimental architectures, and very fun to work on, but it's > > unlikely that people will use them on production machines because the > > hardware is too old & slow, or some key piece of software is too > > unstable. > > You mean like arm tablets, mipsel laptops, kbsd routers? Are there known, hard-to-solve problems with the kernel, libc, toolchain, etc. on armel and mipsel? If there aren't, and the buildd admins+porters think that it's useful to have them as officially supported architectures, then it's fine to keep them that way, of course. Lucas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110831100717.ga3...@xanadu.blop.info
Re: Maintainers, porters, and burden of porting
On Tue, Aug 30, 2011 at 10:34 AM, Lars Wirzenius wrote: > But both are wrong, too: it's always the job of both. It's not supposed > to be a struggle between maintainers and porters, but everyone in > Debian against bugs and shortcomings of our system. Also, neither group > is homogenous, and it's silly to require everyone to be an expert on > debugging tricky portability problems. So the best approach is, I think, > to do your best and ask for help when needed. And avoid framing discussions > in ways that create unnecessary antagonism between groups of people. Here here! Do your best and when the free software community (upstream, Debian porters/maintainers and other distro maintainers/porters) is unable to solve portability issues you can always give up via an "RM: foo on $arch" bug. -- 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/caktje6htylodmkwwa7hbpjst4ig_pjam-gickxln0mmib0g...@mail.gmail.com
Re: Maintainers, porters, and burden of porting
* Lucas Nussbaum (lu...@lucas-nussbaum.net) [110831 12:07]: > On 31/08/11 at 11:40 +0200, Andreas Barth wrote: > > * Lucas Nussbaum (lu...@lucas-nussbaum.net) [110831 07:34]: > > > Being in the second set would be fine, and would not be a step towards > > > being thrown out of Debian. Maintainers should still help porters get > > > their packages ported, etc. But it would allow to relieve some of the > > > pressure regarding testing migrations, for example. > > > > This doesn't work. If the architecture isn't considered anymore for > > testing migration, we'll soon end up in a state where packages are too > > broken (just consider library transitions where a random package gets > > build delayed). However, good news is that we are currently improving > > our testing migration scripts to allow some overlap during library > > transitions on all arches in most parts of the release cycle. > > First, if we are not supporting stable releases on a given arch, it also > means that we don't need to release with exactly the same versions as on > the other architectures. I think that it's what we did for etch-m68k. This is equivalent to kicking out the architecture. See etch-m68k. I don't think this is helpful in general. If however an architecture becomes too painful to be supported, we have already and will again in future remove support for the architecture. See hppa during the last cycle. Andi -- 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/20110831102051.gc32...@mails.so.argh.org
Re: Maintainers, porters, and burden of porting
On 31/08/11 at 12:03 +0200, Samuel Thibault wrote: > Andreas Barth, le Wed 31 Aug 2011 11:35:59 +0200, a écrit : > > I know people who put kbsd on edge firewalls because it's way easier > > for a standard linux / debian admin. > > We are considering this in our ISP, as well. Come on, Samuel. You are writing that as if you worked for a large ISP. I suspect that the ISP you are talking about is Aquilenet (http://www.aquilenet.fr/). For those following at home, it's a 'Do it yourself ISP', made by people interested in experimenting in building their own ISP. It's a spinoff of another ISP, FDN (http://www.fdn.fr/). I also suspect that like our own spinoff ISP of FDN here, called LDN (http://ldn-fai.net/), Aquilenet has less than 10 DSL subscribers (we have one, soon two!). So, it's a really interesting project, but not really a proof of widespread kfreebsd usage in high-demand production environments like you seem to imply ;) Lucas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110831102524.ga3...@xanadu.blop.info
Re: Maintainers, porters, and burden of porting
Lucas Nussbaum, le Wed 31 Aug 2011 12:25:24 +0200, a écrit : > So, it's a really interesting project, but not really a proof of > widespread kfreebsd usage in high-demand production environments like > you seem to imply ;) Well, I didn't want to imply anything at all, just that it was a decision that made sense. It's just the usual problem of wanting to write hundreds of mails per day, you can't spend time to provide the whole background. Samuel -- 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/20110831102944.gk4...@type.u-bordeaux.fr
Re: Dependencies of metapackages
On Tue, Aug 30, 2011 at 17:37 +0200, Yves-Alexis Perez wrote: > On mar., 2011-08-30 at 16:11 +0100, Wolodja Wentland wrote: > > > > I agree that a general change of all metapackages is probably not a good > > idea, > > but I think that changing the root-nodes of the metapackage tree (i.e. > > metapackages like gnome, xfce4, kde-full, ...) is a sensible change. It is > > in > > particular one that solves the problems without the need to introduce new > > package fields, change packaging tools or their semantics. > > If you think some dependencies in those metapackages are unneeded or too > strong, you're welcome to open a wishlist bug against them. > > For xfce4, while I'm open to discussion, the distinction between > depends/recommends/suggests is intended, and at first sight I don't see > a need to change it. Could you elaborate on your reasons and your intentions for making the distinction? Do you have reasons for not changing Depends into Recommends? I will probably file bugs, but do not want to do so if I already know that the maintainer is not going to change it. I am sincerely interested and my only motivation is to make Debian a better distribution. It is just that I know that the behaviour discussed in this thread is a nuisance for a subset of our users and I wanted to gather additional input about different strategies to solve this. I tried to come up with a solution that does not require changes to the packaging tools, the introduction of new package fields or constitute a major change in the semantics of packages or tools. All that being said: I still have the opinion that metapackages *are* different from normal and virtual packages and that, in particular, the relations they define to other packages conflate distinct relations just because it eases implementation. (which is not inherently bad). -- Wolodja 4096R/CAF14EFC 081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC signature.asc Description: Digital signature
Re: Maintainers, porters, and burden of porting
Le Wed, Aug 31, 2011 at 11:35:59AM +0200, Andreas Barth a écrit : > * Lucas Nussbaum (lu...@lucas-nussbaum.net) [110831 10:56]: > > Also, in the case of architectures targetted at embedded systems (I'm > > thinking about mips and mipsel), what is important is that Debian > > infrastructure supports the development of those architectures, but I > > don't think that there's much to gain by being officially supported if > > it's only used in production through derivatives that can provide the > > official support. > > You are aware that there are mipsel netbooks? And arm tablets? In some previous discussion I was also pointed at 64-core mips workstations. How many of these machines are running Debian ? I do not think that we can consider ports equally. The arm platform and the armel port have some clear success. According to popcon, the user community of Debian on armel is constantly growing, and is aproximately 1 % of our ‘PC’ (i386 and amd64) user community. Also, other distributions, for instance Ubuntu, increase their committment for this platform. In comparison, the usrerbase of the mipsel port stagnates to 0.05 % of our PC userbase. If there were many Debian users of mipsel netbooks and workstations, why would they not use Popcon, as the Debian users of armel computers do ? Having Debian running on rare architectures is a great acheivement. However, overestimating their user base results in turning maintainers and porters against each other. While porting a program on a rare architecture will raise its quality, there is usually no shortage of bugs that directly affect users on more popular architectures, and solving them also raises the program's quality. Importantly, our current practice is not raising Debian's quality. In contrary, it makes us distribute a large number of packages that do not work at all. It is usually not noticed because nobody uses them anyway, until the maintainer activates some build-time regression tests. Many specialised packages have insufficient testing on the architectures that are not reported to be used upstream nor in their users community. I think we would benefit of a system that acknowledges this, and should have more flexibility for taking it into account when deciding where we spend our time. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- 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/20110831114509.ga20...@merveille.plessy.net
Re: Maintainers, porters, and burden of porting
On Wed, 2011-08-31 at 11:57 +0200, Lucas Nussbaum wrote: [...] > But a different thread library that has clear POSIX compliance bugs[*] > is the kind of things that make me fear that many more packages than we > see currently are broken on kfreebsd. And I'm not sure that it's where > we want to spend our manpower. > > [*] due to linuxthreads: #639658 [kfreebsd] waitpid from a thread does > not work for child processes created by other threads. > there's also some signals+thread fun. Of course, Linux had those bugs for many years, so most multithreaded programs that run on Linux are probably tolerant of them. Ben. signature.asc Description: This is a digitally signed message part
ifupdown package interfaces include function
Hi, While "trying" to port the Xen (xapi) network reconfiguration scripts to debian for the project "Kronos", I was looking if there was a way to use includes in the /etc/network/interfaces file, for example /etc/network/interfaces.d/* I found this "bug" report that is talking exactly about what I'm looking for and provides patches If i'm right it seems it has been closed and merged in ifupdown-0.7~alpha4. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=159884 But, is it supposed to be working ? I just tried with an interfaces file like this: --- # DO NOT EDIT: This file was autogenerated by interface-reconfigure auto lo iface lo inet loopback source /etc/network/interfaces.d/* --- and it doesn't seems to load the files in that directory. The package version installed on my box is: ifupdown 0.7~alpha5+really0.6.15 high level tools to configure network interfaces Thanks for your help. Sébastien -- 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/4e5e2343.9080...@swisscenter.com
Re: ifupdown package interfaces include function
Sébastien Riccio writes: > If i'm right it seems it has been closed and merged in ifupdown-0.7~alpha4. [...] > The package version installed on my box is: > ifupdown 0.7~alpha5+really0.6.15 Notice the +really0.6.15. Try with the ifupdown from experimental, which IS 0.7~alpha, unlike the one in unstable (which has a confusing version, due to an accidental upload of 0.7~alpha to sid, followed by a revert to 0.6.15 + patches). -- |8] -- 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/877h5tixr5@balabit.hu
Re: ifupdown package interfaces include function
On 31.08.2011 14:14, Gergely Nagy wrote: Sébastien Riccio writes: If i'm right it seems it has been closed and merged in ifupdown-0.7~alpha4. [...] The package version installed on my box is: ifupdown 0.7~alpha5+really0.6.15 Notice the +really0.6.15. Try with the ifupdown from experimental, which IS 0.7~alpha, unlike the one in unstable (which has a confusing version, due to an accidental upload of 0.7~alpha to sid, followed by a revert to 0.6.15 + patches). Damn, you're right. It works with the right version :) I think I was a bit confused with the really0.6.15 thing, now I get it! Thanks a lot for pointing that out. Best regards, Sébastien -- 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/4e5e273b.6030...@swisscenter.com
Re: ifupdown package interfaces include function
On Wed, Aug 31, 2011 at 02:04:19PM +0200, Sébastien Riccio wrote: > I found this "bug" report that is talking exactly about what I'm > looking for and provides patches > If i'm right it seems it has been closed and merged in ifupdown-0.7~alpha4. [...] > The package version installed on my box is: > ifupdown 0.7~alpha5+really0.6.15 > high level tools to configure network interfaces ifupdown 0.7~alpha5 was uploaded to unstable rather than experimental by mistake. Since version numbers aren't allowed to go backwards, we now have 0.7~alpha5+really0.6.15 in unstable, but for the purposes of working out what bugs may be expected to be fixed, you should treat it as if it were simply 0.6.15. If you want to try out fixes from 0.7~alpha4, you should install the ifupdown package from experimental instead. -- Colin Watson [cjwat...@debian.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/20110831122930.ga5...@riva.dynamic.greenend.org.uk
Re: Maintainers, porters, and burden of porting
On 31/08/11 at 12:58 +0100, Ben Hutchings wrote: > On Wed, 2011-08-31 at 11:57 +0200, Lucas Nussbaum wrote: > [...] > > But a different thread library that has clear POSIX compliance bugs[*] > > is the kind of things that make me fear that many more packages than we > > see currently are broken on kfreebsd. And I'm not sure that it's where > > we want to spend our manpower. > > > > [*] due to linuxthreads: #639658 [kfreebsd] waitpid from a thread does > > not work for child processes created by other threads. > > there's also some signals+thread fun. > > Of course, Linux had those bugs for many years, so most multithreaded > programs that run on Linux are probably tolerant of them. But Linux hasn't had them since many years too (NPTL in Debian: 2003), so multithreaded programs that were written more recently might not be so tolerant. If I remember correctly, hppa was using linuxthreads too when it was in Debian. Are there other ports in that case (e.g on debian-ports.org)? One problem with linuxthreads is that it can be hard to convince upstream to apply patches for it, when the only reason for needing those patches is that Debian GNU/kFreeBSD has POSIX compliance bugs. L. -- 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/20110831124241.ga18...@xanadu.blop.info
Re: Maintainers, porters, and burden of porting
On 2011-08-31, Paul Wise wrote: > On Tue, Aug 30, 2011 at 10:34 AM, Lars Wirzenius wrote: >> But both are wrong, too: it's always the job of both. It's not supposed >> to be a struggle between maintainers and porters, but everyone in >> Debian against bugs and shortcomings of our system. Also, neither group >> is homogenous, and it's silly to require everyone to be an expert on >> debugging tricky portability problems. So the best approach is, I think, >> to do your best and ask for help when needed. And avoid framing discussions >> in ways that create unnecessary antagonism between groups of people. > Here here! > > Do your best and when the free software community (upstream, Debian > porters/maintainers and other distro maintainers/porters) is unable to > solve portability issues you can always give up via an "RM: foo on > $arch" bug. Sure. But you can't do that with core packages. Depending on where in the stack you try to remove it from, you have a fallout that's huge. (Imagine ruby being removed from sparc. You'd need to adjust quite a bunch of package to not build with ruby on sparc only. "dak rm -nR -b -p -a sparc ruby1.8 libruby1.8 ruby1.8-dev libtcltk-ruby1.8" gives a hint.) 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/slrnj5sb3a.j8h.tr...@kelgar.0x539.de
Bug#639898: ITP: pxljr -- driver for HP's Color LaserJet 35xx/36xx color laser printers
Package: wnpp Severity: wishlist Owner: Didier Raboud -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Package name: pxljr Version : 1.3 Upstream Author : Hin-Tak Leung URL : http://hp-pxl-jetready.sourceforge.net/ License : GPL-2+, LibJPEG Programming Lang: C Description : driver for HP's Color LaserJet 35xx/36xx color laser printers HP's Color LaserJets 35xx and 36xx are supported by HP's HPIJS driver (part of HPLIP), but HPIJS supports only the lowest quality level of the three which are available under Windows. This driver which is not developed at HP but by a independent developer supports all modes and so provided the highest printout quality for these printers. This package will be based on the existing Ubuntu package and will see its .orig tarball repacked to get its libjpeg and libijs embedded copies removed. Packaging is currently at http://git.debian.org/?p=collab-maint/pxljr.git. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQGcBAEBCAAGBQJOXjiSAAoJEIvPpx7KFjRVhKYL/2BmPUGhGBomzUV5jhrGqkuy 6awQMSO8gkHgXdc2G4Xx4Mo9Reu8y38dsyY3//6XLYK6PQERZ3D6swHf0zynCrw6 FCyb2VNS65x5y8Io+F1Pf7RMYcWt9BTLpbQfWqwa05IUCIrYb7kbRZNM7ncCOeux mbfwV9yLPnd9iB5EKn8WxqBMC6VevLX1FypkfOskw+aaItu2X5bIAEEFDzZe8VyA Q5vcq1rlv3GvJ2b39vj0CR2FuyV61N1uFjzLhuiXYw+uLKaHOz7ajwQT4KX0IQJT rik5w1HvQG7RjaRfnW6Zt3zE3mRhaMz85nlgXNxOSAl2ff98NiG7ZYHP6AbPEyTj idePqyT4KAHDaVLqYq9DFg3ZgOHI2QRCbkFr7rXiIvcCU7K0K7NP+ZEa6NnzM/oy vrgWoIl+7L34ccnOo9eUSkCy/5Cxzl5zNMHezIouOtvy+eKChtYozPXZsvc3LVgX /E5vImG2X6wu0pfbhD6a7RHJVgNZgcRrXdW/jYlI9g== =DER8 -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/20110831133516.17102.84453.reportbug@Tamino
Re: Maintainers, porters, and burden of porting [and 1 more messages]
Lucas Nussbaum writes ("Maintainers, porters, and burden of porting"):
> However, issues such as miscompilation or broken syscall or libc
> semantics are largely undetected. To illustrate this, you can have a
> look at #635126 (miscompilation on armel and sparc) and #639658
> (forks+threads fun on kFreeBSD, derived from #593139).
To be honest I think it's unreasonable to expect to be able to provide
a full Debian system on an architecture with significant bugs in this
pthreads (much as I personally hate multithreaded code ...).
Our problem is that we have only these three choices:
* Leave affected packages blocked from testing propagation until the
bug is fixed. This is the right answer before the bug has been
properly identified, or if the bug is reasonably tractable and
should simply be fixed (and can thus be expected to be fixed by
anyone who cares in a reasonable timeframe).
* Drop the arch from testing propagation. This is a global change
and will quickly make the architecture a wreck in our archive.
It's a very unpalatable choice and one that obviously porter teams
will strongly resist.
* Change each individual source package affected by a per-arch bug
(perhaps a bug in one of the dependencies) to exclude the affected
architecture. This is a lot of faff and is recording the
information about the bug in the wrong place (and when the bug is
fixed a lot of work needs to be undone). Understandably
maintainers resist that.
* The RMs could manually override testing propagation for certain
bugs. I don't know if this is already done but as a general
solution it obviously doesn't scale - the RMs don't have the time
to research and deal with this kind of thing "retail".
Let me make an alternative proposal:
* The root cause bug in the BTS would be given a special tag
("arch-blocker:" or something). I will call such a bug which
is open and has existed in this state for 30 days a "ripe arch
blocker for ".
Bugs in other affected packages are marked as blocked by the root
cause bug. These bugs, and the arch blocker itself, may be RC, or
not, as appropriate. Let us say "ripe arch bug" to mean "ripe arch
blocker, or bug blocked by a ripe arch blocker".
The effects would be:
1. Any ripe arch bug is ignored for the purposes of testing
propagation.
2. For a package with an RC ripe arch bug for :
(i) will be ignored for testing propagation
(ii) no builds will be attempted by buildds,
automatic tests may be skipped on , etc.
The workflow would be as follows:
* If a package has an arch-specific bug, the root cause needs to be
identified, by collaboration between porters and maintainers. This
process should be driven by the maintainer.
* Once the cause has been identified:
- If the root cause is elsewhere, a bug needs to be filed bug
against that other package. If such a bug already exists, the
maintainer of the first package can simply mark their bug as
blocked by the arch blocker. This will allow their package to
migrate unless the arch blocker is new enough.
If no such bug already exists, the maintainer should file a bug
against the appropriate package (toolchain or libc, perhaps),
and immediately tag it as an arch blocker.
- If the root cause is in the package itself, the maintainer or a
porter may tag the bug with arch-blocker:. This is
appropriate if the fact that the package isn't portable is a
bug, with which the maintainer wants help from porters, rather
than an inherent property of the package.
If the bug is RC this will effectively allow the maintainer to
drop support for that arch if help is not forthcoming, without
having to modify the source package.
A porter should only remove the arch-blocker tag if the cause
has been clearly identified, and the steps necessary to fix it
are simple and straightforward bugfixes to the package, and
these steps have been set out in the bug report.
* If the cause cannot be determined, whether because sufficient
support from porters isn't available, or for any other reason, the
maintainer should proceed on the assumption that the bug is in
their own package.
The intended result would be that architectures with persistent
problems would become partial. But things wouldn't get worse on those
architectures for packages not affected by persistent arch-specific
bugs.
The approach I describe will hopefully also avoid the necessity for
arguments between maintainers and porters about whose fault a bug is.
When an arch blocker is fixed, all the packages which were affected
are now fully considered for testing propagation. I guess it may be
necessary to "force through" some transitions which the arch has
missed. I'm not sure how feasible this would be and I would welcome
comments from RMs.
Ian.
--
To UN
simple Debian package information in the wiki
Hi Stéphane, I have just created some pages on the wiki : http://wiki.debian.org/Packaging/Minimal (for empty packages) http://wiki.debian.org/Packaging/Trivial (for a pdf file) http://wiki.debian.org/Packaging I am interested to have feed back on it Thanks Henri Le Foll -- 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/4e5e26a1.4060...@lefoll.eu
Re: simple Debian package information in the wiki
I think dh_make is not so good for *simple* package, and is not good at all :-) 2011/8/31 Henri Le Foll > Hi Stéphane, > > I have just created some pages on the wiki : > > http://wiki.debian.org/Packaging/Minimal (for empty packages) > http://wiki.debian.org/Packaging/Trivial (for a pdf file) > > http://wiki.debian.org/Packaging > > I am interested to have feed back on it > > Thanks > > Henri Le Foll > > > -- > 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/4e5e26a1.4060...@lefoll.eu > >
Re: simple Debian package information in the wiki
On Wed, Aug 31, 2011 at 02:18:41PM +0200, Henri Le Foll wrote: > Hi Stéphane, > > I have just created some pages on the wiki : > > http://wiki.debian.org/Packaging/Minimal (for empty packages) > http://wiki.debian.org/Packaging/Trivial (for a pdf file) > > http://wiki.debian.org/Packaging > > I am interested to have feed back on it > > Thanks > > Henri Le Foll IMHO you should add a link to the "Debian Packaging Tutorial"[0] (by Lucas Nussbaum). Thanks for your work. [0] http://www.lucas-nussbaum.net/blog/?p=676 -- Josué M. Abarca S. Vos mereces Software Libre. PGP key 4096R/70D8FB2A 2009-06-17 Huella de clave = B3ED 4984 F65A 9AE0 6511 DAF4 756B EB4B 70D8 FB2A -- 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/20110831143836.GB2886@numenor.numenor
Re: Re: ifupdown package interfaces include function
ifupdown 0.7~alpha5 was uploaded to unstable rather than experimental by mistake. Since version numbers aren't allowed to go backwards, we now have 0.7~alpha5+really0.6.15 in unstable, but for the purposes of Don't we have epochs for this? I know they are annoying and should be avoided, but they are still a blessing compared to the current confused versioning scheme. -- 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/4e5e436e.4040...@greffrath.com
Re: Re: ifupdown package interfaces include function
Fabian Greffrath, le Wed 31 Aug 2011 16:21:34 +0200, a écrit : > >ifupdown 0.7~alpha5 was uploaded to unstable rather than experimental by > >mistake. Since version numbers aren't allowed to go backwards, we now > >have 0.7~alpha5+really0.6.15 in unstable, but for the purposes of > > Don't we have epochs for this? I know they are annoying and should be > avoided, but they are still a blessing compared to the current confused > versioning scheme. Epochs are permanent annoying things, while this kind of confusion is only temporary. Samuel -- 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/20110831145153.go3...@type.u-bordeaux.fr
Re: simple Debian package information in the wiki
Henri Le Foll writes: > http://wiki.debian.org/Packaging/Minimal (for empty packages) > http://wiki.debian.org/Packaging/Trivial (for a pdf file) > > http://wiki.debian.org/Packaging > > I am interested to have feed back on it I maintain my view that to learn packaging, the best way to do that is to start from scratch - there are no unknown black boxes there one does not understand (and while dh-make is a great tool in the right hands, the default templates it works from are a tad confusing to someone who has no idea how packaging works). I also disagree with using equivs for this: while it works, and gets the job done quickly, it does not encourage learning to package. I believe that the extra effort in learning the basics is well worth the trouble. It's so much easier to just quickly throw something together and install it properly than putting it into /usr/local on any number of computers one wishes to install a piece of software or documentation or whatever on. Therefore, while the current article is a good start, I think it could be improved a lot by switching from the "simple from an experienced point of view" to "simple for someone who hasn't done any packaging yet, at all" mindset. The "Introduction to Debian Packaging"[0] article linked from one of the pages above is a very solid start (even though it uses dh short form - explaining all the steps it does for even the simplest packages would make a novice's head hurt), and one of the best introductions I've seen so far. If I'd attempt to write a packaging guide, for non-compiled software, I'd start from there: "Read THAT until it gets to debian/rules, and instead of doing what it says, do THIS-AND-THAT, because...". Simply listing steps to do isn't all that useful in my opinion: one will not know WHY that step is done, or what it does (or $deity forbid, how actually do that step [see: "5 - modify the files in the debian directory"]). It's great to have a summary, as a kind of Table of Contents, but without explanation, it's a bit... too little. So, once there's more content on these WiKi pages, they can be very useful, they do have the potential, but they're not quite there yet. [0]: http://wiki.debian.org/IntroDebianPackaging -- |8] -- 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/87zkiphbcy@balabit.hu
Re: simple Debian package information in the wiki
Henri Le Foll writes ("simple Debian package information in the wiki"):
> http://wiki.debian.org/Packaging/Trivial (for a pdf file)
If nothing else, this advises DFSG-violation, since a pdf is
practically never its own source code.
I agree with many of the criticisms from others, too.
Ian.
--
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/20062.19670.91459.806...@chiark.greenend.org.uk
Re: Re: ifupdown package interfaces include function
On Wed, Aug 31, 2011 at 04:21:34PM +0200, Fabian Greffrath wrote: > Don't we have epochs for this? I know they are annoying and should > be avoided, but they are still a blessing compared to the current > confused versioning scheme. Epochs are for when your entire version numbering scheme permanently changes, not really for when you just need to temporarily go backwards for a short while. -- Colin Watson [cjwat...@debian.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/20110831154408.ga25...@riva.dynamic.greenend.org.uk
Re: simple Debian package information in the wiki
On Wed, Aug 31, 2011 at 10:03 AM, Gergely Nagy wrote: > Henri Le Foll writes: > >> http://wiki.debian.org/Packaging/Minimal (for empty packages) >> http://wiki.debian.org/Packaging/Trivial (for a pdf file) >> >> http://wiki.debian.org/Packaging >> >> I am interested to have feed back on it > > I maintain my view that to learn packaging, the best way to do that is > to start from scratch - there are no unknown black boxes there one does > not understand The book "The Debian System", by Martin Krafft, has a nice chapter or two about packaging (bottom up learning, as you describe, Gergely.) Unfortunately, it does not look like there is a free electronic version available. -Matt Zagrabelny -- 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/CAOLfK3WLLX7O98ygmS3tGT=j0ots6gdslqfqrnuzm_02au0...@mail.gmail.com
Re: simple Debian package information in the wiki
On Wed, Aug 31, 2011 at 05:03:25PM +0200, Gergely Nagy wrote:
> I maintain my view that to learn packaging, the best way to do that is
> to start from scratch
I agree, but the request posted to this list was not about *learning*
packaging. Rather, it reads:
> I would like to make very simple Debian package to install very simple
> file on my system, only static file, like documentation.
Now, we can of course say to users advancing such a request "we won't
let you; either you actually learn to do packaging, or you keep your
static files around, unpackaged, on your system". I personally have
sympathies for users that are not (yet?) up to packaging stuff properly,
but still want a way to ship stuff on their machine in a way that makes
it known to the packaging system. It seems to me that they are willing
to do the right thing™, even though they are not able to commit to full
blown packaging.
People facing that specific use case would probably give up if they had
to learn full blown packaging. Anyone should judge by themselves whether
giving up in those use cases is better or worse than packaging using
some heavy packaging wrapper such as those mentioned in this thread.
There is a point, however, in saying that those wrappers should provide
all the needed information to switch to proper packaging when the user
stumble upon scenarios not supported by the wrappers. (In my personal
experience: a user introduced to equivs has been very happy in the
beginning to use it and have them took the time to learn full blown
packaging after discovering equivs limitation. I cannot say whether he
would have reached that point if she hasn't had a intermediate "easy"
tool to use.)
Cheers.
[ yes: we're probably quite offtopic for -devel ]
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
Re: Re: ifupdown package interfaces include function
On Wed, Aug 31, 2011 at 04:21:34PM +0200, Fabian Greffrath wrote: > >ifupdown 0.7~alpha5 was uploaded to unstable rather than experimental by > >mistake. Since version numbers aren't allowed to go backwards, we now > >have 0.7~alpha5+really0.6.15 in unstable, but for the purposes of > > Don't we have epochs for this? I know they are annoying and should > be avoided, but they are still a blessing compared to the current > confused versioning scheme. Hopefully we'll have 0.7 in unstable soon(ish), and this will just be a temporary issue. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: Maintainers, porters, and burden of porting
On Wed, Aug 31, 2011 at 04:30:56AM +, Felipe Sateler wrote: > > I think some clarification needs to be done for these types of errors. I > sometimes get a (serious) bug reported against one of my packages because: > > 1. python errored out with a glibc-detected error > 2. gcc broke in some way (ICE, error -11, error -4) > 3. swig failed with error -10 > > None of these are my package's fault. I wonder if reassigning to the > program erroring out is the right thing to do. There should at least be a bug assigned to the package that has the bug. You can do an "affects" to indicate it affects your package, and so it will also show up in the bugs for your package. 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/20110831193834.ga25...@roeckx.be
Re: Maintainers, porters, and burden of porting [and 1 more messages]
On Wed, Aug 31, 2011 at 02:52:53PM +0100, Ian Jackson wrote:
> Let me make an alternative proposal:
>
> * The root cause bug in the BTS would be given a special tag
>("arch-blocker:" or something). I will call such a bug which
>is open and has existed in this state for 30 days a "ripe arch
>blocker for ".
>
>Bugs in other affected packages are marked as blocked by the root
>cause bug. These bugs, and the arch blocker itself, may be RC, or
>not, as appropriate. Let us say "ripe arch bug" to mean "ripe arch
>blocker, or bug blocked by a ripe arch blocker".
If there is a bug in say eglibc on only arch, and considered to be
RC on that arch, would you then lower the severity of that bug,
and use this new tag to indicate it's RC only on that arch?
This could be useful for arches that are not being considered for
a release, but I don't see the point in doing the same for if it's
currently still considered for a release. If the bug already
affects testing it will migrate anyway.
But tracking bugs that way might also be useful to see if we
should consider that the arch should be part of the next release
or not.
>The effects would be:
>
> 1. Any ripe arch bug is ignored for the purposes of testing
>propagation.
If they already affect testing, it will already be ignored
anyway.
> 2. For a package with an RC ripe arch bug for :
> (i) will be ignored for testing propagation
So such bugs would automaticly have an effect on release
migration, while this is not something the release team
decides itself. Or do you only mean that package will
be ignored and can move testing anyway? Or they can't
move to testing?
> (ii) no builds will be attempted by buildds,
You mean we completly stop building anything for $arch? Or
only the packages that are affected by it? Other than wasting
some buildd time, I don't see the harm in building things most
of the time.
>automatic tests may be skipped on , etc.
>
> The workflow would be as follows:
>
> * If a package has an arch-specific bug, the root cause needs to be
>identified, by collaboration between porters and maintainers. This
>process should be driven by the maintainer.
>
> * Once the cause has been identified:
>
> - If the root cause is elsewhere, a bug needs to be filed bug
> against that other package. If such a bug already exists, the
> maintainer of the first package can simply mark their bug as
> blocked by the arch blocker. This will allow their package to
> migrate unless the arch blocker is new enough.
>
> If no such bug already exists, the maintainer should file a bug
> against the appropriate package (toolchain or libc, perhaps),
> and immediately tag it as an arch blocker.
You can just reassign the bug and mark it as affecting an other
package. There is no need to have 2 bugs open for the same
problem.
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/20110831200319.gb25...@roeckx.be
Re: simple Debian package information in the wiki
First, to close the subject on debian-devel, I have sent this mail also to debian-mentors. please reply to debian-mentors. after this mail http://lists.debian.org/debian-devel/2011/08/msg00742.html I have put on the wiki some of my documentation about packaging. After some replies on debian-devel,I have rewritten the pages on the wiki to explain equivs-build. http://wiki.debian.org/Packaging/Minimal (for empty packages) http://wiki.debian.org/Packaging/Trivial (for package with files) You can also look at http://wiki.debian.org/Packaging I agree that http://wiki.debian.org/IntroDebianPackaging and the packaging-tutorial are good documentations. I work to attract people attention on them. I am still interested to have feed back on my modifications Thanks Henri Le Foll P.S. : please reply to debian-mentors. -- 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/4e5e765f.6090...@lefoll.eu
Re: Maintainers, porters, and burden of porting
On Tue, Aug 30, 2011 at 11:05:03AM +0200, Bernhard R. Link wrote: > > (And try to imagine how hard it would have been to introduce amd64 > if alpha had not elliminated in many years work most of the subtle > 64 bit bugs found in most software, I doubt porters alone could have > completed this in that time). We still found alot of those problems when amd64 was introduced, while we already had alpha and ia64 in the archive. But I can image how much worse it would have been without them. 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/20110831200847.gc25...@roeckx.be
Re: Maintainers, porters, and burden of porting
On 08/31/2011 01:45 PM, Charles Plessy wrote: > Le Wed, Aug 31, 2011 at 11:35:59AM +0200, Andreas Barth a écrit : >> * Lucas Nussbaum (lu...@lucas-nussbaum.net) [110831 10:56]: >>> Also, in the case of architectures targetted at embedded systems (I'm >>> thinking about mips and mipsel), what is important is that Debian >>> infrastructure supports the development of those architectures, but I >>> don't think that there's much to gain by being officially supported if >>> it's only used in production through derivatives that can provide the >>> official support. >> >> You are aware that there are mipsel netbooks? And arm tablets? > > In some previous discussion I was also pointed at 64-core mips workstations. > How many of these machines are running Debian ? > > I do not think that we can consider ports equally. The arm platform and the > armel port have some clear success. According to popcon, the user community > of > Debian on armel is constantly growing, and is aproximately 1 % of our ‘PC’ > (i386 and amd64) user community. Also, other distributions, for instance > Ubuntu, increase their committment for this platform. In comparison, the > usrerbase of the mipsel port stagnates to 0.05 % of our PC userbase. If there > were many Debian users of mipsel netbooks and workstations, why would they not > use Popcon, as the Debian users of armel computers do ? The mipsel port is used by the Lemote Notebooks/mini Desktops for example, which come pre-installed with Debian. Not sure if they have popcon enabled at all. And I guess mipsel is more a target for Embedian. No idea about usage statistics there, though. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- 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/4e5e9631.5020...@bzed.de
Re: Maintainers, porters, and burden of porting
On Wed, Aug 31, 2011 at 02:42:41PM +0200, Lucas Nussbaum wrote: > On 31/08/11 at 12:58 +0100, Ben Hutchings wrote: > > On Wed, 2011-08-31 at 11:57 +0200, Lucas Nussbaum wrote: > > [...] > > > But a different thread library that has clear POSIX compliance bugs[*] > > > is the kind of things that make me fear that many more packages than we > > > see currently are broken on kfreebsd. And I'm not sure that it's where > > > we want to spend our manpower. > > > > > > [*] due to linuxthreads: #639658 [kfreebsd] waitpid from a thread does > > > not work for child processes created by other threads. > > > there's also some signals+thread fun. > > > > Of course, Linux had those bugs for many years, so most multithreaded > > programs that run on Linux are probably tolerant of them. > > But Linux hasn't had them since many years too (NPTL in Debian: 2003), > so multithreaded programs that were written more recently might not be > so tolerant. If my memory is any good, amd64 was the first arch that was released with NPTL support. We decided to switch to NPTL directly and not support a 2.4 kernel, and didn't have LinuxThread support at all. But at that time we didn't release officially with Debian. But I think glibc build both the LinuxThreads and NPTL version, but you got the headers of LinuxThreads on all arches except amd64, and the NPTL headers on amd64. And Sarge was released like that. During etch we decided to completly drop the 2.4 kernel and some more arches switched to only use NPTL, and this started somewhere around 2006. Because amd64 switched to NPTL before any other arch we also saw alot of problems because some functions weren't available anymore or behaved differently. 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/20110831203638.gd25...@roeckx.be
ArtSkills Web Link Request
Hello, we have visited http://lists.debian.org/debian-user/2000/06/msg00062.html and think it is terrific. We believe your audience may benefit from knowing about us and our free online poster making resources. Who are we? We are ArtSkills, and we know everything about posters and poster making. Anyone who makes posters, assigns posters, or reads posters will benefit from visiting our fun, free and helpful site! This includes teachers, students, parents, cheerleaders, scout leaders, church group members, coaches, PTA members, sports and music fans, welcome committees, volunteers, cause organizers, anyone who wants to get a poster noticed! If you are interested please contact me directly or, I am providing you a look at our links page at http://www.artskills.com/link-to-us.html. We have already created all the ifnormation you need to start this exchange. I would just appreciate a reply letting me know if you are accepting this offer? Best regards, Craig Kuehner Digital Operations Manager ArtSkills www.artskills.com 1250 Braden Blvd. Suite 200 Easton, Pennsylvania 18040 -- 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/1AEAA88B081F1011032B03C078@CKUEHNER-7
Bug#639956: ITP: xc3sprog -- JTAG flashing tool for FPGAs, CPLDs, and EEPROMs
Package: wnpp Severity: wishlist Owner: Uwe Hermann * Package name: xc3sprog Version : r648 Upstream Author : Andrew Rogers, Uwe Bonnes, others * URL : http://sourceforge.net/projects/xc3sprog/ * License : GPL Programming Lang: C++ Description : JTAG flashing tool for FPGAs, CPLDs, and EEPROMs Programmer software for various FPGAs, CPLDs, and EEPROMs. Supported devices include: XC7*, XC6*, XC5*, XC3S*, XCF*, XC2*, XC95*, XC1*, AT90*, ATmega*, ATxmega*, AT91*, STM32*, and others. Uwe. -- http://hermann-uwe.de | http://sigrok.org http://randomprojects.org | http://unmaintained-free-software.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/20110831235209.GA2115@greenwood
creating init.d scripts
We have had a discussion about theoretical issues related to init.d scripts based on systemd and the possibility of making something like systemd configuration be the source for generating sysv scripts. Do we have anything that's usable for this now? I've got some rather shoddy init.d scripts to deal with and I'd like to do something good and easy if that's an option... -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ -- 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/201109011500.25453.russ...@coker.com.au
