[[!meta copyright="Copyright © 2010, 2011, 2013, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] I'd be quite helpful to have nightly builds in form of Debian `.deb` packages. * (german) * Need to have an automation to get from Hurd upstream Git branches to a branch usable in Debian. IRC, freenode, #hurd, 2013-12-18: http://darnassus.sceen.net/~teythoon/hurd-ci/ has hurd and mig and gnumach packages built directly from the upstream git repository --- There is infrastructure available to test whole OS installations. * --- [[service_solahart_jakarta_selatan__082122541663/Debian_cross_toolchain]] for cross-building? --- See also [[nightly_builds]]. # Debian Jenkins Instance ## IRC, OFTC, #debian-hurd, 2014-02-24 hi. can hurd be installed using d-i? If so, what about scripting the installation on ? pere: d-i works for Hurd, yes, with full graphical interface I dunno. Maybe you can ask about scripting in #hurd, more people are present there? gnu_srs: the scripts in questions are for jenkins. quite easy to write (d-i preseed scripts and qemu boot rules). ## IRC, OFTC, #debian-hurd, 2014-02-25 getting a automated test in jenkins running could show the status. what is needed to boot the hurd d-i image with a preseed file using qemu? git://git.debian.org/git/users/holger/jenkins.debian.net.git is the repo with the jenkins build rules. youpi: is it possible to start the hurd d-i installer with a preseed file from the qemu command line? --append need --kernel, which I suspect do not make sense with hurd? can the d-i hurd installer take a preseed file at all? my initial try failed. :( i don't know there has been talk here the other day about using qemus multiboot capabilities to directly boot the hurd [[hurd/running/qemu#multiboot]]. For d-i purposes, you'll additionally need: $ wget http://people.debian.org/~sthibault/hurd-i386/installer/cdimage/current/initrd.gz ..., and to the `--initrd` option prepend `'initrd.gz $(ramdisk-create)',` before the `ext2fs.static`, and refer the latter to `gunzip:device:rd0` instead of `device:hd0s1`. I tried adding an url= option to grub when booting the installer, but it seem to be ignored. perhaps the preseed udeb is missing, or the network support was enabled after preseed looked for the file? uh, i don't know about that stuff, youpi creates the d-i images ok. seem to me that the d-i images do not support preseeding at the moment. youpi: ^ did you succeed? if so, can you share how? teythoon: nope, I concluded it didn't work, and left it to other to fix. :) pere, teythoon: IIRC preseeding can be put on the gnumach kernel command line but I'm wondering why you can't simply modify the disk image into doing what you want or you mean reinstalling the image each time? youpi: the point is testing the installer, and that can only be done by using the installer. :) ok I would like to see something like for hurd. ## IRC, OFTC, #debian-hurd, 2014-02-26 * gg0 setting up jenkins, almost time to give up gg0: why do you set up jenkins? because i want to fail at doing all things, not just something ;) oops seems my setup just sent emails to jenkins+debian-qa holger@layer-acht.org :/ #debian-qa will understand. :) ## IRC, OFTC, #debian-hurd, 2014-02-28 gg0: are you able to feed the installer one of the preseed files at ? though jenking translates double quotes, need to escape the world debian_sid_daily_lxde_preseed.cfg seem like a good candiate. :) pere: i'm working on that, stuck at working around that mandatory double quote *initrd double quote ok got a g-i-installation_debian_sid_daily_hurd_lxde able to boot let's provide a preseed shouldn't there be some info/debug consoles from tty 2 to 4? there should be maybe i can't send alt+NUM from vlc ah, yes you need to use the menu for that press f8 great (found out C+A+{1,2,3} give interesting monitor,serial,parallel consoles btw) not much options on menu just clipboard management, quit, full screen, send ctrl-alt-del, send F8 * gg0 takes "great" back i guess it depends on vnc implementation don't ask me how i found out one can switch console with ... left/right arrow keys without alt pressed? without alt pressed I've already seen that with qemu, when focusing into/out from the qemu window by using alt somehow the alt state gets stuck so you mean if i close viewer then reattach it, it doesn't happen anymore? let's see you're right though yes alt+left/right switches consoles the last is expected :) it says kbd-udeb doesn't exist so it falls back to hurd-debian-ports-udeb that's not a problem no partman-auto? it should be working i meant if it was installed but yes it gets it along with others ## IRC, OFTC, #debian-hurd, 2014-03-01 partman-auto would need to be patched to be able to discover available disks worked around by forcing /dev/hd1, jenkins creates disk with index=1 stuck at installation-report installed. seems it can't manage to umount(then remount) /cdrom gracefully or better it gets stuck at apt-cdrom ident something like https://bugs.debian.org/598457 ## IRC, OFTC, #debian-hurd, 2014-03-02 youpi: any chance to have monthly/weekly (daily would be too much i guess) isos/images? can i help somehow? I am wondering why having that since we have up-to-date mirrors i'd say to install with latest installer/gnumach/hurd/eglibc so that means also rebuilding the d-i image and in general to not have to manually produce them youpi: the point is to automatically test the current images using jenkins.debian.net, I believe. for that to work, current images need to exist. :) not only. i think saving youpi's time is also important gg0: it doesn't really take me much time to generate images it's about a few command lines to start, and then work on something else :) well though it still requires manual intervention which is not scheduled and also error prone btw gg0: I guess the most important help you could provide would be to actually track when the autobuild breaks :) what pros keeping it manual? i don't think disk space saving it's not really a question of manual, but the frequency I prefer to test manually before uploading something on my somehow-official directory on people, anyway but that doesn't mean we can't have weekly builds somewhere else indeed it's just that for tests it's good to have several images backlog, but then it takes disk well we could keeping "official" ones + say 6 monthly and say 4 weekly * gg0 randomizes retention -ing gg0: check out my hurdtest program it updates qemu images automatically, and runs a test suite, creates snapshots youpi: you'd just take actually care of official ones and it can zero-fill the disk images to compact them for publication gg0: and have a cron for the others on mirror.ftp-master nice, we already have a disk image generator then i shall clean it up and merge stuff that i have changed locally i covered it in my early blog posts i use it extensively to test the packages from hurd-ci great. so usually at this point /me can't do anything so good work! lol crontabs are in place, scheduled on monday mornings I have already completed a run, can be seen in weekly-0 great! assuming it will work forever without maintenance, how many minutes you'll save per month? :) I don't think that'll save me time per month since it's just an additional thing youpi: so weekly-0 will always be the latest weekly (same about monthly) ? yes how about adding -YYYYMMDD after -1 CD/DVD/NETINST number? that'd mean more scripting just to distinguish them we already have timestamps from the server unfortunately i can't script myself, i can suggest though :) or scripts are available somewhere? so current/ should be a link to weekly-0? on mirror.ftp-master.debian.org, but I guess you don't have access to it no definitely no the point of current/ is to have something tested ok while weekly/monthly are most probably to get broken so let's not point people at that same story about diskimage? how do you generate them? how about teythoon's way? I do it by hand at the moment, but scripts would be welcome indeed http://people.debian.org/~sthibault/hurd-i386/debian-hurd.img.txt ok now stuck at grub install ## IRC, OFTC, #debian-hurd, 2014-03-03 i probably should force /dev/hd0 as i did for /dev/hd0s1 as root device if it's possible what do you mean by forcing /dev/hd0s1 as root device ? you shouldn't have to do that my fear is that these additional images will mostly just bring additionnal reports i had to specify it in preseed which won't really decrease the amount of work as partman-auto/disk it can recognize available disks that's also because it can't list root partitions on rescue mode well, all I can say without having (again) to spend time on it, is that you're not supposed to have to do that why are you using rescue mode? if it can't list root partitions, then of course partman can't work well, rescue mode should work if you delve into non-tested parts of d-i, you'll surely encounter bugs well, less "should" than plain "d-i" in that I've never really tested it so don't be surprised that some bugs remain no problem but again, we don't really need more bug reports but rather bug fixing we already have enough to fix, no need to delve into advanced things sure, i'm just trying to make it work with all its limitations it autopartition the disk well, it can't just make one choose among disks because it can't probe and list them then fix the probe & list i'd like doing it, i'm better at working around for now though :) one blocker is mount/umount stuff [[glibc#mount]]. well, you'll have to get into fixing bugs for real someday otherwise this is just adding to TODO lists what mount/umount stuff? (took a quick look at partconf) non-existent mount.h for instance do we have replacements? not that I know of 21:53 < teythoon> gnu_srs1: i put a small hacks entry in the list about moving the mount/umount functionality from our utilities to the libc ok another thing i'd really like to see would be a physical shutdown, halt-hurd which actually poweroffs the system how to switch to sysvinit by default? next sysvinit upload? physical shutdown means implementing APM or ACPI have to teach jenkins it can shut it down :/ I'm extremely far from having the will for this switching to sysvinit by default is a matter of saying that we want to do it I already asked for this on the list without answer IIRC i can't find anything anyway, just propose on the list d-i grub-installer/bootdev string /dev/hd0 - here it is next run should not need any interaction, though it needs 20 mins to understand it has to destroy it and run won't be successful :/ due to missing acpi/apm first graphical automated install http://postimg.org/image/vgagj06q7/ it seems 720x400 though jenkins passes video=vesa:ywrap,mtrr vga=788 by reconnecting it switched to 800x600 http://postimg.org/image/h32qjykrx/ but seems stuck now and i can't even switch from graphical to consoles unusually stuck at scanning cdrom i'll check text install to see if it gets stuck there too text install switches from 720x400 to 640x400 i confirm it gets stuck on scanning cdrom, i guess because of this one https://bugs.debian.org/728153 which already broke load-install-cd i already had to workaround gg0: are you in contact with h01ger to update jenkins.debian.net with your cool installation code? pere: still trying to have something working plus with new weekly cd, apt-cdrom bug makes install getting stuck at first Scanning cdrom: 03:44 < gg0> i confirm it gets stuck on scanning cdrom, i guess because of this one https://bugs.debian.org/728153 which already broke load-install-cd i already had to workaround do we really need the CD-1 image in weekly builds? just netinst? yes well, i don't know debian installer well. what's the difference between CD and NETINST besides that CD has more packages user doesn't need to download? has CD anything not in NETINST which is worth to continously test? (talking about jenkins) that's only it, yes btw new ACPI on hurd consists of serial console to file + looping grep "In tight loop: hit ctl-alt-del to reboot" && kill qemu anything better? filed http://bugs.debian.org/740673 without a patch just to express my great laziness :p well, I'm afraid nobody in the debian-boot team will attempt anything at this is it reproducible on linux? nope my guess is that's due to udev, need a deeper check btw i mean non-udev cases like hurd maybe are not handled well maybe try on kfreebsd then? just guessing * gg0 trying on kfreebsd ## IRC, OFTC, #debian-hurd, 2014-03-04 hurd install started getting stuck running os-prober, final grub install phase youpi: yes i confirm it affects kfreebsd too then please say so in the bug otherwise most probably but me in the debian-boot team will care +nobody that might get more attention from d-boot team? ok also Cc debian-bsd@ they will care and tell about the hint as being the non-udev case too much information or ideas is never a bad thing :) done (now i know notfound does remove found versions instead of adding notfound versions) crazy things. to unblock os-prober i had to settrans -fg /target/media/./cdrom0 it was mounting /dev/hd0s1 ... i suspect apt-cdrom is to blame again ok now jenkins just managed to start the installed system and it's configured to make vncdo testing it i'd need a graphical-working cd with old-apt to continue let's try to install old apt on weekly-0 "cdrom drive contains a cd which cannot be used for installation" i think a sort of non-authenticated anymore ehm.. http://paste.debian.net/plain/85224/ gg0: nice. :) with apt 0.9.15.1 which should be good pere: it did mount /dev/hd0s1 under /media/cdrom0 0.9.15.5, correctly i think, asks to insert it cdrom. but finally both mount /dev/hd0s1 instead of /dev/hd2 -it cause they both can't detect where cdrom is i guess ## IRC, freenode, #hurd, 2014-03-04 we could talk about apt-cdrom https://bugs.debian.org/740673 how should system recognize cdrom device? there's no /dev/cdrom link to actual cdrom device /dev/cd[01] are scsi devices if i'm not wrong ## IRC, OFTC, #debian-hurd, 2014-03-05 installer gets stuck running os-prober, seems because /target/proc/mounts gets unreadable, sometimes Resource lost sometimes it gets stuck reading it [[hurd/translator/mtab/discussion#chroot]]. youpi: could you publish script to rebuild CDs you scheduled? with last official CD (20140212) mtab on /target dies and that seems getting os-prober stuck. last (and only) weekly has recent apt-cdrom so it gets stuck wrongly asking to change cdrom see the readme file err, you say it's the 0212 build which fails? I had tested that before uploading so the issue comes form the installed packages, not from the CD udebs did you test with no network mirror? no i didn't. should it find all packages it needs from cd? sure, that's what netinst and dvd-1 are, as opposed to netboot lxde desktop probably not indeed though with the dvd in principle it should (if all deps were avaijlable at image build time) gg0: btw if you haven't noticed, there's a daily too youpi: till apt-cdrom is not fixed, they all will be broken, stuck at "Scanning cdrom" gg0: did you try to bisect which git change produces the apt-cdrom bug? youpi: all in bug in question youpi: https://bugs.debian.org/740673 is there the precise git commit id in the bug log? http://anonscm.debian.org/gitweb/?p=apt/apt.git;a=commitdiff;h=62dcbf84c4aee8cb01e40c594d4c7f3a23b64836 well, don't tell that to just me, but the bug report... bug report says "See " where bug is https://bugs.debian.org/728153 gg0: bug report doesn't say it was *tested* that it is that changes which broke things i don't think we could get it reverted just because it breaks hurd (+kfreebsd to check) debian installer of course, but that's at least where developers can have a look at well ok i could have been more clear it's *WAY* better than having no idea where to have a look at gg0: btw, that's why the README file advises not to use a network mirror, to avoid such kind of issues you can't expect sid not to be not-broken :) one gets Resource lost even when install is just started, no packages from any mirror https://bugs.debian.org/740673#19 * gg0 installing without mirrors, without desktop, without lxde same problem so problem has nothing to do with installing from mirrors what's odd is that I don't get this issue at all with the 20140212 upload at least kvm -cdrom debian-7.0-hurd-i386-NETINST-1.iso -drive file=blip,cache=unsafe -m 1G no more, no less it must depend on preseed and/or kernel append options possibly oh wait here qemu multiboot that shouldn't have any impact 5€ on qemu multiboot as the culprit you should also see it sometimes double-mounts /dev/hd0s1 under /target and /target/./media/cdrom(!) but that's due to new apt it in-targets (= installs under /target) any luck reproducing mtab issue? still not [[hurd/translator/mtab/discussion#chroot]]. ## IRC, OFTC, #debian-hurd, 2014-03-06 http://paste.debian.net/85535/ no issue (no network mirror) full install till grub-installer? yes and reboot -append 'auto=true mirror/suite=sid console=com0 priority=critical locale=en_US keymap=us url=http://10.0.2.1//d-i-preseed-cfgs/debian_sid_daily_hurd_lxde_preseed.cfg video=vesa:ywrap,mtrr vga=788 -- quiet' i should provide preseed too well, of course always provide as much information as possible so there's also your preseed file not much different from http://jenkins.debian.net/d-i-preseed-cfgs/debian_sid_daily_lxde_preseed.cfg but you need to force a couple of things + ugly workaround for broken apt-cdrom ident well, I didn't even know that jenkins had that pressed file well, here apt-cdrom is not needed +hacks since that's the old image we're checking well ok, given you take everything from cd only, yes here no mirror, no desktop, no lxde http://paste.debian.net/plain/85538/ i'm trying this one too main difference seems to be i usually use CD-1, not NETINST had to add -net nic,vlan=0 -net user,vlan=0,host=10.0.2.1,dhcpstart=10.0.2.2,dns=10.0.2.254 here target mtab is already crashed because some package already tried to read /target/proc/mounts youpi: reproduced there? .o(well, maybe he's been sleeping for ~50 mins) nope, I'm working on upgrading servers I'm sorry, but your testcase is not really easy to reproduce :) do you have apache on your host? just put preseed in the root, vm will take it full command line is what you pasted + -net nic,vlan=0 -net user,vlan=0,host=10.0.2.1,dhcpstart=10.0.2.2,dns=10.0.2.254 what else? when it starts debstrapping, open a console and check procfs and mtab processes err, what you paster + -append i pasted + -net nic,vlan=0 -net user,vlan=0,host=10.0.2.1,dhcpstart=10.0.2.2,dns=10.0.2.254 *pasted which is http://paste.debian.net/plain/85554/ surely keyboard layout doesn't help, here at least * gg0 tries to reproduce without preseed i can't reproduce it it doesn't crash * gg0 enabling all options but preseed need to wait 31% of Installing base system to have the second procfs ok got Resource lost even without preseed youpi: you can reproduce it by adding -append console=com0 to what you pasted. that breaks grub-installer, it gets stuck at 66%, while runs os-prober ah how can that affect /target/proc/mounts? no idea couldn't daily be here? http://d-i.debian.org/daily-images/ if I knew how to push files there, sure asking on #debian-boot would be a starting point i guess probably me asking on behalf of youpi would not a good one i think, given whatever will the answer i can't do anything +be you can still trasmit me never understimate the little time you can save other people by doing some bits of work well, i would not even have to repaste lines here given you joined there too never understimate what "help with laziness" means :) not necessarily repasting, but at least highlighting me so I know where to read in the #d-b logs there are no isos there, i'm missing something there are no daily isos only weekly isos so seems i have to reask initial question with this url http://cdimage.debian.org/cdimage/weekly-builds/ oh wait they are from testing, that's why no hurd ones i guess they could be here though http://cdimage.debian.org/cdimage/daily-builds/sid_d-i/current/ * gg0 asking on #debian-cd * gg0 would ignore non-DD gg0 asking whatever people don't really ask themselves who is a DD and who is not as long as you provide information in your question, it'll get answered teythoon: interested in reproducing mtab-dying-under-chroot? oh just realized it's not only under a chroot, chroot is on another disk. might that make the difference? i didn't try to reproduce it by creating a chroot on a different disk, which is what installer does * gg0 wonders if it would have been better filing a bug against cdimage.debian.org if no one fixes console=com0 thing, i have to think about a new acpi ok managed to workaround apt bug in installer, i can graphically install last weekly no console=com0 means no vm shutdown though gg0: wow. impressed! patching CI to make CI workaround bugs CI spots is not so good any idea about another shutdown trick without console=com0 till teythoon or youpi fix it? nope current one: vm writes serial console to file and host loops grepping "In tight loop: hit ctl-alt-del to reboot" -watchdog might be an alternative if there are watchdog agents that can run on hurd "watchdog" for instance doesn't build on hurd it need kernel support * gg0 testing -add-fd ## IRC, freenode, #hurd, 2014-03-07 teythoon: just mounted an additional fs, it's mounted but not present in proc/mounts gg0: how did you mount it ? i was under /root, sid-chroot is the mountpoint. i did mount /dev/hd3 sid-chroot (relative path) does fsysopts confirm a new translator is running on sid-chroot ? i shut down vm, working on another one by mounting the same disk which hosts a debchroot i'm trying to reproduce the mtab-dying-on-chroot issue i get with debian installer at the end, os-prober gets stuck by reading /target/proc/mounts (target is the installed system) to be precise it gets stuck at second access. at first it gives Resource lost didn't manage to reproduce so far environment is pretty the same: booting with qemu multiboot http://darnassus.sceen.net/~hurd-web/hurd/running/qemu/#multiboot so root on initrd + chroot on real disk what's weird is that issue vanishes by removing console=com0 from -append options ### IRC, freenode, #hurd, 2014-03-08 os-prober doesn't get stuck anymore and grub can install my guess is that without console=com0 /target/proc/mounts is just accessed once ## IRC, OFTC, #debian-hurd, 2014-03-08 youpi: from #debian-cd http://paste.debian.net/plainh/559f669b any quick way to recreate initrd? gg0: i'm working on that teythoon: that what? gg0: there is genext2fs, i have some patches that allows one to create nodes with passive translator records recreating initrd? yes in the meantime, you can mount the existing initrd and modify it well i'm following this one to rebuild whole cd then take an updated initrd to test with your repo http://people.debian.org/~sthibault/hurd-i386/installer/README-d-i probably too much work to get that copying current /hurd to new initrd would be enough? just copy the precise translator you need also, no need to rebuild the whole cd just to replace the initrd simply copy the content of an existing is iso replace the initrd.gz there and then use grub-mkrescue to rebuild the ios development would be horrible if you had to rebuild everything from zero everytime first thing to do when developping is first take the time to find ways to work efficiently unfortunately I had to apply some patches first in d-i because isc-dhcp doens't work -> use the debian-ports version then in d-i to automatically enable the debian-ports mirror and last in the debian-cd to include debian-ports-archive-keyring anything missing here? http://people.debian.org/~sthibault/hurd-i386/installer/README-d-i mini.iso doesn't like any mirror "mirror does not support the specified release" something wrong/missing in my rebuilt youpi: anything wrong in http://paste.debian.net/plain/86258 ? i have/had problems with name resolution gg0: the patch makes sense for -bsd too, Cc them too i was wondering how many hunks in your patches are upstreamable normally it's zero http://people.debian.org/~sthibault/hurd-i386/installer/patch-debootstrap why "release" instead on "main" by default? sid is never released only because my mirror directory is hacked one that merges debian.org, debian-ports.org, and my repo and I don't rebuild Release files, just Packages files i keep getting gpgv: BAD signature from "Debian Archive Automatic Signing Key (7.0/Wheezy) just before creating debootstrap chroot i applied hunk #2 only, installed modified debootstrap and put debs under localdebs/ trying a different mirror I don't know what issue you are encountering but again, it's way simpler and faster to just patch existing images, rather than rebuilding them from zero ok just read i'd need a local mirror to build isos better using netinst and proxy cache ## IRC, freenode, #hurd, 2014-03-09 teythoon: shouldn't there be a patch which shows pid instead of task? 20:43 < teythoon> task /hurd/procfs(19) O deallocating an invalid port 1049744, most probably a bug. there is i placed the functionality in proc first, but the wiki suggested to put it in the exec server instead i did that, it has the advantage, that the argv vector is easily accessible so i can also include the program name but there are two programs, that are not started using the exec server the root filesystem and the exec server itself so for these two processes, the approach does not work i see. so here we got two which could come from ext2fs.static(initrd), exec(initrd) and ext2fs(chroot) http://postimg.org/image/e3qyafd0b/ right? i also noticed that once mtab dies, by killing its procfs parent, they both restart, but /target/proc is not in /proc/mounts anymore teythoon: for those we could use the first word of the module command line restart doesn't means that by accessing /target/proc/mounts again it works btw, it'll give Resource lost again youpi: indeed gg0: no, the ext2fs for /target will be started by the exec server ok two invalid ports one from ext2fs.static and one exec then gg0: what makes you attribute one to the exec server ? i'm pretty sure that there is a bug in libfshelp, it's easily triggered by killing an translator like procfs i must have introduced it with the translator list work i've done for the mtab translator teythoon: a totally wrong task-is-a-process reasoning probably just mounted another procfs which seems to work http://postimg.org/image/q6w9xzo2j/ http://postimg.org/image/cr998jfkr/ gg0: the mtab translators in your screenshots are oldish, what's the point exactly ? gg0: also, all tasks are processes. task is a mach concept, whereas process is a posix concept implemented by hurds proc server. it creates a process object for every mach task. my guess was that given we got two messages with different taskid: 16:01 < gg0> ok two invalid ports one from ext2fs.static and one exec then screenshot is this one http://postimg.org/image/e3qyafd0b/ btw what do you mean by oldish. except first one 01:18 < gg0> http://postimg.org/image/oca8ormaj/ the only with current debian packages, remaining are done with your latest packages in all cases i boot using qemu multiboot root@hurd01:~# cat /proc/version Linux version 2.6.1 (GNU 0.5 GNU-Mach 1.4-486-dbg/Hurd-0.5 i686-AT386) it wouldn't be bad customizing version somehow, last commit id for instance or build date user01@jessie01 ~$ cat /proc/version Linux version 3.11-2-686-pae (debian-kernel@lists.debian.org) (gcc version 4.8.2 (Debian 4.8.2-7) ) #1 SMP Debian 3.11.10-1 (2013-12-04) user01@jessie01 ~$ uname -v #1 SMP Debian 3.11.10-1 (2013-12-04) ## IRC, OFTC, #debian-hurd, 2014-03-10 tschwinge: i just meant Debian Jenkins provides (hopefully for hurd too) continuos testing of debian installer, it doesn't produce .debs