[00:47] <roaksoax> bigjools: o/
[02:46] <bigjools> roaksoax: latest precise package won't install
[02:46] <roaksoax> bigjools: output?
[02:48] <bigjools> roaksoax: http://pastebin.ubuntu.com/1357069/
[02:48] <roaksoax> bigjools: let me fix it
[02:51] <roaksoax> bigjools: oh I know what the problem is :). you should be able to install it using a clean install
[02:51] <roaksoax> i'll add the necessary conflict/replaces
[02:52] <bigjools> yeah ::)
[14:44] <jtv> smoser, are you here?
[14:44] <smoser> jtv, here.
[14:44] <jtv> Hi.  Has anyone asked you yet about ways to get our custom commissioning scripts into cloud-init?
[14:45] <roaksoax> jtv: howdy! hey all the packaging changes you did to change the iscsi stuff from regin to cluster... that also applies to the stabilization branch, right?
[14:45] <jtv> Hi!  Er... I don't think it did, but give me a moment to collect my memories about why.
[14:46] <roaksoax> jtv: that applies to having the images in the cluster-controller rather than region-controller, which is part of the stabilization branch
[14:46] <jtv> Ah.  I may be confusing different jobs there.
[14:47] <smoser> jtv, well, sort of. in denmark i talke da bit with rapheal on how it should be done... i 'd have to think again.
[14:47] <jtv> There are associated changes to the codebase, so it's not just a matter of porting the packaging changes across.
[14:47] <roaksoax> jtv: bug #1068843
[14:48] <smoser> we need to re-wrk the way that stuff is done.
[14:48] <jtv> So it needs a change in cloud-init?
[14:49] <smoser> the rendering for commissioning user-data will basically output a cloud-archive format.
[14:49] <smoser> no changes to cloud-init.
[14:49] <smoser> just to the rendering of the user-data.
[14:50] <smoser> jtv, i'll try to write something readable down at http://pad.daviey.com/custom-commissioning
[14:50]  * jtv loads
[14:50] <smoser> is there a bug for this ?
[14:51] <roaksoax> jtv: https://launchpad.net/maas/+milestone/12.10-stabilization has bug #1068843, which means that all the images should now be on the cluster-controller, right? This means that the tgtd stuff should also be backported to the quantal packaging, right?
[14:51] <roaksoax> (because all the ephemerals will be in the cluster controller side, rather than in the region)
[14:52] <jtv> smoser: I don't think we have a bug for that yet, no.
[14:56] <jtv> roaksoax: yes, that means that the packaging changes should be backported to 1.2.  I was told that there had already been some packaging changes to make the cluster controller depend on tgtd as well.
[14:59] <jtv> smoser: one particular concern was that we wanted to run the custom commissioning scripts from the main commissioning script, so that we can report success using the "signal" call (if appropriate).  We figured that having cloud-init run all the scripts itself probably wasn't going to a perfect fit.
[15:02] <smoser> jtv, right. but some thing syou might not want that.
[15:02] <jtv> eparse
[15:04] <roaksoax> jtv: alright, i'll take care of it
[15:04] <jtv> Thanks.  Losing my laptop really knocked me out of things for a while.
[15:06] <smoser> jtv, right now in existing commissiong script, it is actually not difficult for the user to add something and have it get run, and then maas-signal to post its output back.
[15:07] <smoser> but just because the user needs to send a file down does not mean they necessarily want it executed and its output posted back.
[15:07] <jtv> Right.
[15:07] <smoser> the current script differenciates this by "add_bin" and "add_script". but obviously they might also want to send my_python_library.py down, which would then be used by my_commissioning_script.py
[15:08] <jtv> We're not even talking about supporting that yet, tbh.
[15:08] <jtv> But we do want to be able to report overall success, not just success for each of several scripts.
[15:09] <jtv> And of course failure for custom scripts that bail out without ever getting to the point where they report success.
[15:19] <smoser> jtv, does the stuff there make sense?
[16:01] <jtv> smoser: having trouble figuring out the text tbh
[16:06] <smoser> hmm.
[16:06] <jtv> Most of the text seems to say that cloud-init will run the custom scripts, but then the very last line seems to assume that the maas harness script will do it.  How do the two fit together?
[16:06] <smoser> cloud-init does what you tell it to do.
[16:07] <smoser> maas has to tell it to run the scripts
[16:07] <smoser> it does so by sending a script that executes the other peices.
[16:10] <jtv> That's what we've been wanting, yes.  But I don't see it anywhere in the text, really.  It only says that cloud-init will run files it gets sent.
[16:12] <smoser> i've update dthe last line there, jtv, maybe morem explicit on that now.
[16:15] <jtv> smoser: I guess one of the two prior points is wrong then... one says that cloud-init will run files whose names start with "report-" and the other says that cloud-init will act upon the other files.  But cloud-init in both cases.  I'm guessing that one of those was meant to be the maas harness script instead.
[16:29] <jtv> smoser: sorry, had some trouble there — maybe I shouldn't have upgraded this machine after all.  :)
[16:39] <jtv> Hmm... still can't connect to pad.daviey.com
[16:39] <mgz> daviey appears to be down
[16:53] <Daviey> mgz: i am always down with t
[16:54] <jtv> I like the front page...  just says "Error"
[16:54] <Daviey> jtv: i killed it, do you need it?
[16:54] <jtv> We sort of do, yes.
[16:54] <Daviey> ok, give me 2
[16:55] <mgz> daviey's getting on up
[17:10]  * jtv has to leave now
[17:27] <Daviey> sorry
[17:27] <Daviey> was on a call
[17:29] <Daviey> it's back up
[18:00] <spideyman_> jam: Hi, Do you have a few minutes to discuss the kernel_opt tagging?
[18:01] <mgz> spideyman_: he's probably not on now, as it's late in his timezone, but feel free to bug me instead
[18:01] <jam> spideyman_: so it is technically 5 hours after my EOD, but I'd like to give you help as much as possible
[18:01] <jam> mgz: I was going to poke you, but it is your EOD to, isn't it ? :)
[18:01] <mgz> he *shouldn't* be on... :)
[18:02] <mgz> I owe an hour or so anyway
[18:02] <jam> spideyman_: we essentially appreciate someone actually using the feature, since we want to make sure it is useful
[18:02] <spideyman_> jam: Ah yes..it's very nice, and sorry I didn't realize it was so late
[18:04] <spideyman_> mgz:I sent an email to jam yesterday regarding the issue. If you have some spare time to look at it, I'd appreciate it
[18:04] <jam> spideyman_: timezones being what they are, there really isn't "good" overlap between us.
[18:04] <mgz> spideyman_: I read the main
[18:04] <mgz> *mail
[18:05] <jam> spideyman_: so I think the starting thing is to just find out what is going wrong with your script, because it generally looks right from our end.
[18:05] <jam> So probably we need to have you run it, and figure out what the state is after the script has run.
[18:05] <spideyman_> mgz: ah right. So essentially, I'm not seeing an update in the UI, and the node.tags.values() is empty...yet the tag is created successfully
[18:06] <spideyman_> jam: sure one sec
[18:06] <mgz> so, my one immediate thought was you probably just need to call save()?
[18:06] <jam> spideyman_: can you successfully go to http://.../MAAS/tags/<tag-name> ?
[18:06] <jam> mgz: IME you don't need save for many to many relationships
[18:06] <jam> they get written right away
[18:06] <mgz> in the custom methods we do that already, but when working directly on the model methods, they don't
[18:06] <jam> but maybe you need a save for the new creation?
[18:07] <mgz> right, I think perhaps.
[18:07] <jam> mgz: though I could be wrong about the M2M
[18:07] <jam> save() would certainly be something to try.
[18:07] <spideyman_> jam: running the script now..it will be a sec
[18:08] <jam> Though note that he didn't add a save around the workerNode.tags.add()
[18:09] <mgz> right, the details of the django orm I'm still unclear on, but the top block of code looks a little wrong
[18:10] <mgz> creates 'new_item', then looks it up immediately and puts in 'created_tag', and uses that to add
[18:10] <jam> mgz: the only one I could specifically point to is doing node.tags.create() vs Tag.objects.create(), and using a get() after the create rather than just using the created item.
[18:10] <jam> mgz: right, it seems odd, though not specifically wrong.
[18:10] <mgz> so, seemed like something persistency might be going wrong there
[18:11] <mgz> spideyman_: so, specifically, try the following instead:
[18:12] <mgz> new_tag = Tag.objects.create(name=tag_name, definition="true", kernel_opts=kernel_opts)
[18:12] <mgz> new_tag.save() # may or may not matter
[18:13] <spideyman_> mgz: okay, I give it a shot. I actually need to reboot, as this VM is not responding well
[18:13] <mgz> new_tag.node_set.add(tagged_node)
[18:13] <mgz> and then maybe throw in another save just in case to start with, then if that works, try taking them out again :)
[18:27] <spideyman_> mgz: sorry for the delay...my vm wasn't cooperating.
[18:27] <spideyman_> mgz: https://pastebin.canonical.com/78396/
[18:27] <spideyman_> mgz: I'll paste bin the tag info
[18:28] <spideyman_> mgz: https://pastebin.canonical.com/78397/
[18:29] <spideyman_> mgz: and there's the tag that it created...but it's not attached to the node
[18:29] <mgz> can you pastebin your script too?
[18:29] <spideyman_> mgz: and here's the code I added: https://pastebin.canonical.com/78398/
[18:35] <spideyman_> mgz: the messy but "working" copy is here: lp:~jeffmarcom/+junk/maas-cert if interested.
[18:35] <spideyman_> mgz: you'll find the whole script in question under maascert/control/maas_nodes.py
[18:36] <mgz> spideyman_: so, I'd just flip all that to something like...
[18:36] <mgz> https://pastebin.canonical.com/78401/
[18:37] <mgz> which is the simplest that you can persuade the ORM to do. the other thing to try is to not supply definition= at all.
[18:40] <mgz> hm, the fact the node is your own subclass may also have som bearing
[18:41] <spideyman_> mgz: hmm...still didn't work
[18:42] <spideyman_> mgz: that's true...everything has worked with it so far. I'd hoped that it wouldn't be an issue
[18:45] <spideyman_> mgz: wait...removing the definition worked
[18:46] <mgz> okay, seems that's what you want here anyway, as you're manually assigning the tag to the node
[18:47] <spideyman_> mgz: right...thanks so much!!
[18:48] <mgz> I wonder if the definition was borked because the reasoning is wrong on "true" being a good xpath to match everything, or whether the async nature of populate nodes is somehow messing with your setup
[18:49] <mgz> anyway, I shall now descend, but will stay in this channel under my other alias in case you have any other questions
[20:11] <Pradeep_> on quantal maas after doing "sudo apt-get install maas-dhcp maas-dns" do I need to edit the configurations manually for dhcp
[20:11] <Pradeep_> I remember in Precise it used to be interactive
[20:11] <dannf> hey Pradeep_  - yeah there used to be debconf settings for ip range, etc
[20:12]  * dannf doesn't know how things work in quantl though
[20:13] <Pradeep_> on Precise also there used to be a dnsmaq template file where I can go and edit the configuration
[20:14] <Pradeep_> I was referring to this document http://people.canonical.com/~gavin/docs/lp:maas/install.html#disc-install for installation
[20:47] <Pradeep_> is dhcpd used in Quantal instead of dnsmasq?


[00:11] <darkxst> jbicha, I suppose this is probably a bit much for an SRU? https://bugzilla.gnome.org/show_bug.cgi?id=683060#c71
[00:12] <darkxst> I suppose we could get away with just the shell patch however
[00:13] <darkxst> this is the ubuntu bug https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1064354
[00:56] <darkxst> jbicha, http://paste.ubuntu.com/1288183/, would this be more suitable for SRU (only patches gnome-shell, rather than 3 packages!)
[06:26] <darkxst> ricotz, is this ok for an SRU? https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1064354 (this is my first attempt at one)
[06:42] <ricotz> darkxst, i guess you tested it, but the solution doesnt look that good though
[06:43] <darkxst> ricotz, yes I tested, and that was halfline's suggestion
[06:44] <ricotz> darkxst, wouldn't it be better to let dbus spawn the service
[06:45] <darkxst> the problem is its only needed for shell on lightdm
[06:45] <ricotz> meaning changing the flags to have the gnome-screensaver autostarted some lines later
[06:46] <darkxst> halfline said that wouldnt work
[06:46] <ricotz> why?
[06:47] <darkxst> http://git.gnome.org/browse/gnome-screensaver/commit/?id=3365eec74643773d8d5aa92901b39bdc9496e19b
 is it safe to remove the DO_NOT_AUTO_START flag?
 won't help
[06:48] <darkxst> <halfline> since http://git.gnome.org/browse/gnome-screensaver/commit/?id=3365eec74643773d8d5aa92901b39bdc9496e19b
[06:50] <ricotz> dpkg -S org.gnome.ScreenSaver.service
[06:50] <ricotz> gnome-screensaver: /usr/share/dbus-1/services/org.gnome.ScreenSaver.service
[06:51] <ricotz> it is still there though
[06:53] <ricotz> darkxst, 05_dbus_service.patch is adding it back in
[06:53] <ricotz>   * debian/patches/05_dbus_service.patch:
[06:53] <ricotz>     - restore the dbus service that upstream dropped
[06:53] <ricotz> in 3.2.0-1ubuntu1
[06:55] <ricotz> so if this is going to an ubuntu patch for gnome-shell then the relying on dbus seems better
[06:55] <ricotz> or should your patch go upstream?
[06:58] <darkxst> yeh my patch will go upstream
[07:07] <ricotz> darkxst, ok, you probably want to follow this https://wiki.ubuntu.com/PackagingGuide/PatchSystems#Patch_Tagging_Guidelines
[07:07] <ricotz> to clean up the patch header
[07:10] <ricotz> http://bugzilla-attachments.gnome.org/attachment.cgi?id=226790
[07:10] <ricotz> keep the blank line in the imports and add a blank line after the spawn
[07:11] <ricotz> http://paste.debian.net/plain/201741
[07:11] <darkxst> add them to the upstream patch header or both
[07:12] <ricotz> i noticed the proposed patch after it, which includes a bug reference
[07:13] <ricotz> so using the  "git format-patch" is fine too
[07:18] <darkxst> oh ok, although sometimes they don't apply cleanly to ubuntu version
[07:20] <ricotz> using the git patches directly is the best way imo since it includes all needed information
[07:20] <ricotz> fixing fuzz if needed is easy enough
[07:25] <darkxst> ok, so I updated the debdiff to use the git patch
[07:26] <ricotz> darkxst, ok
[07:27] <ricotz> no need to use UNRELEASED here
[07:27] <ricotz> use quantal-proposed
[07:27] <ricotz> gnome-shell (3.6.1-0ubuntu1.1) quantal-proposed; urgency=low
[07:27] <darkxst> 1.1 or 2?
[07:28] <ricotz> i would go with 1.1
[07:28] <ricotz> which is the preferred policy irc
[07:32] <darkxst> a policy which seems to change depending on packages ;)
[07:32] <darkxst> anyway updated
[07:35] <ricotz> good
[07:37] <darkxst> well that or jbicha has just been tweaking my changelogs with out saying anything.
[07:38] <darkxst> ricotz, anyway thanks for you help
[07:41] <darkxst> I don't suppose you can upload it for me?
[07:49] <darkxst> anyway dinner time here...
[09:38] <ricotz> sorry, i can't upload it
[09:58] <darkxst> ricotz, np, will get jbicha onto it when he wakes up
[11:08] <everaldo> looks like we have a problem to burn to USB
[11:08]  * everaldo investigating
[11:08] <everaldo> btw, http://www.webupd8.org/2012/10/prefer-gnome-shell-download-ubuntu.html
[13:37] <L3mce> Hello... This is the UGR channel?
[13:38] <L3mce> I am fairly adept at creating debian based install isos. I had read that there were difficulties and would like to know if I can help.
[13:40] <jbicha> https://code.launchpad.net/~ubuntu-gnome-dev/+junk/iso-build-script
[13:41] <jbicha> L3mce: I believe our script basically does what it needs to but there's likely still room for improvement
[13:41] <L3mce> I can make it jibe with Startup Disk Creator if it is not currently.
[13:41] <L3mce> I just heard about the project this morning, so I am still catching up to where you are.
[13:42] <jbicha> ah, I think the Startup Disk Creator problems are because Startup Disk Creator is broken in Quantal
[13:42] <jbicha> it works fine in Precise though
[13:42] <L3mce> Oh, great...
[13:43] <L3mce> Ok then... I will just go at bugs.
[13:43]  * L3mce is a dev for linuxmce
[13:45] <jbicha> it did take me a few months to figure out how building an iso worked which meant that this release cycle was a bit short but it worked out ok
[13:48] <L3mce> Well I will load it up and see how we both go at it. If there are any things you want it doing that it is not, let me know. Otherwise I will just look.
[13:52] <jbicha> well for instance when I published yesterday I had to manually copy the filesytem.manifest and create the torrent
[13:52] <jbicha> those 2 steps should be easy to add to the script
[13:59] <L3mce> Yours is very lean and mean. Ours is a bit of a monster as we pre-install most of the system... but we are an appliance, not a distro... so we have a lot of plumbing to install before people stick their grubby fingers in it.
[14:02] <L3mce> nice job :) /me was really hoping he could help more there...
[14:02] <jbicha> yeah, we're trying to do all the configuration stuff & patching in Ubuntu itself
[14:02] <jbicha> well I didn't write the original script and I'm not the only one that's been maintaining it
[14:07] <L3mce> after we do a build we create a dd image with our needs http://svn.linuxmce.org/trac.cgi/browser/people/posde/image.sh and then create the iso after shoving a lot of stuff around  http://svn.linuxmce.org/trac.cgi/browser/people/l3mce/lmcemaster.sh
[14:09] <L3mce> we are also using the mirrors scheme, because it just seemed easiest. eg deb mirror://mirrors.ubuntu.com/mirrors.txt $DISTRO main restricted universe multiverset deb mirror://mirrors.ubuntu.com/mirrors.txt $DISTRO main restricted universe multiverse
[14:10] <L3mce> sorry for the double tap there.
[14:11] <jbicha> ah ok, we just piggy back off ubiquity (Ubuntu's installer) which handles that for us
[14:12] <jbicha> logging off for a bit
[14:12] <L3mce> we use a central core and pxe boot everything else, so this way when folks install it is 90% there, and we just detect and install for GPUs etc, and the diskless stuff is allready packaged and plug n play...
[14:12] <L3mce> ok... will look more where I can help. have a good one.
[15:10] <smartboyhw> jbicha, congrats on the final release of UGR 12.10 !
[17:14] <TheLordOfTime> so is UGR official in 12.10?
[17:14] <TheLordOfTime> i.e. is it an official derivative :P
[17:16] <jbicha> TheLordOfTime: no
[17:16] <TheLordOfTime> when's that happening :p
[17:16] <TheLordOfTime> ... damn... i broke it...
[17:17]  * TheLordOfTime goes to fix php5 again
[17:18] <jbicha> well we have to ask first
[17:18] <jbicha> https://wiki.ubuntu.com/RecognizedFlavors
[18:28] <jbicha> darkxst: VBox 4.2.2 supports xorg 1.13, now we just have to figure out how to backport that to quantal
[19:30] <darkxst> jbicha, so we probably need to update the entire vbox packages, but quantal is still on 4.1.x
[19:30] <darkxst> so probably a major update
[19:32] <darkxst> jbicha, can you upload this? https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1064354
[19:32] <jbicha> uh, that will be fun, FFe https://wiki.ubuntu.com/FreezeExceptionProcess
[19:32] <jbicha> (for a new major version of vbox I mean)
[19:35] <jbicha> darkxst: yes but I won't get to it today
[19:35] <darkxst> ok thats fine
[19:37] <darkxst> have you had any trouble with current vbox on Q (apart from the guest additions)
[19:43] <jbicha> I've actually been using virt-manager these days
[19:43] <jbicha> I got tired of the vbox bugs and wanted to experience the virt-manager bugs instead :)
[19:45] <darkxst> lol, I gave up on vbox several years ago
[19:55] <darkxst> but when I did still use it, I was always running the packages of vbox repo


[18:42] <Keybuk> morning
[18:45] <adam_g> heya.
[18:47] <Keybuk> how goes?
[18:48] <adam_g> well. working with upstart for the first time.
[18:49] <adam_g> does a concept equivilent to the status operation of an LSB init script exist in upstart currently?
[18:51] <djszapi> hi Keybuk
[18:51] <djszapi> Keybuk: upstart logging does not work ...
[18:56] <Keybuk> djszapi: it does, millions of people use it every day
[18:56] <Keybuk> it may not be working for you
[18:56] <Keybuk> I'm honestly starting to suspect somebody at Nokia has disabled that code in your source tree
[18:57] <djszapi> nope
[18:57] <djszapi> I made an own build today.
[18:58] <Keybuk> well, it works for me
[18:58] <Keybuk> perhaps you could tell me more about what doesn't work
[18:58] <Keybuk> what you've tried
[18:58] <Keybuk> etc.
[18:58] <djszapi> it does not help me if you keep repeating it :)
[18:59] <Keybuk> it doesn't help you if you just say "nope" either ;-)
[18:59] <djszapi> I just know it can work, thus it is worthwhile to try to fix it.
[18:59] <djszapi> well "nope" is a kool word :P
[18:59] <djszapi> btw, have you read my mail ?
[18:59] <Keybuk> I haven't read your mail
[18:59] <djszapi> I do not know what else I could amend it with ...
[19:00] <Keybuk> ok
[19:00] <Keybuk> so you've patched upstart with my kmsg patch?
[19:00] <Keybuk> and that version of upstart is currently running as pid #1 ?
[19:03] <djszapi> well, about.
[19:03] <Keybuk> "about" ?
[19:04] <djszapi> yeah, the patch did not change anything to the previous statement, there are *NO* such messages anywhere.
[19:04] <Keybuk> right, I'm asking whether you have that version patched and running ;-)
[19:04] <Keybuk> ok
[19:04] <Keybuk> so let's try something
[19:04] <Keybuk> (as root) run the following
[19:05] <Keybuk> # initctl log-priority
[19:05] <Keybuk> it should print a word, what is that word?
[19:06] <djszapi> FYI: I am @ home.
[19:06] <djszapi> 21:06 pm
[19:06] <Keybuk> can you not access that box?
[19:06] <Keybuk> no VPN or anything?
[19:06] <djszapi> to the prototype ?
[19:06] <djszapi> no, I cannot.
[19:06] <Keybuk> ah
[19:06] <djszapi> it is quite perfectly locked into the safe box.
[19:06] <Keybuk> what time of day can you usually access it?
[19:06] <djszapi> while being there ? :)
[19:07] <Keybuk> what time?
[19:07] <djszapi> no idea :)
[19:07] <Keybuk> haha, right
[19:07] <djszapi> change day by day
[19:07] <djszapi> really...
[19:07] <Keybuk> so what I'll do is reply to your mail with a sequence of debugging steps
[19:07] <Keybuk> if you could follow them exactly, and answer each of them when you have access to the box
[19:07] <Keybuk> then I should be able to figure out what's going wrong with it
[19:08] <djszapi> well
[19:08] <Keybuk> please don't skip steps if you think you know the answer, the output I'm asking for is subtle and you might miss something that would tell me the problem
[19:08] <djszapi> I can access to it in 11 hours
[19:08] <djszapi> ok sure do not be afraid of that :)
[19:08] <Keybuk> yeah, in 11 hours I'll be going to bed
[19:08] <djszapi> btw, we use 0.6.6
[19:09] <djszapi> with quilt patchset
[19:09] <djszapi> where should I see kmsg logs ?
[19:09] <djszapi> I tried the dmesg and the console where printk happens.
[19:09] <Keybuk> I actually have a hunch what's wrong
[19:10] <Keybuk> based on something somebody else at Nokia told me earlier this week ;-)
[19:10] <djszapi> or go thorugh pls.
[19:10] <djszapi> maybe I can answer for some of them
[19:10] <djszapi> which can already show the mistake ...
[19:10] <Keybuk> well, first in your mail you say "warn" which actually means upstart will log *less*, you want log-priority info ;-)
[19:10] <djszapi> somebody ?
[19:10] <djszapi> me or other guy ?
[19:10] <djszapi> yes
[19:10] <Keybuk> but I think in MeeGo you have an /sbin/init shell script wrapper for Upstart
[19:11] <djszapi> I tried info
[19:11] <djszapi> that was done
[19:11] <Keybuk> and that wrapper is not passing command-line arguments to Upstart
[19:11] <djszapi> nothing changed regarding this
[19:11] <djszapi> that is a typo in the mail, sorry.
[19:11] <Keybuk> right
[19:11] <djszapi> I wanted to send a mail.
[19:11] <Keybuk> well, reply to my mail when you have the box, and follow the steps
[19:11] <djszapi> I have just been at the school
[19:11] <Keybuk> and we'll chat tomorrow
[19:11] <djszapi> "but I think in MeeGo you have an /sbin/init shell script wrapper for Upstart" -> why so ?
[19:12] <djszapi> btw, ROTFL !!! :-) http://i.imgur.com/4kepL.jpg
[19:12] <Keybuk> djszapi: because someone else told me you do in the thread where I posted the kmsg patch
[19:12] <djszapi> huh ?
[19:12] <djszapi> not gotcha ...
[19:13] <Keybuk> it's ok
[19:13] <Keybuk> we'll pick this up tomorrow
[19:13] <djszapi> highly doubt
[19:13] <Keybuk> hey ;-) I'm trying to help here
[19:14] <djszapi> during your sleep ?
[19:14] <Keybuk> tomorrow my time
[19:14] <djszapi> if yes, I am fine with that :)
[19:14] <Keybuk> ie. this time tomorrow once you've gone through the steps in my mail
[19:14] <djszapi> well ...
[19:14] <djszapi> when I will get to my box, you will be sleeping.
[19:14] <Keybuk> yes
[19:14] <Keybuk> so you reply to the mail
[19:14] <Keybuk> and then when I'm awake, I read the mail
[19:15] <Keybuk> and hopefully in the output of all the commands will be the clue that tells me what's wrong
[19:15] <djszapi> well I have access to the srouce code.
[19:15] <djszapi> * source
[19:15] <djszapi> if I can help anything with that, do not hesitate to tell me ...
[19:16] <djszapi> btw, I did see nowhere this --verbose option.
[19:17] <djszapi> maybe it is just not documented ?
[19:17] <Keybuk> it's built-in to nih/option.c
[19:17] <djszapi> odd I was thinking that it is kernel thingy ;)
[19:17] <Keybuk> no
[19:17] <Keybuk> it's an upstart thingy
[19:18] <djszapi> Alright.
[19:18] <djszapi> cya tmrw.
[19:18] <djszapi> ty in advance.
[19:18] <Keybuk> (mail should be in your inbox now btw)
[19:19] <djszapi> it is not.
[19:19] <djszapi> just the thread ...
[19:19] <djszapi> got.
[19:20] <djszapi> haha I think all the output will be ok :)
[19:20] <Keybuk> I'm not looking for "ok" or not "ok"
[19:20] <djszapi> (I am just kidding)
[19:20] <Keybuk> I'm looking for a clue that tells me what's wrong that you may miss
[19:20] <Keybuk> Upstart, like most software, uses different strings for the same states in different places
[19:20] <Keybuk> so by reading a log, as a developer, I can see what it's doing which isn't obvious to others
[19:20] <djszapi> that is exactly what I meant with "ok", nothing is gonna inform you :)
[19:21] <djszapi> okay, let us see and really thank you.
[19:25] <Keybuk> np :p


[12:19] <lamont> so lets see.. do we want to have 00list-25.1* in the 26 upload?
[12:20] <lamont> hrm.. actually, I don't see the atapi patch update either...
[03:00] <zul> hey
[03:01] <zul> so what did i miss?
[04:08] <lamont> you know, we could break up the kernel into a package that just builds the -doc and -source packages, and then others that just build-depend: -source, have nothing in them except maybe config files, and then do the build...  that'd let the buildd's spread the load of a new source tree out a bit...
[04:08] <zul> good idea but we arent redhat
[04:08] <zul> or any rpm based distro
[04:09] <zul> does debian do the same way?
[04:09] <zul> ie how we build our kernel...oh this is channel is logged now isnt it?
[04:30] <lamont> heh
[04:30] <lamont> yeah, should be logged
[04:30] <lamont> t-bone was doing it, I expect fabbione has picked that up and incorporated it into the wiki bound logs
[04:31] <lamont> debian is heading to the same place we are, not sure who is further down the path yet.
[04:31] <zul> it should have big black warning signs
[04:31] <lamont> prior to the 2.6 package, it was actually a kernel-tree and kernel-patch-2.4.27-powerpc type world
[04:31] <zul> eww
[04:44] <zul> nighto
[04:45] <jbailey> mdz: I made a bad on 1440 - It looks like scd0 *is* there.  I had windows open to both SATA machines.  I did the kernel upgrade on one and looked at the other afterwards.
[04:46] <jbailey> mdz: ii  linux-image-2. 2.6.10-25.1    Linux kernel image for version 2.6.10 on PPr
[04:46] <jbailey> iridium:/sys/block/sr0#
[04:46] <jbailey> Sorry, obviously being in the rush to get out caught me. =(
[07:27] <fabbione> lamont:
[07:27] <fabbione> +# this is a hack for Ubuntu buildd's
[07:27] <fabbione> +
[07:27] <fabbione> +if [ -e /CurrentlyBuilding ] ; then
[07:27] <fabbione> +       fork := $(cat /proc/cpuinfo | grep ^processor | wc -l)
[07:27] <fabbione> +       fork := $(expr $fork \* 2)
[07:27] <fabbione> +       export CONCURRENCY_LEVEL := $fork
[07:27] <fabbione> +fi
[07:27] <fabbione> +
[07:27] <fabbione> somethinig like this in debian/rules
[07:27] <fabbione> would speed up the kernel build N times
[07:29] <lamont> fabbione: i386 is 4 way, amd64 2, ppc 1.
[07:29] <lamont> ppc is the blocker
[07:29] <fabbione> lamont: i did test on davis.. -j15 flies
[07:29] <lamont> and the other 2 finish in about 2 hours..
[07:29] <fabbione> still slow but clearly much better than -j1
[07:30] <fabbione> specially if the code is ccached
[07:30] <lamont> yeah - feel free to add the hack...
[07:30] <fabbione> we can give it a shot for 26
[07:30] <fabbione> and see how it goes
[07:30] <fabbione> you get the delta for it, don't you?
[07:30] <lamont> ??
[07:30] <lamont> I get what?
[07:31] <fabbione> delta in build time.. to see if we gain or we lose
[07:31] <lamont> yes]
[07:31] <fabbione> cool
[07:32] <lamont> last line of the build logs
[07:43] <lamont> lrwxrwxrwx  1 root root 9 Mar 10 06:37 /usr/sbin/sendmail -> /bin/true
[07:45] <fabbione> * committed<EMAIL_ADDRESS>[07:45] <fabbione> ok 25.2 is up
[07:45] <fabbione> lamont: want to check if the changes to the umask are ok?
[07:47] <lamont> find ~lamont/public_html/Archives ! -user lamont -perm -0200 ! -perm -020
[07:47] <lamont><EMAIL_ADDRESS>[07:47] <lamont><EMAIL_ADDRESS>[07:48] <fabbione> does sftp actually load .bash_profile?
[07:48] <lamont> dunno
[07:48] <fabbione> because that's where i changed the umask
[07:50] <fabbione> umask 002
[07:50] <fabbione> also in .bashrc now
[07:51] <fabbione> i can try to branch and see if that works
[07:52] <lamont> well, if you go chmod g+w those two files, then _I_ can commit to mainline....
[07:52] <fabbione> sure
[07:54] <fabbione> done.. they are actually 2 dirs..
[07:54] <fabbione> let me try to branch and see if sftp will load .bashrc
[07:55] <fabbione> i can still fix the permissions on the fly
[07:56] <fabbione> looks about right
[08:09] <fabbione> * committed<EMAIL_ADDRESS>[08:09] <fabbione> lamont: all the syncs/merges should be ok now
[08:09] <lamont> woot
[09:01] <fabbione> lamont, mdz: would i be crossburned if i kill this patch madness for hoary?
[09:02] <T-None> hey fabbione !
[09:02] <fabbione> hi T-None
[09:02] <mdz> fabbione: not at all
[09:02] <lamont> fabbione: I have yet to see what useful purpose it serves...
[09:02] <T-None> well in my humble opinion i would praise you for doing so ;)
[09:02] <lamont> which is to say, kill away
[09:02] <T-None> lamont: lol
[09:02] <mdz> it should be pretty easy to ensure that it doesn't regress
[09:02] <fabbione> lamont: i am not 100% how make-kpkg will interact with linux-ubuntu-patches
[09:03] <mdz> as long as it still builds and no patches are dropped, it is fine with me
[09:03] <mdz> it should save minutes on the kernel build too :-P
[09:03] <T-None> the only purpose i see is finding out which kernel rev introduced a borkage.   Waldi filed a bug against initrd-tools in Debian which propagated its way into Ubuntu.  Apparently on his systems /proc/scsi isn't populated, and on ours it is.   His claim is that 2.6.10 did away with that.  Have we tweaked it so that ours still has that info?
[04:02] <zul> not sure maybe you should ask in -devel
[04:03] <jbailey> Nah, I'll just pull the source and look.
[04:06] <zul> or youo could do that
[04:29] <jbailey> ## DP: Description: restore generic SCSI proc_info function in drivers/scsi/scsi_proc.c
[04:29] <jbailey> That would probably be the one.
[04:35] <zul> oh it was a kernel question...im not awake yet
[04:35] <fabbione> hey
[04:35] <zul> hey fabbione
[04:38] <jbailey> Heya Fabio =)
[04:38] <jbailey> zul: *lol* =)
[04:39] <zul> fricking palm
[04:40] <fabbione> i am testing the new patch thingy
[04:40] <fabbione> it seems to work fine
[04:40] <zul> which patch thingy?
[04:40] <fabbione> no more 192891821 patch/unpatch
[04:40] <zul> ah good
[04:40] <fabbione> zul: baz update?
[04:41] <zul> ooh you fixed it so it doesnt patch/unpatch a billion times?
[04:41] <fabbione> yup
[04:41] <zul> sweet!
[04:43] <fabbione> there were several changes to do
[04:43] <fabbione> + an important bug fix
[04:45] <fabbione> hey smurfix
[04:46] <abelli_> ciao smurfix
[04:46] <fabbione> smurfix: what was the perfect command to verify the ABI compatibility?
[04:46] <smurfix> fabbione: one sec
[04:47] <fabbione> sure.. also 2 or 3
[04:50] <smurfix> something along these lines ..:
[04:50] <smurfix>  grep vmlinux Module.symvers.old_kernel |sort >/tmp/symvers.old
[04:50] <smurfix> ditto new
[04:50] <smurfix> comm -23 old new
[04:50] <smurfix> must be empty
[04:51] <smurfix> assuming you build with CONFIG_MODVERSIONS
[04:51] <fabbione> where Module.symvers.old_kernel = Systemmap?
[04:52] <fabbione> no
[04:52] <smurfix> fabbione: no, the "Module.symvers" file that's generated by building the kernel
[04:53] <fabbione> yes and we don't ship it
[04:53] <smurfix> Let me check if you can extract that somehow
[04:56] <fabbione> the idea is to automatically check the ABI with the previous kernel at build time
[04:56] <fabbione> previous version
[04:56] <fabbione> now we can also start shipping that file
[04:56] <fabbione> it's not a tragedy
[04:57] <fabbione> if we start shipping it in 26
[04:57] <smurfix> fabbione: The kernel doesn't export that info any more because it now has a built-in relocator
[04:57] <fabbione> from 27 we can add the check at build time
[04:57] <smurfix> so you probably should start shipping it.
[04:57] <fabbione> this would add a Build-
[04:58] <fabbione> this would add a Build-Dep: on the most recent version of the kernel
[04:58] <fabbione> or just on a linux-abi package
[04:58] <fabbione> that can collect all the MOdule.*
[04:58] <fabbione> what do you think?
[04:59] <smurfix> Hmm, better do an abi package.
[05:00] <fabbione> next upload needs to bless a new package anyway
[05:00] <fabbione> so one more or one less won't change much
[05:00] <smurfix> Would be nice to have that available for cross-compiling. You can put the .config files in there too.
[05:01] <fabbione> smurfix: configfiles are in /boot with the images
[05:03] <smurfix> fabbione: true. Doesn't hurt to also ship them in an -abi package, people like me who still habitually build their own kernels would like that. But, your call.
[05:03] <fabbione> what scares me a bit is how to ensure that we always build against the $previousversion -abi
[05:03] <fabbione> without having to control that manually
[05:04] <fabbione> scenario:
[05:04] <fabbione> upload -1
[05:04] <fabbione> there is no previous -abi
[05:04] <fabbione> so we skip the check
[05:04] <fabbione> and it FTBFS on ppc
[05:04] <fabbione> how do we upload -2 that will check the abi for all arches other than ppc?
[05:05] <fabbione> the code needs to be very smart
[05:07] <smurfix> fabbione: What are you going to do if/when the ABIs don't match?
[05:07] <zul> take a large wooden hammer
[05:07] <smurfix> fabbione: ... or do you decree that any -1 is an ABI change but -2+ isn't?
[05:09] <fabbione> smurfix: FTBFS?
[05:09] <smurfix> fabbione: Well, someties you do need to change the ABI :-/
[05:09] <fabbione> smurfix: clearly the -1 is a new abi
[05:09] <fabbione> yes of course you must change the ABI
[05:09] <fabbione> but an ABI change require also a new control file
[05:10] <fabbione> to reflect that change
[05:10] <fabbione> for example
[05:10] <fabbione> if i start doing heavy patching
[05:10] <fabbione> or security patching to the kernel
[05:10] <fabbione> running a build should be able to tell me if that change will introduce an ABI change
[05:10] <smurfix> OK, so you check the old linux-abi package's version number, and skip the ABI check if it doesn't match what you're building
[05:11] <smurfix> excluding the -X version of course
[05:11] <fabbione> kinda yes
[05:11] <fabbione> but if for example
[05:11] <fabbione> we are building -1-2.6.10 ver 2.6.10-2
[05:12] <fabbione> i want it to compaer with -1-2.6.10 ver 2.6.10-1
[05:12] <fabbione> if the ABI does not match
[05:12] <fabbione> i want it to FTBFS
[05:12] <fabbione> so that i can prosuce a -2-2.6.10
[05:12] <fabbione> that is the correct way
[05:12] <fabbione> since there is an ABI change
[05:12] <fabbione> i mean.. i know i could do all of this manually
[05:12] <fabbione> but for N arches in N flavours
[05:13] <fabbione> it's a royal pain
[05:13] <smurfix> fabbione: sure, but I fail to see how that differs from what I've been saying
[05:13] <fabbione> than probably i misunderstood you :-)
[05:13] <fabbione> but ok
[05:17] <smurfix> Let's say you create a linux-kernel-abi package
[05:18] <fabbione> yes
[05:18] <smurfix> some file in it contains the magic string "2.6.10-4"
[05:19] <fabbione> it would need to contain the ABI version too
[05:19] <fabbione> ok
[05:19] <smurfix> I thought that is* the abi version
[05:19] <fabbione> yeah i get you now
[05:19] <fabbione> i was thinking in terms of 2.6.10-1 (starting from scratch)
[05:20] <smurfix> Doesn't really matter, you'd get the magic string "2.6.9-5" or whatever
[05:20] <fabbione> yup
[05:20] <smurfix> different, so skip check.
[05:22] <fabbione> right
[05:23] <fabbione> that would solve all the problems
[05:23] <smurfix> same when you FTBFS, the failed arch would keep its old l-k-a package which still has the old magic string in it.
[05:24] <fabbione> it won't match the ABI and therefor skip the test
[05:24] <fabbione> because hte next upload will have a different ABI
[05:24] <fabbione> good idea
[05:26] <smurfix> The only problem I see is how to build-dep on the latest l-k-a package
[05:26] <smurfix> unless you just want to wing it ;-)
[05:26] <smurfix> (probably not a good idea, now that I think about it)
[05:27] <fabbione> well the first upload will create the package
[05:27] <fabbione> from the second one we will build-dep on it
[05:27] <fabbione> in case of troubles we can always remvoe the build-dep
[05:28] <fabbione> and unroll the loop
[05:28] <smurfix> Yeah, but if the second build installed the package from the first run on the autobuilder, but changes the ABI, then the third build may still see the first package if it happens not to be cleared out
[05:29] <fabbione> that shouldn't be a problem
[05:29] <smurfix> so a mistaked ABI change from 2->3 might be missed
[05:29] <fabbione> the ABI is supposed to be the same between first, second and third
[05:30] <smurfix> Umm, it's supposed to be the same from -2 to -3, but I wan't talking about that
[05:30] <fabbione> oh you mean if there is an ABI change between -1 and -2
[05:30] <fabbione> and we upload -3
[05:31] <fabbione> and there can still be abi from -1 in the buildd
[05:31] <fabbione> at that point the ABI check should be skipped
[05:31] <fabbione> and it will due to the magic file
[05:32] <fabbione> but yes.. that can actually skip a test that should be done
[05:33] <smurfix> Exactly. I don't know how to guard against that other than asking the archives for the current version when you prepare the source package
[05:33] <smurfix> Dunno whether you'd want to go that far.
[05:34] <fabbione> well preparing the source package is still manual
[05:34] <fabbione> and we can still hack on it
[05:35] <smurfix> OK, then you need to remember never to forget to update the dependency when you prepare a new version. ;-)
[05:35] <smurfix> or write a script that does it. Good enough I'd say.
[05:35] <fabbione> smurfix: that is why we have a control.stub that we can mangle as we like :-)))))
[05:39] <fabbione> smurfix: the next question would be.. are you for this challenge?
[05:39] <fabbione> ;)
[05:40] <smurfix> fabbione: gah  ;-)   I need to fix the keyboard chooser first
[05:40] <fabbione> ehhehe
[05:40] <fabbione> fair enough
[05:40] <smurfix> fabbione: it needs a confirmation dialog
[05:42] <fabbione> i think we can postpone this feature to hoary+1
[05:42] <fabbione> even if it would make pitti's life 1029292 times simpler
[05:42] <fabbione> also for us that will have to maintain this kernel for 18 months
[05:57] <fabbione> last script to test the anti-patch-madness fix
[05:57] <fabbione> s/to/for
[05:59] <smurfix> fabbione: If for hoary, when would you need it?
[05:59] <fabbione> within monday
[05:59] <fabbione> but i guess i can try to work on it
[05:59] <fabbione> i will have the weekend free!
[05:59] <fabbione> YEAH YEAH
[06:00] <fabbione> wife -> her sisterm
[06:00] <fabbione> sister even
[06:12] <fabbione> lamont: don't worry
[06:12] <fabbione> i won't upload very soon
[06:12] <fabbione> not with these big changes
[06:12] <fabbione> i am still testing some stuff
[06:12] <lamont> fabbione: it means that you're baz bitch for a few days... :-)
[06:12] <fabbione> i might get up -26 to get the ATAPI thingy in again
[06:13] <fabbione> and the new idiotify patch
[06:13] <fabbione> and the antipatchmadness
[06:13] <fabbione> the ABI stuff can come later
[06:27] <fabbione> ok confirmed 100%.. the patch madness is gone
[06:27] <fabbione> all the scripts are working
[07:00] <zul> heh im almost always here
[07:13] <zul> whoa...224 changes in the last day
[07:45] <mdz> changes?
[07:46] <zul> in linus bk tree
[07:52] <lamont> busy boy
[07:53] <zul> well with the g5 he must be :)


[07:15] <bkerensa> slangasek: Is there a pro tip for using a local relay with caff or pius?
[16:08] <slangasek> bkerensa: don't know what pius is; caff is configurable, caff(1) manpage has the details
[16:57] <Azeban> Hello, hello, hello
[18:40] <blkperl_> slangasek: so it seems i am unable to install sssd:i386
[18:41] <blkperl> its complaining about unmet dependencies likes python:i386....
[18:54] <slangasek> blkperl: why are you expecting that to work?
[18:58] <blkperl> slangasek: because multiarch? :)
[18:58] <Azeban> http://i.imgur.com/ysfTtDh.jpg
[18:58] <Azeban> meet rachel
[18:59] <Azeban> shes 3 weeks ago
[18:59] <blkperl> Azeban: ww-- ?
[18:59] <Azeban> is that an 'aww'?
[18:59] <Azeban> http://i.imgur.com/Bcw96lY.jpg
[19:00] <Azeban> http://i.imgur.com/dDPP418.jpg
[19:01] <slangasek> blkperl: multiarch only works if the packages have been adjusted for multiarch-compatibility.  File a wishlist bug? :)
[19:01] <blkperl> dammit... but stupid i386 software doesn't know how to ldap without it...
[19:02] <slangasek> Azeban: you... have a pet lion?
[19:02] <Azeban> several
[19:03] <slangasek> blkperl: why does this software need anything beyond libpam-sss and libnss-sss?
[19:03] <slangasek> blkperl: *those* packages are multiarch-compatible
[19:03] <blkperl> oh
[19:05] <blkperl> slangasek: apt just threated me when i tried to install those packages :P
[19:05] <blkperl> WARNING: The following essential packages will be removed.
[19:05] <blkperl>   python-minimal python2.7-minimal (due to python-minimal)
[19:05] <slangasek> srsly?
[19:06] <blkperl> yep
[19:06] <slangasek> what version of Ubuntu?
[19:06] <blkperl> Precise
[19:06] <slangasek> can't reproduce this here
[19:07] <slangasek> what I see is: http://paste.ubuntu.com/6990521/
[19:07] <slangasek> perfectly normal
[19:07] <slangasek> oh, Recommends: sssd:i386
[19:08] <slangasek> right, so you want to do apt-get install libpam-sss:i386 libnss-sss:i386 sssd:i386-', or 'apt-get install --no-install-recommends'
[19:08] <blkperl> oh.. thats janky
[19:08] <slangasek> in trusty, sssd is marked Multi-Arch: foreign, which fixes this problem
[19:10] <blkperl> can we get an SRU update? :)
[19:10] <slangasek> probably not, given the trivial workaround
[19:10] <slangasek> but you could ask, the maintainer might care enough to do it
[20:15] <tgm4883> blkperl, when you said it threatened you I imagined a "you sure you want to remove these packages? It would be a shame if something happened to your computer....."
[20:40] <blkperl> tgm4883: :)