| === bebonu is now known as bejonu | ||
| cjwatson | Unit193: Sure, shouldn't be too hard. | 00:16 |
|---|---|---|
| Unit193 | \o/ | 00:17 |
| cjwatson | cyphermox: (I'm happy to do it) | 00:17 |
| infinity | cjwatson: Oo. Very tempted to move all the ubuntu-core-dev seeds to git this cycle if we get germinate-update-metapackage --git | 00:28 |
| cjwatson | And why not. | 00:30 |
| infinity | Oh, except we kinda need to move everyone at once, unless you combine --bzr and --git to a new --vcs that parses the URI and DTRT. | 00:30 |
| infinity | So we can get platform from A and flavour from B. | 00:30 |
| cjwatson | infinity: Something like that might be a little saner, yes | 00:32 |
| cjwatson | infinity: Although moving everyone at once wouldn't actually be hard, but it's the principle of the thing | 00:32 |
| infinity | cjwatson: Moving everyone at once means informing them all and making sure they know how to use git, etc. | 00:35 |
| cjwatson | Yeah | 00:35 |
| infinity | cjwatson: A third option, instead of magic parsers, though, is just to keep platform mirrored realtime in bzr until everyone's moved. | 00:35 |
| Unit193 | FWIW, I'm pretty sure Xubuntu would be very, very much OK with this. | 00:36 |
| cjwatson | infinity: I can probably figure out how to make it reasonably magic. | 00:36 |
| cjwatson | I've spent most of the last three months doing things involving making bzr and git coexist more happily. :-P | 00:37 |
| infinity | :) | 00:37 |
| cjwatson | infinity: Say, didn't we bring up the fact that gcc no longer speaking -m32 on ppc64el breaks the grub2 build? Did that get fixed somewhere? | 00:38 |
| infinity | cjwatson: I thought we reverted that in gcc. Or did it get unreverted again? | 00:38 |
| infinity | Hrm, sure looks like it. | 00:39 |
| cjwatson | Yup, neither gcc-4.9 nor gcc-5 support it in Debian unstable right now. | 00:39 |
| infinity | cjwatson: So, we could switch back to using a cross-compiler, but I really think having it speak -m32 is the right answer. And I kept meaning to have an argument with upstream about the default being wrong, so doko doesn't whine that he's deviating. | 00:40 |
| cjwatson | Mind chasing that with doko? | 00:40 |
| cjwatson | I would really rather not switch back to cross-compiling. We put so much effort into demoting that stack. | 00:40 |
| infinity | Hrm? The cross compilers are all in main for other reasons. | 00:40 |
| cjwatson | And I don't think it's even possible in Debian. | 00:40 |
| infinity | And are landing in Debian any minute now. | 00:40 |
| infinity | But I still think -m32 for freestanding binaries makes perfect sense on ppc64el. | 00:41 |
| infinity | And it's a design flaw that attempts to disable ppcel entirely disable 32-bit compilation. | 00:41 |
| cjwatson | Well, err, OK I guess, but -mbig-endian -m32 is a sane thing, as you say. | 00:41 |
| cjwatson | Also it made my packaging a good deal less ugly not to have to use a cross-compiler. :-P | 00:42 |
| infinity | cjwatson: I'll see about bringing it up with IBM folks. I believe the patch that broke it came from Alan. | 00:43 |
| cjwatson | * Configure with --enable-targets=powerpcle-linux on ppc64el for | 00:43 |
| cjwatson | backports to jessie, trusty, utopic and vivid. | 00:43 |
| cjwatson | So only reverted for the things I'm not using? | 00:43 |
| cjwatson | Or maybe I misunderstand that. | 00:43 |
| infinity | cjwatson: No, you read that correctly. I think doko wanted to stick with upstream defaults for sid/wily, but understood that we relied on that feature for stables and we weren't about to fix the world to accomodate. | 00:44 |
| cjwatson | Ah, so that went with the upstream change. | 00:44 |
| infinity | cjwatson: So, I get his argument, sort of, but I think upstream is wrong. I'll chase from both directions when I'm not quite as vacationy. | 00:44 |
| infinity | cjwatson: Feel free to argue with doko about the Debian/Ubuntu default before then, though. :P | 00:45 |
| cjwatson | Right, thanks. I guess we can just leave grub2 in a busted state in the meantime. | 00:45 |
| cjwatson | (stuck in unstable/-proposed) | 00:45 |
| cjwatson | cyphermox: ^- | 00:45 |
| infinity | cjwatson: The most annoying bit is that in the thread about the patches that disabled ppcle, someone suggested just tearing out the backend if it wasn't wanted, and Alan said "oh, but I use it for testing, so I'm keeping it". | 00:46 |
| infinity | cjwatson: So, the same person who disabled it also doesn't disable it locally. :P | 00:46 |
| infinity | cjwatson: FWIW, is this method of building GRUB a Debian oddity, or is it enshrined in upstream makefiles too that powerpc64le == -mbig/-m32 for the bootloader bits? | 00:49 |
| infinity | cjwatson: If it was upstream, that would be a much stronger argument for the GCC default being just plain wrong. | 00:49 |
| infinity | (Given that some overzealous keener porter GRUB to ppc64le, which is effectively useless, it's possible the upstream makefiles do entirely the wrong thing...) | 00:51 |
| infinity | s/porter/ported/ | 00:51 |
| cjwatson | infinity: Paulo sent it upstream, although I don't think it was actually applied. | 00:51 |
| cjwatson | Though it got a sort of ambiguous semi-ack. It was during my mostly-burnt-out period. | 00:52 |
| infinity | cjwatson: "it" being big/32, or the misguided ppc64le port? | 00:53 |
| cjwatson | The former. | 00:53 |
| infinity | cjwatson: Mmkay. Well, I'm going to buy some ice cream and continue on my quest to see how fat I can get on my vacation, but I'll put this on my "whine to IBM" list and, if I get no traction with them, me "whine to doko" list. | 00:56 |
| sarnold | hehe | 00:56 |
| infinity | s/, me/, my/ | 00:56 |
| infinity | sarnold: Speaking of whining and IBM, they continue to ask every few weeks about the state of the messy ppc64-diag MIR. | 00:56 |
| sarnold | infinity: oof. tyler and jamie are going over the backlog of security team issues and they do know the ppc64-diag's dependent packages are still outstanding | 00:57 |
| sarnold | infinity: I havent looked over the changes in the new tarball, either; I sked for so much I'm almost scared to find out how much they changed.. | 00:58 |
| cjwatson | infinity: Enjoy :-) | 00:58 |
| cjwatson | I enjoyed writing https://git.launchpad.net/germinate/commit/?id=54c933eecf57cfa10526432740cc27f7b7671446 | 00:58 |
| infinity | sarnold: Well, I'm less concerned about them making all the changes you asked for, I know they're good for it, and more about just getting all the deps reviewed with the same level of scrutiny, so we can go with a promote-and-fix-later approach. | 00:59 |
| infinity | sarnold: I think you opened a lot of eyes with your first review, and shook up some of their teams. :P | 01:00 |
| infinity | -build | 01:01 |
| infinity | +/build | 01:01 |
| sarnold | infinity: makes sense; I'm glad they followed through on the "fix later" bit, at least in intention :) | 01:01 |
| infinity | cjwatson: ^-- Does gitignore anchor differently or something? | 01:01 |
| Unit193 | cjwatson: What'd you use for the conversion? | 01:01 |
| cjwatson | infinity: I didn't have to add that, but it forces it to anchor at the start, yeah. './build' would've been the equivalent in .bzrignore. | 01:02 |
| cjwatson | Unit193: I actually forget, I did it a little while back as a test case for LP git. I'd either have used git-bzr or (more likely) bzr fast-export | git fast-import. | 01:03 |
| cjwatson | Unit193: For more complicated cases involving non-trivial surgery on merges and the like, I usually use reposurgeon. | 01:03 |
| Unit193 | cjwatson: I've used bzr fast-export the most for this, but had to patch it for it to work correctly. Not heard of reposurgeon, thanks. | 01:05 |
| wgrant | bzr fast-export has some correctness bugs that need a fair bit of work to fix. | 01:06 |
| cjwatson | Unit193: Yeah, likewise. | 01:06 |
| wgrant | We should really fix them, but I have a working version of bzr-git in the interim. | 01:06 |
| cjwatson | Either way, you have to put a lot of effort into getting upstream->packaging merges right, IME. | 01:06 |
| Unit193 | wgrant: This got the basics, at least http://paste.openstack.org/show/eaeoGONThMUuJiyqtm0e | 01:07 |
| cjwatson | But for a native package it's not too much trouble. | 01:07 |
| cjwatson | For a non-native package, these days upstream is usually in git and you want to stitch your packaging history into upstream's (at least if you do full-tree VCS). | 01:07 |
| === salem_ is now known as _salem | ||
| === bejonu is now known as irobevjodu | ||
| === iulian is now known as Guest71803 | ||
| === nobuto_ is now known as nobuto | ||
| === ubott2 is now known as ubottu | ||
| === popey_ is now known as popey | ||
| === stgraber_ is now known as stgraber | ||
| oliver_ | if here no one think to include maintained packages in LTS distros. than we need no long term support. example gcc 4.8 old stuff, llvm with a libc++ v1 and so on. thats crazy! what meens long term??? to wait if everyone is frustated? C++11 and C++14 the new standards and must work in LTS OSes. Or not? | 13:27 |
| oliver_ | you going in the direction from mickysoft. you start to ignore the importants of saying long term. working on newer versions of ubuntu like 14.10, 15.04 and the next longterm 16.04 LTS. what is to get a working solution in one version and not to develop on more then one version of ubuntu. | 13:31 |
| oliver_ | people need stuff to work with. have a nice day. | 13:32 |
| oliver_ | no one gives a answer. thats what i meen with ignoring everything whats happen around. you can't make somthing popular with this attitude !!!!!!!!!!!!!! | 13:35 |
| s1aden | hello oliver_, sorry nobody was quick enough. Alot of people focused on Ubuntu now work "9-5" on weekdays, it's a Saturday, and I believe in Germany Thursday was a bank holiday too... so very likely that people are away on holiday | 13:43 |
| s1aden | oliver_ if you hang around a little longer, or can point to a bug report for context it may be possible to get you a better answer | 13:44 |
| === s1aden is now known as sladen | ||
| sladen | oliver_: and without a full name it's going to be hard to find you on Launchpad to follow-up | 13:45 |
| teward | need some guidance before I go insane. I'm trying to write an apport hook for the nginx package so when installing/upgrading fails it also automatically pulls in information from `systemctl status nginx.service` and `journalctl -u nginx.service` to supplement the bug information. This is due to there being three or four bugs of "Failed to install/upgrade" but no usable information on it because there's no information about *why* it failed to | 14:26 |
| teward | install/upgrade, just that it did, and that it needs data from systemd to try and diagnose | 14:26 |
| teward | anyone want to give me guidance on how to write an apport hook to achieve this? | 14:26 |
| teward | my next question is how to test if the hook works... | 14:28 |
| sladen | teward: if it's failing to upgrade it's more likely a packaging issue; in which case (and I could be wrong here), the failure hook might want to be against the cross-release upgrade script. | 14:28 |
| sladen | teward: if you can dump 'systemctl status nginx.service' etc to stderr it should make it as far as the system logs and be uploaded that way | 14:29 |
| teward | sladen: lets just say i didn't write the init script and don't have time/luxury to make it log to stderr and i've already made complaints to Debian to fix it too | 14:29 |
| teward | since their init/upstart/systemd scripts USED to be nice and verbose | 14:30 |
| teward | but they changed it and everyone is losing. | 14:30 |
| sladen | teward: less of blaming people, and please be civil here | 14:30 |
| sladen | teward: my understanding is that you came here wanting other people's time and help | 14:30 |
| teward | ... | 14:30 |
| sladen | teward: people are more likely to provide their time and help on a Sunny bank holiday weekend, if you're willing to put in your own time to. If one "do[es]n't have time" oneself, it might be considered unfair to ask the same of others | 14:32 |
| teward | sladen: i fail to see where i wasn't civil. secondly, i've gone over the init scripts before, and the bugs and attempted replication without success, which requires that these 'package install/upgrade triggered' bugs need additional information included in them. When attempting to reproduce the installs, it does not fail to install with clean VMs, so i need additional... | 14:32 |
| teward | ... info added to the bug, and this has been an issue since the 15.04 release | 14:32 |
| teward | sladen: the problem is, that even with changes to the init scripts in the package to be more verbose and log to stderr, that information doesn't show up to the public with systemd, even when I tried such things | 14:32 |
| teward | and the bugs don't include that information. | 14:32 |
| teward | the problem still exists that the additional information needs to be queried/obtained by apport in order to attach to "Failed in install/upgrade" bugs. Because the install fails when the service tries to start | 14:33 |
| sladen | teward: is there a holding bug for this "nginx failed to install/upgrade", so that everything can be kept together in one place? | 14:33 |
| teward | sladen: i've had direct emails on this problem with three separate causes, but that's on an email chain, NOT any bugs, all the bugs are alarmingly data-less and can't be duped to one another without information from the posters in order to glean the cause | 14:34 |
| teward | sladen: these are the current ones: https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1449903, https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1455766, https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1447294 | 14:36 |
| ubottu | Launchpad bug 1449903 in nginx (Ubuntu Vivid) "package nginx-core 1.6.2-5ubuntu3 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,Incomplete] | 14:36 |
| ubottu | Launchpad bug 1455766 in nginx (Ubuntu) "package nginx-core 1.6.2-5ubuntu3 failed to install/upgrade: subproces post-installation script geïnstalleerd gaf een foutwaarde 1 terug" [Undecided,New] | 14:36 |
| sladen | teward: can we create a holding bug, and get the email contents into it. There might be subtle information or cominality that has been overlooked | 14:36 |
| ubottu | Launchpad bug 1447294 in nginx (Ubuntu Vivid) "package nginx-full 1.6.2-5ubuntu3 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [High,Incomplete] | 14:36 |
| sladen | excellent | 14:36 |
| teward | sladen: i'll have to go digging for the emails... | 14:36 |
| teward | sladen: and i know for a fact two of the emails were "Hey, I don't want to make a public bug on this, can you help" types of bugs | 14:36 |
| teward | so... | 14:36 |
| teward | s/of bugs/of emails/ | 14:37 |
| teward | sladen: and i know from one person who 'hijacked' 1447294 (it wasn't their bug) that their issue was using named upstream locations without IP addresses, which is a known race condition/problem at boot/service install times where it doesn't always succeed in lookups | 14:38 |
| sladen | it gets difficult if people don't report things. :) | 14:38 |
| teward | sladen: it gets more difficult when you email them for information requests and get "apache loads first and binds" problems and "DNS lookup failed, cannot bind" problems which are unrelated to the packaging | 14:38 |
| teward | those're the big ones | 14:38 |
| teward | the third is PEBKAC and a failure to use configuration files which are actually correct, but that's less a bug and more user problems | 14:39 |
| teward | sladen: however, this is the... what fourth bug on this i've seen in the past two months, and nobody's responding for reqs for info | 14:39 |
| teward | sladen: hence the need for me to have apport 'do the work for them'... :/ | 14:39 |
| sladen | so reading bug #1447294, it's being suggested that it appears to be a DNS resolution issue as result of hard-coded domainname in the config files | 14:39 |
| ubottu | bug 1447294 in nginx (Ubuntu Vivid) "package nginx-full 1.6.2-5ubuntu3 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [High,Incomplete] https://launchpad.net/bugs/1447294 | 14:39 |
| teward | sladen: note the discrepancy. Poster vs. commenter. | 14:40 |
| teward | sladen: that wasn't their bug | 14:40 |
| teward | sladen: i also commented that their problem isn't fixable, it's a known race condition between nginx vs. system, and i already emailed nginx-devel lists to try and determine if they know how to fix it or not | 14:40 |
| teward | sladen: but since the actual original bug has no information, well... | 14:41 |
| teward | that's why it's "Incomplete", not "Won't Fix" due to "No sane way to control this" | 14:41 |
| sladen | teward: I've marked them as dups for the moment; all three appear to have some logs from upgrade | 14:42 |
| teward | sladen: which if you dig through give you bupkes | 14:42 |
| teward | sladen: hence my reqs for the systemd command, and my more recently discovered command of the journalctl to find nginx information | 14:43 |
| teward | but with nobody giving information and four bugs on this, i'd LOVE to force apport to include that information going forward | 14:43 |
| teward | at least in wily, perhaps Vivid if the SRU team allows the change | 14:43 |
| sladen | teward: would you be able to dup the the fourth one aswell. This helps to give a better indiciation of the scale of the problem | 14:44 |
| teward | god i'm tired... i need coffee. | 14:44 |
| teward | sladen: s/four/three/, s/fourth/third/ | 14:44 |
| teward | the bug that i keep thinking is the 4th is an ancient bug from 13.10 and needs confirmed if it still exists xD | 14:45 |
| sladen | teward: I think pitti might be the best placed to help; but likely won't be around until Monday | 14:45 |
| teward | blargh. | 14:45 |
| teward | no problem. | 14:45 |
| sladen | teward: which is why what we can do in the mean-time is consolidate everything possible into the bug report | 14:45 |
| teward | sladen: ack. | 14:45 |
| teward | sladen: and of course, tell people to actually attach information... | 14:45 |
| teward | triager/developer's worst problem: people don't actually attach followup information | 14:46 |
| teward | even when requested | 14:46 |
| * teward yawns. | 14:46 | |
| sladen | teward: indeed. And the other thing you can do from your emails is subscribe the people who have reported it privately to that bug report | 14:46 |
| sladen | teward: so that they can follow the discussion too, without having to file a bug report themselves | 14:46 |
| teward | sladen: force-of-habit from work: don't subscribe people unnecessarily. I gave them links to it all thoug | 14:46 |
| teward | sladen: that way they can subscribe themselves. That's a habit i've picked up, not necessarily a good one, but meh | 14:47 |
| sladen | by not subscribing them directly, you're making more work for yourself, but having to back-and-forth | 14:47 |
| * teward shrugs | 14:47 | |
| sladen | so while it might seem fairly to them, you should (as you noted above) remember your time too | 14:48 |
| teward | mmm | 14:48 |
| teward | sladen: my time right now is going to go to coffee... i have been awake and beating at the nginx packaging (for 1.9.x because reasons) for three hours and had no food or coffee today... i'll be back later, probably with more questions | 14:48 |
| teward | (it's probably why i came off as less than civil and irritable earlier) | 14:50 |
| Unit193 | didi<tab><tab><tab><tab> dangit, still hiding. | 14:53 |
| === PaulW2U_ is now known as PaulW2U | ||
| === Nigel_ is now known as G | ||
| strikov | Hi guys. Is it okay that systemd-udevd gets started by upstart? | 17:25 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!