| === Guest460 is now known as mfisch | ||
| === mfisch is now known as Guest81704 | ||
| === Guest81704 is now known as mfisch | ||
| === mfisch is now known as Guest30018 | ||
| stub | Is the update-manager indicator on wily supposed to be informing people abount Xenial now? | 05:33 |
|---|---|---|
| pitti | Good morning | 06:25 |
| pitti | hallyn: indeed, that seems fairly new; can you please file one (debian or LP, doesn't matter) with how you got there, so that we can write a test case? | 06:26 |
| infinity | stub: Yes. | 06:37 |
| infinity | stub: wily upgrades were enabled pretty much right after release, it's only LTS->LTS upgrades where we delay until the point release. | 06:38 |
| stub | ok, that was my confusion. I thought all recommended upgrades were delated until point release. | 06:38 |
| stub | I like that word. I'm keeping it. | 06:39 |
| infinity | stub: Nah, the justification is threefold: 1) wily->xenial is what most people were testing through the xenial cycle, so we're pretty sure it mostly works, while trusty->xenial has some bugs to iron out, 2) LTS users expect higher quality, so that 3 months of polish gets them a less crap release, and 3) we get to use the fasttrack EVERY SIX MONTHS IS A NEW UBUNTU, FUCK YEAH users as post-release beta testers for the LTS people. | 06:58 |
| infinity | stub: That said, for technical Canonical employees, we recommend you upgrade way before release. Slacker. | 07:00 |
| infinity | (unless this was your mom's machine) | 07:00 |
| ginggs | morning! would someone help me understand why bliss is not migrating please? if i am reading update_output correctly, then polymake is involved somehow. | 07:03 |
| infinity | ginggs: That output is telling you that upgrading bliss will make polymake uninstallable. | 07:05 |
| infinity | ginggs: Because polymake needs a rebuild for the libbliss1d->libbliss2 soname bump. | 07:07 |
| ginggs | infinity: aha thanks! | 07:08 |
| infinity | ginggs: Do you have upload rights for the rebuild, or shall I lob it at the archive for you? | 07:08 |
| ginggs | infinity: no need to worry, i can do it | 07:09 |
| infinity | ginggs: Enjoy. | 07:09 |
| infinity | (dch -R) | 07:09 |
| ginggs | infinity: for future reference, how did you get from 'will make polymake uninstallable' to 'needs a rebuild'? | 07:09 |
| infinity | ginggs: I checked if any package names changed. Saw the sover bump. Checked rdepends of libbliss1d, which happens to just be libbliss* and polymake, extrapolated. | 07:10 |
| ginggs | infinity: ok, manually then | 07:11 |
| infinity | ginggs: One could also try installing in a chroot while explicitly excluding all the old packages (apt-get install polymake libbliss1d- libbliss1d-dbg-) and watch it whine, if it's to complex to understand at first glance. | 07:11 |
| infinity | The second one is a better option if you see no immediate connection between your upload and the breakage britney is telling you about. | 07:12 |
| infinity | Cause be an interim dep needs fixing, or a dependency is versioned in a way that breaks things, etc. | 07:13 |
| jamespage | mwhudson, hey still awake? do you know if we're planning to adopt the shared linking stuff in go in any way just yet? | 09:25 |
| jamespage | mwhudson, openstack has its first go based work it wants to include and they are struggling with approach so wanted to chime in with what we've done in Ubuntu for LXD and Juju... | 09:26 |
| Skuggen | slangasek: Did you have time to review some sedition for making MySQL upgrades more robust? | 10:14 |
| Skuggen | slangasek: https://github.com/ltangvald/mysql-5.7/commit/f57b068c956d0792bb35cec72fee8d66b0f513c7 | 10:15 |
| === _salem is now known as salem_ | ||
| xnox | marga, W: http://dl.google.com/linux/chrome/deb/dists/stable/Release.gpg: Signature by key 4CCA1EAF950CEE4AB83976DCA040830F7FAC5991 uses weak digest algorithm (SHA1) .... | 14:11 |
| xnox | =) | 14:12 |
| juliank | xnox: that's in progress already AFAICT (the file already has a 4096R signature as well last time I checked) | 14:14 |
| juliank | pub rsa4096/0x7721F63BD38B4796 2016-04-12 [SC] | 14:15 |
| juliank | It's now just a matter of the packages shipping a new key | 14:15 |
| xnox | juliank, right. but the bug is not in the key, but in the parameters passed to gpg as to which digest algo to use =) | 14:15 |
| juliank | xnox: No, no. | 14:15 |
| xnox | hm?! | 14:16 |
| * xnox thought it's about gpg --digest-algo SHA256 | 14:16 | |
| juliank | You get the warning from a DSA1 key | 14:16 |
| juliank | s/key/signature/ | 14:16 |
| juliank | that uses SHA1 | 14:16 |
| xnox | *sigh* | 14:16 |
| juliank | xnox: On the other hand, the RSA signature seems to use SHA1 as well | 14:17 |
| juliank | (But that's not the cause of the error yet) | 14:17 |
| juliank | So while you are practically right in the end, this surprisingly does not follow from the error | 14:19 |
| juliank | :) | 14:19 |
| * juliank had to run gpgv manually to check | 14:19 | |
| juliank | xnox: If you want to track state, https://bugs.chromium.org/p/chromium/issues/detail?id=596074 | 14:20 |
| juliank | There's also the fancy https://bugs.chromium.org/p/chromium/issues/detail?id=440870 where we ask to install into trusted.gpg.d instead of using apt-key... | 14:21 |
| seb128 | juliank, hey, looking at bug #1562733 ... is APT::Update::Post-Invoke supposed to work in case of "E:" like "E: Some index files failed to download. They have been ignored, or old ones used instead."? | 14:23 |
| ubottu | bug 1562733 in apt (Ubuntu) "apt signature requierements prevent updates from some repositories" [High,In progress] https://launchpad.net/bugs/1562733 | 14:23 |
| juliank | seb128: I forgot to update this. It currently doesn't. | 14:23 |
| juliank | We'd have to swap some lines around | 14:23 |
| seb128 | k, so not a solution to the appstream issue :-/ | 14:23 |
| juliank | seb128: I think it should start working soon, we talked about this yesterday in #debian-apt | 14:24 |
| seb128 | juliank, is that swap something you consider doing/a fix or would it be a behaviour change you don't want for some reason? | 14:24 |
| juliank | seb128: DonKult had some concerns because it was always like this; but I don't think the current state makes sense. What we want to do is make -Success run if not all sources failed. But it's slightly unclear yet how much work that is. | 14:26 |
| seb128 | juliank, would that be SRU material for 16.04? | 14:27 |
| juliank | seb128: I'd hope so. 1.2.11 in yakkety is also SRU material, BTW. | 14:27 |
| seb128 | I guess it just requires somebody taking on doing the SRU then | 14:28 |
| seb128 | juliank, thanks! | 14:28 |
| juliank | seb128: I can continue 1.2 releases for some time upstream (until 1.3 hits unstable), and they could be SRUed, as that's a sort-of-stable-series-intended-for-xenial | 14:30 |
| seb128 | juliank, that sounds good ... then I guess it would be up to mvo or infinity to handle xenial SRUs? or do you plan to handle those as well? | 14:31 |
| juliank | Well, I don't have any upload permissions... | 14:32 |
| juliank | Which means it does not really matter that much, it's just a question of who writes the SRU bug | 14:33 |
| juliank | because if I do, someone has to sponsor-ACK it | 14:33 |
| seb128 | right | 14:34 |
| === Guest30018 is now known as mfisch | ||
| === mfisch is now known as Guest56459 | ||
| pitti | slangasek, cyphermox: FYI, I did some research about packages integrating with resolvconf, and I think it's simpler better to do the DNS resolution part first/separately; I adjusted https://blueprints.launchpad.net/ubuntu/+spec/foundations-y-local-resolver accordingly | 15:05 |
| pitti | i. e. this will continue to use resolvconf for the time being, and just replace dnsmasq on the desktop and introduce it on the server | 15:05 |
| pitti | if we want to move from resolvconf to resolved for managing resolv.conf, that's doable, but rather independent, and should then become a separate BP; but this is much more work, and there is not much visible benefit | 15:06 |
| rbasak | flexiondotorg: just to be clear, those packages are things you consider part of MATE, and should be included in part of any MATE packageset, right? As opposed to any special only-you upload thing. | 15:14 |
| pitti | slangasek: I set it to "review" and proposed for yakkety (I can't accept any more); this is now all actually tested, too :) | 15:14 |
| caribou | xnox: With LP: #1564475 you raised crashkernel to 196M, then LP: #1570775 talks to add cio_ignore output to the kexec kernel | 15:16 |
| ubottu | Launchpad bug 1564475 in Ubuntu on IBM z Systems "128M is not enough for kdump on s390 LPARs" [Critical,Fix released] https://launchpad.net/bugs/1564475 | 15:16 |
| ubottu | Launchpad bug 1570775 in makedumpfile (Ubuntu) "makekdump should re-exec with cio_ignore on s390x" [Medium,Confirmed] https://launchpad.net/bugs/1570775 | 15:16 |
| caribou | xnox: what is the final decision on this one ? use cio_ignore + 128M or cio_ignore with 196M ? | 15:16 |
| flexiondotorg | rbasak, Yes, those packages are part of the MATE package set. | 15:16 |
| caribou | xnox: I'm preparing a version of kdump-tools that will set the value different if it sees an LPAR but I need to know if this is still relevant | 15:17 |
| rbasak | flexiondotorg: OK. Just checking I didn't understand something. Thank you :) | 15:17 |
| flexiondotorg | rbasak, No probs. Thanks. | 15:17 |
| rbasak | Uh, misunderstand something I meant :) | 15:18 |
| nacc | anyone else having wiki.ubuntu.com problems? https://wiki.ubuntu.com/NishanthAravamudan/YourDeveloperApplication says (while logged in) that "Immutable Page" for myself... | 15:35 |
| pitti | nacc: log out and back in, SSO sometimes gets confused | 15:37 |
| nacc | pitti: tried that 2x now, will try again | 15:38 |
| nacc | pitti: ack that | 15:38 |
| pitti | it's not immuatable for me, but the page is rendered tiiiiiiny! | 15:38 |
| nacc | pitti: that's probably what is going on, if i had to guess, though | 15:38 |
| nacc | pitti: weird :) | 15:38 |
| pitti | nacc: I tried logging out and back in, and it's now hanging after SSO auth | 15:39 |
| pitti | so, definitively something up here | 15:40 |
| nacc | pitti: yeah, login takes a long time for me, but i wonder if it's the spam prevention stuff | 15:40 |
| pitti | nacc: finished, can edit again, hmm | 15:42 |
| nacc | pitti: still immutable for me :/ | 15:43 |
| nacc | pitti: heh, restarted chrome and now i get a 500 from the login :) | 15:45 |
| nacc | pitti: second attempt, got logged in again, but immutable still | 15:46 |
| === ejat is now known as fenris- | ||
| === fenris- is now known as ejat | ||
| === ejat is now known as fenris- | ||
| === fenris- is now known as ejat | ||
| seb128 | bdmurray, hey, do you think you could look at https://bugs.launchpad.net/ubuntu/+source/apturl/+bug/1566201 ? it's the most reported e.u.c issue on the weekly summary | 16:52 |
| ubottu | Launchpad bug 1566201 in apturl (Ubuntu) "/usr/bin/apturl-gtk:AttributeError:/usr/bin/apturl-gtk@47:main:enableChannel:doEnableChannel" [Undecided,New] | 16:52 |
| seb128 | bdmurray, and any idea why https://errors.ubuntu.com/problem/25cc76910cc3cfeaf1369ca3f208f5c3710046d3 fails to get a stacktrace? | 16:53 |
| seb128 | or https://errors.ubuntu.com/problem/d4cb05c46d65d26239b285df4c0162e393f4972a | 16:53 |
| Michal_amateur | Hello, can somebody help me? I have game, I have backgroud image size 150x150 and I want multiple this picture to size for example 2000x2000. | 16:53 |
| lathiat | Hi Michal_amateur, the channel for support is #ubuntu you should try there | 16:55 |
| Michal_amateur | I see thanks, I will try | 16:56 |
| bdmurray | seb128: both of those nm-applet crashes which failed to retrace have some "?? ()" in StacktraceTop in the first 4 parts. I'll try and force a retrace of them though. | 16:57 |
| seb128 | bdmurray, do they have symbols after the ?? | 17:00 |
| seb128 | or just those? | 17:00 |
| bdmurray | seb128: http://pastebin.ubuntu.com/16321012/ | 17:02 |
| === test is now known as Guest84632 | ||
| === Guest84632 is now known as ghishadow | ||
| Umeaboy | Hi! | 19:58 |
| Umeaboy | Any plans of getting an update for the package repo? | 19:58 |
| sarnold | Umeaboy: can you rephrase your question? | 20:00 |
| Umeaboy | May I please get an update of the repo package into 15.10? | 20:05 |
| nacc | Umeaboy: existing release's versions need to follow the SRU policy at https://wiki.ubuntu.com/StableReleaseUpdates; usually new releses don't qualify in and of themselves | 20:14 |
| Umeaboy | nacc: Right, but can't the upgrade notice at least be hidden by default? | 20:45 |
| nacc | Umeaboy: what "upgrade notice"? | 20:45 |
| Umeaboy | When you run repo init you see a message that there is a newer repo and that an update is suggested to install. | 20:46 |
| nacc | Umeaboy: that's presumably something in the repo source itself? it's unmodified from Debian, so my guess is this is just how the packaged `repo` behaves | 20:50 |
| nacc | Umeaboy: if you want, file a bug, I guess | 20:51 |
| Umeaboy | OK. | 20:51 |
| Umeaboy | I'll do that. | 20:51 |
| Umeaboy | Thanks. | 20:51 |
| Umeaboy | Have to go......take care! | 20:51 |
| mwhudson | jamespage: yeah, should start using go shared libs in y | 21:03 |
| === Guest56459 is now known as mfisch | ||
| === mfisch is now known as Guest87085 | ||
| === Guest87085 is now known as mfisch | ||
| hallyn | pitti: for that deb-systemd-helper error, I filed bug 1579922 | 21:24 |
| ubottu | bug 1579922 in init-system-helpers (Ubuntu) "dh_systemd_enable fails due to 'preset' when service file is renamed" [Undecided,New] https://launchpad.net/bugs/1579922 | 21:24 |
| hallyn | (may well be my fault, but if so then Ineed gentle prodding and corretion :) | 21:24 |
| hallyn | thx | 21:24 |
| === nobuto_ is now known as nobuto | ||
| TJ- | is there any unmentioned dependency of dput that would cause it to stall whilst uploading to a PPA? According to iftop only about 871 bytes are sent - dput is showing "lubuntu-artwork_0.62.dsc: " and nothing else happens and the TCP connection eventually is dropped but dput continues sitting there until Ctrl+C | 22:23 |
| sladen | TJ-: can you try 'strace'ing it? | 22:43 |
| sladen | TJ-: you're probably found a parsing bug | 22:43 |
| TJ- | sladen: I'm using python -m trace ... and it appears to be getting stuck at the sftp client | 22:45 |
| sladen | TJ-: wireshark might be the next top | 22:47 |
| sladen | TJ-: or ssh -v and see how much setup is managed | 22:48 |
| TJ- | solved it - somehow the id_rsa* from 15.10 had been replaced by a fresh generated key on the 16.04 PC; all the other keys (i have 1 key per service/server used) were the same. After doing that there was a "sign_and_send_pubkey: signing failed: agent refused operation" error, which required "ssh-add" to let the agent know about the keys | 23:17 |
| sarnold | it might still be worth a bug report, good error messages are always nice :) | 23:18 |
| TJ- | spoke too soon. It uploaded the .dsc then failed next with "lubuntu-artwork_0.62.tar.xz: Connection to ppa.launchpad.net closed by remote host." | 23:18 |
| TJ- | this time it's continuing, showing a steady 1Mb/sec for the tar.xz file | 23:20 |
| TJ- | I think that problem was the entire ISP connection dropping - just noticed the IRC client reconnected with IPv4 instead of IPv6 | 23:21 |
| TJ- | I've never known an LTS with so many issues as 16.04. I seem to spend most of my days tracking them down | 23:22 |
| sladen | TJ-: please can you turn them into bug reports. This immediately starts to help other people Googling with the same error messages, and in the medium term allows a starting point for getting them fixed | 23:23 |
| TJ- | OK, got it again "lubuntu-artwork_0.62.tar.xz: Connection to ppa.launchpad.net closed by remote host." ... but iftop shows a steady 1Mb/sec upload still going on | 23:24 |
| TJ- | sladen: they are all bug repports | 23:24 |
| sladen | TJ-: excellent | 23:24 |
| TJ- | sladen: along with patches in most cases | 23:24 |
| sladen | TJ-: doubleplusgood! | 23:24 |
| TJ- | But it would be nice if someone learned what 'regression tests' means :) | 23:24 |
| cjwatson | some of us have 25000 of them ;-) | 23:26 |
| sarnold | you could add dep-8 tests for the things you found so they'd show up on http://ci.ubuntu.com/ if they break in the future :) | 23:26 |
| cjwatson | (upload problems to ppa.launchpad.net sound like connectivity issues, honestly - I agree with trying wireshark, you'll probably find some evidence in there) | 23:27 |
| sarnold | hmm maybe not that, that looks ancien.t | 23:27 |
| TJ- | this is nice "Successfully uploaded packages." ... despite the connection closed message... now to see if I get an Accepted email! | 23:27 |
| TJ- | cjwatson: Yes, you're the guy I want! a bug in grub2 I had to chase with a client today actually. do you recall if you were responsible for the patches/sleep_shift.patch (adds Shift keys to GRUB_TERM_ESC in sleep --interruptable) ? | 23:28 |
| TJ- | because on 16.04 Shifts no longer work, and the alternative Esc is causing issues because it is also the key that accesses the firmware's setup | 23:29 |
| TJ- | cjwatson: I shall be filing a bug report on it shortly, now I've got the plymouth-theme-lubuntu-logo bug-fix uploaded, but wondered if sleep was one of yours? | 23:30 |
| cjwatson | TJ-: I wrote that patch eons ago and it's known that it doesn't work on UEFI | 23:30 |
| cjwatson | TJ-: but it's not my responsibility any more, you want cyphermox | 23:30 |
| cjwatson | (well, not in Ubuntu anyway) | 23:30 |
| TJ- | cjwatson: right, so there's a bug report... I couldn't find one earlier but maybe I didn't search well enough | 23:31 |
| cjwatson | I don't know if there's a bug report but I knew about the issues when I wrote the patch | 23:31 |
| cjwatson | UEFI doesn't (or at least didn't at the time) permit checking the status of keyboard modifiers with zero delay | 23:31 |
| cjwatson | and I was instructed to make it zero delay | 23:32 |
| cjwatson | so meh | 23:32 |
| TJ- | ahhh bug 1028126 | 23:32 |
| ubottu | bug 1028126 in grub2 (Ubuntu) "grub hidden timeout does not react to shift" [Undecided,Confirmed] https://launchpad.net/bugs/1028126 | 23:32 |
| TJ- | cjwatson: thank-you :) I'll do some work on it then, see if I can come up with a fix | 23:32 |
| cjwatson | I have a vague recollection that I might have tried to add a delay only on UEFI, but I don't remember if that's true or if so where | 23:33 |
| cjwatson | certainly dig through the current spec version and see if you can work out a way to do zero-delay modifier checks | 23:33 |
| TJ- | cjwatson: I'm working on cryptodisk patches to add keyfile support, and detached headers, which are going upstream, but not dabbled in the GRUB term code so far, still find it easy to get lost in the modules and abstraction at times | 23:33 |
| TJ- | cjwatson: did you understand that to be a problem with UEFI itself, or GRUB's use of UEFI ? | 23:34 |
| cjwatson | UEFI itself | 23:34 |
| cjwatson | I haven't read the relevant bits of the spec for a while but at the time it was not possible to implement the getkeystatus method in grub-core/term/efi/console.c (as opposed to e.g. grub-core/term/i386/pc/console.c) | 23:35 |
| TJ- | the "zero delay" being for the HIDDEN option of GRUB2? | 23:35 |
| cjwatson | sounds right | 23:35 |
| TJ- | ahhhh... OK, I think I can tackle it now... I wasted a few hours today searching fruitless in the source-code for the shift modifier... only to realise I was in the upstream repo, not the Ubuntu patched one! | 23:36 |
| cjwatson | https://anonscm.debian.org/git/pkg-grub/grub.git will be close enough | 23:37 |
| cjwatson | debian/patches/quick_boot.patch is the bit that relies on getkeystatus | 23:38 |
| cjwatson | and that also has an attempted fallback | 23:38 |
| TJ- | thank-you, that's really helpful. | 23:38 |
| cjwatson | the Escape bit is in grub-core/commands/sleep.c:grub_check_keyboard | 23:39 |
| cjwatson | so if that were made to check some other reasonable key as well as GRUB_TERM_ESC it would probably be a reasonable workaround for your client | 23:39 |
| cjwatson | backspace or something | 23:40 |
| TJ- | is the delay required for something in GRUB to settle... in other words, maybe "priming the pump" as soon as grub starts might help | 23:40 |
| TJ- | Yes, that's one thing he asked, but trying to avoid having to maintain patches that won't ever make it into upstream or Debian/Ubuntu. He ships a *lot* of laptops with Ubuntu pre-installed | 23:41 |
| ogra_ | slangasek: i think your last livecd-rootfs change is missing bits in live-build/auto/build | 23:45 |
| cjwatson | TJ-: no "settling". the reason a delay was needed when I last checked the UEFI spec is that it could only detect transitions in modifier keys, not the current state | 23:47 |
| cjwatson | TJ-: so that only works if there's enough time for a user to press a key in the relevant window | 23:47 |
| cjwatson | TJ-: I haven't been involved upstream in a while, but I think adding some other reasonable alternative key to interrupt the sleep command could go upstream | 23:48 |
| cjwatson | TJ-: it wouldn't really conflict with much else | 23:48 |
| slangasek | ogra_: what bits? | 23:49 |
| TJ- | OK, thanks for the background, it is making a lot of sense now | 23:50 |
| cjwatson | np | 23:50 |
| TJ- | that's a real foobar on the side of UEFI if it doesn't treat the modifiers as they were always intended | 23:50 |
| ogra_ | slangasek: there are other mentions of "ubuntu-core:system-image" | 23:51 |
| cjwatson | eh, things are always fairly raw at the level of the firmware | 23:51 |
| cjwatson | pretty much by definition | 23:51 |
| slangasek | ogra_: yes; the ones I dropped were the only ones that were nested conditionals | 23:51 |
| cjwatson | and I think you're reaching with "always intended". modifiers were intended to modify other keys, originally; testing their state in isolation is a bit of an extension really | 23:51 |
| cjwatson | obviously it would be nice if we could | 23:51 |
| ogra_ | slangasek: ah, so the $PROJECT:$SUBPROJECT construct still exists ? fine then ... ignore me :) | 23:52 |
| TJ- | cjwatson: but the original IBM PC/AT hardware defined it at the I/O register level, so the bit flags represent the current state, not a transition | 23:53 |
| slangasek | ogra_: it does still exist for the moment, yes... we can eventually simplify but that's a bit more of a refactor, since there are other projects with support for builds that key on SUBPROJECT=system-image | 23:53 |
| slangasek | (whether they should or not is another question) | 23:53 |
| cjwatson | TJ-: I think it may be possible now though; looking at the current-ish spec, the EFI_KEY_STATE_EXPOSED flag to EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL.ReadKeyStrokeEx looks relevant | 23:53 |
| ogra_ | yeah, stuff for the athens sprint i guess :) | 23:54 |
| ogra_ | as long as stuff still builds allll is fine i guess | 23:54 |
| ogra_ | -ll | 23:54 |
| TJ- | cjwatson: stop already, it's not your problem :p | 23:54 |
| TJ- | cjwatson: but thanks for saving me a few hours already :D | 23:55 |
| ogra_ | (though it is yakkkety anyway .... nothing we currently focus on) | 23:55 |
| cjwatson | TJ-: looks like this may have been added in UEFI 2.4, which postdated my original work. I'll leave figuring out whether it actually works to you | 23:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!