| mwhudson | is there a package in the archive that uses symbol versions that is less complicated than glibc? | 02:18 |
|---|---|---|
| sarnold | mwhudson: if I've understand what you want correctly, the apparmor source package provides a libapparmor: http://bazaar.launchpad.net/~apparmor-dev/apparmor/master/view/head:/libraries/libapparmor/src/libapparmor.map | 02:20 |
| mwhudson | ah yeah, that seems to be what i mean | 02:20 |
| mwhudson | thanks | 02:20 |
| sarnold | I can't promise it's perfect but it's probably esaier than glibc :) | 02:20 |
| mwhudson | is the format documented somewhere? | 02:21 |
| mwhudson | man ld says "see VERSION for more" or something | 02:22 |
| mwhudson | but i don't see where it means | 02:22 |
| mwhudson | ah it all seems to be in http://www.akkadia.org/drepper/dsohowto.pdf | 02:26 |
| mwhudson | some light reading for when insomnia is a problem | 02:26 |
| sarnold | heh I was just wondering if that'd be the best source :/ | 02:26 |
| sarnold | I thought forsure I'd seen something "more official", but can't find what I was thinking of. | 02:27 |
| infinity | mwhudson: I would have recommended zlib, but apparmor seems like a decent example too. | 02:28 |
| infinity | mwhudson: Also, for docs: apt-get install binutils-doc && info ld | 02:30 |
| infinity | mwhudson: Section 3.9 is VERSION. | 02:31 |
| mwhudson | omg info | 02:31 |
| sarnold | ha! I forgot info loads manpages if youdon't have the info pages loaded. | 02:31 |
| sarnold | I checked there for VERSION but .. of course didn't have the binutils-docs loaded. | 02:32 |
| infinity | Yeah, an annoying misfeature. | 02:32 |
| sarnold | one of many. | 02:32 |
| infinity | I imagine info makes sense to emacs users, to me it's always been vile. | 02:33 |
| sarnold | next time I find an emacs user I'll ask :) | 02:33 |
| sarnold | (I wonder if 'vile' can make info less terrible?) | 02:34 |
| infinity | Oh, wow, vile - VI Like Emacs - vi work-alike | 02:34 |
| infinity | WHY IS THAT A THING? | 02:34 |
| sarnold | I ran that on dos back in the day :) | 02:35 |
| infinity | sarnold: Telemate's built-in editor was all the editor I ever needed on DOS. | 02:36 |
| sarnold | infinity: haha :) | 02:37 |
| infinity | Given that DOS only existed to play video games and run Telemate to dial into my UNIX shells at the university... | 02:37 |
| jrwren | i heard pinfo is a nicer info reader | 02:38 |
| infinity | Huh. This youtube video is basically my early teens: https://www.youtube.com/watch?v=nOx9fLBJO1w | 02:39 |
| infinity | Except that I wasn't a scrub with [UNREGISTERED] flashing in the corner. | 02:40 |
| mwhudson | oh, so the man page thing is a poor translation from texinfo or whatever | 02:42 |
| sarnold | I thought there was a nice gui info viewer, like xman, but I can't find the thing now | 02:44 |
| jrwren | xinfo? | 02:45 |
| infinity | There's tkinfo, but I wouldn't call it "nice". | 02:46 |
| infinity | pinfo is definitely nicer than the GNU client, though. | 02:47 |
| infinity | curses based, and kinda usable by normal humans. | 02:48 |
| sarnold | maybe it was tkinfo I was thikning of. I would have sworn just xaw widgets but maybe it was tk.. | 02:48 |
| mwhudson | pinfo is like pouring a nicer kind of vinegar in your eye | 02:50 |
| infinity | Arguably, the sanest modern info viewer would be a web browser frontend for the rendered and some info2html magic. | 02:50 |
| infinity | s/rendered/renderer/ | 02:50 |
| sarnold | and if we're really lucky, we'd burn the info backend once the conversion was done once :) | 02:54 |
| infinity | sarnold: Well, much like LaTeX, the info format isn't a terrible way to write/maintain documentation, it's just that you need to render it sanely to read it. | 02:55 |
| infinity | sarnold: In the case of LaTeX, rendering it sanely is entirely the point, for info, that's been a WIP for 20 years. :P | 02:55 |
| sarnold | hahaha | 02:55 |
| infinity | sarnold: But, given than no modern OS is complete without about 20 HTML rendering engines, and info node cross-referencing should map 1:1 with hyperlinking, conceptually, I figure it wouldn't be rocket surgery to build an info browser into, say, yelp. | 02:59 |
| infinity | sarnold: Or build an info browsing local web service that you could hit from any browser. | 03:00 |
| infinity | I'd actually be surprised if someone hasn't done the latter, and I just can't find it. | 03:00 |
| sarnold | I never liked the fact that the information was broken into multiple pages; I always liked manpages putting all the information in one simple pager | 03:00 |
| sarnold | I'm pretty sure I've run one of those info-to-html servers before :) | 03:00 |
| infinity | Yeah, I tend to prefer manpages too, but whenever I'm using a GNU tool, I have to suffer the pain of info. | 03:01 |
| infinity | And, to be fair, for some it would be amazingly unwieldly to have one giant manpage. | 03:01 |
| infinity | The glibc docs come to mind. | 03:01 |
| === freeflying__ is now known as freeflying | ||
| === salem_ is now known as _salem | ||
| pitti | slangasek: in ubuntu we already have a split upstart-sysv binary; I meant if that will go into Debian as well, to have the same binary package layout in both | 04:35 |
| pitti | Good morning | 04:36 |
| slangasek | pitti: it probably should at some point, but again, not something I'm committing any time to right now | 05:16 |
| pitti | slangasek: ack; I was just wondering | 05:16 |
| === tvoss|lunch is now known as tvoss | ||
| dholbach | good morning | 06:40 |
| mitya57 | infinity, I think yelp already has an info browser | 06:49 |
| Noskcaj | sil2100, Are we ok to sync libgit2-glib and gitg? The only delta is -glib's breaks on gitg < 3.15 | 07:32 |
| sil2100 | Noskcaj: I would say it should be fine to sync it | 07:38 |
| Noskcaj | ok, can you sync them or should i file sync bugs? | 07:38 |
| sil2100 | I'll try doing that today, but it might slide a bit since I still have a few other things to finish up :) | 07:42 |
| Odd_Bloke | I don't think I've ever used info; perhaps this explains some of my past confusion. :p | 07:44 |
| pitti | arges, bdmurray: I'd appreciate if you could process bug 1450009 soon -- this fixes a regression in the previous round of postgresql updates | 08:28 |
| ubottu | bug 1450009 in systemd (Ubuntu) "suspends on closed lid, does not recognized external monitors/dock" [High,Confirmed] https://launchpad.net/bugs/1450009 | 08:28 |
| pitti | arges, bdmurray: erk, I meant bug 1461425 (just a formality, postgresql has an MRE) | 08:28 |
| seb128 | pitti, wrong bug number? ;-) | 08:28 |
| ubottu | bug 1461425 in postgresql-9.1 (Ubuntu Precise) "New upstream microreleases 9.1.17, 9.3.8, 9.4.3 - fixes regression in previous update" [High,In progress] https://launchpad.net/bugs/1461425 | 08:28 |
| seb128 | hehe | 08:28 |
| pitti | seb128: -ETOOMANYTABS | 08:28 |
| seb128 | seems like pitti has systemd autofingers nowadays :p | 08:29 |
| pitti | seb128: yeah, I cannot even write the word <tries very hard> "system" any more :) | 08:29 |
| seb128 | :-) | 08:29 |
| Silentlord | hi, i want an email to contact someone regards application reviewing | 09:58 |
| pete-woods | hi, I seem to be unable to modify bugs on the indicator-network source package (which I maintain / develop) | 10:12 |
| pete-woods | https://launchpad.net/ubuntu/+source/indicator-network | 10:12 |
| pete-woods | can someone tell me how to become a member of "Ubuntu Developers | 10:12 |
| pete-woods | (you'd think I'd already be a member, given I'm employed by Canonical) :p | 10:14 |
| cjwatson | Ubuntu Developers relates to direct upload access and is a community process, not a Canonical process | 10:17 |
| highvoltage | hey pete-woods, http://fridge.ubuntu.com/2011/01/27/becoming-an-ubuntu-developer-a-short-guide/ is slightly dated but still mostly good | 10:17 |
| cjwatson | https://wiki.ubuntu.com/UbuntuDevelopers | 10:17 |
| cjwatson | But there are other ways to get what you want: https://wiki.ubuntu.com/UbuntuBugControl | 10:17 |
| pete-woods | cjwatson: thanks. I think that's more what I'm after :) | 10:19 |
| pete-woods | highvoltage: seems like I don't want to actually become an "ubuntu developer" | 10:19 |
| === RzR is now known as rZz | ||
| larsu | pete-woods: someone needs to set the maintainer of that project to indicator-applet-developers | 10:23 |
| larsu | which is what all the other indicator projects have | 10:23 |
| pete-woods | larsu: that sounds like a more sensible value to me | 10:23 |
| larsu | pete-woods: wait, you are already in ~pspmteam, so this should work | 10:25 |
| larsu | ah my bad. You want to be able to change *ubuntu* bugs | 10:25 |
| pete-woods | larsu: the others (source packages here) look to be maintained my Ubuntu Desktop | 10:25 |
| pete-woods | yeah | 10:25 |
| pete-woods | we're supposed to have all our bugs on the source package now | 10:25 |
| larsu | right, you won't get into ubuntu desktop | 10:26 |
| pete-woods | indeed | 10:26 |
| larsu | UbuntuBugControl is what you want | 10:26 |
| pete-woods | cool | 10:26 |
| pete-woods | I just need to get a | 10:26 |
| larsu | it's fairly easy to join if you're a developer | 10:26 |
| pete-woods | "showcase of my best 5 bug triages" | 10:26 |
| pete-woods | I'm not sure I've done much other than merge branches to fix bugs, though | 10:26 |
| pete-woods | kinda feels like my whole team "unity api team" should be in the bug control group | 10:29 |
| pete-woods | instead of us each having to apply manually | 10:29 |
| pete-woods | oh, it says to contact jcastro if you are an upstream developer? does that mean I don't have to go through the full application process? | 10:40 |
| === doko_ is now known as doko | ||
| rbasak | pete-woods: you can have a team membership to the bug control group: https://wiki.ubuntu.com/UbuntuBugControl#Requirements_for_Teams | 11:12 |
| rbasak | The Canonical Server Team has one. | 11:12 |
| === MacSlow is now known as MacSlow|lunch | ||
| pitti | rbasak: thanks for pinging the biosdevname bug! | 11:45 |
| rbasak | pitti: no problem. Sorry I hadn't followed up on this before. | 11:54 |
| rbasak | pitti: I've also asked internally to see if we can find a Dell contact. | 11:55 |
| rbasak | (well, delegated that to my manager at least) | 11:55 |
| pitti | rbasak: cool, thanks | 11:55 |
| pete-woods | rbasak: yeah, I think I'll have to put in an application for one :) | 12:01 |
| rbasak | Any reason to continue maintaining an upstart job in the Ubuntu delta for squid3? I can drop it now, right? | 12:17 |
| === gammax90 is now known as gammax | ||
| jcastro | pete-woods: just have someone from your team send me a mail and I'll add you today | 12:22 |
| jcastro | that page is mostly for 3rd party developers who have a package in universe or something and want to triage their own bugs | 12:22 |
| pete-woods | jcastro: okay, cool, will send you a mail now :) | 12:24 |
| LocutusOfBorg1 | doko, ping :) | 12:29 |
| LocutusOfBorg1 | I hope you read there, I would like to know if it is ok for you to upload casablanca with CXX=g++5 in unstable (the ABI problem) | 12:29 |
| === MacSlow|lunch is now known as MacSlow | ||
| === _salem is now known as salem_ | ||
| rbasak | Any reason to continue maintaining an upstart job in the Ubuntu delta for squid3? I can drop it now, right? | 13:06 |
| seb128 | rbasak, slangasek or pitti might help you there, unsure if we still want to support booting with upstart | 13:07 |
| caribou | Q: Would adding an upstart job to an existing package in trusty acceptable for an SRU ? | 13:08 |
| caribou | rbasak: I'm facing the same upstart question in Wily wrt my Trusty SRU question | 13:42 |
| caribou | rbasak: I need to add an upstart job for kdump-tools for Trusty but should I also worry about adding it to Wily, as Wily uses the systemd service | 13:42 |
| caribou | In short, do we consider Wily + upstart a supported option ? | 13:43 |
| pitti | rbasak: I think we should still keep upstart working until at least 16.04 LTS | 14:02 |
| pitti | rbasak: now, if squid3 has an init.d script which essentially does the same as the upstart job, it's fine to drop | 14:02 |
| pitti | rbasak: but if it does ubuntu specific things, we should keep it (or adjust the init.d script instead) | 14:02 |
| rbasak | pitti: it has an init.d script from Debian and we were previously adding the upstart job. There'd the odd reported bug with the upstart script and so I think the init.d script is of higher quality. So I'll just drop the upstart job - thanks. | 14:04 |
| pitti | rbasak: ack | 14:04 |
| slangasek | rbasak: no, for 15.04 and beyond I don't think there's any reason to carry a delta for an upstart job. it's reasonable and appropriate to submit that upstart job for upstream inclusion in Debian, though, where upstart is still an option | 14:28 |
| hallyn | infinity: hi - any newer thoughts on bug 1454862 ? | 14:42 |
| ubottu | bug 1454862 in lxcfs (Ubuntu) "[SRU][MRE] merge 0.9 (which is currently in wily) to vivid" [Undecided,Confirmed] https://launchpad.net/bugs/1454862 | 14:42 |
| === Malsasa is now known as Guest29295 | ||
| === Malsasa_ is now known as Malsasa | ||
| infinity | hallyn: I'm not big on thinking in the morning, but I'll get back to you. | 14:55 |
| === PaulW2U_ is now known as PaulW2U | ||
| hallyn | thx | 15:15 |
| infinity | pitti: Can you confirm for me that all new ddebs are coming via the librarian and if I flatten a buildd (thus losing public_html), we won't lose anything? | 15:48 |
| cjwatson | infinity: ddebs.u.c has had its direct buildd retrieval switched off for at least a couple of weeks now | 15:51 |
| pitti | infinity: yes, I disabled all the apache polling | 15:54 |
| pitti | I should actually commit that, thanks for the reminder | 15:55 |
| infinity | cjwatson, pitti: Excellent. Then, in the name of d-i testing, today might finally be the day the arm64 buildds get reinstalled with a distro kernel. | 15:55 |
| cjwatson | Just in time to replace them with Moonshot </not-really> | 15:55 |
| infinity | cjwatson: Yeah, I noted the same irony. | 15:55 |
| infinity | cjwatson: But realistically, I'm sure these Mustangs will be in service for a couple/few more months still, unless we really get our ducks in a row. | 15:56 |
| cjwatson | Yeah | 15:56 |
| infinity | They've treated us remarkably well. I kinda want one in my house. | 15:57 |
| infinity | After we squished the worst issues, they've since been clocking uptime in the months, and the only interruptions for the last year have been DC power maintenance. | 15:57 |
| cjwatson | Let's hope the distro kernel isn't worse. Is this for page size changes? | 15:57 |
| pitti | arges: what was wrong with the utopic/vivid postgresql-9.4? | 15:58 |
| pitti | arges: I'll sync wily from unstable once it hits, but that won't happen until Friday or so | 15:58 |
| infinity | cjwatson: No. Mostly, it's cause I need to test trusty's d-i, but it's also just an excuse to be running our own code, get SRU updates, etc. | 15:58 |
| infinity | cjwatson: But it might also fix some longstanding bugs, like hangs in the gdb testsuite, etc. | 15:58 |
| cjwatson | Fair enough | 15:58 |
| infinity | cjwatson: I also have a sneaking suspicion that the combination of new firmware and new kernel might fix the abysmal I/O and suddenly make those buildds quite a bit speedier. But that's hard to know for sure without trying. | 15:59 |
| cjwatson | Try one or two at a time, I guess | 16:01 |
| infinity | cjwatson: Yeah, I'm only killing one today. See how it holds up under load, then I can do the other 4. | 16:01 |
| * cjwatson nods | 16:01 | |
| pitti | arges: https://launchpad.net/ubuntu/+source/postgresql-9.3/9.3.8-0ubuntu0.4.04 -> erk, version typo | 16:19 |
| pitti | arges: should have been 14.04; but it doesn't matter actually, there's no other release with 9.3, so *shrug* | 16:19 |
| infinity | pitti: 4.04, though? Well done on inventing a release before warty. | 16:21 |
| pitti | infinity: right, it's the 404 release -- not found :) | 16:21 |
| infinity | :) | 16:21 |
| infinity | pitti: And now I realize that Mark missed a great opportunity to use HTTP responses as version numbers instead of using dates. | 16:22 |
| infinity | Those release would have been self-naming too. | 16:22 |
| infinity | Might have even been vaguely appropriate for the first release (100) to be "continue". | 16:24 |
| arges | pitti: yikes sorry about that | 16:30 |
| pitti | arges: no worries | 16:45 |
| pitti | arges: oh, you were able to re-accept the old utopic package? I thought that wouldn't work | 16:45 |
| pitti | arges: anyway, if it works, we can reject the 14.04.1 package from the queue, and otherwise use that | 16:46 |
| pitti | arges: thanks! | 16:46 |
| pitti | arges: nevermind, I mis-looked | 16:47 |
| arges | ah pitti's gone | 17:02 |
| === _salem is now known as salem_ | ||
| === JanC_ is now known as JanC | ||
| menace | Hi, i want to use /etc/cron.daily/apt to download the current/new debian packages. but i only want to install them from the local cache at boot or shutdown. is this possible with unattended-upgrades. I'm not sure if the modes/variables for /etc/cron.daily/apt and unattended-upgrade are the same, so both would only download OR download and install in one step, but i want to have it in two separate steps... | 18:45 |
| === rZz is now known as RzR | ||
| === salem_ is now known as _salem | ||
| === Elimin8r is now known as Elimin8er | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!