[05:05] <Kilos> morning all
[05:48] <Squirm> morning
[06:48] <Kilos> hiya maiatoday Tonberry
[06:50] <maiatoday> hi Kilos
[06:57] <Kilos> hi Vince-0
[07:02] <Vince-0> Hi Kilos !
[07:02] <Vince-0> Happy Wednesday
[07:17] <Kilos> hi henkj
[07:17] <henkj> hi Kilos
[07:28] <superfly> ohi
[07:28] <Kilos> hi superfly
[08:07] <smokestorm21> Hi
[08:08] <Kilos> hi smokestorm21
[08:08] <Kilos> hi jrgns
[08:09] <smokestorm21> My friend told me I should say hi (theblazehen)
[08:09] <Kilos> lol good
[08:09] <Kilos> tell us about yourself
[08:10] <smokestorm21> I love ubuntu. Although I'm a new user
[08:10] <Kilos> great. if you need help ask here
[08:11] <Kilos> basics i try help with. the rest the pros will as and when they get time from busy work schedules
[08:11] <smokestorm21> I'm using enlightenment, cinnamon and gnome-shell. My taste changes frequently
[08:12] <Kilos> lol
[08:12] <Kilos> im on unity and kde on another drive
[08:12] <jrgns> Hi Kilos, all
[08:12] <smokestorm21> Hi jrgns
[08:13] <smokestorm21> Bye ubuntu-za
[08:17] <charl_> good morning all
[08:17] <charl_> morning Kilos, jrgns
[08:17] <Kilos> 'hi ChanServ
[08:17] <charl_> lol
[08:17] <Kilos> ai
[08:17] <Kilos> hi charl_
[08:17] <charl_> :)
[08:17] <charl_> how's it going?
[08:17] <charl_> Maaz_: coffee on
[08:17]  * Maaz_ puts the kettle on
[08:17] <Kilos> good ty and you?
[08:17] <charl_> good thanks
[08:18] <charl_> i see maaz also got a tail :)
[08:18] <charl_> it's becoming a fashion statement here
[08:18] <Kilos> yeah
[08:21] <Maaz_> Coffee's ready for charl_!
[08:37] <Squirm> Maaz_: coffee please
[08:37] <Maaz_> Squirm: There isn't a pot on
[08:37] <Squirm> I am in need
[08:37] <Squirm> Maaz_: coffee on
[08:37]  * Maaz_ starts grinding coffee
[08:41] <Maaz_> Coffee's ready for Squirm!
[08:42] <inetpro> good mornings
[08:43] <Squirm> Maaz_: finally, thanks
[08:43] <Maaz_> Squirm: not at all
[08:43] <Squirm> lo inetpro
[08:43] <Kilos> hi inetpro
[09:29]  * superfly remembers the early days of Linux... switching distros faster than switching underwear
[09:41] <Kilos> hehe
[10:16] <Kilos> power gone. bbl
[10:29]  * Kilos wonders what that cut was for
[10:29] <Kilos> swines
[11:39] <Kilos> again. sigh
[11:41] <inetpro> Kilos: wasn't me, I promise
[11:42] <Kilos> na was pta electric department
[11:42] <Kilos> swines
[11:43] <Kilos> luckily ext4 seems to handle power cuts well
[11:44] <Kilos> would hate to lose this drive
[12:15] <magespawn> howdy all
[12:16] <Kilos> hey magespawn
[12:16] <magespawn> whats up Kilos? not much chatting for sure
[12:17] <Kilos> bad head day and tween rests trying to get old pc working with 98 so i can do the floppy thing
[12:19] <Kilos> sees a usb stick as floppy D:
[12:19] <Kilos> stupid thing
[12:20] <Kilos> then tells you it failed to open it
[12:21] <Kilos> im so happy i found ubuntu
[12:47] <Squirm> [14:41:24] .:***:. Buffer Playback...
[12:47] <Squirm> [14:41:24] .:Kilos:. [14:21:07] im so happy i found ubuntu
[12:47] <Squirm> [14:41:24] .:***:. Playback Complete.
[12:47] <Squirm> lol
[12:47] <Squirm> was in the while 20min the power was off
[12:48] <Kilos> lol
[12:48] <Squirm> Kilos: and it's not the filesystem you need to worry about. it's the hardware
[12:48] <Squirm> so ext4 may be able to handle it, but what about the hdd itself?
[12:48] <Kilos> yes ive lost a few drives after power cuts Squirm
[12:49] <Kilos> but not one since i went to ext4
[12:49] <Kilos> many when i was on winsucks
[12:49] <Squirm> personally, I don't think the fs has anything to do with it
[12:50] <Kilos> i read somewhere that ext4 is more able to handle frequent power cuts
[12:50] <Kilos> but dont ask me where
[12:52] <Kilos> yo sakhi lewe jy nog?
[12:52] <Kilos> sjoe
[12:52] <Kilos> gedink dis jou pc wat hier lurk
[12:53] <sakhi> yebo Kilos ek lewe nog besig man.
[12:53] <Kilos> mooi, besig is goed
[12:54] <sakhi> we lost international connection (flap) for seconds but we back now.
[12:55] <sakhi> my afrikaans is nie so goed nie ek probeer ;)
[12:56] <magespawn> Squirm: i think it has to do with file recovery and the writing process when the power fails
[12:57] <Kilos> oh sorry sakhi
[12:57] <Kilos> i forget whose who at times
[12:57] <sakhi> np
[12:57] <Kilos> but it seems fine to me
[13:13] <Squirm> magespawn: but surely you could format that failed drive and it'll be fine again? But for it not to work?
[13:17] <Kilos> nope Squirm some are dead
[13:17] <Kilos> i think when the power comes on and it wasnt seated properly it burns a boot sector or something
[13:18] <Kilos> beyong my understanding but ya
[13:20] <Squirm> I don't know what format the bootsector is
[13:21] <Kilos> mbr is machine code methinks. i also dont know what the boot sector is
[13:24] <magespawn> Squirm: sometimes yes
[13:25] <magespawn> i think that  tha way fs tells the drive to write affects it when the power goes off
[13:40] <Kilos> remember one used to have to park drives
[13:54] <magespawn> yup and with win 95 the os did it for you, i think it was win 95
[13:56] <Kilos> now i think thats where the prob came in if power cut before parking
[13:57] <Kilos> dunno how linux handles it
[13:58] <magespawn> not sure myself
[13:58] <Kilos> hehe howerver it does a better job
[14:16] <Kilos> bbl gonna try a unetbootin flash
[15:17] <magespawn> later all
[15:34] <charl_> what is this about jozihub, sounds interesting
[15:34] <charl_> http://jozihub.org/
[16:41] <superfly> magespawn: ping
[17:30] <magespawn> superfly pong
[18:12] <Kilos> hi Mezenir
[18:12] <Kilos> magespawn, he must be eating
[18:12] <Kilos> or youve got a short distance pong
[18:12] <magespawn> hey Kilos  Mezenir
[18:13] <magespawn> no worries
[18:28] <magespawn> kids take time
[18:38] <Kilos> hehe yeah
[18:38] <Kilos> lifetime
[18:47] <magespawn> charl_: that looks like a seriously cool idea
[18:50] <Kilos> night guys sleep tight
[18:50] <magespawn> night Kilos
[18:58] <smile4ever> pong :p
[19:04] <magespawn> hey smile4ever
[19:07] <smile4ever> magespawn: How are you? :)
[19:09] <magespawn> good and yourself?
[19:10] <smile4ever> i'm okay :)
[19:11] <smile4ever> I should take some rest :)
[19:11] <magespawn> rest is always needed
[19:15] <smile4ever> yeah, but I'm doing too much
[19:33] <smile4ever> bye ;:)
[19:54] <magespawn> good night all
[20:02] <superfly> magespawn: no worries, found out what I needed from our reason for travelling up to kzn


[10:43] <physiciantaiwan[> Ubuntu Studio 22.10 doesn't support Wi-Fi Network with WPA3-Personal Encryption?
[11:51] <gordonjcp> physiciantaiwan[: should do
[11:51] <gordonjcp> physiciantaiwan[: not all wifi chipsets seem to work well with it though
[11:58] <physiciantaiwan[> My Laptop is old Wi-Fi 5 One(AC3160)


[13:49] <Aki-Thinkpad> Ah; there are so many ubuntu development channels; #ubuntu+1, #ubuntu-app-devel, #ubuntu+2 ... is there any that I am missing?
[13:59] <dobey> Aki-Thinkpad: are you looking for something specific?
[14:00] <Aki-Thinkpad> dobey, I just like being up to date with the development cycle, partly because I am using the platform, and plan to contribute eventually.
[14:00] <Aki-Thinkpad> (Already developing ubuntu-touch stuff)
[14:01] <Aki-Thinkpad> for me, its a really exciting platform to be involved in.
[14:01] <dobey> lurking in irc is probably not the best way to be "up to date"
[14:02] <dobey> i don't know if there's a mailing list for all the changes that get uploaded/synced to the dev release, though
[14:06] <sergiusens> dobey: Aki-Thinkpad you can subscribe to the archive uploads I guess
[14:07] <Aki-Thinkpad> sergiusens, where is that?
[14:08] <Aki-Thinkpad> dobey, very true. Still, lurking irc is easy.
[14:08] <sergiusens> Aki-Thinkpad https://lists.ubuntu.com/mailman/listinfo/trusty-changes
[14:08] <Aki-Thinkpad> sergiusens, thanks!
[14:08] <sergiusens> Aki-Thinkpad: that isn't of use now though, you'll need to wait for the archive to open up for U
[14:08] <Aki-Thinkpad> oh I forgot one; #ubuntu-on-air
[14:11] <dobey> Aki-Thinkpad: and #ubuntu-desktop #ubuntu-kernel #ubuntu-packaging #ubuntu-release #ubuntu-xorg etc etc i think (plus kubuntu, xubuntu, etc specific channels if you want those)
[14:11] <Aki-Thinkpad> dobey, thanks, I appreciate it
[14:11] <Aki-Thinkpad> !cookie
[14:12] <dobey> !rum
[14:12] <dobey> bah
[14:12] <Aki-Thinkpad> ha ha
[14:12] <Aki-Thinkpad> I lol'd.
[14:12] <dobey> 10:10 <ubottu> Sorry, I don't know anything about rum
[14:12] <dobey> yes, that's obvious
[14:12] <Aki-Thinkpad> !wine
[14:12] <Aki-Thinkpad> there you go
[14:13] <dobey> http://www.yellow5.com/pokey/archive/index160.html
[14:14] <ali__> to every body:i want to get all processes that they are running in foreground
[14:15] <Aki-Thinkpad> dobey, o_O  sort of reminds me of hackles... but more abstract
[14:18] <Aki-Thinkpad> dobey, #ubuntu-tablet + #ubuntu-tv are also there. I
[14:18] <Aki-Thinkpad> -I
[15:39] <phunyguy> hey is this the correct channel to ask some questions regarding a ppa?
[15:39] <infinity> phunyguy: The owner of the PPA is probably the better person to ask.  Or #launchpad if you're looking for help with your own PPA.
[15:40] <phunyguy> ... I am the owner....
[15:40] <phunyguy> oh ok
[15:40] <phunyguy> thanks
[17:19] <jayaura> Hello, I am a kernel noob, and was building one the trusty. but dmesg says my module is not signed, and hence tainting the kernel. Is there a way I can get the private keys for signing those modules I Make?
[17:19] <jayaura> "building one ON the trusty"
[17:21] <jayaura> Of course I mean the keys for the one I am already running 3.13.0-24-generic
[17:21] <jayaura> or is that a *private* property of ubuntu ?
[17:23] <infinity> jayaura: It's not so much that it's private, but rather that it's not known even to us.  The key used to sign modules in the archive kernel is generated and thrown away during the build.
[17:24] <jayaura> infinity, hmm so it means I have to build my own kernel with module signing turned off to get away with this problem, right? Do I have any other solution ?
[17:24] <infinity> jayaura: If you're building your own kernel, that's not a problem, as you'd just sign with your own key.  But if you're building modules for use with the archive kernel (using dkms, or by hand), then you'll pretty much have to live with them being unsigned.  This is a known issue that we need to come up with a better solution for.
[17:25] <infinity> jayaura: We don't enforce signature checking, so your module will still load.
[17:25] <infinity> jayaura: The taint listing isn't fatal, just informative.
[17:26] <jayaura> infinity, yes, I get it. Thanks for the info! ,  and for the quick response! :)
[18:03] <stokachu> barry: for private python modules using entry_points in their setup.py do you know how to make sure that private python module path exists in sys.path?
[18:04] <stokachu> barry: right now a console script file is generated automatically, should i put that generated file in /usr/share/<module> and s ymlink it to /usr/bin?
[18:06] <stokachu> ls
[18:11] <barry> stokachu: you have to hack sys.path manually in your script.  some packages do the symlink dance and others just install into /usr/bin.
[18:11] <stokachu> barry: ok cool, i think ill just place the scripts in /usr/share/<mod> and add the file to the links file in the package
[18:12] <stokachu> was just curious what 'the right way' was
[18:13] <barry> stokachu: i think this is all debian policy has to say on the matter: https://www.debian.org/doc/packaging-manuals/python-policy/ch-programs.html#s-current_version_progs
[18:13] <barry> i.e. nothing about /usr/bin
[18:13] <stokachu> ok cool
[18:14] <stokachu> i think this way is clean enough no-one will complain ;)
[18:15] <barry> cool
[18:35]  * ScottK hears rickspencer3 screaming "lost development velocity" in the distance.
[18:36]  * rickspencer3 shakes fist
[18:57] <orbisvicis> how do I pin/prefer a virtual package in pbuilder? For example PackageA depends PackageB and PackageC provides PackageB, how do I give PackageC priority over PackageB ?
[18:58] <orbisvicis> PackageC is local, PackageB remote, I already give local packages higher priority but PackageB still has priority
[19:06] <dobey> orbisvicis: change your build-depends to have "PackageA, PackageC | PackageB" rather than just PackageA; although if the dependency is already satisfied, i don't see why apt would pull the other one in, unless something else depends specifically on PackageB, in your dep tree
[19:12] <orbisvicis> s/PackageA depends/& on/
[19:12] <orbisvicis> dobey: that works, but I was hoping I could simply pin a virtual "provided" package rather than change the build-depends
[19:13] <orbisvicis> dobey: it seems pinning ignores virtual packages, PackageB is selected simply because the name matches
[21:45] <karab44> hello
[21:46] <karab44> when this bugfix will be available for update ? https://launchpad.net/~eugenesan/+archive/ppa/+sourcepub/4095467/+listing-archive-extra
[21:46] <karab44> okay #ubuntu-bugs I undersand :)
[22:23] <orbisvicis> this pinning stuff is very fragile. Can anyone provide an example to match/pin all nonlocal (repository) apache packages ?
[22:53] <orbisvicis> as soon as I use a package name, the pin no longer works. Only * works as Package:
[22:58] <orbisvicis> the mapping is shown in apt-cache policy but the priority is not applied, in apt-cache policy <packagename>
[23:42] <orbisvicis> hm, I didn't read the policy correctly. Actually the same priority is applied to all packages matching <package name>, irrespective of "Pin:" attributes


[03:12] <Plug> Hmm.
[03:12] <Plug> Trying to follow the packaging guide on using pbuilder.
[03:13] <Plug> It's a bit lacking.  Seems like it was tacked on without much forethought, as it's not really used throughout the document
[03:13] <Plug> also, suggesting source, dh_make and cdbs - can we pick one and use it throughout?
[03:25] <rob> its important to know all methods imo
[03:25] <rob> but yes, the guide needs lots of love
[03:25] <Plug> perhaps as appendices
[03:25] <Plug> I'm having a go at some packaging using it now
[03:26] <Plug> I'll be happy to do a spot of editing at the end
[03:26] <rob> be aware if your setting up a chroot that there is a problem with the locales section
[03:27] <rob> you need to also install language-pack-(some country code) to set them up correctly
[03:28] <nixternal> if you want the best input on the packaging guide, crimsun will be the one on that...he knows every inch of packaging
[03:28] <rob> yeah
[03:28] <nixternal> pbuilder and dh_make do the same thing, but dh_make is for packages that haven't been debianized...and pbuilder is
[03:29] <rob> I'd really like to see all the motu guys give it a once over and make suggestions, if they can find the time
[03:29] <nixternal> i followed the packaging guide and had no problem what so ever...it gives you everything you need to know in order to understand packaging and get going
[03:29] <Plug> I'm going to have debianize the package myself, make sure I get the deps right
[03:29] <Plug> _then_ build under pbuilder
[03:29] <Plug> so I have to install the -dev packages twice
[03:29] <Plug> so what I really want is a chroot, I guess
[03:30] <rob> yes, but I found myself having to seek addtional information after reading the packaging guide for a few things
[03:30] <rob> its all on the wiki if you look though
[03:30] <nixternal> that is what #ubuntu-motu is for..plus half the time crimsun ansered my questions in a matter of seconds
[03:30] <nixternal> hiya Madpilot
[03:30] <Madpilot> hi nixternal
[03:31] <nixternal> i am having one heck of a time trying to get a ubuntu-list setup for the Chicago LoCo team...nobody replies to me ;(
[03:37] <LaserJock> nixternal: dh_make and pbuilder don't do the same thing at all ;-)
[03:37] <LaserJock> Plug: and if you want to suggest things for the Packaging Guide email the ubuntu-doc list and I'll look into it
[03:38] <nixternal> well..i did say that wrong...you run dh_make prior to pbuilder
[03:38] <Plug> LaserJock: I'll be in touch, thanks
[03:38] <nixternal> dh_make is a debianizer script, and pbuilder is the package builder
[10:42] <mdke> nixternal_: you mailed mailman@lists?
[10:51] <Burgundavia> nixternal_: the person you need to speak with is jdub
[10:56] <mdke> mpt: here?
[11:09] <mpt> mdke, vaguely
[11:09] <mdke> mpt: just looking over your patch, is good stuff.
[11:09] <mpt> I'll be paying more attention in 20min or so
[11:09] <mpt> cool
[11:10] <mdke> there are a few minor things I've noticed, and one or two things I think should be discussed as a team
[11:10] <mdke> the language changes are all nice
[11:21] <mpt> ok, back
[11:23] <mpt> I probably made dozens of mistakes, I wasn't entirely conscious at the time :-)
[11:24] <crimsun> impressive for only partly conscious.
[11:24] <mdke> mpt: has the menu entry for alacarte changed in edgy?
[11:25] <mpt> No, I'm using Dapper, and I've never seen it called "A La Carte"
[11:25] <mdke> mpt: look in the menu
[11:25] <mpt> I did, before changing it
[11:26] <mdke> what's the menu entry?
[11:26] <mdke> on my system it is "Alacarte Menu Editor"
[11:27] <mpt_> grrr
[11:27] <mpt_> mdke: <mpt> "Applications Menu Editor"
[11:27] <mdke> how odd
[11:27] <mpt_> want a screenshot? :-)
[11:27] <mdke> why is it different on my system?
[11:27] <mdke> no, i believe you
[11:30] <mdke> well, if that is the default menu entry, it's certainly an improvement
[11:30] <mdke> but it's not like that on my system, for some reason
[11:30] <mpt__> Mine's an upgrade from 5.10, not a fresh install, if that makes any difference
[11:30] <mdke> me too, iirc
[11:31] <mdke> mpt_: the only serious thing was removing much of the preface - I agree that is a good idea if this is supposed to be on-screen help, although if it remains a book we'll want to put it back, I think
[11:32] <mpt__> mdke, yes, maybe there should be a divergence
[11:33] <mpt> whee
[11:34] <mpt> Possibly the on-screen help would be a clean subset (on the paragraph level) of the books, but possibly not
[11:35] <mpt> hmmmmm
[11:35] <mpt> Where should documents about the development of the help go? wiki.ubuntu.com, or help.ubuntu.com? :-)
[11:41] <mdke> mpt: like a spec? On wiki.ubuntu.com
[11:42] <mdke> preferably under DocumentationTeam/
[11:46] <mdke> mpt__: is "Disks Manager" another menu entry that I don't have?
[11:50] <Burgundavia> mdke: system--admin--disks
[11:51] <mdke> Burgundavia: that's what I have too
[11:51] <mdke> mpt__: why "Disks Manager"?
[11:52] <mdke> ah, I see, that's what it's called once you open it, fine
[12:04] <melodie> bonjour
[12:09] <mpt_> kia ora
[12:11] <mdke> mpt_: ok, I've replied on the list, have to go now
[12:11] <mpt_> thanks mdke
[12:12] <mdke> thank _you_
[12:14] <melodie> hello mdke,
[12:15] <melodie> mdke what about doing a '/back' to appear present ? :D
[12:16] <melodie> mdke, it seems you have to go, I was coming to question you : when are you back ?
[02:07] <mpt_> mdke, maybe you installed A La Carte yourself before ubuntu-desktop did?
[02:07] <mpt_> that way the original menu entry wouldn't have been overwritten
[02:10] <dsas> mpt_: I thought it got changed from "applications menu editor" when it got the ability to edit the "system" menu too.  I'm off for lunch
[02:51] <mdke> thanks for that
[02:54] <mpt_> thanks mdke
[04:57] <jrib> Does anyone know what happened to hardware support lists?  https://help.ubuntu.com/community/SupportedHardware links to a page that no longer exists and I can't seem to find the lists on my own
[05:03] <mdke_> jrib: https://wiki.ubuntu.com/HardwareSupport
[05:03] <jjesse> monring :)
[05:03] <mdke_> hi jjesse
[05:05] <jrib> mdke_: hmm, thanks.  How come the title search doesn't turn that up?  Does it only search things under huc/community?
[05:06] <mdke_> jrib: yes
[05:06] <jrib> mdke_: and of course my second question is what is the right way to fix the link on https://help.ubuntu.com/community/SupportedHardware? :)
[05:07] <mdke_> jrib: refresh the page, and see what I did.
[05:15] <jrib> mdke_: k, while reading https://help.ubuntu.com/community/UserDocumentation it has that same hardware link that's broken.  Is it possible to setup a redirect or does that just create clutter and I should just correct this page too like you did the one before?
[05:17] <mdke_> jrib: I think we should fix the link to point to the other wiki. But it might be worth doing a redirect if there are lots of those broken links, let's see
[05:18] <mdke_> no, there aren't many such links
[05:18] <jrib> mdke_: ok, I'll take care of this one
[05:18] <mdke_> thanks
[08:36] <linuxmonkey> should we add the commercial repo's in the repo's howto?
[09:24] <Burgundavia> linuxmonkey: probably


[01:01] <pmatulis> mdke: there?
[01:01] <mdke> pmatulis: (In case I'm not around at the moment, please provide a bit of information about what you want and I will respond when I get back)


[06:46] <mborzecki> morning
[06:55] <zyga> good morning
[06:55] <zyga> mborzecki: how was your weekend?
[06:55] <mborzecki> zyga: indoors mostly ;)
[06:56] <mborzecki> zyga: is it equally cold in waw?
[06:56] <zyga> me too, what a coincidence :)
[06:57] <zyga> I see we had a 2.44.1
[06:58] <zyga> anything special on Friday?
[07:00] <mborzecki> zyga: idk, spent almost whole friday fighting console conf
[07:51] <zyga> re
[08:03] <pstolowski> mornings
[08:04] <mvo> good morning zyga and pstolowski
[08:06] <zyga> hey pawel, hey mvo
[08:06] <zyga> I'm not sure how it's around where you live
[08:07] <mborzecki> pstolowski: mvo: morning guys
[08:07] <zyga> but when I walked outside earlier today
[08:07] <zyga> it was so so incredibly quiet
[08:07] <zyga> I heard birds chirping and not much else
[08:08] <zyga> I saw maybe four cars on a wide artery that is normally stuck in traffic at this time
[08:08] <zyga> it's so surreal
[08:16] <zyga> travis very non responsive today
[08:16] <zyga> at least for me
[08:17] <mvo> zyga: yeah, travis had half-a-day of database upgrade at saturday
[08:17] <zyga> uh
[08:17] <mvo> zyga: and I no longer have the "rebuild" button
[08:17] <zyga> what could possibly go wrong now
[08:18] <zyga> I'm trying to open or restart runs
[08:18] <mvo> zyga: can you still restart runs?
[08:20] <zyga> no, I cannot get the pages to load
[08:20] <zyga> travis times out, gh is responding fast
[08:30] <mup> PR snapd#8315 opened: tests: ensure session agent service is ready in prepare <Created by mvo5> <https://github.com/snapcore/snapd/pull/8315>
[08:34] <mup> PR snapd#8316 opened: github: add prototype workflow running unit tests <Created by zyga> <https://github.com/snapcore/snapd/pull/8316>
[08:42] <pedronis> jamesh: hi, we sometimes see failures of snap-session-agent-service-control , https://api.travis-ci.org/v3/job/665599033/log.txt
[08:43] <jamesh> looking
[08:46] <pedronis> jamesh: seems mvo was also looking in that: https://github.com/snapcore/snapd/pull/8315
[08:46] <mup> PR #8315: tests: ensure session agent service is ready in prepare <Created by mvo5> <https://github.com/snapcore/snapd/pull/8315>
[08:48] <mvo> jamesh: yeah, if you could review that PR 8315 that would be great
[08:48] <mup> PR #8315: tests: ensure session agent service is ready in prepare <Created by mvo5> <https://github.com/snapcore/snapd/pull/8315>
[08:49] <mvo> jamesh: it might be too simplistic
[08:50] <jamesh> mvo: is there a systemctl invocation to wait for a unit to be started?
[08:51] <jamesh> e.g. I wonder if we could do "systemctl --user start sockets.target"?
[08:51] <mvo> jamesh: maybe, this is also about socket activation so start might test less than what we tested before?
[08:53] <jamesh> mvo: the tests expect that sockets.target has completed: i.e. systemd has created the unix domain socket and is prepared to start the session agent when someone connects to it
[08:53] <zyga> hey pedronis, good morning
[08:53] <zyga> pedronis: do you remember that A=$B; B=$C; C=foo; problem my earlier implementation of environment untangled?
[08:53] <jamesh> I don't think this would meaningfully change what is being tested, and might get rid of the race
[08:54] <pedronis> zyga: yes
[08:54] <pedronis> is somebody trying to do that?
[08:54] <zyga> pedronis: it seems snapcraft has a bug where it would be useful, it reorders environment entires, it sorts them :|
[08:54] <zyga> pedronis: I filed a bug for snapcraft
[08:54] <pedronis> it's definityl a snapcraft bug
[08:54] <zyga> yeah
[08:55] <zyga> just found this ironic
[08:55] <mvo> jamesh: ok, feel free to push something else to the PR or a new one, happy with a better fix :)
[09:05] <jamesh> mvo: I don't think I can edit other peoples' PRs, so I'll create a new one
[09:06] <mvo> jamesh: thank you
[09:19] <mup> PR core20#28 opened: Add iptables package <Created by alfonsosanchezbeato> <https://github.com/snapcore/core20/pull/28>
[09:26] <mup> PR snapd#8317 opened: many: make sure ephemeral failover snapd does not open sockets <Created by pedronis> <https://github.com/snapcore/snapd/pull/8317>
[09:37] <zyga> please review https://github.com/snapcore/snapd/pull/8316
[09:37] <mup> PR #8316: github: add prototype workflow running unit tests <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8316>
[09:39] <zyga> last run was one minute and 55 seconds
[09:39] <zyga> for "go test" results
[09:45] <mup> PR snapd#8298 closed: many: enumerate system seeds, return them on the /v2/systems API endpoint <UC20> <Created by bboozzoo> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8298>
[09:46] <zyga> brb
[09:47] <mup> PR snapd#8318 opened: tests: ensure sockets target is ready in session agent spread tests <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8318>
[09:51] <mup> PR snapd#8318 closed: tests: ensure sockets target is ready in session agent spread tests <Created by jhenstridge> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8318>
[10:12] <pedronis> mvo: I think you closed the wrong PR ^  8318 sees it was closed in favor of 8318
[10:12] <pedronis> s/sees/says/
[10:14] <mvo> pedronis: oh, sorry, /me is a muppet
[10:15] <mup> PR snapd#8318 opened: tests: ensure sockets target is ready in session agent spread tests <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8318>
[10:16] <mup> PR snapd#8315 closed: tests: ensure session agent service is ready in prepare <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8315>
[10:18] <pstolowski> pedronis: hi, i pushed some changes to search v2 wrt error-list. it turned out to be slightly annoying and the change may look a bit confusing, happy to discuss
[10:18] <pedronis> pstolowski: thx, in a meeting atm
[10:27] <mup> PR snapd#8319 opened: github: run unit tests and spread via github actions <Created by zyga> <https://github.com/snapcore/snapd/pull/8319>
[10:28] <zyga> wow, github actions runner is FOSS
[10:28] <zyga> https://github.com/actions/runner
[10:28] <zyga> and can run on hosted machines
[10:30] <zyga> this is neat https://github.com/actions/labeler
[10:30] <zyga> action to put labels based on what's changed in the tree
[10:39] <ackk> zyga, hi, any chance https://github.com/snapcore/snapd/pull/8265 can be merged? I'd be happy to test a snapd snap with that fix
[10:39] <mup> PR #8265: tests: add regression test for MAAS refresh bug <Created by zyga> <https://github.com/snapcore/snapd/pull/8265>
[10:39] <zyga> ackk: this is just a regression test, there's no fix there
[10:39] <zyga> the fix has been merged and is behind a feature flag, long ago
[10:39] <ackk> zyga, the https://trello.com/c/QjX63wGx/201-4-document-snap-downgrade ?
[10:40] <ackk> zyga, I'm still seeing that issue with it enabled
[10:40] <ackk> zyga, it happens all the time for me
[10:40] <ackk> install/refresh/remove
[10:40] <zyga> I cannot see that
[10:40] <ackk> actually,even when I connect interfaces
[10:40] <zyga> let me log in
[10:40] <ackk> zyga, sorry, wrong link
[10:41] <alvesadrian> good morning
[10:41] <alvesadrian> zyga
[10:41] <ackk> zyga,  I meant if it's robust-mount-namespace-updates
[10:41] <alvesadrian> there is way to sort this with jetty
[10:41] <ackk> copy/paste is a  bit messed up in focal
[10:41] <zyga> ackk: I'm sorry, is this different from any of the earlier fixes we did recently?
[10:41] <alvesadrian> zyga https://pastebin.com/W9iT0sF3
[10:42] <ackk> zyga, wdym?
[10:42] <zyga> ackk: I'm confused
[10:42] <zyga> ackk: can you tell me if the thing that is failing is one of the things we inspected last week
[10:42] <alvesadrian> Starting Jetty: chown: changing ownership of '/tmp/oxauth.pid': Operation not permitted
[10:42] <alvesadrian> su: must be run from a terminal
[10:42] <zyga> alvesadrian: I'm sorry, I cannot debug things for you
[10:42] <ackk> zyga, https://paste.ubuntu.com/p/mjV2zR4Pcn/ is an example of failure
[10:43] <alvesadrian> zyga is not a debug
[10:43] <alvesadrian> am not asking for that
[10:43] <zyga> ackk: does this represent one of the failures we've inspected before or is a new failure?
[10:43] <alvesadrian> is how or why snap is failing to run a jetty app using jetty and the app in the same yaml
[10:44] <ackk> zyga, I'm not sure. one question I have is, does snap-discard-ns clean up everything? I wonder if running that might cause issues with later operations
[10:44] <alvesadrian> zyga where i can find snapcraft.yaml
[10:44] <zyga> ackk: yes it does
[10:44] <alvesadrian> zyga for java server apps
[10:44] <zyga> ackk: it should be invoked when there are no processes around, otherwise you fracture the view, some inhabit old world, some new
[10:44] <zyga> alvesadrian: I don't know, did you try checking on the forum?
[10:44] <alvesadrian> yes
[10:44] <zyga> alvesadrian: since you mentioned chown, snaps should not change ownership of files
[10:44] <alvesadrian> if course i already open a ticket
[10:45] <zyga> ticket?
[10:45] <alvesadrian> sorry a post
[10:46] <ackk> zyga, so, just rebooted the container, I get this: https://paste.ubuntu.com/p/NVQ34Jvwxw/
[10:46] <zyga> ackk: I'm not entirely sure what rebooting a container does
[10:47] <zyga> does it really discard mount namespaces?
[10:47] <alvesadrian> zyga https://forum.snapcraft.io/t/issues-with-different-users-chown-and-su/16129
[10:47] <ackk> zyga, well, it should? I mean it's like a a machine reboot
[10:47] <zyga> I don't know
[10:47] <zyga> that's a lxd question
[10:47] <zyga> alvesadrian: please familiarize yourself with https://forum.snapcraft.io/t/multiple-users-and-groups-in-snaps/1461
[10:47] <alvesadrian> i already read that
[10:48] <ackk> zyga, what should I check to see if the correct namespaces are set up?
[10:48] <alvesadrian> i cannot find a snapcraft.yaml file as example of people bullding a java app with the tocamcat or jetty on it
[10:48] <zyga> great, then you should understand that you cannot chown anything to 1000 or most other values
[10:48] <zyga> I cannot help you beyond that, I don't even know what jetty is
[10:48] <alvesadrian> that will be great for me but i cannot find it like nobody did an snap of hat
[10:49] <alvesadrian> jetty==tomcat
[10:49] <zyga> ackk: it's hard because of startup services,
[10:49] <zyga> ackk: can we spin it another way? can you report a bug with reproducer?
[10:49] <zyga> ackk: I cannot promise I will look instantly
[10:49] <zyga> as we have some other fires
[10:49] <zyga> but I will do my best
[10:49] <ackk> zyga, sure I'll try
[10:50] <alvesadrian> couldnt find any example of snaocraft.yal for a java app containing a tomcat on it
[10:50] <alvesadrian> or a java server app to serve the app
[10:50] <zyga> I don't know anything about tomcat but I googled some results
[10:51] <zyga> did you go over the first few hits?
[10:51] <alvesadrian> nothing man
[10:51] <alvesadrian> being the whole weekend digging
[10:51] <alvesadrian> its like nobody build it a snappy for tomcat app or java server app
[10:52] <alvesadrian> forget about tomcat, just mean a java server app
[10:52] <alvesadrian> nobody builds java server apps on snaps
[10:53] <zyga> alvesadrian: did you check out https://snapcraft.io/docs/java-applications ?
[10:53] <alvesadrian> course
[10:53] <zyga> can you post some feedback about that to the forum
[10:53] <zyga> I'm sorry, I"m not the spokesperson for snapd :)
[10:53] <zyga> I cannot help everyone
[10:53] <alvesadrian> didnt mention anything about using an external java serer as source
[10:53] <alvesadrian> i know
[10:54] <alvesadrian> just wondering if u know something about it
[10:54] <zyga> I don't know what an external java server is (is that tomcat?)
[10:54] <alvesadrian> thans
[10:54] <alvesadrian> external means dont using the plug of jdk
[10:54] <alvesadrian> thata what i mean getting from source
[10:54] <alvesadrian> download it and running
[10:54] <alvesadrian> thats what i mean
[10:55] <zyga> what does "the plug of jdk" mean?
[10:55] <alvesadrian> like a snap that fetch tomcat(java server) and run the app inside
[10:55] <zyga> why fetcH?
[10:55] <zyga> why not bundle tomcat at build time?
[10:55] <alvesadrian> the pluging for the jdk framework
[10:56] <alvesadrian> what u mean?
[10:56] <alvesadrian> an example?
[10:56] <zyga> maybe I misunderstand but from what you are saying the snap package would, after being installed, download tomcat and do something with it
[10:56] <alvesadrian> nope
[10:57] <alvesadrian> snap has a part tomcat and anotehr part for the java app
[10:57] <zyga> I see
[10:57] <zyga> and what is the problem there?
[10:57] <zyga> downloading tomcat?
[10:57] <ackk> zyga, fwiw https://paste.ubuntu.com/p/wQpmk2mkcS/ reproduces it for me. I'm not sure whether to file a new bug or it's just a manifestation of the previous one?
[10:57] <alvesadrian> i cant find an example about how to
[10:57] <zyga> alvesadrian: is tomcat special? is downloading it different from downloading other files?
[10:57] <alvesadrian> place it and run it with the java app
[10:57] <alvesadrian> nope
[10:58] <alvesadrian> just a source zip file
[10:58] <alvesadrian> static
[10:58] <zyga> alvesadrian: did you check the snapcraft documentation for parts?
[10:58] <alvesadrian> it will run a daemon
[10:58] <zyga> there's a way to download things there
[10:58] <zyga> source: URL
[10:58] <alvesadrian> yes
[10:58] <zyga> it can fetch tomcat, or whatever
[10:58] <zyga> so?
[10:58] <zyga> ackk: at this rate, I'd say please file one
[10:58] <zyga> even if it's a dupe
[10:58] <ackk> zyga, ok
[10:58] <zyga> it's easier for me to keep a TODO list this way
[10:59] <zyga> ackk: I'm sorry for the issues, it's likely that maas has found more bugs than an average snap by now :)
[10:59] <ackk> zyga, we like to live on the bleeding edge :)
[10:59] <zyga> alvesadrian: so can you download tomcat using snapcraft part or not?
[10:59] <alvesadrian> yes
[10:59] <alvesadrian> as a part
[10:59] <zyga> ok, so what's the problem again?
[11:00] <alvesadrian> not tomcat specially jetty but they are similar
[11:00] <alvesadrian> after download
[11:00] <alvesadrian> move the java app into the webapp folder
[11:00] <alvesadrian> but not cluu how to run it
[11:00] <zyga> with a service declaration
[11:01] <ackk> alvesadrian, add an app: with daemon:simple and command pointing to a script which runs tomcat?
[11:01] <zyga> (remember to exec in the last line of the script)
[11:01] <alvesadrian> where i can get a snapcraft.yaml with an example
[11:01] <alvesadrian> about how to do it?
[11:02] <zyga> I really think you should slow down and look at snapcraft docs
[11:02] <ackk> zyga, oh, so maybe I'm still hitting https://bugs.launchpad.net/snapd/+bug/1867752 actually
[11:02] <mup> Bug #1867752: Unable to remove snap with content interface (with robust namespace update) <snapd:Fix Committed by zyga> <https://launchpad.net/bugs/1867752>
[11:02] <zyga> https://snapcraft.io/docs/services-and-daemons
[11:02] <ackk> zyga, is this available in a snapd snap?
[11:02] <alvesadrian> so i need to create a service declaration to run the script that start tomcat?
[11:02] <ackk> alvesadrian, yes
[11:02] <zyga> alvesadrian: ^ please check that page
[11:03] <alvesadrian> zyga thanks thats enough
[11:03] <zyga> ackk: this should be in edge
[11:03] <ackk> zyga, ok, I'll test with that, see if it solves the issue. thanks
[11:03] <alvesadrian> ackk also thanks
[11:03] <zyga> thanks!
[11:06] <ackk> zyga, that seems to work, thanks!
[11:10] <alvesadrian> zyga final question
[11:11] <alvesadrian> SNAP_DATA SNAP_USER_DATA SNAP_COMMON
[11:11] <alvesadrian> those contaiing dirs writeables
[11:11] <alvesadrian> can be chown?
[11:11] <alvesadrian> teh files inside fo those?
[11:12] <alvesadrian> ackk also if you know this ^^^
[11:12] <ackk> alvesadrian, yes those are writable. why do you need chown?
[11:14] <alvesadrian> java developers are asking me
[11:14] <alvesadrian> why we cannot chown to jetty or tomcat user
[11:14] <alvesadrian> why it needs to run as root
[11:14] <ogra> where would that user live
[11:14] <ackk> alvesadrian, services run as "root" in the container
[11:14] <ackk> alvesadrian, that's a confined root user though, so it's safe
[11:14] <alvesadrian> no clue why they complaing about that
[11:15] <ogra> iirc fchown and chown syscalls are blocked by seccomp by default
[11:15] <ogra> you can make them a no-op by using snapcraft-preload if you can not change the code
[11:17] <ogra> if your developers heavily insist to drop to a user (which is pretty much nonsense inside confinement, but some apps can not be changed) you can use https://forum.snapcraft.io/t/system-usernames/13386
[11:17] <ogra> ... but need to change your app to use this username ...
[11:18] <alvesadrian> ogra the problem is they want to run jetty services
[11:18] <alvesadrian> with user jetty
[11:18] <ogra> well, and they can not run it as root ?
[11:19] <ogra> it is inside confinement ... switching to that user brings no benefit
[11:19] <alvesadrian> ogra here is teh case
[11:19] <alvesadrian> https://pastebin.com/Uwe6vF8r
[11:19] <alvesadrian> ogra https://pastebin.com/Uwe6vF8r
[11:19] <ogra> but they *can* switch to an unprivileged user if needed ... as described in the doc i just gave you above
[11:20] <ogra> so make them use that and configure it in the snapcraft.yaml
[11:20] <ogra> or convince them to run it as root
[11:21] <ackk> it should be possible to run jetty as root
[11:21] <ackk> there are few apps that really can't be convinced to run as root (postgres being one of them)
[11:21] <ogra> right
[11:21] <alvesadrian> ackk https://pastebin.com/Uwe6vF8r
[11:22] <alvesadrian> thats an exxample of whats going on
[11:22] <ackk> that's a flask app though? I don't see how is it relevant
[11:24] <alvesadrian> su - jetty
[11:24] <alvesadrian> I also set JETTY_USER=jetty for command
[11:24] <ogra> well, su or sudo inside snaps dont work anyway
[11:24] <alvesadrian> Jython 2.7.2rc1 (v2.7.2rc1:1fcef1abf1d6, Mar 1 2020, 16:27:06)
[11:24] <alvesadrian> [OpenJDK 64-Bit Server VM (Amazon.com Inc.)] on java1.8.0_222
[11:24] <alvesadrian> Type "help", "copyright", "credits" or "license" for more information.
[11:24] <alvesadrian> >>>
[11:24] <alvesadrian> >>> f=open("/tmp/text.txt",'w')
[11:24] <alvesadrian> >>> f.write("test")
[11:24] <alvesadrian> >>> f.close()
[11:24] <alvesadrian> >>> import os
[11:24] <alvesadrian> >>> os.getuid()
[11:24] <alvesadrian> 1000
[11:24] <alvesadrian> >>> os.system('chown 1000 /tmp/text.txt')
[11:24] <alvesadrian> chown: changing ownership of '/tmp/text.txt': Operation not permitted
[11:24] <alvesadrian> 1
[11:24] <alvesadrian> Even see this:
[11:24] <alvesadrian> >>> os.stat("/tmp/text.txt").st_uid
[11:24] <ogra> and chown is blocked by seccomp
[11:24] <alvesadrian> 1000
[11:25] <alvesadrian> so we need to fix rthat app code?
[11:25] <ogra> run jetty as root, run the commands as root ...
[11:25] <pedronis> or use snap_daemon if possible
[11:25] <ogra> the snap confinement is designed to be root safe
[11:26] <ackk> alvesadrian, is that chown a test or actual code you have ?
[11:26] <ogra> right, if you really cant use root, use snap_daemon ...
[11:27] <alvesadrian> code
[11:27] <ogra> the point is, there is no jetty user on systems you install your snap on ... and nothing in snaps that allows to create such a user
[11:27] <alvesadrian> thats real code
[11:28] <ackk> alvesadrian, maybe unrelated but, you shouldn't really need to chown the file to the same user that created it?
[11:28] <alvesadrian> am not the developer
[11:28] <alvesadrian> just packaging
[11:28] <ogra> use snapcraft-preload to make chown a no-op then
[11:29] <ogra> https://github.com/sergiusens/snapcraft-preload
[11:31] <ackk> alvesadrian, fwiw if the service is running as root in the snap, that chown will succeed (assuming you replace 1000 with os.getuid()): https://paste.ubuntu.com/p/v88DXT45bh/
[11:32] <ackk> 1000 won't as you can only chown to the same user
[11:32] <ackk> (and root doesn't have CAP_DAC_OVERRIDE in the snap)
[12:12] <mup> PR snapd#8320 opened: Updates to login-session-observe and network-manager interfaces <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/8320>
[12:37] <pedronis> pstolowski: commented, let me know
[12:38] <mup> PR snapd#8312 closed: many: fix packages having mistakenly their copyright as doc <Simple 😃> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8312>
[12:38] <pedronis> pstolowski: also ping me when is ready for re-review, I saw there bits still not addressed. thanks
[12:56] <pedronis> pstolowski: I did a pass on #8309
[12:56] <pedronis> thanks for it
[12:56] <mup> PR #8309: o/configcore: implement Apply method for early configuration of core <Created by stolowski> <https://github.com/snapcore/snapd/pull/8309>
[12:59] <pstolowski> pedronis: thanks! i just replied to one of your search v2 comments
[13:02] <pedronis> pstolowski: answered
[13:03] <pedronis> pstolowski: I'm sure we can do something but yes touching the global helper is delicate so we can postone
[13:04] <pstolowski> pedronis: thanks. yes it's all messy and super confusing already. nb, error-list vs error_list in struct storeErrors, but that's probably historical?
[13:05] <pedronis> pstolowski: yes, that's used in the bit that we should drop when we can
[13:09] <mborzecki> pedronis: do you think we could stay after the standup and discuss integration of snap-recovery-chooser with console-conf?
[13:09] <pedronis> mborzecki: yes, if the standup doesn't take too long
[13:10] <mborzecki> ack
[13:18] <ijohnson> morning folks
[13:19] <cmatsuoka> hey ijohnson
[13:20] <ijohnson> hey cmatsuoka how was your weekend ?
[13:20] <cmatsuoka> confined, and yours?
[13:21] <ijohnson> haha yep same, but we did a lot of cleaning so that's nice
[13:33] <cwayne> cmatsuoka: thats a whole new level of eating your own dogfood man
[13:34] <cmatsuoka> cwayne: haha indeed
[13:55] <pedronis> ijohnson: I answerd to you comments in 8314, we cannot write a snap-failure that assumes only new snapds
[15:10] <ogra> jdstrand, if i added "/dev/usb/lp[0-9]* rwk," to the raw-usb interface to allow a customer to use a receipt printer (writing  to the device directly, no cups or so) ... would you object that ? (raw-usb seems like the correct place, if thats wrong we'll likely need a "raw-usbprinter" interface or so)
[15:12] <jdstrand> ogra: sure, for the same reason as we allow "# Allow access to all ttyUSB devices too"
[15:12] <ogra> yeahm that was my rationale to pick that place :) create
[15:12] <ogra> s/create/great/
[15:13]  * ogra glares at his fingers
[15:34] <ijohnson> mvo: #8287 is the PR for 2.44 of my initial snap-failure changes that pedronis's changes are based on top of FYI
[15:34] <mup> PR #8287: tests, many: don't use StartLimitInterval anymore, unify snapd-failover variants, build snapd snap for UC16 tests (2.44) <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8287>
[15:41] <mvo> ijohnson: thanks, checking it now
[15:43] <cachio> mvo, hey
[15:43] <cachio> I am creating the cloud config in this place currently system-data/var/lib/cloud/seed/nocloud-net/
[15:43] <cachio> for uc20
[15:44] <cachio> mvo, this right? ubuntu-seed/data/etc/cloud/cloud.cfg.
[15:44] <cachio> d
[15:44] <pedronis> cachio: it depends what kind of data are you creating
[15:45] <pedronis> is it user-data?
[15:45] <cachio> user-data and meta-data
[15:45] <pedronis> yea, your place is correct
[15:45] <pedronis> and we need more code
[15:45] <pedronis> (I mean correct about to /data)
[15:45] <pedronis> mvo: ^
[15:46] <pedronis> what we discussed last week actually
[15:47] <cachio> pedronis, i tried to merge #8299 but still out of sync
[15:47] <mup> PR #8299: devicestate,sysconfig: support "cloud.cfg.d" in uc20 for grade: dangerous <Squash-merge> <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8299>
[15:47] <cachio> I did re-login
[15:47] <cachio> but didnt work
[15:47] <cachio> on github and travis as well
[15:47] <cachio> pedronis, any other idea?
[15:48] <mvo> pedronis, cachio indeed, the current PR only supports cloud.cfg.d - I can extend the code for user-data and meta-dat
[15:49]  * mvo added a todo for himsef
[15:49] <pedronis> mvo: we need to extend for seed/* at least for dangerous, for non-dangerous we need to be a bit more careful
[15:49] <cachio> mvo, if it is in a following pr should be nice
[15:52] <ngaio> Hello everyone, where do the MOTU team chat? IRC? The MOTU information on the Ubuntu wiki is many years out of date (seriously!)
[15:52] <mvo> pedronis: yeah
[15:52] <mvo> cachio: yeah, put on my todo
[15:52] <cachio> thanks
[15:53] <ngaio> I'm asking because I have a request about a specific package in Universe that is packaged in Debian
[15:53] <ngaio> (not because I'm looking to update the Ubuntu Wiki ;-) )
[15:54] <mup> PR snapd#8314 closed: cmd/snap-failure,tests: try to make snap-failure more robust <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8314>
[15:56] <mup> PR snapd#8287 closed: tests, many: don't use StartLimitInterval anymore, unify snapd-failover variants, build snapd snap for UC16 tests (2.44) <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8287>
[15:57] <zyga> hmm
[15:57] <zyga> test failure in 2.44.1+ git build
[15:57] <zyga> ... error string = "Get http://42/v1/session-info: context deadline exceeded"
[15:57] <zyga> ... regex string = "Get \\\"?http://1000/v1/session-info\\\"?: context deadline exceeded"
[15:57] <zyga> mvo: ^ perhaps this is what was blocking edge builds?
[15:57] <zyga> FAIL: client_test.go:101: clientSuite.TestAgentTimeout
[15:58] <zyga> there's also a c.Check(err, IsNil) that should be c.Assert
[15:58] <zyga> and a panic after that
[15:58] <zyga> PANIC: client_test.go:287: clientSuite.TestSnapdClientIntegration
[15:58] <zyga> I can send a patch that quickly
[15:59] <mup> PR snapd#8321 opened:  cmd/snap-failure,tests: try to make snap-failure more robust (2.44) <Created by mvo5> <https://github.com/snapcore/snapd/pull/8321>
[16:01] <mup> PR snapd#8322 opened: client: use Assert when checking for error <Simple 😃> <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8322>
[16:01] <zyga> https://github.com/snapcore/snapd/pull/8322
[16:01] <mup> PR #8322: client: use Assert when checking for error <Simple 😃> <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8322>
[16:11] <ackk> zyga, is it possible to make "snap run --strace" work in a container?
[16:11] <ackk> it doesn't seem it is by default
[16:11] <zyga> ackk: IIRC no without lxd changes
[16:12] <ackk> zyga, ok, thanks
[16:19] <mup> PR snapd#8299 closed: devicestate,sysconfig: support "cloud.cfg.d" in uc20 for grade: dangerous <Squash-merge> <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8299>
[16:40] <mup> PR snapd#8323 opened: many: improve comments, naming, a possible TODO <Created by pedronis> <https://github.com/snapcore/snapd/pull/8323>
[16:41] <pedronis> ijohnson: ^ tries to apply your feedback and turns a point of it into a TODO
[16:42] <ijohnson> thanks pedronis just approved it
[16:47] <ijohnson> hmm pedronis (hopefully quick) question about refactoring the logic from snap-bootstrap to boot pkg, should snap-bootstrap/cmd_initramfs_mounts.go pass in the bootloader and modeenv to a function in boot, or should the function in boot get that stuff itself ?
[16:50] <pedronis> ijohnson: this is for run mode right?
[16:52] <ijohnson> pedronis: yes
[16:52] <ijohnson> the logic to pick the base snap and kernel snap to mount and also for the base to update the modeenv
[16:53] <pstolowski> pedronis: can you clarify on #8309 (just replied)?
[16:53] <mup> PR #8309: o/configcore: implement Apply method for early configuration of core <Created by stolowski> <https://github.com/snapcore/snapd/pull/8309>
[16:53] <ijohnson> I'll save the bikeshedding about function names for the PR itself, but while coding it just occurred to me  maybe it would be easier/make more sense if the book package picked that stuff up itself instead of getting that state passed to it from snap-boostap's code
[16:54] <pedronis> ijohnson: yes, I don't think that passing in the bootloader is useful,  it's more like MakeBootable really
[16:54] <pedronis> ijohnson: but what's the input and the output?
[16:55] <pedronis> ijohnson: if we look at how install works,  the input would be []snap.Type and the output paths?
[16:55] <ijohnson> well the input for now was just which snap (base or kernel) and the bootloader and the modeenv, the output is what snap to mount as a string and an error
[16:56] <ijohnson> oh hmm
[16:56] <pedronis> I mean, there's more to the input than []snap.Type,  definitely the bootloader is not needed
[16:56] <ijohnson> right sure ignore that
[16:56] <ijohnson> then I have this (ignore the name)
[16:57] <ijohnson> `func InitramfsSnapToMount(snapT snap.Type) (snapFilename string, err error) {`
[16:58] <pedronis> that seems ok fine, it might or might not need to take the model? maybe not? there' the wrinkle that we need to mutate modeenv
[16:58] <pedronis> sometimes
[16:59] <ijohnson> right so the other thing I was doing here just for simplicity is that this function would mutate the modeenv and write that out, so in generateMountsModeRun, we wouldn't have that step "4.1 Write the modeenv out again"
[16:59] <ijohnson> but I suppose I could return the modeenv and keep that step 4.1
[16:59] <ijohnson> also where would we get the model from during snap-bootstrap ?
[17:00]  * ijohnson looks
[17:02] <pedronis> pstolowski: answered
[17:02] <pstolowski> ty
[17:03] <pedronis> ijohnson: do we need the model?
[17:03] <ijohnson> pedronis: not right now AFAICT ?
[17:03] <pedronis> ok, so ignore me
[17:03] <pedronis> pstolowski: let me know if my comment is still confusing
[17:03] <ijohnson> okay, but do you have thoughts on step 4.1 in snap-bootstrap ?
[17:04] <ijohnson> pedronis: i.e. should we still write the modeenv at the very end, or could we write it sooner?
[17:04] <pedronis> ijohnson: I think we could write it sooner afaiu,  the issue then is more that function name doesn't scream I'm mutating stuff
[17:05] <ijohnson> yeah let's figure out a good name in the PR review :-)
[17:05] <ijohnson> I should have it open this afternoon, need to break now for lunch though
[17:05] <pedronis> ijohnson: I might not get to look at it today though, trying to have a short day for a change :)
[17:05] <ijohnson> pedronis: that's perfectly fine I understand :-)
[17:10] <pstolowski> pedronis: looks good,ty
[17:12] <mup> PR snapd#8324 opened: github: cache go build cache and pkg dirs <Created by zyga> <https://github.com/snapcore/snapd/pull/8324>
[17:20] <pedronis> pstolowski: I made a list of the follow ups if I see things correctly
[17:23] <pstolowski> pedronis: great, thanks. none of that is sophisticated, mostly a matter of diff size for the review / avoiding loosely related changes in this PR
[17:24] <pedronis> pstolowski: yea, no proble, small PRs that can go in quickly are good
[17:27] <pstolowski> eod, o/
[17:33]  * zyga eds
[17:41] <pedronis> mvo: this didn't even trigger travis in any way: https://github.com/snapcore/snapd/pull/8321 seems something really confused there
[17:41] <mup> PR #8321:  cmd/snap-failure,tests: try to make snap-failure more robust (2.44) <Created by mvo5> <https://github.com/snapcore/snapd/pull/8321>
[18:18] <mvo> if someone could eyeball/approve 8321 that would be nice, maybe the approval is what's missing from triggering a travis run?
[18:29] <ijohnson|lunch> mvo I approved it
[18:29] <ijohnson|lunch> still no travis though :-/
[18:33] <mvo> ijohnson|lunch: meh, silly travis
[18:33] <ijohnson|lunch> mvo: what I've done before is to close and re-open the PR
[18:34] <mvo> ijohnson|lunch: thanks, let me try this
[18:34] <mvo> that helped
[18:34] <mvo> thanks pedronis
[18:34] <pedronis> I tried it, but didn't help
[18:34] <pedronis> afaict
[18:34] <pedronis> actually it did
[18:35] <pedronis> it took a little bit
[18:35] <ijohnson|lunch> I reapproved anyways just to make sure it didn't be weird
[18:41] <pedronis> so travis and github got desynced again
[18:42] <pedronis> for me
[18:43] <pedronis> :/
[18:54] <cachio> mvo, I am creating cloug condiguration like this https://paste.ubuntu.com/p/Mz3PHrtZJ6/
[18:54] <cachio> is it ok?
[18:55] <zyga> Travis has a very bad day
[18:55] <cachio> mvo, then I copy that file to /ubuntu-seed/data/etc/cloud/cloud.cfg.d/
[18:55] <cachio> on the image
[19:07] <sergiusens> zyga: Travis had a very bad weekend!
[19:11] <mvo> cachio: yeah, that should work
[19:11] <mvo> cachio: good luck, keep me updated
[19:12] <cachio> mvo, and which is hte path in uc18 and uc16?
[19:12] <cachio> the same should work as well?
[19:12] <mup> PR snapd#8316 closed: github: add prototype workflow running unit tests <Skip spread> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/8316>
[19:13] <mup> PR snapd#8316 opened: github: add prototype workflow running unit tests <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8316>
[19:17] <pedronis> cachio: mvo: in the image you don't want the ubuntu-seed bit (that's the partition mount point)
[19:18] <cachio> pedronis, currently I mount the partition and then copy to /ubuntu-seed/data/etc/cloud/cloud.cfg.d/
[19:18] <cachio> in uc20
[19:19] <cachio> there are 2 partitions and the second one contains /ubuntu-seed
[19:20] <cachio> pedronis, is that ok?
[19:26] <ijohnson|lunch> cachio: yes the put the data/etc/... files in the ubuntu-seed partition
[19:27] <cachio> ijohnson, thanks
[19:27] <ijohnson> cachio: if you are mounting ubuntu-seed at /ubuntu-seed then that directoriy you have is correct
[19:28] <cachio> ijohnson, ye
[19:28] <cachio> s
[19:28] <cachio> I am running now, reults will be ready in few minutes
[19:47] <ijohnson> great cachio
[20:24] <mup> PR snapd#8325 opened: snap-bootstrap: copy auth data from real ubuntu-data in recovery mode <Created by mvo5> <https://github.com/snapcore/snapd/pull/8325>
[20:38] <mup> Bug #1868620 opened: Snaps based on Wine fail with nvidia driver 440  <Snappy:New> <https://launchpad.net/bugs/1868620>
[20:41] <cmatsuoka> zyga: do you have plans to work on LP:1868450? should I assign it back to you?
[20:57] <cmatsuoka> ijohnson: do you know who worked with timers more recently?
[21:20] <ijohnson> cmatsuoka: I think mborzecki or pstolowski
[21:21] <cmatsuoka> ijohnson: thanks, I'll check with them
[21:40] <pedronis> cachio: hi, the issues here seems real, one missing/changed package?, issue with the urls we get from the store, the store is changing how they handle downloads so something might have changed there, please talk to them: https://api.travis-ci.org/v3/job/665954535/log.txt


[00:55] <kyrofa> elopio, alright thanks :)
[03:46] <liuxg> how is "organize" in snapcraft.yaml is used? thanks
[08:14] <liuxg> dholbach, ping
[08:15] <dholbach> liuxg: pong
[08:16] <liuxg> dholbach, do you know what the following sentence means in the snapcraft.yaml?  http://paste.ubuntu.com/13886619/ the organize part
[08:18] <dholbach> liuxg: no, I'm afraid not - best to ask sergiusens or kyrofa when they are back online
[08:19] <liuxg> dholbach, ok. I will do that. the explanation in the document is very weak. https://docs.google.com/document/d/1Rj9nVBttx62BvGlbnkmKOzAlAIEWuLNr1QaSGe3gQDA/edit#heading=h.bx30erj03sx1
[08:19] <dholbach> ah ok, look at this:
[08:19] <dholbach>    * `organize` (yaml subsection)
[08:19] <dholbach>      A dictionary exposing replacements, the key is the internal name whilst
[08:19] <dholbach>      the value the exposed name, filesets will refer to the exposed named
[08:19] <dholbach>      applied after organization is applied.
[08:19] <dholbach> ah, yes - that's the same
[08:19] <liuxg> dholbach, what does it exactly mean in the context?
[08:19] <dholbach> I don't know - I didn't write it
[08:19] <dholbach> I would need to read the code to understand
[08:20] <dholbach> are files renamed with the patterns mentioned there?
[08:20] <liuxg> dholbach, I am going to have a snapcraft training for some of the people in one week. I am trying to understand more about it.
[08:21] <dholbach> I see
[08:21] <liuxg> dholbach, it sounds like that the files inside opt/bin will be put into the bin directory?
[08:22] <dholbach> I don't know
[08:22] <dholbach> have you tried it?
[08:22] <liuxg> dholbach, I have tried the code snippet there, and it does not work at all. http://paste.ubuntu.com/13886619/, it seems there is some error for it.
[08:23] <dholbach> if it errors out, that's a bug :/
[08:23] <dholbach> or the example needs to be updated
[08:23] <liuxg> dholbach, the line does not work at all    - *.h
[08:24] <dholbach> can you file a bug about it?
[08:24] <liuxg> dholbach, i will, the "type" null means a null plugin, right?
[08:24] <dholbach> yes
[08:24] <liuxg> dholbach, there are a few bugs with the code there.
[08:24] <dholbach> yes, it needs to be updated
[08:25] <liuxg> dholbach, so, it is against snapcraft?
[08:25] <dholbach> maybe the example needs to be updated and then it works?
[08:25] <dholbach> there were some changes in the early versions of snapcraft, like type → plugin
[08:26] <liuxg> dholbach, that seems the only document we can refer to. we need a complete tutorial on snapcraft. will anyone push for that?
[08:26] <dholbach> liuxg: the document needs to be updated if the example doesn't work
[08:27] <dholbach> ricmm: ^
[08:27] <dholbach> in general I think it does a good job though
[08:29] <liuxg> dholbach, this is the project https://github.com/liu-xiao-guo/null
[08:30] <liuxg> dholbach, would you please have a try in your place?
[08:30] <dholbach> I can't
[08:30] <dholbach> I have to go to the dentist now
[08:30] <liuxg> dholbach, ok. if you are free, you can do it at your convenience later on.
[08:30] <dholbach> but there are a lot of other folks in here, maybe somebody else can help
[10:03] <JamesTait> Good morning all; happy Thursday, and happy Nobel Prize Day! 😃
[10:45] <liuxg> zyga, ping
[10:59] <zyga> liuxg: hey
[11:00] <liuxg> zyga, last time, you told me to try the requirements.txt, I have tried it, and there is a problem for it. I have reported a bug for it at https://bugs.launchpad.net/snapcraft/+bug/1523384
[11:01] <zyga> liuxg: thanks for reporting the bug
[11:02] <liuxg> zyga, it is ok. by the way, today, I tried another project at https://github.com/liu-xiao-guo/null, I also failed. I did it according to the document "Snappy Ubuntu Core - Application Developer Manual 15.04". I do not where I was wrong for it.
[11:04] <liuxg> zyga, I also reported a but for it at https://bugs.launchpad.net/snapcraft/+bug/1524663.
[12:48] <dholbach> liuxg: I sent a pull request for your example -it should work now
[12:48] <dholbach> but still I feel it's a valid bug because the error messages of snapcraft didn't actually reveal any of the issues
[12:48] <dholbach> maybe you could change the bug description to that
[12:48] <liuxg> dholbach, do you mean the null example?
[12:48] <dholbach> yes
[12:48] <dholbach> https://github.com/liu-xiao-guo/null/pull/1
[12:49] <liuxg> dholbach,  did you do any change?
[12:49] <dholbach> see the pull request
[12:49] <dholbach> there were a number of issues with the example (I updated the doc already)
[12:50] <liuxg> dholbach, OK. many thanks, I think document should be updated :). yes, we need to make the example working. the document is accessed by many people.
[12:50] <dholbach> liuxg: I already updated the doc
[12:51] <liuxg> dholbach, that is cool! by the way, have you figured out "organize" ?
[12:51] <dholbach> yes, it's basically a rename
[12:52] <dholbach> just check the contents of the snap in your example and the files in the parts/ directories
[12:52] <liuxg> dholbach, do you mean rename the "opt/bin" to "bin"?
[12:52] <dholbach> yep
[12:53] <dholbach> or in the working example   usr/bin  →  bin/
[12:54] <liuxg> dholbach, in my example, it is  opt/bin: bin, so, we change it to "usr/bin to  "bin"?
[12:55] <dholbach> https://github.com/liu-xiao-guo/null/pull/1/files
[12:55] <dholbach> check the diff
[12:55] <dholbach> that's what makes the example actually work
[12:56] <liuxg> dholbach, yes, I see it. thanks a lot.
[12:56] <dholbach> ok, cool :)
[13:00] <liuxg> dholbach, you are marvelous!
[13:00] <dholbach> thanks a lot - this was a useful exercise for me as well :-)
[13:03] <liuxg> dholbach, so all of the files in the /usr/bin are gone. the final snap is like http://paste.ubuntu.com/13893283/. the gnupg files are not there.
[13:03] <dholbach> hum, that's weird - try:   snapcraft all --force
[13:04] <dholbach> for me it looks like this: http://paste.ubuntu.com/13893318/
[13:05] <liuxg> dholbach, I have merged your changes already, now the project is like https://github.com/liu-xiao-guo/null/blob/master/snapcraft.yaml. I pulled everything there
[13:07] <dholbach> I'm using xenial, but I'm not sure if that makes a difference
[13:08] <liuxg> dholbach, I just used your command "  snapcraft all --force", it seems to be right. I am now doing it again with a normal "snapcraft"
[13:09] <dholbach> ok
[13:09] <dholbach> "all --force" will go through all phases of snapcraft again and through away old results
[13:09] <dholbach> that's useful if previous runs downloaded something else or moved files around or whatever
[13:09] <dholbach> Sergio said that in version 2.0 snapcraft is going to be cleverer
[13:10] <dholbach> but until then we will have to bear that trick in mind
[13:12] <kyrofa> dholbach, an even more handy trick is to alter your part's `state` file and set its contents to "pull," then run snapcraft again
[13:12] <kyrofa> That way it will rebuild the part without repulling .debs etc.
[13:13] <kyrofa> I find that to be the longest part, depending on the project of course
[13:15] <liuxg> dholbach, If I simply use "snapcraft", the result is the same as what I showed you. However, if i use "--force" option is the like yours. I am still confused. Do I need to use "--force" option all the time?
[13:16] <dholbach> no
[13:16] <dholbach> you shouldn't have to
[13:16] <dholbach> I need to run again... see you later
[13:17] <liuxg> dholbach, ok. thanks. I will let you know the result. it is a little strange to me anyway
[13:17] <kyrofa> liuxg, the snapcraft behavior is very unintuitive right now regarding how the steps are run after they've already been run once. --force is backwards, and it's all very confusing
[13:17] <dholbach> kyrofa can probably help
[13:18] <kyrofa> liuxg, we're working on changing that right now :)
[13:18] <kyrofa> liuxg, so rest assured, we feel your pain
[13:19] <liuxg> kyrofa, thanks for your explanation. so in the future, we will just use snapcraft, right?
[13:19] <elopio> kyrofa: today I need to take my motorcycle to the mechanic. I might be late for the stand up, because buses are unpredictable.
[13:20] <elopio> I'll ping you when I'm back.
[13:20] <kyrofa> elopio, no problem, thanks for the heads up :)
[13:21] <kyrofa> liuxg, first of all, before I try to explain anything you're gonna have to take what I say with a grain of salt-- I only started on snapcraft recently :)
[13:21] <liuxg> kyrofa, alright, thanks
[13:22] <kyrofa> However, my understanding is that the snapcraft steps (pull, build, stage, snap, assemble) will remain the same
[13:23] <kyrofa> liuxg, I believe running `snapcraft` will continue to run through all steps, but it won't re-run any steps it has already run unless you force it
[13:24] <kyrofa> liuxg, similarly, say I run `snapcraft` once and it makes a .snap. If I run `snapcraft pull` again, it won't re-pull because it knows it's already done that. So I'd have to run `snapcraft pull --force`
[13:24] <kyrofa> sergiusens will know all the details here, so hopefully I'm not leading you astray with where things are going
[13:24] <liuxg> kyrofa, I got you. If I run a "snapcraft clean" first, after that, I run "snapcraft", will it run through all of the steps?
[13:26] <kyrofa> liuxg, that sounds about right
[13:27] <liuxg> kyrofa, in my places, it a little bit not so right. I have my test project at https://github.com/liu-xiao-guo/null. it seems to give me different results when i run it.
[13:29] <kyrofa> liuxg, you mean `snapcraft clean` followed by `snapcraft`?
[13:29] <liuxg> kyrofa, yes, that is what I did here. I did not see all of the directories before I did another "snapcraft"
[13:30] <kyrofa> liuxg, give me a minute, let me pull the project
[13:33] <kyrofa> liuxg, I get this after a `snapcraft` run. Same as you? http://pastebin.ubuntu.com/13894019/
[13:33] <liuxg> kyrofa, what is the content inside the snap?
[13:34] <kyrofa> liuxg, bin/{wget,gpg-zip,gpgsplit,gpg}
[13:35] <liuxg> kyrofa, in my case, http://paste.ubuntu.com/13893962/
[13:36] <kyrofa> liuxg, alright let me try a clean and another snapcraft
[13:36] <liuxg> kyrofa, this is another try with "--force" option http://paste.ubuntu.com/13894098/
[13:37] <kyrofa> liuxg, interesting, you're right-- after I've cleaned and run again, I have the same as you
[13:37] <kyrofa> liuxg, let me look into this
[13:37] <kyrofa> liuxg, hang around, I'll ping you when I learn something
[13:37] <liuxg> kyrofa, it is a very confusing to me. running different command gets different results :)
[13:38] <kyrofa> liuxg, agreed
[13:38] <kyrofa> liuxg, confusing to me too :)
[13:38] <liuxg> kyrofa, sounds like a bug somewhere :) next time, I have to use to methods to try them. Still maybe I do not know which one is right.
[13:43] <liuxg> kyrofa, daniel seems to have a different result than us http://paste.ubuntu.com/13893318/
[13:46] <kyrofa> liuxg, haha, no kidding. I didn't have the lspgpot in there
[13:46] <kyrofa> liuxg, I suspect something is weird in the filtering
[13:47] <liuxg> kyrofa, I do not have it too :)
[13:49] <liuxg> kyrofa, I am using daniel's repository, which is the same as mine. I got different results for the two builds http://paste.ubuntu.com/13894397/
[13:56] <liuxg> kyrofa, I have created a bug report for it at https://bugs.launchpad.net/snapcraft/+bug/1524846. if you have any updates about it, could you please update it there? thanks a lot for your helping!
[13:57] <kyrofa> liuxg, no problem :)
[14:42] <kyrofa> sergiusens, I ran into a terrible problem yesterday
[14:43] <kyrofa> sergiusens, if the `source` option for a plugin is ".", it causes ./parts/foo/src to be symlinked to ., which results in a circular link. Which makes any automatic src parsing useless
[14:46] <kyrofa> elopio, ^^ too
[14:46] <tasdomas> hi
[14:46] <tasdomas> how do I disable the automatic snappy update installation
[15:00] <ogra_> tasdomas, the easiest is probably:
[15:00] <ogra_> snappy config ubuntu-core >core-config.yaml
[15:00] <ogra_> then edit the value of autoupdate from true to false ...
[15:00] <ogra_> and run:
[15:00] <ogra_> sudo snappy config ubuntu-core core-config.yaml
[15:00] <ogra_> that will set the new value
[15:06] <tasdomas> ogra_, thanks
[15:45] <elopio> kyrofa: that happened to me, but when the yaml was not in the root.
[15:45] <elopio> in theory we have a condition check that prevents the parts dir to be copied.
[15:45] <kyrofa> elopio, but it's a symlink, not a copy
[15:46] <kyrofa> elopio, note that I'm talking about the sourcedir, not the builddir
[15:46] <elopio> kyrofa: right, the condition is on build, where we copy.
[15:46] <kyrofa> elopio, and that makes sense
[15:46] <kyrofa> elopio, so perhaps this is only really a problem where we need to interrogate the sourcedir in order to complete the pull()
[15:46] <kyrofa> elopio, e.g. the catkin plugin
[15:47] <kyrofa> elopio, so I'm simply making the source and source-subdir checks a bit stricter for that plugin
[15:47] <kyrofa> elopio, but definitely a dangerous thing to keep in mind, at least
[15:47] <elopio> I couldn't add the condition to pull, because of the symlink. So maybe it would be good to copy in pull too.
[15:47] <kyrofa> elopio, took me forever to figure out why it was taking so darn long to run
[15:47] <rOger___> Hi all
[15:47] <kyrofa> elopio, interesting idea, but a bit heavy depending on the project
[15:47] <elopio> kyrofa: right, same here. Until it failed because it was copying a path too long.
[15:47] <kyrofa> elopio, that may be the best/cleanest solution
[15:47] <elopio> rOger___: Hello!
[15:47] <rOger___> I'm checking ubuntu snappy as a base system for embedded appliances
[15:48] <rOger___> for our requirements we should be able to replace several parts of the boot scripts with a different init "system"
[15:48] <rOger___> is there an official way to accomplish this?
[15:49] <ogra_> why do you need to replace the init system ?
[15:49] <elopio> rOger___: not yet. But the devs are working on splitting the image into snaps. And one of the things they are discussing is where is the bootloader defined, and how to replace it.
[15:50] <rOger___> We want to use our python based init scripts where we have more influence on some parts of the system config (like networking)
[15:50] <ogra_> well, thats not really how snappy works
[15:50] <morphis_> sergiusens, ricmm: does the snappy store group snaps per core image version?
[15:50] <morphis_> or do I publish a snap for everything?
[15:52] <ogra_> you have a very locked down core (readonly etc) ... that does the system boot ... and ten you have snaps ... a snap can ship services and binaries ... so you can have your application in a snap nad have the service started on boot ...
[15:53] <rOger___> @ogra_: so if you call a "firewall" an application; It will be called too late in the boot process; the network interfaces will be setup before the application will be started so during a short time I have a router instead of a firewall
[15:53] <nothal> rOger___: No such command!
[15:54] <rOger___> \ogra_: so if you call a "firewall" an application; It will be called too late in the boot process; the network interfaces will be setup before the application will be started so during a short time I have a router instead of a firewall
[15:55] <ogra_> things like networking are part of the core component though
[15:55] <ogra_> snappy offers an interface to configure it etc but you wouldnt easily be able to replace parts in the core
[15:55] <ogra_> (your snap could also ship its own network handling and tell snappy to turn off its own handling though ... )
[15:58] <ogra_> no, as i said, you can tell snappy to not take over networking
[15:58] <morphis_> ogra_: you know that?
[15:58] <ogra_> morphis_, well, in 16.04 you will be :)
[15:58] <ogra_> not sure Chipaca landed that yet but i know it was discussed :)
[15:59] <ogra_> rOger___, jdstrand recently created a ufw snap ... though that integrates with the existing core
[16:00] <morphis_> ogra_: so what is the current store targetting?
[16:00] <rOger___> ogra_: that sounds interesting; i will check it out
[16:00] <ogra_> morphis_, depends ... you can pick when you upload ... most packages should target stable
[16:01] <ogra_> but you can pick "edge" as well
[16:01] <ogra_> (which would target the rolling release by default)
[16:03] <morphis_> ogra_: ah
[16:03] <morphis_> ogra_: stable is 15.10?
[16:03] <morphis_> ogra_: and that changes with 16.04?
[16:04] <ogra_> not sure how it will chane then .... stable is 15.04
[16:04] <ogra_> *change
[16:04] <morphis_> ok
[16:05] <morphis_> ogra_: so I can publish two versions?
[16:05] <morphis_> on for edge and stable?
[16:05] <ogra_> you should be able to ... havent tried it myself
[16:09] <morphis_> ogra_: thanks!
[16:09] <ogra_> np ... ask beuno for more details :)
[16:25] <kyrofa> elopio, ah! I finally understand this stupid mock library
[16:51] <beuno> mwenning, yes you can
[16:51] <beuno> er
[16:52] <beuno> morphis_, ^
[16:52] <morphis_> beuno: great
[19:45] <sergiusens> tyhicks, is there a security reason for this https://bugs.launchpad.net/snappy/+bug/1523372 ?
[19:50] <sergiusens> kyrofa, hey, do you have a sec?
[19:50] <kyrofa> sergiusens, for you, always
[19:50] <sergiusens> kyrofa, hah, let me give you a hangout link :-)
[19:52] <tyhicks> kyrofa: check the privmsg from me
[23:04] <wililupy> Hello, I'm trying to build a snap of LISPmob, but it requires some system changes to snappy, like a configuration file in /etc and some changes to the /etc/sysctl file. How do I go about this in my snapcraft.yaml file?


 "Criteria: open source, kanban-..." <- Do terminal apps count as looking like something made after 2010?
[05:28] <arraybolt3[m]> (I can't think of a single program that does what you're mentioning, but I'm thinking making something from scratch wouldn't be too hard. Maybe have Git as the backend. I stink at GUI design though, so I'd write it in Bash and make it a terminal app.)
[05:29] <arraybolt3[m]> Git would allow ACLs to be a cinch (each "access level" would be a repo, grant contributor privileges to a repo and you've granted access). Open-source, if it's made by us that's a no-brainer, and kanban-like is just a matter of design.
[05:32] <arraybolt3[m]> The only real problem I can see with this is it won't work quite the same as CodiMD, where the note taking is real-time and collaborative.
[05:38] <arraybolt3[m]> There's also this thing I found with some Google searching: https://wekan.github.io/ No clue about ACLs, but it fits the other requirements I believe.
[14:40] <RikMills> arraybolt3[m]: interesting qt based broken package in jammy: https://lists.ubuntu.com/archives/ubuntu-motu/2022-October/008322.html
[14:41] <RikMills> could be a good practice SRU if you can find all the python fixes to make 3.1.3 work with python 3.10
[17:41] <arraybolt3[m]> RikMills: Thanks, will look!
[20:33] <RikMills> https://bugs.launchpad.net/ubuntu/+source/distro-info-data/+bug/1993667
[20:33] -ubot93:#lubuntu-devel- Launchpad bug 1993667 in distro-info-data (Ubuntu Kinetic) "Update distro-info-data for L series" [High, Triaged]
[20:33] <RikMills> some dev tools are broken by that :/


[05:49] <FAalbers2> Hello, How do I receive packages from Wily instead of Trusty ? I need newer version of openocd and Trusty is set to 0.7.0 instead of the latest 0.9.0
[05:55] <rect> Hi all, I am interested in working on the ubuntu-multi-computer experience
[05:56] <rect> It's 2015 and there is still unnecessary general friction when using more than one machine, in terms of synchronizing data and configuration
[05:58] <rect> Right now my thought about how to do this is around establishing separation of "data" and "system/configuration",  and using declarative system configuration languages to compile provision systems
[05:58] <FAalbers2> Hello, How do I receive packages from Wily instead of Trusty ? I need newer version of openocd and Trusty is set to 0.7.0 instead of the latest 0.9.0
[06:00] <rect> I have a little writeup demonstrating a proof of concept of the first aspect here, which is the separation/divorce of the "storage" of data and the "application" of data
[06:00] <rect> I would really appreciate some feedback on the concept!
[06:00] <rect> http://nbviewer.ipython.org/github/andrewjchen/andrewathome/blob/master/andrew%40home.ipynb
[06:45] <dholbach> good morning
[08:41] <Laney> siretart: I'm going to do it so we can get some stuff migrated
[08:41] <Laney> Guess we should transition off libav completely though?
[09:04] <ricotz> Laney, yes, libav needs to go away
[09:04] <Laney> ricotz: did Debian do it yet?
[09:04] <Laney> is it API compatible?
[09:05] <ricotz> Laney, https://release.debian.org/transitions/html/ffmpeg-libav.html
[09:05] <ricotz> and it is compatible in most cases
[09:06] <Laney> maybe someone could take the lead. ;)
[09:17] <flexiondotorg> Laney, dholbach May I request a little bit of sponsoring please?
[09:17] <flexiondotorg> I'd like the ubuntu-mate meta packages tasks updating please.
[09:17] <flexiondotorg> Laney, dholbach And the following two package updates:
[09:17] <flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-settings/+bug/1476616
[09:18] <flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-artwork/+bug/1476611
[09:18] <dholbach> flexiondotorg, sorry, I'm a bit busy right now
[09:18] <flexiondotorg> dholbach, OK.
[09:19] <Laney> flexiondotorg: Sponsoring this afternoon
[09:20] <flexiondotorg> Laney, Cheers.
[11:39] <Laney> infinity: http://paste.ubuntu.com/11947918/
[13:23] <Laney> @pilot in
[13:25] <Laney> hmm
[13:25] <Laney> dholbach: know where the bot is? :)
[13:26] <dholbach> Laney, hum
[13:27] <dholbach> pinged folks in #ubuntu-irc
[13:28] <Laney> cheers
[13:28] <Laney> I thought it was IS for some reason
[13:35] <dholbach> Laney, better now?
[13:36] <Laney> @pilot in
[13:36] <Laney> dholbach: feels good!
[13:36]  * Laney does some warm up stretches
[13:36] <dholbach> yeeehaw :)
[15:11] <doko> tumbleweed, https://launchpadlibrarian.net/212703834/buildlog_ubuntu-wily-amd64.pyzmq_14.4.1-0ubuntu4_BUILDING.txt.gz
[15:11] <doko> however I don't see any b-d for greenlet and cffi
[15:14] <doko> jtaylor, ^^^
[15:18] <doko> tumbleweed, did you file bug reports for the cffi backend split?
[15:23] <bb11> hi! anyone can tell me which tool is used to build alternate installer / ubuntu-server images? apparently it's not debian-cd as this package is in universe and lacks ubuntu-specific settings
[15:25] <tumbleweed> doko: not yet.
[15:29] <infinity> bb11: It is a very old forked version of debian-cd
[15:30] <infinity> bb11: https://code.launchpad.net/~ubuntu-cdimage/
[15:30] <tumbleweed> doko: partly because I'm not ready for them yet. I just want them to start using pre-compiled 1.x style bindings
[15:31] <doko> tumbleweed, sure, but you get build failures when the extension is missing for -dbg packages
[15:33] <roaksoax> infinity: howdy! how can I check what bugs are yet to be verified for an SRU to go through?
[15:33] <bb11> infinity: excellent, just what I needed :)
[15:33] <bb11> thank you
[15:34] <infinity> roaksoax: http://people.canonical.com/~ubuntu-archive/pending-sru.html
[15:34] <roaksoax> infinity: thanks!
[15:34] <flexiondotorg> infinity, May I ask a favour? Please could you update the ubuntu-mate seeds/tasks?
[15:35] <tumbleweed> doko: that's not what that bug is. That's a 3.5 porting bug I think
[15:36] <tumbleweed> doko: pyzmq previously used cffi only on pypy (which requires no build-deps)
[15:36] <tumbleweed> but it looks like it wants to use cffi on 3.5 too
[15:37] <doko> ahh
[15:37] <doko> anyway, have a fix
[15:37] <tumbleweed> I don't know *why* it wants to use cffi on 3.5, that would require looking at the source :)
[15:38] <infinity> flexiondotorg: Bit busy right now, but if you ask again in a few hours...
[15:42] <flexiondotorg> infinity, OK
[15:58] <flexiondotorg> Laney, Thanks for the sponsoring.
[16:28] <dholbach> hey seb128, do you know why ubuntu-desktop-next depends on grub-efi-amd64-signed?
[16:31] <seb128> dholbach, to be able to have signed boot
[16:31] <seb128> dholbach, is that an issue?
[16:32] <dholbach> seb128, I installed ubuntu-desktop-next this morning to play around with a unity8 session every now and then, it removed my grub-pc underneath me and broke boot with me just noticing it when I rebooted earlier
[16:33] <seb128> urg
[16:34] <seb128> dholbach, ubuntu-desktop-next is not supposed to be installed, it's the base for the snappy personal image
[16:34] <dholbach> people are going to install it if it's in the archive :)
[16:34] <seb128> you probably wanted unity8-desktop-session-mir
[16:34] <seb128> dholbach, you can use the same logic for grub-efi-amd64-signed
[16:34] <dholbach> unity8-desktop-session-mir installs less packages than ubuntu-desktop-next
[16:34] <seb128> it's in the archive
[16:34] <seb128> people are going to install it
[16:34] <dholbach> mh
[16:34] <ogra_> dholbach, size doesnt matter ... ask your GF !
[16:35] <dholbach> ogra_, you're such a troll
[16:35] <ogra_> lol
[16:35] <Laney> O_O
[16:35] <seb128> dholbach, anyway, unsure why grub-efi-amd64-signed is breaking boot
[16:35] <Laney> how is -efi installed for desktop?
[16:35] <dholbach> seb128, I'm not going to argue either way, I just didn't expect a *ubuntu*-desktop* package to lock me out of my laptop
[16:36] <seb128> dholbach, yeah, me neither, sorry about that :-/
[16:36] <dholbach> like... I could've installed kubuntu-desktop or lubuntu-desktop
[16:36] <Laney> I guess conditionally by ubiquity maybe?
[16:36] <dholbach> anyway... I just wanted to let you guys know
[16:36] <seb128> dholbach, those are not -next :p
[16:36] <seb128> dholbach, thanks, maybe worth opening a bug
[16:36] <seb128> I don't know grub much
[16:37]  * dholbach starts considering carreer outside IT
[16:37] <seb128> what is grub-efi-amd64-signed made for?
[16:39] <infinity> seb128: For secure boot systems.  Though, it should do no harm on any EFI system.
[16:39] <seb128> what about non efi systems?
[16:39] <infinity> For non-EFI, it's slightly less useful. :P
[16:39] <seb128> is what happened to dholbach expected?
[16:40] <infinity> Yes, it's why we don't ship grub-efi-amd64-signed (or bootloaders at all) in any desktop metapackage.
[16:40] <gQuigs> I think this should be a quick fix (I have a patch posted), and will save us livecd space - https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1452472
[16:40] <infinity> Bootloaders are mutually exclusive, so installing one that doesn't work tends to remove the one that does.
[16:40]  * gQuigs is also hoping to drop gstreamer0.10 to universe this cycle
[16:41] <seb128> "fun"
[16:41] <seb128> dholbach, sorry about that :-/
[16:41] <infinity> seb128: I'm guessing someone added it to desktop-next to mirror how we build livefses with *-live, but that should really be either hacked in livecd-rootfs, or part of a "desktop-next-live" instead.
[16:41] <seb128> infinity, you guess right
[16:42] <dholbach> seb128, I'm glad I found the issue and hopefully not somebody else :)
[16:42] <seb128> dholbach, I hope you manage to fix your machine
[16:42] <dholbach> yeah, took an hour because I had to download a live cd, etc, but that's fine
[16:42] <seb128> good
[16:44] <Laney> gQuigs: We generate that package by modifying lp:~ubuntu-core-dev/ubuntu-seeds/ubuntu.wily desktop, not by editing it directly
[16:46] <gQuigs> Laney: oh, I'll redo a patch/merge proposal on that
[16:47] <Laney> gQuigs: Cheers. Seems like a good idea to me - didn't notice that we got there with dropping everything off the CD.
[16:48] <Davidk> Hi there! My friend and I have decided to make our own remastered version of Ubuntu GNOME. However, we ran into some trouble and I was wondering if anyone could help. We unpacked the OS with squashfs, made our little modifications, then repacked it and burned the ISO onto a disk. However, when we try to start the OS, we get an error message
[16:48] <Davidk> "(initramfs) Unable to find a medium containing a live file system"
[16:53] <gQuigs> Laney: yup, it's just been pidgin for a while, posted a new patch to the bugf
[16:53] <Laney> gQuigs: Can you link a bzr branch instead? It'll have better metadata that way
[16:54] <gQuigs> Laney: propose branch for merging ?
[16:54] <Laney> nah
[16:55] <Laney> in general yes, but since I'm looking already, not necessary
[16:57] <infinity> gQuigs: Ahh, nice catch.  Thanks for that.
[16:57] <gQuigs> Laney: I think I did that right, https://code.launchpad.net/~bryanquigley/+junk/gst0.10_ubuntu
[17:00] <Laney> gQuigs: Ta
[17:01] <Laney> let's see what breaks...
[17:01] <Laney> @pilot out
[17:02]  * dholbach hugs Laney
[17:29] <Davidk> Can anyone that's on possibly help me with an issue I'm having while trying to boot from a disk?
[17:29] <Davidk> There were slight modifications made
[17:29] <Davidk> Unpacked and packed via squashfs
[17:31] <Davidk> It says that no live media can be found
[17:54] <cyphermox> Davidk: did you rename the file in any way?
[17:55] <cyphermox> Davidk: if you're booting from a hard disk you may also need to pass live-installer/net-image=/path/to/the/squashfs_file to tell the installer where to get the squashfs
[17:55] <cyphermox> see http://www.michaelm.info/blog/?p=1378
[18:04] <Davidk> cyphermox: no, no names were changed, as well as no paths
[18:05] <Davidk> And the error is "(initramfs) Unable to find a medium containing a live file system"
[18:07] <dragos> hello i just win an ubuntu competition
[18:09] <dragos> i just remaster an ubuntu but when i click on live it asks for an username and an password. oh and btw i used remastersys for it
[18:10] <cyphermox> Davidk: if you specify live-installer/net-image I bet it's going to work
[18:10] <Davidk> cyphermox: okay, I will give it a shot
[18:12] <dragos> help
[18:17] <cyphermox> dragos: Davidk: for support, you should go to #ubuntu
[18:18] <Davidk> cyphermox: Will do as well if your solution does not work. But thank you so much for your assistance
[18:18] <cyphermox> no worries
[18:18] <Davidk> And I did in Ubuntu GNOME, as this is GNOME
[18:19] <Davidk> But they didn't have a solution unfortunately :/
[18:19] <cyphermox> this is a typical issue on custom installs, the location of net-image needs to be specified if it's not on the cd
[18:21] <Davidk> Ahhh I see. I'll do it and recompile, tho that may take a while. It's my friends' and my first attempt at this so, all help is really and truly appreciated
[18:22] <cyphermox> you don't need to recompile anything for that
[18:22] <cyphermox> as you boot, you should be able to either use F6 to open up the ocmmand-line and add it there, or edit the grub menu entry
[18:22] <Davidk> Ooh that is perfect, thank you!
[18:23] <cyphermox> (well, for testing that it fixes your problem, anyway... to make it permanent you'll need to add it to preseed)
[18:23] <Davidk> Gotcha
[18:25] <dragos> some dude banned me from #ubuntu for no reasion
[18:50] <hjd> Hi, I've two questions; I'm curious why Ubuntu seem to use a different jpeg library than Debian (libjpeg8 vs libjpeg-turbo)? Secondly, even though it doesn't seem to be on the sync blacklist (http://people.canonical.com/~ubuntu-archive/sync-blacklist.txt), why does libjpeg9-dev seem to be missing and causing build problems for yoshimi (https://launchpadlibrarian.net/210424457/buildlog_ubuntu-wily-amd64.yoshimi_<IP_ADDRESS>-2_BUILDING.txt.gz)?
[21:17] <doko> infinity, please could you merge dpkg?
[21:19] <infinity> doko: Yes.
[22:04] <doko> robert_ancell, please update glibmm2.4 in silo 16
[22:04] <robert_ancell> doko, ok
[22:05] <doko> robert_ancell, btw, are you connected for this stack with Debian?
[22:05] <robert_ancell> ?
[22:05] <doko> apparently no
[22:05] <infinity> Or he doesn't speak doko English. ;)
[22:05] <doko> I'm asking for the library renaming
[22:05] <doko> infinity, when do you merge dpkg?
[22:06] <infinity> robert_ancell: I think he meant "do you maintain any of these package in Debian too"?
[22:06] <infinity> doko: https://launchpad.net/~adconrad/+archive/ubuntu/staging/+packages
[22:06] <infinity> doko: Merged, just testing a bit before I copy.
[22:06] <robert_ancell> no, I don't maintain glibmm in Debian.
[22:06] <doko> ta
[22:06] <robert_ancell> doko, which library renaming are you referring to?
[22:06] <doko> robert_ancell, could you rename the package according to the proposed naming scheme?
[22:07] <doko><EMAIL_ADDRESS>[22:07] <doko> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791050
[22:07] <robert_ancell> doko, I can have a look at that
[22:08] <doko> and so on for the whole stack. your tech lead requested it
[22:10] <robert_ancell> doko, seb128 requested it?
[22:10] <doko> yes
[22:11] <doko> see backlog
[22:18] <jderose> is anyone aware of what bug is causing the 14.04.3 64bit desktop daily ISOs to fail the automated testing? when I try running the pending ISO, the installer seems broken (wont launch at all)
[22:19] <infinity> jderose: I'm not aware of such a bug, but I suppose I probably should be. :P
[22:20] <infinity> jderose: Is it only an issue with automated/preseeded testing, or does it fail to be useful when manually booted/driven too?
[22:20] <jderose> infinity: i was just curious if there was an LP bug out there already so i can poke around, try to help :)
[22:20] <jderose> infinity: fails when trying to manually boot into it... although thus far i've only run it under kvm, so might not be an issue on real hardware
[22:21] <infinity> jderose: Hrm.  Kay.  I'll grab a daily and see how it behaves for me after dinner.
[22:21] <jderose> infinity: cool, let me know where i can help :)
[22:22] <infinity> jderose: You can help by fixing all the bugs!
[22:27] <doko> robert_ancell, copying is not good enough, we can't copy the binaries into -proposed using the same version number
[22:30] <jderose> infinity: another possible hint... i noticed that ubuntu gnome 14.04.3 64bit daily has passed the automated testing. maybe it's just not running as many tests, but seemed a little suspicious
[22:43] <jderose> infinity: just tried on physical hardware... broken there too
[22:45] <infinity> jderose: Fun.  Alright.  Like I said, I'll look after dinner.
[23:33] <infinity> jdstrand: Hrm.  So, what's the failure you're seeing?  I'm seeing no boot menu (weird), then straight to a blank desktop (probably a symptom of the first thing)


[20:30] <daker> mhall119: cjohnston i am going to merge this https://code.launchpad.net/~daker/loco-team-portal/fix.616547/+merge/107553
[20:34] <mhall119> daker: what is that Entypo font stuff?
[20:34] <daker> those are font icons
[20:34] <daker> http://www.entypo.com/
[20:35] <mhall119> ah, interesting
[20:35] <daker> you can color them by css
[20:35] <mhall119> also, the mugshots on commenter_profile won't always work
[20:35] <mhall119> because Launchpad is evil
[20:35] <daker> i have a fix for it in trunk
[20:36] <mhall119> for mugshots?
[20:36] <mhall119> how did you fix that?
[20:36] <daker> LP is slow :(
[20:38] <daker> mhall119: https://bazaar.launchpad.net/~ltp-devs/loco-team-portal/0.2/view/head:/loco_directory/common/launchpad.py#L62
[20:38] <daker> mhall119: and this function is called here https://bazaar.launchpad.net/~ltp-devs/loco-team-portal/0.2/view/head:/loco_directory/userprofiles/management/commands/update-profiles.py
[20:40] <daker> the smart_if.py tag will be removed once we move to dj1.3
[20:41] <mhall119> cool
[20:41] <mhall119> daker: my only concern is lack of tests, but if you're happy with it as the project maintainer, I have no objection
[20:42] <daker> ok i'll try to write tests for it later
[20:43] <daker> mhall119: my problem rightnow is that i don't know if i can push directly or make MP for review
[20:55] <daker> mhall119: i have a lot login issues after accounts merge
[20:56] <daker> bug #1074754
[21:21] <mhall119> daker: yes, cjohnston and I spoke to some of the SSO guys about how to resolve this, but it's going to require a new API on their end
[21:21] <mhall119> it's not a simple problem, unfortunately
[21:21] <daker> :(
[21:22] <mhall119> daker: you should be able to push directly to the trunk branch, but doing a merge will keep the history cleaner
[21:22] <daker> ok
[21:22] <mhall119> since you have a lot of revisions on that branch already
[21:22] <daker> mhall119: how can we let those people use LTP ?
[21:22] <mhall119> daker: do you have access to the /admine/sz?
[21:23] <mhall119> minus the sz
[21:23] <mhall119> that was the dog typing
[21:33] <daker> mhall119: no i don't have admin access to l.u.c
[21:39] <mhall119> ok, we need to see about getting you that
[22:11] <daker> django 1.1.2 is not longer available on pypi :( http://pypi.python.org/pypi/Django/1.1.2


[02:02] <rufian> my linux laptop sometimes crashes when I leave it idle. I get a blank screen and the fans working at full speed
[12:55] <herton> lamont: about?
[12:55] <lamont> yessir
[12:55] <herton> lamont: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/791512/comments/12
[12:55] <ubot2> Ubuntu bug 791512 in linux "tcp connections hang in forwarding machine" [Undecided,New]
[12:56] <lamont> herton: will do, it may be later today before I can do that though
[12:57] <herton> lamont: yep, no problem. Hope with this one we finally track it down.
[17:00] <amorphous> Hello folks. Does anyone know how to disable hyper-threading for Intel CPU's? I tried 'noht' boot option and it didn't work.
[17:01] <jpds> amorphous: Isn't that something done on a BIOS level?
[17:01] <amorphous> Yes. But I don't know how to turn if off if there's no BIOS setting for that
[17:02] <amorphous> some manufacturers use BIOS versions that are locked down. (very few options available)
[17:20] <amorphous> jpds, so no other way to disable it if BIOS option is missing?
[17:21] <jpds> amorphous: Not that I know of.
[18:01] <hrw> apw: check http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git;a=shortlog;h=refs/heads/tilt-tracking for omap4 code for 3.0 kernel
[18:08] <jwi> narf - could someone with the required permissions reset the maverick status of bug 790754 to 'committed'? it's part of -30.55, not -30.54. sorry about that, manjo :/
[18:08] <ubot2> Launchpad bug 790754 in linux "[NATTY] RICOH [1180:e823] unable to read MMC cards" [Undecided,Fix committed] https://launchpad.net/bugs/790754