[09:05] <plantoschka> hiho :)
[10:16] <Pjotr> Hello, can anybody tell me who I can contact about fixing this bug: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/868613
[10:17] <Pjotr> A patch has been submitted (twice, in fact, by thow different people). So fixing it should be easy and quick. Yet it hasn't been done yet, and I don't know who I can ask to do it.
[10:31] <Pjotr> Another question, or rather a feature request: I'd like to see the option in xfce4-power-manager in Xubuntu, to make a laptop shutdown when I close the lid. Now this option is not there....
[10:35] <knome> Pjotr, the bug will be in oneiric SRU, as sebastien bacher told you
[10:47] <Pjotr> knome: yes, I know. But I'd like to see it fixed for 12.04. No delay needed, it can be fixed quickly. Then I can alert the other translators, that they can translate the three remaining strings. :-)
[10:47] <knome> the delay comes from the ubuntu release strategy
[10:48] <Pjotr> knome: can you explain that? I don't understand.
[10:49] <knome> in short, oneiric is updated now
[10:49] <knome> only critical+some other updates will get through for everybody
[10:49] <knome> they will be released on oneiric in SRU's (stable release update)
[10:50] <knome> the SRU's are named 10.04.1-3 on LTS's
[10:50] <knome> in non-LTS, there are no specific names afaik, but still, once the version is released, one can't make updates for it infinitely and all the time
[10:51] <knome> because things should be fixed in the next version, unless they are critical
[10:52] <Pjotr> I see. When can I expect to see it fixed for 12.04 Precise Pangolin? With alpha 1 or so?
[10:52] <knome> the toolkit for precise is set after uds
[10:52] <knome> after that changes are possible
[10:53] <knome> before that, it's technically impossible to have it in precise
[10:53] <Pjotr> OK, thanks. :-)
[10:53] <knome> np
[10:53] <Pjotr> Now about this xfce4-power-manager thing I just mentioned: do you happen to know anything about that?
[10:54] <knome> you probably should ask mr_pouit, he should probably know why it's not available/working
[10:56] <Pjotr> I'll do that. Thanks for your time.
[13:20] <GridCube> good morning :)
[16:52] <pleia2> knome: can I get a login to your wiki so I can work on your site todo list?
[16:53] <pleia2> would be good to add other notes there (like what redirects we need)
[16:53] <pleia2> and never got a reply from WPML :(
[18:39] <knome> pleia2, sure
[18:41] <knome> pleia2, you should have email at lyz(at)yourdomain
[18:41] <knome> bbl ->
[18:42] <pleia2> ty knome <3
[18:42] <pleia2> all news posts from drupal are now in the new wordpress install
[19:58] <pleia2> ok, copied over the rest of the pages and updated the todo wiki
[20:13] <knome> pleia2, nice!!
[20:13] <pleia2> :)
[20:13] <pleia2> went into drupal for full lists of stuff, so that's everything
[20:14] <knome> yeah
[20:14] <knome> tahnks
[20:14] <knome> we need to get the newest plugin revision in
[20:14] <knome> then i can get to fixing the css
[20:15] <knome> so since we didn't make the oneiric release, let's make it all be near perfect on first shot
[20:15]  * pleia2 nods
[20:15] <knome> i have a similar ticket with ubuntu studio pending too ;)
[20:16] <pleia2> working on their site too?
[20:16] <knome> yup
[20:16] <knome> http://temp.knome.fi/ubuntustudio/wordpress/
[20:16] <pleia2> cool
[20:17] <knome> note the JS "featured" tabs
[20:17] <pleia2> ooh
[20:17] <knome> and yeah, that is *working under wordpress*
[20:18] <pleia2> :D
[20:19] <knome> and you can edit/add the tabs like normal pages too...
[21:05] <Unit193> Request: Install gvfs-backends by default :P
[21:08] <knome> mm-hmm
[21:13] <mr_pouit> I already fixed that in the seeds for precise =]
[21:14] <Unit193> Thank you very much
[21:32] <knome> is there something for about £12 that one should order from amazon?


[03:12] <mahdi_ja> i configure a ftp server and when i want connect to it i get this error : packet_write_wait: Connection to <IP_ADDRESS> port 22: Broken pipe
[03:12] <mahdi_ja> Connection closed
[03:16] <sarnold> mahdi_ja: port 22 is ssh
[03:17] <sarnold> did you configure sftp instead?
[03:17] <sarnold> (sftp is far better than ftp for most users)
[03:23] <mahdi_ja> sarnold, yes i configure sftp
[03:23] <sarnold> mahdi_ja: can you ssh to localhost?
[03:23] <mahdi_ja> yes i do this for test
[03:24] <mahdi_ja> sarnold, yes i do this for test
[03:24] <sarnold> mahdi_ja: so ssh works but sftp doesn't?
[03:26] <mahdi_ja> sarnold, whit ssh i get this error :Permission denied, please try again.
[03:27] <sarnold> mahdi_ja: I think solving that will go a long way
[03:27] <mahdi_ja> sarnold, and how ?
[03:28] <sarnold> mahdi_ja: check the sshd logs, auth logs, see what errors it's reporting
[03:32] <mahdi_ja> sarnold, thank you
[03:32] <sarnold> mahdi_ja: time for me to run, have fun, good luck, and paste errors to a pastebin if you need more, hopefully someone will be around :)
[10:39] <emOne> Are there some default lists of ports that should be closed by default?
[10:40] <emOne> are there any ports which are already closed on ubuntu server ?
[10:41] <lotuspsychje> emOne: security is a wide area to deal with
[10:41] <lotuspsychje> emOne: try to nmap yourself externally, to see whats open and what not
[10:42] <lotuspsychje> emOne: the attacker is always looking for 24/7 servers with interesting services that are exploitable
[10:44] <emOne> I believe none of my ports are firewalled
[10:44] <lotuspsychje> emOne: its a combo of interesting services they are after, updated or not is important
[10:44] <lotuspsychje> emOne: try nmap -PN -sV ip for services
[10:45] <emOne> lotuspsychje: I received an email saying I should do something about my port 111 which is used by portmapper
[10:47] <lotuspsychje> emOne: running NFS?
[10:48] <emOne> lotuspsychje: I am not sure. I locked myself out while activating the firewall
[10:49] <emOne> trying to get back online
[11:43] <weedmic> Before I write a programme to do the following, is there already such a tool?  runs every x mins, check items v triggers, if trigger is met, send warning email, if triggers not met, apend to report.  captures snapshot of cpus usage, memory usage, storage remaining.  Sends report once each day, sends triggers immediately.
[11:50] <lordievader> weedmic: This sounds like Zabbix
[11:57] <weedmic> will check - i normally use htop and have a big monitor with lots open all the time, but, this is for someone in the backoffice to glance at once a day.
[12:31] <vlt> weedmic: Or Nagios/Icinga.
[12:53] <lordievader> weedmic: Zabbix will nag at you when things hit the fan 😋
[13:48] <weedmic> when htop reports "load average = 18.6" and I have 40 cpus, the number is cpu equivalents?  t/f?
[13:50] <nacc> weedmic: load average is about (in some sense) runnable processes, it's not normalized to how many cpus you have
[14:01] <weedmic> so, 18.6 means about 18 processies are running at the same time on average?
[14:02] <weedmic> if so, how does one know when the number is high enough to be a concern/worry?
[14:17] <lordievader> It is not necesarily running. It means that 18.6 cores are busy a 100% of the time.
[14:18] <lordievader> What I typically do is normalize the load by dividing it between the number of cores/cpus available. That way if it reaches a 100% I know the machine is fully utilized. Above it the machine is over utilized, etc.
[14:24] <weedmic> ok, so it is like I thought, but you are saying cores not cpus.  I have a lot more cores than cpus, so 18.6 must be unimportant.
[14:24] <weedmic> i meant threads not cores nor cpus
[15:16] <nacc> weedmic: every hardware thread is a logical CPU in Linux; load isn't really core based -- it's logical CPU based
[15:17] <weedmic> Q
[15:44] <weedmic> to calculate average cpu load, i can do "inxi -x -C", add all the cpu (col 3) and divide by 5 (It only does top 5) - correct?
[15:48] <weedmic> nvm - the real thing i wanted was "cat /proc/loadavg”"
[16:43] <teward> ahasenack: can i coopt you to do some nginx testing for me?
[16:43] <teward> very basic tests but :P
[16:43] <ahasenack> teward: probably :)
[16:44] <teward> ahasenack: can you install nginx from bionic updates, remove the IPv6 listen line, and then restart NGINX, and see if it still listens on IPv6?
[16:44] <ahasenack> that would be odd if it did
[16:44] <teward> from what I can tell a straight `listen 80;` will still listen on both v4 and v6 in most modern setups
[16:44] <ahasenack> and the host, ipv6 enabled? For this test
[16:44] <teward> since listen 80 without <IP_ADDRESS> is a "bind all"
[16:44] <teward> yeah
[16:44] <teward> and then if you want to test with v6 disabled feel free
[16:44] <ahasenack> let me get a vm then
[16:45] <teward> ack
[16:45] <teward> to my knowledge based on the documentation, listen :80 is equivalent to "LIsten on port 80 on all available interfaces and IP addresses"
[16:45] <teward> and listens on <IP_ADDRESS>:80 and [::]:80
[16:47] <ahasenack> upstream said in the upstream bug that by default nginx doesn't listen on ipv6, though
[16:47] <ahasenack> but we shall know in a few
[16:48] <ahasenack> teward: hm, looks like it stops listening on ipv6: https://pastebin.ubuntu.com/p/McKNnMTBSS/
[16:48] <teward> hmm
[16:49] <teward> ahasenack: AIUI though disabled IPv6 is nonstandard
[16:49] <teward> and not the 'norm'
[16:49] <teward> therefore this is an edge case that we can't easily adapt for...
[16:49] <ahasenack> I tend to agree
[16:49] <ahasenack> sshd ships with
[16:50] <teward> i could have SWORN we had another bug like this
[16:50] <ahasenack> #ListenAddress <IP_ADDRESS>
[16:50] <ahasenack> #ListenAddress ::
[16:50] <ahasenack> commented like that
[16:50]  * teward digs into it
[16:50] <ahasenack> and it doesn't fail to start if ipv6 isn't there
[16:50] <ahasenack> but I think it would fail if the ipv6 line was uncommented
[16:50] <ahasenack> and ipv6 was not supported
[16:51] <teward> fairly sure https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1743592 is a dupe of this
[16:51] <ahasenack> agreed it is
[16:52] <teward> duped it
[16:52] <teward> we could introduce this in Eoan first
[16:52] <teward> see if there's any whining/moaning
[16:52] <teward> but it's not SRU-able on its own
[16:53] <teward> rbasak: ^ in case you want to check my brain on this
[16:53] <teward> but i'm fairly sure a 'default config' change SRU is not going to be enough to be SRU worthy on its own
[16:54] <teward> nor would such an SRU actually *get* to the end users side of things because of how config files're handled
[16:56] <rbasak> Sorry, I'm just finishing one thing and then I need to run.
[16:56] <rbasak> I'll try to remember to look later
[16:57] <ahasenack> teward: I tend to agree. The main argument being, I think, that if you changed your system to completely disable ipv6, at the OS level, then you should also take care of individual configuration changes that are needed per service
[16:58] <teward> rbasak: no problem, it's not SRUable in my opinion and because of how dpkg handles config files files would not get overwritten by default.
[16:58] <teward> just wanting to check my brain here :)
[16:58] <ahasenack> because this could be surprising in the other way around too: you want ipv6 enabled, you have configured a listen directive for it, then for reasons outside your control suddenly ipv6 is disabled and your site is not reachable via that protocol anymore
[16:58] <teward> ahasenack: that's also my opinion.  we could comment out the v6 line for Eoan+ but not get that backports.
[16:58] <ahasenack> nginx not starting up is a valid failure mode
[16:58] <teward> yep
[16:58] <teward> and we even have that in the config if port 80 is already bound to
[16:58] <teward> at least, in later
[16:58] <teward> later NGINX versions in Ubuntu*
[19:46] <axisys> tcpdump on port 443 shows packets coming, openssl s_client -connect remote:443 gets certificate , but netstat -tunlp | grep 443 shows only port 8443 .. what is tied to port 443 ?
[19:46] <axisys> https://remote takes me to the site
[19:47] <tds> axisys: just to check, you're running that netstat command on "remote"?
[19:48] <tds> either way, I'd check for iptables rules, port 443 may be redirected to a different local port
[19:48] <axisys> yes running on remote :-)
[19:49] <axisys> tds: ah.. that was it
[19:49] <axisys> tds: -A PREROUTING -p tcp -m tcp --dport 443 -j DNAT --to-destination <IP_ADDRESS>:8443
[19:49] <axisys> tds: thank you


[06:45] <jphilips> bluesabre, pleia2, knome: tried to upload an image to the website and getting an HTTP error.
[06:45] <jphilips> https://imgur.com/mqF0b9F.png
[06:46] <jphilips> https://imgur.com/GD64L8M.png
[07:21] <Unit193> bluesabre: I guess if it's not too late we might want to grab the new thunar?
[08:48] <jphilips> testing week announcement - https://xubuntu.org/news/xubuntu-21-04-testing-week/
[09:51] -SwissBot:#xubuntu-devel- ATTN: Xubuntu Core 21.04 - amd64 - amd64 built.
[11:12] <bluesabre> Unit193: yeah!
[16:13] <pleia2> jphilips: if you're still having trouble, submit a ticket with<EMAIL_ADDRESS>and ask for help in #canonical-sysadmin
[16:13] <pleia2> (alas, they maintain the install, not us)
[16:51] <pleia2> jphilips: make sure you give them the RT ticket number, they need that for their work queue
[16:51] <pleia2> (they can't just help via IRC, they need a ticket)
[16:53] <jphilips> pleia2: oh okay will do
[20:37] <Unit193> pleia2: I hate to jump on your re-join, but would I be able to assist upgrading the xubuntu-dev server?
[20:40] <pleia2> Unit193: ok, I have a work call in 20 minutes, but if all goes well I can do the upgrade after that
[20:41] <Unit193> Oh, well that was quick!  Hope the call isn't too terrible. :)
[20:58] <Unit193> jphilips: Have you done a lot of ISO tests?
[21:03] <jphilips> Unit193: i've done a bit and we have a few testers in the telegram group who are doing testing.
[21:03] <Unit193> Ever run across grub installation bugs, https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bugs?field.searchtext=grub&orderby=-id ?
[21:04] <Unit193> My main tester for Xubuntu Core has been hit by this for some time now, it seems some others (might?) not have this issue, so it's maybe intermittent.  But I've not actually heard of a confirmed successful install.
[21:16] <jphilips> never had a grub installation bug before, though i think 20.04.2 did have such a bug, which is why they released <IP_ADDRESS>
[21:18] <Unit193> Heh, LP 1920684 even mentions specifically Xubuntu.
[21:18] <ubot3> Launchpad bug 1920684 in ubiquity (Ubuntu) "Grub could not be updated during install of xubuntu" [Undecided, New] https://launchpad.net/bugs/1920684
[21:20] <jphilips> i remember hearing about this - https://www.explorelinux.com/grub-install-fatal-error-during-installing-ubuntu-20-10-to-usb-drive/
[21:29] <jphilips> this seems identical to that bug - https://askubuntu.com/questions/1311137/ubuntu-20-10-installer-not-seeing-existing-windows-10-installation
[21:29] <jphilips> doubt any grub issue would be xubuntu specific
[21:29] <Unit193> Most certainly not.  Would you like to try a current Core image to see if you also hit it?
[21:30] <jphilips> saw a notice on irc today that the latest build of core was out, so why not
[21:34] <jphilips> will ask the xubuntu testers to also give it a go
[21:41] <jphilips> when i'm using zsync to download the iso, i'm getting this error https://imgur.com/yuoWlAM.png
[21:42] <jphilips> is `zsync https://unit193.net/xubuntu/core/pending/xubuntu-21.04-core-amd64.iso.zsync` not sufficient
[21:43] <Unit193> zsync can't handle https.
[21:43] <Unit193> Debian #459706
[21:43] <ubot3> Debian bug 459706 in zsync "zsync can not download from HTTPS" [Minor, Open] https://bugs.debian.org/459706
[21:43] <jphilips> so how to use the .zsync file
[21:44] <Unit193> Either use http: or don't use zsync, basically.
[21:44] <jphilips> thanks
[21:44] <Unit193> https://sourceforge.net/p/zsync/mailman/zsync-users/ dang, that's pretty dang dead..
[21:58] <Unit193> pleia2: FWIW, I pulled in the openssl update and restarted affected services.


[02:13] <ScottK> NCommander: Need some help on qt4-x11 on powerpc.
[02:14] <ScottK> NCommander: slangasek figured a work-around for the ld segfault, we just need some help figuring out how to mangle the .pro files to make it apply to powerpc.
[02:35] <crypt-0> is lucid stable enough to test yet?
[02:35] <crypt-0> in other words, is it worth in install , without having to hack the rest together?
[02:36] <crimsun> WFM; YMMV
[04:57]  * hyperair just realized that file-roller doesn't seem to have been merged/synced from debian for a long time. is there a reason for that?
[04:58] <ScottK> Most likely no one did it.
[04:58] <hyperair> it doesn't appear in merges.ubuntu.com either
[04:58] <StevenK> hyperair: We have our version of it
[04:58] <hyperair> and all the file-roller changelog entries are -0ubuntu1
[04:59] <StevenK> hyperair: IE, we handle the packaging of it, and don't want to use Debian's packaging
[04:59] <hyperair> ah i see
[05:04] <DaskreeCh> Hello
[05:05] <DaskreeCh> Does anyone have any insight as to why do-release-upgrade would fail with no new release found on Jaunty at this time ?
[07:01] <StevenK> didrocks: Hm. In the ubuntu-netbook-remix-default-settings postrm: if [ ! -d /var/lib/gconf/une.mandatory ]; then rm -rf /var/lib/gconf/une.mandatory ; fi
[07:01] <StevenK> didrocks: Isn't that test backwards, and should be if [ -d ?
[07:05] <pitti> Good morning
[07:06] <StevenK> Morning pitti!
[07:06] <pitti> hey StevenK
[07:06] <pitti> hm, a weekend and no pings in scrollback? must be Christmas..
[07:24] <StevenK> pitti: Haha!
[07:34] <jmarsden> pitti: Thanks for your help getting the fix for bug #223281 into Karmic... how do we now get it into Lucid?  Officially it should have gone into Lucid first, but that doesn't seem to have happened in this case?  Or am I just confused?
[07:36] <pitti> jmarsden: erm, it is? see comment 37, and hte lucid task is closed
[07:36] <pitti> $ LANG=en_AG python2.6 -c "import locale ; print locale.getdefaultlocale()"
[07:36] <pitti> ('en_AG', None)
[07:36] <pitti> ^ on lucid
[07:36] <pitti> I tested that when I sponsored
[07:38] <jmarsden> OK, I missed that comment.  I read comment #36 and didn't realize you'd been able to get the patch to work in Lucid OK.  Cool.
[08:32] <dholbach> good morning
[09:25] <geser> james_w: I trying to merge "dictionaries-common" the bzr way: bzr branch lp:ubuntu/lucid/dictionaries-common, bzr merge-package lp:debian/squeeze/dictionaries-common but I get "bzr: ERROR: No such tag: upstream-1.4.0". Did I something wrong or is this because it's a native package?
[09:37] <james_w> geser: merge-package is currently broken with native packages, you can use "bzr merge" until it is fixed.
[09:39] <geser> james_w: thanks, this worked
[10:34] <Riddell> pitti: kubuntu-dev approved Lure to for a per-package upload for digikam and kdegraphics, are you able to add those permissions for him?
[10:34] <pitti> Riddell: technically yes, but formally this has to be run by DMB
[10:35] <pitti> (since these packages are in main)
[10:36] <pitti> I agree that this is a bit weird, since you could give him even more permissions by adding him to kubuntu-dev without getting DMB ack
[10:36] <Riddell> pitti: we weren't clear if we were empowered to do such things but since the packages are within the list of kubuntu-dev it would seem daft if we couldn't approve for a subset of kubuntu-dev
[10:36] <pitti> so eventually this policy needs to be cleaned up wrt. existing delegations
[10:37] <Riddell> pitti: how do I contact the DMB then?
[10:38] <pitti> Riddell<EMAIL_ADDRESS>[10:38] <pitti> in that thread we should also discuss a general policy change for this delegation case
[10:38] <pitti> seems silly right now
[10:58] <Keybuk> slangasek: I'm not sure why you've marked "migrate apparmor to Upstart" as DONE when there's still clearly an init script
[11:11] <cjwatson> james_w: is there a standard way of importing just an upstream release tarball, given the upstream branch on which it's based?
[11:12] <james_w> cjwatson: "just" ?
[11:12] <cjwatson> well, I don't want to do a merge as well, like merge-upstream does - I just want the import step
[11:13] <james_w> there's no way currently
[11:13] <james_w> from the CLI at least
[11:14] <pitti> oh, how does it figure out the release tarball from just a branch? doesn't that require a watch file?
[11:14] <cjwatson> ok, so I guess I just unpack, 'bzr add --file-ids-from path-to-other-branch', and commit
[11:16] <cjwatson> pitti: in my case I'm talking about a manual operation for a package natively maintained in bzr
[11:16] <pitti> ah
[11:16] <cjwatson> I just imported openssh's CVS history :)
[11:16] <cjwatson> and glued it into the upstream import
[11:50] <crimsun> Would an archive admin please reject karmic-proposed's alsa-lib_1.0.20-3ubuntu6.1? I'm reworking the SRU debdiff based on a newer patch by upstream (based on my submitted patch).
[11:54] <pitti> crimsun: done
[12:06] <crimsun> pitti: thanks. SRU proposal updated and uploaded.
[12:25] <mathiaz> what's the CLI version to add a ppa to the sources.list?
[12:28] <ion> add-apt-repository ppa:foo IIRC
[12:30] <mathiaz> ion: great - thanks
[12:32] <ion> keybuk: https://code.edge.launchpad.net/~ion/ubuntu/lucid/mountall/lucid but unfortunately i’m unable to make a bootchart with this change, since plymouth just cancels any fscks in my VM.
[12:41] <Keybuk> how does plymouth cancel fscks?
[12:43] <Keybuk> (merged)
[12:44] <ion> keybuk: I haven’t investigated it any further, but plymouth seems unable to display aything, and whenever mountall starts a fsck, it gets cancelled immediately.
[12:44] <ion> I assumed it’s due to the user interaction code thinking the user pressed esc or somethig.
[12:47] <apw> pitti, you about?  wondering if you/anyone knows where the base corelimit is set
[12:49] <Keybuk> ion: possibly, am working on that code today a bit
[12:49] <apw> Keybuk, ion?
[12:49] <Keybuk> apw: comes from the kernel, overridden by upstart "limit core" (if any), overridden by PAM /etc/security/limits.conf (if set), overridden by bash, etc.
[12:50] <apw> ahh... a person :)
[12:50] <Keybuk> I think it basically ends up 0 all the way down
[12:50] <apw> Keybuk, so where would i find limit core, in .conf files for upstart yes?
[12:51] <Keybuk> apw: I don't think we override it anywhere
[12:51] <apw> ok so it must be 0 in the kernel then
[13:01] <apw> Keybuk, ok if i needed to set rlimit core to 1 for 'everything' is that easy in upstart
[13:07] <pitti> meh, gdm still fails to start
[13:07] <Keybuk> apw: -1 you mean?
[13:07] <Keybuk> no, it's not easy
[13:07] <Keybuk> unless you want to patch the kernel? :p
[13:07] <apw> no i mean 1
[13:07] <pitti> it seems gdm and KMS start around the same time, and both lose
[13:07] <pitti> apw: it should be 0 by default, shouldn't it?
[13:08] <Keybuk> 1 is a tiny core limit?
[13:08] <pitti> apw: you can override it in /etc/security/limits.conf
[13:08] <pitti> it's 0 by default (as it should be)
[13:08] <Keybuk> apw: what are you trying to do?
[13:09] <apw> pitti, well yes and no, a new mechanism to handle detect recursive core dumping by the core dump pipe process has changed the semantics of 0 for that case
[13:09] <apw> in that i really does mean no dump ... any other value means infinity with pipe
[13:09] <pitti> ah, so that was it
[13:09] <apw> yep
[13:09] <Keybuk> apw: if something in the kernel has changed what the default should be, change the kernel default to match ?
[13:09] <apw> so one option would be to use 1
[13:10] <apw> Keybuk, the default is what its meant to be.  no core.
[13:10] <apw> just the meaning in the face of pipe has changed
[13:10] <pitti> apw: 1 would mean 0 for all practical cases, but enable pipe again?
[13:10] <Keybuk> apw: then the default throughout the system will also be "no core", right?
[13:11] <Keybuk> since ulimit -c in my shell says "unlimited", something must be setting it to -1
[13:11] <apw> pitti, my testing of that says so yes
[13:11] <Keybuk> (apparently my own .zshrc :p)
[13:11] <apw> Keybuk, its returning 0 for me
[13:11] <Keybuk> right
 it's 0 by default (as it should be)
 Keybuk, the default is what its meant to be.  no core.
[13:12] <Keybuk> ...
[13:12] <Keybuk> so we're all on the same page here?
[13:12] <Keybuk> the default is 0 (no core), and we all think it should be?
[13:12] <pitti> ack
[13:12] <apw> basically we want no core without apport, and a core with apport right?
[13:12] <pitti> well, I don't particularly care about the exact value 0
[13:12] <apw> and we are using the way 0 worked to get that
[13:12] <pitti> just to not clutter the fs with core files by default
[13:12] <Keybuk> right, that is my understanding
[13:12] <Keybuk> no core files, but yes to core pipes
[13:13] <apw> right ... so i think a dirty fix would be to have the default be 1
[13:13] <pitti> that's what Neil Hormann recommended, too
[13:13] <pitti> (thanks for digging out that commit)
[13:13] <Keybuk> sounds reasonable
[13:13] <apw> i do like the safety aspect of the 0 == die on recursion
[13:13] <Keybuk> so where the kernel sets 0 as the default, change that to 1
[13:13] <apw> so if we are happy 1 is good, we have to decide how to set it for us
[13:14] <apw> well if its easy to change it in /etc/security/limits.conf that would be lower impact
[13:14] <Keybuk> apw: that won't work
[13:14] <apw> (on me) :)
[13:14] <Keybuk> for a start, PAM is not used for system daemons
[13:14] <Keybuk> so those would still have 0
[13:14] <pitti> that wouldn't catch early boot and daemons, though
[13:14] <pitti> right
[13:14] <Keybuk> you could set it in upstart, but that's a hacky code change to work around the fact we don't have the source to our kernel
[13:14] <Keybuk> (which we do)
[13:14] <Keybuk> you could set it in the initramfs, but then anyone not using an initramfs would have 0
[13:14] <apw> does apport start early enough to get cores there?
[13:15] <Keybuk> really, set it in the kernel ;P
[13:15] <Keybuk> apw: it doesn't matter when apport starts; apport isn't inherited
[13:15] <Keybuk> apport is either on or off
[13:15] <Keybuk> if you start a system daemon, then start apport, cores go to appor
[13:15] <Keybuk> +t
[13:15] <apw> fair
[13:15] <Keybuk> also, I'd point out that any point you're trying to do this in the boot sequence is adding at least one syscall to our boot ;)
[13:16] <Keybuk> maybe even an entire shell script
[13:16] <Keybuk> etc.
[13:16] <Keybuk> just to work around changing a default in the kernel :P
[13:16] <apw> heh all changes have risk, specially where noone has added an option for it (sadly)
[13:28] <dholbach> who can I interest in giving a session at UDW? https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep
[13:36] <tseliot> pitti: are there any plans to change ia32-libs in lucid? I think I heard something about it but I'm not sure
[13:37] <pitti> tseliot: foundations is working on a real multiarch implementation, but right now I don't know whether that will land soon enough
[13:38] <tseliot> pitti: ah, ok. I asked as I need to use alternatives in ia32-libs too. I think I'll just modify that package until a different solution is found
[13:54] <sgallagh> mathiaz: ping
[13:54] <mathiaz> sgallagh: hi!
[13:55] <mathiaz> sgallagh: I noticed sssd 1.0 had been released.
[13:55] <sgallagh> mathiaz: Long time no see. How was your vacation? :)
[13:55] <mathiaz> sgallagh: great! thanks :)
[13:55] <sgallagh> mathiaz: I was trying to reach you last week to get a build done of the pre-release code to make sure nothing was broken for you, but you were away and I didn't know who was filling in.
[13:56] <sgallagh> So hopefully 1.0.0 doesn't break anything for you, but we can work out a patch if needed.
[13:56] <mathiaz> sgallagh: right - that's ok. I may have some more spare cycle in the new year to make sure things are all good for 1.0.0
[13:56] <mathiaz> sgallagh: I'll let you know if I run into some issues with 1.0
[13:57] <sgallagh> mathiaz: Please do.
[13:57] <sgallagh> mathiaz: I also wanted to know: did you ever build either of the pre-releases (0.99.0 and 0.99.1)? Because we discovered a security bug in them.
[13:57] <sgallagh> (It's fixed in 1.0.0)
[13:57] <mathiaz> sgallagh: nope
[13:57] <sgallagh> mathiaz: ok, great
[13:58] <sgallagh> The bug wasn't present in 0.7.1 or earlier, so Karmic is probably safe.
[13:58] <mathiaz> sgallagh: good to know
[14:25] <Keybuk> tseliot, ion: did you notice that plymouth starts on the wrong VT>
[14:27] <tseliot> Keybuk: no, as I haven't used Lucid for a while. Does it start on vt1?
[14:27] <Keybuk> well
[14:27] <Keybuk> that's the funny thing
[14:27] <ion> I haven’t really got around to looking at plymouth yet.
[14:27] <Keybuk> it switches to vt7
[14:27] <Keybuk> but then appears on vt1
[14:27] <Keybuk> I think this is why the input is screwed up
[14:27] <Keybuk> and think this is why the X transition is screwed up
[14:27] <ion> Ah
[14:29] <tseliot> Keybuk: does this happen only on boot?
[14:29] <Keybuk> no
[14:29] <Keybuk> start plymouth on the console does it too
[14:29] <Keybuk> (assuming X isn't running :p)
[14:29] <Keybuk> it ends up over your current VT
[14:31] <tseliot> hopefully gdb will help us see what's grabbing vt1
[14:31]  * Keybuk gets karmic deja-vu
[14:31] <Keybuk> debugging filesystem progress notification results in debugging the splash screen
[14:32] <tseliot> :-/
[14:32] <Keybuk> it's all good really
[14:32] <Keybuk> it all needs debugging
[14:32] <Keybuk> and at least it's not usplash :p
[14:33] <tseliot> heh
[14:33] <ion> :-)
[14:33] <Keybuk> I made mountall not depend on plymouth anyway
[14:34] <Keybuk> if plymouth isn't running, it pretends that the broken filesystem had "nobootwait" in it :p
[14:35] <tseliot> I'll have more time to spend on plymouth as soon as I'm done with nvidia
[14:35]  * tseliot -> doctor
[15:24] <smoser> anyone have an update to date archive mirror that they can 'du -sm' for me ? i'm just mirroring and want to see what I'm shooting for. currently i've got 268332
[15:24] <smoser> i think i've got to be close
[15:27] <smoser> Keybuk, i think you mentioned a way once to  me that I could ensure that I ran before a given upstart job.
[15:28] <smoser> explicitly, I want to ensure that I run before rc-sysinit.conf
[15:28] <Keybuk> on starting rc-sysinit ?
[15:29] <cwillu_at_work> incidently:  gdm doesn't start after booting in recovery mode and selecting 'continue normal boot';  one has to run gdm-binary by hand
[15:41] <Keybuk> ion: try current mountall
[15:41] <Keybuk> (trunk)
[15:42] <jpds> smoser: http://www.mirrorservice.org/sites/archive.ubuntu.com/ubuntu/
[15:53] <slangasek> Keybuk: because I can never keep apparmor and apport straight
[15:53] <slangasek> even between one terminal window and the next
[15:53] <ebroder> slangasek: Really? It's easy - one of them reports bugs, and the other one creates bugs
[15:55] <ejat> anyone know how to clean/delete previous conversation in empathy ?
[15:58] <ScottK> pitti: Would you please rescore gcc-4.4 on ia64 down to 2000?  We're about to upload a complete KDE release and we'll have fewer failures/retries later if it doesn't get blocked behind gcc.
[16:02] <pitti> ScottK: done
[16:03] <ScottK> pitti: Thanks.
[16:05] <ion> keybuk: http://heh.fi/tmp/mountall/
[16:06] <ion> keybuk: The prioritization seems to work fine with plain ioprio_set.
[16:06] <smoser> Keybuk, so right now, rc-sysinit.conf is "filesystem and net-device-up IFACE=lo"
[16:06] <ion> keybuk: I wonder why mountall uses so much CPU at the end?
[16:07] <smoser> in the end (maybe this works now) I want my script to be "(mounted MOUNTPOINT=/ and net-device-up IFACE=eth0)"
[16:07] <smoser> but for now, i have "(local-filesystems and net-device-up IFACE=eth0)"
[16:07] <Keybuk> smoser: your script will *halt* filesystem mounting and stuff until it finishes
[16:07] <Keybuk> you know that, right? :p
[16:07] <smoser> i want to some how say "make sure this runs before the rc-sysvinit"
[16:07] <Keybuk> don't look at the rc-sysinit.conf
[16:07] <Keybuk> because it's broken
[16:08] <smoser> Keybuk, right. i know it will do that.
[16:08] <smoser> ok, so i see that if i run early and block i will obviously run before sysvinit
[16:08] <Keybuk> ion: probably parsing the fsck -C output and handing it to mountall
[16:09] <smoser> but is there a way to genericlly, from one script say "i have to run before another"
[16:09] <Keybuk> smoser: no
[16:09] <smoser> right now i'm trying to debug, i want to insert a script that runs before anothe rone
[16:09] <Keybuk> smoser: you can say "I have to run when another is started", but that's quite, quite different
[16:09] <smoser> oh, i guess i can just do on starting for that
[16:09] <smoser> riht
[16:09] <smoser> right
[16:09] <smoser> so i think on starting is sufficient for what i need right now.
[16:11] <ion> keybuk: http://heh.fi/tmp/mountall/hot-host-cache.png mountall’s highest CPU usage seems to be at the end, with no apparent correlation with fscks.
[16:11] <ion> keybuk: http://heh.fi/tmp/mountall/cold-host-cache.png as well
[16:12] <ttx> pitti: I'll need your help to trigger a server Cd respin, whenever amd64 gets built at https://launchpad.net/ubuntu/lucid/+source/eucalyptus/1.6.2~bzr1103-0ubuntu3
[16:13] <Keybuk> I don't see that here atm
[16:14] <ion> keybuk: Dunno whether running under VirtualBox screws with the graphs, though.
[16:16] <pitti> ttx: bumped build score for now
[16:16] <ejat> anyone know how to clean/delete previous conversation in empathy ?
[16:16] <pitti> ttx: please ping me when it's published, then I'll trigger a rebuild of the CD
[16:16] <ttx> pitti: will do , thanks
[16:19] <smoser> Keybuk, sorry to keep pestering you, but you keep answering :).  one more question.  If i want to run at "old school 'rc.local'" what would you recommend for implementing that
[16:23] <Keybuk> on stopped rc RUNLEVEL=[2345]
[16:29] <mathiaz> Keybuk: can you generate an upstart event with additional data? Ex: cloud-yaml-config CFGFILE=/etc/cloud/config.yaml ?
[16:29] <Keybuk> yes
[16:30] <mathiaz> Keybuk: so that upstart jobs that start on cloud-yaml-config would have access to CFGFILE?
[16:30] <Keybuk> yes
[16:30] <mathiaz> smoser: ^^
[16:30] <mathiaz> Keybuk: awesome thanks
[16:31] <ScottK> pitti: Would you also reduce the score on openjdk-7 from doko's toolchain PPA to ~2000 on IA64 only (for the same reason).
[16:32] <smoser> mathiaz, that is good, yeah. so i think that is important to pass that from the event.
[16:32] <tseliot> Keybuk:  do you get a ply_trace ("deactivating on vt change") if you enable tracing and reproduce the bug in plymouth?
[16:33] <doko> ScottK: no need, will fail after unpack
[16:33] <ScottK> doko: Thanks.  pitti: Nevermind.
[16:33] <pitti> o
[16:33] <pitti> k
[16:33] <Keybuk> tseliot: haven't tried
[16:34] <tseliot> Keybuk: that would be a way to see when it switches vt and maybe track down the issue
[16:35] <Keybuk> problem is that all the tracing output mucks up the output ;)
[16:35] <Keybuk> so you can't tell whether it's working or not
[16:36] <tseliot> the tracing output go into a file
[16:36] <tseliot> (in theory)
[16:39] <Keybuk> yeah, there's lots of "theory" here ;)
[16:39] <Keybuk> I figured out why all fscks get cancelled with plymouth running
[16:39] <Keybuk> plymouth sends garbage back repeatedly when you use watch keystroke
[16:42] <smoser> Keybuk, i think i read somewhere that at some point you expect 'script' section to allow for interpreters other than 'sh -e' is that correct?
[16:42] <smoser> if so, how reasonable is that that that would happen in lucid
[16:43] <smoser> wait, maybe its not that bad to live with out it.
[16:43] <Keybuk> no, it won't happen in lucid
[16:43] <Keybuk> I haven't decided it's definitely going to happen yet
[16:44] <smoser> Keybuk, so you take the 'script' section put it in a file, and then 'sh -e file' ?
[16:44] <smoser> is that right?
[16:46] <Keybuk> no, but close enough
[16:47] <tseliot> Keybuk: garbage? Maybe vt related?
[16:47] <Keybuk> tseliot: I'm thinking that this whole plymouth goes on the wrong vt is our fundamental problem
[16:47] <Keybuk> it'd explain why fedora don't see it (they like it on vt 1 :p)
[16:47] <Keybuk> if VT7 is in KD_GRAPHICS but VT1 is in KD_TEXT
[16:47] <Keybuk> and plymouth is scanning out its fb to VT1
[16:47] <smoser> Keybuk, i dont understand why you wouldn't implement it. it seems like a lot of bang for a very small amoutn of buck
[16:48] <Keybuk> it'd explain why fbcon scans over the top
[16:48] <Keybuk> it'd explain why input is fu'd
[16:48] <Keybuk> it'd explain why our X transition screws up (there's a VT switch in there <g>)
[16:48] <smoser> but i guess its fairliy easy to work around at the moment:
[16:48] <smoser> http://paste.ubuntu.com/344173/
[16:48] <Keybuk> smoser: because, for example in that case, Upstart now needs to worry about whether /usr is mounted <g>
[16:49] <smoser> upstart doesn't need to worry about that
[16:49] <Keybuk> both most commonly requested "other" interpreters are on /usr
[16:49] <Keybuk> upstart needs to care about them failing
[16:49] <smoser> any more than it needs to worry that the users shell script is not terribly bogus
[16:49] <smoser> not its job
[16:49] <Keybuk> also because I think writing jobs in anything other than shell is probably wrong
[16:49] <Keybuk> thinking of all the hassles of allowing maintainer scripts to be written in other languages
[16:49] <Keybuk> (it'd slow down boot for a start <g>)
[16:50] <smoser> Keybuk, it could also speed up boot
[16:50] <Keybuk> how does starting the entire python interpreter "speed up" boot? :p
[16:50] <Keybuk> python is enormous
[16:51] <smoser> because bin/sh scripts will typically fork loads of times to do something that could be done in perl., python, <insert interpreter here> without forking
[16:51] <smoser> and insert-interpreter-here isn't necissairly slow
[16:51] <superm1> Keybuk, is there a particular reason not to switch to VT1 by default in Ubuntu though?
[16:52] <Keybuk> superm1: cjwatson and slangasek don't want to :)
[16:52] <robbiew_> heh
[16:52]  * cjwatson doesn't want to be hunting and destroying old documentation for the rest of his life when there's no real need to
[16:53] <smoser> i personally dont think that that is the right place to enforce policy of "write maintainer scripts in /bin/sh" or "write startup scripts so they are fast"
[16:54] <Keybuk> smoser: noted
[16:54] <smoser> thanks
[16:54] <smoser> :)
[16:55] <ttx> pitti: I'm about to stop for dinner and the amd64 build is still going to start in "1 minute"... will you be around this evening, and if not, could you set up a magic trigger ?
[16:57] <pitti> ttx: slangasek has a magic trigger for this; slangasek, here by chance? would you mind passing your script which triggers a CD build when a particular package is published?
[16:59] <ttx> pitti: steve should be around later, I'll check the build in a few hours and ask him to trigger if necessary
[16:59] <ttx> pitti: worse case scenario, we'll trigger it tomorrow morning before taking coffee :)
[17:00] <pitti> ttx: I'm off for dinner now, too, but I'll be around until 1930 CET
[17:00] <ttx> pitti: ok
[17:22]  * mpt wonders if we have a FTRFB (Fails to Run From Binary) to go with our FTBFS
[17:40] <slangasek> pitti: better would be if I finally factor that trigger out into a script...
[17:46] <slangasek> Keybuk: where's the evidence that bug #497299 is linked to bug #447654?  The submitter of this bug had a broken interfaces file, that's hardly related.
[17:47] <slangasek> Keybuk: and there's no 'instance' here, so from your earlier description, this doesn't fit the and+or problem
[17:49] <Keybuk> slangasek: it's still the same problem
[17:49] <slangasek> how?
[17:49] <Keybuk> because you block ifup from finishing until filesystems are mounted
[17:49] <Keybuk> which means if you have anything requiring a network interface to mount filesystems
[17:49] <Keybuk> like
[17:49] <Keybuk> say
[17:49] <Keybuk> NFS
[17:49] <Keybuk> you're going to fuck them
[17:51] <slangasek> Keybuk: ah; I don't see why you would lump that in with bug #447654, but I think that problem can (and should) be addressed by making /etc/network/if-up.d/upstart use --no-wait ?
[17:51] <Keybuk> slangasek: that would be a bug for different reasons
[17:51] <Keybuk> we have things (EC2 for example) *relying* on the fact that it's not --no-wait
[17:51] <slangasek> howso?
[17:52] <Keybuk> how about you stop rushing to fix things in a blind panic ?
[17:52] <Keybuk> I was deliberately not fixing that bug for a reason
[17:52] <Keybuk> because all of the ways I could think of were worse
[17:53] <slangasek> you mean the bug that was brought up as part of a session at UDS, and that you and I subsequently discussed on IRC?
[17:53] <slangasek> that's "a blind panic"?
[17:53] <Keybuk> yes, and I kept saying that there were bad things that could happen with it
[17:53] <Keybuk> and then you uploaded a "fix" anyway
[17:53] <Keybuk> you must have figured that there was _some_ reason I was holding back?
[17:54] <slangasek> 08-12-2009 12:10:24 <<EMAIL_ADDRESS>why not add "and net-device-up IFACE=lo" to the rc-sysinit.conf file ?
[17:54] <slangasek> that doesn't look like "holding back" to me
[17:55] <Keybuk> it was a suggestion for testing
[17:55] <Keybuk> not a "go ahead and upload as an SRU"
[17:55] <Keybuk> now I've had more than 6s to think about it, it's clearly wrong
[17:56] <slangasek> how and why does EC2 rely on ifup being synchronous?
[17:56] <Keybuk> slangasek: because it does
[17:56] <Keybuk> and I want that net-device-up to be synchronous
[17:56] <slangasek> great, thanks for the insight
[17:57] <Keybuk> oh, sorry
[17:57] <Keybuk> you're quite right
[17:57] <Keybuk> I should drop everything I'm doing right now and explain to you how everything works
[17:57] <elmo> jeez, guys, chill out
[18:08] <tseliot> Keybuk: would a kernel patch to start on tty7 help (or hurt :-P )?
[18:08] <Keybuk> tseliot: it's not that
[18:08] <Keybuk> because the current vt looks a bit like 7
[18:08] <Keybuk> it's a bit more strange
[18:08] <tseliot> ?
[18:08] <Keybuk> I don't know how to describe the behaviour I'm seeing
[18:09] <Keybuk> because it doesn't make rational sense
[18:10] <tseliot> because it keeps switching to vt1?
[18:10]  * tseliot scratches head
[18:11] <Keybuk> right
[18:11] <Keybuk> I can watch it switch to vt7
[18:11] <Keybuk> and then, it's like it gets there
[18:11] <Keybuk> and all is fine
[18:12] <Keybuk> but it's on vt1
[18:12] <Keybuk> it's like vt7 becomes a magic portal to vt1
[18:12] <Keybuk> or something
[18:12] <Keybuk> very weird
[18:13] <tseliot> can it be that it copies the content of vt7 to vt1 and then switches to vt1?
[18:15] <Keybuk> in effect, I think that's what's happening
[18:15] <Keybuk> but I think it's more at the drm/fb layer
[18:15] <Keybuk> like it's on VT7, but scans out the framebuffer for vt1
[18:16] <Keybuk> which the kernel lets happen
[18:16] <Keybuk> (but probably shouldn't have)
[18:16] <Keybuk> so the first framebuffer scan out partially switches vt
[18:20] <tseliot> yes, of course I was referring to the drm stuff
[18:20] <Keybuk> and then you end up in an odd situation
[18:20] <Keybuk> where /dev/console is pointed at tty7
[18:20] <Keybuk> but the framebuffer is being scanned out to vt1
[18:20] <Keybuk> and that framebuffer is going onto the screen
[18:21] <Keybuk> which means you're in KD_TEXT on that vt, not KD_GRAPHICS
[18:21] <Keybuk> which is why fbcon can spam over the top
[18:21] <Keybuk> and in order to start X, you need a VT switch
[18:21] <Keybuk> which is why we don't get the smooth transition without scanning out to fbcon too
[18:21] <Keybuk> etc.
[18:21] <Keybuk> that's my best guess
[18:25] <ebroder> Can I talk any ubuntu-sru types into looking at bug #497606?
[18:27] <Keybuk> slangasek: right, so...
[18:27] <Keybuk> you know that events in upstart have both a start and a completion, right.
[18:27] <Keybuk> ?
[18:28] <tseliot> Keybuk: yes, I think that's more or less what's happening. I'll have another look at the drm code
[18:31] <slangasek> Keybuk: yes
[18:31] <Keybuk> slangasek: everything reacts to the start of the event, so if you have lots of jobs that say "start on foo" - then they all get that kick at the same time
[18:31] <Keybuk> the completion of the event doesn't happen until everything that was kicked is either started (services) or finished (tasks)
[18:32] <Keybuk> completion only matters to the process that emitted the event
[18:32] <slangasek> Keybuk: did you read my comment on bug #493480 before assigning it back again, or are you just playing bug pong?
[18:33] <Keybuk> slangasek: I put it on my procmail file that reassigns bugs back to where they came from
[18:33] <slangasek> Keybuk: where do I file bug reports against your buggy procmail file?
[18:33] <qense> pitti: do you think that bug 229370 could be related to bug 463347 or maybe bug 469837? I reckon it probably is somewhere in devicekit-disks, but I'm not sure if it is a duplicate of an already reported bug.
[18:33] <Keybuk> if it's an encrypted /tmp, it's a cryptsetup bug
[18:33] <lamont> xchat srsly reads its logs 1 character per read() call??? WTF???
[18:33] <slangasek> Keybuk: read the bug.
[18:33] <Keybuk> since /tmp on anything else works just fine
[18:33] <qense> I do find many ancient bug reports with similar symptoms as 229370, but they were fixed in GNOME 2.14. :S
[18:34] <Keybuk> there's no proof in the bug that it has anything to do with mountall
[18:34] <Keybuk> now, do you want to talk about that, or why the rc-sysinit job doesn't work?
[18:38] <pitti> qense: 469837 could potentially be a dupe of 463347; the fstab issue (229370) doesn't sound like a plausible duplicate
[18:38]  * pitti waves goodbye
[18:39] <qense> pitti: OK, in that case I'll do some further investigating. thanks!
[18:48] <Keybuk> slangasek: followed up on bug #493480
[18:49] <Keybuk> I think that udev is told about the device before cryptsetup calls mke2fs, and cryptsetup never follows up with a change event
[18:59] <ScottK> pitti: Would you please rescore kde4libs to 1900.  I need to give the other KDE packages a chance to depwait before it builds.
[19:02] <ScottK> Or even lower maybe
[19:45] <ebroder> What's Ubuntu's stance on 4-clause BSD licenses?
[19:46] <ebroder> Can a package with one still end up in main/universe?
[19:47] <cjwatson> they're free, they're just GPL-incompatible
[19:48] <ebroder> Ok. Do you need an explicit ACK for syncing a new package non-free -> universe, or will it just happen eventually?
[19:50] <slangasek> ebroder: er, Debian's stance of 4-clause BSD isn't different; why is the package in non-free?
[19:50] <ebroder> Yeah, I just realized that. -> back to the copyright file
[19:51] <ebroder> http://tinyurl.com/yznfcrz if anybody else wants to help me search :)
[19:53] <ebroder> Oh - I see. There's some stuff that doesn't have a license specified
[19:53] <ebroder> multiverse it is, I think
[19:53] <cjwatson> and to answer your question, non-free -> multiverse by default
[19:55] <ScottK> pitti: Nevermind (FTBFS anyway)
[20:37] <stgraber> hey, I'm just wondering, in the hal-less world, how does one get an equivalent of lshal (as in, get every piece of detected hardware for parsing purpose) or hal-get-property (for example to know the main video controler) ?
[20:37] <stgraber> I'm currently transitioning LTSP out of hal but have some scripts here and there that'd need porting
[20:38] <stgraber> (also, I've been using lshal to store hardware inventory in a standard/parsable way, I'd love to replace that with something offering similar information)
[20:50] <ttx> slangasek: could you trigger a server ISO respin ?
[20:55] <slangasek> ttx: server?
[20:56] <ttx> slangasek: yes
[20:56] <slangasek> ttx: running
[20:56] <ttx> slangasek: thx!
[21:12] <slangasek> ttx: done
[21:58] <slangasek> james_w: ping?
[22:01] <james_w> hi slangasek
[22:08] <slangasek> james_w: hi - were you doing syncs today?  There seems to be a lot of stuff not flushed yet from the queue, and I'm not sure what its status is
[22:08] <james_w> ah
[22:08] <james_w> forgot --flush-syncs
[22:09] <james_w> thanks
[22:22] <slangasek> james_w: ok, cheers :)
[23:04] <kees> are two people doing archive admin work?  I just got rejects for stuff that accepted already?
[23:06] <james_w> the flush seemed to reject all the packages, I'm not sure why
[23:10] <hrocha> hi, i don't know if you can help me with this but i'll try to explain the problem
[23:11] <Keybuk> james_w: around?
[23:11] <Keybuk> lp:ubuntu/ureadahead got deleted! :(
[23:11] <hrocha> i'm trying to install lucid but it fails with a (gksudo:17942): GLib-CRITICAL **: g_str_has_prefix: assertion `str != NULL' failed
[23:11] <james_w> Keybuk: huh?
[23:11] <Keybuk> james_w: it's gone!
[23:11] <Keybuk> lp doesn't show it anymore
[23:11] <hrocha> that happens when i click the "install" button on the last step of ubiquity
[23:11] <james_w> oh
[23:11] <Keybuk> and it was the branch I'd pushed everything to
[23:12] <lifeless> 8 hour i386 build queue :(
[23:12] <cjwatson> hrocha: should be more detail in /var/log/syslog and /var/log/installer/debug
[23:12] <lifeless> Keybuk: I saw the same
[23:12] <hrocha> cjwatson, perfect, thanks, i'll check it out
[23:12] <lifeless> bah. s/keybuk/kees/
[23:13] <cjwatson> hrocha: I'm interested in debugging it
[23:13] <hrocha> cjwatson, me too =)
[23:13] <james_w> Keybuk: it may have been a package that had a bug in the import, so I replaced it
[23:13] <Keybuk> james_w: but there's no branch there at all
[23:13] <Keybuk> and I don't have the history anywhere else!
[23:13] <hrocha> cjwatson, i think the problem is with calling gksudo with no password
[23:13] <hrocha> because if i run gksudo and just press enter it aborts with the same assertion failure
[23:14] <cjwatson> hrocha: I very much doubt it; if the problem were to do with gksudo, it would fail much earlier
[23:14] <cjwatson> hrocha: I think that's likely to be a red herring
[23:14] <kees> lifeless: rhm?
[23:14] <Keybuk> james_w: the branch that was there wasn't an "importer" branch
[23:14] <Keybuk> it was one I push --overwrite'd
[23:14] <Keybuk> like you said to
[23:14] <hrocha> but the assertion of ubiquity says "gksudo"
[23:14] <james_w> really?
[23:14] <Keybuk> really!
[23:14] <Keybuk> I don't suppose there's a backup anywhere?
[23:14] <cjwatson> hrocha: like I say, that's probably a red herring. /var/log/syslog and /var/log/installer/debug should have the real error(s)
[23:15] <hrocha> cjwatson, ok, let me help you
[23:15] <lifeless> kees: rejects and acceps for the same thing
[23:15] <kees> lifeless: ah! okay.  I wasn't sure which context I needed to have loaded.  :)
[23:15] <lifeless> Keybuk: if the branch object is still around, we can use heads to recover the tip
[23:16] <james_w> Keybuk: I can't find one on jubany
[23:16] <lifeless> Keybuk: if the branch has been deleted its probably still on disk for a losa to recover
[23:18] <Keybuk> whew, I found a working copy!
[23:22] <hrocha> cjwatson, from syslog
[23:22] <hrocha> Dec 21 23:18:38 ubuntu ubiquity[26273]: progress_loop()
[23:22] <hrocha> Dec 21 23:18:39 ubuntu kernel: [ 3005.357755] ubiquity[26273]: segfault at 7fe72f7bc840 ip 00007fe743db7ef4 sp 00007fff83232780 error 4 in libglib-2.0.so.0.2300.0[7fe743d79000+c6000]
[23:23] <cjwatson> hrocha: could you put the whole files (both syslog and debug) on paste.ubuntu.com, please?
[23:23] <cjwatson> I'm not going to debug fragments :)
[23:23] <hrocha> ok
[23:27] <hrocha> cjwatson, http://paste.ubuntu.com/344369/ (for syslog)
[23:27] <hrocha> cjwatson, http://paste.ubuntu.com/344370/ (installer/debug)
[23:28] <cjwatson> hmm
[23:28] <cjwatson> I'm almost inclined to say this is a glib2.0 bug
[23:28] <cjwatson> I don't suppose it wrote a crash report to /var/crash?
[23:29] <cjwatson> the segfault is in libglib-2.0.so.0, but there's no traceback here
[23:29] <hrocha> cjwatson, yes, there is a trace there
[23:30] <cjwatson> can you use ubuntu-bug (or the crash icon in the panel, if you have one) to report it, please?
[23:30] <cjwatson> that's the best way to get us all the information in a convenient form
[23:30] <hrocha> ok, i'll use ubuntu-bug because i don't have the crash icon
[23:33] <hrocha> cjwatson, ubuntu-bug is says that i should report a PID
[23:34] <hrocha> cjwatson, if the process died, there is no pid
[23:34] <cjwatson> it also allows passing a .crash file
[23:34] <cjwatson> Usage: /usr/bin/ubuntu-bug <pid>|<symptom name>|<package name>|<program path>|<.crash file>
[23:42] <hrocha> cjwatson, bug reported
[23:43] <hrocha> cjwatson, i'll wait for the bug to be fixed to continue helping you with lucid
[23:46] <cjwatson> hrocha: thanks
[23:46] <hrocha> cjwatson, i thank you also for all the work all team members have been doing since ubuntu 4.10
[23:48] <cjwatson> hrocha: what's the bug number?
[23:49] <hrocha> #499272
[23:51] <smiter> <--beathing his head against the wall dealing with install of 9.10 black screen
[23:51] <smiter> *beathing lol
[23:51] <smiter> beating
[23:54] <smiter> can anyone here give a little advice on how to attack this?
[23:55] <ion> Try disabling KMS. What GPU do you have?
[23:56] <smiter> <--absolut beginning with ubuntu... havent programmed in over 30 years..
[23:56] <smiter> Gnome maybe?
[23:56] <ion> What graphics adapter? ATI? nVidia? Intel?
[23:56] <smiter> ati
[23:57] <smiter> radeon 9200 vid card
[23:57] <smiter> rv 280 i believe
[23:58] <smiter> i read 9200 were having a problem on 9.10 so i tried to install 9.04  same problem.. now loading 8.10 same problem.. ubuntu is running.. the screen goes black when starting up the prog
[23:59] <smiter> i can hear the jungle drums running so i know its up and running, just have a totally black screen
[23:59] <ion> Oh, then it’s not a KMS issue.
[23:59] <ion> What’s the last visible thing when booting?
[23:59] <smiter> the program installs.. i just cant see it lol
[23:59] <smiter> umm the ubuntu loading screen