[02:18] is there a package in the archive that uses symbol versions that is less complicated than glibc? [02:20] 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] ah yeah, that seems to be what i mean [02:20] thanks [02:20] I can't promise it's perfect but it's probably esaier than glibc :) [02:21] is the format documented somewhere? [02:22] man ld says "see VERSION for more" or something [02:22] but i don't see where it means [02:26] ah it all seems to be in http://www.akkadia.org/drepper/dsohowto.pdf [02:26] some light reading for when insomnia is a problem [02:26] heh I was just wondering if that'd be the best source :/ [02:27] I thought forsure I'd seen something "more official", but can't find what I was thinking of. [02:28] mwhudson: I would have recommended zlib, but apparmor seems like a decent example too. [02:30] mwhudson: Also, for docs: apt-get install binutils-doc && info ld [02:31] mwhudson: Section 3.9 is VERSION. [02:31] omg info [02:31] ha! I forgot info loads manpages if youdon't have the info pages loaded. [02:32] I checked there for VERSION but .. of course didn't have the binutils-docs loaded. [02:32] Yeah, an annoying misfeature. [02:32] one of many. [02:33] I imagine info makes sense to emacs users, to me it's always been vile. [02:33] next time I find an emacs user I'll ask :) [02:34] (I wonder if 'vile' can make info less terrible?) [02:34] Oh, wow, vile - VI Like Emacs - vi work-alike [02:34] WHY IS THAT A THING? [02:35] I ran that on dos back in the day :) [02:36] sarnold: Telemate's built-in editor was all the editor I ever needed on DOS. [02:37] infinity: haha :) [02:37] Given that DOS only existed to play video games and run Telemate to dial into my UNIX shells at the university... [02:38] i heard pinfo is a nicer info reader [02:39] Huh. This youtube video is basically my early teens: https://www.youtube.com/watch?v=nOx9fLBJO1w [02:40] Except that I wasn't a scrub with [UNREGISTERED] flashing in the corner. [02:42] oh, so the man page thing is a poor translation from texinfo or whatever [02:44] I thought there was a nice gui info viewer, like xman, but I can't find the thing now [02:45] xinfo? [02:46] There's tkinfo, but I wouldn't call it "nice". [02:47] pinfo is definitely nicer than the GNU client, though. [02:48] curses based, and kinda usable by normal humans. [02:48] maybe it was tkinfo I was thikning of. I would have sworn just xaw widgets but maybe it was tk.. [02:50] pinfo is like pouring a nicer kind of vinegar in your eye [02:50] Arguably, the sanest modern info viewer would be a web browser frontend for the rendered and some info2html magic. [02:50] s/rendered/renderer/ [02:54] and if we're really lucky, we'd burn the info backend once the conversion was done once :) [02:55] 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] 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] hahaha [02:59] 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. [03:00] sarnold: Or build an info browsing local web service that you could hit from any browser. [03:00] I'd actually be surprised if someone hasn't done the latter, and I just can't find it. [03:00] 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] I'm pretty sure I've run one of those info-to-html servers before :) [03:01] 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] And, to be fair, for some it would be amazingly unwieldly to have one giant manpage. [03:01] The glibc docs come to mind. === freeflying__ is now known as freeflying === salem_ is now known as _salem [04:35] 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:36] Good morning [05:16] pitti: it probably should at some point, but again, not something I'm committing any time to right now [05:16] slangasek: ack; I was just wondering === tvoss|lunch is now known as tvoss [06:40] good morning [06:49] infinity, I think yelp already has an info browser [07:32] sil2100, Are we ok to sync libgit2-glib and gitg? The only delta is -glib's breaks on gitg < 3.15 [07:38] Noskcaj: I would say it should be fine to sync it [07:38] ok, can you sync them or should i file sync bugs? [07:42] I'll try doing that today, but it might slide a bit since I still have a few other things to finish up :) [07:44] I don't think I've ever used info; perhaps this explains some of my past confusion. :p [08:28] 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] bug 1450009 in systemd (Ubuntu) "suspends on closed lid, does not recognized external monitors/dock" [High,Confirmed] https://launchpad.net/bugs/1450009 [08:28] arges, bdmurray: erk, I meant bug 1461425 (just a formality, postgresql has an MRE) [08:28] pitti, wrong bug number? ;-) [08:28] 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] hehe [08:28] seb128: -ETOOMANYTABS [08:29] seems like pitti has systemd autofingers nowadays :p [08:29] seb128: yeah, I cannot even write the word "system" any more :) [08:29] :-) [09:58] hi, i want an email to contact someone regards application reviewing [10:12] hi, I seem to be unable to modify bugs on the indicator-network source package (which I maintain / develop) [10:12] https://launchpad.net/ubuntu/+source/indicator-network [10:12] can someone tell me how to become a member of "Ubuntu Developers [10:14] (you'd think I'd already be a member, given I'm employed by Canonical) :p [10:17] Ubuntu Developers relates to direct upload access and is a community process, not a Canonical process [10:17] 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] https://wiki.ubuntu.com/UbuntuDevelopers [10:17] But there are other ways to get what you want: https://wiki.ubuntu.com/UbuntuBugControl [10:19] cjwatson: thanks. I think that's more what I'm after :) [10:19] highvoltage: seems like I don't want to actually become an "ubuntu developer" === RzR is now known as rZz [10:23] pete-woods: someone needs to set the maintainer of that project to indicator-applet-developers [10:23] which is what all the other indicator projects have [10:23] larsu: that sounds like a more sensible value to me [10:25] pete-woods: wait, you are already in ~pspmteam, so this should work [10:25] ah my bad. You want to be able to change *ubuntu* bugs [10:25] larsu: the others (source packages here) look to be maintained my Ubuntu Desktop [10:25] yeah [10:25] we're supposed to have all our bugs on the source package now [10:26] right, you won't get into ubuntu desktop [10:26] indeed [10:26] UbuntuBugControl is what you want [10:26] cool [10:26] I just need to get a [10:26] it's fairly easy to join if you're a developer [10:26] "showcase of my best 5 bug triages" [10:26] I'm not sure I've done much other than merge branches to fix bugs, though [10:29] kinda feels like my whole team "unity api team" should be in the bug control group [10:29] instead of us each having to apply manually [10:40] 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? === doko_ is now known as doko [11:12] pete-woods: you can have a team membership to the bug control group: https://wiki.ubuntu.com/UbuntuBugControl#Requirements_for_Teams [11:12] The Canonical Server Team has one. === MacSlow is now known as MacSlow|lunch [11:45] rbasak: thanks for pinging the biosdevname bug! [11:54] pitti: no problem. Sorry I hadn't followed up on this before. [11:55] pitti: I've also asked internally to see if we can find a Dell contact. [11:55] (well, delegated that to my manager at least) [11:55] rbasak: cool, thanks [12:01] rbasak: yeah, I think I'll have to put in an application for one :) [12:17] Any reason to continue maintaining an upstart job in the Ubuntu delta for squid3? I can drop it now, right? === gammax90 is now known as gammax [12:22] pete-woods: just have someone from your team send me a mail and I'll add you today [12:22] that page is mostly for 3rd party developers who have a package in universe or something and want to triage their own bugs [12:24] jcastro: okay, cool, will send you a mail now :) [12:29] doko, ping :) [12:29] 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) === MacSlow|lunch is now known as MacSlow === _salem is now known as salem_ [13:06] Any reason to continue maintaining an upstart job in the Ubuntu delta for squid3? I can drop it now, right? [13:07] rbasak, slangasek or pitti might help you there, unsure if we still want to support booting with upstart [13:08] Q: Would adding an upstart job to an existing package in trusty acceptable for an SRU ? [13:42] rbasak: I'm facing the same upstart question in Wily wrt my Trusty SRU question [13:42] 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:43] In short, do we consider Wily + upstart a supported option ? [14:02] rbasak: I think we should still keep upstart working until at least 16.04 LTS [14:02] 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] rbasak: but if it does ubuntu specific things, we should keep it (or adjust the init.d script instead) [14:04] 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] rbasak: ack [14:28] 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:42] infinity: hi - any newer thoughts on bug 1454862 ? [14:42] bug 1454862 in lxcfs (Ubuntu) "[SRU][MRE] merge 0.9 (which is currently in wily) to vivid" [Undecided,Confirmed] https://launchpad.net/bugs/1454862 === Malsasa is now known as Guest29295 === Malsasa_ is now known as Malsasa [14:55] hallyn: I'm not big on thinking in the morning, but I'll get back to you. === PaulW2U_ is now known as PaulW2U [15:15] thx [15:48] 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:51] infinity: ddebs.u.c has had its direct buildd retrieval switched off for at least a couple of weeks now [15:54] infinity: yes, I disabled all the apache polling [15:55] I should actually commit that, thanks for the reminder [15:55] 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] Just in time to replace them with Moonshot [15:55] cjwatson: Yeah, I noted the same irony. [15:56] 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] Yeah [15:57] They've treated us remarkably well. I kinda want one in my house. [15:57] 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] Let's hope the distro kernel isn't worse. Is this for page size changes? [15:58] arges: what was wrong with the utopic/vivid postgresql-9.4? [15:58] arges: I'll sync wily from unstable once it hits, but that won't happen until Friday or so [15:58] 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] cjwatson: But it might also fix some longstanding bugs, like hangs in the gdb testsuite, etc. [15:58] Fair enough [15:59] 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. [16:01] Try one or two at a time, I guess [16:01] 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:19] arges: https://launchpad.net/ubuntu/+source/postgresql-9.3/9.3.8-0ubuntu0.4.04 -> erk, version typo [16:19] arges: should have been 14.04; but it doesn't matter actually, there's no other release with 9.3, so *shrug* [16:21] pitti: 4.04, though? Well done on inventing a release before warty. [16:21] infinity: right, it's the 404 release -- not found :) [16:21] :) [16:22] pitti: And now I realize that Mark missed a great opportunity to use HTTP responses as version numbers instead of using dates. [16:22] Those release would have been self-naming too. [16:24] Might have even been vaguely appropriate for the first release (100) to be "continue". [16:30] pitti: yikes sorry about that [16:45] arges: no worries [16:45] arges: oh, you were able to re-accept the old utopic package? I thought that wouldn't work [16:46] arges: anyway, if it works, we can reject the 14.04.1 package from the queue, and otherwise use that [16:46] arges: thanks! [16:47] arges: nevermind, I mis-looked [17:02] ah pitti's gone === _salem is now known as salem_ === JanC_ is now known as JanC [18:45] 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... === rZz is now known as RzR === salem_ is now known as _salem === Elimin8r is now known as Elimin8er