[00:02] <jtaylor> how do I proceed now. propose the branch for merge and let the sponsor subscribe sru or subscribe them myself?
[00:32] <nhandler> Thanks RainCT. Somehow, I don't think I'll have much trouble with this package based on the ML feedback, but I'll definitely keep you in mind when I am ready
[00:46] <micahg> jtaylor: propose the branch for merge and subscribe ubuntu-sponsors
[00:46] <micahg> jtaylor: oops, no need to subscribe when proposing a merge
[00:47] <micahg> jtaylor: I'll be piloting in a bit, so I can run this through if it's ready
[00:52] <jtaylor> micahg: merge proposed
[00:52] <jtaylor> binary debdiff is just egg-file -> egg-folder with all the setuptools stuff in it
[00:56] <micahg> jtaylor: thanks
[07:04] <dholbach> good morning
[09:50] <jtaylor> micahg: I can't reproduce that foolscap problem in chroot, natty and oneiric, anything special you did?
[10:08] <Laney> hwo can I view patches to a package in fedora? anything like the PTS?
[10:10]  * Laney found pkgs.fedoraproject.org
[10:11] <RAOF> Oh, is that useful?  I always trawl the git.
[10:13] <Laney> it got me to the git in the end
[11:34] <Laney> Rhonda: is it known that packages.d.o's file search is broken for experimental? http://packages.debian.org/search?suite=experimental&mode=exactfilename&searchon=contents&keywords=csharp should return results, for example
[11:40] <Rhonda> hmmm
[11:40] <Rhonda> huhm, http://packages.debian.org/experimental/all/mono-csharp-shell/filelist
[11:41] <Rhonda> That's there since a month, right …
[11:41] <Rhonda> Laney: Can you file a bug about that, please? against www.debian.org
[11:42] <Laney> sure
[11:42] <Rhonda> Thanks. Not much time now to investigate further.
[11:58] <wejaeger> Hey, anyone up for reviewing http://revu.ubuntuwire.com/p/l2tp-ipsec-vpn
[12:46] <stlsaint> im getting this error when trying to upload changes file with dput: No host ppa:stlsaint/packagesources found in config
[12:48] <arand> stlsaint: Is this from debians dput (does not support normal ppa syntax)?
[12:54] <stlsaint> arand: yes i am on debian
[12:55] <arand> stlsaint: You can specify PPAs individually http://paste.debian.net/117487/
[12:55] <arand> Alternatively, port over the PPA argument magic from the ubuntu version into debian ;)
[12:56] <stlsaint> arand: is that the dput conf?
[12:56] <arand> stlsaint: ~/.dput.cf  yes
[12:57] <stlsaint> arand: aye gotcha
[12:58] <stlsaint> arand: is it suppose to be blank at first?
[12:58] <arand> stlsaint: yes, /etc/dput.cf is read initially ~/.dput.cf overrides/adds, I assume..
[13:01] <stlsaint> arand: so where you have ubuntu should i have debian?
[13:01] <stlsaint> arand: i tried running and it still gave same error
[13:02] <arand> stlsaint: I'm also on debian, your's should be very similar, just replacing ppa names (redeclipse ppa unstable, in my case)
[13:04] <stlsaint> arand: i changed everything but still same error, same as yours except i change the name and ppa on all three stanzas
[13:05] <arand> The title in [] is the one to use when dputting, eg, "dput ppa-unstable *.dsc In my case to upload to my ppa:arand/unstable"
[13:07] <stlsaint> arand: hrm one sec
[13:08] <stlsaint> arand: this is command im using: dput ppa:stlsaint/packagesources lxdm_0.3.0-0ubuntu5.1_i386.changes
[13:09] <arand> stlsaint: You want to replace the "ppa:stlsaint/packagesources" with whatever to named the entry for that ppa (in my case, e.g. just "resvn")
[13:12] <stlsaint> arand: so i have a ppa on lp name packagesources, that should go in place of where you have resvn?
[13:14] <arand> stlsaint: the thing within [] can be anything, but that is the name you will have to use when nivoking dput.
[13:14] <arand> Gotta run, sorry
[13:14] <stlsaint> here is the commadn i use:  dput ppa:stlsaint/packagesources lxdm_0.3.0-0ubuntu5.1_i386.changes
[13:14] <stlsaint> shucks
[13:33] <stlsaint> dang im slow
[13:33] <stlsaint> arand: i see what you were saying now
[13:34] <stlsaint> i fixed that but now im getting something about no signature on that file but signed the package at build
[13:35] <stlsaint> crap never mind on that either
[15:32] <mnemoc> hi, I want to push to a ppa a fixed version of a package, tp_smapi. Is there any easy trick (debuild -something?) to help the infrastrcture to notice the diff?
[15:33] <mnemoc> any docu related to this case?
[15:34] <mnemoc> wrong channel? :)
[16:00] <micahg> jtaylor: I built the package locally, could be I broke something, I'll push up to my SRU PPA to see if I get the same failure
[16:02] <jtaylor> micahg: wait I think I want to add a small change to the patch
[16:02] <jtaylor> the dependency on python-twisted is too strong, it only needs -core and -web
[16:03] <jtaylor> it just slipped in in the dh_python2 transition
[16:07] <jtaylor> or would that change also first have to be uploaded to debian? in this case its probably not worth it
[16:08] <micahg> jtaylor: changes must be made in the dev release first
[16:10] <jtaylor> then one can probably ignore it, it just installes a few extra packages
[16:11] <micahg> jtaylor: yeah, that's not worth fixing in an SRU
[16:11] <micahg> jtaylor: but Debian should get the fix if appropriate
[16:12] <jtaylor> yes going to commit it to the vcs soon
[16:46] <arand> stlsaint: Sorry for rushing off, you got it working?
[16:48] <stlsaint> arand: well the command went thru but there is still nothing in my ppa
[16:48] <stlsaint> arand: though it said upload was successful
[16:49] <arand> stlsaint: And the build queue is empty as well, and yo've received no confirmation by email?
[16:50] <arand> Hmm, yea it appears to be completely empty...
[16:52] <arand> stlsaint: The source (debiuld -S) is signed with one of the gpg keys that are specified on LP as well?
[16:54] <stlsaint> arand: yes
[16:56] <arand> Then I'm not quite sure, I think then you'd have followed the same procedure as I normally do, and unless LP is in flux currently, I don't know what the issue would be .. :/
[16:57] <stlsaint> arand: cool thanks
[17:11] <micahg> jtaylor: confirmed, I get the error on upgrading python-foolscap
[17:12] <jtaylor> I don't, what could be the cause? it upgrades in debian and a clean chroot and a oneiric vm
[17:12] <micahg> jtaylor: this is for the natty SRU
[17:12] <jtaylor> yes thats what I tried
[17:13] <jtaylor> also they are practially the same
[17:13] <micahg> no idea, I haven't come across this before
[17:14] <jtaylor> the only difference is a dropped breaks which was empty anyway
[17:14] <jtaylor> does the version in oneiric install an your natty machine?
[17:15]  * micahg can check
[17:16] <micahg> jtaylor: yep, that worked
[17:16] <jtaylor> oO
[17:24] <jtaylor> I don't get why it doesn't happen on my machine, but I guess I need to add a Break: python-foolscap (<< 0.6.1-3)
[17:30] <micahg> jtaylor: that version won't work for the SRU, I wonder what the difference is
[17:33] <jtaylor> lets see if I can get piuparts to run
[18:00] <jtaylor> friggn piuparts, worked once with the debian version and now it fails on the same file with some weird unrelated error ...
[18:11] <jtaylor> micahg: as I can't reproduce the problem can you try adding that to the control: http://paste.ubuntu.com/610697/
[18:11] <jtaylor> althout it should not be necessary ...
[18:26] <micahg> jtaylor: yep, in a bit, about to head out for lunch
[18:43] <evaluate> Hello.
[18:44] <evaluate> I was wondering if Bug 702316 is under review and if maybe there is anything else that I need to do for the patch to get applied.
[18:49] <micahg> evaluate: yeah, I have the patches, I just need to test build and upload
[18:49] <evaluate> micahg, cool.
[18:49] <broder> evaluate: you did everything right, the process has just been a little laggier than usual because of the recent release, UDS, etc.
[18:49] <micahg> evaluate: sorry, my piloting ran a little late, so I figured to wait until today to upload
[18:49] <micahg> but since I already looked at it, wanted to claim it
[18:51] <evaluate> micahg, would enabling the indicator need a patch too?
[18:52] <micahg> evaluate: hmm, technically, probably should be since it's 2 different things
[18:54] <evaluate> Thing is, I disabled it by default in the source package, since it generated a lot of problems for maverick/lucid, but I think it should work fine in natty, so it would be nice if it was enabled by default.
[18:55] <micahg> evaluate: right, and it seems that it was supposed to be enabled in the last upload but I don't think the merger noticed your source change
[18:58] <evaluate> ok, so what would be the right thing to do to have it enabled in this case?
[18:58] <evaluate> Should I submit another patch? Or edit the current patch?
[18:59] <micahg> evaluate: have a named patch to enable the indicator and a named patch to fix the crash
[18:59] <micahg> evaluate: if you want to fix it up, I can grab it over the weekend
[19:00] <evaluate> Can I leave the current patch as it is and submit another one for enabling the indicator, or do you want me to also rename the current one?
[19:00] <micahg> evaluate: I thought the current one enables it
[19:00] <micahg> all in one patch that is
[19:01] <evaluate> Ohh, yes it does.
[19:01] <evaluate> Forgot that I also had that change in there.
[19:01] <micahg> oh, it's set to auto, not yes, but I think with the build flag we're good
[19:02] <evaluate> Well, auto means that if the appindicator-0.1 package is present (which is set as a build-dep in ubuntu) it will default to yes.
[19:03] <evaluate> ok then, so can I leave the patch as it is?
[19:03] <micahg> evaluate: yeah, are you going to push these changes into Debian as well?
[19:05] <evaluate> Yes. I have sent the 1.3.13 version which includes these changes to my mentor, but it couldn't be uploaded due to some transitions going on in Debian and now I didn't bug him anymore about it since I want to roll out 1.4.0 soon anyway.
[19:06] <micahg> evaluate: k, I'll upload this to oneiric later today or over the weekend so we can get the SRU in
[19:07] <evaluate> Good. Thank you very much!
[19:07] <micahg> evaluate: thank you for your work!
[19:09] <micahg> evaluate: actually, I might move the enable indicator piece out since it's not part of the upstream patch, but I can do that locally
[19:10] <evaluate> Yeah, I enabled the indicator only in the 1.4 branch.
[19:19] <micahg> jtaylor: works now...
[19:19] <jtaylor> strange, it should not need that and why does the oneiric version work
[19:20] <micahg> jtaylor: no idea
[19:21] <micahg> jtaylor: if you want to have someone else test, I have the original in ppa:micahg/sru-test
[19:30] <jtaylor> ok from there I could reproduce it
[19:31] <micahg> jtaylor: cool :)
[19:31] <Quintasan> bdrung_: ping
[19:32] <micahg> jtaylor: so, do you want to discuss with some python gurus if the breaks/replaces is correct or if there's a better fix for this?
[19:32] <jtaylor> #debian-python says no replace needed, but I'll just check whats the difference to the package I built
[19:33] <micahg> jtaylor: k, well, you can show them the package in the PPA and the error and see if they change their minds :)
[19:43] <bdrung_> Quintasan: pong
[19:43] <Quintasan> bdrung_: sponsor-patch is broken I think
[19:44] <Quintasan> sponsor-patch --builder=pbuilder-dist 712534 --workdir kamoso
[19:44] <Quintasan> AssertionError: kamoso/kamoso_2.0-0ubuntu2.dsc does not exist.
[19:44] <Quintasan> ls kamoso/kamoso_2.0-0ubuntu2.dsc -> kamoso/kamoso_2.0-0ubuntu2.dsc
[19:44] <Quintasan> the file is there
[19:44] <bdrung_> Quintasan: that is fixed in trunk. can you file a bug report and add the needed stuff for a SRU?
[19:45] <Quintasan> bdrung_: well, I can, but later, uploading 24mb bug stacktrace now @_@
[19:45] <bdrung_> Quintasan: thanks
[19:47] <bdrung_> tumbleweed: we need a online test infrastructure for these kind of bugs ^
[19:58] <Quintasan> bdrung_: the version for SRU should be 0.123?
[19:58]  * Quintasan notes you might as well upload that to oneiric
[19:59] <bdrung_> Quintasan: 0.122.1
[20:07] <bdrung_> Quintasan: http://paste.ubuntu.com/610750/
[20:08] <Quintasan> oh
[20:17] <Quintasan> bdrung_: bug 785923
[20:17] <Quintasan> I think I'm doing it right
[20:18] <Quintasan> bdrung_: Are you going to upload a newer version to oneiric soon?
[20:19] <bdrung_> Quintasan: yes
[20:19] <Quintasan> cool
[20:28] <bdrung_> Quintasan: uploaded to proposed
[20:29] <Quintasan> oh wait..what? so fast
[20:29] <Quintasan> :D
[20:29] <bdrung_> Quintasan: in rare cases :)
[20:30] <Quintasan> :)
[20:36] <bdrung_> broder: re bug #785854 - what's the reason for the broken pipe?
[20:37] <tumbleweed> bdrung_: what was the issue you say we need testing for?
[20:37] <tumbleweed> oh that one
[20:37]  * tumbleweed sees the paste
[20:38] <bdrung_> tumbleweed: btw i am releasing 0.123
[20:38] <bdrung_> tumbleweed: i give a few seconds to veto
[20:39] <tumbleweed> cool
[20:47] <broder> bdrung_: because diff got to the end of its input? there are a bunch of programs that expect SIGPIPE, not EPIPE
[20:47] <broder> cjwatson walks through the basics at http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/2009-07-02-python-sigpipe.html
[20:48] <broder> because python changes the SIGPIPE handler, and signal handlers don't get reset on fork/exec, the program that expects SIGPIPE starts getting EPIPE instead, and gets confused
[20:51] <tumbleweed> meh, we probably need to work around that in a bunch of places (or wrap subprocess, or use this subprocess32 backport)
[20:52] <broder> tumbleweed: i may have a subprocess wrapper that resets a bunch of generally undesirable behavior
[20:52] <broder> i need to dig it up
[20:52] <bdrung_> but why doesn't it always fail?
[20:52] <tumbleweed> bdrung_: it'd only be an issue if the pipeline shuts down before the processes are done
[20:52] <tumbleweed> i.e. if we stop being interested in output
[20:53] <broder> bdrung_: there's some raciness involved. i don't remember the details
[20:54] <tumbleweed> I guess it also breaks subprocess' childern
[20:55] <broder> right, that would be what's happening here, i think
[20:56] <tumbleweed> yeah
[21:23] <jtaylor> micahg: not even break works for me when installing from a ppa, but conflicts seems to work. I'll try to understand that and then probably go over debian
[21:26] <jtaylor> (although its not affected, I don't know why)
[22:13] <shadeslayer> hi! i can't seem to be able to build avogadro with oneiric in a pbuilder, is there a problem with the gcc package ?
[22:14] <shadeslayer> http://paste.ubuntu.com/610811/ << error in pbuilder
[22:14] <broder> shadeslayer: update your pbuilder
[22:14] <shadeslayer> afaik it's updated, but i'll check again
[22:14] <shadeslayer> bleh ... outdated mirrir
[22:14] <shadeslayer> *mirror
[22:18] <shadeslayer> broder: didn't work
[22:18] <shadeslayer> same issue
[22:18] <broder> shadeslayer: all that error means is that the gcc packages you have installed don't match the version of the gcc packages in the archive
[22:19] <broder> although it could be a publishing skew issue of some sort
[22:19] <shadeslayer> okay, but i switched to the main archives
[22:19] <broder> i know doko was in the middle of updating gcc for something, so maybe just wait a day
[22:19] <shadeslayer> yeah looks like it
[22:55] <micahg> jtaylor: you should use breaks w/replaces
[22:55] <jtaylor> micahg: does not work
[22:56] <jtaylor> micahg: only conflicts
[22:56] <jtaylor> micahg: debian work fine, Im slowly thinking this is a dpkg bug
[22:56] <jtaylor> tries to remove a file from the new package instead of the old
[22:56] <micahg> jtaylor: breaks/replaces works for me with the package I built locally upgrading from the one in the repo
[22:58] <jtaylor> micahg: not for me, its kind of a heisenbug, as earlier I could not reproduce it to begin with
[23:00] <jtaylor> http://paste.ubuntu.com/610839/
[23:02] <micahg> jtaylor: weird, upgrading from natty to oneiric version was fine, upgrading to version in my PPA + breaks/replaces was fine for me
[23:02] <jtaylor> yes my oneiric vm worked fine too
[23:03] <jtaylor> and according to debian policy it should work without the breaks too
[23:03] <jtaylor> (which it does in debian)
[23:28] <micahg> bdrung_: any reason for me not to upload the eclipse FTBFS fix over the weekend?
[23:38] <bdrung_> micahg: no
[23:39] <bdrung_> micahg: can you check if 3.6.2 is affected too? (master-3.6 git branch)
[23:39] <micahg> bdrung_: k, thanks
[23:39] <bdrung_> i have only amd64
[23:39] <bdrung_> (and there it builds)
[23:42] <micahg> bdrung_: idk if I'll be able to get to it, but I'll see


[07:07] <dholbach> good morning
[11:10] <locodir-user> hi i am new to ubuntu i have installed ubuntu 10.04 but not able to play music or view documents
[11:10] <locodir-user> what i need to do
[11:13] <locodir-user> hi
[11:14] <locodir-user> hi Agafonov can u plz help me
[11:33] <locodir-user>  hi i am new to ubuntu i have installed ubuntu 10.04 but not able to play music or view documents
[11:34] <czajkowski> locodir-user: hi it's kinda quiet in here, and this isn't a support channel, you might get more help from #ubuntu
[17:51] <locodir-user> want free cd
[17:51] <locodir-user> how to get free cd delivered to home?


[21:53] <bryce> then I ask for a ''full backtrace'' and I think that completely pushes them over the edge of sanity
[21:54] <Nafallo> :-)
[21:55] <slangasek> well, yes, this particular bug submitter also believes that "the most likely environment to use ubuntu is academia" (?) :)
[22:00] <Nafallo> slangasek: :-)
[22:01] <bryce> slangasek: btw the sync request is bug #211385
[22:01] <ubotu> Launchpad bug 211385 in xserver-xorg-video-amd "please sync xserver-xorg-video-geode (main) from Debian (main)" [Undecided,New] https://launchpad.net/bugs/211385
[22:03] <calc> i'm so tired, i'm going to be dead tomorrow due to this crappy jetlag :(
[22:04] <Nafallo> calc: changed to summertime recently? :-)
[22:05] <calc> Nafallo: change from -5 to +1 today
[22:05] <calc> er -5 to +2 maybe
[22:06] <calc> 7 hours difference
[22:06] <Nafallo> calc: where are you? :-)
[22:06] <calc> Prague
[22:06] <calc> I was in Houston yesterday
[22:06] <Nafallo> sounds more like +2 indeed :-)
[22:07] <calc> got on the plane at Wed 3:30PM got to the hotel at Thu 12:00PM, heh
[22:07] <Nafallo> us Londoners stole +1 ;-)
[22:07] <calc> ah yea
[22:07] <Nafallo> :-)
[22:09] <mario_limonciell> ArneGoetje, ping.  I was checking to see if you were aware of breakage in terms of language packs?
[22:09] <mario_limonciell> ArneGoetje, see http://cdimages.ubuntu.com/dvd/20080410/report.html or http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/hardy/ubuntu-dvd/20080410/livecd-20080410-i386.out for information
[22:11] <mario_limonciell> slangasek, it looks like the issue is actually that openoffice.org-hyphenation-en-us got moved to universe for some reason or another?
[22:12] <mario_limonciell> slangasek, were you aware of whether that was intended?
[22:12] <slangasek> mario_limonciell: it wasn't moved, it was never /in/ main
[22:12] <slangasek> we've worked this out, the dependency has been moved back to openoffice.org-hyphenation
[22:12] <mario_limonciell> in the very near past you worked it out?  that dvd was just queued a few hours ago
[22:13] <slangasek> yes
[22:14] <ted1> So, seriously, is there no Debian archive somewhere?
[22:15] <slangasek> ted1: sounds like you're looking for snapshot.debian.net?
[22:17] <mario_limonciell> slangasek, so should all pending language issues be fixed at this point if another DVD is made (we've been trying to get a good one the last few days)
[22:18] <ted1> slangasek: Yes, yes I am.  Thank you.
[22:19] <ogra> hmm, f-spot segfaults on a fresh install
[22:19] <Nafallo> ugh
[22:19] <slangasek> mario_limonciell: looks like it, yes
[22:19] <slangasek> mario_limonciell: want me to fire one off?
[22:19] <ogra> http://paste.ubuntu.com/6719/
[22:21] <Nafallo> ogra: I get a SIGSEGV after I Quit via the menu :-)
[22:22] <ogra> with f-spot ?
[22:22] <Nafallo> ogra: yes. not fresh install though.
[22:22] <mario_limonciell> slangasek, yeah if you can
[22:22] <Nafallo> ogra: upgraded gutsy.
[22:22] <ogra> it looks like that are two errors ...
[22:23] <Nafallo> ogra: at least :-)
[22:23] <slangasek> mario_limonciell: running a livefs build only
[22:23] <ogra> one is a missing sqlite db and the other is that it cant connect to dbus
[22:23] <mario_limonciell> slangasek, yeah probably a good idea (waste of space to make dvds when that livefs is what keeps failing)
[22:24] <stratus> ogra: the missing sqlite db is well known issue
[22:25] <ogra> stratus, any idea if thats fixed in debian ?
[22:25] <slangasek> mario_limonciell: can I just leave it running and wait for feedback from you if there are still failures?
[22:25] <mario_limonciell> yeah
[22:25] <mario_limonciell> i'll check on it in an hour or two
[22:25] <slangasek> (or if you want me to follow through with an ISO build)
[22:25] <slangasek> hmm, takes longer than an hour to finish, doesn't it? :)
[22:26] <slangasek> if it succeeds anyway
[22:26] <stratus> ogra: see 81905 in lp
[22:26] <mario_limonciell> well it will fail within an hour at least :)
[22:26] <slangasek> ok :)
[22:26] <stratus> ogra: it seems that f-spot have no idea where the sqlite db is and guesses that the table tags is missing
[22:29] <stratus> ogra: did f-spot setup .gnome2/f-spot/photos.db ?
[22:29] <ogra> yup
[22:30] <stratus> is it a really fresh install, right? I assume you didn't copy your home directory there.
[22:30] <ogra> right
[22:30] <cellofellow> !bug 206149
[22:30] <ubotu> Launchpad bug 206149 in ubuntu "The system doesn't recognize my Realtek RTL8185 wireless card." [Undecided,New] https://launchpad.net/bugs/206149
[22:30] <stratus> then sqlite .gnome2/f-spot/photos.db and check if the missing table is there
[22:30] <ogra> and -b ./ solves it
[22:31] <stratus> oh cool
[22:31] <stratus> probably a bug during the build, f-spot has no base dir set or a wrong one
[22:31] <ogra> yeah
[22:31] <ogra> smells like that
[22:32] <ogra> i still have a segfault on exit though
[22:32] <ogra> but it starts and runs fine
[22:32] <stratus> oic
[22:32] <cellofellow> any idea what's up with that bug?
[22:32] <stratus> at least no d-bus related bug too
[22:38] <LaserJock> slangasek: is it ok if I upload a translation update of edubuntu-docs?
[22:40] <slangasek> LaserJock: yes
[22:40] <LaserJock> thanks
[23:37] <Keybuk> slangasek: ping?
[23:39] <slangasek> Keybuk: pong
[23:41] <Keybuk> slangasek: proposed udev patch
[23:41] <Keybuk> http://people.ubuntu.com/~scott/fix-persistent-net.pl.txt
[23:41] <Keybuk> well, patch/er/
[23:41] <tjaalton> slangasek: uploaded new lrm for the latest ABI. it also fixed faulty dh_strip which was supposed to skip stripping nvidia, but didn't since the versioning was changed
[23:47] <slangasek> Keybuk: looks sane to me... :)
[23:47] <slangasek> tjaalton: thanks, will process it
[23:47] <tjaalton> slangasek: thanks
[23:47] <Keybuk> slangasek: I've tested it in every crazy situation I can replicate
[23:49] <slangasek> Keybuk: let's go for it then :)
[23:50] <slangasek> tjaalton: I note there's an open bug report for the nvidia stripping thing, and it's not mentioned in the changelog, so please close by hand
[23:51] <Keybuk> slangasek: uploaded
[23:51] <tjaalton> slangasek: right, will do


[14:32] <OneBit> Hello, i want install a ubuntu-server via cloud-init autoinstall. I have two disks and i want RAID 1. Is this possible?
[15:55] <dalurka> OneBit: yes
[17:55] <akutz> Is there a known issue where MAC addresses in metadata need to be case-specific for a given renderer? We found that when our provided MACs are lower-case, networking fails on RHEL. Now, this would be an older version of CI without several of the more recent patches, including one I did in network_state.py that does switch to case-insensitive MAC matching, but I am not sure if that actually addressed the issue or if it is even the same issue.
[17:55] <akutz>  Regardless, I think CI should 1) accept MACs in either case and 2) compare them in a case-insensitive manner and 3) output the value in the format required by the renderer.
[17:57] <minimal> akutz: do the MAC addresses have a leading zero? are they quoted?
[17:58] <akutz> They will always have the correct number of digits, as for quoted, not sure. Regardless, I've not seen the quoting affect it in the past. Is that possibly renderer specific?
[17:59] <akutz> Just verified that we do not quote the value.
[17:59] <minimal> akutz: I had an issue in past with network-config that required MAC quoting as due to YAML "smarts" they could be misinterpreted
[17:59] <akutz> Ack. Interesting.
[17:59] <akutz> Thank you.
[18:00] <akutz> But wouldn't that be specific to CI and not the distro? I guess since it's older CI on RHEL then Ubuntu/Photon may not be subject to the same issue since their CI will be newer.
[18:01] <minimal> akutz: here's my related MR from a couple of years ago: https://github.com/canonical/cloud-init/pull/623
[18:01] <akutz> minimal: cool, thank you. Here's the one to which I was referring up above -- https://github.com/canonical/cloud-init/pull/1327
[18:04] <minimal> akutz: there is https://github.com/canonical/cloud-init/pull/1135 when the change updated the docs to state "Letters must be lowercase"
[18:05] <akutz> Thanks again minimal -- we're going to try adding the quotes to see if that solves the issue. If it does, and it works for RHEL, then it would mean that there's some change in CI where uppercase worked on newer versions of CI but now older.
[18:06] <minimal> the quotes issue is only really a factor if the mac address contains no letters as then the YAML library treats it as a Base60 number instead
[18:06] <akutz> Ack.
[18:07] <akutz> So it turns out my engineer built CentOS 8 with CI 22.1. I didn't know she didn't use a stock image. That means she likely hit the change to requiring lcase MACs, and once we start testing against newer ubuntu and Photon images that use 22.1 and have that patch from 12/21, we'd hit it there too.
[18:10] <holmanb> akutz: yeah there was an old bug about the mac case that was worked on last cycle, but I guess that's already been brought up - the "built with 22.1" explanation makes sense
[18:11] <akutz> Do you happen to have that bug ID handy? The issue linked was just the doc change.
[18:12] <akutz> I found https://bugs.launchpad.net/cloud-init/+bug/1876941, but I don't see any code that addresses this. The solution is just to doc it?
[18:13] <akutz> (not judging, just asking)
[18:13] <akutz> Ah, found https://bugs.launchpad.net/cloud-init/+bug/1876363
[18:14] <holmanb> akutz: the first one is the one I was referring to "worked on last cycle" - I think we discussed and agreed that supporting both cases should happen
[18:14] <akutz> I may take on this bug, but I'm concerned about back-compat and the level of testing to ensure that it's handled appropriately everywhere.
[18:15] <holmanb> akutz: if you want to take it on, you're welcome to :)
[18:15] <holmanb> can help with ensuring test coverage when it comes time for review
[18:16] <akutz> Heh, I know no one would stop me per se, I'm just not sure I'm the right person for it. The LP has a specific location where this needs to be addressed (wait_for_phys_devices). I actually addressed this issue in the sysconfig renderer earlier this year as well. That's at least *one* location the LP didn't mention -- I'm sure there are others.
[18:17] <akutz> I think the first step will be to find out whether each renderer has specific requirements regarding MACs to ensure that any changes to those in CI does not affect how they are emitted for their respective renderers.
[18:18] <holmanb> akutz: that or you could just convert both cases to the case currently in use (assuming that works as expected)
[18:18] <holmanb> which would probably be less work than auditing various renderers :)
[18:19] <akutz> Yep. My concern is that the renderer may not actually correctly know which case it should be used and is dependent upon having the correct case passed all the way through via the metadata.
[18:20] <akutz> So there are two methods here -- normalize all macs or update all comparisons or dict lookups to be case insensitive.
[18:21] <holmanb> akutz: agreed
[18:22] <akutz> And I guess my first thought is normalization is generally easier because there are only so many places where the value is inputted and outputted. That's true for comparison and lookup as well, but those will be trickier to spot I think. Anyway, that's what prompted my comment about renderers.
[18:25] <akutz> Huh, in netinfo.py the REs for matching MACs for various distros all use [\da-f], effectively asserting the system tools that report MAC info always do so in lcase.
[18:29] <holmanb> akutz: not sure if it helps, but here is a pointer to some mac regex I submitted to a different project: https://github.com/bee-san/pyWhat/blob/main/pywhat/Data/regex.json#L1479
[18:30] <holmanb> it supports either case
[18:31] <akutz> holmanb: thanks! I guess my point was more that CI seems to already internally expect MACs to be lcase in certain situations. And more importantly those situations involve the distro command used to produce the network info data. The fact that these distros all report MACs in lcase is strong evidence that they should be normalized as such.
[18:32] <akutz> It honestly makes me wonder if there shouldn't just be a function that processes metadata prior to processing and updates all MACs to be lcase.
[18:32] <holmanb> akutz: ah, I see what you're saying
[18:33] <holmanb> yeah, agreed, normalize to lower case on input is how I'd tackle this
[21:17] <chiluk> Hey folks.  Does anyone have an example of a cloud.cfg that can actually set up dns nameserver, and search domains on 20.04 in aws?   The resolv_conf module doesn't work, and I can't seem to get a functional incantation of https://cloudinit.readthedocs.io/en/latest/topics/network-config.html
[21:19] <chiluk> Really it just feels like there are many ways to skin this cat, (forcibly setting /etc/resolv.conf, systemd-resolved, netplan, network-manager, ifcfg) what's the recommended way to do this.
[21:32] <holmanb> chiluk: Hello! Could you expand on "resolv_conf doesn't work"? I seem to recall systemd-resolved wiping out /etc/resolv.conf on $OTHER_DISTROBUTION, but I can't speak for 20.04 off the top of my head.
[21:34] <holmanb> chiluk: I would probably start with configuring dns along with other network configs via: https://cloudinit.readthedocs.io/en/latest/topics/network-config-format-v2.html, but I don't have an AWS/20.04 config lying around, sorry
[21:37] <chiluk> holmanb: yeah the resolv_conf cloud-init module is not resulting in a modified /etc/resolv.conf.  I haven't figure out if the module is failing or if resolv.conf is getting overwritten by systemd-resolvd ..
[21:37] <holmanb> minimal: Would you happen to know offhand whether cloud-init analyze works on Alpine?
[21:38] <chiluk> holmanb: as for network-config-format-v2, I couldnt' seem to make that work either, and I was hoping someone had a functional cloud.cfg I could copy.
[21:38] <minimal> holmanb: one sec whilst I check on a VM I have handy...
[21:40] <minimal> blame/show/dump work, boot fails with "You must be running a Kernel Telemetry supported distro."
[21:44] <holmanb> minimal: Interesting, thanks!
[21:47]  * holmanb needs to figure out why lxc wasn't working for an alpine image
[21:48] <minimal> holmanb: have never tried lxc with Alpine cloud-init, its on my "to test" list
[21:49] <holmanb> minimal: I use lxc for checking various distro things, makes it really easy to test things quick
[21:50] <minimal> yeah I just need to figure out how to create a LXC container inside a chroot, that's how my script currently builds VM disk images
[21:50] <minimal> or else take a different approach for LXC
[21:51] <minimal> holmanb: is there a particular lxc template you're using for Alpine?
[21:51] <holmanb> minimal: I was trying to pull and run from the canonical image server: https://us.lxd.images.canonical.com/
[21:51] <holmanb> minimal: I don't build them myself
[21:52] <holmanb> looks like they have templates/build scripts/jenkins info on that page ^^
[21:53] <minimal> holmanb: this seems to be it: https://github.com/lxc/lxc-ci/blob/master/images/alpine.yaml
[21:53] <minimal> I think I looked at that once briefly
[21:56] <holmanb> yeah that looks like it
[21:57] <minimal> holmanb: which Alpine release did you use?
[21:57] <chiluk> Maybe I should ask a different question.  What is the best way to debug a failing cloud.cfg?  Is there a cloud-init command that forces it to rerun the network configuration?
[21:57] <chiluk> basically I want to boot a node ... modify cloud.cfg, and run something so that cloud-init attempts to use or analyze cloud.cfg
[21:58] <minimal> chiluk: have you tried enabling debugging for cloud-init? then the /var/log/cloud-init.log file would show a lot more detail as it processes network-config and user-data
[21:58] <holmanb> minimal: the cloud one: lxc init images:alpine/cloud
[21:58] <chiluk> well the problem is that I can't log in with my broken cloud.cfg
[22:01] <minimal> holmanb: did you write the user-data yourself or got it from the lxc people? e.g. from that template they seem to install openssh rather than openssh-pam which will cause problems if the user-data locks a user-account
[22:02] <holmanb> chiluk: there's a newer "pre-test-flight" tool for validating that your cloud-config is valid - that will check for obvious errors like keys that aren't valid even though yaml is valid
[22:02] <chiluk> cool I'll check that out.
[22:02] <chiluk> is there a way to force cloud-init to run as if it was running for a first-boot?
[22:02] <holmanb> chiluk: invoked via cloud-init devel schema -c ./config.yml on a running cloud-init system, or you could grab the cloud-init repo and run it locally setting the pythonpath
[22:03] <holmanb> chiluk: yes, to re-run use `cloud-init clean --reboot`, which will reset and reboot
[22:03] <holmanb> chiluk: or cloud-init clean followed by --reboot
[22:03] <chiluk> holmanb: will that reboot the node though?
[22:03] <chiluk> my issue is that I'm borking networking ..
[22:04] <holmanb> chiluk: yes it will
[22:04] <chiluk> is there a way to do that without the reboot?
[22:04] <holmanb> chiluk: have you tested your config locally in a container/vm?
[22:04] <chiluk> that's an idea... I guess I could probably just configure serial console in aws.
[22:05] <chiluk> alright I have some things to try .. thanks holmanb.
[22:05] <holmanb> chiluk: you _could_, by running the cloud-init "local" stage
[22:05] <chiluk> how does one do this?
[22:06] <holmanb> chiluk: I would highly recommend iterating in a local container/vm (where networking can be borked and you can debug) until your config works
[22:06] <holmanb> but...
[22:07] <chiluk> alright.
[22:08] <holmanb> chiluk: honestly I don't know if I would recomend running individual stages of cloud-init without a reboot
[22:09] <holmanb> likely to get results you don't expect, and there's four separate systemd services that run at particular parts of the systemd boot order
[22:09] <holmanb> err, minimal: I don't think we're talking about the same thing
[22:10] <minimal> holmanb: I thought you were creating a cloud-init enabled Alpine LXC container
[22:10] <holmanb> minimal: I'm just trying to pull down the image from the server to run an alpine container - I haven't managed to pull an image, so I haven't even gotten to cloud-config
[22:11] <holmanb> minimal: the canonical server has pre-built cloud-init containers of various distros
[22:12] <minimal> right: so you're trying to use this one? alpine	edge	amd64	cloud	20220426_13:00	YES (2.0 and up)	YES (2.0 and up)	YES	YES
[22:12] <minimal> for 3.15?
[22:12] <holmanb> the first one
[22:12] <minimal> oops, sorry, Edge
[22:12] <minimal> the first one? 3.12?
[22:13] <minimal> the first Alpine version that had cloud-init packaged was 3.13
[22:14] <holmanb> minimal: ahh, it was user error
[22:14] <holmanb> edge
[22:14] <minimal> ok, edge is the "bleeding edge" of Alpine :-)
[22:15] <holmanb> minimal: perfect :)
[22:15] <holmanb> minimal: broken and new is my favorite
[22:15] <minimal> so if you can't even pull down the image then is that not a tooling issue?
[22:15] <holmanb> minimal: yeah you asking which version made me realize I was just invoking lxc wrong
[22:17] <minimal> hotmanb: so I was assuming those Canonical images were based on the upstream lxc templates, in which I pointed out a potential issue with the alpine cloud one & cloud-init
[22:18] <minimal> that behaviour of openssh (if PAM not enabled) and locked users
[22:18] <holmanb> minimal: ahh, because openssh is not used on alpine?
[22:19] <minimal> because in Alpine the package openssh-server is OpenSSH compiled without PAM and package openssh-server-pam is it compiled with PAM support
[22:20] <minimal> actually I'll have to check as they're actually specifying "openssh": https://github.com/lxc/lxc-ci/blob/master/images/alpine.yaml#L331
[22:20] <minimal> so "openssh" depends on "openssh-server"
[22:23] <holmanb> minimal: ahh, I see
[22:23] <minimal> long-story-short: in Linux a locked account is one where password access is blocked (acct is no disabled and so SSH-key-based access should still work), however upstream OpenSSH treat locked as completely locked (inc. SSH-key-based-access) *UNLESS* PAM is enabled
[22:23] <minimal> doesn't affect most distros as they only ship a single OpenSSH server package with PAM support
[22:24] <minimal> for Alpine though there's 3 different packages for OpenSSH server (3rd is with Kerberos support)
[22:24] <holmanb> minimal: sure, makes sense
[22:25] <minimal> I discussed this about 2 months ago on here with either blackboxsw or smoser as I wanted to figure out some sort of cloud-init way to handle this (e.g. adding a "disabled" option to "users:" section)
[22:26] <minimal> where "disabled" wouldn't lock the account (which puts "!" in password field) but rather put something else like "*" in there instead
[22:30] <minimal> holmanb: so have you now managed to pull down the image ok?
[22:31] <holmanb> minimal: I have, thanks
[22:31] <minimal> does it boot ok?
[22:32] <holmanb> minimal: it does
[22:32] <holmanb> one error, datasource related
[22:32] <holmanb> __init__.py[ERROR]: Could not import DataSourceVMware. Does the DataSource exist and is it importable?
[22:32] <minimal> I didn't see anything in the template about tweaking cloud.cfg's datasources list so I'm guessing its using the default list
[22:34] <minimal> holmanb: hmm, it is in the package: https://pkgs.alpinelinux.org/contents?file=*VM*&path=&name=cloud-init&branch=edge&repo=community&arch=x86_64
[22:35] <minimal> I would have assumed the LXC people would have tweaked the cloud.cfg to only try the LXC DataSource (for "performance" reasons) rather than go through a list of various DS
[22:36] <holmanb> minimal: /shrug
[22:36] <holmanb> I just use it
[22:37]  * holmanb needs to eat food now
[22:37] <minimal> actually there is no LXC in c-i, only a LXD DS - I assume this handles both LXC and LXD
[22:38] <holmanb> Thanks for the help minimal!
[22:39] <minimal> holmanb: no problem. If its trying to use NoCloud for LXC then I suspect the LXC image has some other problems (i.e. they didn't follow the notes in my README.Alpine file for the cloud-init package)
[22:41] <minimal> holmanb: light reading here if you're interested ;-) https://git.alpinelinux.org/aports/tree/community/cloud-init/README.Alpine


[07:14] <dholbach> good morning
[07:19] <Unit193> Howdy.
[07:48] <SilverLion> mornin
[20:52] <SilverLion> good evening
[20:53] <nlsthzn> o/
[20:54] <SilverLion> nlsthzn, long time no see man!
[20:54] <nlsthzn> Why SilverLion , where you blind?
[20:54] <nlsthzn> *were
[20:54] <SilverLion> nlsthzn, seems like it :D
[20:54] <nlsthzn> :) how are you?
[21:01] <SilverLion> nlsthzn, busy getting my 23 inch Screen back on track
[21:03] <nlsthzn> nice
[21:04] <SilverLion> nlsthzn, but i wait till the release of Lubuntu 12.04
[21:04] <nlsthzn> I am still trying to get my screen to use it's naitive resolution
[21:09] <SilverLion> nlsthzn, ;)