[00:16] <maco> so... anyone in here heading to debconf this summer?
[00:21] <ajmitch> wish I could, but it's a little far, and a little too expensive
[00:22] <soren> Where is it?
[00:23] <ajmitch> NYC
[00:24] <soren> Ah.
[00:24] <soren> ajmitch: Everything is a little far from you, isn't it? :)
[00:24] <soren> Can you get to anywhere useful in less than 10 hours?
[00:24] <soren> :p
[00:26] <ajmitch> well, australia isn't that useful :)
[00:26] <imbrandon> maco: i plan to as of now, but things may change
[00:28] <maco> mmk i think im going to try to take a chinatown bus up to nyc
[00:42] <akgraner> kirkland, ping
[00:43] <akgraner> is there a wiki for byobu - I can't seem to find it - or is your blog post about byobu 2.0 what I should link to?
[01:00] <psusi> jdong, you ready to play with defrag? ;)
[01:00] <psusi> jdong, I got it revved up much faster now, and I *think* I have the extent tree code right
[01:06] <bluefoxicy> so
[01:06] <bluefoxicy> an acquaintance of mine is bitching that the way Ubuntu handles language packages is stupid
[01:06] <bluefoxicy> (while offering up that the way DEbian does it isn't much better; and that all other current solutions are hilariously bad)
[01:06] <bluefoxicy> ... I told him I just bought the Pimsleur German course, and a fantasy fiction book I already have but in German
[01:07] <bluefoxicy> and proceeded to go on about how I'm having more difficulty installing language packs than him; and that the repos are slow and the installer seems to be even more slow
[01:16] <crimsun> mdz: it's unlikely I'll be able to debug prior to UDS-M
[01:30] <anon^_^> Is this where you can reach members of the "Ubuntu Development Team?"
[01:30] <crimsun> anon^_^: yes, and ubuntu-devel@
[01:31] <anon^_^> I'm trying to get one package in the Ubuntu Repository rolled back to an earlier version for lucid
[01:32] <anon^_^> and one package for another project backported
[01:32] <anon^_^> they're maintained by the Ubuntu Development Team
[01:32] <anon^_^> Bugs have been filed on launchpad, but it doesn't seem like UDT actually reads the bug reports
[01:33] <crimsun> anon^_^: which reports? And yes, nearly all members read bug reports consistently.
[01:33] <anon^_^> https://bugs.launchpad.net/ubuntu/+source/kftpgrabber/+bug/559245
[01:33] <anon^_^> Kftpgrabber
[01:33] <crimsun> anon^_^: however, some people have scarce resources (probably like you), so a bit of patience is well appreciated.
[01:33] <anon^_^> this project is pretty much dead, it's a nice ftp app, but development on it ceased nearly 2 years ago
[01:33] <anon^_^> last stable release was 2 years ago
[01:34] <mathiaz> kees: hi!
[01:34] <anon^_^> the devs from that project started work on a KDE4 port, but it was at an alpha stage of development missing features
[01:34] <mathiaz> kees: I'd like to develop a script that gives the list of promotion to main needed to pull a package in main
[01:34] <anon^_^> that's what the SVN is largely based on
[01:35] <mathiaz> kees: ie: promoto-to-main condor -> returns the list of other source packages that would be required to promote to main as well
[01:35] <anon^_^> I wrote some instructions up how to compile from SVN around six months ago, in the answer section on launchpad
[01:35] <mathiaz> kees: do you have an idea of how to do that?
[01:35] <anon^_^> it seems someone from UDT read the direction on how to compile, but didn't read that the SVN build is not really usable
[01:35] <anon^_^> the SVN build is what is currently available in the lucid and meerkat repository
[01:36] <crimsun> anon^_^: I think you may have a bit more cogent response in #kubuntu-devel to be honest
[01:36] <anon^_^> ok
[01:36] <anon^_^> some basically they need to rollback to the last stable release for that
[01:37] <anon^_^> another issue is with gparted
[01:37] <ajmitch> from the look of things, the SVN snapshot is from debian
[01:37] <anon^_^> seperate app, but fairly important
[01:37] <anon^_^> https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/574106
[01:38] <anon^_^> gparted 0.5.2-9 was released May 3rd, 2010
[01:38] <anon^_^> not really complaining about someone not noticing this bugreport yet
[01:39] <anon^_^> but earlier gparted versions had a regression where you could not edit/delete or resize any partition where an active LVM was present on the device
[01:40] <anon^_^> so if you installed your os on an LVM, you're hosed
[01:40] <anon^_^> The version of gparted in the lucid and meerkat repos has this regression
[01:49] <kirkland> akgraner: pong
[01:52] <Damascene> nxvl, hi
[01:52] <Damascene> I want to talk about bug #572776
[01:54] <persia> Damascene: Does aptoncd not work for that?
[01:54] <Damascene> hi persia,
[01:54] <Damascene> he just added some comments on that bug I want to discuss with him
[01:55] <Damascene> no
[01:55] <Damascene> we have a long discussion about it yesterday
[01:56] <nxvl> here
[01:57] <Damascene> ok
[01:57] <nxvl> the comment was basically the summary of what we talked last night (or around 20 hours ago whatever that was in your tz)
[01:57] <nxvl> persia: not it doesn't
[01:58] <Damascene> it's actually enough to provide txt file with the links for 4
[01:59] <Damascene> no need to write special script that will work on windows too
[01:59] <nxvl> from no need to will be cool is a difference :D
[02:00] <nxvl> also will be kind of hard to generate a list of downloadable packages, since you have lots of mirrors
[02:01] <nxvl> also maco's idea was good, generate a state of the system file, then get with that to an online machine and get the updates, so you only have one trip to the internet
[02:03] <Damascene> I know it's good.
[02:03] <Damascene> I just thought the last comment made it look harder to implement
[02:04] <nxvl> nope it doesn't
[02:04] <Damascene> sudo apt-get update --print-uris
[02:04] <Damascene> gives you the update links
[02:05] <Damascene> if you download them and put them in the place you might be able to start with something
[02:05] <Damascene> but the naming is different than the thing in /etc/apt/sources.list.d/
[02:05] <kees> mathiaz: sure.  you'd just recursively examine all Depends: lines
[02:06] <mathiaz> kees: and recommends as well
[02:06] <kees> mathiaz: right, yeah.  which element were you curious about?
[02:07] <mathiaz> kees: well - basically I want to find out how much would be required to promote condor to main
[02:07] <mathiaz> kees: in the past we've been burned a couple of times with dependencies not being MIRed when the promotion was done
[02:08] <mathiaz> kees: so I'd like to have a reliable way to figure out *every* source package that will be promoted to main to get one source package as well
[02:08] <Damascene> nxvl, does the apt-get update store things in /etc/apt/sources.list.d/ or were
[02:08] <mathiaz> kees: so I'd like to have a reliable way to figure out *every* source package that would need to be promoted to main given one source package
[02:08] <kees> mathiaz: there isn't a perfect way to do with due to alternates.  i.e  Depends: pkg1 | pkg2
[02:09] <kees> mathiaz: but if you just throw away alternates, you can probably get pretty close.
[02:09] <mathiaz> kees: right - do you know of a script that does such a thing?
[02:09] <kees> mathiaz: nope
[02:09] <mathiaz> kees: if not, would you recommend starting in python or bash?
[02:09] <kees> python.
[02:09] <mathiaz> kees: it seems that python-apt doesn't have every info required
[02:10] <kees> mathiaz: what's missing?
[02:10] <persia> Can't apt-rdepends do both forward- and reverse- analysis to address this issue?
[02:10] <mathiaz> kees: let me try again in ipython
[02:10] <kees> persia: yeah, but it's dumb about conflicts, recommends, etc
[02:10] <kees> mathiaz: I've found doing it by hand to be much simpler.
[02:11] <kees> mathiaz: if you get to like 4 things not already in main, it's a good case to discourge putting it in main.  ;)
[02:11] <mathiaz> kees: :)
[02:11] <mathiaz> kees: well - that doesn't help in giving an estimate on what needs to be done ;)
[02:11] <kees> mathiaz: for each of the pkg1 | pkg2 bits, you probably want to check each one for them being in main first, and then if non found, recurse through pkg1.
[02:11] <persia> apt-get --dry-run --print-uris install ${PACKAGE} | grep universe might be a quick way to get a list (dunno how robust it would be)
[02:12] <kees> mathiaz: right.  :)
[02:12] <mathiaz> persia: hm - that's a quick hack :)
[02:12] <mathiaz> persia: how about build-dependencies?
[02:12] <mathiaz> persia: s/install/build-dep/ ?
[02:12] <kees> persia: oh, yeah, good one
[02:12] <nxvl> Damascene: /var/lib/apt/lists/
[02:12] <persia> mathiaz: Sure.
[02:13]  * mathiaz tries
[02:13] <kees> best to start from a clean main-only chroot though
[02:13] <mathiaz> kees: yes
[02:13] <Damascene> nxvl, thanks, I'll update the report
[02:13] <Damascene> brb
[02:15] <mathiaz> persia: hm - universe/main is not available in the output
[02:16] <mathiaz> persia: http://paste.ubuntu.com/427334/
[02:16] <nxvl> mathiaz: i remember i did that in barcelona for the remove sudo from the system
[02:16] <nxvl> or something like that
[02:16] <nxvl> kees: did you remember?
[02:17] <persia> mathiaz: Seems --dry-run and --print-uris don't play nice together.
[02:17] <nxvl> oh! no, i generated a list of packages that depended on sudo
[02:17] <nxvl> nevermind
[02:18] <mathiaz> persia: right - I've removed --dry-run - works good
[02:18] <mathiaz> persia: now I just need to iterate on the list
[02:18] <persia> mathiaz: I had to use -y for my test.  Remember *not* to use sudo :)
[02:19] <mathiaz> persia: :) - I'm testing in schroot using lvm snapshots
[02:19] <persia> mathiaz: So old school.  aufs-schroots are the new rage :)
[02:19] <mathiaz> persia: and --print-uris seems to induce dry-run
[02:19] <mathiaz> kees: ^^ have you heard that - lvm is sooo 2009
[02:20] <persia> It doesn't.  --print-uris expects you to go download stuff separately.  I suspect --dry-run skips the actual deb fetch, and --print-uris is hooked into that to print the URI rather than fetching it.
[02:20] <kees> persia: can do --download-only
[02:20] <kees> mathiaz: yup, aufs is the new hotness
[02:20] <persia> kees: For which?
[02:20] <kees> persia: for the --print-uris instead of --dry-run
[02:21] <persia> Oh, nifty.
[02:21] <mathiaz> And I can get the source package from the pool url
[02:22] <persia> Yep.  URIs are fairly easy to parse :)
[02:27] <anon^_^> any comment from Ubuntu Development Team on gparted?
[02:27] <anon^_^> https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/574106
[02:33] <persia> anon^_^: We don't typically use backports for bugfixes (and that bug isn't against a backport project).  Do you maybe want an SRU for that?
[02:34] <anon^_^> yeah that would be nice
[02:42] <Damascene> persia, may I pm?
[03:34] <micahg> Amaranth: ping
[03:34] <Amaranth> wow good timing
[03:34] <Amaranth> just got home
[03:35] <micahg> Amaranth: hi, I've got quite a few bug reports re compiz/Thunderbird
[03:35] <micahg> one example is bug 564011
[03:35] <Amaranth> well compiz hasn't changed so... :)
[03:35] <micahg> Amaranth: indeed, I just noticed that
[03:36] <micahg> Amaranth: k, I guess I'll go search/complain to upstream
[03:36] <Amaranth> sounds like they probably tried and failed to implement the _NET_WM_SYNC protocol
[03:37] <micahg> Amaranth: ok, I can research that, thanks
[03:37] <Amaranth> micahg: Plus the second person in that bug report is probably using kwin effects
[03:38] <micahg> Amaranth: I have another 5 people with compiz, but does kwin also try to implement those protocols?
[03:38] <Amaranth> micahg: I know they were bragging about finally doing smooth resize of GTK+ apps which would require that
[03:39] <micahg> Amaranth: ok, I think I have enough to search with now, thanks so much for your help
[03:39] <Damascene> persia, nxvl , I've created this page
[03:39] <Damascene> https://wiki.ubuntu.com/damascene/offline%20update
[03:40] <Damascene> please look at it
[03:41] <Damascene> bug 572776 if any one else interested
[03:41] <persia> Damascene: I'm still not sure how aptoncd isn't designed specifically to meet the issue you've described.
[03:41] <Damascene> did you read the last line in Alternative section? persia
[03:42] <Damascene> it will need you to depend on some person Machine
[03:42] <persia> Damascene: It depends on *another* machine.
[03:43] <Damascene> :)
[03:43] <persia> But any solution depends on another machine.
[03:43] <Damascene> *some person machine*
[03:43] <ScottK> persia: That or a point release ISO, right?
[03:44] <Damascene> persia, it should be ubuntu and not cleaned
[03:44] <persia> ScottK: But point-release-ISO is already a supported use-case, isn't it?
[03:44] <Damascene> persia, so you should agree with the man to not clean his system packages
[03:45] <ScottK> persia: It is.
[03:47] <Damascene> persia, have you tested Japanese language with mlterm?
[03:47] <persia> No.
[03:48] <Damascene> could you do it please?
[03:50] <Damascene> it should work fine. is there any translation for CLI programs in Japanese?
[03:52] <persia> There is.  It appears to be fine, although the widgets aren't the same as those in other programs, and it doesn't respect my "system wide" font settings.
[03:52] <persia> So, likely needs a bit of work to be a default (plus, it's feature poor compared to terminator)
[03:54] <Damascene> so the problem with vte is only for RTL
[03:54] <persia> Right.
[04:01] <YokoZar> Is there a way to specify a different make target with CDBS?  After configure I want to do make foo, not just make
[04:07] <ccheney> YokoZar: not sure how to do it but afaik you can override anything in CDBS
[04:07] <ccheney> YokoZar: i haven't used CDBS in so long I have forgotten how to do it
[04:07] <ajmitch> probably one of the rules in /usr/share/cdbs/1/class/makefile.mk
[04:07] <YokoZar> ccheney: I checked the documentation and they have special override flags for configure and clean and install but not make :(
[04:08] <YokoZar> http://cdbs-doc.duckcorp.org/en/cdbs-doc.xhtml#id490459
[04:08] <ajmitch> YokoZar: tried DEB_BUILD_MAKE_TARGET ?
[04:08] <ajmitch> sorry, it's meant to be DEB_MAKE_BUILD_TARGET
[04:08] <YokoZar> ajmitch: no I hadn't tried that, didn't see that in the docs
[04:08] <StevenK> Like CDBS has docs.
[04:08] <ajmitch> YokoZar: the source is the best documentation for cdbs
[04:09] <ccheney> yep rtsl :)
[04:10] <YokoZar> Fair enough, I'll give it a go
[04:10] <persia> Note that reading CDBS source may well make one think it's safe to use the undocumented internal interfaces: do *try* to use the documentation first, so that you don't have to redo it when CDBS changes (which does happen)
[04:11] <ajmitch> persia: the problem is knowing what's safe & what's not
[04:12] <persia> ajmitch: I believe only that in the documentation is safe, although the rest may be more or less stable.
[04:12] <ccheney> reading cdbs may also cause you to decide to use debhelper directly instead, this is a good thing ;-)
[04:13] <persia> Well, with newer debhelper, sure.  With older debhelper, I'm not sure I'd have agreed with that.
[04:13] <YokoZar> ccheney: Yes, debhelper is my favorite here, but editing a cdbs package generally means using cdbs still ;)
[04:14] <ccheney> cdbs in general used to at least be very broken
[04:14] <ccheney> i seem to recall it having issues with rebuilding at times when it shouldn't have
[04:14] <ccheney> YokoZar: yea :)
[04:14] <ccheney> my experience with cdbs internals ended in late 2004 so is quite a bit out of date
[04:15] <xnox> cdbs iterates over all packages wasting time. And it has *way* to many targets for a regular package & package-common
[04:15] <xnox> somethings are nice, most things are just too: "we are make wizards we can make do anything"
[04:16] <ccheney> xnox: for very simple packages the wasted time is probably fairly trivial, but probably not for something large like OOo
[04:16] <xnox> %:
[04:16] <xnox>       dh $@
[04:16] <xnox> done
[04:16] <ccheney> i think i saw some of the issues when using cdbs for kde
[04:17] <xnox> ccheney, they did create dh_* addons for their needs
[04:17]  * ccheney is referring to the cdbs/kde from pre 2005
[04:17]  * xnox was a happy windows XP user in 2005
[05:46] <slytherin> Auto login does not unlock the default keyring. Is it intentional?
[05:53] <ScottK> I think so.
[05:53] <RAOF> slytherin: It *can't* unlock the default keyring, unless that keyring has no password.
[05:54] <slytherin> RAOF: This is a problem then because default keyring stores even wireless keys. So user can not connect automatically to wireless connection if he chooses auto login.
[05:54] <slytherin> In that sense using auto login is a loss of functionality.
[05:55] <RAOF> Well, they can; they just need to set “usable for all users” in the connection information (which will also give them the benefit of having the network available in recovery mode)
[05:56] <RAOF> They could also just set an empty password for the default kerying, in which case it's available.
[05:56] <persia> If the wieless password is secret enough to not be available to any user, it shouldn't be autoconnected on autologin anyway.
[05:57] <persia> Anyway, the wireless keys *should* be stored by network-manager, not by the keyring (although the keyring may contain the secrets necessary to get the keys from network-manager).
[05:58] <persia> imbrandon: Didn't you dig into this recently?
[05:58] <RAOF> persia: It's not even that - even with a globally available *connection* the user will need to authenticate (via polkit) to view the actual password I think.  That's certainly nm-applet's behaviour.
[05:58] <persia> That's how it's supposed to work, yeah.
[05:59] <slytherin> The reason I am asking this is because I have seen some bug reports where users are not aware that this is the root cause.
[05:59] <persia> NM has it's own secret stores, specifically to enable use in XDG environments, so you have the same set of connections if you switch from KDE to GNOME, etc.
[06:00] <slytherin> For example, someone setup a headless server with VNC enabled (with password) and autologin. But since the default keyring does not get unlocked the user can not actually connect via VNC.
[06:11]  * ccheney found a bunch of old deb source on his system
[06:11] <ccheney> nvidia driver 1.0.1251 heh
[06:14] <ccheney> hmm all the way back to nvidia 0.9.6 actually
[06:16] <temugen> Keybuk: OK, I think I've made my final commit to http://bradmisik.com/trunk/fragraph/ unless you have any other features you want. Time to move on to other projects :)
[06:25] <imbrandon> persia: sorry i was afk
[06:25] <imbrandon> persia: dig into what? /me reads backlog
[06:25] <persia> imbrandon: No worries.  We were just discussing NM+keyrings+autologin being confusing to users.
[06:25] <imbrandon> ahh
[06:26] <slytherin> rather anything that uses keyring + autologin
[06:26] <imbrandon> you mean by loggin in they asking for a password right away ;)
[06:28] <slytherin> No. Autologin does not unlock the default keyring. So when some app uses keyring user is prompted for keyring password.
[06:48] <persia> slytherin: But this is a good thing, isn't it?  If someone *really* doesn't want to protect any secrets, they should have no password for the default keyring.
[06:50] <slytherin> right. But this is not obvious for users. Users wonder 'why am I being prompted for password'.
[06:57] <persia> Right.  It needs thinking about.
[07:24] <dholbach> good morning
[09:38] <cjwatson> smoser: originally bug 569394, although it was a bit of a wild goose chase and I ended up closer to bug 567592
[10:42]  * pitti prepares and uploads a fixed gcc-4.5
[10:42] <pitti> (talked to doko on the phone)
[10:44] <pitti> s/uploads/wait until LP is back../
[10:47] <ajmitch> morning pitti  :)
[10:49] <pitti> g'day ajmitch! how are you?
[11:07] <ajmitch> pitti: good thanks, how are you today?
[11:08] <pitti> I'm great, thanks!
[11:08] <pitti> looking forward to maverick
[11:08] <ajmitch> so am I, hopefully it'll be an interesting cycle
[11:13] <persia> It's Patch Day!  If anyone has time, please stop by #ubuntu-reviews and help us get patches applied.
[11:22] <dholbach> persia: Patch Day! 5th May
[11:22] <dholbach> persia: but you're right - it needs more publicity
[11:22] <persia> dholbach: No, it just started.
[11:23] <persia> Remember, it's considerably earlier in some parts of the world :)
[11:23] <persia> (still 4 May here too)
[11:23] <dholbach> gotcha
[11:23]  * dholbach will blog
[11:23] <persia> Thanks!  We'll be carrying on for the full international day, as I understand the schedule.
[11:31] <james_w> http://cgit.freedesktop.org/dbus/dbus/tree/dbus/dbus-spawn.c <- is there any way that have_exec_errnum can be false in that file?
[11:36] <geser> does somebody know when rmadison will list maverick or who to bug about it?
[11:37] <cjwatson> geser: oh, that would be me, one moment
[11:37] <cjwatson> geser: done
[11:37] <geser> thanks
[11:38] <pitti> cjwatson: and while you are at it, perhaps drop intrepid?
[11:38] <pitti> cjwatson: (btw, I fixed madison-lite on cocoplum)
[11:38] <pitti> cjwatson: thanks!
[11:38] <cjwatson> done
[11:38] <cjwatson> thanks for doing cocoplum
[11:38] <pitti> np
[11:39] <james_w> I think that's why we are seeing dbus "error: failed to launch program: Success" fairly frequently.
[11:44] <pitti> ooh, seems LP is back
[11:44]  * pitti uploads gcc-4.5
[11:46] <pitti> ... and accepts it
[12:07] <ogra> mumble ... so why does fuseiso only support isofs
[12:09] <persia> "iso" ? :)
[12:09] <persia> What filesystem do you want?
[12:14] <ogra> persia, any my kernel supports :)
[12:15] <persia> Well, there's lots of fuse modules :)
[12:15] <ogra> persia, fuseiso suppports loop mounting of .img/.iso files but restricts itself to isofs
[12:16] <ogra> would be nicer to have a plain fuse-loop bit that just uses the available filesystems
[12:16] <persia> Ought be easy to toss together, really.
[12:16] <ogra> the only code i found so far uses UML ...
[12:16] <Riddell> mthaddon: topic fail, cropped at end
[12:26] <tkamppeter> pitti, hi
[12:43] <bdrung> is maverick open for uploads or do we have to wait for the toolchain?
[12:43] <james_w> bdrung: topic?
[12:44] <soren> mvo: do-release-upgade on Hardy does not offer to upgrade to Lucid unless I pass -d. I'm not sure where to report that?
[12:44] <bdrung> james_w: what does "toolchain freeze" mean?
[12:45] <soren> (since I suspect it's not an update-manager problem per se, but rather something that needs changing server-side)
[12:45] <james_w> bdrung: the archive is frozen while the toolchain is prepared, but any uploads will land in UNAPPROVED
[12:46] <bdrung> thanks
[12:46] <mvo> soren: its a known think, either --proposed or -d is needed currently
[12:46] <mvo> soren: its like this because we have not enabled hardy -> lucid universally yet
[12:47] <soren> Ah, ok. So it's semi-intentional?
[12:47] <mvo> soren: yeah, also we need to better communicate this
[12:47] <ogra> its documented on the help pages
[12:47] <ogra> https://help.ubuntu.com/community/LucidUpgrades
[13:09] <pitti> hey tkamppeter
[13:16] <tkamppeter> pitti, there is still the problem of CUPS not starting on boot for some users.
[13:19] <tkamppeter> pitti: bug 554172, bug 565197, bug 574109, http://www.cups.org/str.php?L3575
[13:23] <pitti> tkamppeter: no idea about that one, I'm afraid; the rc.d symlink seems fine and the init script present
[13:26] <pitti> smb, apw: FYI, I can't release linux (or anything else) to -updates right now, due to bug 574552
[13:27] <apw> pitti, sounds bad ... thanks for the heads up
[13:27] <pitti> apw: it is :/
[13:27] <smb> pitti, Doh, ok thanks for giving a heads up
[13:31] <apw> pitti, the bug doesn't really make it clear its affecting all proposed updates too ... i assume this appeared at lunch today
[13:32] <pitti> apw: I wrote some comments into it
[13:32] <pitti> apw: right, new LP rollout
[13:33] <apw> pitti, oddly that bug was files 20 hours ago, so before the rollout, you being affected being new ... seems the bug just widened its reach
[13:33] <pitti> apw: I still moved a package to -updates this morning
[13:33] <apw> yeah so it got a heck of a lot worse
[13:33] <apw> or its a different bug with the same symptoms i guess
[13:50] <tkamppeter> anyone around who knows about problems of daemons/services not starting in Lucid and to which package to assign the bug reports?
[13:51] <patrickd> Can anyone tell me where the lib of libboost fame is actually installed, I've queried the archive with both dpkg -L and apt-filelist but it seems like only the documentation is being installed. Even though I have installed the "dev" version. e.g. apt-get install libboost-dev libboost-python-dev
[13:52] <patrickd> dpkg -L libboost-dev only shows entries for /usr /usr/share /usr/share/doc/libboost-dev
[13:53] <geser> patrickd: when you read the package description, you will notice that it's only a meta-package to pull in the default version
[13:53] <geser> which is currently libboost1.40-dev
[13:55] <patrickd> geser, but unless I'm missing something in that package also there are only headers and doc's in it to. With no lib to link against or am I missing something?
[13:56] <kklimonda> patrickd: libboost1.40-dev depends on other dev packages ;)
[13:56] <geser> patrickd: the libboost-*-dev packages are split for each "sub"-library
[13:58] <geser> as you mentioned early libboost-python-dev: libboost-python1.40-dev contains the .so symlink (similar for the other libboost-*1.40-dev packages)
[13:58] <patrickd> ah, okay. I've found the files there in /usr/lib
[13:59] <patrickd> but I don't understand why when running for example dpkg -L libboost-python-dev it doesn't appear to touch the /usr/lib/ folder
[14:00] <kklimonda> patrickd: because libboost-python-dev is also a metapackage which depends on the current default boost version
[14:00] <geser> libboost-python-dev is once again a metapackage to pull in the default libboost version, here libboost-python1.40-dev which contains the symlink
[14:01] <patrickd> ah, okay. I think I understand what's going on now.
[14:01] <patrickd> thanks for the explanation folks.
[14:05] <tkamppeter> Anyone can help me with an Upstart problem? bug 554172, bug 565197, bug 574109 CUPS not starting on boot.
[14:08] <xaver> hi Keybuk
[14:16] <tkamppeter> Keybuk, slangasek, hi
[14:37] <dpm> mvo, when you've got some time, could you have a look at bug 573502? We might have to disable translations if it's not possible to show multibyte chars there
[14:38] <mvo> dpm: hmhm, it should be possible, let me try to verify
[14:38] <dpm> thanks!
[14:40] <aburch> (win 21
[14:40] <aburch> Mah.
[14:43] <pitti> apw, smb: bigjools is our hero, works again and kernel copied to -updates
[14:43] <StevenK> No, *I'm* the hero, damn it :-P
[14:43] <pitti> ooh
[14:43]  * pitti hugs StevenK, thanks!
[14:43] <pitti> so bigjools was the messenger :)
[14:43] <StevenK> Effectively :-)
[14:44] <smb> StevenK, Thanks then
[14:44] <seb128> StevenK, you are also the one who broke it in the first place right? ;-)
[14:44] <pitti> StevenK: you really earned your new soyuz badge!
[14:44] <StevenK> pitti, smb: Sorry for the issue
[14:44]  * seb128 runs
[14:44] <ogra> lol
[14:44] <StevenK> seb128: Yes. And I cry a little more everytime it gets mentioned.
[14:45]  * seb128 hugs StevenK
[14:45] <seb128> let's not mention it there ;-)
[14:49] <apw> StevenK, thanks!
[14:53] <pitti> cjwatson, sabdfl, kees, mdz, Keybuk: TB meeting reminder in 7 mins
[14:54] <sabdfl> thanks pitti
[15:06] <pitti> cjwatson: do you think it's ok for me to accept debhelper and cdbs? (maverick)
[15:09] <cjwatson> pitti: don't see why not
[15:10] <pitti> cjwatson: gcc-4.5 seems to build better now, *crossing fingers*
[15:13]  * abogani waves
[15:13] <abogani> Are there any chance to change behavior of /etc/init.d/ondemand (into initscripts package) to let users to choose cpufreq governor (for example through a file in /etc/default/) ?
[15:13] <ogra> abogani, file a whishlist bug (preferably with a patch ) :)
[15:15] <abogani> ogra: Ok. I'll surely do it. Thanks!
[15:16] <ogra> abogani, note though that the file should notify about the huge waste of energy and harming the environment etc in case you switch to performance ;)
[15:30] <mvo> dpm: I can reproduce the problem, it appears that we just have no font for this at the terminal
[15:43] <zyga> mvo: hi :)
[15:44] <mvo> hey zyga
[15:51] <dpm> mvo, ah, thanks for looking into it. Bummer, is there a way to fix this? I.e. installing the necessary fonts?
[15:53] <dpm> mvo, or can you think of a way we could disable the CJK translations alternatively?
[15:54] <mvo> dpm: I don't know, I don't know much about the fonts situation on the console, i.e. if there is a good font with full CJK coverage, ev or cjwatson know for sure, or the CJK users.
[15:55] <cjwatson> I know nothing
[15:57] <JFo> that isn't what I heard about you cjwatson ;-0
[15:57] <cjwatson> ok, nothing about this
[15:57] <JFo> heh
[15:57]  * dpm pheews
[15:57] <JFo> dpm, :)
[15:58] <dpm> let's try ArneGoetje or ev, then. Arne, Evan, it's about bug 573502, do you know about the font situation in the console, and if so, do you think you could comment on the bug?
[16:00] <cjwatson> oh, wait, recovery mode.  I thought you meant gnome-terminal or something
[16:00] <cjwatson> dpm: the Linux console can't render CJK
[16:00] <cjwatson> it's not a matter of fonts - it doesn't have the rendering technology
[16:01] <cjwatson> likewise Indic languages
[16:01] <cjwatson> I'm not sure about RTL
[16:02] <mvo> jibel: hello, thanks for the fixes for #566779 and #568925, I prepare a SRU for those now (and the gmarkup one too)
[16:02] <dpm> thanks cjwatson. Bummer, we'll have to somehow disable whatever translated text it cannot render, or disable translations altogether
[16:02] <cjwatson> people who need CJK text on consoles use things like jfbterm
[16:03] <mvo> hey glatzor
[16:03] <mvo> dpm: can we somehow select in rosetta that this package can not be translated into certain languages?
[16:03] <cjwatson> which wouldn't be impossible, we have a framebuffer there already in most situations now, it's just fairly cumbersome
[16:03] <jdstrand> pitti: hi! can I have you opinion on http://people.canonical.com/~jamie/ff36-apparmor.diff.txt? background: there is a pending firefox update and there are these 4 bug fixes to the apparmor profile. the aa profile is disabled by default and no chance of regression (plus, me and several other people use the profile with these commits)
[16:04] <jdstrand> pitti: the question is whether to SRU these separately, with all the associated archive churn, or push them with the pending security update
[16:05] <jdstrand> pitti: I wouldn't normally ask, but in the case of firefox, upstream adds features and bug fixes beyond security fixes, so these low regression potential items seemed kinda gray...
[16:05] <dpm> mvo, no, unfortunately it's not possible to selectively allow translatable languages in rosetta. They should either revert the translations and leave them untranslated, or we blacklist the affected languages in the package, if that is possible. I think that might be the best thing to do in the short term.
[16:06] <mvo> dpm: blacklistting is possible, I just need to add code for this
[16:07] <glatzor> heyas mvo!
[16:07] <dpm> mvo, do you think you could do that if we provide you a list of affected locales in the bug report?
[16:20] <mvo> dpm: yes
[16:36] <cjwatson> pitti: perl uploaded - should I just accept it directly?
[16:36] <pitti> cjwatson: hm, should we wait for gcc, to get perl built with it?
[16:36] <cjwatson> ok by me
[16:56] <pitti> cjwatson: hm, thinking about it, that would also need a gcc-defaults upload, wouldn't it?
[16:57] <cjwatson> I guess
[17:12] <cr3> how come building a package in PPA for maverick works for architecture any but not all?
[17:12] <cjwatson> cr3: PPAs haven't been enabled yet for maverick, so I guess you got lucky
[17:13] <cjwatson> or at least they aren't supposed to have been
[17:13] <thedoor> hi all :)
[17:13] <thedoor> can i ask some newbie questions here?
[17:33] <jibel> mvo, hey, no problem.
[17:33] <jibel> mvo, btw what do you think is the right fix for bug 545336 ?
[17:34] <jibel> mvo, it only affects spanish users because texlive-latex-extra translation is muuuch too large.
[18:07] <dmart> kees: hi, do you have a moment to discuss your comments on https://blueprints.edge.launchpad.net/ubuntu-arm/+spec/arm-m-missing-security-features ?
[18:07] <kees> dmart: hi! sure.
[18:08] <dmart> kees: What did you mean by "nothing should be prelinking. everything is correctly already PIC"?
[18:09] <kees> dmart: I'm a bit new to ARM things, but as I understand it, nothing should be prelinking.
[18:09] <kees> dmart: it serves no purpose that I'm aware of.
[18:09] <dmart> My understanding of the potential benefits of prelinking are that you may reduce a lot of dnyamic linker thrashing during app startup, but I don't know if this has been extensively investigated
[18:09] <kees> dmart: it used to be an issue for symbol resolution, but the hash tables from a few years ago made it irrelevant
[18:09] <kees> dmart: yeah, that's a total non-issue now.
[18:09] <dmart> So prelinking is a possible optimisation, not a legacy compatibility thing
[18:10] <kees> dmart: the GNUHASH extension makes symbol look-up insanely fast.
[18:10] <dmart> I think doko integrated that for ARM now
[18:10] <kees> I view it as legacy, as the hash serves the purpose in the general case now.
[18:11] <kees> readelf -e /bin/true | grep gnu.hash
[18:11] <kees> ^^ that should answer it
[18:11] <kees> (oh right, I have armel simulator...)
[18:11] <dmart> I'd need to check with doko; I think at one point gnu.hash was present but not used for ARM (or maybe the other way around)
[18:11] <kees> so, yes.  armel has the gnu.bash stuff
[18:11] <dmart> ok
[18:12] <dmart> prelinking is still potentially interesting because we may suffer a lot of TLB misses and cache line fills during app startup at symbols get resolved.
[18:12] <kees> regardless, ASLR is missing, even if legacy apps want to prelink.  prelinking makes ASLR useless, but just for the app doing the prelink.
[18:12] <dmart> Sure
[18:13] <kees> dmart: that might be true, but I think (hope) it's an uncommon need.
[18:13] <kees> (doing prelink)
[18:13] <dmart> dunno really, currently the preformance implications are not well understood.  I don't think it's been investigated much yet, but I've heard it mentioned.
[18:14] <dmart> I've found no obvious reason why ASLR shouldn't be possible on ARM generally
[18:14] <dmart> maybe just noone did it yet.
[18:15] <dmart> kees: Next point: the vdso
[18:15] <dmart> Currently, on ARM we enter the kernel via SVC (aka SWI) - which is more analogous to INT and SYSENTER/SYSEXIT
[18:15] <dmart> s/and/than/
[18:16] <dmart> There is no need for a "well-known return address" to get back into userspace
[18:16] <kees> dmart: right, yes, ASLR> totally possible, just no one has done it.
[18:16] <kees> dmart: ah, okay.  I know that x86 starting doing sysenter because int80 was so expesnive.
[18:16] <kees> er, expensive.
[18:16] <kees> dmart: if that's not the case for ARM, then I don't really care.
[18:17] <kees> dmart: but I have to wonder why ARM has a vdso then...
[18:17] <kees> 7fff192e1000-7fff192e2000 r-xp 00000000 00:00 0                          [vdso]
[18:17] <kees> seems like if it has a vdso, it should be ASLRs
[18:17]  * psusi decides to inject some luls for everyone's amusement: "Who is General failure, and why is he trying to read my C: drive?"
[18:17] <kees> psusi: hehe
[18:17] <dmart> If this is ARM, why do the addresses have 48 bits? ;)
[18:18] <dmart> I don't see this with cat /proc/$$/maps or ldd /bin/bash (for example)
[18:20] <kees> dmart: oh, perhaps the qemu environment is crazy
[18:20] <kees> dmart: I don't have a "real" ARM system.  :P
[18:21] <dmart> Maybe you are getting the host's info somehow
[18:21] <kees> I must be
[18:21]  * kees boots an ARM VM instead of chroot thingy
[18:22] <dmart> OK, well I'll tweak the blueprint whiteboard a bit based on this chat
[18:22] <kees> dmart: hah.  well that makes things easier.  ;)
[18:22] <kees> dmart: yeah, please drop the vdso thing.  :)
[18:22] <kees> dmart: do you know why ARM loads ELF so low in memory?  was there a time when it didn't have sane virtual memory?
[18:22] <dmart> vdso might be relevant later, but probably not for now.  The nearest equivalent thing is the vectors page, but it's not straightforward to move that.
[18:23] <dmart> Do you know why x86 loads ELF so _high_ in memory ;)  I've always wondered about this
[18:24] <kees> heh, I don't.  :)
[18:24] <dmart> Anyway, I don't really know why the difference exists.  I think there's just no reason not to... there's nothing else down there that we're trying to avoid
[18:25] <kees> yeah, with the mmap_min_addr stuff, it's one of the deltas between x86 and ARM.
[18:26] <dmart> There's also the issue of where the linker traditionally puts .text: for ARM it's just at the bottom of VM, leaving space for some NULL pages
[18:27] <kees> right, that's what I mean.  x86 linker goes to 0x0804000, ARM linker goes to 0x00008000
[18:27] <dmart> On x86, it's 0x8048000, but I have no idea what the 128MB gap is for.  libc seems to appear down there sometimes
[18:28] <kees> anything you're seeing below that is due to x86-32 nx-emulation patch crack.
[18:28] <dmart> ugh
[18:28] <dmart> ;)
[18:29] <dmart> Fortunately XN should work natively on ARMv7
[18:29] <kees> but yeah, dunno about the 0x08040000 bump.  anyway, was just curious, since it'd be nice to have the memory layouts be similar.  :)
[18:30] <dmart> I don't have an answer on that one.  I wondered whether the kernel used to live down there on very old kernels or something... but really I have no idea.
[18:31] <dmart> Anyways, I'll tweak the blueprint again tomorrow.  Most of it seems totally doable, though I haven't dug too deep
[18:31] <kees> dmart: cool.
[18:31] <dmart> thanks
[18:31] <kees> dmart: thanks!
[18:46]  * cjwatson wonders if this is a viable idea for making merge-o-matic lots faster
[18:55] <imbrandon> ?
[19:07] <maxb> By what logic is ureadahead a mandatory dependency of ubuntu-minimal? This seems... wrong
[19:24] <psusi> it does seem like it should go under the desktop metapackage rather than minimal...
[19:29] <psusi> also seems like the priority should not be required
[20:45] <ccheney> any gstreamer gurus that happen to have time to look at a bug for me? :)
[20:46] <notlistening> Okay I turn my printer on it pops as the make and model in the printing dialouge, what mechanism is use to get that information is it HAL?
[20:46] <ccheney> nm seb128 responded that my issue is upstream
[20:47] <notlistening> and how can i access that information?
[21:16] <psusi> HAL has been removed
[22:58] <lifeless> james_w: around ?
[23:57] <psusi> jdong, pushed my updated e2defrag to lp:e2defrag if you want to check it out
[23:58] <jdong> psusi: cool, I'll try to make time to try that
[23:58] <psusi> jdong, how's your little graph maker doing?
[23:59] <psusi> I'd like to check that out to visualize before and after