| === infinity3 is now known as infinity | ||
| === halfie_ is now known as halfie | ||
| === spossiba_ is now known as spossiba | ||
| === fmasi is now known as Guest61135 | ||
| === davmor2_ is now known as davmor2 | ||
| === trevorjay is now known as trevorj | ||
| === Guest61135 is now known as fmasi | ||
| arges | hey. Wondering why the current linux-image-generic-lts-quantal shows 3.5.0.49.55 while the git tag shows Ubuntu-lts-3.5.0-49.73 ? Why the difference in build numbers? | 13:27 |
|---|---|---|
| rtg | arges, I wonder if that is the meta package tag ? | 13:30 |
| arges | rtg: so the meta package just has a different build number? | 13:31 |
| rtg | arges, of course. its actually the upload number (and is completely arbitrary) | 13:31 |
| arges | rtg: ok so if I uname -a that particular kernel I should get #73 (which matches with the git tag) | 13:32 |
| rtg | the tags in the kernel repo should be the same as the source package, e.g., Ubuntu-lts-3.5.0-49.73, Ubuntu-lts-3.5.0-50.74, etc | 13:33 |
| rtg | arges, the last 2 tags look right to me. | 13:34 |
| arges | $ rmadison linux-lts-quantal | grep updates | 13:34 |
| arges | linux-lts-quantal | 3.5.0-49.73~precise1 | precise-updates | source | 13:34 |
| arges | rtg: yea I think I was just looking at the wrong source package. | 13:34 |
| rtg | arges, the meta package is gonna be different (except for the ABI number) | 13:35 |
| arges | cool starting to make more sense now. thanks for clearing that up : ) | 13:36 |
| rtg | arges, we use the upload number to distinguish interim versions within an ABI series. | 13:36 |
| apw | rtg, so ... why have you flippied the top of ubuntu-utopic from UNRELEASED to utopic, as it isn't done or uploaded that seems counter intuitive | 13:59 |
| rtg | apw, yup, so my local builds use the right chroot | 14:03 |
| rtg | we still have to run insertchanges before its a complete changelog | 14:03 |
| apw | hmmm, perhaps shove a 3.14.0-0.0 in then ? | 14:03 |
| apw | underneath | 14:04 |
| rtg | apw, is it breaking your PPA builds ? | 14:04 |
| apw | no it is breaking me :) well actually it is mostly triggering confusing versioning | 14:04 |
| apw | as it is "released" i am appending post release versioning not ~ stuff | 14:04 |
| apw | rtg, now i am confused again, as you seem to have flipped it back to 3.14 and unreleased, or have i lost control of my trees | 14:05 |
| rtg | apw, well, go ahead and fix it as you like as long as the first changelog entry that is not 'UNRELEASED' says utopic. | 14:05 |
| apw | oh no, that was me being a spaz | 14:06 |
| apw | ack | 14:06 |
| === yleger is now known as Yaann | ||
| Yaann | Hi ! | 14:53 |
| Yaann | I'm looking for a way to generate a shutdown initramfs on ubuntu, does anybody know how to do that ? It needs to disconnect properly the nbd root device. | 14:55 |
| === mjg59` is now known as mjg59 | ||
| apw | Yaann, hmmm, not sure if anyone here would know, you might try #ubuntu-server, they might | 15:16 |
| Yaann | apw: Ok, thanks ! | 15:18 |
| * ogra_ wonders why an initramfs would be involved in any shutdown bits | 15:24 | |
| apw | oddly this is not the first question we have had on this, i think the initramfs bits are involved as you | 15:25 |
| apw | have to exclude yourself when starting in the initramfs, to prevent yourself being killed on the way down | 15:25 |
| apw | Yaann, did you mean startup or shutdown here | 15:26 |
| xnox | Yaann: as far as I know, shutdown initramfs is a dracut/systemd features which is not yet used in neither debian nor ubuntu. | 15:26 |
| xnox | Yaann: in ubuntu we only have startup initramfs, which can be updated with $ update-initramfs -u | 15:27 |
| xnox | (and dropping in appropriate hooks/scripts in either /etc or /usr -> see initramfs-tools manpages) | 15:27 |
| apw | xnox, as in we go back to the original initramfs root ? | 15:27 |
| apw | s/we/they | 15:27 |
| xnox | apw: correct. On fedora: the originial initramfs is left in-tact, at shutdown one goes back into it and unmounts root. That way all network filesystems/mdadm/fakeraid etc. are never started from the mounted rootfs. | 15:28 |
| ogra_ | like android ? | 15:28 |
| ogra_ | where your initrd becomes the top part of / ? | 15:28 |
| xnox | apw: so no processes / daemons are allowed to "takeover" daemons started from the initramfs. | 15:29 |
| apw | so you have to rebuild that on any package install which is included, ugg | 15:30 |
| xnox | ogra_: yes and no. android shutdown is very simple - sync, killall, umount. -> it really does not care. | 15:30 |
| ogra_ | yeah, but the boot-up sounds similar | 15:30 |
| apw | that is how all of them work on startup though | 15:30 |
| ogra_ | (which is pretty awful if you want to have a generic OS instead of one thats bound to a specific device) | 15:30 |
| xnox | yeah, startup is the same across all.... | 15:30 |
| apw | where you mount /root in / (the initramfs one) and then get things ready and move into /root | 15:30 |
| ogra_ | apw, no, on android your initrd *becomes* your root | 15:31 |
| ogra_ | there is never any pivoting | 15:31 |
| apw | so stays your root | 15:31 |
| ogra_ | right | 15:31 |
| apw | they do know how to hurt my head | 15:31 |
| * apw does wonder how any root which needs a daemon runnign is meant to work | 15:31 | |
| ogra_ | this is perfect if your OS is actually built for a specific device ... we will never be able to cope with their boot speed for example | 15:32 |
| ogra_ | but if you want a generic desktop OS thats just awful ... | 15:32 |
| xnox | there is no "generic desktop os" =))))))))))) | 15:32 |
| ogra_ | well, :) ubuntu :) | 15:32 |
| ogra_ | something that works with variung hardware | 15:33 |
| ogra_ | *varying | 15:33 |
| xnox | just a lot of desktop OSs highly optimised for a wide range of x86 machines with common configurations/firmware expectations =)))))) | 15:33 |
| ogra_ | yeah, that :) | 15:33 |
| Yaann | xnox: Yep I already have a custum startup initramfs but I when to properly disconnect my root device before shuting down and the shutdown binary will not be available anymore after disconnecting the block device | 15:39 |
| ogra_ | Yaann, talk to the guys in #ltsp ... they do that properly | 15:39 |
| ogra_ | (nbd is the default in ubuntus ltsp implementation) | 15:40 |
| xnox | Yaann: look at "/etc/init.d/sendsigs" if you drop a pidfile into /run/sendsigs.omit your process will not be killed on shutdown. | 15:40 |
| ogra_ | i guess you only remount ro and leave the rest to the nbd-client | 15:40 |
| xnox | Yaann: and your daemon should not hold any files open. | 15:40 |
| xnox | Yaann: the fact that the binary is "no longer available" is not actually a problem. | 15:41 |
| ogra_ | (stgraber definitely knows the mechanics) | 15:41 |
| Yaann | xnox: I already added the right PID in /run/sendsigs.omit.d/nbd-client, the kernel doesn't panic anymore but the server never receives a proper disconnect | 15:41 |
| Yaann | ogra_: I'm gonna try on #ltsp :) | 15:42 |
| ogra_ | ask alkisg there | 15:43 |
| ogra_ | he also knows a lot about the nbd setup they use | 15:43 |
| rtg | apw, # first bad commit: [177cf92de4aa97ec1435987e91696ed8b5023130] drm/crtc-helpers: fix dpms on logic | 16:11 |
| rtg | I reverted that on top of utopic master-next and now everything resumes just fine | 16:11 |
| arges | apw: do you need to add my SOB line when I ACK patches? | 16:16 |
| arges | err Do I rather. | 16:16 |
| apw | arges, people will convert an ACK to Acked-by: though i tend to include the Acked-by in mine | 16:17 |
| apw | rtg, that is worrying as the code is clearly spack before that fix | 16:18 |
| arges | apw: ok cool | 16:18 |
| apw | arges, oh an normally i add [ACK] or similar to teh subject to make it clear. | 16:25 |
| apw | see my last couple :) | 16:28 |
| === zequence_ is now known as zequence | ||
| clopez | Out of curiosity... why Ubuntu 14.04 comes with kernel 3.13 ?? That kernel version is not LTS (is already EOL, see https://www.kernel.org/). Wouldn't have made more sense to ship 3.12 instead? | 17:32 |
| apw | clopez, that is only not a gregkh LTS support kernel, the ubuntu kernel team is supporting the 3.13 kernel long term | 17:35 |
| clopez | Not only gregkh supports LTS kernels: https://www.kernel.org/category/releases.html For example debian kernel maintainer Ben Hutchings supports the 3.2 LTS version | 17:36 |
| clopez | if you are going to do the effort of maintaining the 3.13 line on your own, I wonder why you don't do it upstream ? | 17:37 |
| bjf | clopez, yes, and we use ben's 3.2 stable patches for precise | 17:37 |
| bjf | clopez, we do "do it upstream" | 17:39 |
| bjf | clopez, you will see our announcements regularly on lkml | 17:39 |
| clopez | then is that kernel page outdated? | 17:40 |
| apw | it only includes ones gregkh officially recognises | 17:40 |
| mdeslaur | http://lkml.iu.edu/hypermail/linux/kernel/1404.2/05016.html | 17:40 |
| bjf | clopez, sort of. those maintainers are "blessed" by gregkh | 17:40 |
| antarus | politics, yay! | 17:41 |
| hallyn | stgraber: hm, trying to think... can it happen that there are cgroups in /proc/cgroups which do *not* show up in /proc/self/cgroup? | 17:42 |
| hallyn | apw: ^ happen to know? | 17:42 |
| hallyn | i think not, but i'm not absolutely certain | 17:42 |
| stgraber | hallyn: should be easy enough to check | 17:43 |
| apw | i do not know to be hones | 17:43 |
| stgraber | hallyn: /proc/1/cgroup lists all of them so I don't think it's possible | 17:43 |
| stgraber | hallyn: pid 1 even lists the systemd one which was clearly setup long after pid 1 started | 17:44 |
| clopez | I guess gregkh only trusts kernel developers with a track of important contributions | 17:44 |
| bjf | clopez, you just trolling here or what? | 17:44 |
| clopez | No | 17:45 |
| apw | clopez, you could have picked that phrase from his emails | 17:45 |
| hallyn | stgraber: my concern is with the unified hierarchy crap... | 17:45 |
| clopez | is there any other reason why he won't allow you to maintain the 3.13 LTS "officially" ? | 17:45 |
| apw | you'd have to ask him his reasons not us | 17:45 |
| apw | nor does it make any difference, we do the work, people other than us consume it, we are happy | 17:46 |
| bjf | clopez, what apw said ^ | 17:46 |
| stgraber | hallyn: yeah, not sure how things would look like with the unified hierarchy | 17:48 |
| clopez | I understand that, but it seems a bit odd that you don't know why he won't allow you to maintain the branch on kernel.org | 17:48 |
| hallyn | stgraber: just trying to decide whether i should parse both or not. but i won't... | 17:49 |
| apw | clopez, he has said basically what you said, that our maintainers have no track record. that dispite maintaing various stable trees for extended periods | 17:50 |
| apw | clopez, but also it makes no difference to us, people consume the trees we produce, which is the aim | 17:51 |
| ogasawara | http://www.spinics.net/lists/stable/msg32034.html | 17:51 |
| clopez | yes, I found it: this http://article.gmane.org/gmane.linux.debian.devel.kernel/79170 | 17:52 |
| bjf | clopez, and it really doesn't matter what greg says about it being "official" or not. we have to maintain the kernels we ship and that's what we do. (and i think we do it quite well) | 17:53 |
| clopez | I see | 17:53 |
| clopez | thanks for the explanation :) | 17:53 |
| bjf | clopez, for every LTS we reach out to greg and ask what he's thinking of picking for his LTS and he doesn't say until after we have picked ours and then he picks something else | 17:55 |
| clopez | I'm checking the amount of commits from canonical: 372 on 2013, not bad. | 17:59 |
| clopez | So the initial reason (few contributions) seems that not longer holds... I wonder if there is something else :\ | 18:02 |
| clopez | Maybe is because the specific canonical developer requesting to maintain the LTS branch has few contributions? | 18:27 |
| clopez | yeah, the link posted by ogasawara explains that... maybe you should consider putting a developer with a big enough track of contributions as the head of the stable branches in order to get greg blessing | 18:37 |
| clopez | some suggestions: http://sprunge.us/jfII | 18:37 |
| apw | clopez, or maybe we should select the person we think most qualified to get the job done | 21:37 |
| infinity | apw: I'm too busy. | 21:44 |
| === tdmackey_ is now known as tdmackey | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!