| === philipballew is now known as philip | ||
| * apw yawns | 09:00 | |
| * smb notes the world is brighter outside today | 09:03 | |
| smb | Must be that white stuff that suddenly appeared | 09:04 |
|---|---|---|
| apw | heh .. we may have a sunny day here for the first time in at least a month | 09:06 |
| smb | We had some of that too until today, which is dry but cold. Soon it is supposed to get warmer again and wet... | 09:09 |
| * apw wills the grass to grow | 09:11 | |
| === Guest46324 is now known as med_ | ||
| === med_ is now known as medberry | ||
| === ara is now known as Guest1754 | ||
| === ara_ is now known as ara | ||
| === ara is now known as Guest55288 | ||
| === Guest55288 is now known as ara_ | ||
| zequence | infinity: Hi. Will do right away. Been away for a couple of days | 14:01 |
| TooLmaN | Hi guys. I'm building my first Core system. What 12.04 kernel file should I grab from packages.ubuntu.com/precise/kernel/? The test unit only has 1GB RAM so I'm guessing 'linux-generic'? Thanks | 14:46 |
| TooLmaN | The kernel file is only a 1.7KB .DEB. Is that correct? | 14:51 |
| TooLmaN | seems way too small | 14:51 |
| TooLmaN | ok found a 35MB file that seems the right size. linux-image-3.2.0-56-generic-pae_i386 | 14:54 |
| apw | TooLmaN, linux-generic is the meta package not eh kernel itself | 14:54 |
| TooLmaN | apw: well that would make sense lol | 14:55 |
| TooLmaN | following https://wiki.ubuntu.com/Core/InstallationExample. It just says to grab a kernel from packages.ubuntu.com. Pretty vague to me | 14:55 |
| apw | TooLmaN, yeah it makes sense when you know what you are writing, but not to a new person, it is a wiki so if you have better words do change it, or add an example or something | 14:59 |
| TooLmaN | apw: I'll get it working before I try to change the wiki. Thanks for the info. | 15:00 |
| apw | TooLmaN, sure, just do fix it if it is confusing, as the next one will glad of it | 15:01 |
| TooLmaN | apw, will do. Trying to revive some older Wyse terminals as minimal Ubu boxes. | 15:03 |
| * ppisati disappears for a bit | 15:05 | |
| === ara_ is now known as ara | ||
| sforshee | rtg: I've been messing with this module signing thing some more, and when I build the package the modules are all signed | 15:26 |
| rtg | sforshee, thats what I found. I'm just downloading from the archive to check those packages | 15:26 |
| sforshee | rtg: I'm pretty sure I did that yesterday and found that they really aren't signed | 15:27 |
| rtg | sforshee, well, what extra step does the buildd perform ? I wonder if an sbuilder could reproduce this ? | 15:27 |
| apw | sforshee, what not working with signing for you ? | 15:28 |
| apw | rtg, ^^ | 15:28 |
| sforshee | apw: all the modules that come from the kernel package (i.e. not in -extras) are lacking signatures | 15:28 |
| apw | if you build it locally? | 15:28 |
| sforshee | no, they're there if I build locally | 15:29 |
| rtg | apw, and I just confirmed that. | 15:29 |
| rtg | how odd | 15:30 |
| rtg | apw, is that signed bullshit ? | 15:30 |
| rtg | is this* | 15:31 |
| sforshee | huh, actually if I download the package and unpack it the signatures are there | 15:31 |
| apw | which files are you checking if not hte ones in the package ? | 15:31 |
| rtg | sforshee, I'm not finding _any_ signatures in linux-image-3.12.0-4-generic_3.12.0-4.10_amd64.deb | 15:32 |
| rtg | dpkg -x linux-image-3.12.0-4-generic_3.12.0-4.10_amd64.deb tmp;find . -name "*.ko"|while read f;do if ! egrep -q "Module signature appended" $f;then echo $f;fi;done | 15:32 |
| sforshee | rtg: you're right, I checked the wrong file | 15:32 |
| rtg | apw, so, I'll bet this has something to do with the way the signed kernel is built, huh ? | 15:33 |
| apw | rtg, i think we have no problem :) | 15:41 |
| rtg | apw, explain ? | 15:41 |
| infinity | Are you stripping one package differently from the other? | 15:43 |
| infinity | Can't see how it would relate to the signed kernel, since that happens in an entirely different package, and is just vmlinux. | 15:44 |
| rtg | infinity, well, it doesn't happen with a local build. linux-image from the archive has no signatures. therefore, it seems that it must be something that happens on the builder (like the signing process). | 15:45 |
| infinity | The module signing process, perhaps, but not the kernel signing process. | 15:46 |
| infinity | It has to be something that happens during the linux build, not any other package. | 15:46 |
| infinity | And if it can't be reproduced locally, your local setup might not be as close to a proper package build as you think. | 15:47 |
| * infinity grabs the source to test. | 15:47 | |
| rtg | infinity, all modules are signed the same way regardless of the package they ultimately end up in. | 15:47 |
| infinity | rtg: Yes, and then some are being "unsigned". But that can only be happening during the package build, as we don't touch the packages once the buildd has given us a hash of all the debs it just created. :P | 15:48 |
| rtg | infinity, don't you have to touch linux-image in order to sign vmlinuz ? | 15:49 |
| infinity | rtg: No, vmlinuz isn't signed in linux-image. | 15:50 |
| infinity | rtg: Only in linux-signed-image. Which pulls a copy of vmlinuz to sign it. But certainly doesn't do ANYTHING to the original package. | 15:50 |
| infinity | (Not that we could even if we wanted to) | 15:50 |
| apw | right (sorry had a contractor here) | 15:58 |
| apw | module and kernle signing is separate | 15:58 |
| apw | you are saying some modules are unsigned, which ones | 15:58 |
| rtg | apw, yep, I see that signing _is_ separate | 15:59 |
| rtg | apw, so, even on ckt this is happening. linux-image modules are unsigned, whereas linux-image-extra _are_ signed. | 15:59 |
| apw | rtg, and yet in the main archive not ? (i assume it must be the same in the main as well) | 16:00 |
| apw | which version are you checking | 16:00 |
| rtg | apw, yes, it is the same in the main archive as well | 16:00 |
| apw | that seems unexpected as we make the extra package by making the main package as normal | 16:01 |
| rtg | apw, I've been looking at trusty in ckt (but I don't think version really matters) | 16:01 |
| apw | and hten moving the modules from the install to a new package | 16:01 |
| infinity | Version matters, as this is a recently-introduced bug. | 16:01 |
| rtg | infinity, actually, its been going on for awhile | 16:02 |
| infinity | How far back? | 16:02 |
| rtg | at least saucy for sure | 16:02 |
| infinity | What's the LP bug again? | 16:02 |
| apw | so give me a module which is in main so i can check on my saucy box | 16:02 |
| rtg | apw, lib/modules/3.13.0-0-generic/kernel/sound/pci/snd-ens1370.ko | 16:02 |
| infinity | apw: dpkg -L linux-image-$(uname -r) | grep modules | 16:03 |
| jsalisbury | ** | 16:04 |
| jsalisbury | ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting | 16:04 |
| jsalisbury | ** | 16:04 |
| apw | rtg, and how are we confirming they are unsigned | 16:04 |
| sforshee | apw: I'm looking for the string "Module signature appended" at the end | 16:05 |
| rtg | apw, find /lib/modules/`uname -r` -name "*.ko"|while read f;do if ! egrep -q "Module signature appended" $f;then echo $f;fi;done | 16:05 |
| rtg | apw, make sure you installed from the archive and not some local crack | 16:05 |
| sforshee | apw: I've got a saucy install here which seems to have the same results as with trusty | 16:06 |
| infinity | So, yeah, definitely unsigned in image and signed in image-extra here on 3.11.0-13-generic | 16:07 |
| infinity | Weeeeird. | 16:07 |
| infinity | Would be nice to figure out when this started being true. | 16:07 |
| apw | so that makes some sense, as extra is the 'left overs' from a proper install | 16:08 |
| apw | i can only assume we are stripping them as we move them over | 16:08 |
| apw | though i thought we used mv | 16:08 |
| rtg | apw, we're not as far as I can tell | 16:08 |
| rtg | I mean, we _are_ using mv | 16:08 |
| apw | yeah, we are ... so it is some post processing on linux-image which differs | 16:09 |
| apw | the package processing is the same too ? | 16:10 |
| rtg | skipdbg ? | 16:10 |
| apw | skipbdg ? | 16:11 |
| apw | we do run depmod on the ones in the main package | 16:11 |
| apw | and not on the ones in the other | 16:12 |
| rtg | apw, depmod isn't supposed to update anything. | 16:12 |
| apw | right i assume it is not but i was looking for differnces | 16:12 |
| apw | for 'skipdbg' we are makgin a separate version | 16:13 |
| apw | a separate install out of the kernel tree | 16:13 |
| rtg | apw, yeah, we're also doing an objcopy. | 16:13 |
| apw | yeah just saw that and yep i bet that is breaking it | 16:14 |
| apw | who got us to add that, kamal maybe | 16:14 |
| infinity | So, extra is definitely built in a "special" way. I imagine linux-image is getting stripped, and extra not. | 16:14 |
| rtg | lemme build with skipdbg=false | 16:14 |
| apw | infinity, no i think this is the objlink thing | 16:14 |
| kamal | apw, we're talking about what now? | 16:15 |
| rtg | infinity, I think its a post processing step that only happens on the buildds 'cause skipdbg keeps us from locally building a _giant_ debug file | 16:15 |
| rtg | kamal, we're pretty sure its your fault | 16:15 |
| kamal | rtg, well obviously, but it doesn't ring a bell to me | 16:15 |
| kamal | (not that that means much) | 16:16 |
| rtg | actually, this may go back a long ways. perhaps feisty. | 16:16 |
| kamal | soooo before my time | 16:16 |
| rtg | yeah, we're just yanking your chain. | 16:17 |
| kamal | yup | 16:17 |
| apw | rtg, so if the key has not been wacked when we package you might be able to do this again: | 16:30 |
| apw | Makefile:mod_sign_cmd = perl $(srctree)/scripts/sign-file $(CONFIG_MODULE_SIG_HASH) $(MODSECKEY) $(MODPUBKEY) | 16:30 |
| rtg | apw, yep, just looking at that file | 16:31 |
| apw | if we can resign them then it might be easier | 16:31 |
| apw | rather than changing the the main kernel makefiles | 16:31 |
| apw | and if it is there we should once we are finished make sure it is wacked | 16:32 |
| rtg | apw, yep, that is my thinking | 16:32 |
| apw | rtg, great | 16:35 |
| rtg | apw, starting a V=1 build with skipdbg=false. it'll take a bit, but I should have sufficient log to figure out the key business. | 16:36 |
| apw | yeah sometimes it is just work letting gomeisa take the strain | 16:38 |
| jsalisbury | ## | 16:50 |
| jsalisbury | ## Kernel team meeting in 10 minutes | 16:50 |
| jsalisbury | ## | 16:50 |
| === jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues December 3rd, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer! | ||
| lfaraone | apw: re 1206387 , the package currently in the queue restores OpenAFS functionality on 3.11 , so we're current through linux-lts-saucy, but that SRU does not contain the fix for trusty's config (bug 1246675) | 17:35 |
| ubot2 | Launchpad bug 1246675 in openafs (Ubuntu) "OpenAFS fails to build on trusty kernel 3.12 [openafs-modules-dkms 1.6.5.1-1: openafs kernel module failed to build]" [High,Fix released] https://launchpad.net/bugs/1246675 | 17:35 |
| lfaraone | bug 1206387 | 17:35 |
| ubot2 | Launchpad bug 1206387 in openafs (Ubuntu Precise) "openafs-modules-dkms 1.6.1-1+ubuntu0.2: module FTBFS on 3.8.0" [High,Confirmed] https://launchpad.net/bugs/1206387 | 17:35 |
| lfaraone | apw: Ideally I'd like the current package accepted and we'll just update for trusty's kernel once it gets closer to release. | 17:35 |
| apw | lfaraone, yeah that is an appropriate approach as we won't have 3.12 for very long | 17:39 |
| lfaraone | the only reason I bothered to introduce a delta this early in the cycle for openafs is because I'm running trusty on my laptop, and (some of) my email is in AFS maildirs. :P | 17:41 |
| apw | heh :) | 17:45 |
| apw | lfaraone, am i correct in thinking that we have released all of the versions you have penidng | 17:48 |
| apw | lfaraone, that reminds me, if you want to get a preview of the 3.13 kernel we have early (-rc1 ish) kernles in our PPA: https://launchpad.net/~canonical-kernel-team/+archive/ppa/+packages | 17:50 |
| lfaraone | apw: no, 1.6.5.1-1ubuntu0.12.04.1 is still waiting to get accepted to precise-proposed | 17:53 |
| apw | lfaraone, /me wonders why queue isn't showing it to him | 17:53 |
| lfaraone | sory 1.6.5.1-1~ubuntu0.12.04.1 | 17:53 |
| apw | ahh there it is, finger fail on my side. thanks | 17:54 |
| lfaraone | I messed up the first upload's version number, so I requested that it be rejected. | 17:54 |
| apw | ahh thats what it is | 17:55 |
| apw | lfaraone, i assume you are tyring to commonise the version here with that in trusty ? | 17:56 |
| lfaraone | apw: 1.6.5.1-1~ubuntu0.12.04.1 is a backport of 1.6.5.1-1 , which is in Saucy. | 17:57 |
| apw | lfaraone, is it a backport of 1.6.5.1-1ubuntu1 ? | 17:58 |
| lfaraone | apw: No. | 17:58 |
| apw | so i think the number might be a litle odd, i am unsure that the ~ would be neeed, as ubuntu0 is before ubuntu1 but, as long as it is 'before' i assume it is ok | 17:59 |
| lfaraone | apw: right, I uploaded the SRU before I uploaded the new verison in trusty. | 18:00 |
| apw | but i assume your version isn't newer than 1.6.5.1-1 which is what your currnet number implies, but ... not sure its a problem | 18:02 |
| lfaraone | apw: the SRU is the same code as 1.6.5.1-1, but if you upgrade your system should install the 1.6.5.1-1 package replacing the backported version. So, we need to make the SRU less than the version in the development release. | 18:04 |
| lfaraone | 1.6.5.1-1~ubuntu0.12.04.1 is less than 1.6.5.1-1 , the latter of which was previously in trusty. Its also less than 1.6.5.1-1ubuntu1, so upgrades will still work. | 18:05 |
| apw | ahh i see, got you | 18:05 |
| apw | lfaraone, there is a heap of change between what is applied in trusty (1.6.5.1-1 not th ubuntuN versions) and what was backported, in debian/rules which i thought i might have seen an upload to undo, but cannot find now | 18:32 |
| lfaraone | apw: the debian/rules changes were in Anders' original debdiff as changes needed to build on precise, I believe. | 18:33 |
| apw | hmmm, ok | 18:34 |
| lfaraone | apw: in any case, it just moves logic from override_dh_install-arch to override_dh_install | 18:36 |
| lfaraone | and removes override_dh_install-arch. Perhaps the disntinction between override_dh_install-arch and override_dh_install-indep didn't exist in precise's debhelper? | 18:37 |
| apw | yeah that is believeable | 18:37 |
| lfaraone | https://lists.debian.org/debian-devel/2011/12/msg00092.html implies the options were new in Debian in late 2011, so I imagine they may not have made it to precise before DIF / FF | 18:38 |
| apw | yeah thanks | 18:38 |
| infinity | Could relate to this: | 18:47 |
| infinity | debhelper (9.20120608) unstable; urgency=low | 18:47 |
| infinity | * dh: When there's an -indep override target without -arch, or vice versa, | 18:47 |
| infinity | avoid acting on packages covered by the override target when running | 18:47 |
| infinity | the command for packages not covered by it. Closes: #676462 | 18:48 |
| infinity | -- Joey Hess <joeyh@debian.org> Fri, 08 Jun 2012 13:15:48 -0400 | 18:48 |
| apw | nnng what language is that written in | 18:48 |
| infinity | apw: I think it's saying that if you have "foo-indep", "foo" would run for those same packages again, unless you also have a "foo-arch". | 18:50 |
| infinity | (In which case, "foo" wouldn't happen at all, just the two overrides) | 18:50 |
| infinity | So, the fix could be to simply add an override_dh_install-indep that calls dh_install -i | 18:51 |
| infinity | But I haven't looked at the diff, as long as it's sane, I don't care. | 18:51 |
| apw | switches to the omre normal overrides | 18:53 |
| apw | lfaraone, i asusme this has been tested with at least the P and S kernels as it seems to carry a bump for everything | 19:00 |
| apw | lfaraone, i wonder when we went to 3.5 we just plled in the updates for the kernel componet, not the test of it, why are we not doing the same for this one? | 19:03 |
| lfaraone | apw: the cherrypick needed would be really bit, ref https://bugs.launchpad.net/ubuntu/+source/openafs/+bug/1206387/comments/2 | 19:11 |
| ubot2 | Launchpad bug 1206387 in openafs (Ubuntu Precise) "openafs-modules-dkms 1.6.1-1+ubuntu0.2: module FTBFS on 3.8.0" [High,Confirmed] | 19:11 |
| lfaraone | *big | 19:11 |
| lfaraone | apw: this has been in the OpenAFS PPA for a month, and I believe is in use by everyone at MIT running the HWE kernels. I had installed the packages on my system running non-HWE and they worked for me. | 19:15 |
| lfaraone | I believe CMU is also running 1.6.5.1 on Precise via the PPA. | 19:16 |
| apw | if my memory of hte main users of afs that might well be pretty much all of them ... | 19:16 |
| apw | lfaraone, and i guess we get more change for 3.12 and likely again for 3.13 | 19:16 |
| infinity | The more important question isn't "does this work on 3.8", but "does it break on 3.2"? | 19:17 |
| apw | i think we do need to know it has been tested in all the valid combinations P P+Q P+R P+S | 19:17 |
| lfaraone | apw: is P+Q supported, still? | 19:18 |
| apw | lfaraone, not for much longer i suspect indeed | 19:18 |
| apw | i do so wish the HWE backports were in per series PPAs and not in the archive | 19:18 |
| infinity | All of them are supported until after 14.04 comes out. | 19:19 |
| lfaraone | apw: yeah… me too. | 19:19 |
| infinity | But it seems unlikely that you'd craft a kernel module that works on 3.2 and 3.8 but not 3.5... | 19:19 |
| apw | infinity, yeah that | 19:19 |
| lfaraone | Anyway, I can install ALL the kernels in a VM and double check. | 19:19 |
| apw | lfaraone, that would be great | 19:20 |
| stgraber | rtg: ping | 19:24 |
| rtg | stgraber, on the phone | 19:24 |
| stgraber | rtg: ok. When you're back, can you let me know what package your verification-done-precise applies to in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1205284? | 19:25 |
| ubot2 | Launchpad bug 1205284 in linux (Ubuntu Precise) "linux-tools naming is not scalable to multiple source packages" [Medium,Fix committed] | 19:25 |
| stgraber | rtg: if that's apt, then I'll release it to -updates. The rest will go through the standard kernel SRU process. | 19:25 |
| rtg | stgraber, bug apw about that | 19:25 |
| apw | stgraber, hi ... which package are you considering the bug for sru wise | 19:28 |
| stgraber | apw: apt | 19:29 |
| stgraber | apw: the sru report says apt has been in -proposed for long enough and if rtg's verification-done-precise tag applies to it, then I can release it, but due to the high number of sources linked to that bug and lack of comment, I can't know whether the tag was meant for apt or for some of those linux sources... | 19:30 |
| bjf | stgraber, i believe rtg was responding to the previous comment from my bug spamming asking for testing/verification | 19:31 |
| bjf | stgraber, that would make it (the rtg tag) applicable to the linux package | 19:31 |
| apw | i don't expect rtg's does apply there... infinity your apt update for that linux-tools bug was about getting the apt "mark as autoinstalled" stuff right for toosl right ? | 19:31 |
| apw | infinity, if so i can veryify that ... | 19:31 |
| apw | stgraber, and yeah these tags are uttrely usless on these bugs, can we get them fixed somehow to include the package where there is more than one/ | 19:32 |
| apw | ? | 19:32 |
| rtg | yeah, my change to the tag would have been for linux, not apt | 19:32 |
| apw | stgraber, i believe i understnad that apt change and can verify it | 19:34 |
| stgraber | apw: I guess we could extend the syntax to be verification-done[-<source name>][-<series name>] which should work for those cases (at least so long as we don't have source package names that match series name ;)) | 19:34 |
| stgraber | apw: that'd be great! | 19:34 |
| stgraber | bdmurray: ^ | 19:34 |
| bjf | stgraber, does anyone other that the kernel team use those verification tags? | 19:35 |
| stgraber | bjf: sure, all SRUs do | 19:35 |
| bjf | huh | 19:35 |
| bjf | i don't remember using that as an example but I must have | 19:36 |
| stgraber | and that usually ends up being a bit of a mess when multiple sources are concerned as we need to differentiate which have been tested and which haven't :) | 19:36 |
| === thomi_ is now known as thomi | ||
| infinity | apw, stgraber: I can verify that apt change DTRT... When you have tools installed with the new naming scheme. | 19:51 |
| infinity | (Which is only lts-saucy at this point, isn't it?... I don't recall now) | 19:51 |
| stgraber | infinity: the bug report lists linux-lts-saucy and linux as affected for precise | 19:52 |
| infinity | stgraber: Well, it's not fixed in the current precise-proposed... | 19:55 |
| infinity | Looks like the bug ref in the changelog was just about updating the wrappers, not about the packaging. | 19:56 |
| infinity | apw: ^ | 19:56 |
| apw | infinity, linux is affected as it carries the new wrappers for all releases, but does not get switched to that form | 19:57 |
| apw | stgraber, ^ | 19:57 |
| infinity | apw: Did we intent to switch the package names for linux/precise too, or just leave it be? | 19:57 |
| infinity | s/intent/intend/ | 19:57 |
| apw | only linux-lts-saucy is using the new form indeed, so the apt changes only affect there | 19:57 |
| apw | i was not intending on changing the older releases unless somone whined no | 19:58 |
| * infinity nods. | 19:58 | |
| * rtg -> lunch | 20:05 | |
| apw | infinity, so are you or am i, verifying this apt thingy | 20:11 |
| apw | infinity, i have a vm availble to do it | 20:12 |
| infinity | apw: Go nuts, if you're all set up to verify. | 20:17 |
| rtg | ogasawara, re: bug #1255297 - were you gonna send a patch to the list ? Its been at least 15 minutes. | 20:39 |
| ubot2 | Launchpad bug 1255297 in linux (Ubuntu Saucy) "XPS 15 SD Card Reader Support" [Medium,In progress] https://launchpad.net/bugs/1255297 | 20:39 |
| ogasawara | rtg: sheesh, I'm about to hit send | 20:40 |
| rtg | :) | 20:41 |
| bjf | ogasawara, it looks like the next SRU cycles kernels will be the one for 12.04.4 | 21:06 |
| ogasawara | bjf: ack, I figured it would be | 21:07 |
| ogasawara | bjf: can we make sure that patch for 1255297 lands in it | 21:07 |
| bjf | ogasawara, i'm thinking this next cycle is going to be kinda long given holidays and release prep | 21:07 |
| bjf | ogasawara, as long as it doesn't cause any regressions i don't see why it won't make it | 21:08 |
| ogasawara | bjf: ack | 21:08 |
| ogasawara | bjf: and ack on making this next cycle a little longer | 21:08 |
| bjf | ogasawara, but just for you i can make sure that commit gets in :-) | 21:09 |
| ogasawara | bjf: heh, thanks :) | 21:09 |
| apw | stgraber, ok i've confired the apt changes (added same to the bug) and vairous other bits | 21:16 |
| stgraber | apw: cool, thanks. I'll release the apt SRU then. | 21:41 |
| apw | stgraber, wonderful thanks | 21:42 |
| apw | rtg, that sign fix turned out nice and simple, and the where of its occurance says why i have never seen it, as i nearly always am running your latest shiney kernel hand compiled | 21:50 |
| rtg | apw, yep, though I'm still struggling to get a trusty upload to build so that I can be absolutely sure. | 21:51 |
| rtg | FTBS: make[2]: Leaving directory `/build/buildd/linux-3.12.0/debian/build/tools-perarch/tools/lib/traceevent' | 21:51 |
| rtg | LINK perf | 21:51 |
| rtg | /usr/bin/ld: cannot find -liberty | 21:51 |
| rtg | apw, I think 'UBUNTU: [Config] switch build-depends to libiberty-dev' fixes the FTBS (buils testing as we speak) | 21:52 |
| rtg | build* | 21:52 |
| apw | ahh i didn't realise he was wacking it from the old place ... | 21:53 |
| rtg | yeah, its gone | 21:53 |
| apw | that was rather quick :) | 21:53 |
| apw | i figured we had as long as it took to get 3.13 in, seems i was wrong | 21:54 |
| * rtg -> EOD | 22:31 | |
| === medberry is now known as med_ | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!