| smoser | nacc, you decided no backports ? | 00:01 |
|---|---|---|
| smoser | that is fine with me. | 00:01 |
| nacc | smoser: at least for now, we'll need to consider where to put them in the tree (and how they should be named/tagged/etc) | 00:01 |
| nacc | smoser: i don't think it's a significant use-case, since it's opt-in for users | 00:01 |
| smoser | agree. | 00:03 |
| nacc | smoser: thanks! | 00:03 |
| === _salem is now known as salem_ | ||
| === mnepton is now known as mneptok | ||
| rlaager | What's the procedure to get a bug nominated for a release? I'd like to see this SRUed to Xenial, and I'll prep a debdiff (again) once another pending SRU is resolved: https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1571241 | 01:11 |
| ubottu | Launchpad bug 1571241 in zfs-linux (Ubuntu) "ZFS initrd script does not import zpool using /dev/disk/by-id device paths" [Undecided,Fix released] | 01:11 |
| sarnold | hey it looks like i've got buttons for that | 01:13 |
| sarnold | are you sure "Fix Released" is the right status? | 01:13 |
| rlaager | sarnold: Yes, it should be Fix Released in yakkety. I haven't personally tested it. I suppose I can do that right now. But the fix is in 0.6.5.7, which is in Yakkety. | 01:14 |
| rlaager | sarnold: Yes, yakkety works. | 01:15 |
| sarnold | aha | 01:15 |
| sarnold | thanks | 01:15 |
| nacc | rlaager: typically you ask in #ubuntu-bugs, iirc sru right (https://wiki.ubuntu.com/StableReleaseUpdates) | 01:19 |
| rlaager | nacc: Thanks. Sorry, I've read that page several times, but I missed that. | 01:23 |
| nacc | rlaager: np, it's in Procedure, 4. | 01:24 |
| nacc | so i guess that's 3.4 :) | 01:24 |
| rlaager | Yeah, I see it now. I searched for #ubuntu-bugs after you mentioned it. | 01:24 |
| nacc | rbasak: ok, new caveat, do we want to be tracking debian/sid and experimental? | 02:21 |
| nacc | rbasak: as there are times where we sync or merge with experimental, it seems | 02:21 |
| nacc | specifically exim4 4.73~rc1-1ubuntu1 | 02:21 |
| nacc | well, e.g. :) | 02:21 |
| nacc | it is orphaned by our current algorithm because changelog previous (4.73~rc1-1) is not (4.72-2ubuntu1) but 4.72-3 is in the new debian/changelog and is imported. | 02:22 |
| === yuning-afk is now known as yuning | ||
| === salem_ is now known as _salem | ||
| Mirv | flexiondotorg: very nice blog post that ubuntu-mate-yakkety-progress-update :) | 08:02 |
| alkisg | Hi, there's an autogenerated .html web page somewhere in ubuntu.com or launchpad.net, that lists all of the packages in the -proposed repositories, along with how long they've been in the queue etc... but I can't find it in google... does anyone know its URL? | 08:58 |
| ricotz | alkisg, http://people.canonical.com/~ubuntu-archive/pending-sru.html | 08:59 |
| alkisg | Thank you! :) | 08:59 |
| rbasak | nacc: eventually we'd want to track experimental I think, yes. Not sure about right now, though I appreciate that it creates a history problem with missing parents if we don't. | 09:11 |
| caribou | Is there a way to have a conffile that we modify upon install be identified as such (i.e. modified by us) so it is not considered a user change ? | 09:32 |
| caribou | rbasak: that /etc/default/grub.d/kdump-tools.cfg once again :) | 09:37 |
| rbasak | caribou: you want a package to be able to modify its own "conffile" without creating conffile prompts? Use ucf. | 09:37 |
| rbasak | (or better, .d directories or something if possible) | 09:38 |
| caribou | rbasak: another option is to install separate files in /var/lib/kdump & manage specificities with symlinks & dpkg-maintscript-helper | 09:39 |
| rbasak | caribou: can you explain in more detail what you're trying to achieve? | 09:39 |
| caribou | rbasak: the crashkernel= boot parameter has architecture specific values that I need to configure upon install in /etc/default/grub.d/kdump-config.cfg | 09:40 |
| caribou | so it is picked up by update-grub | 09:40 |
| caribou | rbasak: so either I have architecture-specific files in /var/lib/kdump & I symlink it to /etc/default/grub.d/kdump-config.cfg | 09:40 |
| caribou | rbasak: or /etc/default/grub.d/kdump-config.cfg is a real file that I modify and use ucf | 09:41 |
| caribou | rbasak: right now, crashkernel=384-:128M for all architectures which is wrong for ppc64el | 09:42 |
| caribou | rbasak: and s390x uses /etc/zipl.conf | 09:42 |
| rbasak | I wonder if /etc/default/grub.d needs to grow some arch-conditional functionality. | 09:42 |
| rbasak | Would the user ever need to modify /etc/default/grub.d/kdump-config.cfg? | 09:43 |
| rbasak | Or is it going into /etc only because that's where the .d directory is? | 09:43 |
| rbasak | Or do you want the user to be able to delete the file? | 09:43 |
| caribou | rbasak: yes, if the hardware has very large amount of memory, hence 128M is too small | 09:43 |
| rbasak | Does kdump-config.cfg contain only that small crashkernel line? | 09:44 |
| caribou | rbasak: use can change it but shouldn't remove it or it'll break kernel crash dump functionality | 09:44 |
| caribou | A replacement variable to be used by update-grub : | 09:44 |
| caribou | rbasak: GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=384M-:128M" to be exact | 09:45 |
| rbasak | I think that's suitable for ucf, though I'm interested to hear what others think. | 09:45 |
| rbasak | Perhaps a /usr/share/kdump/kdump-config.cfg.<arch> or something, and have the maintainer scripts call ucf against the right file. | 09:46 |
| caribou | rbasak: yes, that's one of my option | 09:46 |
| caribou | and it would simplify the script logic; right I have to use 'sed' on the existing file | 09:47 |
| caribou | rbasak: thanks; I'll test this one out | 09:52 |
| rbasak | caribou: it might be worth filing a bug in Debian asking for arch-conditional functionality right inside /etc/default/grub.d/. If that were possible, then you could just drop a conffile in, right? It might not be worth doing it for the single use case that needs it, but letting the maintainer know may help tally up the use cases. | 09:54 |
| rbasak | (but I'd use ucf in the meantime and assuming the answer is "sorry, not worth it for now") | 09:55 |
| caribou | rbasak: good idea | 09:55 |
| brendand | when using adt-virt-qemu, can i prevent the target from being destroyed at the end of the testing? | 09:56 |
| caribou | rbasak: well, maybe one of the grub maintainer who's hanging around here will have something to say | 09:56 |
| rbasak | caribou: :) | 09:56 |
| rbasak | brendand: are you looking for adt-run --shell-fail or --shell? | 09:57 |
| brendand | rbasak, probably. i've used that before but not on a transient target so hopefully it works | 10:01 |
| === yuning is now known as yuning-afk | ||
| === hikiko is now known as hikiko|ln | ||
| === hikiko|ln is now known as hikiko | ||
| brendand | i need to use a file that is placed in the real-tree during the autopkgtest run, i can see copyup commands copying real-tree on the target to tests-tree in the output-dir, but it looks like it is subsequently deleted - how can i prevent that? or is there an alternative way to copy files from the test bed to the host? | 13:19 |
| rbasak | brendand: for debugging? | 13:25 |
| rbasak | or something else? | 13:25 |
| brendand | rbasak, no i need the junit xml file generated by nosetests | 13:25 |
| brendand | so i need to get it on to the jenkins slave | 13:25 |
| rbasak | What for? To save an artifact? | 13:26 |
| brendand | rbasak, to use with jenkins junit test results plugin. it gives a nice detailed picture of the results | 13:27 |
| rbasak | OK, so I guess you need a standard way to get test artifacts from dep8 tests saved by adt-run to be used later. | 13:28 |
| rbasak | I'm not aware of a documented way to do this, but it might be worth filing a bug to ask for functionality in adt-run for the test to be able to supply that. | 13:28 |
| rbasak | I imagine something like an environment variable to tell the test where to put things. | 13:29 |
| rbasak | Since right now it only copies out stdout, stderr, etc. | 13:29 |
| brendand | i'm pretty sure there is a way because a previous test suite i worked on did it. i'll go look at that code and see what was done there | 13:29 |
| rbasak | pitti doesn't seem to be around. | 13:29 |
| brendand | rbasak, yeah. sheesh | 13:29 |
| brendand | :P | 13:29 |
| rbasak | I wouldn't be surprised if there is an undocumented directory that you can use if you happen to know to drop stuff there. But it might be undefined behaviour and too much knowledge of adt-run internals. It would be nice to have a formal and stable way to do it. | 13:30 |
| dobey | brendand: does the -o option to adt-run not give you what you want? | 13:44 |
| brendand | dobey, no that tells adt-run where to put the artifacts that it does copy from the testbed | 13:44 |
| brendand | dobey, i want to see that other things go there than the defaults | 13:45 |
| brendand | i think i found it, just testing it now | 13:45 |
| === inaddy is now known as tinoco | ||
| ginggs | doko: hi, i fixed the shogun ftbfs, what do i need to do to LP: #1576967 ? | 14:15 |
| ubottu | Launchpad bug 1576967 in shogun (Ubuntu) "shogun fails to build, demoting to proposed" [Undecided,Confirmed] https://launchpad.net/bugs/1576967 | 14:15 |
| brendand | dobey, rbasak - everything written into $ADT_ARTIFACTS will end up in 'artifacts' under the output-dir | 14:49 |
| brendand | not mentioned in the man page - maybe it's in the more extensive web based documentation | 14:49 |
| nacc | rbasak: I think, technically, it's trivial for me to track debian/* (which woudl be overkill, as we don't sync from oldstable/stable). This is a harder thing to fix-up, though, i think, as it will cause us to reparent entire trees | 14:50 |
| nacc | bjf: jgrimm pointed me in your direction to ask a quick query about a bug: LP: #1433906 | 15:08 |
| ubottu | Launchpad bug 1433906 in linux-lts-vivid (Ubuntu) "Acer, Inc ID 5986:055a is useless after 14.04.2 installed." [High,Triaged] https://launchpad.net/bugs/1433906 | 15:08 |
| nacc | bjf: I provided some feedback, as this is filed aginst the LTS HWE stacks, but I think is actually an upstream issue (and thus probably shoudl be filed against linux as well), given 16.04 reports | 15:09 |
| nacc | bjf: just didn't want henrik's work to go ignored (and someone on #ubuntu asked about it so i happened to look) | 15:09 |
| bjf | nacc, looking | 15:10 |
| nacc | bjf: thanks! | 15:10 |
| bjf | nacc, we have it on our radar now ... will see what we can do | 15:18 |
| nacc | bjf: thanks! it does seem like upstream would take the next revision of henrik's patch, based upon my review of the list, but also i wasn't sure if ubuntu ever took outofband patches (not yet upstream) from the community -- i assumed not, but figured i should learn :) | 15:19 |
| bjf | nacc, we will do so in the right situation .. this looks like it might be one | 15:20 |
| nacc | bjf: got it, thanks! | 15:20 |
| rbasak | brendand: neat. Useful to know. Thanks! | 15:30 |
| === Guest19728 is now known as adrian | ||
| === mnepton is now known as mneptok | ||
| brendand | oh this is weird - the files in artifacts/ are 3 and a half hours older than everything else :/ | 16:00 |
| brendand | so jenkins won't use the xml file, ugh | 16:00 |
| mapreri | Laney: ximion: so, i just tried on a real fresh yakkety vm to look up scribus on {ubuntu,gnome}-softwere, and it does't show up. why? | 16:15 |
| nacc | mapreri: typo? ubuntu-software (vs. softwere) ? | 16:18 |
| nacc | mapreri: oh scribus itself | 16:18 |
| Laney | don't know, sorry - start debugging by pkill -f gnome-software; gnome-software --verbose and then see if you get anything interesting | 16:18 |
| ximion | mapreri: run "appstreamcli get scribus.desktop" | 16:19 |
| ximion | does that return something? | 16:19 |
| Laney | it's definitely in the appstream | 16:19 |
| Laney | don't have bandwith beyond that to debug for you atm, sorry | 16:19 |
| mapreri | appstreamcli knows something, so this is cool already. https://paste.ubuntu.com/16710210/ | 16:20 |
| mapreri | `gnome-software --verbose` is kinda of noisy. | 16:21 |
| Laney | search for scribus | 16:22 |
| mapreri | this is crazy https://paste.ubuntu.com/16710302/ | 16:22 |
| mapreri | (gnome-software:2344): Gs-DEBUG: app invalid as no pixbuf scribus.desktop | 16:22 |
| mapreri | (gnome-software:2344): Gs-DEBUG: no search results to show | 16:22 |
| mapreri | not sure what's telling me though | 16:23 |
| Laney | that's your way in to debug it, unless ximion knows why already | 16:23 |
| ximion | mapreri: does "/var/lib/app-info/icons/ubuntu-yakkety-universe/scribus_scribus.png" exist? | 16:27 |
| mapreri | nope | 16:28 |
| mapreri | /var/lib/app-info/icons/ubuntu-yakkety-universe/64x64/scribus_scribus.png does though | 16:28 |
| mapreri | ximion: guess you forgot 64x64 ↑ | 16:29 |
| ximion | ah, right, that's good enough | 16:29 |
| ximion | jup | 16:29 |
| ximion | so, gnome-software is being dumb here | 16:29 |
| ximion | or rather appstream-glib | 16:30 |
| Laney | it has both a cached and a stock icon in the appstream | 16:30 |
| ximion | for some reason, it uses the icon name "scribus", which is the stock icon-name, while the icon cachename, "scribus_scribus.png" is available | 16:31 |
| ximion | Laney: yeah, I though that would confuse it at first too, but since the stock icon name is very common, we would have lost 60% of all apps in GS if this was a common bug | 16:32 |
| ximion | hmm... | 16:33 |
| Laney | I'll leave it with you | 16:33 |
| Laney | thanks | 16:33 |
| ximion | Laney: this might be a bug in the generator not building new-style metadata, but *also* a bug in asglib for not reading the old data properly | 16:33 |
| ximion | which, in the latter case, is important, because the patch which touched it last is queued for SRU | 16:34 |
| ximion | so far with only positive feedback | 16:34 |
| ximion | I'll investigate this, because there is a chance that if it is broken at all, that I was the one who broke it | 16:34 |
| Laney | this is yakkety which has the new code already | 16:35 |
| ximion | (although this ran through multiple rounds of testing by various people already...) | 16:35 |
| Laney | so yes, thanks | 16:35 |
| mapreri | (btw, this only confirms my idea that the AS system was too young to supersede ubuntu-software-centre) | 16:36 |
| Laney | not helpful | 16:36 |
| mapreri | ximion: if you need some kind of testing I'm up for that, but I'm not sure if there is something more i can help with that | 16:36 |
| ximion | mapreri: it doesn't make sense that only Scribus would be hit by this bug | 16:36 |
| mapreri | yeah, indeed :s | 16:36 |
| ximion | btw, whatever the bug is, the chance that it doesn't exist in Xenial is high | 16:37 |
| mapreri | i mean, it's not that i'm doing something so weird | 16:37 |
| mapreri | ximion: to check that, I suppose I could get a xenial VM and temporary put yakkety in the apt lines, right? | 16:38 |
| Laney | it's true actually | 16:38 |
| Laney | get https://launchpad.net/ubuntu/+source/appstream-glib/0.5.13-1/+build/9549443/+files/libappstream-glib8_0.5.13-1_amd64.deb | 16:38 |
| Laney | and it works again | 16:39 |
| * Laney marked the sru accordingly | 16:40 | |
| ximion | Laney: are you sure? | 16:40 |
| mapreri | let me try | 16:41 |
| ximion | I tried with the new and old asglib (using Cuttlefish as an example of having both stock and cached icons), and no matter which asglib I use, that too doesn't show up | 16:41 |
| Laney | http://people.canonical.com/~laney/weird-things/scribus.png | 16:42 |
| mapreri | yeah | 16:42 |
| mapreri | it shows up indeed with the older asglib | 16:42 |
| ximion | Laney: wow, I just got the gnome-software freezes the entire system bug | 16:43 |
| ximion | couldn't click on any desktop element anymore | 16:44 |
| Laney | "the" bug? | 16:44 |
| ximion | on KDE! | 16:44 |
| Laney | crazy | 16:44 |
| ximion | jup, I saw it reported on GNOME | 16:44 |
| Laney | not heard of or seen that | 16:44 |
| ximion | and I though that the chance that this was related to gnome-software was close to zero... | 16:44 |
| ximion | mapreri: I can reproduce this now, I'll prepare a patch later | 16:45 |
| mapreri | ximion: great, thanks | 16:45 |
| ximion | need to get some other things done first | 16:45 |
| ximion | Laney: ah, I confused it with LP:#1578317 (and messed that one up with another thread of GS stopping the whole system) | 16:48 |
| ximion | Laney: when doing a new debdiff, which version number should that have? | 16:50 |
| mapreri | now, unrelated, can I sru this scribus package by just appending '~ubuntu16.04.0' to the version? (this is the only change since xenial) | 16:50 |
| ginggs | mapreri: 1.4.6+dfsg-2ubuntu1 should be fine - you have 1.4.6+dfsg-3 in yakkety | 16:58 |
| ximion | Laney: this might be a bug in GS afterall... | 17:00 |
| ximion | Laney: it's not my bug! :D | 17:41 |
| ximion | the patch I made just exposed a different bug in asglib ^^ | 17:42 |
| mapreri | inceptionbug | 17:42 |
| ximion | or rather, some odd behavior, where I need hughsie for to clarify | 17:42 |
| ximion | at time, the code simply prefers stock >> cached >> local >> remote icons | 17:43 |
| ximion | which would make sense if GS would fall back to the cached icon if the stock icon isn't found | 17:43 |
| ximion | so, this can be fixed in asglib or GS | 17:44 |
| ximion | mapreri, Laney: bug report against GS filed and attached to LP 1576780 after a brief discussion with the GS maintainer | 17:57 |
| ubottu | Launchpad bug 1576780 in appstream-glib (Ubuntu Xenial) "Needs to implement the full DEP-11 icon spec for compatibility with 3rd-party repos" [Medium,Fix committed] https://launchpad.net/bugs/1576780 | 17:57 |
| ximion | it's a rather severe bug in GS, IMHO, so we should fix it in an SRU if a patch is available | 17:57 |
| ximion | meanwhile, the appstream-glib fix which trigger this bug should stay blocked | 17:58 |
| mapreri | ximion: but are you saying that it works perfectly fine in yakkety with kde? | 17:59 |
| ximion | yes, because I had an icon theme which shipped a different Scribus icon | 18:00 |
| mapreri | ah | 18:00 |
| mapreri | tricky. | 18:00 |
| ximion | (was still on to fix a KDE bug ^^) | 18:00 |
| ximion | switching back to breeze made the entry disappear again :D | 18:01 |
| ximion | mapreri: plasma-discover is not affected by this bug, it shows Scribus | 18:04 |
| ximion | so, you have KDE covered :) | 18:04 |
| mapreri | o.O( who uses the default DE anyway!? ) | 18:05 |
| * ximion needs to run | 18:10 | |
| nacc | hrm, seems like xfce4-whiskermenu-plugin has broken grep-merges | 18:43 |
| nacc | as it's author and uploader are None | 18:43 |
| nacc | Unit193: --^ | 18:44 |
| slangasek | oh, is that what broke it ;) | 18:44 |
| nacc | slangasek: i just dumped a few print's in and saw: | 18:44 |
| nacc | package xfce4-whiskermenu-plugin, author None, uploader = (None) | 18:44 |
| nacc | seems like that implies that the json has a None for the 'user'? | 18:45 |
| slangasek | yeah, how did someone manage that | 18:46 |
| slangasek | I guess that's a bug in the MoM code, since the lp upload page looks fine | 18:46 |
| slangasek | bdmurray: ^^ maybe you have insight on this | 18:47 |
| nacc | slangasek: ack, i was looking at the same | 18:48 |
| bdmurray | slangasek: no idea | 18:50 |
| b4r | anyone in particular working on the php7.0 package and updating to today's php 7.0.7? | 18:57 |
| === mnepton is now known as mneptok | ||
| nacc | b4r: responded in #ubuntu-server | 19:33 |
| Unit193 | I didn't break it. :3 | 20:16 |
| rhollencamp | trying to follow directions at http://packaging.ubuntu.com/html/udd-getting-the-source.html#branching | 20:19 |
| rhollencamp | when I run `bzr branch ubuntu:x/cinnamon-settings-daemon cinnamon-settings-daemon.dev` | 20:19 |
| rhollencamp | bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/+branch/ubuntu/x/cinnamon-settings-daemon/". | 20:20 |
| rhollencamp | looking in launchpad, it doesn't list a branch for xenial (https://code.launchpad.net/ubuntu/+source/cinnamon-settings-daemon) | 20:21 |
| Unit193 | nacc: About the only thing I can think of is if it's expecting my name to only have letters. | 20:54 |
| Unit193 | But that'd break on some forign names too. | 20:54 |
| bdmurray | sinzui: Is all the TODO stuff in the bug description of bug 1556981 done? | 21:05 |
| ubottu | bug 1556981 in juju-core (Ubuntu Wily) "[needs-packaging] Juju 1.25.5 is not in wily and trusty" [Wishlist,Fix committed] https://launchpad.net/bugs/1556981 | 21:05 |
| sinzui | bdmurray: I am shamed, it is and I did not update when I added the comments. I will update now | 21:06 |
| bdmurray | sinzui: I didn't mean to publicly shame you. | 21:06 |
| sinzui | bdmurray: the bug is updated. I think the wily and trusty packages are good to go to *-updates when their 7 days in proposed is up | 21:07 |
| bdmurray | sinzui: think? do you have any reservations because I was about to release them | 21:08 |
| sinzui | bdmurray: please do release them. They are solid | 21:09 |
| === nobuto_ is now known as nobuto | ||
| nacc | Unit193: oddly it shows you correctly for the package just before it | 22:08 |
| nacc | rhollencamp: possibly because it's in sync with debian now? | 22:11 |
| Unit193 | I don't see anything I could have done, hmm. Also, wow. Thanks for the ping, means I uploaded the new one exactly one month after. :D | 22:11 |
| nacc | rhollencamp: not sure, but the vcs in the control file is: https://anonscm.debian.org/git/pkg-cinnamon/cinnamon-settings-daemon.git | 22:11 |
| nacc | Unit193: yeah, I doubt it's you :) | 22:12 |
| Unit193 | Figured good to check. | 22:12 |
| mwhudson | can someone remind me how often the cronjobs that import things from debian run? | 22:28 |
| mwhudson | there is one cron job that copies state from debian into the 'debian' distro on launchpad | 22:29 |
| mwhudson | and another that copies things from the 'debian' to 'ubuntu' distros | 22:30 |
| mwhudson | iirc one of these is gina and the other is iron, but i certainly forget all the details | 22:30 |
| wgrant | mwhudson: gina imports into the debian distro on LP every six hours, running on the machine named iron. | 23:33 |
| wgrant | The "autosync" from Debian to Ubuntu runs on snakefruit at a frequency I don't recall. | 23:33 |
| mwhudson | wgrant: aah | 23:43 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
