[00:30] <GunnarHj> sil2100: Ok, thanks for letting me know.
[00:31] <sil2100> GunnarHj: sorry about this anyway, I noticed it too late and didn't get to running it manually, maybe I should have
[00:31] <sil2100> Anyway, I just thought we'll get a batch this week
[00:32] <GunnarHj> sil2100: I thought there was some kind of manual intervention to build the packages, but you say it will happen automatically?
[00:33] <GunnarHj> sil2100: Or are you talking about the tarballs?
[00:35] <sil2100> GunnarHj: well, the delta langpacks are happening automatically, a day after tarball exports
[00:36] <GunnarHj> sil2100: Ah, didn't know that.
[00:38] <sil2100> GunnarHj: as per the schedule https://dev.launchpad.net/Translations/LanguagePackSchedule
[00:41] <GunnarHj> sil2100: Right, so there are weekly updates all over (when it works), and while the builds for the stable releases goes to the PPA, the builds for the development release make it directly to the archive.
[01:59] <nauticalnexus> lmao
[01:59] <nauticalnexus> tfw openrct2 dev team says you can't build openrct2 for Ubuntu, and package in deb file
[01:59] <nauticalnexus> tfw u literally JUST DID THAT
[08:53] <didrocks> xnox: hey, you mentioned some xubuntu ubiquity plugin and such, I don't find them in the ubiquity source nor find other packages matching those descriptions
[09:19] <doko> rbalint: https://launchpad.net/ubuntu/+source/mtd-utils/1:2.0.1-1ubuntu2 still ftbfs on ppc64el
[10:28] <rbasak> When switching the one thing in main for a particular thing, what's the expected upgrade path for users usually? Leaving upgrading users with a packaging now in universe and release note it? Or something further?
[10:29] <rbasak> When switching the one thing in main for a particular thing, what's the expected upgrade path for users usually? Leave upgrading users with a package now in universe and release note it? Or something further?
[10:36] <xnox> didrocks, sigh, need to search for it again then. maybe it was somebody else, like edubuntu or mythbuntu
[10:36] <xnox> rbasak, we do leave people with packages in universe typically.
[10:37] <xnox> rbasak, sometimes we promote the new thing via upgrade-manager quirks, but we stopped doing that, as it is fragile. seeding new stuff into metapackage works fine, as long as there is a clear successor.
[10:40] <didrocks> xnox: so, I guess there is nothing, I see no plugins at all
[10:43] <cjwatson> I thought it was an ubuntustudio ubiquity plugin
[10:43] <cjwatson> didrocks: https://launchpad.net/ubuntustudio-live ?
[10:44] <cjwatson> https://launchpad.net/ubuntu/+source/ubuntustudio-live too
[10:44] <didrocks> cjwatson: ah, thanks! the naming isn't the best. I'll check if there is the minimal install in it that xnox elluded to
[10:47] <xnox> /o\ studio
[10:47] <xnox> thanks colin!
[10:48] <didrocks> yeah, it's not a minimal install checkbox, it's a view with checkbox to select/deselect installed packages
[10:49] <cjwatson> there may be some other plugin that exists that I forgot about
[10:49] <didrocks> or maybe xnox's memory is failing ;)
[10:49] <cjwatson> grepping Contents also finds dell-recovery and edubuntu-live
[10:50] <xnox> didrocks, they do wipe your memory upon leaving Intel...
[10:50] <didrocks> xnox: ahah :)
[10:50] <xnox> or so I was told.... I can't remember
[10:50] <didrocks> thanks for the hints cjwatson :)
[10:51] <cjwatson> mythbuntu-live-autostart also used to exist
[10:52] <didrocks> the edubuntu one is unsurprinsgly very close to ubuntustudio (full list of packages to select/remove from)
[10:52]  * didrocks looks at mythbuntu
[10:53] <rbasak> xnox: thanks. In this case I don't think it's included in a metapackage (it's from server-supported)
[10:53] <didrocks> ubiquity/plugins/myth-install-type.py, ah, promising :)
[10:53] <xnox> rbasak, ah, well, we do drop things on the floor (main->universe) and that is it =)
[10:54] <rbasak> OK
[10:54] <xnox> rbasak, upon upgrade with like do-release-upgrade, it does mention that these are now community supported packages.
[10:54] <rbasak> Good point
[10:54] <xnox> rbasak, so people can read it, and forget that list of things =)
[10:54] <didrocks> xnox: ok, I confirm that the list per install type is hardcoded in mythubuntu
[10:54] <xnox> didrocks, lolz
[10:55] <xnox> didrocks, slangasek was like "no i have not heard about didrocks adventures" and he was like "chat with him to align" and I'm like "i did", everyone likes everything =)
[10:55] <xnox> didrocks, but need to do the actual coding with stacked squashfses....
[10:55] <GunnarHj> cjwatson: Hi Colin! I'm investiging a translation issue for util-linux together with seb128. Translations haven't been imported to LP in a long time (7 years).
[10:55] <GunnarHj> The latest bionic build log claims that the tarball util-linux_2.30.2-0.1ubuntu1_amd64_translations.tar.gz was created. I'd like to see what it contains. Do you possibly know how to find it?
[10:56] <didrocks> xnox: yeah, we still need something for the LTS, so let's go with the easy option as a fallback in case you don't get the stacked squashfses work on time
[10:56] <Unit193> * Ship ubuntu-dgbsym key
[10:56] <didrocks> xnox: sounds like easy enough, not a lot would be lost
[10:56] <Unit193> xnox: Thnak you!
[10:57] <xnox> Unit193, your welcome. it is in a separate package though, just install that =)
[10:58] <cjwatson> GunnarHj: You should be able to dig it out from the queue.  Let me see ...
[10:58] <Unit193> Doesn't matter, it exists.  There's a bug that can be closed now too.
[10:58] <cjwatson> GunnarHj: https://launchpad.net/ubuntu/bionic/+queue?queue_state=3&queue_text=util-linux
[10:59] <GunnarHj> cjwatson: Thanks!
[11:07] <seb128> cjwatson, doing something like "ubuntu.getSeries(name_or_version='bionic').getPackageUploads(name='util-linux', version='2.30.2-0.1ubuntu1 ', custom_type='raw-translations')" from a lp-shell used to work but it doesn't seem to do what I expect now ... did that change/stop working?
[11:07] <cjwatson> seb128: That stray space in the version doesn't look likely to help.
[11:08] <seb128> shrug, indeed
[11:08] <seb128> cjwatson, thanks for spotting :)
[11:08] <seb128> and sorry for the noise
[11:08] <cjwatson> np
[11:08] <cjwatson> I expect there's more debugging to do here, but I think the relevant logs have expired at our end by now since the last attempt was a while ago
[13:14] <xnox> doko, on arm64, gcc: error: unrecognized command line option ‘-m64’ -> i guess one should not use that option, ever, right?
[13:22] <mdeslaur> cpaelzer: FWIW, virt-manager 1.4.3 ftbfs on bionic
[13:23] <mdeslaur> cpaelzer: I can give you my debdiff if you feel like investigating
[13:23] <mdeslaur> cpaelzer: this is what I'm hitting: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888133
[13:24] <cpaelzer> mdeslaur: I was just starting a merge a few minutes ago
[13:24] <cpaelzer> mdeslaur: did you already start one?
[13:25] <mdeslaur> cpaelzer: yes, then hit all the test failures in the debian bug
[13:25] <mdeslaur> one sec
[13:26] <mdeslaur> let me retry building it to see if anything changed
[13:29] <cpaelzer> mdeslaur: guido marked it as found in libvirt 4.0 - so likely a change in behavior in there
[13:29] <cpaelzer> mdeslaur: I might abandon my just started merge and better help you to get over that FTBFS
[13:29] <mdeslaur> yeah, that's what I suspected...I looked through the virt-manager tree to see if there seemed to be any commits to address that, but I had not found any
[13:30] <mdeslaur> perhaps it's worthwhile to try 1.5
[13:30] <mdeslaur> ok, still get the test failures...let me stick my source package somewhere for you
[13:41] <cpaelzer> mdeslaur: 4224b092 or fe59c337 maybe
[13:42] <cpaelzer> mdeslaur: FYI I can recreate the issue
[13:42]  * mdeslaur looks
[13:43] <mdeslaur> cpaelzer: I had tried 8b4befae602779cbef2d579e4c532b9cd0f1fee9
[13:43] <mdeslaur> but yeah, perhaps combining them all
[13:45] <mdeslaur> or just going to 1.5
[13:49] <cpaelzer> I try that atm
[13:49] <cpaelzer> rather brute force, just to know if it would work
[13:50] <cpaelzer> already building ...
[13:56] <cpaelzer> mdeslaur: 1.5 is failing as well, but differently
[13:56] <mdeslaur> :(
[13:57] <cpaelzer> now around "Size must be specified for non existent volume" and ....img' does not exist
[13:58] <mdeslaur> how silly of me to think that they would test the latest virt-manager on the latest libvirt ;P
[13:58] <pchamtaczke>  hi ubuntu devs. I need help with launchpadlib. I need to retrive package's dsc information sorted by publish date
[13:58] <cpaelzer> mdeslaur: all remaining issue son 1.5 have "/tmp/__virtinst_cli_exist1.img" being missing as the issue
[13:59] <cpaelzer> veen the messages with the size track down to the same thing
[13:59] <mdeslaur> oh, interesting
[13:59] <pchamtaczke> repositories are divided by main and contrib. Is there a way to retrive only from one repo?
[14:11] <cjwatson> Ubuntu doesn't have a "contrib" component; its equivalents are main/restricted/universe/multiverse.  https://launchpad.net/+apidoc/devel.html#archive-getPublishedSources and similar calls can be given a component name to filter results.
[14:12] <cjwatson> (And I think that should answer your other question too.)
[14:12] <cpaelzer> mdeslaur: of the cdrom cases only the s390x cases fail
[14:12] <xnox> cpaelzer, but s390x has no cdrom....
[14:12] <xnox>  =)
[14:12] <cpaelzer> well you can pass a virtual one
[14:13] <mdeslaur> cpaelzer: kill it with fire
[14:13] <cpaelzer> the others are all with virt-clone
[14:13] <cpaelzer> not sure yet, but they all seem to have the same "signature" so I hope it is one or two fixes at most
[14:15] <mdeslaur> cpaelzer: ProTip: I always write xnox's name in the changelog when I break s390x stuff ;)
[14:16] <cpaelzer> real Pro :-)
[14:16] <cpaelzer> it is not any s390x specific thing in this case (other than by accident of names)
[14:16] <mdeslaur> hehehe
[14:16] <cpaelzer> just the tests that refer to /tmp/__virtinst_cli_exist1.img in their test xml fail
[14:16] <cpaelzer> I assume the setup of said file fails
[14:16] <cpaelzer> but it hides from me atm
[14:18] <cpaelzer> ah there is an exist_images in clitest.py - that looks good
[14:27] <cpaelzer> mdeslaur: this is a file that the test entry is supposed to prepare
[14:27] <cpaelzer> mdeslaur: and it does
[14:27] <cpaelzer> mdeslaur: but as a link to a non existing file
[14:27] <mdeslaur> hrm
[14:27] <cpaelzer> mdeslaur: I'll go on debugging and let you know what I find or if I give up
[14:27] <mdeslaur> ack, thanks
[14:28] <pchamtaczke> cjwatson: ok i get it. It there a way to get history of package? I mean for example history of gimp package: what version was in 2014, what dependencies, what binaries had?
[14:28] <pchamtaczke> i see that prints current packages
[14:31] <cjwatson> pchamtaczke: That call returns publication records, which includes packages that have been superseded or deleted, so it's the basic building block for what you're asking for.
[14:32] <pchamtaczke> thanks, its nice. This answer is sufficient for me ;)
[14:32] <cjwatson> pchamtaczke: Though quite a bit of assembly will be required if you're trying to work out properties of binaries, and depending on what you're doing it may be easier to go through archive.getPublishedBinaries.
[14:33] <cpaelzer> mdeslaur: ok, silly me
[14:33] <cpaelzer> mdeslaur: that was actually an artifact of my "brute force 1.5"
[14:33] <cpaelzer> mdeslaur: resolved the issue, well done 1.5 looks good now
[14:33] <cpaelzer> inside my sbuild chroot
[14:33] <cpaelzer> mdeslaur: if you'd go to a tarball of 1.5 it should be just good
[14:35] <mdeslaur> cpaelzer: oh, awesome
[14:35] <mdeslaur> cpaelzer: are you going to upoad it?
[14:36] <cpaelzer> I'd need to clean up a lot
[14:36] <cpaelzer> but yes I think I'll redo the merge you did and add 1.5 on top
[14:36] <cpaelzer> unless you say it would be easy for you to add 1.5 on top of yours
[14:37] <cpaelzer> reading your changelog it was just dropping upstrema changes on your rebase
[14:37] <cpaelzer> I should be able to redo that quickly
[14:37] <cpaelzer> mdeslaur: I'll set you as additional reviewer when I have something ok ?
[14:40] <pchamtaczke> cjwatson: i need to build api that retrieve information about binaries from fixed time interval. I need follow properties from binaries: name, version, architecture and publication date. Every property i have from received objects from `getPublishedBinaries`. That intervals will be problematic but i invent something
[14:42] <mdeslaur> cpaelzer: sure
[14:45] <cpaelzer> mdeslaur: you dropped use_qxl_for_ubuntu.patch I don't see the upstream change for it
[14:45] <cpaelzer> other reasons to drop ?
[14:47] <cpaelzer> oh was this 15.04 only?
[14:47] <mdeslaur> it was dropped upstream
[14:47] <cpaelzer> not sure how _is_related_to is evaluated
[14:48] <cpaelzer> was that  984ba6b33e80f9a91b93677b991fcd7ee4831218
[14:48] <cpaelzer> yep
[14:48] <cpaelzer> ok
[14:48] <mdeslaur> yes
[15:32] <doko> xnox: yes
[15:45] <doko> GunnarHj: pkgbinarymangle's tests fail
[15:46] <GunnarHj> doko: I know. seb128 will look at that.
[15:47] <seb128> doko, do you have any idea what could be wrong? that doesn't look related to the change so was probably an existing issue in bionic
[15:53] <cpaelzer> mdeslaur: 1.5 built fine now
[15:53] <mdeslaur> cpaelzer: awesome
[15:53] <cpaelzer> mdeslaur: I'll push a review as soon as calls leave me alone
[15:55] <doko> seb128: sorry, no. just saw the ftbfs
[15:55] <doko> maybe needs updates for new debhelper?
[15:57] <seb128> could be, it seems to fail to unpack some source
[15:57] <seb128> I don't know what changed in debhelper, need to have a look
[15:58] <seb128> "AssertionError: b"no entry control.tar.gz in archive\n\ngz[179 chars]nd\n" != b'' : b"no entry control.tar.gz in archive\n\ngzip: stdin: unexpected end of file\ntar"
[16:03] <cpaelzer> mdeslaur: please review https://code.launchpad.net/~paelzer/ubuntu/+source/virt-manager/+git/virt-manager/+merge/337287
[16:03] <cpaelzer> mdeslaur: there is also a ppa building across arches to test, linked from the MP
[16:05] <mdeslaur> ugh, how about a debdiff
[16:08] <mdeslaur> cpaelzer: I'm in the middle of something, I'll pull it down in an hour and take a look
[16:08] <cpaelzer> mdeslaur: due to timezones you'll have all of your day to do it
[16:10] <mdeslaur> cool :)
[16:32] <bdmurray> How does one suspend from gnome on bionic? The power button only offers shutdown.
[16:33] <nacc> bdmurray: from the dropdown, hold Alt
[16:33] <nacc> bdmurray: iirc, it toggles from power off to suspend
[16:33] <nacc> super intuitive :)
[16:33] <xnox> bdmurray, i wish that was fixed becuase the "just close the lid" does not work on the desktop
[16:33] <bdmurray> that's crazy
[16:34] <nacc> bdmurray: did it change to a 'pause' for you?
[16:34] <bdmurray> nacc: yeah, hence my comment
[16:34] <nacc> bdmurray: yeah :0
[16:35] <nacc> bdmurray: there's also a screen rotation thing if you have that, and it's equally unintuitive (does the icon it show mean that's the current state or what it would go to??)
[16:35] <nacc> it's *almost* like gnome doesn't care about users' sanity
[16:41] <GunnarHj> seb128: I built pkgbinarymangler successfully on artful (locally). So there is indeed something with the builddep versions.
[16:41] <jbicha> bdmurray: it's documented at https://help.ubuntu.com/stable/ubuntu-help/shell-exit.html#suspend :(
[16:42] <bdmurray> jbicha: Do you know if there is a bug report about the issue?
[16:43] <jbicha> lol
[16:43] <jbicha> it's a Feature
[16:43] <xnox> bdmurray, i think i made one.
[16:44] <jbicha> you'd have to convince either GNOME Designers or the GNOME Shell developers of the behavior you want
[16:44] <jbicha> or convince the Ubuntu Desktop team that it's worth diverging for
[16:44] <xnox> bdmurray, i wonder if there is an extension we can ship, and/or some such
[16:44] <jbicha> one issue with adding an extra Suspend button there is that 5 buttons makes it crowded at the bottom of the menu
[16:45] <xnox> https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1697143
[16:45] <GunnarHj> bdmurray, jbicha: I got the same question in the Swedish loco, and provided the very same link to the docs.
[16:45] <nacc> there was a proposal at some point that they shouldl all be togglles
[16:45] <jbicha> (the 4th button is the auto-rotate button that shows up on certain hardware)
[16:45] <nacc> or something like that
[16:45] <xnox> jbicha, 5? which five? I only have three
[16:45] <nacc> xnox: i have 4
[16:46] <nacc> xnox: and a suspend would be 5
[16:46] <nacc> xnox: you only have 4 if you ahve a rotate-able screen
[16:46] <xnox> nacc, i have system settings, lock, shutdown.
[16:46] <jbicha> xnox: there's a screenshot of the auto-rotation button on the bug report
[16:46] <xnox> nacc, that screen rotation button is well.... useless
[16:46] <nacc> xnox: right
[16:46] <nacc> xnox: it can be handy to have it disabled, fwiw
[16:46] <xnox> a suspend one >>> screen rotation
[16:46] <nacc> as otherwise your screen flickers a lot :)
[16:47] <xnox> nacc, imho it should be disabled by default, and if you enable it in setting, get the lock rotation button.
[16:47] <nacc> xnox: yes, that's basically how it works
[16:47] <nacc> you have to (on my hardware) install iio-sensor-proxy and configure it properly to get rotation
[16:47] <xnox> nacc, and imho settings button should be "System settings..." a line entry.
[16:47] <jbicha> nacc: iio-sensor-proxy is installed by default
[16:48] <nacc> jbicha: ah ok, it wasn't at the time i installed :)
[16:48] <nacc> xnox: yes, the icons don't make anything clearer to me
[16:48] <xnox> nacc, ok, when you click power button, it should have "suspend", "hybernate" test buttons options....
[16:48]  * jbicha points xnox to #gnome-design on irc.gnome.org …
[16:48] <nacc> heh
[16:48] <xnox> https://extensions.gnome.org/extension/826/suspend-button/
[16:48] <jbicha> but it's difficult getting change from GNOME Design, both because many of these issues have been presented many times
[16:49] <jbicha> and because GNOME Design made all their radical changes for 3.0 and now are hesitant to make major changes ;)
[16:51] <xnox> "or simply long-click the power off button." what the?!
[16:51] <jbicha> it sort of makes sense except that I can't think of anywhere else in GNOME that uses long-click
[16:52] <xnox> there is no indication that it is a long-clickble button
[16:52] <xnox> it could have been a GIF that animates


[12:13] <joep> Hi, I am trying to install 7.10 in a 64-bit AMD system. I'm running now FC7. Except boot are all partitions on LVM. Ubuntu doesn't recognize this. IS there a solution?


[00:11] <lamont> cjwatson: well, the part of me wearing my buildd-guy hat would be tempted to just stub it out completely, but that would be, well, wrong.
[00:15] <cjwatson> lamont: it's a genuine request, I've spent a fair bit of time making that go faster (principally by optimising the hell out of process execution and trying to do as much in-process as possible) but perhaps other eyes could see something I missed
[00:17] <lamont> cjwatson: yeah - I'll add it to my list of things to do
[00:17] <cjwatson> I note idly that man-db can do full-text search of all manual pages on my laptop over seven times faster than Fedora's man package can
[00:18] <cjwatson> (and that's without either of them having a proper FTS engine in there, which would probably be a good idea)
[00:18] <cjwatson> (http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/2009-07-14-man-db-K.html)
[00:22] <ScottK> ajmitch: :-)
[00:23] <ScottK> I only got involved with it because no one else was sorting it and one of the major users in Main is KDE.
[00:23] <ajmitch> ScottK: I've dropped the majority of changes that we had, but there's some black magic going on with dependencies from what I've seen
[00:23] <ajmitch> I only touched it because of boost-python being broken & it being a dependency of other packages
[00:25] <ScottK> ajmitch: If you want a package that uses the MPI stuff, elmerfem needs merging.
[00:25] <ajmitch> I may take a look
[06:26] <Joit> hi. where can i make suggestions for the install cd
[06:51] <dholbach> good morning
[07:28] <chilicuil> hhh
[07:33] <pitti> Good morning
[08:39] <geser> could an archive admin please kill http://people.canonical.com/~ubuntu-archive/NBS/rdoc1.8. ruby1.8 provides/conflicts/replaces rdoc1.8 and there are only unversioned dependencies left (and one versioned but ruby1.8 is the preferred alternative to rdoc1.8)
[08:40] <geser> and the same for http://people.canonical.com/~ubuntu-archive/NBS/rdoc1.9.1. ruby1.9.1 provides/conflicts/replaces rdoc1.9.1 and only unversioned dependencies left.
[08:43] <sabgenton> ubuntu servers usb install instructions http://www.ubuntu.com/server/get-ubuntu/download show how to install desktop
[08:44] <sabgenton> this is disconcerting as with say   the old  karmic this never worked for server editon
[08:44] <sabgenton> does this information even work?
[08:44] <sabgenton> (for server)
[08:46] <sabgenton> considering there was never in the  past support  for server on usb   http://www.ubuntu.com/server/get-ubuntu/download should be made a lot clearer if there really is support now.
[09:01] <bigon> robert_ancell: are you around?
[09:01] <robert_ancell> bigon, hi
[09:05] <robert_ancell> bigon, ?
[09:06] <bigon> robert_ancell: hi, about http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550478 is this really needed? josselin was not happy with putting things for testing purpose only in the "production" package
[09:07] <pitti> is it just me, or has edge.lp been ridiculously slow since yesterday?
[09:08] <robert_ancell> bigon, it's proposed to be in the -dev package.  It is used by python-gi in their make check.  If we don't package it somewhere then that will always fail.
[09:09] <robert_ancell> bigon, since it is built and installed with make install, I'm guessing the gobject-introspection guys consider it useful in other projects.
[09:11] <bigon> robert_ancell: it's require the adding of an extra shared lib too
[09:12] <robert_ancell> bigon, does that matter?
[09:13] <cjwatson> sabgenton: please file a bug on https://bugs.launchpad.net/ubuntu-website about that
[09:14] <sabgenton> doing right now :)
[09:14] <cjwatson> sabgenton: (the webmaster isn't likely to be awake at this time and isn't in this channel anyway)
[09:14] <sabgenton> what chanel ?
[09:15] <sabgenton> cjwatson: where does he live on irc?
[09:17] <cjwatson> sabgenton: please use the bug tracking system, it's more efficient
[09:17] <sabgenton> k doing
[09:32] <ogra> pitti, hey, looking at udisks i see we dont have any ubuntu patches in it, i need to add one thats really specific to the image builds, so very ubuntuish, do you think upstream would accept that or should i just go ahead and add a quilt patch ?
[09:32] <pitti> ogra: depends on the patch
[09:33] <ogra> pitti, its adding another partition label to the hidden partitions in the udev rule
[09:33] <pitti> ogra: if it's sensible for Debian, I can commit it there; if it's sensible for upstream, I'd rather commit it there and then cherrypick to Debian and sync
[09:33] <ogra> its not sensible for either i think, since it fully depends on the way we build images
[09:34] <pitti> ogra: and we can't use one of the standard partition types for rescue partitions?
[09:34] <pitti>   ENV{UDISKS_PARTITION_TYPE}=="0x00|0x11|0x12|0x14|0x16|0x17|0x1b|0x1c|0x1e|0x27|0x3d|0x84|0x8d|0x90|0x91|0x92|0x93|0x97|0x98|0x9a|0x9b|0xbb|0xc2|0xc3|0xdd|0xef", \
[09:34] <ogra> omap images will have a vfat partition that fakes a NAND and is the first partition, i want to hide that on desktops
[09:34] <pitti> there's plenty to choose from, after all?
[09:34] <ogra> no, i cant change the type
[09:34] <ogra> it has to be a label
[09:34] <ogra> else the bootloader wont work
[09:35] <pitti> does the type/label come predefined by some vendor?
[09:35] <ogra> no, i can define the label, the type needs to be vfat bootable etc etc
[09:35] <ogra> (wioth a certain CHS layout even)
[09:35] <pitti> ogra: so, what's the new label?
[09:35] <pitti> ogra: we can't just use "Recovery Partition" or "RECOVERY"?
[09:35] <ogra> well, i'D call it OMAPBOOT or some such
[09:36] <pitti> ah
[09:36] <ogra> currently i use one of the SYSTEM* labels
[09:36] <ogra> works fine but its an abuse
[09:37] <ogra> if you think that abuse is fine i can also keep it but calling it OMAPBOOT or some such would be cleaner
[09:37] <pitti> ogra: I don't mind the "abuse" :)
[09:37] <ogra> ok, i'll keep the current name then
[09:37] <pitti> ogra: OTOH, any package can ship a rule to ignore it
[09:37] <pitti> ogra: i. e. if your boot loader package ships an udev rule to ignore OMAPBOOT, that's just fine
[09:37] <ogra> right, but that would mean a new package just for that
[09:38] <ogra> we dont install the bootloader packages :)
[09:38] <pitti> ok
[09:38] <ogra> flash-kernel could probably do it though ... hmm
[09:38]  * ogra will think about that, thanks pitti
[09:38] <pitti> ogra: so, I don't mind which label it has; I'd just like to avoid a delta to Debian just for this
[09:38] <ogra> yeah, understood
[09:39] <pitti> so if it's necessary, I'd rather commit it to the Debian tree
[09:39] <pitti> (need to ask mbiebl for that, since it's debatable)
[09:39] <ogra> well, its very ubuntu specific
[09:40] <ogra> so i dont think debian wants it
[09:40] <pitti> other distros don't use that boot loader?
[09:40] <pitti> (meego, etc.)
[09:40] <ogra> its bound to the way we build the new images which i assume debian will never adopt )preinstalled images)
[09:41] <pitti> ogra: in general such things should be maintained in one place; i. e. if your image build system defines $LABEL, it could also stick in an udev rule file which ignores that very $LABEL :)
[09:41] <ogra> the new images are two partition images where we resize the second partition on the fly to the full size of the disk while the first partition has to follow a ceratin scheme
[09:41] <pitti> echo ... > /etc/udev/rules.d
[09:41] <ogra> right, butu the tool i use gets removed with oem-config
[09:41] <geser> cjwatson: could you please kill rdoc1.8 and rdoc1.9.1 from the NBS list? or should I file a bug for it?
[09:42] <ogra> and i dont really want a file on the FS thats not handled by a package
[09:42] <pitti> ogra: /etc/udev/rules.d/ already has a few
[09:42] <ogra> but rolling a package only for the rules file seems overkill
[09:42] <pitti> persistent network, etc.
[09:42] <ogra> hmm
[09:42] <cjwatson> geser: one moment
[09:42] <pitti> ogra: no, if nothign else, the image build process should do that along with creating the partitions -> define stuff in one place
[09:43] <ogra> pitti, well, then i can also do it from jasper-initramfs during fiorst boot
[09:43] <BlackZ> pitti: did you read my e-mail regarding cdbs?
[09:43] <cjwatson> geser: done
[09:43] <geser> thanks
[09:43] <pitti> BlackZ: not yet, bit busy right now; I'll get to it
[09:43] <jmux> Hi. I'm on 8.04 LTS using upstart. I have a dhclient-exit hook, which fails, because udev starts ifplugd, which starts dhclient, which calls the hook before I have a writable local fs. How can I wait for the upstart writable fs event inside my dhclient exit hook?
[09:43] <BlackZ> pitti: thanks
[09:43] <pitti> BlackZ: I'm not in the ubuntu distro team this cycle, so I'm lagging on distro stuff, sorry
[10:02] <apw> cjwatson, was it you i was talking to about ti-omap in maverick, that we were now building those from the main package ?
[10:09] <cjwatson> apw: yeah, I hadn't got round to doing anything about the result of that conversation yet ...
[10:11] <apw> cjwatson, ahh ok then that makes sense... a quick Q on how to migrate the meta package, i _think_ i don't need anything speciial (replaces et al) to produce a replacement binary package at a higher version number from a different source package ... is that correct ?
[10:11] <sabgenton> is there any reason I should have my bug  ticked private?
[10:12] <apw> sabgenton, if apport ticked it private then it would likely mean that it thinks it added some backtrace information which may contain private information and it cannot tell
[10:12] <cjwatson> apw: correct
[10:12] <apw> cjwatson, thanks
[10:12] <sabgenton> apport?
[10:13] <sabgenton> sorry new to launchpad
[10:13] <apw> apport is the automatic bug filer, like from application crashes
[10:13] <apw> if its just your own bugs, then normally not
[10:14] <sabgenton> so if i want my bug to get traction I should make it unprivate?
[10:14] <sabgenton> I just typed the bug up my self on the website
[10:15] <apw> if you made it private, then likely  only you can see it, so noone else is even aware of it
[10:16] <cjwatson> private bugs are for (a) security bugs that need to not be disclosed to the public as yet (but in that case tick the security box so that the security team get to see it) (b) bugs with private information like crash dumps from your mail reader (but apport deals with subscribing some people so that they aren't entirely lost) (c) commercially-sensitive bugs, such as bugs from a hardware manufacturer on unreleased hardware
[10:17] <cjwatson> a private bug with no explicit subscribers other than yourself is invisible
[10:17] <cjwatson> (well, to everyone other than Launchpad admins, but they'll probably never look at it)
[10:19] <achaemenes> hi guys, im running 2.6.24-28-server on 8.04 - i want to get the kernel source, as-is currently running, disable CONFIG_DEBUG_RODATA, and build a package
[10:19] <achaemenes> i dont want the latest from git, i want the exact version, and all i want to do is rebuild it with that single change
[10:20] <apw> achaemenes, there are two ways to do that, but i would normally get the git source, the version you have is tagged in that
[10:20] <sabgenton> thanks for  the info
[10:20] <apw> achaemenes, we tag every released version
[10:20] <achaemenes> oh, i just installed linux-source-2.6.24
[10:20] <sabgenton> acording to what I understand now I'll unprivate it
[10:20] <apw> achaemenes, that is a raw source and not that useful for building
[10:21] <achaemenes> right, ok ill do a git clone then
[10:21] <apw> achaemenes, if you have trouble you can find us over on #ubuntu-kernel
[10:21] <achaemenes> excellent - thankyou apw
[10:22] <sabgenton> grr it won't  unprivate
[10:23] <sabgenton> ajax symbol spins but just  says error
[10:23] <sabgenton> probly my slow conection I guess
[11:15] <Joit> hi. where i can make suggestions for the install cd?
[11:15] <cjwatson> the bug tracking system, usually
[11:16] <Joit> ok thanks
[11:16] <Joit> and bye :)
[11:16] <cjwatson> there's #ubuntu-installer if you want to discuss things first, but IRC is in general not so good for anything you want to be remembered
[11:17] <Joit> ok i will try this channel too
[11:17] <Joit> well its actually only a option what is to add
[11:22] <tkamppeter> pitti, hi
[11:22] <pitti> hello tkamppeter
[11:24] <tkamppeter> pitti, what does the reporter of bug 597248 has to enter to get Apport making a symbolic backtrace of his segfault.
[11:25] <pitti> tkamppeter: easiest would be to enable apport for the current session and replicate the crash, and have apport pick it up; https://wiki.ubuntu.com/Apport#How%20to%20enable%20apport
[11:25] <pitti> tkamppeter: if he doesn't want that, the fallback is to install debug packages etc. locally and run under gdb, see https://wiki.ubuntu.com/DebuggingProgramCrash
[11:31] <tkamppeter> pitti, thank you.
[12:10] <Riddell> ev, cjwatson: as you may or may not have gathered we'd like to merge the kubuntu desktop and netbook images and load the correct desktop based on screen size, where is the best place to detect screensize and edit the config file on starting the live CD and installing the system?
[12:13] <cjwatson> somewhere in casper I suppose
[12:28] <thangam_arun> Hello all
[12:28] <thangam_arun> i am trying to trebuild kernel on ubuntu 8.10
[12:29] <thangam_arun> but i am getting only 2 .deb files, image and header
[12:30] <thangam_arun> is there any body can direct me to the right path ??
[12:30]  * ogra directs thangam_arun to #ubuntu-kernel :)
[12:31] <thangam_arun> Thanks
[14:37] <ccheney> doko, hello?
[14:38] <doko> ccheney: ?
[14:38] <ccheney> doko, did you happen to see my comments about the OOo MIRs that need processing?
[14:38] <ccheney> doko, they were assigned to you on jun 7
[15:37] <ccheney> pitti, hi
[15:38] <ccheney> pitti, iirc you are the person who assigns MIR bugs to people to process, is that correct? there is a server MIR I need to have processed for a2, bug 594372
[15:38] <pitti> ccheney: hello
[15:38] <pitti> ccheney: that's asac now (since I'm OEM this cycle)
[15:38] <ccheney> pitti, ah ok
[15:38] <ccheney> asac, ping, see above :)
[15:38] <pitti> :)
[15:38] <ccheney> pitti, have a great day :)
[15:39] <pitti> ccheney: thanks, you too!
[15:39] <pitti> in fact, was a pretty good "boot faster" day so far
[15:46] <asac> pitti: hey
[15:47] <pitti> hello asac, how are you?
[15:47] <asac> pitti: quite well ;)... hope you too! did you discuss with other linaro folks on how we can use your "reduce disk footprint"
[15:47] <pitti> oh, was I supposed to?
[15:47] <pitti> asac: I moved the stuff to the public wiki now, so it should be easy to grab
[15:47] <asac> pitti: no ;) ... just wanted to check so i dont ask questions already discussed
[15:48] <pitti> https://wiki.ubuntu.com/ReducingDiskFootprint
[15:48] <asac> pitti: cool. did the dpkg changes land in maverick?
[15:48] <pitti> it links to all the bzr changes, patches, etc
[15:48] <pitti> asac: not yet, just in debian's trunk so far
[15:48] <pitti> and I have a backport for lucid
[15:48] <asac> pitti: is it risky to make that available in maverick?
[15:48] <pitti> no, it's fairly well tested by now
[15:48] <pitti> we have run that in an OEM project for two weeks
[15:49] <asac> pitti: ok we have a https://blueprints.edge.launchpad.net/ubuntu/+spec/arm-m-disk-footprint spec
[15:49] <asac> pitti: i would like to give you an item to make the dpkg  available in the archive ... if you dont mind ;)
[15:49] <pitti> asac: the apt changes are interesting as well, but I'd like mvo to review the branch first
[15:49] <pitti> that didn't land upstream yet
[15:49] <pitti> asac: sounds fine
[15:49] <pitti> please do
[15:49] <asac> pitti: ok. i will read through your wiki and reuse most of that for the footprint spec which needs some love
[15:50] <asac> pitti: thanks!!
[15:50] <asac> stay tuned
[15:50] <pitti> gern geschehen
[15:54] <asac> ccheney: pushed that MIR to mterry
[15:54] <ccheney> asac, thanks!
[15:54] <mterry> asac, I have been remiss with MIRs, sorry
[15:54] <asac> mterry: heh. well, we all failed ;)
[15:54] <asac> mterry: do you have capacities at all atm?
[15:55] <mterry> asac, not really.  maybe this weekend
[16:17] <tseliot> pitti: do you think it would make sense if I made the -dev packages of the different nvidia packages conflict with each others? This would allow me to install the headers in (/usr/include) e.g. /usr/include/GL instead of what I'm currently doing /usr/include/nvidia-current/GL (so that all of them can be installed at the same time)
[16:18] <tseliot> slangasek: ^
[16:46] <pitti> asac: who is handling the firefox translation bits in langpack-o-matic these days?
[16:49] <asac> pitti: we said chrisccoulson_ would take that over through learning by doing
[16:49] <asac> e.g. whenever there is a need we would discuss and see how things go
[16:49] <pitti> asac: thanks
[16:49] <pitti> asac: I got a bug about adding a new language; I'll assign to Chris and sub you, does that sound ok?
[16:49] <asac> pitti: the po2xpi processor was improved by ArneGoetje in the past ... so if the problem is there he might be a good candidate
[16:49] <asac> pitti: yeah. tahts good
[16:49] <pitti> shoudl be easy, like adding a new file somewhere
[16:49] <asac> pitti: though ArneGoetje should be able to handle that too iirc
[16:50] <asac> but chrisccoulson_ should definitly be invovled so he get that knowledge too
[16:50] <pitti> *nod*
[17:09] <slangasek> tseliot: I think that makes sense, yes
[17:09] <tseliot> slangasek: ok, thanks
[17:11] <vish> pitti: hi, the sd/mmc card is also verified bug , previously we had a bigger numbering there , it is not visible now at normal view. which fixes the bug for most users. we will however be adding more icons in larger sizes for maverick which will solve the problem for users trying to zoom to 400% :)
[17:11] <vish> the humanity update ^
[17:12] <pitti> vish: ah, I see; please tag it as verification-done then (sorry, busy right now0
[17:12] <vish> pitti: cool , i didnt know i could do that. wanted to check with you first. Thanks
[17:12]  * vish doing it now
[17:43] <JFo> bryce_, bug 573601 looks like it is solved by some configuration in an X config. does this need to go back to an X package?
[17:44] <bryce_> *looking*
[17:45] <bryce_> JFo, yeah refile to nvidia-graphics-drivers if it looks like something a dev should look at
[17:45] <bryce_> JFo, if it's purely a configuration goof by the user, forward to answers or close as not a bug
[17:46] <JFo> hmm, not sure
[17:46] <JFo> he added some stuff and it fixed him
[17:46] <JFo> dunno where the goof was
[17:46] <JFo> I'll send it up to the dev
[20:34] <dupondje> pitti: you here ?
[20:58] <JontheEchidna> So, looks like libept broke API something awful yesterday. The textsearch class used for xapian is totally obliterated and left as two nearly-useless functions for getting the database path and the database timestamp
[20:58] <JontheEchidna> Since synaptic uses that class, somebody's gonna have to take care of it sooner or later. This is what I did for libqapt: http://pastebin.com/5rw3XwBV
[20:59] <JontheEchidna> It's not worth it to link to libept anymore to get a string and a time_t, imo
[21:01] <JontheEchidna> oops, wrong diff. http://pastebin.com/n5xKSqAg
[21:03] <JontheEchidna> Basically all one has to do is make member variables for the timestamp and the Xapian::Database, initialize them, then rip the expand() function out of ept::textsearch and slap it in the code somewheres
[21:05] <JontheEchidna> I'd contribute a patch, but I'm not in-tune with the build-systems of the G* world, given my K background. ;)
[21:10] <hdon> hello hard working ubuntu devs :) i submitted a bug report affecting "ALT+TAB" window switching -- a critical feature for developers and power users -- a long time ago but nobody seemed to notice it because, i believe, they were skeptical it could be reproduced. the bug still exists in Karmic Koala, and i have now updated the bug with a video demonstrating the problem: https://bugs.launchpad.net/ubuntu/+bug/405252
[21:11] <micahg> hdon: #ubuntu-bugs is more appropriate to have bugs triaged in
[21:12] <hdon> micahg, thanks for the advice
[23:31] <jono> is GIMP continually crashing for you all?
[23:38] <ddecator> the stable version was working for me earlier (on lucid)
[23:39] <arand> jono: 10.10? Randomly or on start?


[18:13] <markie-> hey room
[18:33] <brobostigon> evening markie- :0
[18:33] <brobostigon> :)
[18:34] <markie-> Hey brobostigon, how are things?
[18:34] <brobostigon> markie-: could be alot batter, but could be worse. and you?
[18:35] <brobostigon> better*
[18:35] <markie-> brobostigon: Pretty much the same, i'm hoping it rains  a little :P
[18:36] <brobostigon> markie-: clean the air out, yes.
[18:36] <markie-> brobostigon:  How has things been around here? anything exciting happening?
[18:37] <brobostigon> markie-: pretty quiet.
[18:37] <markie-> brobostigon:  Does this channel get promoted much?
[18:38] <brobostigon> markie-: i do sometimes, when i see interest.  ican account for anyone else.
[18:39] <brobostigon> cant*
[18:39] <markie-> Yea, fair enough :)


[16:59] <krytarik> Eickmeyer: In context of today's LP bug 1962304, it would seem grub2-themes-ubuntustudio should depend on grub2-common rather than grub-common, doesn't it?
[17:00] <Eickmeyer[m]> krytarik: Yes, but it seems weird that we're seeing this happen now, over two years later.
[17:01] <Eickmeyer> Part of me can't be bothered to SRU something this close to Jammy's release, which I guess is still 2 months out.
[17:01] <krytarik> Well, I think LP bug 1928019 reported earlier might be related to this too though.
[17:03] <krytarik> I mean 20.04 is supposed to be supported for about another year regardless though.
[17:03] <Eickmeyer> Yeah, as a grace period for upgrade.
[17:05] <krytarik> But yeah, given the few reports about this so far, I'm not sure it's worth the effort of doing an SRU either.
[17:11] <Eickmeyer> I am, however, seeing the grub-common package as a dependency of the grub theme, not the old branding-common package (since removed).
[17:12] <Eickmeyer> And I'm trying to figure out why it's not grub2-common. I might, for Jammy, make it grub-common | grub2-common.
[17:14] <krytarik> grub2-common depends on grub-common itself.  And the latter wouldn't help in the case the bug report is about.
[17:16] <Eickmeyer> It seems as though, in the case of the branding-common package, it ran update-grub on postinst, but that only works if the system already has grub installed.
[17:17] <Eickmeyer> In the case of this raspberry pi situation, that means it didn't have grub installed, which brought an impossible situation, which means my comment/closure still stands. Seems to be a support issue more than anything.
[17:20] <krytarik> I think we are just lucky that usually grub2-common is already installed by way of the bootloader itself.
[17:20] <Eickmeyer> Additionally, I recall 3 years ago when I made the change to the plymouth postrm (as is the case in the latter bug), that it needed to always assume grub was there. Pretty sure that was an AA that told me that, and I just followed.
[17:22] <Eickmeyer> Either way, I will proably fix for jammy, but I'm not 100% convinced SRU-ing this is worth the effort.


[16:49] <Roland> hi everybody. a little bit offtopic, but...  the problem is, on the 31. of january estonian, latvian and lithuanina prime ministers are gonna sign the Rail Baltic agreement. We have created a petition in these 3 languages to delay the signing until details of the project are made public. Currently we need help from lithuanians, to publish it on one of your petition site. If you want details, write me.


[00:06] <cyphermox> gah
[00:06] <cyphermox> no
[00:06] <cyphermox> the bug is about it being broken
[00:06] <cyphermox> the fix for the leaks is correct and I think it was successfully validated too
[00:07] <cyphermox> except it's still not fixing the underlying, related dbus issue
[00:12] <cody-somerville> cyphermox: This is what I see with dbus-monitor: http://pastebin.ubuntu.com/1529451/
[00:12] <cody-somerville> cyphermox: The errors are returned by bus_event_group or bus_about_to_show_group in libdbusmenu-glib/server.c.
[00:12] <cyphermox> yeah
[00:13] <cyphermox> but NM doesn't do anything magical with the dbusmenu stuff itself, everything goes through libappindicator as a batch
[00:13] <cyphermox> it's really just calls to app_indicator_set_menu, with the full menu and the old one getting unref'djust prior
[00:14] <cyphermox> there is no reason why the menu wouldn't be available as far as nm-applet is concerned
[00:14] <cyphermox> I'd be interested to know if the same kind of behavior happens when nm-applet runs outside the indicator-applet
[00:14] <cyphermox> it probably doesn't stop responding in that case
[00:20] <cody-somerville> cyphermox: Do any other indicators that you know of update themselves as much and have event groups?
[00:20] <cyphermox> sadly no
[00:21] <cyphermox> no other indicators update as much
[00:21] <cyphermox> just a second I'm tracking down one weird kernel header thing
[00:25] <cyphermox> yay broken
[00:26] <cyphermox> cody-somerville: so I will get back to the libdbusmenu code, I'm pretty convinced the issue is there
[00:26] <cyphermox> but it's not obvious what goes wrong, it needs more work
[00:27] <cody-somerville> cyphermox: Agreed.
[00:44] <cody-somerville> cyphermox: For bus_event_group and bus_about_to_show_group, they both iterate over the events calling bus_event_core on each. If bus_event_core returns TRUE, they set 'gotone' to TRUE. bus_event_core then calls lookup_menuitem_by_id which looks in the dbusmenu server's lookup cache (a hashtable). It would appear that this lookup returns NULL which causes bus_event_core to return FALSE. Thus 'gotone' stays as FALSE and both b
[00:44] <cody-somerville> us_event_group and bus_about_to_show_group return the error we see.
[01:24]  * xnox ponders if the system load indicator is similar or not, as it's menu is constantly updated with values if one keeps it open.
[02:07] <smspillaz> tkamppeter: *shrug* I don't develop drivers