Re: jenkins kfreebsd jobs (Re: Plan B for kfreebsd)
Hi Steven, On Donnerstag, 13. November 2014, Steven Chamberlain wrote: I think we're missing some data from the end of the serial.log; probably due to some buffering, and qemu being sent SIGKILL. Please consider this change to use SIGINT for up to 10 seconds, then SIGKILL only if it's still running after that: https://git.steven.hosting.pyro.eu.org/jenkins.debian.net.git/?h=894584fca2 66789c8f40b4c0cad60b7909385523 did you make this never returns false? The script will immidiatly end in that case, iirc... cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: jenkins kfreebsd jobs (Re: Plan B for kfreebsd)
Hi, Holger Levsen wrote: On Donnerstag, 13. November 2014, Steven Chamberlain wrote: Please consider this change to use SIGINT for up to 10 seconds, then SIGKILL only if it's still running after that: https://git.steven.hosting.pyro.eu.org/jenkins.debian.net.git/?h=894584fca266789c8f40b4c0cad60b7909385523 did you make this never returns false? The script will immidiatly end in that case, iirc... Are you thinking of -e (exit on error)? g-i-installation.sh doesn't seem to run in that mode, actually it ignores some failing commands already during cleanup steps. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141114120218.gc26...@squeeze.pyro.eu.org
Re: jenkins kfreebsd jobs (Re: Plan B for kfreebsd)
Hi, On Freitag, 14. November 2014, Steven Chamberlain wrote: Are you thinking of -e (exit on error)? yes g-i-installation.sh doesn't seem to run in that mode, actually it ignores some failing commands already during cleanup steps. yes, but during cleanup +e is explicitly set, I think. Oh, well, I suppose I should either merge and see how it fails or read the code myself before merging... ;-) cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: jenkins kfreebsd jobs (Re: Plan B for kfreebsd)
Holger Levsen wrote: g-i-installation.sh doesn't seem to run in that mode, actually it ignores some failing commands already during cleanup steps. yes, but during cleanup +e is explicitly set, I think. Aha yes it does set +e inside that function. But code before and after it does ignore + have to handle fatal errors itself. The code I added shouldn't return false, except maybe a race between 'ps' and 'kill' (if the process goes away in that time); but seems unlikely with the 'sleep 1' after each iteration. Oh, well, I suppose I should either merge and see how it fails or read the code myself before merging... ;-) Well, you were right; I didn't think to check for a set +e in the script, only looked for something like that at the top of the script and assumed it was safe to return false anywhere. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141114123321.gg26...@squeeze.pyro.eu.org
Re: jenkins kfreebsd jobs (Re: Plan B for kfreebsd)
Hi Steven, On Freitag, 14. November 2014, Steven Chamberlain wrote: Aha yes it does set +e inside that function. But code before and after it does ignore + have to handle fatal errors itself. The code I added shouldn't return false, except maybe a race between 'ps' and 'kill' (if the process goes away in that time); but seems unlikely with the 'sleep 1' after each iteration. ok, cool, thanks for checking! +merged+pushed+deployed+job triggered :) cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: jenkins kfreebsd jobs (Re: Plan B for kfreebsd)
Hi Holger, Holger Levsen wrote: I don't understand why getting the preseed file then fails... https://jenkins.debian.net/view/g-i-installation/job/g-i-installation_debian_sid_daily_kfreebsd/433/screenshot/full After I started at the error message long enough, it finally hit me, and it's kind of amusing. If you could please fix my silly mistake: https://git.steven.hosting.pyro.eu.org/jenkins.debian.net.git/?h=b463b29fdcf5ec4104a2df624690aac8f23481a1 Thanks! Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141114131949.ge26...@squeeze.pyro.eu.org
Re: jenkins kfreebsd jobs (Re: Plan B for kfreebsd)
Hi Steven, On Freitag, 14. November 2014, Steven Chamberlain wrote: After I started at the error message long enough, it finally hit me, and it's kind of amusing. If you could please fix my silly mistake: hehe, I know that feeling... :-) merged + triggered etc.. - thanks! cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: jenkins kfreebsd jobs (Re: Plan B for kfreebsd)
Hi, On Mittwoch, 12. November 2014, Samuel Thibault wrote: Maybe hurd also could redirect syslog there to help debug the issue you're seeing. Indeed. actually, all installs can probably benefit from this :) There is: console=com0, it'd only redirect the kernel messages though (which can however be useful to get the out of the vga console output, and in a safe place) [...] Yes, it'd be com0 for GNU/Hurd. patches, please. cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: jenkins kfreebsd jobs (Re: Plan B for kfreebsd)
Hi, On Mittwoch, 12. November 2014, Steven Chamberlain wrote: Holger Levsen wrote: in the video there is no IP address to be seen. em0 gets a link, but thats all. Later 'network autoconfiguration succeeded', so DHCP probably worked; the IP address isn't usually mentioned within the GUI installer, but the d-i syslog will probably explain what the problem is. ok, cool. Okay I've tried to log serial console output as an artifact, if you could pull again please: https://git.steven.hosting.pyro.eu.org/jenkins.debian.net.git/?h=adc905d26d 93381495a47ece2259207009f0da5e merged+pushed, thanks. Will trigger new builds once jenkins.d.n is up again, there are currently some disturbances in the cloud... cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: jenkins kfreebsd jobs (Re: Plan B for kfreebsd)
Hi, https://jenkins.debian.net/view/g-i-installation/job/g-i-installation_debian_sid_daily_kfreebsd/432/artifact/results/serial.log is there now and it shows how the right IP is received. I don't understand why getting the preseed file then fails... cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: jenkins kfreebsd jobs (Re: Plan B for kfreebsd)
Holger Levsen wrote: https://jenkins.debian.net/view/g-i-installation/job/g-i-installation_debian_sid_daily_kfreebsd/432/artifact/results/serial.log is there now and it shows how the right IP is received. I don't understand why getting the preseed file then fails... I think we're missing some data from the end of the serial.log; probably due to some buffering, and qemu being sent SIGKILL. Please consider this change to use SIGINT for up to 10 seconds, then SIGKILL only if it's still running after that: https://git.steven.hosting.pyro.eu.org/jenkins.debian.net.git/?h=894584fca266789c8f40b4c0cad60b7909385523 Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141113134537.ge23...@squeeze.pyro.eu.org
Re: jenkins kfreebsd jobs (Re: Plan B for kfreebsd)
Holger Levsen wrote: in the video there is no IP address to be seen. em0 gets a link, but thats all. Later 'network autoconfiguration succeeded', so DHCP probably worked; the IP address isn't usually mentioned within the GUI installer, but the d-i syslog will probably explain what the problem is. -serial file, to write those separately as an artifact whatever you prefer really. I tend to somewhat prefer the latter... optionally output that at the end of the job... Okay I've tried to log serial console output as an artifact, if you could pull again please: https://git.steven.hosting.pyro.eu.org/jenkins.debian.net.git/?h=adc905d26d93381495a47ece2259207009f0da5e Maybe hurd also could redirect syslog there to help debug the issue you're seeing. Unless there's a convenient kernel parameter to send console messages there, you could always use preseed/early_command to modify inittab like I did here: https://anonscm.debian.org/cgit/qa/jenkins.debian.net.git/commit/?id=f85e9c3f8dcc4283120e77794a150daad930da46 Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141112192613.ga19...@squeeze.pyro.eu.org
Re: jenkins kfreebsd jobs (Re: Plan B for kfreebsd)
Steven Chamberlain, le Wed 12 Nov 2014 19:26:14 +, a écrit : Maybe hurd also could redirect syslog there to help debug the issue you're seeing. Indeed. Unless there's a convenient kernel parameter to send console messages there, There is: console=com0, it'd only redirect the kernel messages though (which can however be useful to get the out of the vga console output, and in a safe place) you could always use preseed/early_command to modify inittab like I did here: https://anonscm.debian.org/cgit/qa/jenkins.debian.net.git/commit/?id=f85e9c3f8dcc4283120e77794a150daad930da46 Yes, it'd be com0 for GNU/Hurd. Samuel -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141112220600.gj3...@type.youpi.perso.aquilenet.fr
Re: Plan B for kfreebsd
Christoph Egger wrote: It means we need a stable release of some sort to keep DSA provided hardware. That's currently buildds and porterboxes. That's annoying. To provide stable/security support ourselves, it seemed we'd need an unofficial repo, and that doesn't sound like something DSA could use. Although, how is that handled for hurd-i386? I assume it has no security support, there may be some unofficial packages used; are therefore none of their machines DSA? Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014120505.gd14...@squeeze.pyro.eu.org
Re: Plan B for kfreebsd
Hi! Steven Chamberlain ste...@pyro.eu.org writes: Christoph Egger wrote: It means we need a stable release of some sort to keep DSA provided hardware. That's currently buildds and porterboxes. That's annoying. To provide stable/security support ourselves, it seemed we'd need an unofficial repo, and that doesn't sound like something DSA could use. weasel christoph: the ftp-folks wouldn't mind having a jessie-kfreebsd suite in the main archive. With our own acceptance policy I guess (like backports has different people accepting and stuff) and DSA would sure be willing to use that. All it means is we need to do some release that is close enough to being debian for the infrastructure. It means we can't only do some rolling stuff and expect DSA to run hardware for us for example. Although, how is that handled for hurd-i386? I assume it has no security support, there may be some unofficial packages used; are therefore none of their machines DSA? These are private machines Christoph -- 9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731 Debian Developer | Lisp Hacker | CaCert Assurer -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87389psz04@anonymous.siccegge.de
Re: Plan B for kfreebsd
Steven Chamberlain, le Tue 11 Nov 2014 12:05:06 +, a écrit : Although, how is that handled for hurd-i386? I assume it has no security support, there may be some unofficial packages used; are therefore none of their machines DSA? We are still stuck in the not released arch = no DSA machine = not released arch loop. Samuel -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014123400.gc3...@type.youpi.perso.aquilenet.fr
Re: Plan B for kfreebsd
On Tue, 11 Nov 2014, Samuel Thibault wrote: Steven Chamberlain, le Tue 11 Nov 2014 12:05:06 +, a écrit : Although, how is that handled for hurd-i386? I assume it has no security support, there may be some unofficial packages used; are therefore none of their machines DSA? We are still stuck in the not released arch = no DSA machine = not released arch loop. Except that it's not a loop. DSA has indicated time and time again that if an arch qualifies for a release in all other aspects, we'd be running buildds and porterboxes close to the release. And, TTBOMK, the release team has so far accepted that. IOW the fact that hurd is not being released with jessie is not due to not having d.o systems. -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014123902.gk20...@anguilla.noreply.org
Re: Plan B for kfreebsd
On Tue, 11 Nov 2014, Samuel Thibault wrote: Peter Palfrader, le Tue 11 Nov 2014 13:39:02 +0100, a écrit : On Tue, 11 Nov 2014, Samuel Thibault wrote: We are still stuck in the not released arch = no DSA machine = not released arch loop. Except that it's not a loop. DSA has indicated time and time again that if an arch qualifies for a release in all other aspects, we'd be running buildds and porterboxes close to the release. And, TTBOMK, the release team has so far accepted that. IOW the fact that hurd is not being released with jessie is not due to not having d.o systems. Ok, then I don't understand why there are DSA-admined buildds and security buildds columns in the release qualification sheet. Because they need to exist for the release. They are necessary, not sufficient. You aren't blocking on them. If/when DSA admined buildds are the only remaining issue and we're close to the release, then we can make them. -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014131109.gm20...@anguilla.noreply.org
Re: Plan B for kfreebsd
Peter Palfrader wrote: On Tue, 11 Nov 2014, Samuel Thibault wrote: We are still stuck in the not released arch = no DSA machine = not released arch loop. Except that it's not a loop. DSA has indicated time and time again that if an arch qualifies for a release in all other aspects, we'd be running buildds and porterboxes close to the release. Until Christoph quoted your brilliant suggestion on IRC, I did think there were one or more loops here with no obvious way out, for us or many future ports. At least, the release team's decision seemed far-reaching, since: 0. stable RM says 'no' to a port 1.1. if there's not a 'stable' release, the buildds can't be DSA 1.2. without DSA buildds, there can be no security builds either (and vice-versa) 1.3. packages built for sid, on non-DSA buildds are not official? so would need to rebootstrap itself 2.1. testing goes away too 2.2. users/developers are left with only sid, which is obviously more broken; development gets harder, users leave 2.3. port becomes less appealing for maintainers to support, stop trying to building their packages on it 3.1. if there's no testing or stable, FTP team might not see much reason to distribute it; it moves to debian-ports.org and, I suppose never comes back 3.2. mirrors no longer carry it, most QA tools and supporting infrastructure can no longer support it 4. next release qualification, the port seems in pretty bad shape due to all of the above probably receives a 'no' again Anyway, I'm really hopeful now. weasel suggested a 'jessie-kfreebsd' suite could still be supported by FTP team. (Actually, could that be named something more generic like jessie-ports? So that another arch can try something similar? Or would it be confused too much with debian-ports.org?) Porters would try to maintain it like a stable release. Perhaps able to do make improvements that release team policy might not have allowed; like backporting something that particularly benefits that arch. Practically it would be an 'official Debian port', and we'd have all the usual things like install media. If it turns out to be in fact stable, hopefully it would be acceptable to DSA. The remaining obstacles go away. It sounds sustainable, and seems like a model for other ports to follow. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014134118.gf14...@squeeze.pyro.eu.org
Re: Plan B for kfreebsd
Steven Chamberlain, le Tue 11 Nov 2014 13:41:18 +, a écrit : Practically it would be an 'official Debian port', and we'd have all the usual things like install media. I wouldn't call it official, but I agree on the rest. Getting hurt by sid bugs is always a pain, and you can not have users that way. And having a port in the normal infrastructure flow helps a *lot* to get maintainers at least try to fix their packages, instead of leaving all the tudy to the porter team. Samuel -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014135228.gg3...@type.youpi.perso.aquilenet.fr
Re: Plan B for kfreebsd
Hello, 2014-11-11 14:41 GMT+01:00 Steven Chamberlain ste...@pyro.eu.org: Peter Palfrader wrote: On Tue, 11 Nov 2014, Samuel Thibault wrote: Anyway, I'm really hopeful now. weasel suggested a 'jessie-kfreebsd' suite could still be supported by FTP team. (Actually, could that be named something more generic like jessie-ports? So that another arch can try something similar? Or would it be confused too much with debian-ports.org?) Porters would try to maintain it like a stable release. Perhaps able to do make improvements that release team policy might not have allowed; like backporting something that particularly benefits that arch. Practically it would be an 'official Debian port', and we'd have all the usual things like install media. If it turns out to be in fact stable, hopefully it would be acceptable to DSA. The remaining obstacles go away. It sounds sustainable, and seems like a model for other ports to follow. I have been thinking adding stable to debian-ports would be great for these kind of cases, but still there are many open ends: * Need for unreleased-stable suite * Keep up with security maintenance * Keep up with point releases * Handling transitions in acceptable time (not directly affecting stable release) * Handle migrations between unstable - stable(?) suites All that, and maybe more, without release, security, buildd, dsa team support. Not trivial stuff to do, but that might not only help the kfreebsd but all the other debian-ports arches to get an unofficial stable release. Regards, -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-. -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caodfwegbko7gk_mjvsygibceeu_ky6hffwi3rtqnc0+f3ir...@mail.gmail.com
