[00:33] <Kopfgeldjaeger> n8
[00:35] <bobesponja> bug 1
[00:35] <ubotu> Launchpad bug 1 in ubuntu "Microsoft has a majority market share" [Critical,In progress] https://launchpad.net/bugs/1
[01:55] <chowmeined> are there any plans to add like a way to detect which ACPI settings to use? like some kind of auto ACPI configuration system that will allow suspend etc work on more machines?
[02:01] <sladen> chowmeined: could you spec it;  the man question would be /how/ to present such an interface?
[02:01] <chowmeined> no interface, just uses like dpkg-reconfigure and runs a bunch of tests to detect the configuration, the drivers in use etc.. then sets whatever needs to be tweaked to make suspend work for that config
[02:02] <chowmeined> for example, i just installed ubuntu 7.10 on a latitude d600.. to make suspend work, only a few settings in /etc/default/acpi-support needed to be changed
[02:03] <chowmeined> so.. why not automate that
[02:16] <sladen> chowmeined: in the cases where the settings /are/ known, they are automated
[02:17] <chowmeined> oh ok, so where can i add rules? id like to submit to wherever these need to go so they can be fixed for these types of computers
[02:17] <sladen> chowmeined: see /usr/share/acpi-support/Dell*.config
[02:17] <chowmeined> ok, thanks
[02:18] <sladen> chowmeined: yes, bank on, once you figure out the correct rules for your machine, (and how to identify it), https://launchpad.net/ubuntu/+source/acpi-support/+filebug with the name of your laptop in the subjet
[02:19] <chowmeined> ok, i work for an organization and we have lots of types of computers (standard model dells but).. it'd be nice to have them automatic for hardy
[02:20] <chowmeined> i plan on testing hardy alphas extensively on our systems to make sure they will work
[02:21] <sladen> chowmeined: that would be very helpful;  there'll be a switch to pm-utils so that will need testing across them
[02:22] <sladen> chowmeined: and if the testing is done before release, it should make it into the final release for Hardy
[02:22] <chowmeined> is there a blueprint for that?
[02:22] <chowmeined> i guess i can google for it
[02:22] <sladen> the pm-utils switchover, no, I don't think so
[02:23] <sladen> https://blueprints.launchpad.net/ubuntu/+spec/pm-utils-integration
[02:23] <chowmeined> oh there it is
[02:56] <mneptok> insobox: could you please change your client's $REALNAME?
[02:56] <mneptok> and ident
[02:57] <LaserJock> hmm, I didn't know you had ops ;-)
[02:58] <mneptok> LaserJock: i don't tell anyone, as i want people to have faith and trust in the project :)
[04:35] <boitono> You lazy nerds!  Your new update crashed his computer, tell my boyfriend how to fix it NOW!!
[04:36] <somerville32> boitono: Hello. Please see #ubuntu for support.
[04:37] <Keybuk> boitono: first we'd have to know the problem
[05:01] <ebrahim> persia, Salaam!
[05:02] <persia> ebrahim: Shalom
[05:02] <ebrahim> persia, Are you Persian?
[05:06] <persia> ebrahim: No (and my Farsi is weak).  I was assigned this username when I first received a unix account (ages ago), and maintain it out of tradition.
[05:07] <mneptok> ebrahim: wa-aleykum a-salaam :)
[05:07] <ebrahim> persia, :D nice! You've been lucky to receive such a username.
[05:08] <persia> ebrahim: Yes, indeed :)
[05:08] <ebrahim> mneptok, :) Do you know Persian? or Arabic?
[05:08] <mneptok> ebrahim: no, i'm an American. :)
[05:09] <mneptok> ebrahim: Euro-American, precisely
[05:09] <ebrahim> mneptok, so were do you know the answer to Salaam?
[05:09] <mneptok> ebrahim: i care about manners and etiquette?
[05:09] <mneptok> :)
[05:10] <mneptok> bismillah, no? :)
[05:10] <ebrahim> mneptok, :) Yes!
[05:15] <soren> Adri2000: Sure, just go ahead with the pbuilder merge.
[05:17] <Hobbsee> soren: congratulations, oh new overlord
[05:18] <soren> Hobbsee: er?
[05:18] <Hobbsee> soren: MC
[05:19] <soren> Hobbsee: I've been stuck on a plane all day. I haven't a clue :)
[05:19] <soren> Hobbsee: Oh, cool.
[05:19]  * soren goes t osee the results
[05:21] <soren> The so-called hi-speed internet at this hotel is not very impressive.
[05:22] <Hobbsee> hah
[05:22] <Hobbsee> how fast is it?
[05:22] <soren> That's a very impressive vote.
[05:22] <Hobbsee> they're probably comparing it to au
[05:23] <soren> I think they're comparing it to smoke signals.
[05:23] <soren> Bad ones.
[05:24] <slangasek> I'm content to compare it to .au
[05:26] <Hobbsee> haha
[05:26] <Hobbsee> soren: have you found the beer yet, though?
[05:27]  * Hobbsee is greatful that sevilla had a good internet connection.  at least downstairs.
[05:27] <soren> Oh yes. There's a reason I'm still aweake.
[05:27] <soren> And can't spell "awake"
[05:27] <soren> (the last bit is not really true)
[05:28] <soren> It's hard to type properly with this much latency between key press and the character showing up on the screen.
[05:30] <Hobbsee> soren: just how bad is it?
[05:30] <Hobbsee> soren: like, what speed are you actually getting?
[05:32] <jdong> soren: ooh you're at the hotel?
[05:32] <jdong> soren: does the hotel use MIT internet, or the hotel chain's?
[05:32]  * jdong looks out his window in the direction of the hotel :)
[05:33] <mpt> Hotel chain's
[05:34] <jdong> mpt: oh well, that sucks :(
[05:34] <soren> Hobbsee: From the time I press a key until I see the character, I'd guess it's slightly less than a secon.d
[05:35] <soren> jdong: I have no clue.
[05:35] <jdong> soren: are you on the <IP_ADDRESS>/8 subnet?
[05:35] <soren> Nope.
[05:35] <slangasek> eew? 18.?
[05:35] <soren> <IP_ADDRESS>/16
[05:36] <soren> Oh, publically?  I expect elmo has set up something decent downstairs.
[05:38] <soren> Otherwise, I'll go nuts.
[05:38] <jdong> soren: just come on campus and steal some drops :)
[05:38] <Hobbsee> if he can get off the netsplitting server, taht'd help :P
[05:39]  * soren needs sleep
[05:39] <ajmitch> already? :)
[05:39] <soren> It's 6:40 AM in my body's timezone.
[05:39] <jdong> soren: pfft in MIT time that's the finishing touches on a problem set :)
[05:40] <ajmitch> jdong: I thought that was when you started assignments?
[05:40] <jdong> ajmitch: shhh ;-)
[05:40] <soren> jdong: Does your day start at 1 AM in MIT time?
[05:40] <jdong> soren: days never end in MIT time :)
[05:40] <soren> jdong: :p
[05:40] <jdong> until a suicide monday, then we finally get 24hr sleep :)
[05:40]  * soren goes to sleep
[05:40] <soren> g'night.
[05:40] <jdong> night
[05:41] <Hobbsee> night soren
[06:08] <blahdeblah> Hi.  Does anyone know whether there is an effort within Canonical or the Ubuntu community to create a web-based update management service for Debian & Ubuntu machines (i.e. an equivalent to RHN for Red Hat or WSUS for Windows)?
[06:08] <blahdeblah> Before i embark on such an endeavour, are there any efforts in this area that i should check out?  (Adapting another distribution's tool?  As a module of a larger monitoring/management package?)
[06:10] <Hobbsee> blahdeblah: landscape sounds similar, but i don't know of the details
[06:10] <blahdeblah> Hobbsee: Got a link?
[06:11] <Hobbsee> blahdeblah: i'd guess https://launchpad.net/landscape but i'm not affiliated with it, so cant tell you more
[06:12] <blahdeblah> Cool - thanks.
[06:22] <Mithrandir> hi Hobbsee
[06:22] <Hobbsee> Mithrandir!
[06:22]  * Hobbsee hugs Mithrandir, then stomps on his feet
[06:22] <Hobbsee> Mithrandir: you in boston yet too?
[06:22] <Mithrandir> I'm lying in bed, pondering breakfast, so please don.t
[06:23] <Mithrandir> no, incoming plane from Oslo was delayed, so I missed my connection
[06:23] <Hobbsee> urgh :(
[06:23] <Mithrandir> plane leaves in about 3.5 hours
[06:23] <Hobbsee> i'm surprised the sydney people didnt get delayed too, (on the sydney flight)
[06:23] <Hobbsee> ahhh
[06:23] <stgraber> Mithrandir: :(
[06:24] <Mithrandir> shit happens, I'll be around tomorrow
[06:26] <Hobbsee> Mithrandir: true.  less beer for you, then.
[06:27] <Mithrandir> indeed. :-(
[06:28] <Mithrandir> but I got maemo mapper up and running here, which is nice.
[06:29] <Hobbsee> :)
[06:32] <ajmitch> GPS app?
[06:33] <Mithrandir> ajmitch: yup
[07:04] <ebrahim> Where can I find info on ubuntulog?
[07:26] <imbrandon> ebrahim, i'm pretty sure its one of seveas's bots , prod him
[07:29] <ebrahim> imbrandon, found https://help.ubuntu.com/community/InternetRelayChat#head-3764552ccef65ea78b1fd8d16bee097a5ca6c76c in #kubuntu-devel ;)
[08:50] <Amaranth> imbrandon: iirc fabbione actually runs ubuntulog
[10:31] <Kopfgeldjaeger> hi
[10:43] <ksivaji> is it possible to integrate kget with opera
[12:36] <pitti> Good morning
[12:36] <Hobbsee> morning pitti!
[12:36] <StevenK> Morning pitti
[12:36]  * pitti hugs Hobbsee from the US east coast
[12:36]  * Hobbsee hugs pitti back from australia
[12:38] <Hobbsee> pitti: how many people have you hugged in the last 24 hours, then?  :)
[12:39]  * Hobbsee suspects pitti went on a mass hug-a-thon
[12:39] <pitti> Hobbsee: not that many yet actually, I arrived pretty late, so I only met 10 guys or so
[12:40] <Hobbsee> pitti: awww
[12:50] <Kmos> ubotu is down, anyone can re-start it ?
[12:51] <Hobbsee> news at 11.
[12:51] <Hobbsee> Kmos: if they could have, they would have already done so.  long ago.
[12:51] <Kmos> :-)
[12:51] <Hobbsee> and htey cant from here anyway
[12:52] <Kmos> Hobbsee: maybe only seveas has access to it
[12:52] <Hobbsee> Kmos: and based on the fact that seveas is not in this channel...
[12:52] <Kmos> he's not on irc :(
[12:53] <Hobbsee> which probably means that his, and ubotu's connection is broken.
[12:54] <Kmos> ok
[13:30] <Adri2000> soren: pbuilder merge : http://adrishost.homeip.net/~adri2000/ubuntu/toupload/pbuilder_0.174ubuntu1.debdiff ; I changed gutsy to hardy in pbuilderrc. this is not test-built yet because of some latex unmetdeps.
[13:31] <Hobbsee> Adri2000: he'll be at breakfast
[13:32] <Hobbsee> Adri2000: pbuilder depends on latex now?
[13:36] <Adri2000> Hobbsee: build-depends on dblatex yes
[13:37] <sits> hi there
[13:37] <sits> is this the wrong channel for Launchpad devs?
[13:37] <Kmos> sits: #launchpad
[13:37] <sits> Kmos: thank you
[13:37] <Hobbsee> Adri2000: how weird.
[13:37]  * minghua heard some story about texlive stuff uninstallable in hardy, too.
[13:39] <Adri2000> Hobbsee: it seems to be used for the doc
[13:39] <Hobbsee> Adri2000: ahhh, okay.
[13:39] <persia> Two problems: imbalanced builds (should be OK soon), and an update required to libkpathsea.  Not huge, but needs attention.
[13:43] <minghua> persia: Do you know more details about the required update to libkpathsea?  Is it poppler related?
[13:45] <Burgundavia> popey: you around?
[13:47] <persia> minghua: I'm not entirely sure.  I'm guessing it's security related.  Should be fixed with when the merge is done.
[13:52] <minghua> persia: I see, thanks.
[14:02] <Hobbsee> Kmos: hi.  i see removal requests.  if any are wrong, should i mark them as wontfix, yell at you, get someone else to fix them, or all of the above?
[14:02] <Hobbsee> Kmos: as a start, do all the packages actually *exist* in ubuntu?
[14:05]  * Hobbsee does not plan to spend time explaining, for you to then "forget" in an hour.  again.
[14:06]  * popey is around
[14:06] <popey> shame burgundavia isn't
[14:09] <sladen> popey: you made it?
[14:10] <popey> yes
[14:10] <popey> there was a mess up on the trains, so we ended up getting a bus part of the way
[14:11] <popey> i wrote it up on the uds page in case others need that info
[14:11] <popey> quite a number of canonical ppl here already
[14:11] <popey> sladen: when do you get here?
[14:11] <sladen> popey: *cough*.  get where... ?
[14:12] <Kmos> Hobbsee: the ones to remove exists at ubuntu
[14:12] <Fujitsu> Kmos: Have they been removed from Debian already?
[14:12] <Kmos> Fujitsu: yep
[14:12] <persia> Kmos: Are they required to support upgrades from Dapper?
[14:12] <Fujitsu> Aren't Debian removals processed automagically>
[14:12] <Fujitsu> *?
[14:12] <sladen> popey: made it to Reykjavík, have a talk to the LUG in an hour an a half
[14:12] <popey> ahhh
[14:12] <persia> Fujitsu: Depends.  Not usually.
[14:13] <popey> when do you hit boston?
[14:13] <Kmos> persia: that i don't know, if they'll break the upgrade
[14:13] <mjg59> popey: Hm. Silver+Red sounded easier, really...
[14:13] <persia> Kmos: You'll want to test that before the package gets removed.  We need to support Dapper upgrades for a while yet.
[14:13] <popey> yeah, we had 5 people each with different directions
[14:13] <popey> christ knows how
[14:14] <popey> mine was a print of the wiki page which was deemed "to verbose" so was dismissed :)
[14:14]  * Hobbsee hums, taps fingers.
[14:14] <Hobbsee> i wonder how hard it would be to find the old log, to save persia a whole lot of typing.
[14:14] <persia> Hobbsee: If it weren't for repeating things, I'd have nothing to say :)
[14:15] <Kmos> persia: one of them is merged into first package.. bug 157659
[14:15] <persia> Kmos: You don't have to tell me.  You have to explain in the bug, clearly enough that there's no question, and document all your testing.
[14:15] <Hobbsee> Kmos: that *doesn't* say if it's goign to break when upgrading from dapper.
[14:15] <mjg59> Time for some switft breakfast, I think
[14:15] <Kmos> https://bugs.edge.launchpad.net/ubuntu/+source/lckdo/+bug/157663 -> this one is now included in moreutils
[14:15] <Ubotwo> Launchpad bug 157663 in lckdo "Please remove lckdo from Ubuntu Hardy" [Wishlist,New]
[14:16] <Hobbsee> mjg59: yes.  leave this channel, before you start throwing things at the wall
[14:16] <Hobbsee> TheMuso!
[14:16] <Hobbsee> Kmos: now actually read what persia said.
[14:16] <popey> breakfast was indeed good mjg59
[14:16]  * popey ate too much bacon
[14:16] <Hobbsee> mmm...bacon
[14:16] <popey> for a given definition of $too_much
[14:16] <Kmos> Hobbsee: i need to explain.. i think i've explained in description, i try to explain the best
[14:17]  * StevenK didn't have any bacon.
[14:17] <Chipzz> persia: well, to be honest, I don't think it's fair to hold that particular thing against Kmos... I don't dare to start yo imagine how many packages were removed during the past 3 release cycles without taking that into consideration
[14:17] <Hobbsee> Kmos: clearly you *havent* else we wouldnt be telling you what we were above.
[14:18] <persia> Chipzz: LTS.  Hardy is the next LTS.  We *must* support Dapper -> Hardy upgrades.
[14:18] <Chipzz> persia: I *know* that
[14:19] <Hobbsee> Chipzz: most people actually thought about things (as in, the case where something is replaced by something else), and fixed them.  Kmos doesn't.
[14:19] <Chipzz> persia: but it's very much possible similar breakage already *was* caused during the edgy/feisty/gutsy cycles by some oversight when removing packages...
[14:19] <persia> Chipzz: Perhaps you're right.  I'll check the removal logs.
[14:20] <Chipzz> persia: can you be 100% sure that no-one has made such a mistake yet? I think you can't...
[14:20] <Hobbsee> Chipzz: btw, the sponsors tend to catch that sort of thing.  which is why kmos got such a grilling over it last time.
[14:20] <Hobbsee> Chipzz: we cant.  but 2 wrongs dont make a right, and at least attempting to get the vast majority correct would be good.
[14:20] <persia> Chipzz: No, I can't.  That's why I'm checking.
[14:21] <Hobbsee> persia: i wonder if there's a script that can check it all.
[14:21] <Hobbsee> persia: as in, dapper --> gutsy upgrade, and see what falls over
[14:22] <persia> Hobbsee: One could create such a script.  Set up a chroot.  debootstrap Dapper.  Install everything from the removal log.  dist-upgrade.  Trap errors.
[14:22] <Chipzz> persia: uptil now dapper -> hardy upgrades were barely considered; I am pretty darn sure that, especially early in the edgy cycle, this was not taken into consideration/overlooked
[14:23] <Hobbsee> Chipzz: uh, no.  they've *long* been getting considered.
[14:23] <Hobbsee> Chipzz: what evidence do you have for your claim?
[14:23] <persia> Chipzz: I'm not sure about that.  I know we are keeping a number of transition packages just for that reason.
[14:23]  * Hobbsee doesnt even recall Chipzz working with packages.
[14:24] <Chipzz> Hobbsee: I don't, but I tend to be fairly familiar with debian and ubuntu, and I read most of what's being said in here (but in most cases I tend to keep out of the discussion)
[14:24] <Hobbsee> Chipzz: based on how it's usually spoken about in -motu
[14:25] <Hobbsee> i can see why you would see it's not said here.
[14:25] <Hobbsee> all the main people *know* that they have to support dapper --> hardy, so there's no need to discuss it, is there?
[14:25] <Hobbsee> therefore, i cant see your claim as being valid :)
[14:25] <persia> Chipzz: That's probably it.  Most of the "we keep until later" discussion has happened in candidate removal bugs.
[14:25] <StevenK> There's a need to dicuss *how*, but not *why*
[14:25] <Chipzz> Hobbsee: also, I have seen remarks that testing dapper -> hardy upgrades was only going to get started to be tested during the hardy cycle
[14:25] <Hobbsee> Chipzz: actual physical testing.  yes.
[14:26] <Hobbsee> Chipzz: but it's not hard to go "i'm removing something, it's being replaced by something else, i'll fix it while i'm at it".  that's very different from physical testing.
[14:27] <Riddell> (FOSSCamp in #fosscamp)
[14:27] <Chipzz> Hobbsee: the bottom line of what I'm saying is, while I'm not a big fan of Kmos at all, I *do* think you (plural) are being a bit harsh on him with regard to to the dapper -> hardy issue
[14:28] <Chipzz> I think he'll not be the only one to oversee such issues
[14:28] <Chipzz> s/oversee/overlook/
[14:28] <Kmos> Chipzz: i'm the black cheap =)
[14:29] <Chipzz> Kmos: and with good reason for that too...
[14:29] <Kmos> Chipzz: not always
[14:29] <Hobbsee> Chipzz: all the people get grilled on it
[14:30] <Hobbsee> Chipzz: of course, usually people understand the problem a little quicker, and only need the explanation once.
[14:30] <Kmos> the are here to learn, and things from the past, shouldn't be merged with the present
[14:30] <Kmos> Hobbsee: and you know if it will break or not ? you talk to me as I'm a MOTU and not a user that likes to contribute
[14:31] <Hobbsee> Kmos: aren't you attempting to become a MOTU?
[14:31] <Chipzz> Kmos: but I do agree that archive removal requests are best let to people intimitaly familiar with the archive
[14:31] <Hobbsee> Kmos: your wiki page says as much
[14:31] <Hobbsee> Kmos: i dont really care who you are - i care if you repeatedly try to break the archive - no matter who it is.
[14:31] <Chipzz> s/let/left/
[14:31] <Kmos> Hobbsee: i don't say there i won't be one right now
[14:31] <Kmos> *want
[14:32] <Kmos> i need to learn a lot of things first
[14:32] <Kmos> and with that, come my mistakes
[14:32] <Hobbsee> so, to you, consistent mistakes on the same issues are perfectly acceptable, because you're only a user trying to help, not a guy wanting upload rights?
[14:32] <Kmos> Chipzz: i just check some debian removals, and two of my requests are merged into another packages that are already in hardy
[14:33] <Kmos> Hobbsee: i like you to consider me as that now.. when I officially candidate as MOTU, you can give me right in the head
[14:34] <Kmos> Hobbsee: i'll remove it from my wiki =)
[14:34] <Hobbsee> Kmos: has it occured to you that there are other people who also want to help out, and if you consistently use up the majority of help on offer, due to not actually learning anything, and making the same mistakes over and over again, that you're not helping, and you're just wasting our time?
[14:35] <Kmos> Hobbsee: yeah.. but in that questions of upgrade breakage.. you don't think you're asking too much for me, even you don't know if it will break
[14:35] <Kmos> or not
[14:36] <Kmos> wiki is updated
[14:36] <Hobbsee> ...
[14:36] <minghua> Kmos: No, I don't think Hobbsee is asking too much.
[14:37]  * Hobbsee ponders any sane response that comes up from that.
[14:37] <Hobbsee> beyond writing to the mailing list, posting this log, and saying that kmos is clearly unsuitable - and that prefernece of help should be given to those who actually listen to it, and care about getting things right.
[14:37] <Kmos> Hobbsee: do what you want..
[14:38] <minghua> Kmos: If you are proposing a removal, you are supposed to know if it will break things or not, not Hobbsee.  If Hobbsee has questions, you'd better have good answers, or at least a "sorry, I didn't think about that, I'll think about now", and add that to bug report.
[14:38] <Kmos> minghua: i've commented bug 157663
[14:38] <Kmos> because of that
[14:39] <Hobbsee> mneptok: i think i have a job for you.
[14:39] <Hobbsee> Kmos: why dont you care about getting the stuff right?
[14:39] <minghua> bug 157663
[14:39] <Fujitsu> minghua: ubotu is dead.
[14:39] <Hobbsee> minghua: i dont think this bot supports that
[14:39] <Hobbsee> Ubotwo: ping
[14:39] <Ubotwo> pong
[14:39] <minghua> bug #157663
[14:40] <Hobbsee> Ubotwo: bug 157663
[14:40] <Ubotwo> Hobbsee: Error: "bug" is not a valid command.
[14:40] <Hobbsee> nope
[14:40] <Fujitsu> Hah.
[14:40] <minghua> Oh well.
[14:40] <Kmos> Hobbsee: I care, but I don't know everything.. if i've written all the things needed
[14:40] <Hobbsee> Kmos: yet, when you get things explained to you, you dont seem to listen and actually remember the stuff.  at all.
[14:40] <Hobbsee> hwo do you explain that?
[14:42] <minghua> Hobbsee: So someone explained the LTS->LTS upgrade issue to Kmos before he filed bug 157663?
[14:42] <Hobbsee> minghua: oh yes.  crywrap removal, to stunnel4
[14:42] <Hobbsee> minghua: he finally got it, then.
[14:43] <Hobbsee> minghua: that was feisty.  i know, because i had the honours.
[14:43] <Kmos> Hobbsee: you don't have never explained me about this thing of removal package and how to do it.
[14:43] <Hobbsee> Kmos: do you want me to show you the fscking logs?
[14:43] <minghua> Hobbsee: ...right.  I won't waste my time here, then.
[14:43] <Kmos> Hobbsee: don't needed
[14:44] <Kmos> it's lunch time
[14:44] <Hobbsee> Kmos: really, don't lie, when things are publically logged.
[14:44] <Hobbsee> all it will prove is how you are.
[14:44] <Hobbsee> er, how you are lying.
[14:44] <Kmos> Hobbsee: you told me about that crywrap -> stunnel4
[14:45] <Hobbsee> Kmos: which was the LTS->LTS upgrade stuff.
[14:45] <Kmos> Hobbsee: https://bugs.edge.launchpad.net/ubuntu/+source/singularity-data/+bug/157659
[14:46] <Ubotwo> Launchpad bug 157659 in singularity-data "Please remove singularity-data from Ubuntu Hardy" [Wishlist,New]
[14:46] <Kmos> this one won't break anything
[14:46] <Kmos> it's merged into singularity package
[14:46] <soren> Where's ubotu?
[14:46] <Kmos> i think it won't break
[14:46] <Kmos> soren: down
[14:47] <persia> Kmos: Please document the reasoning in the bug, rather than in IRC.  The people who will make the final decision need to see the documentation, regardless of whether it works, or if we all agree.
[14:47] <Hobbsee> soren: seveas' connection appears to have fallen over
[14:47] <ScottK> Kmos: This isn't the first time you've been grilled over not getting removal requests right.
[14:49]  * Kmos lunch time
[14:49] <Kmos> ScottK: I know =)
[14:50] <ScottK> Kmos: There is really no point in going through telling you stuff, you forget, make the same mistakes, and we tell you again and it's a big suprise to you every time.
[14:50] <Hobbsee> ScottK: but remember, according to kmos, he's only a user who wants to help, so shouldnt be required to actually get things right.  unless i'm misreading what he says above, of course.
[14:50] <ScottK> Kmos: You REALLY need to find something to focus on that you do, in fact, know how to do.  I've no idea what that would be, but please find it.
[14:51] <Hobbsee> ScottK: getdeb, perhaps?
[14:51]  * ScottK <-- AFK - Has better things to do.
[14:52] <ScottK> Hobbsee: No, it's fairly clear he doesn't know how to package software.
[14:52] <soren> Hobbsee: I'm just reading a bit of backscroll here.. Is the dapper->hardy upgrade stuff documented on the wiki somewhere?
[14:52] <Hobbsee> soren: it's certainly in a spec
[14:52] <Hobbsee> soren: and has been discussed since dapper.
[14:52] <soren> I know, I know.
[14:52] <soren> I'm just wondring if it's appropriately linked on the MOTU pages or some such.
[14:52] <Hobbsee> so, it will be in the wiki somewhere, yes.
[14:52] <Hobbsee> soren: unsure, tbh.  we usually raise it with people when they do their first removal request, etc.
[14:53] <persia> soren: It may not be.  We don't tend to provide much prescriptive documentation, more information on how to use tools and processes, rather than what to do with them.
[14:54] <minghua> soren, Hobbsee: In the lckdo removal case (bug 157663), I think gutsy->hardy upgrade is affected, so it's not only LTS->LTS upgrade issue.
[14:54] <soren> persia: Yeah. I'm just thinking it might be worth the time to actually write this particular bit down.
[14:55] <persia> soren: Perhaps.  I'm tempted to wait until after the MOTU wiki cleanup is more complete before adding much, just to reduce the coordination headache of the transition.
[15:13] <Hobbsee> Kmos: new packages get done by the autosyncer, btw.
[15:14] <Hobbsee> Kmos: how do you thikn that all the other new packages get in?  someone requesting them all individually?
[15:15] <StevenK> I didn't think the autosyncer did that.
[15:15] <StevenK> I thought they were done semi-automatically by -archive guys
[15:16] <Hobbsee> StevenK: well, they get stuck in source new, sure, but afaik, they get pulled there by the autosync
[15:17] <StevenK> Hrm. I'll bug pitti when I see him
[15:17] <Hobbsee> freecol
[15:17]  * Hobbsee goes to look
[15:17] <Fujitsu> It's not the normal autosyncer, but there is another script run manually every so often that pulls them in.
[15:19] <Hobbsee> Fujitsu: ahhh.
[15:19] <Hobbsee> Fujitsu: based on the size of the new queue, i'm unsurprised that they haven tdone it yet
[15:20] <persia> In gutsy, the NEW queue was processed agressively starting around mid-UDS.  I would expect the same this time.
[15:20] <Fujitsu> Hobbsee: As well as the build queue being too big for Soyuz to handle properly, yeah.
[15:21] <Hobbsee> persia: when people got bored of sessions?  *g*
[15:21] <Hobbsee> Fujitsu: fun
[15:21] <persia> Hobbsee: I can't speak to motivation :)
[15:27] <Kopfgeldjaeger> bcm43xx firmware makes 23 GB traffic in one week
[15:53] <Hobbsee> hiya jono
[15:56] <Hobbsee> agoliveira
[15:56] <Hobbsee> bah.
[15:57]  * Hobbsee kicks her tab completion
[16:00] <calc> Hobbsee: hi
[16:00] <Hobbsee> hi calc!
[16:16] <StevenK> jono: You know, your laptop comes with a keyboard. :-P
[16:18] <agoliveira> Hobbsee: Did you call me?
[16:18] <Hobbsee> agoliveira: only by accident.
[16:18]  * agoliveira feel unloved :(
[16:18] <StevenK> Awww
[16:19]  * StevenK tickles agoliveira more
[16:19]  * agoliveira moves to other room
[16:20]  * Hobbsee hugs agoliveira
[16:21]  * agoliveira wipe the tears and see the sunshine for the first time today...
[16:22] <Hobbsee> agoliveira: you can tell everyone else at the conference that you shouldnt all get klined now.
[16:22]  * agoliveira is eating the "s" today...
[16:22] <lifeless> Hobbsee: thanks!
[16:22] <Hobbsee> agoliveira: that can be your calling :)
[16:22] <Hobbsee> lifeless: :)
[16:23] <lifeless> now if only I irc'd from the conference so that I'd care :)
[16:23]  * StevenK smirks
[16:23] <Hobbsee> lifeless: they havent put the cloak in yet, but they should realise it's a harmless IP - at least, if they've read their mail.
[16:23] <jono> StevenK: hehe
[16:24] <StevenK> jono: You don't like the laptop keyboard?
[16:24] <ompaul> Hobbsee, as soon as they see the mail they should wrap the cloak aound it - can only be done by senior staffers
[16:25] <Hobbsee> ompaul: yeah, thought so.
[16:29] <Hobbsee> guten tag, ogra
[16:29] <Hobbsee> found any nice cats yet?  :)
[16:29] <ogra> hallo sarah
[16:30] <ogra> nope, boston seems to be no cat city
[16:30] <Hobbsee> awww
[16:30] <ogra> at least not one for stray cats :)
[16:30] <Hobbsee> aww
[16:33]  * ScottK imagines stray cats being unlikely to survive the Boston winter.
[16:34] <ogra> which winter ?
[16:34] <Hobbsee> boston has *multiple* winters?
[16:35] <stgraber> well, it's warmer here than in switzerland :)
[16:35]  * Hobbsee thinks that violates all that she learnt about seasons :)
[16:35] <Hobbsee> stgraber: what's the normal temp of switzerland/
[16:35] <ogra> i mean ... i brought all these warm sweaters and now is sit here in a t-shirt... sweating
[16:35] <ogra> s/is/i/
[16:35] <Hobbsee> ogra: ah.  hence, s/which/what/
[16:35] <stgraber> Hobbsee: was something like 2°C the day before I left :)
[16:35] <ogra> ah
[16:35] <Hobbsee> stgraber: oof.
[16:35] <ogra> same in .de
[16:38] <ogra> hah !
[16:38]  * ogra just found out why his evolution crashes all the time ...
[16:38]  * ogra reboots
[16:59] <TheMuso> ogasawara: The hotel is too warm IMO.
[16:59] <TheMuso> ugh
[16:59] <TheMuso> ograThe hotel is too warm IMO.
[17:00] <stgraber> TheMuso: +1
[17:00]  * TheMuso opened the window in his room to let some fresh air in. it was crazily warm overnight. I didn't sleep with much on me.
[17:01] <TheMuso> As in, bed clothes.
[17:01] <calc> any gnome/totem devs around?
[17:01] <calc> i have an ogg that appears to crash totem on 7.10
[17:02]  * stgraber sleeps well, having no sleep for 40hours certainly helped :)
[17:02]  * calc needs to hunt down seb128 here on the 3rd floor to show him
[17:03] <TheMuso> stgraber: Aye.
[17:03] <TheMuso> stgraber: i had a 20 hour trip, ad only managed to get 2 hours of sleep, if htat.
[17:03] <TheMuso> and even
[17:03] <TheMuso> And even now I am still a little tired, as I got up earlier than I really needed to it seems.
[17:04] <stgraber> TheMuso: I maybe slept for 30min in the plane but not much more, way too noisy and I don't seem to easily sleep in plane
[17:04] <TheMuso> stgraber: I can sleep most places, but planes are the exception, so I know what you mean.
[17:04] <calc> i found that i must be allergic to down, woke up with red itchy eyes
[17:05] <TheMuso> calc: Re that ogg, have you looked atht ehtags with vorbiscomment? Could there be anything in the tags that could cause totem to crash? And have you tried totem-xine?
[17:05] <TheMuso> ugh typing not soo good either. :p
[17:05] <calc> haven't tried totem-xine yet
[17:05] <TheMuso> mm ok.
[17:06] <stgraber> if that works with -xine, best would be to find another gstreamer based movie player and try with it
[17:06] <stgraber> so you can check if that's totem or backend related
[17:06] <calc> yea
[17:08] <calc> hmm actually its not vorbis its an ogg video so vorbiscomment pukes on it
[17:09] <stgraber> calc: maybe ogmtools and ogminfo
[17:09] <stgraber> (never used it)
[17:13] <calc> hmm its actually not the file
[17:13] <calc> X Error of failed request:  BadAlloc (insufficient resources for operation)
[17:13] <calc> i keep getting that for some reason
[17:13] <calc> it happens in totem-gstreamer totem-xine xine so far
[17:13] <Hobbsee> memory?
[17:14] <calc> i have plenty free
[17:14] <calc> bryce_: any ideas what cause that?
[17:16] <calc> Riddell: you are next to me... any ideas what cause BadAlloc when you aren't low on ram for displaying stuff in X?
[17:16] <seb128> calc: looks like a video driver issue
[17:16] <mvo> calc: compiz?
[17:16] <seb128> or that
[17:16] <calc> no compiz here
[17:17] <calc> on i945
[17:17] <Hobbsee> mvo!
[17:17] <Riddell> calc: do other videos work?
[17:17] <seb128> intel or i810?
[17:17] <mvo> hey Hobbsee
[17:17] <calc> i810 that should be intel, right?
[17:17]  * calc wonders why it was set to i810
[17:17] <seb128> you can try the other one
[17:18] <StevenK> Hrm. Mine is currently set to i810
[17:20] <calc> works
[17:22] <calc> so it didn't like the i810 driver apparently
[17:22] <TheMuso> Lovely.
[17:25] <blueyed> calc: we have a fix ready for the gtk crash in OOo (bug 131526). Can you sponsor the upload/look at it?
[17:29] <calc> blueyed: for hardy?
[17:29] <calc> blueyed: i have a bunch of fixes to go in for gutsy-updates if that is what you are positioning it for
[17:30] <blueyed> calc: for hardy and gutsy-proposed
[17:30] <blueyed> calc: sweet! I've just found bug #155125, too - which has a patch also already.
[17:31] <calc> blueyed: can you email me at<EMAIL_ADDRESS>with this log and any other information you think is pertinent
[17:31] <calc> i am running to another meeting, bbia 5m
[17:31] <blueyed> calc: ok
[17:37]  * calc back
[17:37] <calc> blueyed: when things calm down a bit i plan on uploading to a ppa for testing the fixes
[17:39] <blueyed> calc: you don't want to do this.. I've been accused of causing DOS with my OOo upload. And actually the i386 build is likely to fail anyway.
[17:39] <timbobsteve> can I ask a question about custom usplash? or should I ask in #ubuntu ?
[17:41] <calc> blueyed: that is why it will be in a ppa
[17:41] <calc> blueyed: vs gutsy-proposed
[17:41] <calc> blueyed: https://help.launchpad.net/PPAQuickStart
[17:41] <Hobbsee> calc: give it a few days - people want to get *some* stuff built in between 3 ooo uploads, and a whole bunch of langpacks
[17:42]  * calc must be confused about what other OOo uploads
[17:42] <Hobbsee> calc: buildds are unusable for anyone else at the moment - have been for a couple of days
[17:42] <blueyed> calc: I've been talking about my ppa. i386 is likely to fail there (at least my build failed)
[17:42] <calc> blueyed: ah ok
[17:43] <calc> i'm waiting to see what other major bugs pop up, and i would like to get openoffice.org-base issue resolved as well in 1ubuntu5.2 if possible
[17:43] <calc> i'm not sure yet how much work that will be
[17:45] <calc> you uploaded 3 ppa's in one day?
[17:45] <Hobbsee> calc: 2 days.
[17:45] <calc> ok so probably within 24hr anyway ;)
[17:45]  * Hobbsee didn't check the hours :)
[17:45]  * calc thinks he is trying to kill the buildds ;
[17:45] <calc> ;)
[17:45]  * Hobbsee just went looking for "why are people complaining about why their stuff isnt built yet"
[17:46] <calc> ppa is autobuilt right?
[17:46] <StevenK> I think the autosyncer ran as well.
[17:47] <Hobbsee> calc: it does the queue automatically, yes
[17:48] <calc> Hobbsee: ok
[17:48] <Hobbsee> calc: and main gets preference, i expect
[17:48] <StevenK> Main does
[17:49] <Hobbsee> yes, but i'm unsur ehow much of that goes for ppa too
[18:26] <bryce_> calc: sounds like the -intel bug in Xv Peter has a fix for perhaps; I can point you at the .deb later if you want to see if it fixes
[18:48] <joejaxx> jono: there is an existing blueprint for live-cd-share-live-cd i proposed it for uds-boston on lp
[19:26] <Supremus> pitti, hello
[19:26] <Supremus> pitti, could you please check bug 103489
[19:35] <warsocket> where sould i go with a question about a programming technique to hide console output from other programs form my c program. I intent to submit my program to ubunut when its done.
[19:35] <dooglus> hi all.  I would like to make an ubuntu package of ImageMagick using a recent release.  Where can I find instructions for doing so?
[19:35] <warsocket> this channel or another?
[19:36] <nixternal> dooglus: https://wiki.kubuntu.org/PackagingGuide
[19:37] <dooglus> nixternal: thanks
[19:37] <nixternal> no problem...dooglus, you can also check out #ubuntu-motu for packaging help
[19:38] <dooglus> nixternal: when I make the package, is there any chance it would be used by ubuntu?  the version currently shipped is very old, and misses quite a few featues, like the ability to optimize animated gifs
[19:38] <nixternal> you can create a debdiff for the updated package, and yes there is a chance it would be used, as long as you did the package right...you could also submit it to revu.tauware.de as wel
[19:47] <Supremus> pitti, could you please check bug 103489
[19:48] <pitti> Supremus: not ATM, sorry (in a discussion round)
[19:49] <Supremus> ok
[20:16] <jdong> hmm, XSBC-Original-Maintainer trips up pdebuild-internal
[20:16] <jdong> somehow it thinks the name of the output debs is the value of XSBC-O-M
[20:16] <TheMuso> Lovel/c
[20:16] <TheMuso> ugh
[20:16] <TheMuso> lovely
[20:17]  * jdong tries to reproduce again
[20:18] <jdong> cp: cannot stat<EMAIL_ADDRESS>No such file or directory
[20:18] <jdong> reproduced
[20:20] <coffeedude> Q: printing URL for the specifications mentioned?
[20:22] <jdong>    for files in $(sed -rn '/^Files:/,${s/.* ([^ ]+)$/}' ../${CHANGES}); do
[20:22] <jdong> that's the line that must be broken
[20:25] <jdong> any sed overlords around?
[20:27] <jdong> got it
[20:30] <jdong> should SRU's to gutsy-proposed 0ubuntu1 rleease be 0ubuntu1.1, or 0ubuntu1.1~prop1?
[20:31] <jdong> soren: ping
[20:50] <StevenK> Mithrandir: You look like I feel.
[20:51] <warsocket> Whats the best approch if i'm looking for ppl to join my unifiedinstaller project (Wiki: https://wiki.ubuntu.com/Spec/UnifiedInstaller)
[20:51] <Mithrandir> StevenK: heh. :-)
[20:51] <Mithrandir> StevenK: I feel quite awake, but I'd like another beer soon.
[20:52]  * StevenK hasn't had a drink at all.
[20:52] <StevenK> I have a feeling I will be face-planting in my bed upstairs early tonight.
[20:52] <Mithrandir> I've had close to a bottle of wine today.
[20:52] <Mithrandir> I think.
[20:53] <StevenK> If you don't remember, you've drunk too much. Or too little.
[20:56] <TheMuso> StevenK: I think I'll be doing something similar. I'm awake now, but still feel somewhat tired.
[20:56] <Adri2000> Mithrandir: may I bug you to push that sru to -updates please ? https://bugs.launchpad.net/ubuntu/+source/audacious-plugins/+bug/152918 it's been more than a week and there are more than two "works for me"
[20:56] <Ubotwo> Launchpad bug 152918 in audacious-plugins "Try to replace libcurl.so from audacious-plugins-extra" [High,Fix committed]
[21:02] <Mithrandir> Adri2000: done
[21:04] <Adri2000> thanks
[21:05] <Adri2000> Mithrandir: should I update the bug or are you going to do it?
[21:05] <Mithrandir> Adri2000: please do it you
[21:05] <Adri2000> ok
[21:07] <soren> jdong: wazzup?
[21:08] <jdong> soren: saw you touched pbuilder a lot
[21:09] <jdong> soren: discovered this puppy this morning, and got a debdiff for it: https://bugs.edge.launchpad.net/ubuntu/+source/pbuilder/+bug/157867
[21:09] <Ubotwo> Launchpad bug 157867 in pbuilder "pdebuild-internal broken when XSBC-Orig-Maintainer used because of faulty sed command" [Undecided,New]
[21:09] <jdong> it's a 1-liner and should be SRU'able, and of course applied to Hardy too
[21:14] <soren> jdong: I'm a bit surprised that hasn't been triggered before.
[21:14] <jdong> soren: as am I :)
[21:14] <jdong> but the original sed matches any fields below Files:
[21:15] <soren> sure, sure, i get it :)
[21:15] <soren> But any X-* fieldn lands down there, AFAIR.
[21:15] <jdong> yeah, it appears that way
[21:15] <soren> Ah... I get it.
[21:15] <Adri2000> (don't forget there is that pending upload for hardy: http://adrishost.homeip.net/~adri2000/ubuntu/toupload/pbuilder_0.174ubuntu1.debdiff :))
[21:16] <soren> Most of the other custom fields are XS or XB, and hence don't land in changes.
[21:16] <soren> Adri2000: I know, I know.  :)
[21:17] <soren> I actually can't think of anything else that uses XC fields.
[21:44] <nachito> hi
[21:44] <nachito> hola
[21:44] <nachito> hi
[21:44] <nachito> hi
[21:44] <nachito> :(
[21:45] <mebrahim> nachito, Hi!
[21:45] <mebrahim> nachito, :D
[21:45] <nachito> hablemos en espan^ol
[21:46] <nachito> spanish??
[21:46] <SLaPoet> nachito: de donde?
[21:46] <nachito> de Chile
[21:46] <nachito> y tu ocmpadre?
[21:46] <SLaPoet> nachito: un momento
[21:47] <nachito> ok
[21:48] <SLaPoet> nachito: #ubuntu-cl
[21:48] <SLaPoet> ayudad  en espanol
[21:48] <SLaPoet> that's about all the spanish i know
[21:53] <ompaul> !es
[21:53] <Ubotwo> Si busca ayuda en Español por favor entre en los canales #ubuntu-es, #kubuntu-es o #edubuntu-es, allí obtendrá mas ayuda.
[21:59] <keescook> mvo: I have a usb stick for you
[22:06] <mvo> keescook: thanks!
[22:07] <keescook> mvo: sure!  :)  took a while to compress.  :)
[22:07] <mvo> keescook: its taking a while here to uncompress too :)
[22:08] <keescook> heh
[22:08] <simira> mvo: are you in Boston yet?
[22:08] <mvo> simira: hello! yes I am
[22:09] <simira> mvo: lucky you :p Could you rl-ping Tollef is you see him? He's been idle for an hour now, and I'd like to talk to him before I go to sleep.
[22:09] <simira> s/is/if
[22:09] <soren> How often does MoM run these days?
[22:10] <mvo> simira: sure, I will tell him if I run into him, he was here a couple of minutes ago but left the room
[22:11] <simira> mvo: thanksalot :) Have a nice time over there! (still not jealus :p )
[22:12] <mvo> simira: thanks :)
[22:27] <soren> Adri2000: Your pbuilder merge looks good, thanks. I'll merge it with jdong's patch and upload in a bit.
[22:28] <jdong> soren: fantastic, thanks
[22:29] <soren> jdong: Do you have the lin to the bug report handy?
[22:32] <jdong> soren: soren https://bugs.edge.launchpad.net/ubuntu/+source/pbuilder/+bug/157867
[22:32] <Ubotwo> Launchpad bug 157867 in pbuilder "pdebuild-internal broken when XSBC-Orig-Maintainer used because of faulty sed command" [Undecided,New]
[22:32] <soren> jd	Thanks.
[22:32] <jdong> sure thing
[22:32] <jdong> thank you :)
[22:35] <soren> Adri2000: It doesn't build due to latex annoyances.


[01:20] <bazhang> ghosthunter007 is really pushing it
[04:47] <JoseeAntonioR> hey guys, floodbot1 flooding in #u-unregged
[04:58] <IdleOne> appears to have stopped
[05:02] <JoseeAntonioR> great
[05:02] <JoseeAntonioR> thanks!
[17:52] <genii-around> Hm


[10:49] <meena> Good point
[10:50] <meena> i can't tell from the documentation a new network interface is considered
[10:51] <meena> faa: i'd have to look at the code, and chances are, before i'm able to do that, someone more experienced with the project will have woken up
[12:03] <faa> meena: thank, good news :)
[12:04] <meena> my hour of laptop time has been wasted, and now i have to go and wake my daughter from her nap
[12:09] <faa> this is not an urgent problem, but I will be glad to any advice, because as far as I can see, now cloud-init does not have the ability to change the network configuration
[13:11] <cjmm6> Hi, I need help with latest cloud-init version. In machines that not needed or not works cloud-init, I use a systemd service (I cannot use boot parameters), that using a Before=cloud-init-local.service and some conditions, then write the file to disable cloud-init /etc/cloud/cloud-init.disable (or remove this file if need use cloud-init)
[13:11] <cjmm6> This works in previous versions of cloud-init
[13:11] <cjmm6> But in the last version not works because exists one previous task called "cloud-init-generator". Then, so i don't know how to make my systemd unit run before that task
[13:13] <cjmm6> My systemd unit is:
[13:13] <cjmm6> [Unit]
[13:13] <cjmm6> Description=Control cloud-init to enable or disable cloud-init dinamically at boot time
[13:13] <cjmm6> DefaultDependencies=no
[13:13] <cjmm6> After=systemd-remount-fs.service
[13:13] <cjmm6> Before=NetworkManager.service network.service network-pre.target
[13:13] <cjmm6> Before=shutdown.target sysinit.target
[13:13] <cjmm6> Before=cloud-config.service cloud-final.service cloud-init-local.service cloud-init.service cloud-config.target
[13:13] <cjmm6> Conflicts=shutdown.target
[13:13] <cjmm6> [Service]
[13:13] <cjmm6> Type=oneshot
[13:13] <cjmm6> ExecStart=/usr/local/bin/control-cloud-init.sh
[13:13] <cjmm6> RemainAfterExit=yes
[13:13] <cjmm6> TimeoutSec=0
[13:13] <cjmm6> # Output needs to appear in instance console output
[13:50] <smoser> cjmm6: you wont really be able to reliably run before a generator
[13:50] <smoser> at least not with a systemd unit
[13:54] <smoser> you can disable the generator and then you'll get cloud-init behavior like before.
[13:55] <smoser> unfortunatlye "fully disabled" isn't really possible without the generator.  cloud-init will still run through all its stages and use the 'none' datasource.
[14:26] <Odd_Bloke> The generator doesn't do much to the system, either, so it probably isn't the end of the world if it runs and then your custom unit disables all the cloud-init units that it just added to the boot graph.
[14:32] <cjmm6> disable is as follows?
[14:32] <cjmm6> ln -sf /dev/null /etc/systemd/system-generator/cloud-init-generator
[14:32] <cjmm6> because early systemd cannot use systemctl
[14:33] <cjmm6> and how to reenable generator without systemctl?
[14:37] <Odd_Bloke> The generator runs before any units run, so you won't be able to disable the generator using a unit.
[14:38] <Odd_Bloke> And I was going to say that you should be able to disable the units in your own unit, but that may be too late for systemd to pick up the change.
[14:39] <Odd_Bloke> Hmm.
[14:41] <cjmm6> I cannot try to disable all cloud-init units
[14:41] <cjmm6> error!
[14:42] <Odd_Bloke> cjmm6: How do you get the systemd unit onto these systems?
[14:42] <cjmm6> i haven't tried disabling the unit systemd of cloud-init, i will test it if it works
[14:43] <Odd_Bloke> cjmm6: Sorry, I meant how do you get the systemd service which was working with older versions of cloud-init onto the system?
[14:43] <cjmm6> Its because I use a VM image compatible with multiple environment systems.
[14:44] <Odd_Bloke> Right, so the conditions in the unit are used to determine enable/disable based on where you're booting?
[14:44] <cjmm6> Yes! Dinamically
[14:45] <cjmm6> Then, I use one unique VM image for multiple systems
[14:45] <cjmm6> https://github.com/cesarjorgemartinez/automate-virtual-machine-linux-images/tree/master/CentOS7Minimal
[14:46] <cjmm6> Until this challenge (Ubuntu):
[14:46] <cjmm6> https://github.com/cesarjorgemartinez/automate-virtual-machine-linux-images/tree/master/Ubuntu20Minimal
[14:47] <smoser> https://github.com/cesarjorgemartinez/automate-virtual-machine-linux-images/blob/master/Ubuntu20Minimal/files/control-cloud-init.sh
[14:47] <smoser> is that what is controlling cloud-init ?
[14:48] <smoser> it looks to me that you enable cloud-init on kvm and aws. and disable elsewhere.
[14:48] <Odd_Bloke> cjmm6: OK, so one thing you could potentially do is configure cloud-init to only consider the data sources that will present on KVM and EC2.  The generator should then disable cloud-init when it fails to find those datasources.
[14:48] <Odd_Bloke> s/find/detect the applicability of/
[14:48] <smoser> but in reality... cloud-init really should do all the right things.
[14:49] <smoser> i'im surprised if it ever enables itself in a scenario where you think it should not run
[14:49] <smoser> or even disables itself where you think it should
[14:51] <cjmm6> Not ...  cloud-init really should do all the right things... In many systems it is even harmful
[14:51] <smoser> like ?
[14:51] <cjmm6> Then, if you can test, Centos7 and 8 works correctly because not use the last cloud-init
[14:52] <smoser> the intent of the generator is to enable cloud-init when there is a "datasource". and do nothing otherwise.
[14:52] <smoser> i'm sorry, i didn't follow.
[14:53] <cjmm6> Centos 7 => cloud-init-18.5-3.el7.centos.x86_64
[14:53] <smoser> i agree that cloud-init was very annoying in the past.
[14:53] <smoser> without the generator, when it ran and chose the "None" datasource, it would have undesireable side effects.
[14:53] <cjmm6> ubuntu 20 => 20.1
[14:53] <smoser> but the generator was intended to *fix* those.
[14:54] <smoser> can you actually provide examples when it ran and you think it should not have ran ?
[14:54] <cjmm6> ad-hoc environments, or cloud-init not supported
[14:55] <cjmm6> + using compatible VMs between environments, as the purpose of this projet
[14:56] <cjmm6> "boot one image in multiple envs"
[14:56] <smoser> can you provide a 'cloud-init collect-logs' from any of those environments ?
[14:56] <cjmm6> without changes
[14:57] <smoser> ubuntu cloud images are "one image" that boots in multiple envs
[14:57] <smoser> and all "just work" (and if they do not, then feel free to file bugs)
[14:57] <smoser> i'm not trying to be rude.  we want to make this work, but we've intended to solve the problem that you're having with the generator
[14:57] <smoser> so we want to fix the generator if it is not behaving correctly
[14:58] <smoser> rather than make users like yourself have to write scripts to do the right thing.
[15:00] <smoser> cjmm6: ^
[15:02] <smoser> Odd_Bloke's suggesting of configuring the datasource_list should also work.  but the goal you're after of "one image" is already a design goal of the project.
[15:04] <cjmm6> but need one thing to disable, always... Only works in my test, if, when the VM is booted, enter to ssh and create /etc/cloud/cloud-init.disable, and second reboot
[15:06] <smoser> i dont understand.  "but need one thing to disable, always"
[15:07] <smoser> in some scenarios you want to stop cloud-init from running ?
[15:07] <smoser> what are those scenarios?
[15:08] <cjmm6> yes, in adhoc envs, when no need to change nothing. New envs without already cloud-init support, etc.
[15:10] <cjmm6> Situations that, exists a big bug with difficult solution, or the Operating Systems not update the cloud-init for their own reasons...
[15:24] <smoser> so how do you determine that this is such an environment?
[15:27] <smoser> as you seem to know, you can disable cloud-init always by touching /etc/cloud/cloud-init.disabled.
[15:37] <rharper> cjmm6: a couple of comments;  the image build process (https://github.com/cesarjorgemartinez/automate-virtual-machine-linux-images/blob/master/Ubuntu20Minimal/postscripts/post-stage-1.sh)  does a lot of work cleaning up the image due to the image being booted in the first place via packer;  you may want to look at using something like mount-image-callback (in Ubuntu's cloud-image-utils package) to allow you to mount the image without booting so you
[15:37] <rharper> can add your various changes (injecting scripts and programs and updating defaults in the image);    second, for Centos 7/8 cloud-init, RedHat merges features/fixes from master; so while 18.5 is "old" the core capabilities around dynamically enabling/disabling cloud-init (via ds-identify);   third; I suspect that the cloud-init control script is not needed; the cloud-init generator using the ds-identify code (/usr/lib/cloud-init/ds-identify, writes
[15:37] <rharper> output to /run/cloud-init/* ) one can examine that to see why cloud-init gets enabled or not;  If you have a scenario where cloud-init ran when you did not want it to; or the reverse; capturing /run/cloud-init/* contents into a bug will let us help sort out if it's expected behavior or if there is a bug
[16:09] <Odd_Bloke> smoser: Can you still disable cloud-init by touching that file after the generator has run?
[16:14] <smoser> Odd_Bloke: well it wont next time
[16:14] <smoser> but the ship has almost certainly sailed when you touch it otherwise.
[16:21] <meena> anyone here seen / answered faa's problem of adding another network interface?
[16:23] <rharper> meena: faa: by default, adding a nic won't trigger any update to existing network configuration rendered;  so that's expected behavior.    the instance-id is set by the meta-data in the NoCloud datasource;  changing the instance-id will boot like a new instance;
[16:28] <rharper>  If you've added a nic, and you know what an updated network-config (v1) format should look like, you can use 'cloud-init devel net-convert'  to render a specific distro/renderer output; and then copy that to where you need ;  Long term, as we land support in Datasources for refreshing metadata and handling hotplug, https://github.com/canonical/cloud-init/pull/47  ;  I could see NoCloud (configured with an HTTP end-point instead of local files) could
[16:28] <rharper> refresh (fetch metadata) on hotplug of nic.
[16:56] <Odd_Bloke> blackboxsw: rharper: Could one of you look over my proposed changes to https://github.com/canonical/cloud-init/pull/358, please?  They're minor, but as mruffell is out this week, I'd like at least one other person to check them before I land them.
[16:56] <rharper> Odd_Bloke: sure
[16:57] <Odd_Bloke> Thanks!
[17:38] <meena> rharper: you set pr has gone stale…
[17:39] <rharper> yes, it's still valid, just needs a refresh and push
[18:29] <smoser> rcj or maybe Odd_Bloke , or maybe one of the microsoft people here...
[18:30] <smoser> it was my impression in the past that when Ubuntu images were uploaded, that the upload was done with sparseness in-tact
[18:30] <smoser> but then that the copy from region to region did not maintain that sparseness.
[18:31] <smoser> it seems that a feature went into some tools https://github.com/Azure/azure-cli/issues/11509
[18:31] <smoser> late in 2019 that may make my knowledge obsolete.
[18:32] <Odd_Bloke> I believe we addressed that a while ago; I remember pairing with SteveZ (of Azure) to fix it at a F2F a few years back.
[18:32] <smoser> My question then... Do infrastructure (user->user or region->region) copies inside azure now retain sparseness ?
[18:34] <smoser> my current employer is in a similar situation where we publish sparse images, but then use of those images was believed to entail non-sparse copies.
[18:34] <smoser> i'd love to have some link to doc that says otherwise, or link to a nice manual that I could RTFM.
[18:34] <Odd_Bloke> The image copy/replication happens on the backend for Ubuntu image publication (kicked off via private APIs), so I don't know if knowledge from Ubuntu publication will transfer over to a third-party image publication flow.
[18:35] <Odd_Bloke> (We are categorically different from images uploaded by users.)
[18:36] <smoser> hm... yeah.
[18:36] <smoser> so what i'm after is
[18:36] <smoser> a.) we publish an image (we do this i think as well as we can, using sparseness)
[18:36] <smoser> b.) user launches that image or imports it into their account
[18:38] <smoser> i'm not actually sure how they do that, but if its "click click" or otherwise somehow underlying infrastructure, then i'd certainly hope it was sparse.  and if it is *not* click click, then i'd like to at least know how to tell someone that they can copy it the right way.
[18:38] <smoser> thanks Odd_Bloke
[18:39] <smoser> i'm disappointed that cjmm6 disappeared. i was honestly interested in his/her use case.
[18:42] <smoser> well, if someone ms knowledgeable could reach out, i'd love to chat some.
[19:49] <Odd_Bloke> rharper: I've updated https://github.com/canonical/cloud-init/pull/358, could you take another quick look pls?
[19:49] <rharper> Odd_Bloke: yes
[19:49] <Odd_Bloke> Thanks!
[20:13] <rharper> Odd_Bloke: one more comment, I just left for you
[20:14] <blackboxsw> falcojr: lucasmoura if either of you get a chance. I've put up a basic SRU doc  from which we'll work to validate this cloudinit SRU https://github.com/cloud-init/ubuntu-sru/pull/97/files
[20:15] <blackboxsw> it basically creates a bunchof  broken links which we will fill in as we verify each cloud or manual work it
[20:15] <blackboxsw> work *item*
[20:18] <Odd_Bloke> rharper: And replied.
[20:21] <rharper> k
[20:46] <blackboxsw> lucasmoura: falcojr rharper the much anticipated quilt patches for xenial https://github.com/canonical/cloud-init/pull/406
[20:46] <blackboxsw> and procedure
[20:46] <lucasmoura> blackboxsw, ack
[20:46] <blackboxsw> I'll do basically the same for bionic and eoan now.
[20:46] <blackboxsw> without the procedural steps
[20:56] <rharper> ok
[21:01] <blackboxsw> rharper: falcojr lucasmoura https://github.com/canonical/cloud-init/pull/407 bionic
[21:02] <rharper> thx
[21:03] <Odd_Bloke> rharper: Updated, thanks again for the review!
[21:08] <blackboxsw> and eoan https://github.com/canonical/cloud-init/pull/409
[21:56] <Odd_Bloke> blackboxsw: rharper: https://github.com/canonical/cloud-init/pull/358 just landed, so we can SRU away now, I think.
[22:34] <blackboxsw> nice Odd_Bloke I don't mind doing another new-upstream-snapshot round
[22:34] <blackboxsw> might as well