[02:18] <mwhudson> is there a package in the archive that uses symbol versions that is less complicated than glibc?
[02:20] <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:21] <mwhudson> is the format documented somewhere?
[02:22] <mwhudson> man ld says "see VERSION for more" or something
[02:22] <mwhudson> but i don't see where it means
[02:26] <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:27] <sarnold> I thought forsure I'd seen something "more official", but can't find what I was thinking of.
[02:28] <infinity> mwhudson: I would have recommended zlib, but apparmor seems like a decent example too.
[02:30] <infinity> mwhudson: Also, for docs: apt-get install binutils-doc && info ld
[02:31] <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:32] <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:33] <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:34] <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:35] <sarnold> I ran that on dos back in the day :)
[02:36] <infinity> sarnold: Telemate's built-in editor was all the editor I ever needed on DOS.
[02:37] <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:38] <jrwren> i heard pinfo is a nicer info reader
[02:39] <infinity> Huh.  This youtube video is basically my early teens: https://www.youtube.com/watch?v=nOx9fLBJO1w
[02:40] <infinity> Except that I wasn't a scrub with [UNREGISTERED] flashing in the corner.
[02:42] <mwhudson> oh, so the man page thing is a poor translation from texinfo or whatever
[02:44] <sarnold> I thought there was a nice gui info viewer, like xman, but I can't find the thing now
[02:45] <jrwren> xinfo?
[02:46] <infinity> There's tkinfo, but I wouldn't call it "nice".
[02:47] <infinity> pinfo is definitely nicer than the GNU client, though.
[02:48] <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:50] <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:54] <sarnold> and if we're really lucky, we'd burn the info backend once the conversion was done once :)
[02:55] <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:59] <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.
[03:00] <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:01] <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.
[04:35] <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:36] <pitti> Good morning
[05:16] <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
[06:40] <dholbach> good morning
[06:49] <mitya57> infinity, I think yelp already has an info browser
[07:32] <Noskcaj> sil2100, Are we ok to sync libgit2-glib and gitg? The only delta is -glib's breaks on gitg < 3.15
[07:38] <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:42] <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:44] <Odd_Bloke> I don't think I've ever used info; perhaps this explains some of my past confusion. :p
[08:28] <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] <pitti> arges, bdmurray: erk, I meant bug 1461425 (just a formality, postgresql has an MRE)
[08:28] <seb128> pitti, wrong bug number? ;-)
[08:28] <seb128> hehe
[08:28] <pitti> seb128: -ETOOMANYTABS
[08:29] <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> :-)
[09:58] <Silentlord> hi, i want an email to contact someone regards application reviewing
[10:12] <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:14] <pete-woods> (you'd think I'd already be a member, given I'm employed by Canonical) :p
[10:17] <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:19] <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:23] <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:25] <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:26] <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:29] <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:40] <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?
[11:12] <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:45] <pitti> rbasak: thanks for pinging the biosdevname bug!
[11:54] <rbasak> pitti: no problem. Sorry I hadn't followed up on this before.
[11:55] <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
[12:01] <pete-woods> rbasak: yeah, I think I'll have to put in an application for one :)
[12:17] <rbasak> Any reason to continue maintaining an upstart job in the Ubuntu delta for squid3? I can drop it now, right?
[12:22] <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:24] <pete-woods> jcastro: okay, cool, will send you a mail now :)
[12:29] <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)
[13:06] <rbasak> Any reason to continue maintaining an upstart job in the Ubuntu delta for squid3? I can drop it now, right?
[13:07] <seb128> rbasak, slangasek or pitti might help you there, unsure if we still want to support booting with upstart
[13:08] <caribou> Q: Would adding an upstart job to an existing package in trusty acceptable for an SRU ?
[13:42] <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:43] <caribou> In short, do we consider Wily + upstart a supported option ?
[14:02] <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:04] <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:28] <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:42] <hallyn> infinity: hi - any newer thoughts on bug 1454862 ?
[14:55] <infinity> hallyn: I'm not big on thinking in the morning, but I'll get back to you.
[15:15] <hallyn> thx
[15:48] <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:51] <cjwatson> infinity: ddebs.u.c has had its direct buildd retrieval switched off for at least a couple of weeks now
[15:54] <pitti> infinity: yes, I disabled all the apache polling
[15:55] <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:56] <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:57] <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:58] <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:59] <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.
[16:01] <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:19] <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:21] <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:22] <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:24] <infinity> Might have even been vaguely appropriate for the first release (100) to be "continue".
[16:30] <arges> pitti: yikes sorry about that
[16:45] <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:46] <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:47] <pitti> arges: nevermind, I mis-looked
[17:02] <arges> ah pitti's gone
[18:45] <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...