| xnox | Mirv, i believe anybody with any upload rights can retrigger any autopkgtests | 00:07 |
|---|---|---|
| xnox | so like majority of people | 00:07 |
| tsimonq2 | oh nice | 00:07 |
| xnox | ScottK, can I become Ubuntu Backports team member? I need to upload & approve a few things that should live in backports long-term. Primary looking at backporting security uploads, to existing backports; as well as monitoring/approving/uploading things like btrfs-tools, tinc VPN, and othrs. | 00:09 |
| xnox | could you bless me? and I shall follow https://wiki.ubuntu.com/UbuntuBackports as best as I can. | 00:09 |
| tsimonq2 | xnox: while you're here, what gets uploaded to backports? | 00:13 |
| tsimonq2 | I don't know what does lol | 00:13 |
| xnox | tsimonq2, read wiki... | 00:16 |
| * tsimonq2 facepalms at himself | 00:19 | |
| tsimonq2 | sorry, long day | 00:19 |
| tsimonq2 | have a nice evening xnox | 00:20 |
| xnox | no problems =) and i should go to bed. | 00:29 |
| tsimonq2 | o/ xnox | 00:30 |
| === JanC is now known as Guest19696 | ||
| === JanC_ is now known as JanC | ||
| ScottK | xnox: I'm not active with ubuntu-backports management anymore. IIRC micahg is who you want. | 04:41 |
| Mirv | xnox: I know | 04:45 |
| Mirv | pitti: is there some sort of auto-retry nowadays in autopkgtest? I'm just wondering how the akonadi s390x tests seem to be "always" running when I check them, and they did seem to do so during the weekend too while they finally finished/Passed between Sat-Sun night | 04:47 |
| micahg | xnox: let's chat some time, we can probably work something out ;) | 05:04 |
| cpaelzer | good morning | 05:27 |
| Mirv | mardy would like an archive admin to (pre)binNEW review the package account-plugin-mcloud from https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-059/+sourcepub/6844940/+listing-archive-extra | 05:44 |
| pitti | Mirv: no, akonadi on s390x "just" breaks the testbed and thus causes an endless stream of auto-retries; I'll look into it | 06:17 |
| pitti | tsimonq2: the script is really just a prototype; if you want to use it for real, rather ask robru -- he has a much better one, tweaked for PPAs (bileto silos) and with much better caching | 06:18 |
| Mirv | ok | 06:22 |
| Saviq | RAOF, yeah, Mirv did it - thanks guys! | 06:26 |
| pitti | Mirv: done, qt should land in the next britney run | 07:00 |
| Mirv | pitti: thank you | 07:02 |
| === Lawayney is now known as Laney | ||
| === seb128_ is now known as seb128 | ||
| === vrruiz_ is now known as rvr | ||
| cpaelzer | pitti: hi apw and I wondered if you could share a thought on constructing adt-run parms in a way that the tests would run against a kernel from ppa:canonical-kernel-team/ubuntu/unstable? | 09:38 |
| cpaelzer | pitti: apw already send you a pm, but it might be better to do a three+whoever wants discussion here | 09:38 |
| pitti | hey cpaelzer | 09:39 |
| pitti | cpaelzer: do you just want to test this locally, or does it need to be on the infra? | 09:40 |
| pitti | cpaelzer: locally it's easiest to just start a VM, install that kernel, and run autopkgtest with --null in that VM against that DKMS package | 09:40 |
| pitti | err "-- null" | 09:40 |
| pitti | cpaelzer: you can also install the kernel from the PPA via --setup-commands, but that's a bit complicated; any existing log against a kernel PPA shows the command line | 09:41 |
| pitti | cpaelzer: e. g. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety-canonical-kernel-team-unstable/yakkety/amd64/a/acpi-call/20160918_090545@/log.gz | 09:42 |
| cpaelzer | wow you write fast or these messages got batched somwhere :-) | 09:42 |
| cpaelzer | I'd have liked to test locally | 09:42 |
| pitti | got batched apparently :) (looks normal at my end) | 09:43 |
| apw | yeah timestamps look like quick but not magical typing speed here :) | 09:44 |
| cpaelzer | thanks pitti I'll try for the setup commands first and let you know, falling back to a null driver in case of too much issues | 09:45 |
| cpaelzer | apw: pitti: adt-run [12:07:55]: testbed running kernel: Linux 4.8.0-11-generic | 10:17 |
| cpaelzer | thanks pitti | 10:17 |
| pitti | cpaelzer: cool :) | 10:17 |
| cpaelzer | this is the cmdline that works for my dpdk test | 10:17 |
| cpaelzer | just in case anybody needs something similar soon | 10:17 |
| cpaelzer | adt-run --shell --debug --apt-upgrade --setup-commands 'apt-key adv --keyserver keyserver.ubuntu.com --recv-key 110E21D8B0E2A1F0243AF6820856F197B892ACEA' --setup-commands 'REL=$(sed -rn "/^(deb|deb-src) .*(ubuntu.com|ftpmaster)/ { s/^[^ ]+ +(\[.*\] *)?[^ ]* +([^ -]+) +.*$/\2/p; q }" /etc/apt/sources.list); echo "deb http://ppa.launchpad.net/canonical-kernel-team/unstable/ubuntu $REL main" > /etc/apt/sources.list.d/autopkgtest- | 10:17 |
| cpaelzer | canonical-kernel-team-unstable.list; echo "deb-src http://ppa.launchpad.net/canonical-kernel-team/unstable/ubuntu $REL main" >> /etc/apt/sources.list.d/autopkgtest-canonical-kernel-team-unstable.list; ' --setup-commands 'apt-get update; apt-get install -y linux-image-generic linux-headers-generic' --binary *16.07-0ubuntu3*.deb --no-built-binaries --source dpdk_16.07-0ubuntu3.dsc --- adt-virt-qemu --cpus 4 --ram-size=2048 ~/work/ | 10:17 |
| cpaelzer | adt-yakkety-amd64-cloud.img | 10:17 |
| cpaelzer | derived from the logs you linked pitti | 10:18 |
| === hikiko is now known as hikiko|ln | ||
| jamespage | pitti, is (more) of an ubuntu veteran than I am - do you know if its possible to generate merge reports between ubuntu and debian experimental? | 11:01 |
| jamespage | I don't appear to have that in my knowledge set | 11:01 |
| jamespage | hmm used to be able todo it using bzr branches | 11:02 |
| jamespage | maybe I need to use nacc and rbasak package import thingumy | 11:03 |
| pitti | jamespage: neither have I, I'm afraid; I guess one coudl configure MoM to do that, but I don't think we actually have that | 11:10 |
| pitti | jamespage: but I've never actually used the auto-merges, they are almost always cluttered | 11:10 |
| jamespage | pitti, where is the source for MoM? | 11:10 |
| pitti | jamespage: IMHO it's much easier to grab the ubuntu diff and apply it to the exp package | 11:10 |
| jamespage | yeah you're probably right | 11:11 |
| pitti | jamespage: (and clean up the obsolete bits before, as usually) | 11:11 |
| jamespage | I'll do what | 11:11 |
| jamespage | that | 11:11 |
| jamespage | golly can't type today | 11:11 |
| pitti | jamespage: you know patches.u.c.? | 11:11 |
| jamespage | pitti, yes | 11:14 |
| === hikiko|ln is now known as hikiko | ||
| jamespage | pitti, hey - can we drop the upload of python-pymysql I just did to yakkety? its still in proposed, and will create a whole load of headache for openstack packages | 12:03 |
| jamespage | my mistake - got overzealous with taking new point releases from debian | 12:04 |
| jamespage | https://launchpad.net/ubuntu/+source/python-pymysql/0.7.9-1ubuntu1 | 12:04 |
| jamespage | 0.7.6 is just fine | 12:04 |
| pitti | jamespage: https://launchpad.net/ubuntu/+source/python-pymysql/+publishinghistory | 12:06 |
| pitti | jamespage: sorry, it got published to -release half an hour ago | 12:06 |
| jamespage | pitti, I think its still in proposed no? | 12:06 |
| jamespage | Pending rather than published? | 12:06 |
| pitti | jamespage: so it now needs to be uploaded as 0.7.9+really0.7.6 or so (or fix stuff to get along with 0.7.9) | 12:07 |
| jamespage | yah published to proposed 2 mins about | 12:07 |
| pitti | jamespage: no, it's published | 12:07 |
| pitti | also, can't really stop "pending" any more | 12:07 |
| jamespage | pitti, so we can't drop things from yakkety-proposed? | 12:07 |
| pitti | jamespage: we can | 12:08 |
| jamespage | Yakketyproposed2 minutes agomainmisc | 12:08 |
| pitti | but it's in yakkety-release already | 12:08 |
| pitti | jamespage: oh, sorry, I mis-read | 12:08 |
| pitti | jamespage: sure, I'll remove it | 12:08 |
| jamespage | pitti, thankyou! | 12:08 |
| pitti | done | 12:08 |
| GunnarHj | pitti: Hi Martin, I can't find ubuntu-docs (or any other -docs package) at https://translations.launchpad.net/ubuntu/yakkety/+translations . Same thing in xenial. What has happened? | 12:36 |
| === _salem is now known as salem_ | ||
| seb128 | GunnarHj, https://translations.launchpad.net/ubuntu/yakkety/+source/<name> seems to work? | 12:47 |
| GunnarHj | seb128: Indeed. But the translators typically use the overview pages to find untranslated strings, and currently they don't see the -docs packages that way. | 12:48 |
| seb128 | tthat might be more of a launchpad question | 12:52 |
| seb128 | or maybe dpm knows | 12:52 |
| GunnarHj | dpm_: ^ ? | 12:53 |
| GunnarHj | seb128: Is there a quick access to someone at LP? | 12:54 |
| seb128 | #ubuntu-launchpad | 12:54 |
| seb128 | no, sorry | 12:54 |
| seb128 | #launchpad | 12:54 |
| GunnarHj | seb128: Ok, thank, will try that. I may also post to the ubuntu-translators list to call their attention to it. | 12:55 |
| seb128 | GunnarHj, yw | 12:59 |
| dpm_ | seb128, GunnarHj, this sounds to me as if the .pot files for the docs packages did either not get uploaded or not approved | 13:05 |
| GunnarHj | dpm_: They were both uploaded and approved, and taken into account in the latest language-pack-gnome-xx-base packages. | 13:07 |
| seb128 | dpm_, the source is translatable just fine | 13:08 |
| seb128 | dpm_, it's just not listed on the view GunnarHj asked about | 13:08 |
| seb128 | in the list | 13:08 |
| seb128 | dpm_, he got a reply on #launchpad | 13:09 |
| GunnarHj | seb128, dpm: Mystery resolved. wgrant pointed out that the pages list the template names, not the package names, which in this case is ubuntu-help. | 13:14 |
| seb128 | yeah, I read that | 13:14 |
| seb128 | good then, no bug ;-) | 13:14 |
| GunnarHj | seb128: Right. :) | 13:14 |
| GunnarHj | seb128: Only in my head. :( | 13:15 |
| * Laney offers GunnarHj some bug spray to help deal with that | 13:17 | |
| GunnarHj | Laney: Haha. I may need a dozen of those. :) | 13:18 |
| dpm | seb128, GunnarHj, cool | 13:25 |
| sforshee | pitti: I have a machine that after upgrading to yakkety sometimes hangs on boot then drops to maintenance mode. When this happens the journal shows that <disk>.device/start jobs are timing out, which I think is becuase udev isn't adding the systemd tag to devices. Any ideas why this would happen? | 13:29 |
| semiosis | Odd_Bloke: are you around? can you update livecd-rootfs on the cloud images build servers? | 13:31 |
| semiosis | Odd_Bloke: the last build from the 14th doesn't have the resolv.conf fix from livecd-rootfs 2.408.4 | 13:31 |
| semiosis | or if not Odd_Bloke, anyone else? | 13:47 |
| semiosis | this is regarding bug 1621393 | 13:48 |
| ubottu | bug 1621393 in cloud-images "xenial64 image (20160907.1.0) has a broken (empty) /etc/resolv.conf" [Undecided,New] https://launchpad.net/bugs/1621393 | 13:48 |
| smoser | pitti, around ? | 13:48 |
| smoser | i actually do not understand https://bugs.launchpad.net/ubuntu/+source/walinuxagent/+bug/1624596 completely. | 13:48 |
| ubottu | Launchpad bug 1624596 in walinuxagent (Ubuntu) "ephemeral-disk-warning.service causes ordering cycle on multi-user.target" [Medium,Triaged] | 13:48 |
| smoser | https://git.launchpad.net/~usd-import-team/ubuntu/+source/walinuxagent/tree/debian/ephemeral-disk-warning.service?h=ubuntu/yakkety is the ephemeral-disk-warning.service . | 13:51 |
| smoser | it seems to me that having 'WantedBy' of multi-user.target implies Before | 13:51 |
| smoser | is that true? | 13:51 |
| pitti | smoser: yes, normally Requires= and Wants= implies Before=, since that's almost always what you want | 14:05 |
| pitti | smoser: i. e. you define a target, define its dependencies, and usually you want the target to get active only after all your deps are started | 14:05 |
| pitti | smoser: so if you want a dep to start after your target, you need an explicit After= | 14:06 |
| smoser | yeah, and that makes sense. but since it is not strictly wrong, it should have decided that there was an ordering issue and dropped it. | 14:06 |
| pitti | see man systemd.tareget, "Automatic Dependencies"; you can turn that off with DefaultDependencies=no if you don't care about the order, but I guess it's better to be explicit about it | 14:09 |
| smoser | pitti, so do you agree with my suggested fix there ? | 14:14 |
| pitti | smoser: looking | 14:15 |
| pitti | smoser: structurally that will avoid the dep loop indeed; you would know better if it's semantically right, i. e. cloud-final does not need to run for ephemeral-disk-warning.service to work (but by the name I suppose it doesn't) | 14:16 |
| pitti | adding an actual Description= might be nice, while you are at it? | 14:16 |
| smoser | i'll submit merge proposal upstream for both | 14:18 |
| smoser | i'm not actually sure *why* they had that after. | 14:19 |
| pitti | cheers | 14:19 |
| pitti | smoser: if it's just checking hardware and spit out some warning, that wouldn't need any particular ordering at all, does it? | 14:19 |
| smoser | pitti, well, cloud-init is going to format that disk | 14:23 |
| === ricotz_ is now known as ricotz | ||
| gpiccoli | pitti: ping | 14:47 |
| pitti | hello gpiccoli | 14:48 |
| gpiccoli | Hi pitti, how are you doing? | 14:48 |
| gpiccoli | Sorry to bother you! | 14:48 |
| gpiccoli | If you have some time, wanna discuss quickly LP 1615021 =) | 14:48 |
| ubottu | Error: Could not gather data from Launchpad for bug #1615021 (https://launchpad.net/bugs/1615021). The error has been logged | 14:48 |
| pitti | gpiccoli: aah, so it wasn't really hanging, the installer just showed up on the serial console when you expected it on VT1 (or vice versa)? | 14:52 |
| gpiccoli | yeah pitti hehehe | 14:53 |
| gpiccoli | It showed on tty1 (I guess) whereas I was expecting in hvc0 ! | 14:53 |
| gpiccoli | Wanna thank you for all the help and effort on this | 14:54 |
| pitti | gpiccoli: TBH I don't actually know how the kernel (or maybe d-i) interpret console= and what the "primary" console is | 14:54 |
| gpiccoli | Also, I have some questions pitti | 14:54 |
| gpiccoli | One of the questions is exactly about this lol | 14:54 |
| pitti | my gut feeling is that the installer doesn't care and just uses teh "current" console /dev/tty or /dev/console | 14:54 |
| gpiccoli | I did a little digging on initramfs, and seems bterm is used to start the debian-installer menu | 14:55 |
| pitti | but I'm not sure if it actually interprets the command line by itself, or whether the linux kernel has some semantics of "last/first console= is the primary one" or so | 14:55 |
| gpiccoli | And it takes one of these consoles as env variable | 14:55 |
| pitti | I notice that at least in VMs I do see the kernel and boot messages on *all* consoles though | 14:55 |
| pitti | cyphermox, cjwatson: do you happen to know if d-i interprets console= kernel cmdline args to find out what the "primary" one should be? | 14:56 |
| gpiccoli | yes, the console kernel param is used to show the kernel messages on multiple console | 14:56 |
| pitti | cyphermox, cjwatson: or do they just use /dev/console or don't care at all and just use whatever the kernel presents as /dev/tty? | 14:56 |
| gpiccoli | But I guess the last one is used to show debian isntaller | 14:56 |
| gpiccoli | Let's see the opinion of cyphermox and cjwatson | 14:57 |
| pitti | gpiccoli: nice finding with "any command line customization works", what a red herring! | 14:57 |
| pitti | gpiccoli: i. e. you always removed the default console= and just put in hvc0? | 14:57 |
| cjwatson | If it cares it'll be in rootskel (for the installer itself) and finish-install (for setup of the installed system) | 14:58 |
| cjwatson | Those are fairly small components so you can poke around there | 14:58 |
| pitti | cjwatson: thanks; indeed both have tons of hits on egrep -r 'console|cmdline|tty' | 14:59 |
| cjwatson | There's some logic in rootskel that appears to prefer the last console on the command line | 14:59 |
| cjwatson | I haven't looked around exhaustively | 14:59 |
| pitti | …………………………………………# Locate the last enabled console present on the command line | 14:59 |
| pitti | rootskel-1.115ubuntu1/src/sbin/reopen-console-linux | 14:59 |
| pitti | and defaulting to /dev/console if no console= is given at all | 14:59 |
| pitti | gpiccoli: posted to the bug for posterity | 15:02 |
| gpiccoli | pitti, very nice, thanks a lot! | 15:05 |
| pitti | gpiccoli: so all good now? | 15:05 |
| gpiccoli | since the default is /dev/console, that explain a lot! | 15:06 |
| gpiccoli | Well, it ends the bug I guess, but I have a more is_this_feature_interesting question now | 15:06 |
| pitti | gpiccoli: though I still don't know how the kernel determines what /dev/console should point to (both with and in absence of console= arguments) | 15:06 |
| gpiccoli | (not sure either, will investigate, since it's curious =) ) | 15:07 |
| gpiccoli | I noticed some installers in other distros makes use of the following strategy | 15:07 |
| cyphermox | pitti: gpiccoli: as I recall we do read the setting | 15:07 |
| gpiccoli | They open a terminal multiplexer (as screen or tmux) in base console (/dev/console hehehe) and attach to it in all other consoles | 15:08 |
| gpiccoli | So, the installer is visible in every terminal, and we have a bonus of being able to open a console along the installer too | 15:08 |
| gpiccoli | since terminal multiplexers have the "window" feature! | 15:08 |
| gpiccoli | Would this be a good/accepted addition to Ubuntu installer? | 15:09 |
| gpiccoli | Do you think it's interesting? | 15:09 |
| pitti | gpiccoli: https://www.kernel.org/doc/Documentation/serial-console.txt | 15:09 |
| pitti | this seems to agree that the last console= is what /dev/console will "point" to (but kernel messages still go to all of them) | 15:09 |
| cyphermox | yes | 15:09 |
| cyphermox | last one wins | 15:09 |
| gpiccoli | ouch, this is really interesting to know! THanks folks | 15:10 |
| cyphermox | pitti: is there a bug I should watch or are you working on it already? | 15:10 |
| gpiccoli | What about the multiplexer cyphermox, cjwatson and pitti, seems interesting/feasible to you? | 15:10 |
| cjwatson | I'm no longer involved in this, please untag me | 15:11 |
| pitti | gpiccoli: sounds interesting indeed, although not exactly simple; for example, different consoles can (and will) have different geometries, term capabilities (color codes/fonts etc.) | 15:11 |
| cjwatson | But I do recall it coming up recently on debian-boot@ | 15:11 |
| gpiccoli | cjwatson, unatagged! Sorry =/ | 15:11 |
| cjwatson | So I'd suggest looking through recent list archives there | 15:11 |
| pitti | gpiccoli: so I think just a naïve implementation will look awful in a lot of cases | 15:12 |
| gpiccoli | Yeah pitti, you're right! It would need to "base" on the simpler console hehehe | 15:12 |
| cjwatson | Some stuff on https://lists.debian.org/debian-boot/2016/08/threads.html | 15:12 |
| cyphermox | I remember there was some old command you could poke to set /dev/console or otherwise get console messages on the current tty (or remove them from there, as it was most often the case) | 15:12 |
| cyphermox | but maybe it's just old memories from Slowlaris days | 15:13 |
| gpiccoli | Very nice cjwatson, thank you! | 15:13 |
| gpiccoli | cyphermox, hahaha . I guess the best it to set hvc0 as console | 15:13 |
| gpiccoli | Or set nothing, which works for us | 15:14 |
| cyphermox | yeah | 15:14 |
| gpiccoli | Great, thanks very much for your help! | 15:14 |
| bdmurray | tseliot: Should bug 1619306 be verification-done? | 15:36 |
| ubottu | bug 1619306 in ubuntu-drivers-common (Ubuntu Xenial) "SRU request: Include the 367 driver in Ubuntu 16.04" [High,Fix committed] https://launchpad.net/bugs/1619306 | 15:36 |
| tseliot | bdmurray: yes, as it was verified. I changed it to the wrong status, I suppose | 15:37 |
| doko | apw: is there a reason to build linux 4.8 with gcc 5? I mean, gcc-6 was released way before linux 4.8 | 16:19 |
| seb128 | doko, hey, could you check if there is still anything missing in https://bugs.launchpad.net/ubuntu/+source/libphonenumber/+bug/1618178 ? it looks like the previous comments got addressed | 16:20 |
| ubottu | Launchpad bug 1618178 in libphonenumber (Ubuntu) "[MIR] libphonenumber" [Undecided,New] | 16:20 |
| doko | seb128: still on my list, but it still doesn't show up on http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg | 16:22 |
| seb128 | why would it? | 16:22 |
| seb128 | we have not seeded unity8-desktop-session yet | 16:22 |
| seb128 | since some of the MIRs are not acked yet | 16:23 |
| seb128 | it would be backward to add the depends before getting the MIR | 16:23 |
| doko | ahh, it's part of unity ... | 16:24 |
| seb128 | yes... | 16:26 |
| robru | pitti: tsimonq2: https://git.launchpad.net/bileto/tree/britney/fetch-indexes | 16:41 |
| nacc | infinity: quick q, re: dpkg-dev. It seems like with the move in debian to use (1.18.8) to replace the changelog program parsers with perl modules, some changelogs that were previously parseable now lead to parse errors. Is there any guarantee that shouldn't have happened? It seems correct for it to be a parse error now, but it is also a change in behavior. | 18:38 |
| nacc | infinity: i can also take my question to debian, just saw you had the last upload and figured i'd check if you knew | 18:38 |
| infinity | nacc: I'd file a bug with Debian including the specific changelog entries. Though, if they're obviously syntactically incorrect, I'd be more inclined to say it was a bug that they parsed before. :P | 18:42 |
| infinity | nacc: There's certainly no harm in fixing old changelog entries. | 18:42 |
| nacc | infinity: yeah, that's kind of my approach, but it seems like at least at one point in debian's history, bad changelogs were more frequent than now. Makes for a headache for importing :) | 18:42 |
| nacc | infinity: thanks for the tips | 18:43 |
| nacc | if i had to guess, it's almost certainly fixed in current publishes, it's just historical publishes that have unparseable entries | 18:43 |
| infinity | nacc: What, specifically, isn't working that used to? | 18:43 |
| infinity | nacc: dpkg-parsechangelog giving up when it encounters a broken entry? | 18:45 |
| infinity | nacc: (ie: dpkg can't parse its own changelog before 1.2.13) | 18:45 |
| nacc | infinity: so, e.g., srcpkg:at 3.1.10.1 (first version published in debian available in lp publishing history) has a changelog tail that looks like: http://paste.ubuntu.com/23203956/. With 16.04's `dpkg-parsechangelog -l- --format rfc822 -SVersion --all` spat some warnings, but still returned the list of published versions. In 16.10 it errors out and doesn't output any versions. | 18:46 |
| infinity | nacc: Indeed, it stops parsing at "Old Changelog:" | 18:48 |
| infinity | For good reasons. | 18:48 |
| nacc | yeah, i'm not saying it's wrong, per se, to change behavior. I was just surprised :) | 18:49 |
| infinity | http://paste.ubuntu.com/23203975/ | 18:49 |
| nacc | interesting | 18:50 |
| infinity | nacc: Anyhow, I'm not sure I see that as a bug or a feature, but you'd be better of discussing it with guillem. | 18:50 |
| nacc | infinity: yep, i'll do that, thanks! | 18:50 |
| nacc | infinity: for context, this is a git-importer for launchpad publishing history of source packages. So in theory, when i'm importing 3.1.10.1, e.g., as published in lp, I only have access to 3.1.10.1's source. But it looks like it's a bound range with bad entries, so possible for me to fix (with a new feature i just finsihed implementing :) | 18:52 |
| infinity | nacc: Ahh, but when importing 3.1.10.1, you shouldn't care about versions before it, I would assume. | 18:53 |
| infinity | nacc: And getting just the top entry should still work, no? | 18:53 |
| nacc | infinity: yeah, that's true -- but the code in quesiton is generic and looks at the entire history to see where our next common ancestor is between the changelog's entries and the published history for that distro/series/pocket | 18:54 |
| * infinity goes to hunt down an animal to lunch on. | 19:03 | |
| semiosis | is anyone around who can help update livecd-rootfs on the cloud images build servers and kick off a new build of xenial? Odd_Bloke has done this in the past but I haven't been able to reach him for a few days. this is regarding bug 1621393 | 19:22 |
| ubottu | bug 1621393 in cloud-images "xenial64 image (20160907.1.0) has a broken (empty) /etc/resolv.conf" [Undecided,New] https://launchpad.net/bugs/1621393 | 19:22 |
| infinity | semiosis: Do cloud image builds use a PPA for livecd-rootfs? If so, that needs updating to match the SRU. | 19:34 |
| nacc | rbasak: but in better news, i can confirm our apt workaround is actually quite nice. as i was apply the same logic to 'at' and it basically just worked :) | 19:43 |
| semiosis | infinity: i seem to remember Odd_Bloke saying something about a PPA, yes | 20:10 |
| infinity | semiosis: Right, that's what needs updating, then. The builders themselves are ephemeral. But the archvie they get livecd-rootfs from is likely not the primary archive. :/ | 20:18 |
| infinity | (Which is a bug in the cloud setup, but not my bug...) | 20:19 |
| infinity | semiosis: So, you might be stuck poking Odd_Bloke repeatedly. | 20:19 |
| semiosis | infinity: then that's what i'll do. thanks. | 20:23 |
| doko | tumbleweed, Laney: promoted. please could you fix https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822148 too? | 20:31 |
| ubottu | Debian bug 822148 in src:snowball "snowball: memory leaks in libstemmer" [Important,Open] | 20:31 |
| nacc | rbasak: do you have a good method for me to verify that my pygit2 converison has resulted in the same repository (including all history) for all the existing imports? i'm not sure if there is a good command to force a comparison of all objects in two repositories? | 20:31 |
| tumbleweed | doko: upgrading to the new github snowball is a fairly large job, that I've been putting off for months | 20:33 |
| tumbleweed | don't expect it in the next days | 20:33 |
| doko | ahh, ok. qa.ubuntuwire.org is more pressing ;) | 20:34 |
| tumbleweed | doko: on tho other side, cherry picking those PRs might be easy enough | 20:36 |
| tsimonq2 | thank you robru | 21:14 |
| robru | tsimonq2: you're welcome! | 21:14 |
| jderose | infinity: so Laszlo Ersek kindly chimed on https://bugs.launchpad.net/ubuntu/+source/shim/+bug/1624096 - apparently it's a problem with shim, which upstream has fixed as of git commit 7052e7530755 | 21:29 |
| ubottu | Launchpad bug 1624096 in shim (Ubuntu) "yakkety: backport (or rebase to) fix eliminating a double-close in shim" [Undecided,Confirmed] | 21:29 |
| infinity | slangasek: ^ | 21:30 |
| infinity | slangasek: You <3 shim. | 21:30 |
| slangasek | jderose: how did this break "after August 25th"? the most recent change to shim-signed in yakkety was on August 8 | 21:32 |
| jderose | i <3 shim, you <3 shim, everybody <3's shim :P | 21:32 |
| slangasek | and turning around a fix for shim-signed is not quick | 21:32 |
| slangasek | oh, why are the edk2 binaries still in multiverse? | 21:33 |
| slangasek | <fixy-fixy> | 21:33 |
| jderose | slangasek: not totally sure... all i know is that the last timestamp i have for the last golden image i made for yakkety (using a xenial host) was August 25th, so the bug was introduced around there (+/- a week or so) | 21:34 |
| slangasek | jderose: so, can you double-check what shim-signed version is in that one? | 21:35 |
| slangasek | "When fallback.efi is not present, the should_use_fallback error path attempts to close a file that has already been closed" | 21:37 |
| jderose | slangasek: yeah, give me a sec. i can figure out what version is in my exported tarbal, but that dosen't necessarily tell me what version was in the iso i installed from as sometimes i'll update the same qemu vm (from the same dev iso) for a week or so before a fresh remastering. | 21:37 |
| slangasek | jderose: did you somehow have fallback.efi previously? | 21:37 |
| jderose | slangasek: as i don't know what "fallback.efi" is, i'm not sure. i don't expect it's something i could have introduced anyway :P | 21:38 |
| slangasek | you could have ;) | 21:38 |
| jderose | sure sure. but could i have done it accidentally, without knowing? :P | 21:39 |
| slangasek | dunno | 21:39 |
| slangasek | there is a bug about that though, if I can find it | 21:39 |
| slangasek | cyphermox: do you remember where the bug report about fallback.efi support is? | 21:41 |
| slangasek | ah, LP: #1366546 | 21:41 |
| ubottu | Launchpad bug 1366546 in shim (Ubuntu) "Ubuntu doesn't provide \EFI\BOOT\BOOTX64.EFI for UEFI systems" [Undecided,Triaged] https://launchpad.net/bugs/1366546 | 21:41 |
| slangasek | so, we could work around your bug, more quickly than round-tripping to Microsoft, by adding fallback.efi to the disk | 21:44 |
| jderose | slangasek: so it's an ISO mastering issue then? | 21:44 |
| jderose | slangasek: hmm, so i working from home today and don't have easy access to the August 25th golden image tarbal i made... but i can figure it out tomorrow when i'm in the office. do you need to know this still? | 21:48 |
| slangasek | jderose: probably not; for now we can assume that your Aug 25 image happened to have an out-of-date shim-signed package, and focus on the workaround wrt fallback.efi | 21:50 |
| jderose | slangasek: okay, gotcha. please let me know if there's anything i can do to get you helpful information | 21:51 |
| doko | wgrant, tumbleweed: what can we do about the ftbfs reports for the test rebuilds? end of this week I'd like to post about the test rebuild including links to the build failures | 21:52 |
| tumbleweed | doko: I can do a run against a test archive. What's it called? | 22:10 |
| doko | tumbleweed: https://launchpad.net/ubuntu/+archive/test-rebuild-20160916 and https://launchpad.net/ubuntu/+archive/test-rebuild-20160916-linaro | 22:17 |
| mizu_ | Hi can anyone here help me set up lxr so that i can index the linux kernel | 22:27 |
| sladen | mizu_: if you just want to view the result; something like http://lxr.free-electrons.com/source/kernel/printk/printk.c maybe useful | 22:36 |
| mizu_ | sladen: Hey! thanks for the reply. I'm required to have my own copy of the kernel on lxr. | 22:37 |
| mizu_ | It's for a class. | 22:38 |
| mizu_ | sladen: I was trying to follow the User manual for LXR. but i'm getting lost along the way. my poor english is making it a bit difficult. | 22:40 |
| sladen | mizu_: well, people can help, but not do your homework for you :0 | 22:41 |
| sladen | :) | 22:41 |
| sladen | mizu_: perhaps you could share how far you got. And where you have gotten stuck? | 22:42 |
| mizu_ | sladen: Okay give me a few moments to write what i've done. sorry if it will be hard to understand | 22:42 |
| mizu_ | sladen: Also thank you! | 22:43 |
| mizu_ | So i downloaded the kernel from kernel.org and unzipped it in the /home/source/kernel directory. As it tells me to do in the User Manual. Then after installing all the required software for lxr like the swishe ctag etc. I went into the lxr folder and ran the configure-lxr.pl script. as it tells me in the manual. And i went with all the default options. This created my lxr.conf file. I then set up mysql, with root password. I than | 22:50 |
| mizu_ | And I am getting a nothing to index error | 22:50 |
| mizu_ | I am a bit lost in where the kernel comes into this setup | 22:50 |
| === deltab_ is now known as deltab | ||
| nacc | mizu_: i'm guessing beteween your first and second descriptino, you got cutoff. It ended with "I than" | 22:51 |
| mizu_ | nacc: Oh sorry about that. I said I than ran the ./genxref script. and got a nothing to index error | 22:53 |
| mizu_ | the user manual says to do. ./genxred --url=http://localhost/lxr --tree=tree --version=v2 | 22:53 |
| nacc | genxref, right? | 22:54 |
| mizu_ | sorry that should be genxref | 22:54 |
| mizu_ | yes | 22:54 |
| nacc | mizu_: how are you storing your trees? FILES/cvs/git/subversion/bitkeeper | 22:57 |
| mizu_ | nacc: Files | 22:57 |
| nacc | mizu_: ok, what is your exact genxref invocation? | 22:58 |
| mizu_ | nacc: sorry my english is not the best by invocation you mean what command do i put in when i run genxref? | 22:58 |
| sladen | mizu_: yes, we need to know (a) what exactly you are typing (b) what exact error message is then showing | 22:59 |
| sladen | mizu_: it is probably best if you paste your terminal input/output here: http://paste.ubuntu.com/ | 23:00 |
| nacc | mizu_: yeah, you said ran the ./genxref script, please pastebin the exact in/output | 23:00 |
| mizu_ | since i'm following the user manual, i just put in what they had which was. "./genxref --url=http://localhost/lxr --tree=tree --version=v2" | 23:00 |
| mizu_ | okay one sec sorry | 23:00 |
| mizu_ | paste.ubuntu.com/23204818 | 23:03 |
| nacc | mizu_: i think you are taking their guide too literally | 23:05 |
| nacc | version you pass is the version you want to index | 23:05 |
| nacc | and tree is the name of a tree to index | 23:05 |
| mizu_ | is the tree the directory to the linux kernel? also does the kernel need to be compiled first? | 23:06 |
| nacc | given taht you're indexing the linux kernel, i'm assuming it wouldn't be 'v2' | 23:06 |
| nacc | mizu_: no, it's not necessary to compile the kernel, this is a source index | 23:06 |
| nacc | mizu_: you probably don't need to pass --tree at all, afaict | 23:07 |
| nacc | mizu_: if you pass a url | 23:08 |
| mizu_ | but then how would it knw to index the kernel? | 23:08 |
| nacc | mizu_: the url (http://localhost/lxr) references a path on your system, afaict -- that's what you configured | 23:09 |
| mizu_ | hm, i am a bit confused. I think i will start from scratch and set up the conf file again | 23:10 |
| mizu_ | nacc: It would be best to use mutiple-tree configuration yes? I need to index both kernel and grub. | 23:11 |
| nacc | mizu_: i have no idea :) | 23:12 |
| sladen | mizu_: looking at eg. http://oss.segetech.com/integra/lxr.conf | 23:13 |
| sladen | mizu_: I can see "6) Copy this file as /usr/local/lxr/lxr.conf and adjust as needed - baseurl, virtroot, sourceroot, sourcerootname, cvswebprefix" | 23:13 |
| sladen | mizu_: have you configured anything like this? | 23:13 |
| sladen | mizu_: eg. how is genxref being told where to find the source to index? | 23:14 |
| mizu_ | sladen: when you run the config script its supposed to set it up i believe, but the script gives me different questions from the manual so its a bit confusing. one sec. I will retry the config script, which createes the conf file they are editing in that link. | 23:15 |
| sladen | mizu_: can you pastebin the lxr.conf file? | 23:20 |
| sladen | mizu_: the important config setting appears to be "sourceroot" | 23:21 |
| sladen | mizu_: and then the 'versions' are just sub-directories inside that | 23:22 |
| mizu_ | sladen: yup! one sec redoing the script tht creates the file | 23:22 |
| mizu_ | sladen: sorry, this script is acting weird for some reason | 23:37 |
| mizu_ | sladen: really sorry about that. script was being weird. pastebin.com/ENNMhCb2 | 23:46 |
| === alexisb is now known as alexisb-afk | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
