[00:00] <gsilva> btw, wxl, my membership meeting will be on the 7th. Do you think you can attend to that one?
[00:00] <wxl> yep i will be there gsilva
[00:00] <gsilva> Okay, thank you :)
[00:00] <gsilva> I'll also ask belkinsa in one of these upcoming days
[00:00] <wxl> only thing that would keep me from it is if work pulled me away for some reason
[00:01] <wxl> in which case, i'd email in a +1 (that counts)
[00:01] <gsilva> I see. No worries, if you can, great, if you can't, I'll survive :P
[01:45] <ianorlin> wxl I want to save that to a subpage under my user page on the wiki for future reference
[15:09] <wxl> ianorlin: which'n?
[15:34] <fwioq> would 15.10 get finaly lxqt?
[15:34] <fwioq> http://lubuntublog.blogspot.de/2014/10/lubuntu-14.html
[15:35] <fwioq> For the moment we are still working on our plans to implement LXQt in either 15.04 or 15.10.”
[15:35] <fwioq> it does not get into 15.04 so it would get for shure into 15.10 ?
[16:58] <wxl> anyone have time to confirm the fix in bug 1300798
[17:35] <ianorlin> wxl when you were explaining the workflow to get changes in launchpad and github
[17:42] <wxl> ianorlin: we should make a "launchpad for github users" page :)
[18:14] <pedanticweirdo49> hello ladies and gents - just to let you know that the link to the ubuntu release notes on the lubuntu home page is wrong
[18:15] <pedanticweirdo49> specifically
[18:15] <pedanticweirdo49> running jQuery("#Ubuntu_Release_notes+ul a").attr("href")
[18:15] <pedanticweirdo49> in developer console
[18:16] <pedanticweirdo49> result is "https://wiki.ubuntu.com/VividVervert/ReleaseNotes"
[18:16] <pedanticweirdo49> but result should be "https://wiki.ubuntu.com/VividVervet/ReleaseNotes"
[18:20] <ianorlin> I don't have access to edit that but thanks
[18:21] <pedanticweirdo49> while I'm here, do you know if I will be able to install on a 64 bit system with 32 bit uefi (and no legacy boot) without having to recompile grub?
[18:26] <ianorlin> pedanticweirdo49: I am not sure about that as I don't have any of those systems
[18:27] <wxl> pedanticweirdo49: nice nick. that's on lubuntu.net
[18:27] <wxl> ?
[18:27] <pedanticweirdo49> yes
[18:28] <wxl> hm i might not be seeing the same thing you are. 1s
[18:29] <wxl> i see it thanks
[18:30] <wxl> that might be on the wiki page too
[18:30] <wxl> nope it's not
[18:30] <wxl> hahahah it's like someone re-typed all the notes XD
[18:32] <krytarik> wxl:  https://wiki.ubuntu.com/VividVervet/ReleaseNotes/Lubuntu?action=diff&rev2=11&rev1=10
[18:32] <pedanticweirdo49> looks like my work here is done
[18:32] <pedanticweirdo49> thanks for all your hard work chaps
[18:33] <wxl> i see
[18:33] <wxl> if only we had access to lubuntu.net >:(
[21:02] <wxl> well, i've hit it: nth-level geek status. running in emacs in a terminal with evil for vi keybindings.
[21:08] <ianorlin> I don't think running emacs on a rotary phone would be possible
[21:33] <wxl> ianorlin: oh, did i mention i'm running my whole computer off of a treadmill?
[21:34]  * wxl kids :)
[21:41] <Unit193> wxl: You killed him.
[23:02] <gsilva> ianorlin, is gilir usually around on irc?
[23:02] <gsilva> or his nickname is another one?
[23:02] <wxl> gsilva: rarely ever
[23:03] <gsilva> Hum, okay. Was expecting more answers from the community to join the session of Lubuntu next Thursday
[23:03] <wxl> huh?
[23:03] <gsilva> At the UOS, the one we were organizing?
[23:04] <gsilva> I was expecting more answers on the mailing list of people warning us if they are interested to attend or not
[23:04] <wxl> oh yeah i wouldn't expect that
[23:04] <wxl> in fact i wouldn't expect nothing
[23:04] <wxl> but people WILL join :)
[23:05] <wxl> might want to encourGe them to register
[23:05] <gsilva> Hope so :)
[23:21] <gsilva> wxl, do you know any remote work website?
[23:21] <wxl> gsilva: you mean like businesses that support remote work?
[23:21] <gsilva> I only know weworkremotely but that one is focused on programming and design offers
[23:21] <wxl> yeah don't know, sorry
[23:21] <gsilva> No, a job market focused on remote work
[23:22] <gsilva> The offers in my country are a complete joke.


[12:34] <bluesabre> fossfreedom: going to do some testing for lp 1669818 and I can do the greeter upload if everything looks good
[12:34] <bluesabre> (and hi from Xubuntu team)


[00:15] <nemo> Hm. I think you guys maybe have something broken in your tab complete...
[00:15] <nemo>  svn diff sk.bash: [: too many arguments
[00:15] <nemo> sk.txt  sk.zip
[00:15] <nemo> (that was me hitting tab on sk. )
[00:16] <nemo> on a similar front, super annoying that mplayer startofogvfile<tab> does not tab complete - like it doesn't recognise *.ogv
[00:17] <ScottK> nemo: File bugs.  An IRC channel is not a very good bug tracker.
[00:38] <TheMuso> crimsun: Sounds good.
[01:17] <psusi> cjwatson, think you can review my fix for the dmraid regression and upload it as an SRU once some other users successfully test it?  see bug #568050 and the linked bzr branch
[02:49] <nemo> ScottK: heh. actual bug tracker isn't a very good bug tracker either. but fine.
[02:49] <ScottK> nemo: It tends to be a bit more peristent than IRC backscrolls though.
[07:32] <\sh> moins
[08:01] <pitti> Good morning
[08:05] <\sh> moins pitti
[08:17] <dholbach> good morning
[08:19] <mvo> hey dholbach
[08:19] <dholbach> hey mvo
[08:20] <didrocks> hey dholbach, good morning mvo
[08:21] <dholbach> salut didrocks
[08:22] <mvo> hey didrocks!
[08:56] <AnAnt> Hello
[08:56] <AnAnt> regarding this bug LP 580944
[08:56] <AnAnt> it is obvious that the /etc/default/sl-modem-daemon (ie. a conf file) has been damaged or tampered with severely, anyways it caused the package state to be not be fully installed
[08:57] <AnAnt> what's the optimum solution: shall I attach to the user the default conf file & tell him to put it there ? or is there  a way to reinstall the package (& overwriting the conf files)
[08:57] <AnAnt> mvo: ping ^
[08:58] <mvo> AnAnt: it would be interessting to know the state of the file
[08:58] <mvo> AnAnt: so attaching it is a good idea
[08:58] <AnAnt> mvo: state of the file ?
[08:58] <AnAnt> mvo: the file is attached
[08:59] <mvo> AnAnt: oh, ok. let me actually look at the bugreport then
[08:59] <AnAnt> mvo: that's why I said it was either damaged, or someone severely tampered it
[09:00] <mvo> AnAnt: indeed, that looks like file system corruption
[09:01] <mvo> AnAnt: I guess best is removing it and reinstalling with "dpkg -i --force-confmiss /var/cache/apt/archives/sl-modem-daemon_<tab>"
[09:01] <mvo> AnAnt: or purge/reinstall with apt-get
[09:02] <AnAnt> mvo: do you think and can be purged ?
[09:02] <AnAnt> mvo: or even removed ?
[09:02] <AnAnt> I've seen packages that go into a real bad state that you can neither remove nor upgrade !
[09:02] <AnAnt> unless I have to remove some prerm for example
[09:03] <mvo> AnAnt: that is (unfortunately) true, but happens not that often, in this casse it may work, but I have not looked at the orther scripts of the pkg
[09:03] <AnAnt> mvo: ok
[09:05] <AnAnt> thanks
[09:05] <AnAnt> bye
[12:00] <stgraber> Keybuk: could you have a look at bug 581527 when you have a minute ? the attached patch should hoppefuly make the life of some OpenVZ users a bit easier as well as fix some other cases I don't know about ;)
[12:00] <Keybuk> the patch is still wrong
[12:01] <Keybuk> udev cannot function without the netlink socket
[12:02] <stgraber> yes, I know that, I just don't think "cannot function" means it should segfault ...
[12:02] <stgraber> in a VZ environment we don't have any kind of device anyway, so we really don't need udev to work, we just need it to not make the software crash because it segfaults ...
[12:03] <Keybuk> I'd be happy if your patch made it an assertion error
[12:04] <stgraber> as I mentioned in the bug report, I really don't know much about udev's code and so don't have a clue about its error codes, so if you know what that function should return when it doesn't get a valid structure as parameter, I'll be happy to change the patch
[12:04] <Keybuk> if you pass invalid data to functions, that's always a programming error, thus an assertion error
[12:10] <stgraber> Keybuk: ok, I'm looking at moving it to making an assertion error. Just wondering why it's not the case for all the other functions in that file that simply "return NULL" when udev_monitor is NULL, any idea ?
[12:10] <Keybuk> no idea, you'd have to talk to upstream
[12:10] <Keybuk> they may have a different opinion
[12:44] <cjwatson> Keybuk: so, casey's MoM lock is still held following the reboot a while back - can I remove it so that the cron job proceeds, or are you operating it manually?
[12:47] <Keybuk> cjwatson: I thought you were operating it ;)
[12:48] <cjwatson> nope
[12:48] <jml> hello
[12:49] <cjwatson> I asked if I could remove the lock a few days ago, but I guess it got lost in UDSery and I didn't see an answer, so I stayed clear but forgot to re-ask on the train or whatever
[12:55] <cjwatson> Keybuk: I'm going to take that as a yes, and have removed the lock now
[12:55] <Keybuk> sorry, was on the phone
[12:55] <Keybuk> yes, it's ok for you to drive :p
[12:55] <cjwatson> ah ok
[12:55] <cjwatson> I don't want to drive, I just want to let cron drive. :-)
[12:56] <cjwatson> .oO( maybe mom should be an upstart service to avoid all this stale lock guff )
[12:57] <Keybuk> heh
[12:58] <cjwatson> I suppose that's a sane thing to have in upstart-cron, run once an hour unless it's running already
[12:58] <cjwatson> though doesn't really cover running it by hand
[12:59] <Keybuk> indeed
[12:59] <Keybuk> "start mom"
[14:04] <JFo> cjwatson, I have a bug that you will probably be interested in: bug 578742
[14:05] <JFo> I apologize in advance :-)
[14:07] <cjwatson> JFo: not too bothered yet, assuming that it can be forwarded upstream and fixed in maverick; at this point, given the lack of userspace support, I only care about problems that would make it difficult for us to implement that support
[14:07] <cwillu_at_work> JFo, anything less than an rc of 2.6.34 is considered obsolete and basically dangerous to use by #btrfs :p
[14:08] <JFo> oh indeed
[14:08] <JFo> my concern is, how to address this with the reporter. Plus my boss (pgraner) told me to punt to cjwatson :-)
[14:11] <cjwatson> JFo: um, I don't see how it's anything much to do with me.  I have many of the tasks to implement userspace support in maverick, but kernel support for btrfs is not my problem
[14:11] <JFo> heh
[14:11] <JFo> no problem
[14:11] <JFo> my desire is to respond that it is unsupported
[14:11] <cwillu_at_work> a dkms package + more recent btrfs userspace would make upstream happier with us :p
[14:11] <JFo> so that is the plan
[14:11] <cjwatson> JFo: that would be inappropriate
[14:11] <JFo> and yet, that is what I am told from both sides
[14:12] <JFo> well *currently* unsupported
[14:12] <cjwatson> JFo: the correct way to deal with it would be to test whether it's fixed in a more recent release; if it is, it can be closed as Fix Released in maverick; if it isn't, it should be forwarded upstream
[14:12] <cjwatson> just closing it as "unsupported in lucid" deprives us of a source of problem reports, surely
[14:12] <cjwatson> it cannot be the case that all possible bugs people might file on lucid's btrfs are automatically fixed in maverick's
[14:13] <cwillu_at_work> cjwatson, a dkms build of the latest or running 2.6.34 would suffice for that;  upstream thinks it's saner to use a dkms build though
[14:13] <cjwatson> cwillu_at_work: sure, my point is it should be actually tested before closing it
[14:14] <cwillu_at_work> fair enough;  a ppa with up-to-date modules would be useful
[14:15] <cwillu_at_work> there's lots of issues with btrfs in 2.6.32 though, somewhat fewer in 2.6.33;  bug reports from those versions shouldn't be upstreamed until they've been tested with more recent versions imo is all I'm saying
[14:15] <cjwatson> JFo: to clarify, saying it's unsupported is fine, but not in itself a reason to close the bug since after all we do ship it, and the reason we ship it is to collect early feedback so automatically discarding that feedback is a bit odd
[14:16] <cjwatson> (I think the fact that people have to go through contortions to get their system to boot with a btrfs / is a fairly clear indication that it's unsupported in lucid)
[14:17] <cwillu_at_work> JFo, you should mention on that bug that running btrfs on rootfs is actively dangerous;  there's a dpkg bug that isn't fixed in lucid that hurts _really_ bad with btrfs
[14:17] <cwillu_at_work> /var/lib/dpkg/info corruption specifically
[14:17] <cwillu_at_work> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575891
[14:17] <cjwatson> cwillu_at_work: lies, that's fixed in lucid :)
[14:18] <cwillu_at_work> cjwatson, it is?  I missed that commit then :p
[14:18] <cjwatson> cwillu_at_work: dpkg <IP_ADDRESS>ubuntu4
[14:18] <cwillu_at_work> ah, goodie
[14:18] <cwillu_at_work> I've been bind mounting my /boot onto /var/lib/dpkg for a while because of that :)
[14:21] <cwillu_at_work> in related non-news, I'm trying to get btrfs to build as a dkms module, but I keep tripping on a permission error during dkms build
[14:36] <cwillu_at_work> ah, got it;  symlinked to the root of the tree instead of fs/btrfs
[14:38] <lool> stgraber: Hey
[14:38] <lool> stgraber: I just wanted to tell you your UDS demo was awesome
[14:39] <popey> ooo yes, I agree lool !
[14:43] <ScottK> JFo: Bug #496093 looks like it's in need of some serious triage/sorting out how many problems are really in one bug.  It's one of the two bugs the release team is subscribed to that is still getting piles of new comments.
[14:44] <JFo> ugh, thanks for the pointer ScottK
[14:44] <ScottK> JFo: Enjoy.
[14:44] <ScottK> ;-)
[14:44] <JFo> heh
[14:44] <imbrandon> yea i'm actualy bit by that bug on my other laptop ( or a variant of ) [ rt2870 ]
[14:44] <imbrandon> i was just reading it too
[15:20] <cjwatson> mdke: could https://help.ubuntu.com/9.10/installation-guide/ be updated to the version in karmic-proposed, which is actually distinct from jaunty?
[15:21] <cjwatson> or, well, meaningfully distinct in terms of version numbers and such
[15:32] <akgraner> kenvandine, oops :-(  sorry about that  - did the bliptv title have it that way - I think that is where we pulled the titles from
[15:33] <kenvandine> :)
[15:33]  * kenvandine looks
[15:34] <kenvandine> akgraner, yup... it's wrong there
[15:34] <kenvandine> akgraner, can you fix it there?
[15:34] <akgraner> kenvandine, I'll email them.. and let ya know
[15:34] <akgraner> :-)
[15:34] <kenvandine> thx :)
[15:36] <akgraner> kenvandine, popey is going to change it
[15:36] <akgraner> :-)
[15:38] <akgraner> kenvandine, I hope you badge was right as they even took pics of the badges :-)
[15:38] <kenvandine> hehe... it was
[15:38] <popey> sorry for not spotting that on the day
[15:38] <akgraner> thanks for catching that
[15:38] <kenvandine> no worries
[15:39] <popey> have changed and triggered resync to youtube
[15:39] <kenvandine> awesome
[15:44] <shtylman> who would I talk to about getting kde imported into launchpad? (likewise for qt)
[15:44] <Riddell> shtylman: james_w ?
[15:44] <Riddell> if you're talking about code
[15:44] <shtylman> yea... code indeed
[15:44] <psusi> cjwatson: so you are going to SRU the libparted fix for the 10.04.1 respin? :)
[15:44] <james_w> hi shtylman
[15:44] <Riddell> I expect most of our packages do have code branches in launchpad, some like kdebase don't but that should be fixable
[15:45] <shtylman> james_w: howdy
[15:45] <cjwatson> psusi: it has my attention now at least
[15:45] <Riddell> if you're talking about svn imports, that's more complex
[15:45] <psusi> cjwatson: looks like another user reported it worked for them...
[15:45] <james_w> shtylman: what can I help you with?
[15:45] <shtylman> james_w: to bring you up to speed, the current plan is to be able to do qt and kde daily builds when launchpad supports it
[15:46] <shtylman> james_w: this means that we need to make sure we have all the nessesary kde svn code in launchpad bzr (as I understand it)
[15:46] <cjwatson> psusi: I'm still catching up after UDS, I don't expect to decide today
[15:46] <psusi> k
[15:46] <shtylman> I haven't the first clue on the proper way to import that or layout the bzr branches ... so I seek guidance :)
[15:47] <Riddell> note that Qt is in Git
[15:47] <james_w> shtylman: that's correct. I'm not really the person to talk to about that, you want someone on the launchpad-code team.
[15:48] <james_w> shtylman: there is documentation at https://help.launchpad.net/Code/Imports, and you can find people on #launchpad that should be able to help
[15:48] <shtylman> james_w: thanks
[15:48] <james_w> shtylman: let me know if you don't get anywhere
[15:49] <shtylman> k
[15:51] <psusi> Keybuk: wait, what's this about udev not creating dev nodes anymore, but devtmpfs instead?  yet another kernel fs to auto create dev nodes?  I thought that was one of the reasons udev was made, to get away from devfs and move the dev node creation to user space?
[15:51] <Keybuk> that was *last year* :p
[15:51] <Keybuk> now udev doesn't create device nodes
[15:52] <pitti> psusi: well, the original objection was about the kernel defining names and permissions, not so much the actual mknod(), AFAIR
[15:52] <Keybuk> quest scott% cat /etc/issue.net
[15:52] <psusi> so it's back to a new devfs like kernel fs?  ack...
[15:52] <Keybuk> Ubuntu 10.04 LTS
[15:52] <Keybuk> quest scott% mount | grep "on /dev"
[15:52] <Keybuk> none on /dev type devtmpfs (rw,mode=0755)
[15:52] <Keybuk> pitti: which is also ironic, since now we make the kernel define the names and don't let you change them in userspace ;-)
[15:52] <cjwatson> it's not really as much like devfs as all that
[15:52] <maco> Keybuk: does the kernel just go in cycles about how to handle this stuff?
[15:52] <pitti> Keybuk: but we still control permissions and symlinks
[15:53] <Keybuk> pitti: right
[15:53] <pitti> which the original devfs didn't
[15:53] <cjwatson> the problems with devfs were (a) it had its own special and unique snowflake naming scheme (b) it introduced a huge pile of new kernel infrastructure just for itself (c) it didn't allow any userspace control at all
[15:53] <psusi> so wait... you can no longer use a udev rule to persistently name a given disk /dev/sda even if the kernel detects it in a different order?
[15:53] <cjwatson> devtmpfs doesn't suffer from these problems
[15:53] <pitti> psusi: you can do arbitrary symlinks, but not rename the "master" node
[15:53] <Keybuk> psusi: correct, you can only use a udev rule to persistently add a symlink to the disk with the name that is memorable to you
[15:53] <maco> psusi: yay for UUIDs?
[15:53] <Keybuk> /dev/porn -> /dev/sdXY  where the XY is whatever it is this boot
[15:54] <psusi> that seems like a big step backwards?
[15:55] <pitti> psusi: NB that even without devtmpfs current udev does not support renaming any more :)
[15:55] <Keybuk> not really
[15:55] <pitti> but symlinks are really just as good
[15:55] <Keybuk> allowing renaming of device nodes caused huge numbers of problems and gained nothing
[15:55] <psusi> it did?
[15:55] <Keybuk> symlinks work perfectly for "personal names"
[15:55] <Keybuk> psusi: yes, for example, swap /dev/sda and /dev/sdb atomically ;-)
[15:55] <psusi> hrm... I suppose
[15:56] <psusi> why need to do it atomically?  just have udev create them with the correct name in the first place
[15:56] <Keybuk> and there's benefit to having a "master node" whose name matches the standard at all times
[15:56] <Keybuk> and whose name matches the sysfs object too
[15:56] <Keybuk> renaming sda to sdb would not rename /sys/devices/.../sd
[15:56] <Keybuk> renaming sda to sdb would not rename /sys/devices/.../sda
[15:57] <psusi> hrm... true... I have been getting annoyed lately running that script to parse the ureadahead output and it gets confused because the kernel name listed is dm-5,  but there is no /dev/dm-5
[15:57] <Keybuk> see, Symlinks 1 - Renames 0
[15:57] <Keybuk> ;P
[15:57] <psusi> good point ;)
[15:59] <psusi> now... I still see an issue with the naming of dm nodes
[15:59] <Keybuk> we're hoping that the devmapper kernel-side will start putting NAME= into its uevents
[15:59] <Keybuk> err, DEVNAME= sorry
[15:59] <psusi> if the native kernel name is dm-1 for the partition on dm-0... does that mean that devtmpfs will create dm-1, then udev will see that it is a partition and make a link for dm-0p1 to point to it?
[15:59] <Keybuk> if that's the desired behaviour, that makes sense
[16:00] <Keybuk> dm0
[16:00] <Keybuk> dm1 -> dm0p1
[16:00] <Keybuk> dm2 -> dm0p2
[16:00] <Keybuk> dm3
[16:00] <Keybuk> dm4 -> dm3p1
[16:00] <Keybuk> doesn't seem terrible
[16:00] <Keybuk> except I got my arrows the wrong way around :)
[16:00] <psusi> personally I don't like the p in there, but can live with it... but really it seems cumbersome to map dm-1 to dm-0p1 rather than just partition dm-0... seems the kernel side really needs to just support partitions like md now does
[16:01] <Keybuk> that would be better, I agree
[16:02] <Keybuk> biab
[16:03] <pitti> why am I suddenly spammed with millions of merge proposals? is that just me?
[16:04] <james_w> pitti: I think it might be due to being in ~techboard. Does the mail say why?
[16:04] <pitti> not really
[16:04] <pitti> james_w: but I've been in TB for a long time, and this only started this week
[16:05] <pitti> or perhaps last week with a new LP rollout, and I just ignored them
[16:05] <james_w> pitti: ah, rollout
[16:05] <james_w> LP now sends mail on merge proposals via teams, it used to just be direct subscriptions
[16:06] <james_w> I've been trying for ages to restructure things so that ubuntu-dev would catch merge proposal mail, but it's slow going
[16:06] <james_w> I'll go ping the losas
[16:06] <pitti> james_w: thanks
[16:17] <cr3> is there a way to have network interfaces consistently appear as eth0, eth1, etc. based on mac address?
[16:18] <jpds> cr3: Yes.
[16:18] <cjwatson> cr3: /etc/udev/rules.d/70-persistent-net.rules
[16:19] <cr3> cjwatson: awesome! has this been around for long?
[16:19] <cjwatson> quite a few releases, yes
[16:19] <cjwatson> definitely at least hardy but I think rather longer
[16:36] <bigcx2> hey all
[16:36] <bigcx2> not sure if this is the proper outlet for this
[16:36] <bigcx2> but
[16:36] <bigcx2> does anybody know how to create a keyboard binding/shortcut without X running?
[16:36] <bigcx2> like in a virtual console?
[16:41] <arand> bigcx2: It's #ubuntu for support.
[16:51] <bigcx2> arand: figured, didn't really feel like my message getting lost in the 1600+ people trying to get support in there
[17:49] <cr3> what's the file under /proc, I think, which can be used to reset the buffer cache?
[17:50] <cjwatson> cr3: /proc/sys/vm/drop_caches
[17:50] <cr3> I think it's /proc/sys/vm/drop_caches, I wonder if I simply need to echo 0 in there... trying it out...
[17:50] <pochu> cr3: yes
[17:51] <ion> proc(5). echo 3.
[17:51] <cr3> pochu: I was running top which showed something like: 84456k buffers. after running echo 0 | sudo tee -a /proc/sys/vm/drop_caches, the value didn't change significantly
[17:52] <cr3> ion: awesome, thanks!
[18:09] <psusi> echo 1 drops file cache, 2 drops dentry cache, 3 drops both
[18:13] <apw> can anyone tell me how the 'Supported:' information gets into apt-cache showpkg output?
[18:15] <cjwatson> apw: talk to mvo
[18:16] <slangasek> apw: and as of last week, there's a bug that shows all -updates packages as 'unsupported'
[18:17] <apw> slangasek, ahh i have new kernel packages with no line at all, likely related
[19:06] <bdrung> nxvl:
[19:06] <bdrung> ping
[19:15] <Damascene> I couldn't find solang in ubuntu repo
[19:15] <Damascene> it should be there so one can test it
[19:17] <bdrung> Damascene: it was removed in debian and in ubuntu afterwards
[19:18] <Damascene> do you know why?
[19:18] <kklimonda> Damascene: it got removed from lucid due to buggy nature and depending on deprecated libraries. no one has stepped in to help with updating it (neither then nor now). it also got removed from debian (probably the same reason)
[19:18] <Damascene> because some one thought it is a port of f-spot?
[19:19] <bdrung> kklimonda: i saw one bug report with an updated package
[19:19] <kklimonda> Damascene: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=547506
[19:19] <bdrung> https://launchpad.net/bugs/512097
[19:19] <Damascene> I see
[19:20] <Damascene> thanks
[19:21] <Damascene> mlterm is now in version 3. it will be included in the next release or some on should ask for that?
[19:21] <kklimonda> solang 0.4 has one interesting feature - they have replaced their database with the tracker backend
[19:22] <kklimonda> on the other hand shotwell is written in Vala - also nice interesting technology.. choice, choices ;)
[19:22] <kklimonda> Damascene: what has been decided at UDS?
[19:25] <nxvl> bdrung: pong
[19:26] <Damascene> kklimonda, I don't know
[19:26] <Damascene> who knows?
[19:26] <Damascene> nxvl, how come no one knows about keyrx
[19:27] <bdrung> nxvl: bug #581167 - should i remove "(Canonical)" from your name? a complaining gpg is a configuration problem.
[19:27] <bdrung> nxvl: the .pc directory came from the debian branch and it's probably a bug of the importer
[19:27] <nxvl> bdrung: if you want to, the problem is that my gpg key is exactly like that, if not present it won't recognize my gpg key, but since i'm not signing + uploading, i don't really mind
[19:28] <nxvl> bdrung: i just have it like this in my DEBFULLNAME for when i do universe
[19:29] <bdrung> nxvl: most commands allow to set the key (i set DEBSIGN_KEYID in /etc/devscripts.conf)
[19:29] <nxvl> huh
[19:29] <nxvl> interesting
[19:29] <nxvl> will take a look at that then
[19:29] <nxvl> :D
[19:29] <nxvl> thanks for the tip
[19:30] <kklimonda> Damascene: I think it was dpm who has asked you to raise this issue at the UDS and he may be a good person to ask anyway
[19:30] <bdrung> i have two keys and want to force the correct one (and it's easier for sponsoring)
[19:31] <nxvl> Damascene: about what?
[19:31] <Damascene> nxvl, about the ubuntu should provide update packages bug
[19:31] <nxvl> ohh
[19:32] <Damascene> seem like keryx do the job
[19:32] <Damascene> it should get some support form ubuntu
[19:33] <nxvl> Damascene: will take a look at it later
[19:33] <Damascene> ok
[19:34] <nxvl> Damascene: ohh, gui, i'm not maintaining that
[19:34] <nxvl> Damascene: ping mvo about this
[19:34] <Damascene> ok
[19:35] <bdrung> nxvl: configure changes the patched Makefile?
[19:35] <Damascene> Bug 572776
[19:35] <Damascene> just for reference
[19:35] <nxvl> bdrung: not as far as i remember, or we patched that aswell
[19:36] <nxvl> mdeslaur: ^^
[19:36] <nxvl> mdeslaur: is about openssl
[19:36] <bdrung> nxvl: "Those can't be striped out, please see changelog entry for 0.9.8k-7ubuntu2 and 0.9.8k-7ubuntu3 for more information"
[19:38] <mdeslaur> bdrung: hmm...the pc directory was present because the patches are currently _applied_ in the source tree
[19:38] <bdrung> nxvl: Configure and util/perlpath.pl are modified directly. so there should be no problem in putting these changes into patches.
[19:38] <nxvl> bdrung: actually, is source format 3.0, so those are quilt patches anyway
[19:39] <nxvl> let me find the wiki
[19:39] <bdrung> nxvl: yes, but i want to avoid debian/patches/debian-changes-0.9.8n-1ubuntu1
[19:40] <nxvl> bdrung: configure was an issue too, because it didn't clean or something, mdeslaur knows more about the issue since he fixed it last time
[19:41] <nxvl> an please get in touch with him since he had some plans for this upload aswell, or something
[19:42] <bdrung> mdeslaur: ping
[19:42] <mdeslaur> bdrung: yeah
[19:43] <bdrung> mdeslaur: i was talking with nxvl about openssl
[19:44] <mdeslaur> bdrung: are you reviewing it?
[19:44] <bdrung> mdeslaur: the new package has "direct" changes and are put into debian/patches/debian-changes-0.9.8n-1ubuntu1 due to dpkg-source 3.0 (quilt).
[19:44] <bdrung> mdeslaur: yes
[19:45] <mdeslaur> hmm...I'm not sure how that will work with source 3.0
[19:45] <bdrung> it would be nice to have debian-changes-0.9.8n-1ubuntu1 reverted back to proper patches
[19:45] <mdeslaur> bdrung: maybe the FTBFS issue is resolved now that the package has been migrated to 3.0
[19:45] <bdrung> it should work with 3.0
[19:46] <mdeslaur> bdrung: someone will need to test it with proper patches to see if it will build on all archs
[19:46] <bdrung> mdeslaur: it's just an issue of building twice
[19:47] <mdeslaur> bdrung: right, the patches wouldn't un-apply cleanly before, so the build would fail
[19:47] <bdrung> yes, but 3.0 (quilt) does not unapply the patch
[19:48] <bdrung> Damascene: i use apt-mirror to mirror the complete archive. then i transport this on an hdd to the networkless computer
[19:48] <Damascene> do you want some one to download the whole ubutnu repo?
[19:49] <bdrung> Damascene: i must admit that this is an overkill for just having the updates ;)
[19:50] <Damascene> keryx seems fine but I've not tested it yet
[19:50] <Damascene> I mean not so much testing
[19:50] <Damascene> but having the packages from ubuntu would be fine too
[19:58] <bdrung> nxvl: the package has many lintian error and warnings
[19:58] <nxvl> ok, just unsubscribe -sponsors and i will take a closer look after work
[19:59] <nxvl> and please add that infor to the bug report
[19:59] <nxvl> i assume plane-merging isn't as good as it sounded :P
[19:59] <bdrung> nxvl: i think it's better to work with debian to resolve the lintian errors
[20:00] <bdrung> nxvl: the clean target isn't clean
[20:03] <nxvl> mdeslaur, kees, jdstrand: next cicle i won't touch openssl, enough headache for 2 releases!
[20:03] <nxvl> :D
[20:13] <micahg> should the libgs8 patch be taking an extra 1.5MB?
[20:28] <Daenyth> Will pbuilder run easily on a non-ubuntu host?
[20:28] <Daenyth> Right not I build in an ubuntu vm on arch linux host, but that's rather slow. chroot would be much nicer
[20:29] <Daenyth> is that easily set up?
[20:33] <pochu> !pbuilder | Daenyth
[20:34] <Daenyth> pochu: those instructions assume you are running on ubuntu
[20:36] <pochu> Daenyth: what's your host?
[20:37] <Daenyth> arch linux
[20:37] <pochu> it works. I dunno about arch linux instructions or success stories there though
[20:38] <Daenyth> I mean, if it's been known to work on at least *some* non-ubuntu systems, I can wing it from there
[20:38] <Daenyth> I just wanted to know if pbuilder will break if not run on ubuntu
[20:38] <Daenyth> I can't imagine it needs to know *that* much about the host system...
[20:39] <ScottK> It will run on Debian.  Not sure about anywhere else.
[20:39] <joaopinto> there were some pbuilder packages on arch, check google :P
[20:39] <Daenyth> I'll look into that
[20:39] <joaopinto> there is debootstrap, according to google
[20:40] <Daenyth> well yeah
[20:40] <joaopinto> chroot/debootstrap should be sufficient to install a debian base system
[20:40] <Daenyth> hrm
[20:40] <Daenyth> yes true
[21:04] <cwillu_at_work> joaopinto, debootstrap has a specific target for pbuilder in fact :p
[21:12] <smoser> can someone clarify ?
[21:12] <smoser> grub 1.98-1ubuntu6 is grub 2
[21:12] <smoser> right?
[21:12] <ScottK> smoser: It is.
[21:12] <smoser> yeah, i see that now 'apt-cache show grub2 | grep Version'
[21:12] <smoser> just confusing. thanks though.
[22:12] <shtylman> anyone have any git-buildpackage experience? ... is it possible to build without cleaning? it seems to want to clean all the time
[22:13] <shtylman> does bzr buildpackage have a noclean mode?
[22:15] <slangasek> shtylman: bzr-buildpackage doesn't clean, it just exports (which will ignore files in the working directory that bzr doesn't know about).  If you want to skip the redundant clean afterwards, you would run 'bzr bd -- -nc'
[22:15] <slangasek> (to tell debuild not to call debian/rules clean)
[22:16] <shtylman> slangasek: thanks
[22:17]  * ScottK gives kees a hug.
[22:25] <shtylman> if I have a project that builds with scons... is there something (env var or whatnot) that I can put in the debian/rules file to basically pass the -j flag onto scons when dpkg-buildpackage runs it?
[22:26] <xnox> shtylman, dh supports scons
[22:26] <xnox> %:
[22:26] <xnox>        dh --parallel $@
[22:26] <shtylman> um... I don't follow :/
[22:27] <xnox> this will pass -j flag to scons configure / build if DEB_BUILD_OPTIONS=parallel=X
[22:27] <xnox> is set
[22:27] <shtylman> sorry for my newbieness :)
[22:27] <xnox> shtylman, read
[22:27] <xnox> $ man debhelper
[22:27] <xnox> $ man dh_auto_configure
[22:27] <shtylman> k
[22:27] <xnox> $ man dh_auto_build
[22:27] <xnox> =)
[22:27]  * shtylman goes to read
[22:31] <micahg> tkamppeter: should the libgs8 update take an extra 1.5MB?
[22:32] <tkamppeter> micahg, which libgs8 update? The recent SRU?
[22:32] <micahg> tkamppeter: yes
[22:33] <shtylman> xnox: were you implying that it would automatically pass that to the build system? or that I need to make sure the rules file must have something special beyond running scons in the build-stamp target (which is what happens right now)
[22:34] <xnox> shtylman, dh $@ will automagically handle parallel, strip, optimize options for you. Beyond the two line snippet you shouldn't need anything else =)
[22:34] <shtylman> xnox: gotcha... but from my memory of makefiles %: is a catch all ... why would I want to use that specifically?
[22:35] <shtylman> right now, the rules file has a build target that calls scons itself
[22:35] <shtylman> is that wrong?
[22:35] <xnox> shtylman, you can do that =)
[22:35] <ScottK> It's not wrong, but it may make it harder than it has to be.
[22:35] <xnox> and yes %: is catch all
[22:36] <xnox> but that's the beauty of it
[22:36] <xnox> read
[22:36] <xnox> $ man dh
[22:36] <shtylman> heh
[22:36] <xnox> dh build
[22:36] <shtylman> I think my rules file is not including debhelper... which is part of the problem :)
[22:36] <xnox> runs configure, build, test (with policy complaint options for most of buildsystems)
[22:36] <xnox> dh binary (makes sure the software is build installed and all dh_* scripts are run in correct order)
[22:37] <xnox> dh clean (does buildsystem clean and cleans all stamps & etc)
[22:38] <tkamppeter> micahg, this is strange, the patch cannot generate another 1.5MB of code. Perhaps a build server problem.
[22:39] <micahg> tkamppeter: .deb files seem to be the same size
[22:40] <xnox> shtylman, bzr branch lp:~dmitrij.ledkov/+junk/dh-style
[22:40] <xnox> shtylman, this branch has presentation about dh & 5 samples on how to use it =)
[22:40] <shtylman> xnox: nice :)
[22:40] <tkamppeter> micahg, where is the difference then? The /usr/lib/libgs.so.8.71 file?
[22:40] <micahg> tkamppeter: I'm pulling them down now to check
[22:43] <micahg> tkamppeter: yes, I'll pastebin
[22:44] <micahg> tkamppeter: http://pastebin.com/eLvvw7Sr
[22:47] <micahg> tkamppeter: BTW, I'm on amd64
[22:49] <tkamppeter> micahg, unfortunately, I cannot help here, best is you ask a gcc expert.
[22:49] <micahg> tkamppeter: k, thanks
[23:06] <joaopinto> anyone experienced in converting OSS to PA client applications ?
[23:07] <pochu> joaopinto: maybe ask on #pulseaudio ?
[23:08] <joaopinto> good point :P


[07:27] <hyperair> RAOF: https://bugs.freedesktop.org/show_bug.cgi?id=48777 <-- i wonder if this would fix the xi2 scroll-jamming issue
[09:43] <kklimonda> hum, any idea on bug 800022? people seem to have to export LIBVA_DRIVER_NAME="fglrx" for va-api to work (and some applications not crashing)
[09:48] <kklimonda> or is it an incorrect link..
[09:52] <RAOF> hyperair: No, I'm pretty sure that's not it - I talked with whot, and he said it was a known limitation in the implementation that he needs to fix :/
[10:14] <hyperair> RAOF: you mean the scroll-jamming is a known implementation?
[10:14] <hyperair> er known limitation
[10:14] <hyperair> that sucks =\
[10:14] <RAOF> Apparently so.
[10:15] <hyperair> is he around?
[10:15] <hyperair> i'd like to ask which value's overflowing
[10:15] <hyperair> perhaps we can have a hack in place to stop this from happening
[10:16] <RAOF> No, he's not.
[10:18] <RAOF> Why are gentoo users so *aggresively* ignorant when asking for help?
[16:00] <bryceh> RAOF, :-/
[16:00] <bryceh> sadly they're that way when giving help sometimes too...
[16:18] <mlankhorst> Ah ignorant helpers are even worse. :(
[16:57] <bryceh> cnd, posted reviewed-by to the xorg-devel list for that branch.
[16:58] <cnd> thanks!
[16:58] <cnd> I'm preparing an SRU of xorg-server right now
[16:58] <bryceh> cnd, I didn't spot anything that directly concerns me, it looks fine.  but it seems a lot of code to consider for sru'ing
[16:58] <cnd> yeah
[16:58] <cnd> they are all necessary though
[16:59] <cnd> they're the results of me seeing input lockups and such
[16:59] <bryceh> there's some changes which are just code refactors, and others (if I understand right?) enable functionality that wasn't functioning before.
[17:00] <bryceh> cnd, for getting it accepted into sru, if you  could elaborate on those bugs it might help in getting it approved
[17:00] <cnd> the code refactoring changes were required for subsequent fixes
[17:01] <cnd> I don't remember any new functionality
[17:01] <cnd> but I will be sure to provide a detailed summary of the change
[17:02] <bryceh> cnd, it's certainly possible I just misunderstood some comments as meaning it enabled functionality that wasn't working before
[17:06] <bryceh> 2efbed23 "When activating an explicit grab, update owning listener" I guess was the one that I wondered about being new functionality.
[17:09] <bryceh> cnd, anyway, other than that, good work!  hope the sru goes in smoothly.
[17:09] <cnd> bryceh, ahh yes
[17:09] <cnd> that is kinda new functionality, kinda bug fix
[17:09] <cnd> but without it, popup menus won't work
[17:09] <cnd> so if on a touchscreen you press on a gtk app menu
[17:09] <cnd> or in the menu bar
[17:10] <cnd> and you hold as the menu drops down
[17:10] <cnd> then you drag your finger down
[17:10] <cnd> without the change, the menu won't see the events
[17:10] <cnd> and you have to lift your finger and touch again to actually select an item
[17:10] <bryceh> ah, yeah that does sound like a bug fix.  Was it working previously or has it just never worked?
[17:11] <cnd> it was working previously because another bug was shadowing it :)
[17:11] <cnd> whot had been telling some folks that he thought it wasn't really fixable
[17:11] <cnd> some of the gtk devs had asked
[17:11] <cnd> so it's new functionality in that it wasn't a bug that was planned to be fixed :)
[17:11] <bryceh> interesting
[17:12] <bryceh> cnd, maybe just toss a sentence in the description like "Fixes broken popup menus, where they fail to..."
[17:13] <cnd> yeah
[17:13] <bryceh> do we have a bug # open for that?  if so link that in too.
[17:14] <bryceh> cnd, also, are all these patches together one bug fix, or do they address distinct problems?  I suspect if you can break it into several SRUs they'll go through the process faster than going in as one big lump
[17:14] <bryceh> but maybe chat up one of the SRU admins about that, maybe it doesn't matter (or would be more work than worth)
[17:15] <cnd> bryceh, I'm targeting them to bug 974887
[17:15] <cnd> I plan to note each patch individually to explain why it's needed
[17:15] <cnd> but in the packaging it will be one big squashed patch
[17:23] <bryceh> cnd, ok
[18:03] <bryceh> Sarvatt, what do you think the regression potential is for the SRU bug #968218 ?
[18:05] <jcristau> ha, reminds me of bugs.debian.org/660411
[18:06] <bryceh> jcristau, indeed, it's the same bug (and same patch).  thanks for the pointer
[18:06] <jcristau> you're not fixing that for the older releases?
[18:09] <jcristau> it's still somewhere on my to-do list to fix it in squeeze... (http://bugs.debian.org/661652)
[18:10] <bryceh> jcristau, looks like the SRU was proposed only for oneiric.  but if the issue is affecting earlier releases, would certainly make sense to sru it for those as well.
[18:11] <jcristau> it affects squeeze so presumably also lucid
[18:29] <cnd> argh!
[18:30] <cnd> why is the escape key mapped to "delete everything I just wrote in the bug description update"
[18:30] <cnd> I often hit escape out of habit because I'm a vi user
[18:30] <cnd> and I just lost a good 20 minutes of write up
[18:30] <jcristau> sometimes i do that with ^w
[18:36] <bryceh> Sarvatt, mind doublechecking my hackjob on your patch?  https://bugs.launchpad.net/ubuntu/+source/libxi/+bug/968218/comments/16
[18:36] <Sarvatt> bryceh: the upstream commit should apply directly?
[18:37] <jcristau> Sarvatt: not to lucid
[18:37] <jcristau> bryceh: http://anonscm.debian.org/gitweb/?p=users/jcristau/libxi.git;a=commitdiff;h=d33c64350c961e3b096565b30e1e98f7c9a569dc is what i had if that helps
[18:37] <jcristau> Sarvatt: (no touch / scroll stuff in XI 2.0)
[18:42] <bryceh> jcristau, thanks
[19:08] <cnd> bryceh, do you have a bug for the change you made to xorg-server for re-enabling patch 227?
[19:09] <cnd> or: how should we propose the SRU with the touch changes and that change?
[19:11] <bryceh> cnd, 930936 would be the bug
[19:14] <cnd> bryceh, how did it get disabled?
[19:16] <cnd> oh, it was never enabled...
[19:16] <cnd> d8e24bf6634b0ef80a21ac1d1b13412d88aa7800
[19:18] <cnd> oops
[19:18] <cnd> http://paste.ubuntu.com/937318/
[19:25] <cnd> bryceh, I've updated the bug report for the SRU
[20:08] <bryceh> cnd, ok thanks
[22:17] <Sarvatt> note to self: don't try cnd's crack jupiter ppa :)
[22:17] <cnd> Sarvatt, huh?
[22:17] <Sarvatt> pointer acceleration is all screwed up in 0ubuntu11~jupiter7
[22:17] <cnd> really?
[22:18] <cnd> I just uploaded to proposed
[22:18] <Sarvatt> moving 1 finger from top to bottom at a steady speed, the acceleration is all over the place
[22:18] <cnd> so if it's broken I need to fix it
[22:18] <cnd> Sarvatt, what device?
[22:18] <Sarvatt> bcm5974, macbook air 4,2
[22:18] <cnd> I don't have any issues here


[01:20] <xcyclist> Ubuntu kernel builds appear to put out a bunch of stuff, .deb files, .udeb files, and a .tar.gz file, that I don't see specified in a document accurately.  Is there a document I SHOULD  be reading, or can I help updating one that is old?
[01:20] <xcyclist> I have been using https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel, and for instance it says I should see 3 .deb files instead of dozens of files.
[01:20] <xcyclist> Please advise how I can be most helpful in either asking a question, reading other documents, or updating inaccuracies.
[01:31] <xcyclist> I apologize.  I lost my connection.
[07:13] <juergh> xcyclist, running 'fakeroot debian/rules binary' (from the wiki page you reference) simply does a build of the binary packages for your currently running architecture (which results in 3 debs). A full official build will result in a whole lot more packages: binaries for all the supported architecture, indep packages, source package, ...
[08:26] <apw> udebs for the installer and for x86 a signing tarball
[09:21] <tjaalton> sforshee: ping bug 1752507
[09:21] <ubot5`> bug 1752507 in linux-firmware (Ubuntu Artful) "add i915/glk_dmc_ver1_04.bin" [Undecided,New] https://launchpad.net/bugs/1752507
[10:01] <thresh> hello.
[10:05] <thresh> I'm on 4.13.0-36-generic, backported to 16.04, and see this crash/lockup ocasionnally: http://thre.sh/stuff/v05.crash.txt
[10:05] <thresh> does that sound similar to something already known?
[13:04] <sforshee> jjohansen, tyhicks: either of you have any ideas about this? https://paste.ubuntu.com/p/JBHVsV9SsZ/
[13:04] <sforshee> it's happening during adt, but only on ppc64el
[13:16] <tyhicks> sforshee: hey - what's being tested when that's happening?
[13:20] <sforshee> tyhicks: I don't think we know, cascardo?
[13:23] <cascardo> I am not sure, but it might be apparmor
[13:23] <tyhicks> that sounds reasonable
[13:23] <cascardo> or something way before that, cause we don't know exactly when it starts
[13:24] <tyhicks> it looks like something is testing/fuzzing the /proc/<PID>/attr/current interface
[13:25] <sforshee> the audit backlog messages start about 1.5 minutes later, possibly these two things aren't related
[13:27] <tyhicks> the "AppArmor: change_hat: ..." messages don't go through the audit subsystem
[13:27] <tyhicks> so they're unrelated in the sense that they're not causing the audit backlog issue
[13:28] <tyhicks> but it is still possible that AppArmor is generating the audit messages that are causing the audit backlog issue
[13:28] <cascardo> I would disagree
[13:28] <cascardo> [121737.681674] audit: type=1400 audit(1520969595.539:16276): apparmor="DENIED" operation="setprocattr" info="current" error=-22 profile="unconfined" pid=7572 comm="bash"
[13:28] <cascardo> but, yeah, I also agree that might be a red herring
[13:29] <tyhicks> cascardo: to be clear, I suspect that something is testing apparmor and apparmor is generating a bunch of audit messages
[13:30] <tyhicks> what problems is it causing? is the testbed failing because of this?
[13:30] <sforshee> tyhicks: the test does fail, we're not sure that it's related to all of those messages but it's one of the few leads we've got right now
[13:31] <sforshee> rather the vm seems to get hung somehow
[13:32] <sforshee> but I'm also now suspecting that it may be that a test is trying to suspend/resume the vm and that it's dying there
[13:33] <tyhicks> neither of those sets of error messages (the ones from AppArmor nor the ones from audit) indicate a dire situation that would take the vm down
[13:33] <tyhicks> they're error conditions for sure but they're handled error conditions
[13:34] <sforshee> ok, thanks tyhicks
[13:34] <cascardo> from my little experience with autopkgtest, sometimes the backend will look for the login prompt on the console
[13:34] <cascardo> and I thought that was the problem, that so many errors on the console would prevent it from finding it
[13:35] <cascardo> but maybe the nova backend is not that broken
[13:35] <tyhicks> that's possible
[13:35] <tyhicks> I'd argue that the apparmor error message is mostly useless and should go away
[13:35] <tyhicks> the audit message is important and can't go away
[13:35] <tyhicks> so, getting a clear console might not be possible
[13:36] <cascardo> that's okay
[13:36] <cascardo> I think the problem here is how it would generate that so many messages in that small amount of time
[13:36] <cascardo> when trying to sigstop auditd, I couldn't get that to happen even when writing to attr/current in a loop
[13:37] <tyhicks> huh, why is auditd running in the VM?
[13:37] <tyhicks> that's surprising to me
[13:37] <cascardo> I got a slightly different behavior as well, a "lost" message as well
[13:37] <cascardo> ah, I am not saying it was
[13:37] <tyhicks> oh, I see what you're saying
[13:37] <cascardo> that's just the only thing I thought would have caused those backlog messages
[13:38] <cascardo> like: there need to be an open auditd socket, right?
[13:38] <tyhicks> the audit subsystem forwards to the syslog when an auditd hasn't registered itself with the kernel
[13:39] <tyhicks> that's the default configuration on ubuntu
[13:39] <tyhicks> I would expect that the test runners would be in that configuration (auditd isn't installed by default)
[13:40] <cascardo> but how does it forward that? by the kernel log/printk only?
[13:40] <tyhicks> yeah, forwarding is in-kernel
[13:42] <cascardo> okay, so I got that same TAP13 message as from the ADT log
[13:46] <cascardo> right after running the step_after_suspend_test
[13:46] <cascardo> and my VM can't respond anymore
[13:46] <cascardo> what is supposed to be waking it up, by the way?
[13:46] <cascardo> and nothing seemed to have changed on that test, either from our last kernel or on the testing repos
[13:47] <cascardo> more likely, we broke suspend on ppc
[13:47] <apw> or worse we made it do something, and the wake up does not work
[13:48] <apw> i have this odd feeling we don't run those in adt in some sense
[13:49] <cascardo> I could just test it with the older kernel and see how it behaves
[13:49] <apw> yeah, the problem is we modify the kernel self tests etc to turn them off, and that can stop working
[13:49] <apw> has done before
[13:49] <cascardo> just have to set it up all over again, cause this openstack is broken
[13:50] <cascardo> I looked it up, we didn't just turn it on again recently
[13:50] <cascardo> so, it should have been running before
[13:50] <cking> hrm, i'm confused, I was sure it was disabled for x86
[13:50] <apw> cking thinks we haven;t turned it back on
[13:50] <apw> well this is ppc which is breaking on suspend
[13:50] <cking> maybe I'm mistaken, a lot changes around here
[13:50] <apw> so i am suspicious we should not be running it there either
[13:50] <apw> as an unrelaible to wake up test
[13:51] <apw> in a VM environment
[13:51] <cking> it maybe that the RTC wakeup is broken in a VM, or it the RTC wakeup is too short, or a bunch of other reasons
[13:52] <cascardo> hum... it was commented out on 4.15.0-10.11
[13:52] <cascardo> and clone didn't work on 4.15.0-11.12
[13:53] <sforshee> from a previous log which did run to completion, I don't see that test being run
[13:54] <sforshee><EMAIL_ADDRESS>[13:55] <cascardo> okay
[13:55] <cascardo> that file has changed
[13:55] <cascardo> and the sed line is not working anymore
[13:56] <cascardo> it's not a += anymore, it's a :=
[13:56] <sforshee> \o/
[13:56] <cascardo> I am fixing that on the testsuite, then will retrigger it
[13:57] <sforshee> awesome, thanks cascardo
[13:57] <cascardo> gotta make sure I write something that will work on new and old kernels
[13:58] <cascardo> thank you for making me look past the audit backlog thing
[14:02] <tyhicks> nice!
[14:03] <cascardo> now, let's hope the only problem we see is the kallsyms one
[14:04] <juergh> apw, can you please accept the nomination for #1755817?
[14:05] <cascardo> juergh: approved
[14:10] <juergh> cascardo, thanks
[15:06] <xcyclist> Thank you juergh.  Is there a document with the taxonomy of the different build combinations, both setups, and product files?
[15:12]  * apw doubts we have anything that detailed ... the intent of packages is one thing and one thing only to build in the defined debian/ubuntu build environment
[17:11] <sforshee> cascardo: your ppc64el retry finished, the only failure is the expected kernel_symbols_missing
[17:12] <sforshee> I'll add a hint for that, then we should be in good shape to promote
[17:45] <sforshee> apw: the testing for our bionic kernel is all in order but it looks like we need to clear NBS
[17:49] <apw> sforshee, i think i did that already, about 15:30 my time
[17:49] <apw> but as it is 17:50 i am suspicious
[17:50] <sforshee> apw: the adt matrix still shows it is NBS
[17:50] <apw> sforshee, hmmm, should be resolved there soon, cirtainly britney is now showing it only held by the bug
[17:51] <sforshee> ack, ta
[18:40] <cascardo> sforshee: thanks!