Re: debootstrap and cdebootstrap vs systemd
On Fri, 7 Nov 2014, Adam Borowski wrote: > You can chroot to the system from the host machine, and upgrade to sysvinit. > If your host can't run arm code, install qemu-user-static and copy > /usr/bin/qemu-arm-static to the target system. This is no fix. There are systems Qemu does not emulate. debootstrap --include and --exclude should work. (I very vaguely recall getting angry at them at some point in the past too, and just resorting to $EXTRAPACKAGES in pbuilderrc instead, requiring cowbuilder --update right after cowbuilder --create, once or even twice, to get things to the right state. So they might not work ☹) bye, //mirabilos -- [16:04:33] bkix: "veni vidi violini" [16:04:45] bkix: "ich kam, sah und vergeigte"... -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.11.1411070958590.22...@tglase.lan.tarent.de
Re: debootstrap and cdebootstrap vs systemd
-Original Message- From: Cyril Brulebois To: Simon Richter Cc: debian-devel@lists.debian.org, debian-embed...@lists.debian.org, debootst...@packages.debian.org, cdebootst...@packages.debian.org Sent: Fri, 07 Nov 2014 10:45 Subject: Re: debootstrap and cdebootstrap vs systemd > You might want to stop accepting 2.6 as a base kernel version. Apologies in advance. You really hit a nerve here. Kernel 3.7 was released December 2012. Debian project created a dependency on this for the default init system roughly 15 months later. Which is fine, and perfectly understandable. It makes sense. I don't want to argue that. But please don't make light of the situation for those who can't apt-get install hardware-redesign beg-silicon-vendor-for-updates port-and-re-validate-custom-undocumented-modules go-back-in-time-and-teach-hardware-engineers-linux-kernel-lifecycle 3.7 is less than 2 years ago even today, apparently even that is a blip in many embedded hardware solutions' life-cycle. Some manufacturing sectors are still selling m68k and Z80 CPUs. For SoCs though, it seems the tradition is: fork a particular Linux kernel release, mangle it beyond recognition, throw it over the wall and then act like customers are speaking an alien language if they ever ask for updates. "Don't accept old kernels" is almost equivalent to telling many unrelated businesses in a particular ecosystem to burn their investments and start again from scratch, just because the SoC and/or board vendors have a broken business model. And that's hard to explain to business people and even hardware engineers that a chip/board/subsystem is "unsupported" even though supply guarantees stretch out to the year 2020 and beyond. And for all I know, perhaps these businesses deserve everything that happens to them, who knows.
Re: debootstrap and cdebootstrap vs systemd
For what it's worth, some of the boards I work with aren't emulated by QEMU either. However, for me that did not turn out to be a problem for chrooting into my alien rootfs just to run apt/dpkg & friends. Qemu only has to emulate a very minimal/"thin" CPU environment when chrooting with binfmts, just enough to support a few kernel syscalls to your host computer's native Linux kernel. I don't think qemu is doing any peripheral/memory-layout/IO etc emulation when used like this - those things (Eg. networking, file-system access) are provided by thin wrappers to the host system's kernel, kind of like WINE. On 07/11/14 20:00, Thorsten Glaser wrote: > On Fri, 7 Nov 2014, Adam Borowski wrote: > >> You can chroot to the system from the host machine, and upgrade to sysvinit. >> If your host can't run arm code, install qemu-user-static and copy >> /usr/bin/qemu-arm-static to the target system. > This is no fix. There are systems Qemu does not emulate. > debootstrap --include and --exclude should work. (I very > vaguely recall getting angry at them at some point in > the past too, and just resorting to $EXTRAPACKAGES in > pbuilderrc instead, requiring cowbuilder --update right > after cowbuilder --create, once or even twice, to get > things to the right state. So they might not work ☹) > > bye, > //mirabilos -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/545c96a2@yahoo.com.au
Re: debootstrap and cdebootstrap vs systemd
On Nov 07, csir...@yahoo.com.au wrote: > "Don't accept old kernels" is almost equivalent to telling many > unrelated businesses in a particular ecosystem to burn their > investments and start again from scratch, just because the SoC and/or > board vendors have a broken business model. And that's hard to explain > to business people and even hardware engineers that > a chip/board/subsystem is "unsupported" even though supply guarantees > stretch out to the year 2020 and beyond. Yes, your ecosystem is broken. That's your prerogative, but please do not pretend that Debian has to support it. -- ciao, Marco signature.asc Description: Digital signature
Re: debootstrap and cdebootstrap vs systemd
On 07/11/14 21:12, Marco d'Itri wrote: > Yes, your ecosystem is broken. That's your prerogative, but please do > not pretend that Debian has to support it. > Where did you hear me say Debian has to support it? I'm reacting to the whimsical suggestion that running a new kernel is just a matter of chioce. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/545ca22c.7060...@yahoo.com.au
Re: debootstrap and cdebootstrap vs systemd
On Fri, Nov 07, 2014 at 10:00:38AM +0100, Thorsten Glaser wrote: > On Fri, 7 Nov 2014, Adam Borowski wrote: > > > You can chroot to the system from the host machine, and upgrade to sysvinit. > > If your host can't run arm code, install qemu-user-static and copy > > /usr/bin/qemu-arm-static to the target system. > > This is no fix. There are systems Qemu does not emulate. But afaik all debian archs are? From the ports side qemu doesn't do hppa, and m68k and sparc64 are probably buggy. Nothing unfixable, just that nobody has cared enought to get them fixed :) And for not-even-in-ports architectures debootstrap is not really relevant. > debootstrap --include and --exclude should work. Yes of course. If not there could be a --variant=sysvinit, but clearly it should be possible to debootstrap without systemd. Riku -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141107104029.ga13...@afflict.kos.to
Re: debootstrap and cdebootstrap vs systemd
On Fri, Nov 07, 2014 at 08:30:32PM +1100, csir...@yahoo.com.au wrote: > "Don't accept old kernels" is almost equivalent to telling many > unrelated businesses in a particular ecosystem to burn their > investments and start again from scratch, just because the SoC and/or > board vendors have a broken business model. And that's hard to explain > to business people and even hardware engineers that a > chip/board/subsystem is "unsupported" even though supply guarantees > stretch out to the year 2020 and beyond. If you choose an old Soc vendor kernel, you effectively choose to use old userland from the same era. Better do your business plan based on it: "we won't upgrade userspace except for backported critical fixes and features we REALLY need" And it probably not that bad deal anyways. Instead wondering how to adapt your existing working code to new userland (say initscripts to systemd), your engineers can spend time working on something that actually matters to your customers. Riku -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141107111829.gb13...@afflict.kos.to
Re: debootstrap and cdebootstrap vs systemd
-Original Message- From: Riku Voipio To: csir...@yahoo.com.au Cc: debian-devel@lists.debian.org, debian-embed...@lists.debian.org Sent: Fri, 07 Nov 2014 22:36 Subject: Re: debootstrap and cdebootstrap vs systemd > If you choose an old Soc vendor kernel, you effectively choose to use old >userland from the same era. Better do your business plan based on it: > "we won't upgrade userspace except for backported critical fixes and > features we REALLY need" Thanks Riku, however what's best for my userland should be up to me to figure out. Thanks to the amazing emdebian toolchain, it's trivial to build my system for any supported debian release. The Debian ecosystem also makes it trivial to rebuild packages from source, for example to make headless or "nox" versions where necessary. Coupled with a completely automated, continuous build setup (from source for non-standard bits, including boot loader & kernel) I really enjoy developing for Debian! But the software I maintain, not to mention its supporting pieces, run in places other than embedded. Maintaining two release branches in light of the ease of building and maintaining sid userland isn't an obvious choice. Finally can I just re-iterate: these are not "old" or obscure SoCs; TI and freescale each have massive sales in CPU lines that don't have >3.0 kernels. The world's biggest Qseven COM vendor doesn't have an ARM board that supports >3.0 kernels. Even gumstix, popular in the open source scene, their newest boards don't have kernels >3.5.
customization of the kernel command line
Hello, I am preparing a package for a scientific camera andor3. This package contain a kernel module for the video grabber. >From the constructor documentation, I need to add the nopat option to the >linux command line. So I would like to know what is the proper way to customize this command line when installing the package. thanks Frederic -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/a2a20ec3b8560d408356cac2fc148e53b1fcb...@sun-dag3.synchrotron-soleil.fr
Re: customization of the kernel command line
HI, On Fri, Nov 07, 2014 at 01:11:51PM +, PICCA Frederic-Emmanuel wrote: > Hello, > > I am preparing a package for a scientific camera andor3. This package > contain a kernel module for the video grabber. > > >From the constructor documentation, I need to add the nopat option to > >the linux command line. > > So I would like to know what is the proper way to customize this > command line when installing the package. Documentation in /usr/share/doc//README.Debian :-) This is easy and safe. Please also read: https://www.debian.org/doc/debian-policy/ch-files.html#s10.7.3 https://www.debian.org/doc/debian-policy/ch-files.html#s10.7.4 Regards, Osamu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141107135242.GA28881@goofy.local
Re: debootstrap and cdebootstrap vs systemd
Le 07. 11. 14 13:32, csir...@yahoo.com.au a écrit : Finally can I just re-iterate: these are not "old" or obscure SoCs; TI and freescale each have massive sales in CPU lines that don't have >3.0 kernels. The world's biggest Qseven COM vendor doesn't have an ARM board that supports >3.0 kernels. Even gumstix, popular in the open source scene, their newest boards don't have kernels >3.5. Mainline kernel usually support all those chips just fine if the chip manufacturer upload his kernel patches to the mainline as it should do. If you take the risk to work with a chip manufacturer that don't upload his patches to the mainline kernel, then you have to assume this risk, not the distribution. I have experienced this situation many time. This was the standard 15 years ago, but now more and more chips manufacturers understand the importance of uploading there patches to the mainline kernel, so you have more choice in not falling into that bad situation. Jean-Christian -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/545ccc80.8000...@eclis.ch
Re: inconsistent versions of M-A: same packages
Hi Ralf, On Mittwoch, 5. November 2014, Ralf Treinen wrote: > yes, you did miss something :-) > first link on the page: "Non-installable packages" > https://qa.debian.org/dose/debcheck/unstable_main/index.html thanks! (+doh, I guessed I oversaw these links on the debcheck pages and then didnt find anything for the outdated and file-overwrite checks so I didnt check again. The bad weather in https://qa.debian.org/dose/debcheck/testing_main/index.html is still surprising to see, at this point... > 2) if you ask about co-installablity of packages with the same name but > different architectictures (and which are M-A=same) : this is a completely > different (and much more interesting) question. Since dose is now > multi-arch aware we can do this, but there are some questions to discuss > about the precise scenario. Is this what you meant ? yes, these are the interesting cases to discover (and fix)! cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: debootstrap and cdebootstrap vs systemd
On Fri, Nov 07, 2014 at 08:30:32PM +1100, csir...@yahoo.com.au wrote: > Apologies in advance. You really hit a nerve here. > > Kernel 3.7 was released December 2012. Debian project created a dependency on > this for the default init system roughly 15 months later. Which is fine, and > perfectly understandable. It makes sense. I don't want to argue that. Well I know wheezy runs fine on a 3.0 kernel. Not sure how much further back you can go. Of course that was as far as I can tell released Around August of 2011, so only another year and a bit longer. > But please don't make light of the situation for those who can't apt-get > install hardware-redesign beg-silicon-vendor-for-updates > port-and-re-validate-custom-undocumented-modules > go-back-in-time-and-teach-hardware-engineers-linux-kernel-lifecycle If udev decides to stop supporting kernels without some useful recent feature, do you expect Debian to keep patching to code to support older kernels that even Debian has no intention of using in new releases? What would be the point of that? > 3.7 is less than 2 years ago even today, apparently even that is a blip in > many embedded hardware solutions' life-cycle. Some manufacturing sectors are > still selling m68k and Z80 CPUs. For SoCs though, it seems the tradition is: > fork a particular Linux kernel release, mangle it beyond recognition, throw > it over the wall and then act like customers are speaking an alien language > if they ever ask for updates. > > "Don't accept old kernels" is almost equivalent to telling many unrelated > businesses in a particular ecosystem to burn their investments and start > again from scratch, just because the SoC and/or board vendors have a broken > business model. And that's hard to explain to business people and even > hardware engineers that a chip/board/subsystem is "unsupported" even though > supply guarantees stretch out to the year 2020 and beyond. Well if you don't try to explain it, you will be stuck with the problems forever. Where I work we make it clear to the suplier that support for the chip has to be mainlined to Linus's tree, or we don't want to deal with the chip. We know what it is like to deal with a vendor kernel that isn't maintained and we don't want to do that. We want nothing to do with SDKs or BSPs either. They are not useful for long term maintainance of a product. They are harmful. > And for all I know, perhaps these businesses deserve everything that happens > to them, who knows. Sounds fair to me. They are doing things wrong and hurting their customers. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141107145016.gr24...@csclub.uwaterloo.ca
Re: inconsistent versions of M-A: same packages
Hi Holger, Quoting Holger Levsen (2014-11-07 15:46:31) > On Mittwoch, 5. November 2014, Ralf Treinen wrote: > > yes, you did miss something :-) > > first link on the page: "Non-installable packages" > > https://qa.debian.org/dose/debcheck/unstable_main/index.html > > thanks! (+doh, I guessed I oversaw these links on the debcheck pages and then > didnt find anything for the outdated and file-overwrite checks so I didnt > check again. but was your original question not about debcheck checking for multiarch co-installability across architectures? I agree with Ralf, that this would best be done not by debcheck but by a small script which compares if the Packages files for all distributions ship M-A:same packages in the same version. > > 2) if you ask about co-installablity of packages with the same name but > > different architectictures (and which are M-A=same) : this is a completely > > different (and much more interesting) question. Since dose is now > > multi-arch aware we can do this, but there are some questions to discuss > > about the precise scenario. Is this what you meant ? > > yes, these are the interesting cases to discover (and fix)! One interesting scenario for which to detect co-installability problems is when it comes to satisfying crossbuild dependencies. The following page is regenerated daily: http://bootstrap.debian.net/cross.html I have new hardware now, so I plan to extend the set of source packages that I check for crossbuild dependency satisfaction. Furthermore, a current "problem" of debcheck is, that it will only tell you one reason for non-installability but for fixing problems like this it is useful to have more than one reason to be able to parallelize bugreports and to better estimate how many packages are blocked by a certain multiarch problem. I'm currently working on an enhanced dose-builddebcheck version which will provide this functionality and when it's done, the web page above will show those additional problems too. cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141107151612.6173.861@hoothoot
Re: inconsistent versions of M-A: same packages
Hi Johannes, On Freitag, 7. November 2014, Johannes Schauer wrote: > but was your original question not about debcheck checking for multiarch > co-installability across architectures? yes, this was just a btw-question on the side... > I agree with Ralf, that this would best be done not by debcheck but by a > small script which compares if the Packages files for all distributions > ship M-A:same packages in the same version. I'd happily run this script on jenkins.debian.net... if someone "gives it" to me ;-) > One interesting scenario for which to detect co-installability problems is > when it comes to satisfying crossbuild dependencies. > > The following page is regenerated daily: > > http://bootstrap.debian.net/cross.html cool, very nice! > I have new hardware now, so I plan to extend the set of source packages > that I check for crossbuild dependency satisfaction. not sure what ressources you need, but maybe jenkins.d.n can also help here? (or alternatively, jenkins can also be used to just notify about problems like the d-i_overview* jobs from https://jenkins.debian.net/view/d-i_misc/ do...) > Furthermore, a current "problem" of debcheck is, that it will only tell you > one reason for non-installability but for fixing problems like this it is > useful to have more than one reason to be able to parallelize bugreports > and to better estimate how many packages are blocked by a certain > multiarch problem. I'm currently working on an enhanced dose-builddebcheck > version which will provide this functionality and when it's done, the web > page above will show those additional problems too. neat! I'm looking forward to see this in action! :-) cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: inconsistent versions of M-A: same packages
Hi Holger, Quoting Holger Levsen (2014-11-07 16:31:09) > > I agree with Ralf, that this would best be done not by debcheck but by a > > small script which compares if the Packages files for all distributions > > ship M-A:same packages in the same version. > > I'd happily run this script on jenkins.debian.net... if someone "gives it" to > me ;-) is jenkins not triggered by pushes to git and thus sub-optimal for jobs that should be run like a cron job? I thought I'd run such a script on bootstrap.debian.net because that one has all Packages files for all architectures already and it would be trivial to run such a script in addition. But first I'd like to make sure what the interesting information would be. Would it be interesting to get the highest version of a binary package across all architectures and then check if that version exists in all architectures? Or would it be interesting to make sure that all versions exist across all architectures? (binary packages can exist in more than one version in unstable) botch currently ships the program botch-check-ma-same-versions which checks whether two Packages packages files agree on the M-A:same versions. Running it with amd64 and armhf unstable Packages files as input yields that all 25 version skews are due to binNMUs. I can extend the script to allow more than two Packages files as input and make the output machine readable. > > One interesting scenario for which to detect co-installability problems is > > when it comes to satisfying crossbuild dependencies. > > > > The following page is regenerated daily: > > > > http://bootstrap.debian.net/cross.html > > cool, very nice! > > > I have new hardware now, so I plan to extend the set of source packages > > that I check for crossbuild dependency satisfaction. > > not sure what ressources you need, but maybe jenkins.d.n can also help here? > (or alternatively, jenkins can also be used to just notify about problems > like > the d-i_overview* jobs from https://jenkins.debian.net/view/d-i_misc/ do...) Gladly, dose3 is very fast and even checking the whole archive doesn't take more than 3 minutes :) The problem before was, that I was running the script on a shared server with *very* limited resource constraints. But thanks for the offer! cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141107154739.6173.88256@hoothoot
Bug#768471: ITP: pk-update-icon -- Displays an update-notification tray icon
Package: wnpp Severity: wishlist Owner: Matthias Klumpp * Package name: pk-update-icon Version : 1.0.0 Upstream Author : Guido Berhoerster * URL : https://code.guido-berhoerster.org/projects/pk-update-icon/ * License : GPL-2.0+ Programming Lang: C Description : Displays an update-notification tray icon pk-update-icon displays notifications and an icon in the tray area of the panel when package updates are available. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141107154919.4773.2484.reportbug@sirius
Re: Time for compassion and the Init GR
Sam Hartman dijo [Thu, Nov 06, 2014 at 09:58:29AM +]: > > Early morning, Wednesday, November 19, the results of the GR on init > system coupling will be announced. > No result will make everyone happy. In fact, that morning, some of our > developers, users and contributors will be really unhappy. > > I would be dishonest if I said I didn't hope to be happy and reassured that > morning. I suspect we all hope that the project will agree with our > position on this complex and emotionally intense issue and reassure us > that our values are close to those of the project; reassure us that > this is a place where we can safely work together. > (...) Thanks, Sam, for this well-worded, well-thought and throughout mail that summarizes perfectly what I'd love to be able to state. The social component of Debian is core to the project. Not only to the project's identity, but it also explains its functioning, and to a certain degree, its permanence for over twenty years. At several points in time, we have passed through periods of harsh discussions such as this one (I don't remember any being as bitter or long-lasting), and we must take care not to see it become greater than ourselves. signature.asc Description: Digital signature
Bad weather in testing ? (was: Re: inconsistent versions of M-A: same packages)
Hi Holger, (repliying separately to the two pointes raised by you) On Fri, Nov 07, 2014 at 02:46:31PM +, Holger Levsen wrote: > On Mittwoch, 5. November 2014, Ralf Treinen wrote: > > yes, you did miss something :-) > > first link on the page: "Non-installable packages" > > https://qa.debian.org/dose/debcheck/unstable_main/index.html > > thanks! (+doh, I guessed I oversaw these links on the debcheck pages and then > didnt find anything for the outdated and file-overwrite checks so I didnt > check again. > > The bad weather in > https://qa.debian.org/dose/debcheck/testing_main/index.html > is still surprising to see, at this point... not at all ! The weather icons are a bit misleading (this is one reason why I wasn't such a big fan of these), one has to look at the figures. "Storm" is indicated for the "some" category, that is packages that are not installable on *some* architecture. There are 1449 of these, but 1440 of them are architecture=all, and only 9 of them are architecture-specific. The issue of architecture=all packages that are not installable on some architecture can IMHO not be solved with our current setup which makes architectures=all available on every architecture. There is only one package in the "each" category, and this is a false positive due to multiarch: lib32nss-mdns, which exists only on amd64 (this is why it shows up in the each category) and depends on an i386 package, which is deliberate in this case. -Ralf. -- Ralf Treinen Laboratoire Preuves, Programmes et Systèmes Université Paris Diderot, Paris, France. http://www.pps.univ-paris-diderot.fr/~treinen/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141107161504.ge9...@vanadium.pps.jussieu.fr
Re: inconsistent versions of M-A: same packages
On Fri, Nov 07, 2014 at 02:46:31PM +, Holger Levsen wrote: > > 2) if you ask about co-installablity of packages with the same name but > > different architectictures (and which are M-A=same) : this is a completely > > different (and much more interesting) question. Since dose is now > > multi-arch aware we can do this, but there are some questions to discuss > > about the precise scenario. Is this what you meant ? > > yes, these are the interesting cases to discover (and fix)! It just appeared to me that we probably do not have a syntax to pinpoint a package built for a specific architecture. "We" meaning in this case dpkg, apt, and dose (if I am not mistaken). The usual trick in dose would be, for all package names that exist on multiple architectures and that are M-A=same, to create a pseudo package like this: Package: p-multi Depends: amd64:p, i386:p and then to check installability of all these pseudo packages against a background of all the real Packages files. However, dose does currently not allow this syntax in dependencies, nor does dpkg TTBOMK. Internally, dose already identifies packages by a triple (architecture,name,version), so it should be only a question of extending the input language. Once we can teach dose to accept the pseudo packages as described above we could run it with all the Packages files for all archiectures, which makes roughly 500.000 packages. This will be stress test for dose, but is seems to me doable. However, dose-debcheck also requires the specification of --deb-native-arch in cases where it cannot be obtained by looking at the input file. This is necessary since, according the the MultiArch specification, architecture=all packages are considered to be of the native architecture. This means that we have to run our check for all possible values of --deb-native-arch, and this starts to be quite expensive. For this reason we should probably limit ourselves to all the interesting cases of combinations of native and foreign architectures. The only reasonable combination that I can currently think of is native-arch: amd64 foreign-archs: i386 Are there are any other useful combinations ? Maybe in the arm world? -Ralf. -- Ralf Treinen Laboratoire Preuves, Programmes et Systèmes Université Paris Diderot, Paris, France. http://www.pps.univ-paris-diderot.fr/~treinen/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141107163506.gf9...@vanadium.pps.jussieu.fr
Re: Bad weather in testing ?
On 07/11/14 16:15, Ralf Treinen wrote: > There is only one package in the "each" category, and this is a false > positive due to multiarch: lib32nss-mdns, which exists only on amd64 > (this is why it shows up in the each category) and depends on an i386 > package, which is deliberate in this case. That's a transitional hack, and I intend to get rid of it in jessie+1. I think it's OK that QA tools complain about it. (I'm surprised the wine* family of packages don't get similar results though - that's where I stole the idea from.) s -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/545d0b61.7020...@debian.org
Re: inconsistent versions of M-A: same packages
+++ Ralf Treinen [2014-11-07 17:35 +0100]: > On Fri, Nov 07, 2014 at 02:46:31PM +, Holger Levsen wrote: > > For this reason we should probably limit ourselves to all the interesting > cases of combinations of native and foreign architectures. The only > reasonable combination that I can currently think of is > > native-arch: amd64 > foreign-archs: i386 > > Are there are any other useful combinations ? Maybe in the arm world? For cross-building there are lots of useful combinations. Many combinations are interesting but currently native is usually amd64, sometimes i386, soon other arches like arm64 and ppc64el might become more popular as native build host: native-arch: amd64 foreign-archs: , could sometimes be a list like 'armel armhf', 'powerpc ppc64el' For general runtime multiarch use I've found native-arch: arm64 foreign-arch: armhf useful recently (for using armhf packages in bootstrapping when arm64 ones were not yet available/working) Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141107183329.gs28...@stoneboat.aleph1.co.uk
so long and thanks for all the fish
It's become abundantly clear that this is no longer the project I originally joined in 1996. We've made some good things, and I wish everyone well, but I'm out. Note that this also constitutes an orphaning as upstream of debhelper, alien, dpkg-repack, and debmirror. I will be making final orphaning uploads of other packages that are not team maintained, over the next couple of days, as bandwidth allows. If I have one regret from my 18 years in Debian, it's that when the Debian constitution was originally proposed, despite seeing it as dubious, I neglected to speak out against it. It's clear to me now that it's a toxic document, that has slowly but surely led Debian in very unhealthy directions. -- see shy jo signature.asc Description: Digital signature
Re: so long and thanks for all the fish
Hi, 2014-11-07 22:04 GMT+01:00 Joey Hess : > It's become abundantly clear that this is no longer the project I > originally joined in 1996. We've made some good things, and I wish > everyone well, but I'm out. > > Note that this also constitutes an orphaning as upstream of > debhelper, alien, dpkg-repack, and debmirror. > > I will be making final orphaning uploads of other packages that are not > team maintained, over the next couple of days, as bandwidth allows. > > If I have one regret from my 18 years in Debian, it's that when the > Debian constitution was originally proposed, despite seeing it as > dubious, I neglected to speak out against it. It's clear to me > now that it's a toxic document, that has slowly but surely led Debian > in very unhealthy directions. I don't know you, but I taking part of Debian since potato. All I can say is: :/ Debian needs all passion it can get and it is sad that this project can consume so much until someone can not provide more. This - I guess - it the matter of responsibility and pushing it too far ... maybe. So all what is left to say: good luck and have fun. Be blessed :) Greetings, Björn PS: Oh, before I forget ... a last ><*> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cagmps55addt61za5hxphntv69qjutl5qjulgnyzkk7yfbhm...@mail.gmail.com
Re: so long and thanks for all the fish
On Nov 07, Joey Hess wrote: > It's become abundantly clear that this is no longer the project I > originally joined in 1996. We've made some good things, and I wish > everyone well, but I'm out. Well, this sucks. -- ciao, Marco signature.asc Description: Digital signature
Re: debootstrap and cdebootstrap vs systemd
On Fri, Nov 07, 2014 at 12:40:29PM +0200, Riku Voipio wrote: > > debootstrap --include and --exclude should work. > > Yes of course. If not there could be a --variant=sysvinit, but clearly > it should be possible to debootstrap without systemd. I'd say every --variant except the default should have no systemd. No init at all would be better, but excluding an essential package (init) makes dist-upgrades not fun. * minbase Not suitable for booting without further work. * buildd Init is not needed, bloat is highly harmful (unpacking the chroot without CoW takes 5x the time to build a small package!), so a slim init like sysvinit is much preferred. * fakechroot|scratchbox Not meant/capable of booting on their own (chroot only). -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141107212503.ga14...@angband.pl
Re: so long and thanks for all the fish
On Fri, Nov 07, 2014 at 05:04:10PM -0400, Joey Hess wrote: > It's become abundantly clear that this is no longer the project I > originally joined in 1996. We've made some good things, and I wish > everyone well, but I'm out. > > Note that this also constitutes an orphaning as upstream of > debhelper, alien, dpkg-repack, and debmirror. Aww, and I postponed harassing you about a new dh_ script I'd want until after the freeze frenzy goes down... :/ Thanks for all your good work! -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141107214921.gb14...@angband.pl
Re: so long and thanks for all the fish
Joey Hess writes: > It's become abundantly clear that this is no longer the project I > originally joined in 1996. We've made some good things, and I wish > everyone well, but I'm out. I'm gutted. > If I have one regret from my 18 years in Debian, it's that when the > Debian constitution was originally proposed, despite seeing it as > dubious, I neglected to speak out against it. It's clear to me > now that it's a toxic document, that has slowly but surely led Debian > in very unhealthy directions. You're not wrong. It's always been fun working with you -- Good luck with your next enthusiasm :-) Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY pgp5F2kYd9_yZ.pgp Description: PGP signature
Re: so long and thanks for all the fish
Joey Hess wrote: > It's become abundantly clear that this is no longer the project I > originally joined in 1996. We've made some good things, and I wish > everyone well, but I'm out. (Insert record-scratch sound-effect and sounds of brain rebooting here.) Thank you deeply for your work. It saddens me no end to see Debian drive away one of its most valuable contributors and long-standing fixtures. Between debhelper and d-i, I can think of few if any Debian developers who have had as significant an impact as you have. You will be missed. - Josh Triplett -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014110702.GA4347@jtriplet-mobl1
Re: so long and thanks for all the fish
Hi Joey, among all the Debian developers you have been one of the most inspiring to me. I hope that you will keep your blog syndicated on planet.debian.org ! Cheers, -- Charles Plessy 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: https://lists.debian.org/20141107223551.gd31...@falafel.plessy.net
Re: so long and thanks for all the fish
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 In advance sorry for all spelling mistake that I will write as I am writing from my phone and I am not a native English speaker. I am emotionally crushed by this. You are one of two DD's I interviewed for our LUG in Banja Luka, shortly after conference. You were among first people I saw when I came early in morning to Vaumarcus. You're by your contributions to Debian already a legendary DD. Stories are told among Free software users about you and your life. I want to say to you no, no, no. Don't leave the project for which you and many other will become like grandparents in another 18 years. You, bdale, vorlon, moray, holger and other long time Debian people should be there, become Debian Oldmen that will pass stories on DebConfs about our community project early days and its rise to glory. Please, for a day, sit down and consider all of us who care for well-being of Debian community, who care on personal level a lot. If you can do that, please do. Speaking of community, I know my voice is yet small, but I think many have expressed and agree that we look more complicated then government structures. We really need to change this because its killing the community feeling and its draining energy from our members. I mean whats next in this sad show? We are going to loose mbiebel, gunnar, zack? Am I going to come to are DebConf where bdale and keithp will not be there to talk about rockets? Where zack will not educate us about Free software? Where holger will not be there to help video team? I am sorry if I sound silly but its hard to see people leave because they got emotionally burned out. I love to see bubulle posting his love for running or looking at enrico's talks because his funny ways of presenting is cheering me up in sucky days. Heck I could say some unique thing for every single person. I just want the warm community feel back where we do not need some special technical process to reach some consensus but a nice talks between friends because we are afterall friends here. A family. So, please, lets care for each other and do a handshaking and hugging as a consensus for everything. With love, zlatan P.S. I didn't get chance to harass paultag in Portland and if he leaves the project I am leaving Earth P.P.S. Joey, if you in the end really leave - I wish you good luck in all you do On 7 November 2014 22:04:10 CET, Joey Hess wrote: >It's become abundantly clear that this is no longer the project I >originally joined in 1996. We've made some good things, and I wish >everyone well, but I'm out. > >Note that this also constitutes an orphaning as upstream of >debhelper, alien, dpkg-repack, and debmirror. > >I will be making final orphaning uploads of other packages that are not >team maintained, over the next couple of days, as bandwidth allows. > >If I have one regret from my 18 years in Debian, it's that when the >Debian constitution was originally proposed, despite seeing it as >dubious, I neglected to speak out against it. It's clear to me >now that it's a toxic document, that has slowly but surely led Debian >in very unhealthy directions. > >-- >see shy jo - -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -BEGIN PGP SIGNATURE- Version: APG v1.0.9 iQJSBAEBCAA8BQJUXUuKNRxabGF0YW4gVG9kb3JpYyAoRGViaWFuZXIpIDx6bGF0 YW4udG9kb3JpY0BnbWFpbC5jb20+AAoJEC5cILs3kzv9pAYQAJHEYPBvZblk1WNo LyxAt9gFvCkzZ+PXjbv9QNkZwZlxhuQOOIPbnjKPQgtdrP8F6Qsigw5l3RR4ddNG R35GCku07dmaxQQeKCF44rPxhnZ8AELQJHyGKQWlxfmACPmUd+/7U4+V7FrcL+S9 i39GPulo9NSqikhQO8aV1eFJjnQW5zpdo49+66r/wkqH7Y9ps4+O3lcb7VdOOjg4 p0s23oiDEtfwhV5PP3HXN24U17fRRt6Z0oZTlcLOszWNACrYGwn32Bqk9CYdNqvx ClH4n91kx6Ud8WfhzknFW37w8MCddMWhvBZajmHNsqaEpZ6v3SHea+weAWpRuGmX MdTnB/QtG+xCL8eJ8chFzM2SCIXgYsUM40Qo09a/2zvtvVYZjN8hxi2rBxJLn75p nzzFnh3AbG0QBdM78Z87vmN6u7Kp2lDNDwZbenB4CRoZGNbnN0tbrEpWyboQ1ujV 9b0Dv1F9GngODP2hkW2Ni/FgVz1Opadmf5+S2f7E656LkUuKSAqSq/U2RlfxkATP LaE9juMQLVK8inVZ5Bkqs1EzDvhy8w4KyZzTiKFbZoHvIK2mMV87K6JmYXq2Eyk6 canZjU5lPu9OIGUD11AMlkGUnw7e/usKN95kO631PhKv1MYNmPEoKTJrIrved+fW 8rJ6tT2ebAyMwGjW584f6onhDq+u =/mWq -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: https://lists.debian.org/c6e80a23-650d-4a0d-8dd0-7576be5df...@riseup.net
Bug#768508: ITP: gitinspector -- statistical analysis tool for git repositories
Package: wnpp Severity: wishlist Owner: Christian Kastner * Package name: gitinspector Version : 0.3.2 Upstream Author : Ejwa Software * URL : http://code.google.com/p/gitinspector/ * License : GPL-3+ Programming Lang: Python Description : statistical analysis tool for git repositories gitinspector is a statistical analysis tool for git repositories. It creates informative and visually appealling reports in various output formats. Its features include: * Shows cumulative work by each author in the history * Filters results by extension * Can display a statistical timeline analysis * Scans for all filetypes (by extension) found in the repository * Multi-threaded; uses multiple instances of git to speed up analysis * Supports HTML, XML and plain text (terminal) output -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/E1XmsYL-R0-Mj@pequod.7s
Re: so long and thanks for all the fish
Joey Hess writes: > It's become abundantly clear that this is no longer the project I > originally joined in 1996. We've made some good things, and I wish > everyone well, but I'm out. Thank you. You've been a model Debian member to many of us, and I will miss your inspiration and clear-headedness. -- \ “Pinky, are you pondering what I'm pondering?” “I think so, | `\Brain, but if we get Sam Spade, we'll never have any puppies.” | _o__) —_Pinky and The Brain_ | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85mw824lwk@benfinney.id.au
Re: customization of the kernel command line
On Fri, 2014-11-07 at 13:11 +, PICCA Frederic-Emmanuel wrote: > Hello, > > I am preparing a package for a scientific camera andor3. > This package contain a kernel module for the video grabber. > > >From the constructor documentation, I need to add the nopat option to > the linux command line. > > So I would like to know what is the proper way to customize this > command line when installing the package. There is no system for doing this, and even if there was I would consider it a bug for a package in Debian to append a workaround parameter like 'nopat'. Can't you try to fix the driver? Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Re: so long and thanks for all the fish
On Fri, 2014-11-07 at 17:04 -0400, Joey Hess wrote: > but I'm out. Wow what saddening news :-( It's really a pity to good ones leaving... hope you'd reconsider your decision and come back after some break perhaps! If not, all the best and thanks. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: debian-devel-digest Digest V2014 #806
On 11/07/2014 05:07 PM, debian-devel-digest-requ...@lists.debian.org wrote: Subject: so long and thanks for all the fish From: Joey Hess Date: 11/07/2014 04:04 PM To: debian-devel@lists.debian.org It's become abundantly clear that this is no longer the project I originally joined in 1996. We've made some good things, and I wish everyone well, but I'm out. Note that this also constitutes an orphaning as upstream of debhelper, alien, dpkg-repack, and debmirror. I will be making final orphaning uploads of other packages that are not team maintained, over the next couple of days, as bandwidth allows. If I have one regret from my 18 years in Debian, it's that when the Debian constitution was originally proposed, despite seeing it as dubious, I neglected to speak out against it. It's clear to me now that it's a toxic document, that has slowly but surely led Debian in very unhealthy directions. -- see shy jo Debian without Joey Hess ain't Debian. But good luck and I hope you're still involved somewhere!
Re: so long and thanks for all the fish
Ew. I've always thought you have been providing Debian with very sensible thoughts and guiding. Your wisdom will be missed. Wishing you the best. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141108012909.go3...@type.youpi.perso.aquilenet.fr
Bug#768523: ITP: r-omegahat-xmlrpc -- GNU R package for RPC over XML
Package: wnpp Owner: Dirk Eddelbuettel Severity: wishlist * Package name: r-omegahat-xmlrpc Version : 0.3-0 Upstream Author : Duncan Temple Lang * URL or Web page : http://www.omegahat.org/XMLRPC/ * License : BSD Description : GNU R package for RPC over XML This (tiny) package is a (Build-)-Depends of (r-cran-)rneos which itself is now a (Build-)Depends of (r-cran-)fportfolio which has been in Debian for close to a decade. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/8761eqs80b@max.nulle.part
Re: inconsistent versions of M-A: same packages
UDD can help with this. A list of source packages that have M-A: same binary packages in jessie that have different versions in any two release architectures is at: http://debian.nanonanonano.net/qa/maskew There are currently 247 source packages in that list (assuming I've not done something very silly in that SQL). The list is generated by a very brief script in: http://debian.nanonanonano.net/qa/macheck While I'm currently running that from cron on that box, this would be better run on udd.d.o or qa.d.o, dropping the output in a suitable place. It's quite feasible to extend that script to prepare a list of version→arch mappings for each source package. cheers Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/m3kab7$15v$1...@ger.gmane.org
Re: inconsistent versions of M-A: same packages
Hi, Quoting Ralf Treinen (2014-11-07 17:35:06) > It just appeared to me that we probably do not have a syntax to pinpoint a > package built for a specific architecture. "We" meaning in this case dpkg, > apt, and dose (if I am not mistaken). No. We do have it. > The usual trick in dose would be, for all package names that exist on > multiple architectures and that are M-A=same, to create a pseudo package like > this: > > Package: p-multi > Depends: amd64:p, i386:p > > and then to check installability of all these pseudo packages against a > background of all the real Packages files. If the above is a Debian Packages file, then it must be the other way round. First the name and then the architecture. Dose3 internally does the encoding the other way round which is very confusing because it exposes this in its yaml output. If you wanted to write a cudf file, then your example is correct except that your ":" must be encoded as "%3a". > However, dose does currently not allow this syntax in dependencies, nor does > dpkg TTBOMK. Dose distcheck does not allow it but dose buildcheck does. This is probably a bug in the distcheck frontend. Dpkg and apt allow this just fine. Try to do: apt-get install --simulate gcc-4.9-arm-linux-gnueabihf And you will end up with a number of armhf packages on your system (you have to enable armhf beforehand of course). > Internally, dose already identifies packages by a triple > (architecture,name,version), so it should be only a question of extending the > input language. > > Once we can teach dose to accept the pseudo packages as described above we > could run it with all the Packages files for all archiectures, which makes > roughly 500.000 packages. This might fail not only because of M-A:same conflicts but also because some packages just conflict with each other through a normal Conflicts:. You probably need a clever way to partition dependencies. cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141108054124.6173.66236@hoothoot
