[00:24] <rackerhacker> jjohansen: i'm back with a linux-ec2 question if you're around ;)
[00:30] <jjohansen> sure
[00:30] <jjohansen> though I have a couple bugs against it, that I still have to look into
[00:31] <jjohansen> rackerhacker: ^
[00:36] <rackerhacker> ah, okay, that may be unrelated
[00:37] <rackerhacker> i git a git clone of the latest, picked up the ec2 branch, but the fdr doesn't generate debian.ec2/build any longer
[00:37] <rackerhacker> caught me a little off guard
[00:38] <jjohansen> rackerhacker: do an fdr clean first
[00:38] <rackerhacker> i did that... did a clean followed by a prepare-ec2
[00:38] <jjohansen> how about binary-ec2
[00:38] <jjohansen> or just binary
[00:38] <rackerhacker> hmm, i'll give that a try
[00:39] <rackerhacker> i think i owe you a case of beer for how much you've helped already ;)
[00:39] <jjohansen> warning on this kernel it seem there is an issue with it not booting Bug #527208
[00:39] <ubot3> Malone bug 527208 in linux-ec2 "ec2 instance fails boot, no console output on  c1.xlarge" [Medium,Confirmed] https://launchpad.net/bugs/527208
[00:39] <jjohansen> on c1.xlarge
[00:40] <rackerhacker> i'll go take a look at that one
[00:40] <jjohansen> hopefully we can get it cleaned up soon, just haven't gotten to it yet
[00:40] <rackerhacker> so far, it's been a rock solid kernel
[00:40] <rackerhacker> but i'm not using it at ec2 ;)
[00:41] <jjohansen> rackerhacker: glad to here its stable for you
[00:41] <jjohansen> I assume your using it as dom0
[00:42] <rackerhacker> domU actually
[00:42] <jjohansen> ah, just not on ec2
[00:42] <rackerhacker> i haven't tested it as a dom0 to be honest
[00:42] <jjohansen> me neither :)
[00:42] <rackerhacker> yeah, not on ec2... i work for a competitor
[00:42] <rackerhacker> you haven't tried it as a dom0?
[00:43] <jjohansen> nope, I have been to busy with other things
[00:44] <rackerhacker> i could imagine... that lucid release is coming up quickly
[00:44] <jjohansen> my focuses has been making sure it works for EC2, and then get back to other stuff
[00:44] <jjohansen> yep, frighteningly fast
[00:44] <rackerhacker> well i can certainly toss it around as a dom0 if that'd help you in the future
[00:44] <rackerhacker> 2.6.18 is getting old :/
[00:45] <jjohansen> rackerhacker: be my guest but I don't know that its something that will ever be supported again
[00:46] <rackerhacker> alrighty
[00:48] <rackerhacker> looks like fdr binary-ec2 just starts building it immediately
[00:50] <rackerhacker> these are the steps i had noted from you before -> http://pastie.org/private/k0uazxqyxrrj0ygsp6qcq
[00:53] <jjohansen> rackerhacker: yeah, the prepare isn't necessary if you are just looking to build
[00:53] <jjohansen> fdr clean followed by fdr binary-ec2 will do
[00:54] <rackerhacker> ah, i thought prepare was necessary to set up debian.ec2/build
[00:54] <jjohansen> build will do it if it doesn't find the prepare stamp
[00:54] <jjohansen> so it gets done, you just don't manually have to do it
[00:54] <jjohansen> I do it to update the version string etc
[00:55] <rackerhacker> ah, so dump my .config into the base directory and use binary-ec2?
[00:55] <jjohansen> nope
[00:55] <rackerhacker> sorry, i'm still new to the ubuntu way of doing this :/
[00:55] <jjohansen> if you are updating the config, you can either do
[00:55] <jjohansen> fdr editconfigs
[00:55] <jjohansen> and that will refactor configs etc
[00:55] <jjohansen> or you do a prepare
[00:56] <jjohansen> dump your new configs into build
[00:56] <jjohansen> and touch the stamps
[00:56] <jjohansen> you need to make sure to touch the stamps files in the build dir, other wise what you dump in there will get overwritten
[00:57] <rackerhacker> ah, i think the prepare route is the way i need to go
[00:57] <jjohansen> think standard make time based deps
[00:57] <jjohansen> yeah, if you are updating the configs and don't want to maintain a patch in git
[00:57] <jjohansen> the other option is doing fdr editconfigs
[00:58] <jjohansen> commit your config changes to your tree
[00:58] <jjohansen> and then when you fetch our tree rebase, so that your changes are applied over top
[00:58] <jjohansen> of course config changes will probably break you patch
[00:59] <rackerhacker> i didn't think of that... good idea
[01:00] <jjohansen> if you do that, you shouldn't need the separate prepare step
[01:03] <rackerhacker> awesome
[01:07] <jjohansen> rackerhacker: question, would us moving to a pv-ops based kernel for EC2 affect you?
[01:07] <rackerhacker> jjohansen: are you talking about dropping the ec2 patchset and making it more like the upstream?
[01:08] <jjohansen> rackerhacker: yep
[01:08]  * rackerhacker gasps
[01:08] <jjohansen> not saying it is going to happen, but it could
[01:08] <rackerhacker> hah, we're still using /dev/sda and tty1, so that'd be painful
[01:08] <jjohansen> we tried it with karmic and ran into some pretty serious problems we couldn't resolve
[01:09] <rackerhacker> i did a ton of testing with <IP_ADDRESS> w/pv_ops and had a lot of time skew issues
[01:09] <jjohansen> hrmm, I wasn't aware of time skew issues
[01:09] <rackerhacker> as much as 8 minutes after 3-4 days on that kernel
[01:10] <rackerhacker> we had to pull it due to the complaints and search for an alternative
[01:10] <jjohansen> hrmm, that is something I will have to try
[01:10] <rackerhacker> one of the canonical folks works for us now and he made the linux-ec2 suggestion
[01:11] <jjohansen> ah
[01:11] <jjohansen> well banging on pv-ops again and seeing if I can't make it work is on my todo
[01:12] <jjohansen> knowing issues, is a very good thing
[01:12] <rackerhacker> i think the most painful part for me is getting our customers off /dev/sda and tty1
[01:12] <rackerhacker> the xvda -> sda patch is simple, and it works fine
[01:12] <rackerhacker> but getting hvc0 out and using tty1 instead is rough
[01:13] <jjohansen> rackerhacker: I think atm we would be patching our kernels to use those as well
[01:13] <jjohansen> rackerhacker: if I get a kernel that looks like it is working I will point you at it
[01:14] <rackerhacker> jjohansen: i'll be happy to test for you
[01:14] <jjohansen> thanks
[01:14] <rackerhacker> and i might be able to get my company to get behind it with whatever's needed
[01:15] <rackerhacker> i need to get pvgrub rolling ;)
[09:28] <poolie> hi, i upgraded /backup on my lucid desktop to ext4 the other day
[09:28] <poolie> now it's getting io errors along the lines of
[09:28] <poolie> Feb 25 17:45:37 grace kernel: [37152.894557] EXT4-fs error (device dm-4): make_indexed_dir: invalid rec_len for '..' in inode 2933963
[09:28] <poolie> is anyone interested in debugging this, or should i just fsck and try to recover?
[09:29] <amitk> poolie: it might be worth it just to post your dmesg to a bug and post a link here
[09:30] <poolie> ok, will do
[09:38] <poolie> csurbhi/amitk, i filed https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/527644
[09:38] <ubot3> Malone bug 527644 in linux "lucid ext4  make_indexed_dir: invalid rec_len for '..' in inode" [Undecided,New]
[09:38] <poolie> let me know if you want any more info or if you have any suggestions
[09:38] <apw> apw
[09:38] <apw> apw_
[09:39] <apw> poolie, i assume you fskc'd it as part of the upgrade to ext4 ?
[09:39] <poolie> i did
[09:39] <poolie> only the one time recommended by the upgrade doc
[09:40] <poolie> during which it updates the checksums
[09:40] <apw> reasonable
[09:40] <poolie> i haven't changed those files since then though
[09:40] <poolie> they're unchanged since 20070706
[09:41] <apw> its somewhat supprising that the encoding of . and .. in a directory would be broke
[09:41] <poolie> i'm a bit concerned because i upgraded /home at the same time, perhaps foolishly
[09:42] <apw_> you have me concerned too, as i was about to do my rootfs
[09:43] <lifeless> poolie: did you run the example fsck flags?
[09:43] <poolie> -D etc, yes, of course
[09:43] <lifeless> poolie: the main thing it needs to rebuild is the new bitmaps; the directory tuning isn't needed as part of ext4
[09:43] <lifeless> poolie: [sometimes it pays to ask paranoid questions :P]
[09:44] <poolie> oh
[09:44] <lifeless> poolie: anyhow, that make_indexed_dir isn't part of the new ext4 features; it does sound alarming though.
[09:44] <poolie> actually I did not use -0
[09:44] <poolie> it sounds like an ext3 thing
[09:44] <apw_> # tune2fs -O extents,uninit_bg,dir_index /dev/sdb1
[09:44] <apw_> is that the one you turned on?
[09:45] <poolie> actually it was http://kernelnewbies.org/Ext4
[09:45] <poolie> so extents,uninit_bg,dir_index
[09:45] <poolie> and then fsck -CDf
[09:45] <lifeless> you probably had dir_index already, knoowing your machines
[09:46] <poolie> yes, i probably did
[09:47] <apw_> hrm, that would explain why you are the first to be mentioning it.  you should record that in the box
[09:47] <apw_> bug even
[09:48] <lifeless> apw_: I don't think its related; I *know* I had dir_index on - and nearly all ubuntu upgrades to ext4 will have had dir_index on.
[09:48] <lifeless> we turned it on by default about 4? years back
[09:48]  * apw_ checks his
[09:50] <apw_> Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
[09:52] <poolie> it's in /etc/mke2fs.conf or something
[09:52] <lifeless> apw_: looks about right to me
[09:58] <poolie> apw_: so i should probably leave and have dinner in a sec
[09:59] <poolie> if this is not just a glitch it seems like a bad bug so i'd like to help it get solved
[09:59] <poolie> is there anything else i can do?
[10:00] <lifeless> poolie: have you done another fsck? (just -f, no -D)
[10:00] <poolie> yes, see the bug
[10:00] <lifeless> poolie: ok, sorry :>
[10:00] <poolie> many errors, which it won't fix with -p
[10:00] <apw_> ok ... thanks for the report
[10:16] <lifeless> apw: can I run something by you ?
[10:16] <lifeless> when I run iotop
[10:16] <lifeless> I get 'CONFIG_TASK_DELAY_ACCT not enabled in kernel, cannot determine SWAPIN and IO %'
[10:18] <apw> yep, that one seemed to have a measurable cost i think
[10:19] <lifeless> ><
[10:19] <lifeless> is there a kernel with it on ? was very useful for figuring out what apps are being bad
[10:20] <lifeless> the other thing is, do we build debug packages for the kernel? for use with oprofile?
[10:20] <lifeless> years ago I filed a bug asking for this, and we started, but I can't seem to find them now...
[10:22] <apw> i don't think we have a kerel with it on no
[10:22] <apw> the debug packages are in the ddebs.ubuntu.com archive
[10:26] <lifeless> apw: ok cool
[10:26] <lifeless> thanks
[10:26] <lifeless> apw: you might want to close the bug I opened about DELAY_ACCT then :>
[10:27] <apw> there was some discussion about it on kernel-team, not sure if it got bottomed out on or not
[12:29] <jxiong> hello
[12:29] <jxiong> folks, I spent several hours to try to find the vmlinux file for my laptop
[12:29] <jxiong> do you have any ideas?
[12:29] <jxiong> Linux ubuntu 2.6.31-19-generic #56-Ubuntu SMP Thu Jan 28 02:39:34 UTC 2010 x86_64 GNU/Linux
[12:30] <nigel_c> Should be in /boot/vmlinuz-<IP_ADDRESS>-generic
[12:30] <smb> jxiong, Have you tried ddebs.ubuntu.com ? There should be ddeb packages for kernels
[12:30] <jxiong> smb: yes, I tried.
[12:31] <jxiong> it doesn't include something like linux-image-XXX-debug/dbgsym..
[12:32] <nigel_c> apt-file search /boot/vmlinuz-<IP_ADDRESS>-generic?
[12:34] <jxiong> nigel_c: thank you, what I'm searching for is vmlinux, which includes debug info
[12:35] <jxiong> vmlinuz is an executable image, it's a compressed binary code
[12:38] <nigel_c> I'm pretty sure all the Ubuntu kernels have the config options enabled that include debugging info, so you should just be able to run gdb on any vmlinux. Vmlinuz is just the same thing gzipped IIRC.
[12:39] <smb> As the pre-compiled seem to have vanished again, the only way seems to "apt-get source ..." the linux-image source and the compile it yourself :(
[12:41] <jxiong> what a pity
[13:17] <apw> Keybuk, hey ... i am struggling to get you the page numbers for pages you don't have mapped
[13:18] <apw> ie. as you don't have the pages actually present in ureadahead you don't have the pfn numbers so you don't have the pfn's to lookup kpageflags
[13:18] <Keybuk> apw:  how do you mean?
[13:18] <Keybuk> mmap maps the pages, no?
[13:18] <apw> no they are not present as you have never referenced them
[13:19] <apw> so you don't have them in your pagemaps to map ... blah
[13:19] <apw> now i think i have a different way round this
[13:19] <apw> i think i can return the additional info in the mincore result
[13:19] <apw> which brings me to the fact i think you have  a bug in your mincore use
[13:19] <apw> as you for if (!vec[x])
[13:20] <apw> but the manual says you can't do that, you can only rely on the value of bit 0
[13:20] <apw> i suspect returning that information in mincore would be pretty handy for you
[13:20] <apw> but ... it does rely on all users of mincore reading the manual page
[13:21] <apw> Keybuk, what do you think
[13:22] <Keybuk> sounds reasonable
[13:23] <Keybuk> someone changed the mincore() manpage <g>
[13:23] <apw> that interface seems to only allow me to return very small amounts of info, no more than a few bits, which makes it hard to return anything more than 'used/unused'
[15:46] <manjo> apw, http://voices.canonical.com/kernelteam/
[15:46] <manjo> smb, http://voices.canonical.com/kernelteam/
[15:57] <apw> Keybuk, hey how is that plymouth race the one which leads to 'return' being fatal ... who has that?
[15:57] <Keybuk> I have the ball on that one
[15:57] <Keybuk> though it's your fault, you and your buggy kernel
[15:58] <apw> excellent ... whats wrong with my beautiful kernel :)
[15:59] <smb> apw, apparently sound
[16:03] <manjo> \http://www.sonystyle.com/webapp/wcs/stores/servlet/ProductDisplay?storeId=10151&catalogId=10551&langId=-1&productId=8198552921665974276
[16:06] <cnd> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ec67bbedcf290ef182a897017f65a2707106c7f8
[16:17] <tjaalton> cnd: probably needs the other two commits for 1.52 as well?
[16:19] <apw> then its probabally too big for lucid
[16:19] <cnd> tjaalton: I'm going to try to build a module with just that commit to see if it works
[16:19] <cnd> but yeah, that commit alone is pretty huge
[16:20] <tjaalton> this one looks quite sensible to me
[16:20] <tjaalton> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=232f5693e5c9483e222528ef81979e42ea2f2908
[16:22] <cnd> tjaalton: we tend to just backport fixes, so unless this fixes a bug people are having we probably won't backport it
[16:22] <tjaalton> sooner or later they will ;)
[16:23] <cnd> cnd, it may, but it may also introduce more issues
[16:23] <apw> linux-image-2.6.32-15-generic-debug_2.6.32-15.21~ddebrenameapw1_i386.ddeb
[16:23] <apw> smb, ^^
[16:23] <cnd> so we have to be judicious
[16:26] <tjaalton> that patch needs at least this one http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ec67bbedcf290ef182a897017f65a2707106c7f8
[16:26] <tjaalton> or manual backporting, of course
[16:26] <cnd> tjaalton: yes, that's the same that I posted above
[16:27] <tjaalton> uh, damn
[16:27] <cnd> I'm going to build a module with just that commit
[16:27] <tjaalton> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ee54500d7b960984df125bdd0cd2105d6150e8f1
[16:27] <tjaalton> this one
[16:27] <cnd> tjaalton: I assume you have hw for this?
[16:27] <tjaalton> no
[16:27] <tjaalton> well, I have an intuos4
[16:27] <tjaalton> but not the new stuff
[16:27] <cnd> tjaalton: would you mind testing a module if I get one built?
[16:27] <tjaalton> cnd: sure
[16:28] <apw>   INSTALL debian/-generic/usr/lib/debug/lib/firmware/yam/1200.bin
[16:28] <smb> seems to be missing somethign
[16:28] <cnd> tjaalton: please subscribe to bug 516777, I'll post the stuff there
[16:28] <ubot3> Malone bug 516777 in linux "HP Touchsmart tm2 requires newer wacom driver" [Low,Triaged] https://launchpad.net/bugs/516777
[16:30] <tjaalton> cnd: you mean to test it doesn't break mine?
[16:30] <cnd> tjaalton: yes
[16:30] <cnd> I'll post a test module to that bug
[16:30] <tjaalton> cnd: right, might as well upgrade the desktop to lucid then (and test that suspend thing :)
[16:37] <bjf> smb, ring me back please
[17:08] <cnd> smb, tjaalton, apw: test module is up at http://people.canonical.com/~cndougla/516777/wacom.ko
[17:22] <Keybuk> apw: am I missing something here?
[17:22] <Keybuk> the mainline 2.6.33 build is missing devtmpfs
[17:22] <manjo> smb, apw cnd I am dropping off
[17:24] <apw> Keybuk, ahh ... its beacuse its being built on karmic ...
[17:25] <Keybuk> apw: FAIL
[17:25] <apw> well it depends what you think they are for
[17:25] <apw> originally they were for testing on karmic... what it highlights is we need them to be built for both
[17:26] <apw> or ... more specifically ... they are built for one ... which one needs to be part of that information
[17:27] <Keybuk> happily it proves you can still boot lucid without devtmpfs <g>
[17:28] <apw> yeah just about, slow as hell mind
[17:28] <apw> i'll have a think about what we should be doing there over beer tonight
[17:28] <apw> i don't want to have to build them all twice, that would suck
[17:31] <cnd> smb, tjaalton, apw: http://people.canonical.com/~cndougla/516777/i386/wacom.ko if you need it
[17:32] <cnd> http://people.canonical.com/~cndougla/516777/amd64/wacom.ko for amd64 (I moved it)
[17:33] <smb> cnd, Sorry to be wincing. The i386 is for 2.6.31-13... :(
[17:33] <cnd> smb: what?
[17:34] <cnd> grrr... how did that happen
[17:36] <smb> ok, its 2.6.32-13
[17:41] <cnd> smb: should be better now
[17:41]  * smb looks
[17:59] <Keybuk> apw: if I want to apply a patch to one of your mainline linux-source packages
[17:59] <Keybuk> what do I have to do to stop the ABI checker eating me?
[18:00] <apw> the mainline builds i think they are disabled in there
[18:01] <apw> check the check-abi script to see whats in it
[18:01] <Keybuk> ok
[18:01] <Keybuk> http://people.freedesktop.org/~glisse/0001-drm-radeon-kms-initialize-set_surface_reg-reg-for-rs.patch
[18:01] <Keybuk> this may end up on kernel-team if it works
[18:07] <Keybuk> apw: argh
[18:07] <Keybuk> in fact
[18:07] <Keybuk> where *IS* the source package for mainline builds?
[18:07] <apw> supposed to be with them
[18:07] <Keybuk> isn't
[18:07] <Keybuk> http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.33/
[18:08] <apw> there is a 64mb source package there
[18:08] <Keybuk> no there isn't
[18:08] <Keybuk> there's no .dsc or .tar.gz
[18:08] <Keybuk> there's a deb that contains a tarfile
[18:08] <Keybuk> but that *does not contain the debian directory or the config*
[18:08] <apw> it doesn't ?
[18:08] <Keybuk> no
[18:09] <apw> well just checkout the one in our git tree into it
[18:09] <Keybuk> example command?
[18:09] <toabctl> hi
[18:09] <toabctl> can anybody help with bug #527912 ?
[18:09] <ubot3> Malone bug 527912 in xf86-input-wacom "Wacom Bamboo CTH-661 not recognized" [Undecided,New] https://launchpad.net/bugs/527912
[18:09] <apw> git checkout origin/master debian debian.master
[18:09] <Keybuk> apw: there's no .git either
[18:10] <apw> so copy the debian* out of the lucid git tree
[18:11] <Keybuk> will that work?
[18:11] <Keybuk> all the changelog and versions and abis will be all wrong
[18:11] <Keybuk> and it'll vomit the install
[18:11] <apw> do you need that patch in .33 or in lucid ?
[18:11] <Keybuk> I need to test the patch
[18:11] <apw> if you want me to build you one
[18:12] <Keybuk> I'm going to try and build off lucid
[18:12] <Keybuk> that seems easiest
[18:12] <Keybuk> I know how to do that <g>
[18:12] <apw> yeah probabally is :)
[18:13] <apw> toabctl, which release are you runningn
[18:13] <toabctl> apw, lucid
[18:13] <toabctl> apw, there changed something with wacom drivers
[18:13] <apw> did it work before on karmic?
[18:14] <toabctl> apw, i don't now. the board is 2 days old:)
[18:14] <apw> so it may not be a supported version then
[18:14] <apw> what usbid's does it have
[18:14] <toabctl> apw, how can i get the usb id?
[18:15] <apw> lsusb
[18:15] <toabctl> apw, i think it should work with http://linuxwacom.sourceforge.net/index.php/main but this drivers only support xserver <= 1.6
[18:15] <toabctl> apw, Bus 001 Device 010: ID 056a:00d3 Wacom Co., Ltd
[18:16] <toabctl> apw, where's the place to find the usb-id <-> driver mapping?
[18:17] <tjaalton> toabctl: the thing is that the X driver isn't being loaded for the device
[18:18] <toabctl> tjaalton, and how can i fix this? maybe the driver supports the board...
[18:18] <tjaalton> udevadm info --export-db
[18:18] <tjaalton> attach that to the bug
[18:19] <tjaalton> (need to add an apport hook for xf86-input-wacom)
[18:19] <apw> tjaalton, we probabally should get that for kernel bugs too
[18:20] <toabctl> tjaalton, added: see http://launchpadlibrarian.net/39785696/udevadm_info.txt
[18:20] <tjaalton> apw: yeah
[18:21] <apw> tjaalton, so does X input handle those direct?
[18:21] <tjaalton> apw: via udev, yes. but they also need the kernel module for fancy features
[18:22] <tjaalton> toabctl: thanks
[18:22] <apw> ok ... so it may or may not work
[18:22] <tjaalton> I need to check the list for bamboo
[18:22] <tjaalton> toabctl: has it ever worked?
[18:22] <toabctl> tjaalton, no. i got it 2 days ago
[18:23] <toabctl> tjaalton, but there are comments on the web that i worked with karmic
[18:23] <tjaalton> huh, ok
[18:24] <tjaalton> but it's a different driver on lucid, so something might be missing
[18:24] <toabctl> tjaalton, the problem is (i think), that the wacom stuff changed completely with lucid (see alpha-2 release notes)
[18:24] <tjaalton> like the udev rules for it
[18:24] <tjaalton> oh really? :)
[18:24] <tjaalton> (I know)
[18:24] <toabctl> tjaalton, yes. hopefully just a udev rule is missing :)
[18:26] <toabctl> tjaalton, the device is available in the output of udevadm. but what can i do now?
[18:28] <tjaalton> toabctl: just wait for now
[18:29] <toabctl> tjaalton, how long ?:-)
[18:29] <bjf> toabctl, if it was working in karmic and you need the tablet, run karmic
[18:30] <tjaalton> it doesn't have any ID_INPUT* stuff listed, so figuring out why input_id is not run
[18:30] <bjf> toabctl, keep testing lucid alpha/beta releases and see when it gets fixed
[18:30] <toabctl> bjf, i don't need the tablet. i'll give it back if it will not work in 2 weeks.
[18:30] <toabctl> bjf, but i like to find out if it's possible that the tablet does the job.
[18:31] <tjaalton> toabctl: could be that the kernel doesn't know it yet, otherwise it should be in the input subsystem I think
[18:31] <bjf> toabctl, you could try a karmic live-cd image and see if it works
[18:32] <manjo> JFo, bjf, applied you kernel-qa / tests patch and I implemented progress bar
[18:32] <manjo> JFo, bjf I will check in soon
[18:33] <JFo> ok
[18:36] <toabctl> tjaalton, in /lib/udev/rules.d/69-xserver-xorg-input-wacom.rules is no line for the id 056a:00d3 . maybe that's the problem? i don't know much about udev rules..
[18:36] <tjaalton> toabctl: check bug 522318, there are new rules for a similar case where the subsystem is 'pnp'
[18:36] <ubot3> Malone bug 522318 in xorg-server "Serial Tablet PCs not supported in lucid" [Medium,Fix committed] https://launchpad.net/bugs/522318
[18:36] <tjaalton> toabctl: partly correct
[18:37] <tjaalton> toabctl: I'll add something to the bugreport for you to try..
[18:37] <toabctl> tjaalton, ok. thx
[18:52] <tjaalton> toabctl: yeah I don't think wacom supports it yet, properly anyway. can't find the id from wacom_wac.c
[18:52] <tjaalton> toabctl: is it the "pen & touch"
[18:52] <tjaalton> ?
[18:53] <toabctl> tjaalton, yes. pen & touch
[18:53] <toabctl> tjaalton, some people say it works: see http://aur.archlinux.org/packages.php?ID=31540
[18:54] <tjaalton> ok, those patches are not upstream then
[19:03] <tjaalton> toabctl: there's a huge thread on linuxwacom-discuss about it
[19:04] <toabctl> tjaalton, can give paste me a link ?
[19:04] <tjaalton> the support might be in linuxwacom, but not yet in xf86-input-wacom..
[19:04] <toabctl> tjaalton, and why does ubuntu no more supports linuxwacom?
[19:05] <tjaalton> toabctl: because it doesn't work with xserver 1.7
[19:05] <toabctl> and where is the source of xf86-input-wacom? the source package has as homepage http://linuxwacom.sf.net
[19:05] <tjaalton> xf86-input-wacom is the way forward
[19:05] <tjaalton> http://linuxwacom.git.sourceforge.net/git/gitweb.cgi?p=linuxwacom/xf86-input-wacom;a=summary
[19:07] <toabctl> tjaalton, in the git repository is xf86-input-wacom-0.10.4 available, but the ubuntu packages has 0.10.3
[19:08] <tjaalton> right
[19:08] <tjaalton> the driver itself support it, as it turns out
[19:08] <tjaalton> but not the kernel component
[19:08] <cnd> bdmurray: re the wacom stuff, which arch did you test?
[19:09] <bdmurray> amd64
[19:09] <tjaalton> toabctl: maybe best to continue on ubuntu-x ->
[19:09] <manjo> bjf, I pushed your changes and added progress indicator to copying log files
[19:09] <manjo> JFo, ^^
[19:09] <toabctl> tjaalton, i asked on ubuntu-x, but nobody answered.
[19:09] <JFo> cool, thanks manjo
[19:10] <tjaalton> toabctl: because you were having the discussion here already :)
[19:11] <toabctl> ok. switch talk to #ubuntu-x
[19:13] <cnd> bdmurray: can you paste uname -a?
[19:15] <bdmurray> Linux artemis 2.6.32-14-generic #20-Ubuntu SMP Sat Feb 20 05:18:19 UTC 2010 x86_64 GNU/Linux
[19:16] <bjf> manjo, two thoughts...
[19:16] <cnd> apw, smb, do you know what would cause this when running insmod: wacom: no symbol version for module_layout
[19:16] <bjf> manjo, one: I'd like to see all the log collection in a single function so it's real obvious where the log collection is happening
[19:17] <manjo> bjf, did you see the changes I made after yours ?
[19:17] <bjf> manjo, yes
[19:17] <smb> cnd, I assumed it was my non-standard kernel. I would say it requires and external function module_layout
[19:17] <manjo> so copy_files() does all the copying ie log collection ..
[19:17] <cnd> smb, could it be because I didn't build the whole kernel?
[19:18] <cnd> just the drivers/input/tablet directory?
[19:18] <smb> cnd, It might be
[19:18] <bjf> manjo, no copy_files does the copy and the ui, I'd like to see the calls to copy_files in a single function "capture_logs" or some such
[19:18] <manjo> ?
[19:19] <cnd> smb, bdmurray: I'm going to try to rebuild the entire kernel and put up the resulting kernel, let's see how well that works
[19:19] <bdmurray> cnd: okay
[19:19] <apw> cnd it may well be yes.  its something modpost makes
[19:19] <smb> cnd, you still might be able to just put up the module
[19:19] <apw> scripts/mod/modpost.c:          mod->unres = alloc_symbol("module_layout", 0, mo
[19:19] <bjf> manjo, lines 251 - 260
[19:19] <cnd> smb, yeah, that's what I plan
[19:19] <smb> cnd, I guess you just need the full compile to get a version function
[19:19] <smb> versioned function
[19:20] <manjo> bjf, oh ic
[19:20] <manjo> bjf, send me a patch
[19:20] <manjo> bjf, I think that is a good point
[19:20] <bjf> manjo, actually I'm thinking I'd like the log and system information captured in a separate script which I could call without having to run the test
[19:20] <bjf> manjo, what do you think of that?
[19:21] <bjf> that may not have been very clear
[19:21]  * manjo thinking ...
[19:21] <manjo> we can have it in a separate script
[19:22] <manjo> and source that script and use the function in kernel-qa as well
[19:22] <bjf> manjo, the copy is happening at the very beginning,
[19:22] <manjo> so in kernel-qa you could do source new_script
[19:22] <bjf> hmmm
[19:23] <manjo> in case we want to use copy_files() anywhere
[19:23] <bjf> manjo, I'm running it right now and the progress bar has "[sudo] password for bradf:" in it
[19:23] <manjo> yeah you are supposed to run sudo ./kernel-qa
[19:23] <manjo> bjf, just type your passwd
[19:24] <manjo> bjf, this is coz we have a sudo less environment usually
[19:26] <manjo> bjf, I am also thinking of adding a function like ... exec_with_progress() .. so you can call it like exec_with_progress "somecmd parameters"
[19:26] <bjf> manjo, if you put a "sudo date" before the first "copy_files" then the user is prompted for the password before the dialog comes up
[19:26] <manjo> from the test case
[19:26] <manjo> bjf, no I should ask for the password in a dialog box
[19:27] <manjo> bjf, and I know how to do that
[19:27] <manjo> bjf, I did not do it coz we have passwd less env... but that is not good if we want to have it generic
[19:27] <bjf> manjo, why do you need to ask for it in a dialog box?
[19:28] <manjo> bjf, so if you run ./kernel-qa it will ask for your passwd
[19:28] <manjo> or kernel-qa needs to be installed with uid root
[19:29] <bjf> manjo, yes, and if you'd just put the "sudo date" as the first thing you get to type in your password and then the ui comes up
[19:29] <bjf> it's simple
[19:29] <manjo> ok
[19:30] <manjo> bjf, dialog --passwordbox does it in a fancy way
[19:31] <bjf> manjo, I was looking at some bugs and I've noticed that checkbox is gathering hw information in an interesting way that we might look at
[19:32] <manjo> bjf, :) we might just recreate checkbox finally
[19:32] <bjf> manjo, not intereted in that however, the hwinformation did look interesting, just a sec I'll get you a bug #
[19:33] <manjo> bjf, I know what you are taking about
[19:33] <manjo> bjf, hwinfo and pciutils are not installed by default on servers for example
[19:33] <manjo> bjf, and its painful to deal with it coz checkbox croaks
[19:33] <manjo> bjf, not that I am agianst the idea of looking into it ... just letting you know
[19:34] <bjf> manjo, then I don't think you know what I'm talking about
[19:34] <manjo> ok]
[19:34] <manjo> point me to bug please
[19:34] <bjf> manjo, bug 399319
[19:35] <ubot3> Malone bug 399319 in checkbox "Remove the HAL dependency from Launchpad HWDB and checkbox " [Medium,Fix released] https://launchpad.net/bugs/399319
[19:36] <bjf> manjo, they are processing "udevadm info --export-db" and "grep -r . /sys/class/dmi/id/ 2>/dev/null" and "devkit-disks --dump"
[19:36] <manjo> bjf, udevadm info --export-db
[19:36] <manjo> yep we can have that
[19:37] <manjo> they changed to it after me bitching about it for 1yr
[19:37] <bjf> manjo, but I think you want to look at how checkbox does it because I believe he combines it all into an xml file and submits it as a single xml blob
[19:38] <bjf> manjo, I'd like to get it in the exact same format
[19:38] <manjo> bjf, sure, you want to do it :)
[19:41] <bjf> manjo, I'll look into it, it won't get done right away
[19:41] <manjo> sure, I don't understand fancy langs like xml
[19:41] <bjf> manjo, I was looking at it last night and his code is shit to follow
[19:41] <manjo> :) lol
[19:42] <manjo> bjf, I have had to ceal with it for 1.3yrs now
[19:42] <manjo> deal
[19:42] <manjo> bjf, and I am no way python expert
[19:43] <manjo> bjf, its more fun when it blows up in front of imp people ... and you are scrambling to fix it
[19:44] <manjo> apw, you still around ?
[19:48] <manjo> apw, I have an aspire one that boots from USB stick to a blinking cursor :)
[20:13] <cnd> bdmurray: still around? can you test out the amd64 wacom module?
[20:13] <cnd> I just uploaded a new one to the same location
[20:14] <bdmurray> cnd: yes, testing
[20:17] <bdmurray> cnd: works great!
[20:17] <cnd> bdmurray: it both loads AND it works for your wacom tablet?
[20:17] <bdmurray> cnd: yes
[20:18] <cnd> bdmurray: great! please log your results in the bug
[20:18] <cnd> I still don't know whether we'll be able to put it into lucid, we'll at least need more testing
[20:18] <cnd> cause the changes are rather expansive
[20:18] <cnd> but we can look into other options if not
[21:14] <LLStarks> apw, quick question. why isn't the kernel ppa an actual ppa?
[21:42] <cnd> LLStarks: apw is likely gone for the day, which ppa are you referring to?
[21:42] <LLStarks> the mainline kernel ppa
[21:45] <cnd> LLStarks: hmmm... I'm guessing the reason is that no one ever really runs it as a ppa?
[21:45] <cnd> I'm not really sure
[21:45] <LLStarks> that would save me 4 wgets and dpkgs
[21:46] <LLStarks> well, manual operations.
[22:00] <cnd> LLStarks: why four?
[22:00] <LLStarks> headers. image. generic.
[22:00] <Q-FUNK> hi!
[22:01] <LLStarks> headers all.
[22:01] <LLStarks> wait.
[22:01] <LLStarks> damn.
[22:01] <LLStarks> headers. header generic. source. image.
[22:01] <cnd> oh, yeah
[22:02] <cnd> LLStarks: do you run mainline all the time?
[22:02] <LLStarks> not always.
[22:02] <LLStarks> breaks things from time to time.
[22:02] <Q-FUNK> what kernel .config option do I need to have root=UUID work on cmdline?   I'm attempting to build my own minimal kernel as a test to debug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/396286
[22:02] <ubot3> Malone bug 396286 in linux "[Geode LX] [OLPC] 2.6.31-generic: kernel panic near the end of initramfs" [High,In progress]
[22:06] <cnd> Q-FUNK: if you are doing testing, it may be easier to just use root=/dev/sd??
[22:06] <cnd> instead of using UUID
[22:06] <cnd> unless the UUID is particular to that bug
[22:07] <Q-FUNK> cnd: it works with that, but then I constantly have to manually fix menu.lst
[22:07] <mjg59> Also, the kernel doesn't parse that
[22:07] <cnd> Q-FUNK: ahhh, have you looked at the differences between your kernel config and the ubuntu kernel config?
[22:08] <cnd> that may tell you
[22:08] <Q-FUNK> mjg59: doesn't parse what?
[22:09] <mjg59> Q-FUNK: root=uuid
[22:09] <cnd> mjg59: it parses something like root=UUID=299e7785-7c3d-4e90-9779-239cb237a4d2
[22:10] <mjg59> Fairly sure that's done by initramfs
[22:10] <Q-FUNK> mjg59: ok.  does ubuntu have a magic hack that converts something like root=UUID=299e7785-7c3d-4e90-9779-239cb237a4d2 to what the kernel expects?
[22:11] <cnd> mjg59: yes, you're right
[22:11] <cnd> Q-FUNK: how are you building your kernel?
[22:11] <mjg59> Q-FUNK: No, it just does it itself
[22:12] <mjg59> Which means it probably won't work unless you build with a ramdisk
[22:12] <Q-FUNK> kernel-package, with the option --initrd
[22:13] <cnd> Q-FUNK: I'm not too familiar with using kpkg, unfortunately
[22:14] <cnd> I build kernels through the process described at: https://wiki.ubuntu.com/KernelTeam/KernelMaintenanceStarter
[22:14] <cnd> someone else may be able to help you with kpkg
[22:42] <mjg59> Which means it probably won't work unless you build with a ramdis4
[22:42] <mjg59> Oops.
[22:49] <Q-FUNK> ogasawara: seems that I have a winner.  something that gets included in the initrd.img is what causes https://bugs.launchpad.net/ubuntu/+source/linux/+bug/396286
[22:49] <ubot3> Malone bug 396286 in linux "[Geode LX] [OLPC] 2.6.31-generic: kernel panic near the end of initramfs" [High,In progress]
[22:50] <Q-FUNK> only, I have no idea what exactly.
[22:51] <mjg59> Q-FUNK: Hack initramfs-tools and add set -x to the top of it in order to see what's executing and when?
[22:51] <Q-FUNK> mjg59: that sounds like a plan.  let's see if I can find the right file to hack for this.
[22:58] <lifeless> there is a verbose mode
[22:58] <lifeless> update-initramfs -u -v
[23:38] <Q-FUNK> ogasawara: bug report updated.  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/396286  hopefully smb can make something out of it. :)
[23:38] <ubot3> Malone bug 396286 in linux "[Geode LX] [OLPC] 2.6.31-generic: kernel panic near the end of initramfs" [High,In progress]


[00:00] <Resistance> its pending builds in a PPA (I confirmed a build in pbuilder)
[00:00] <Resistance> before I can test
[00:00]  * Resistance grumbles something about nobody caring to read things in depth
[00:00] <micahg> Resistance: bug fixes really should be cherry picked (yes we can backport the new feature release, but then not everyone benefits)
[00:01] <Resistance> micahg:  this was cherry-picked initially, geser discussed this one with me, and the bug fix was fixed in Quantal, but an SRU wasnt likely to be supported (according to cjwatson) and geser stated he'd support a backport from Quantal if the fix is in Quantal
[00:01] <Resistance> if it were up to him
[00:01] <Resistance> so the problem is whether or not this is going to be fixed
[00:01] <micahg> Resistance: is there an actual patch?
[00:01] <Resistance> negative, the fix was only able to be applied in an upstream version
[00:01]  * micahg sees discussions of new versions, but no evidence of a patch
[00:01] <Resistance> hence why cjwatson stated an SRU wasn't viable
[00:02] <Resistance> micahg:  read changelogs on the source package
[00:02] <Resistance> and the sync request
[00:02] <Resistance> (which i filed)
[00:02] <Resistance> https://bugs.launchpad.net/ubuntu/+source/boinc/+bug/998195
[00:03] <Resistance> that was fixed within Quantal, but i also don't have the patch (since it seems that this was fixed upstream, with a new version, with no real patch)
[00:03] <Resistance> i could emial the debian maintainer, but cjwatson looked at the bug at my request and said it'd unlikely be SRU'd (because of version change)
[00:04] <Resistance> like the znc package, they dont release patches to fix things
[00:04] <Resistance> (one of the reasons i hate that package, really)
[00:07] <micahg> Resistance: hmm, if I throw up a build disabling a patch in the precise version, can you try it?
[00:07] <Resistance> micahg:  if i can finish beating this system out of segving, sure
[00:08] <Resistance> (its segving in Perl, and i cant figure out whether its the program/script or perl itself)
[00:09] <Resistance> meh,s crew it
[00:09] <Resistance> micahg:  which repository would it end up in
[00:09] <Resistance> main / universe, or proposed?
[00:09] <micahg> Resistance: -updates after SRU verification
[00:10]  * micahg is uploading to a PPA ATM though
[00:11] <Resistance> actually...
[00:11] <Resistance> it seems something went screwy...
[00:11]  * Resistance cant access his Seti@Home account to test
[00:11] <micahg> meh, how did this build in the first place
[00:11] <Resistance> micahg:  they did change it so it builds with gcc 4.7 (a different debian bug, that was also fixed)
[00:11] <Resistance> and tbh, idk
[00:12] <micahg> no, I mean the patches don't apply
[00:12] <Resistance> wait, really?
[00:12] <Resistance> they applied on my end here :/
[00:12] <Resistance> last i checked anyways
[00:12] <Resistance> hmm
[00:12] <Resistance> you know what, i hate PPAs
[00:12] <Resistance> there's a 5 hour wait on my ppa builds
[00:12] <Resistance> :/
[00:13] <micahg> Resistance: you get what you pay for :P
[00:14] <Resistance> micahg:  i may as well just set up a debian repository locally :/
[00:14] <micahg> Resistance: apt-cacher-ng + sbuild FTW
[00:14] <micahg> ah, the patch is stacked, let me refresh it
[00:16]  * Resistance yawns
[00:16] <Resistance> well, i guess its time for another coffee run
[00:17] <Resistance> oh, micahg, i've got to poke you about bugsquad bug policies on Importance, a potential definition for "core" vs. "non-core" seems to have surfaced (but only two or three people have weighed in)
[00:18] <micahg> yeah, I"ll respond at some point as well
[00:19] <Resistance> well including my weighing in, the potential option we have on the table is define "core" as part of one of the default flavor packages, i.e. ubuntu-desktop, kubuntu-desktop, etc.
[00:19] <Resistance> but that's only one potential definition
[00:19] <micahg> backportpackage is being funny: 7.0.24+dfsg-1ubuntu0.1~ubuntu12.04.1~ppa1
[00:19] <Resistance> lool...
[00:19] <Resistance> lol*
[00:19] <micahg> Resistance: should hopefully build in ppa:micahg/sru-test at some point
[00:19] <Resistance> that is funny xD
[00:20] <Resistance> what did you set the urgency to, "low"?
[00:20] <Resistance> if so, my PPA's'll build long before yours
[00:20]  * micahg doesn't bother setting the urgency, let the queue do its thing
[00:21] <Resistance> yeah, mine'll build first then, unless somehow you got higher priority
[02:29] <bregma> do package updates in Debian get automatically synced to Ubuntu (assuming no changes) or is a sync request required?
[02:29] <LordOfTime> bregma:  syncs happen periodically on the dev release, but sometimes a sync request is needed.
[02:30] <micahg> bregma: with no Ubuntu changes, a sync request isn't needed until after Debian Import Freeze unless there's a reason
[02:30] <LordOfTime> ah, right
[02:30] <LordOfTime> :P
[02:30]  * LordOfTime forgot about freezes
[02:30] <LordOfTime> micahg:  check -bugs, please
[04:15] <bkerensa> micahg: do we/can we update packages that we sync from debian?
[04:15] <bkerensa> instead of waiting for debian to update the package?
[04:16] <micahg> bkerensa: yes, but if possible, better to work with the Debian maintainer to accomplish that goal if you care about it saying up to date
[04:16] <micahg> s/saying/staying/
[04:17] <bkerensa> kk
[12:17] <geser> has someone an idea what went wrong here? https://launchpadlibrarian.net/105319564/buildlog_ubuntu-quantal-i386.sift_4.0.3b-2ubuntu1_FAILEDTOBUILD.txt.gz
[12:44] <geser> argh, found the issue: the package compiles binaries, but replaced them later with pre-compiled once :(
[12:44] <jtaylor> lol
[12:44] <Laney> wtf
[12:51] <geser> and of course those binaries were x86-64 and me building on amd64 so I didn't catch this (the DD uploaded an amd64 deb too)
[17:00] <LordOfTime> hey micahg, that sru-test you asked me to do, apt-get is 404ing, did you build it for Precise? (for boinc)
[17:00] <LordOfTime> (in your PPA)
[17:02] <micahg> LordOfTime: yep
[17:02] <LordOfTime> that's odd
[17:02] <LordOfTime> because apt is 404ing on it then
[17:03] <LordOfTime> lemme remove it from my sources, and re-add
[17:03] <LordOfTime> this isnt the first time add-apt-repository's gone wonky for me
[17:04] <LordOfTime> ... woah......
[17:04] <LordOfTime> micahg:  i'm going to retract the backport / sru request, given that it wants to install a crapload of i386 stuff
[17:05] <micahg> huh?
[17:05] <LordOfTime> micahg:  it wants to install...
[17:05] <LordOfTime> 246 32bit packages
[17:05] <LordOfTime> just to install boinc
[17:05]  * LordOfTime thinks that that's somewhat overkill
[17:05] <LordOfTime> most of these are packages that already exist for the GNOME runtime
[17:05] <micahg> something seems not right
[17:05] <LordOfTime> indeed
[17:06] <LordOfTime> micahg:  https://pastebin.com/0A3ZyHf8
[17:06] <LordOfTime> EVIL HTTPS
[17:06] <LordOfTime> use it without https
[17:06] <LordOfTime> take a look at all it wants installede
[17:08] <micahg> LordOfTime: oh, right, we were discussing this yesterday in -devel :), boinc-client recommends ia32-libs
[17:09] <LordOfTime> *recommends*
[17:09] <LordOfTime> then why is this listing as dependencies
[17:09] <micahg> it's not
[17:09] <micahg> we install recommends by default
[17:09] <LordOfTime> ...
[17:09] <LordOfTime> bleh
[17:10] <LordOfTime> no offense, but IMO that's a bit rubbish... recommended packages arent necessarily dependencies, so what if someone didnt want the recommended packages
[17:10] <LordOfTime> (just to put that out there)
[17:11] <micahg> --no-install-recommends :)
[17:11] <micahg> The Recommends field should list packages that would be found together with this one in all but unusual installations.
[17:11] <Laney> or uninstall them, or apt-get install mycoolpackage myuncoolrecommendedpacakge-
[17:13] <LordOfTime> micahg:  the program installs and runs, but i'm running into more internet problems today, so i'm not going to be able to fully test this to see if that bug is gone
[17:13] <micahg> LordOfTime: ok, let me know when you can and I'll upload the SRU
[17:15] <LordOfTime> something's... not right... its not letting me set up my boinc user to here ...
[17:16] <LordOfTime> huh, you know what
[17:17] <LordOfTime> that explains it
[17:17] <LordOfTime> it segv'd in memory :/
[17:20] <LordOfTime> micahg:  i'm going to poke one of the people who had volunteered to test the backport, perhaps they can test the SRU, and they/I will get back to you
[17:20] <LordOfTime> because boinc refuses to work on my system (SIGSEGV in memory)
[17:21] <micahg> thanks
[17:25] <geser> Laney: should we update the section about handling of sync request in https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue (page linked from https://wiki.ubuntu.com/SponsorshipProcess)
[17:25]  * Laney sees something for the first time
[17:25] <LordOfTime> o.O
[17:26] <Laney> geser: looks like it could be updated and simplified indeed
[17:27] <Laney> and it probably doesn't want to be MOTU specific
[18:15] <highvoltage> broder: familiar with gimp at all? I have people at work and google+ who wants 2.8 on precise. I'm not sure how big it is or if it's to brave to take it on for a backport
[18:15] <highvoltage> (I guess I'll try it in a ppa and if it doesn't seem that complicated I'll try getting it in backports)
[18:15] <micahg> highvoltage: has quite a few rdeps
[18:15] <micahg> highvoltage: it should be in quantal by early next week
[18:16] <highvoltage> micahg: ok
[18:16] <broder> highvoltage: no familiarity. recruit the people who want it to do the rdep testing :-P
[18:16] <broder> oh my, that's quite a lot of rdeps
[18:16] <micahg> highvoltage: having said that, if we can get people to test the rdeps we can approve a backport (but the thing is, we'd want someone willing to smoke test the rdeps when we have security updates)
[18:17] <broder> eh, i still disagree with that
[18:17] <broder> (a) does gimp even have that many security updates?
[18:17] <broder> (b) i still think for security updates that we should only smoke the package itself, not the rdeops
[18:17] <micahg> 3 in the last year
[18:17] <broder> ugh
[18:17] <micahg> err 13 months
[18:18] <highvoltage> oh well, perhaps a ppa would suffice then
[18:18] <broder> in any case, i argue that the likelihood that a minimal security patch breaks an rdep is infinitesimal compared to the likelihood that a backport of a major release will
[18:18] <micahg> I'd be ok for partial rdep testing on the security backports (without major version changes)
[18:19] <broder> i've been talking about this for a while and not actually doing anything, so i guess i will send mail to the list and try to get it officialized'
[18:21] <micahg> we'll also need to backport from the next LTS when the time comes to get security updates for the life of precise
[18:22] <broder> no, we don't. security support for backports is best effort
[18:23] <micahg> I think that's for stuff we don't know more than stuff we do know
[18:24] <micahg> it is best effort, but to backport a package that's known to be CVE prone seems wrong (without some type of ongoing commitment from people)
[18:47] <highvoltage> gimp 2.8 also depends on a bunch of newer build dependences (libatk, libcairo2, libgdk-pixbuf2.0-dev, libwebkitgtk, python-dev...), I guess it was a bit optimistic to think that it would be easy :)
[18:49] <micahg> highvoltage: newer than precise?
[18:50]  * micahg is just aware of gegl being an issue
[19:24] <highvoltage> micahg: yep, the source package I have is from debian experimental
[21:49] <bobweaver> Hello there is there going to be a fix-it-Friday tomorrow ? IF so where is it located and what time. Thanks a ton !
[22:06] <geser> bobweaver: here and the whole friday and you don't need to wait on a fix-it-friday to fix bugs on a friday (or any other day of the week)
[22:09] <bobweaver> thanks a ton geser
[22:26] <pfifo> Hi, not sure whats up with the gnomebaker package for i386 precise... "This may mean that the package is missing, has been obsoleted, or is only available from another source" I hope its not being obsoleted, I need that package!
[22:48] <LordOfTime> micahg:  still around?


[07:26] <bradm> anyone seen maas stop doing dynamic updates for juju hostnames when you deploy?  if I start a boostrap, I can ssh into the host via IP, but the bootstrap fails because the cname for the host doesn't seem to be in place
[07:26] <bradm> bigjools: ^^ ? :)
[07:38] <bigjools> bradm: CNAMEs have gone away in 1.6 onwards
[07:38] <bigjools> but never heard of that happening unless the celeryd is down
[07:38] <bigjools> region celery that is
[07:39] <bradm> bigjools: this is with maas 1.5, it was working and then has suddenly stopped
[07:39] <bigjools> is region-celery running?
[07:39] <bigjools> and connected
[07:40] <bradm> bigjools: it appears to be working, how do I tell if its connected?
[07:40] <bradm> er, s/working/running/
[07:40] <bigjools> is it processing jobs?
[07:40] <bigjools> also is the cluster celery running and uploading dhcp leases?
[07:41] <bradm> bigjools: sure looks like it, I'm seeing things about "Received task" in the logs
[07:41] <bigjools> and the cluster celery?
[07:42] <bradm> bigjools: looks like it
[07:42] <bigjools> and the zone file doesn't have the CNAME?
[07:42] <bradm> bigjools: nope
[07:42] <bradm> bigjools: juju bootstraps are failing because I can't ssh to the hostname, but if I use the IP its fine
[07:43] <bigjools> can you restart the region celery
[07:43] <bradm> sure, doing so
[07:44] <bradm> ok, kicking off a bootstrap now
[07:48] <bradm> bigjools: ok, I see the dhcp offer and ack, but I can't resolve the hostname
[07:51] <bigjools> can you restart the cluster celery
[07:51] <bradm> how about I stop them both, then start
[07:51] <bigjools> and then can you examine the database to see if the dhcp lease is in
[07:52] <bradm> aha, how do we do that?
[07:52] <bigjools> I gotta run, dinner time.  "sudo maas-region-admin dbshell --installed"
[07:52] <bigjools> select * from maasserver-dhcplease;
[07:52] <bigjools> err _ not -
[07:52] <bradm> bigjools: perfect, thanks.  will see how it goes
[07:53] <bigjools> if the lease is not there there's something wrong with the cluster celery lease parsing and/or upload to the region
[07:53] <bigjools> ttfn
[10:22] <allenap> mgz: http://paste.ubuntu.com/8573190/
[10:22] <mgz> ta
[14:57] <th3rt> Silly question here,  but MaaS seems to selectively pick up and display IP addresses assigned to hosts.  Host discovery and boostrapping seems to get the IP fine,  but the MaaS web interface doesn't display it.
[14:57] <th3rt> Any idea why?
[15:08] <th3rt> Never mind.  Looks like I missed the part where the docs say that if I use MaaS dhcp then maas won't be able to statically assign an address.  I suspect it is this static address assignment that populates the web interface.


[01:14] <mup> PR snapcraft#3788 closed: parts: correct spelling of build-base in yaml_utils.load <Created by jhenstridge> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3788>
[02:34] <mup> PR snapcraft#3789 opened: store: support login --with <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3789>
[02:40] <tmpm697> hi all, just ask in #ubuntu but i just found this channel is more accurate to post issue related to snapd
[02:40] <tmpm697> i had snap version here: https://0x0.st/ouPT.txt
[02:41] <tmpm697> basically i use microk8s via snapd and microk8s enable dns and then microk8s reset, but after reset k get all -A still show resources there (old pods spawned by 'microk8s enable dns' command), why?
[02:42] <tmpm697> i expect soemhow microk8s.reset will remove all resources, but it didn't
[05:45] <mborzecki> morning
[06:08] <zyga[m]> hello
[06:22] <mardy> hi mborzecki, zyga[m]!
[06:22] <zyga[m]> hey guys
[06:23] <zyga[m]> any news on refresh-allowed?
[06:23] <mborzecki> heya
[06:24] <mborzecki> zyga: no, i don't think pedronis has looked at it yet
[06:25] <zyga[m]> okay, in case I miss it please ping me once there's some idea on what's next
[06:59] <mardy> mborzecki: I've got a meeting starting now, so I'll ping you later about your comment on https://github.com/snapcore/snapd/pull/11665
[06:59] <mup> PR #11665: cmd/snap-confine: be compatible with a snap rootfs built as a tmpfs <Needs Samuele review> <Created by mardy> <https://github.com/snapcore/snapd/pull/11665>
[06:59] <mardy> mborzecki: do I understand it correctly, that the issue is that when you request a layout inside a read-only fs, snapd creates a full mimic over a tmpfs?
[07:01] <mborzecki> mardy: no, when I added a layout under say /usr/foo, it creates a mimic on /usr, which then will have major:minor of a tmpfs device rather than the base snap
[07:01] <mborzecki> so the stale base check would compare different dev_t now
[07:02] <mborzecki> does this make sense? 🙂
[07:16] <mup> PR snapd#11477 closed: usersession/userd: ask the user whether to open the URL by given app <⛔ Blocked> <Needs security review> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/11477>
[07:32] <mardy> mborzecki: yes, it does. I'll rework the branch a bit; I guess all what I can do in that case, is to discard the namespace, right? Because in that case I'm not sure what I could check to determine whether the NS is stale...
[07:34] <mardy> mborzecki: the whole point of the should_discard_current_ns() function is to determine if the base snap changed, right? Or is there more?
[07:41] <mup> PR snapd#11842 closed: o/ifacestate: warn if the snapd.apparmor service is disabled <Created by mardy> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/11842>
[07:54] <zyga[m]> @mardy:libera.chat: yeah, that's roughly it
[07:57] <mardy> zyga[m]: thanks. I've got another question, that digging into the git history didn't help to answer: do you know if this die() line could be just replaced with a "return true"? https://github.com/snapcore/snapd/blob/master/cmd/snap-confine/ns-support.c#L303
[07:57] <zyga[m]> perhaps but the general desire was to avoid error handling and just die die die
[07:58] <zyga[m]> this is harder to attack at the cost of some ux in edge cases
[07:58] <mardy> I see
[07:58] <mardy> though in this case (if the namespace was messed up), we would just discard it, so it should be rather safe
[07:59] <mborzecki> mardy: yup, that's the crux of the check, whether that's useful well 🙂
[07:59] <mborzecki> mardy: i wait for the day when we drop the preserved mount ns and really just create everythign from scratch each time
[08:01] <zyga[m]> yeah, that might be easier
[08:03] <zyga[m]> although I think it's not easy to say it's safe :)
[08:37] <mup> PR snapd#11689 closed: tests/nested/manual/core20-early-config: revert changes that disable netplan checks <Simple 😃> <Run nested> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/11689>
[08:37] <mup> PR snapd#11861 closed: interfaces/system-packages-doc: allow read-only access to /usr/share/cups/doc-root/ and /usr/share/gimp/2.0/help/ <Created by lissyx> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/11861>
[09:10] <mardy> mborzecki: I replied to your comment on https://github.com/snapcore/snapd/pull/11665, your feedback on how to proceed is highly welcome :-)
[09:10] <mup> PR #11665: cmd/snap-confine: be compatible with a snap rootfs built as a tmpfs <Needs Samuele review> <Created by mardy> <https://github.com/snapcore/snapd/pull/11665>
[09:17] <mborzecki> mardy: looks reasonable, remember to run make fmt on the code though 🙂
[10:02] <mup> PR snapd#11874 opened: gadget: check also mbr type when testing for implicit data partition <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/11874>
[12:02] <mup> PR snapd#11875 opened: o/assertstate: support multiple extra validation sets in EnforcedValidationSets <validation-sets :white_check_mark:> <Created by stolowski> <https://github.com/snapcore/snapd/pull/11875>
[14:20] <mup> PR snapcraft#3789 closed: store: support login --with <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3789>
[16:54] <mup> PR snapd#11876 opened: tests: add support for uc22 in listing test <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/11876>
[21:00] <mup> PR snapd#11877 opened: tests: enable mount-order-regression test for arm devices <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/11877>
[23:06] <mup> PR snapcraft#3790 opened: lifecyle: root level build-packages and build-snaps <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3790>
[23:21] <mup> PR snapcraft#3791 opened: packaging: ignore craftctl python environment variables <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/3791>


[16:49] <AaronRainbolt> looks like Simon or someone else dutifully started the next step of the cycle for us
[16:51] <tsimonq2[m]> Yup that was me 🙂
[16:51] <tsimonq2[m]> Give it, meh, 6 hours and this will be up to date: https://ubuntu-archive-team.ubuntu.com/transitions/html/qt-6.6.2.html#!good,bad,partial,unknown,!notintesting
[16:51] <tsimonq2[m]> Also fun fact, once qt6-declarative is built and published, qt6-tools can also be synced
[16:52] <tsimonq2[m]> I know it's slightly confusing when just looking at a bullet-pointed list... the diagram is better
[16:52]  * tsimonq2[m] uploaded an image: (219KiB) < http://localhost:8008/_matrix/media/v3/download/ubuntu.com/OPhwQLTcjRbKomdyyqFfRnrE/image.png >
[16:52] <tsimonq2[m]> https://qt-kde-team.pages.debian.net/images/qt6_build_deps.png
[16:52] <AaronRainbolt> spaghetti
[16:52] <AaronRainbolt> but yes that is helpful :)
[16:53] <tsimonq2[m]> lmfao it's debatable on whether it's more or less helpful than the bullet pointed list 😜
[16:57] <tsimonq2[m]> Aaron Rainbolt: Have you ever done no-change rebuilds for a transition before?
[16:59] <arraybolt3> I don't know for sure, but I think I probably have and I believe I know how it's done.
[16:59] <arraybolt3> DOwnload package, bump version (carefully!), add a changelog about why you NCR'd, upload, right?
[17:00] <tsimonq2[m]> I'd suggest pinging LocutusOfBorg and asking for his NCR script hah, there's a way to get a package ready with one command if you do dch-foo right
[17:00] <arraybolt3> ok :)
[17:01] <tsimonq2[m]> Otherwise once all the Qt packages in the stack are synced/built, probably before the two NEW packages, this will have a good list of what needs NCRs and in what order: https://ubuntu-archive-team.ubuntu.com/transitions/html/qt-6.6.2.html
[17:01] <arraybolt3> kk
[17:01] <tsimonq2[m]> If we make Madison mad and the stack still won't migrate, we should see what it complains about: https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_output.txt
[17:02] <tsimonq2[m]> anyway that's about all there is to it - dch -R is what I'll typically do
[17:02] <tsimonq2[m]> and I've already seen calibre and that one German ID package both FTBFS, so those won't need NCRs, they'll need retries
[17:19] -Ubottu[m]:#lubuntu-devel- Builds: Lubuntu Desktop amd64 [Jammy 22.04.4] has been updated (20240507)
[17:21] -Ubottu[m]:#lubuntu-devel- Builds: Lubuntu Desktop amd64 [Jammy 22.04.4] has been updated (20240507)
 "I'd suggest pinging LocutusOfBor..." <- I want to know this
[18:29] <tsimonq2[m]> We'll share :)
[18:29] <tsimonq2[m]> It's late in Italy, so probably a tomorrow thing... plus qt6-declarative isn't built and published on riscv64 yet
[18:55] <RikMills[m]> This?
[18:55]  * RikMills[m] sent a code block: http://localhost:8008/_matrix/media/v3/download/chat.staging.ubuntu.com/vDEjskicggymguOdoaxwaaSQ
[18:55] <RikMills[m]> called rebuild-for
[18:56] <RikMills[m]> so you do rebuild-for "what you are rebuiilding against" source
[18:57] <RikMills[m]> That is what I use anyway
[18:57] <RikMills[m]> Came from doko I think
[18:58]  * RikMills[m] posted a file: rebuild-for (0KiB) < http://localhost:8008/_matrix/media/v3/download/kde.org/822c458ff6de6609036e73dcd60ef97b02550c211787919844398596096 >
[18:58] <ErichEickmeyer[m> That's one of those things that should be in ubuntu-dev-tools.
[18:59] <RikMills[m]> Simon Quigley: wxl  ?
[19:00] <tsimonq2[m]> Thanks!
[19:00] <AaronRainbolt> nifty
[19:01] <wxl[m]> ErichEickmeyer[m: send in the PR!
[19:01] <ErichEickmeyer[m> wxl[m]: I'm just saying I'm surprised doko hasn't.
 "#!/bin/sh..." <- > <@rikmills:kde.org> ```... (full message at <http://localhost:8008/_matrix/media/v3/download/chat.staging.ubuntu.com/PHxvhjYlIwvFPRrlwnDfQQtH>)
[19:08] <RikMills[m]> I don't doubt it ;)
[19:09] <RikMills[m]> But it works.....
[19:11] <ErichEickmeyer[m> Just a few safeguards, but nothing too terrible.
[19:12] <tsimonq2[m]> I actually like LocutusOfBorg's iteration better ;) https://pastebin.ubuntu.com/p/rBmTtsst5n/
[19:13] <tsimonq2[m]> ¯\_(ツ)_/¯ they're all just scripts wrapping around dch and dput, I'm sure a Pythonic approach can be taken too
[19:14] <RikMills[m]> In the end you get a commends you can script into a long batch list of packages, so prepare hundreds of source packages in one dir in one go
[19:15] <RikMills[m]> s/commends/command/
[19:15] <RikMills[m]> then do dput ubuntu *.changes
[19:15] <RikMills[m]> :)
[19:20] <RikMills[m]> oh, LOBs does the dput. same difference though
[19:21] <tsimonq2[m]> RikMills[m]: Not only does it do the dput, it has the prompt/safeguard commented out ;)
[19:22] <tsimonq2[m]> Perfect, who needs that anyway? :P
[19:23] <RikMills[m]> 🤐
[21:26] <AaronRainbolt> Hardware RISC-V64 builders when
[21:26] <AaronRainbolt> :P
 "Hardware RISC-V64 builders when" <- Too RISCy.


[01:47] <JonathanD> Hi guys.
[02:56] <Unit193> Howdy JonathanD
[02:57] <Unit193> Cheri703: It was that, or fair + motor cross :P
[02:57] <Cheri703> hehe, good call
[02:57] <Unit193> Mod tractor pull tomorrow that I might go to also (And a demo derby sat :D:D:D )
[03:23] <ashams> hello everybody
[03:25] <ashams> I noticed that your LoCo have a Council, this idea was suggested by some of our LoCo members, I want to ask how this idea helped you Or why did you do that?
[03:25] <Unit193> Howdy ashams and welcome to the Ohio LoCo
[03:25] <ashams> Unit193: hi, thanks
[03:25] <ashams> Unit193: what you think?
[03:25] <Unit193> Sweet, what one are you from? And Cheri703 ^^ :P
[03:26] <ashams> Unit193: Egypt
[03:26] <ashams> pad.lv/~egyptlocoteam
[03:26] <Cheri703> I believe that it was moved to a council so that a. the work could be shared, b. it encourages more participation and delegation, and c. it avoids having one person trying to be "in charge" I know other teams have had people treat it as their personal kingdom, and having others helps avoid that
[03:27] <ashams> Cheri703: but wont this split your team into two layers?
[03:28] <Cheri703> not really
[03:28] <Cheri703> there are only 3 on the council, and it's not like we dictate anything, anyone can suggest anything, and people are totally free to take initiative on things. we are more here to help things go smoothly than to make official decisions and such
[03:28] <ashams> Cheri703: what new members think about this? do they have some envy on those on top?
[03:29] <Cheri703> I have no idea...I'd hope not, if they do, a. they can talk to us, and b. they can run in the next election
[03:29] <Cheri703> why would they not envy the ONE person in charge? if they would envy the 3?
[03:29] <ashams> Cheri703: :)
[03:30] <ashams> Cheri703: do you have any regulations for ppl to jump in/out and specially out?
[03:30] <Cheri703> of the council? the team? what are you asking?
[03:31] <ashams> Cheri703: sorry, I meant of the Council?
[03:31] <Cheri703> one year terms as far as I know
[03:31] <ashams> Cheri703: sorry, I didn't get what you mean?
[03:32] <Cheri703> council members serve for one year, and then we hold an election to replace them. current council members can re-run and get re-elected, but it gives the opportunity for new folks
[03:33] <ashams> Cheri703: great
[03:33] <Unit193> If they want to back out, we elect a person to fill in
[03:35] <ashams> Cheri703: do you regulate who give presentations or sessions to ppl from outside the community? I mean there can be some persons who really like to give a session but they not really qualified, do the Council have any sovereignty to say No, you can't.
[03:36] <ashams> Cheri703: I mean, Does the Council forms a governance?
[03:36] <Cheri703> Not at this point we don't/haven't
[03:37] <Cheri703> if someone wants to, but doesn't feel qualified, they'd be welcome to ask for help from the group (not just the council). help in preparing a speech or help by having someone who might be willing to do it instead
[03:39] <ashams> Cheri703: It happened in our LoCo, that someone really new, wanted to give a session by material he got from someone else and he insists to that session by himself only: It would help if the Council have governance powers in such case, do you recommend us to go ahead and give a council that power?
[03:40] <Cheri703> where did he want to give the session? and why should he not be allowed?
[03:41] <ashams> Cheri703: He is not qualified at all
[03:41] <ashams> Cheri703: :(
[03:41] <Cheri703> but what is qualified? what topic? who does he want to speak to?
[03:42] <ashams> Cheri703: Normally introduction to Ubuntu, but he wasn't even using it ;) !!!!
[03:42] <Cheri703> personally I wouldn't have a problem with it
[03:42] <ashams> Cheri703: why? How?
[03:42] <Cheri703> because it is a learning experience for him
[03:42] <Cheri703> who am I to say he can't have that?
[03:43] <Cheri703> like I was trying to get to earlier, it may depend on who he wants to talk to
[03:43] <ashams> Cheri703: outerspace!
[03:44] <Cheri703> ...?
[03:44] <ashams> Cheri703: sorry, to ppl who don't know about linux
[03:44] <Cheri703> so why would it matter? as long as he is mostly right, they will still learn something
[03:44] <ashams> Cheri703: that would be their first impression...
[03:45] <Cheri703> my first impression was my brother saying "here, boot this cd, tell me what you think next time you see me"
[03:45] <Cheri703> so...any intro is probably ok
[03:46] <Cheri703> anyway ashams, I'm not going to debate it with you. I would be perfectly fine with it, and in my opinion, forming a council for the purpose of telling people they CAN'T participate in sharing ubuntu seems very counter-intuitive
[03:47] <ashams> Cheri703: I'm not debating at all, I'm just trying to know how you really think about it, so sorry...
[03:47] <Cheri703> well, I'm just saying, I've stated my opinion, I get yours, I just think it's a non-issue
[03:49] <ashams> Cheri703: Yeah, it's really a non-issue. I was just trying to get your full idea. Thank you very much
[03:49] <ashams> Cheri703: Thank you for helping me :)
[03:49] <Cheri703> yup :)
[03:50] <ashams> Unit193: Thank You :)
[03:50] <Unit193> ashams: Sure, I just knew who to call! :P
[03:51] <Unit193> Cheri703: Thanks, you would/are better at that than I
[03:56] <ashams> Cheers Ohio LoCo, Greetings from Egypt LoCo team, best wishes.....
[04:26] <Unit193> Welcome back Mr Bios
[04:35] <BiosElement> Thanks Unit
[14:03] <thafreak> Morning Ohio
[14:04] <Unit193> Howdy, it already feels like afternoon :P
[14:05] <thafreak> well...i guess it kind of is....i'm just rolling into work now...
[14:05] <thafreak> very long mornings some days
[14:05]  * Unit193 has been up since yesterday
[14:09] <thafreak> any reason?
[14:09] <thafreak> you stay up playing a game...working on homework or a project? Or just not a fan of sleep?
[14:10] <Unit193> Had to do something the next morning or somebody will whine and complain and I don't do mornings :P
[14:11] <thafreak> oh....I've done that many times
[14:11] <thafreak> I tend to still get like 2-3 hours of sleep...unless I'm still working when they come in to work the next morning...
[14:12] <thafreak> Like re-build a server over night, and still be setting things up when people stroll into work in the morning...that sucks
[14:12] <paultag> fail!
[14:12] <paultag> 03:56 < ashams> Cheers Ohio LoCo, Greetings from Egypt LoCo team, best wishes.....
[14:12] <thafreak> it was the hardware that failed....
[14:12] <paultag> awwww :)
[14:12]  * Unit193 might be borg
[14:13] <paultag> I love the borg
[14:13] <thafreak> and FYI, for anyone building raid storage, buy an extra drive or two to have around
[14:13] <paultag> I want to be borg
[14:13] <paultag> imagine if I could sync my brain with other brains
[14:13] <paultag> I could talk about stuff and things
[14:13] <thafreak> cause if one drive fails 3 years down the road, you probably won't be able to buy the same drive anymore :)
[14:13] <paultag> thafreak: that's actually a good point
[14:13] <paultag> thafreak: never thought of that
[14:13] <paultag> damn
[14:14] <paultag> that's why I'm not a sysadmin
[14:14] <paultag> thafreak: so, after your little puppet clone, howsabout I get you to do some Syn work? It's so close to working >:D
[14:14] <thafreak> well, if it's soft raid...you could TECHNICALLY, replace with bigger drives, and re-build, then replace another with a bigger drive, and re-build, and eventually have a bigger array...
[14:14] <paultag> that sounds lame
[14:14] <paultag> and time consuming
[14:15] <thafreak> Actually, I'm down...I think it would go nicely with my puppet clone work :)
[14:15] <paultag> just rsync it over :)
[14:15] <paultag> thafreak: no shit? That's awesome news
[14:15] <paultag> thafreak: We've got about 5 of us on it now
[14:15] <thafreak> rsync would require a second array in place :)
[14:15] <paultag> thafreak: you'd be the 6th
[14:15] <paultag> thafreak: yeah, true, I guess :)
[14:15] <paultag> thafreak: but I don't have a sous-chef, someone who can hack without me standing over their sholder
[14:16] <paultag> I could use a solid hand on the project
[14:16] <thafreak> i've never done it, but supposedly you can replace a drive at a time, and eventually have a bigger array...
[14:16] <thafreak> i can hack and slash
[14:16] <paultag> it sounds time consuming and painful
[14:16] <paultag> thafreak: dude, I'd love you long time
[14:16] <paultag> thafreak: there are so many hacks
[14:16] <thafreak> you have a coding standards doc, so some one as my self would be able to write code that fit in and didn't stand out?
[14:16] <paultag> thafreak: sure 'nuf -- http://docs.syn.pault.ag/syn-policy.html
[14:17] <paultag> thafreak: that's a WIP, so it's changing, but it covers the basics of every aspect of Syn, for the most part
[14:17] <paultag> thafreak: section 6
[14:17] <thafreak> geez...
[14:17] <paultag> that's open to change if we need to :)
[14:17] <thafreak> I think we have this backwards
[14:17] <thafreak> I should be recruiting you :)
[14:17] <paultag> thafreak: I'm always open for hack trades :)
[14:18] <thafreak> wow, the tabs over spaces thing...that's a big one
[14:18] <paultag> thafreak: yeah I know
[14:18] <thafreak> I'd have to adjust my .vimrc :)
[14:19] <paultag> thafreak: I'm a bit odd when it comes to Python. If you really feel strongly and you'll be working closely with me on it, I could change
[14:19] <paultag> thafreak: but the way I see it is tabs are nicer
[14:19] <paultag> people can set the stop to where they want (4 versus 8 versus 2)
[14:19] <paultag> it's easier to indent / back up
[14:19] <thafreak> oh, I always use the tab key...i just set vim to expand them to spaces....
[14:19] <paultag> and it should be a smaller size of the file over a huge package
[14:19] <paultag> thafreak: ah, I see
[14:19] <thafreak> this is true...
[14:20] <paultag> thafreak: but if someone really really cared, I could change
[14:20] <paultag> I know I'm a minority
[14:20] <thafreak> I think you just need to pick one and only one, and it seems the python community at large went spaces...so that's what I did
[14:20] <thafreak> no biggie
[14:20] <thafreak> like i said, I always use the tab key anyway
[14:21] <paultag> Yeah, I'm keeping it all consistant for if we need to switch it later, and so it's not mixed
[14:21] <thafreak> except when breaking up long lines...trying to get braces to line up, tabs don't always work
[14:21] <paultag> truth
[14:21] <paultag> thafreak: well spaces are fine there, since it's in the code line
[14:21] <paultag> that's more about the identation
[14:21] <thafreak> it annoys me to break things up anyway....but, so do long lines now....
[14:23] <paultag> thafreak: most of us are in #whube, if you want the IRC room
[14:23] <paultag> thafreak: and the code's on Github :)
[14:23] <thafreak> yeah, I think I'm "watching" it already on github...not that that means anything to me really, except as sort of a bookmark
[14:24] <paultag> :)
[14:24] <paultag> thafreak: issues exist on github/whube/syn/issues
[14:24] <thafreak> like things I "watch" I don't always keep track of...it's more of a log in to github, and oh yeah, I wanted to keep tabs on that project
[14:24] <thafreak> cool
[14:24] <paultag> yeah :)
[14:25] <thafreak> So I'm planning on building a much much larger system eventually...the puppet clone is just on piece...
[14:25] <paultag> thafreak: o'rly?
[14:26] <thafreak> it's essentially going to give a single sysadmin the ability to manage 10-100 times the servers he/she could normally manage
[14:26] <thafreak> like the one system to rule them all
[14:26] <paultag> thafreak: that would be pretty goddamn badass
[14:26] <thafreak> dashboards and panels out the wazoo
[14:27] <thafreak> clickety click to update all your systems pacakges...deploy new systems for specific roles...see what systems are doing (performance wise)
[14:27] <paultag> it would be kinda fun to expose Syn functions through a TCP/IP layer
[14:27] <paultag> establish a SSH link and be able to control package stuff
[14:27] <thafreak> I was thinking sort of a push system
[14:28] <thafreak> have you looked at pushy?
[14:28] <paultag> thafreak: no, let me google it :)
[14:28] <thafreak> remote python execution over ssh
[14:28] <paultag> oh interesting...
[14:28] <paultag> oh shit
[14:28] <thafreak> so you could run syn functions remoteley
[14:28] <paultag> thafreak: that's brillaint...
[14:28] <thafreak> there's also rpyc
[14:28] <thafreak> which is similar
[14:28] <paultag> how did I not think of this
[14:29] <thafreak> yeah, I know right
[14:29] <thafreak> basically, anything you think of, some one already did...and some one else already did it better than that guy
[14:29] <thafreak> or girl
[14:29] <paultag> thafreak: syn's open for hacking if you want to add some of this stuff, it would actually help the build farm I need to wire
[14:29] <thafreak> aight...
[14:30] <paultag> thafreak: so we can have a central machine that can scp a file, move it over ssh, and then call syn-plumbing to kick a build
[14:30] <paultag> thafreak: because all user-exposed scripts are actually python "plumbing" calls wrapped in a try/catch
[14:30] <thafreak> I found some neat stuff to hook pushy into fabric and re-use it's paramiko ssh connection...so you can remote run python in your fabric code
[14:30] <paultag> that's sweet
[14:31] <thafreak> then it would be easy to run remotely with pushy I bet
[14:31] <paultag> truth
[14:31] <paultag> thafreak: so, what's it going to take to get you hacking with me on this?
[14:31] <paultag> I need someone to be critical of my work, I need a peer :)
[14:31] <thafreak> I think I may also, instead of simply writing a puppet clone in python, I might actually base it on fabric
[14:32] <thafreak> so you want peer reviews...I could probably help with that
[14:32] <thafreak> what made you decide to go from toy/idea tinkering, to going full steam with syn?
[14:32] <paultag> thafreak: howsabout a hack trade. I'll actively work with your pet if you can help me with mine :)
[14:32] <paultag> thafreak: things just sort of lined up
[14:33] <thafreak> not out of frustration with apt or anything?
[14:33] <paultag> thafreak: I saw the goal, and ended up doing 7 KLOCS in the last 4 weeks
[14:33] <thafreak> or dpkg i should say
[14:33] <paultag> thafreak: Well yeah, but only mild
[14:33] <paultag> thafreak: the real idea is that I can do it better, cleaner and modernly
[14:33] <paultag> thafreak: it's not that I'm mad now and I'll give up once I accept it
[14:33] <paultag> just small things that annoy me about dpkg / deb generation
[14:34] <thafreak> well, no matter what you do, I'm sure it will blow yum out of the water atleast :)
[14:34] <paultag> yeah fuck that mess :)
[14:34] <thafreak> ah...ok
[14:34] <thafreak> generating debs is fucking nuts
[14:34] <paultag> thafreak: oh yeah, and all package maintainer files are in JSON
[14:34] <thafreak> honestly, I think I prefer making rpm's....
[14:34] <paultag> thafreak: and with a few scripts to curl a project page and regex for a package number, it can auto-upgrade syn source files and push them automatically, and only need human help when it fails
[14:35] <paultag> thafreak: Syns are super easy to make
[14:35] <thafreak> alright....I'd like to help steering at the very least... :)
[14:35] <paultag> that would be more then useful
[14:36] <thafreak> cause i honestly haven't liked any package system 100%
[14:36] <paultag> thafreak: me neither, hopefully this can help a bit.  Simple, easy, braindead simple to read if you need to
[14:37] <thafreak> to track what packages are installed?
[14:38] <paultag> also rebuilding it is a snap if you need to, it fragements package data in the package directories as well
[14:38] <paultag> thafreak: yeah, for now. I don't see a reason to use something like SQL :)
[14:38] <thafreak> yeah, sql is overkill...
[14:38] <paultag> I worked it out and tried it with about 10,000 package entries
[14:38] <thafreak> i really don't know what I would use honestly...haven't thought about the needs of a package system much
[14:39] <paultag> it was still faster then both pickle using the same method and dpkg
[14:39] <thafreak> pickle, or cPickle?
[14:39] <paultag> thafreak: yeah, it's one of those decisions that literally does not matter. It's really not blocking anything
[14:39] <paultag> thafreak: pickle, but I don't like the way it stores stuff, so I ditched it.
[14:39] <paultag> and it's not readable by any other language, really
[14:39] <thafreak> ah...this is true
[14:40] <thafreak> so what about BSON
[14:40] <paultag> the json dict would make it easy to post-mortum if the machine broke
[14:40] <thafreak> binary json?
[14:40] <paultag> thafreak: all the json read/write is abstracted with classes, so if you wanted to change it, it should be a few line delta
[14:40] <thafreak> not readable necessarily, but still cross platform
[14:40] <paultag> thafreak: it's pushing json compressed with gzip now
[14:40] <thafreak> gotcha...
[14:41] <thafreak> watch the mongodb/couchdb space, as they're heavy json users...anything they come up with will be useful for you I'm sure
[14:41] <paultag> thafreak: http://docs.syn.pault.ag/?p=json_file.json_file -- base interface for json_file, http://docs.syn.pault.ag/?p=json_bfile.json_bfile -- delta for the binary version
[14:41] <paultag> thafreak: I'll have to :)
[14:43] <thafreak> So, here's a q for you
[14:43] <paultag> sure sure
[14:43] <thafreak> you seem very pro json
[14:44] <paultag> I am :)
[14:44] <paultag> it's a scitch smaller then XML, which is nice for over the line / persistant stuff
[14:44] <thafreak> would you make a new syntax that's close to puppet's, but using json/yaml/or even plain python
[14:44] <paultag> also a snap to process :)
[14:44] <paultag> thafreak: hummm
[14:44] <thafreak> OR, write a parser to parse puppet syntax?
[14:45] <thafreak> The upside is that people could theoretically continue to use their already written puppet files
[14:45] <paultag> thafreak: true, but then you have to bind yourself to puppet's feature set
[14:45] <paultag> it's a toughie
[14:46] <thafreak> Well, I was kind of modeling it after puppet anyway with it's dependancy graphs
[14:46] <thafreak> I'm open to doing both too I guess
[14:46] <thafreak> a new syntax that's more flexible, but also supporting puppet's to make it easy for people to switch
[14:46] <paultag> thafreak: it's an odd problem
[14:46] <paultag> thafreak: I don't think there's a right answer here
[14:47] <thafreak> essentially, I'm parsing the file, and turning it into sets of resource objects arranged in a graph
[14:47] <paultag> humm :)
[14:47] <thafreak> so you could define a file, and what properties it needs, ownership, mode, should it exist or not exist, etc...
[14:48] <thafreak> that's all modeled as a file resource object
[14:48] <paultag> yeah, sure
[14:48] <thafreak> having more than one parser at that point shouldn't affect much other than allowing them to be defined differently
[14:48] <paultag> true
[14:48] <thafreak> the guts still work the same
[14:48] <paultag> yeah
[14:49] <thafreak> I'm really leaning towards having it be basically python syntax, as it would be easiest to implement...just need to work out what it should look like
[14:49] <thafreak> then add a puppet parser later
[14:49] <paultag> thafreak: I think python is tempting, and it could lead to some interesting things
[14:49] <paultag> thafreak: like extending it locally, and having conditionals and cases
[14:49] <paultag> be able to have an upgrade path function
[14:50] <paultag> but it adds complexity
[14:50] <paultag> and you have to provide a full interface
[14:50] <thafreak> I was thinking build a cli tool, and you point it at a "manifest", and it automatically does all the imports you need, then parses the file as python
[14:50] <paultag> I think that could be really solid
[14:51] <thafreak> so you don't need to import anyhting in your manifest...
[14:51] <thafreak> but that opens you up to security stuff...you know, never execute untrusted code...
[14:51] <thafreak> the whole use of exec/compile to run python from strings
[14:51] <paultag> thafreak: if they're about to execute a puppet script, at this point, if they're going to fuck up the datacenter, they'll fuck it up
[14:52] <thafreak> this is true...puppet allows you to execute shell commands willy-nilly
[14:52] <paultag> right
[14:52] <thafreak> so the sysadmin should be not stupid, and not execute something from the internet without reading it
[14:52] <paultag> a hacker should not be able to even make the connection to auth outside the datacenter
[14:53] <paultag> thafreak: I mean, they could rm -rf manually, too
[14:53] <thafreak> very true
[14:53] <paultag> if the sysadmin sucks, he should not be there :)
[14:54] <thafreak> i could throw some regex's in there maybe to look for things before execing it too...
[14:54] <paultag> thafreak: yeah, but it's not your job to ensure this is a safe plastic rounded toy
[14:54] <paultag> thafreak: this is for managing a datacenter
[14:54] <thafreak> and maybe run it through lint first to make sure it's even correct syntax
[14:54] <paultag> that would be awesome
[14:54] <paultag> syntax checking is awesome
[14:55] <thafreak> cause it would be silly to run it, and your tool blows up with an exception because of bad syntax in the manifest
[14:55] <paultag> thafreak: not only that, but it's nice to know how you're doing from time to time, so running lint often would be very useful
[14:55] <thafreak> you think if I name my tool sockpuppet, I'll get sued?
[14:55] <paultag> thafreak: nah :)
[14:56] <thafreak> or is there a snake/puppet reference to be made?
[14:56] <paultag> hummm
[14:56] <paultag> littlemspiggy
[14:57] <paultag> kermitthefrog
[14:57] <thafreak> more snakey...ie python
[14:57] <thafreak> oh...or I could go not the snake, but the comedy troupe
[14:57] <paultag> right right
[14:57] <paultag> oh good point
[14:57] <thafreak> should see if they had puppets for anything memorable
[14:58] <paultag> I was just googling
[14:58] <paultag> BRB
[14:58] <thafreak> cool...I'll bbl
[15:26] <thafreak> got it...
[15:26] <paultag> :)
[15:26] <thafreak> project code named "killer rabbit"
[15:26] <paultag> YES
[15:26] <thafreak> after the rabbit from holy grail
[15:26] <paultag> yeappers!
[15:28] <thafreak> that's atleast the name for now while I develop it...
[15:28] <thafreak> otherwise I'll spend too much time trying to name it
[15:28] <thafreak> and never write anything
[15:29] <paultag> thafreak: for sure
[15:31] <paultag> thafreak: P.S., most of the synners are in #whube :)
[15:31] <paultag> thafreak: and I'm sure most of them would be willing to help with killer rabbit too
[15:31] <thafreak> haha cool
[16:42] <thafreak> w00t! they got spice into debian testing! damn, wheezy is gonna be pimp
[16:42] <thafreak> look out fedora
[17:01] <paultag> thafreak: :)
[17:45] <itsafork> BONJOUR!
[17:45] <Unit193> Casps Lock... Howdy
[17:48] <itsafork> need an opinion::  what are your thoughts on a presentation about gaming on Ubuntu???
[17:49] <Unit193> It has games? ;) Who is the target?
[17:49] <paultag> teenagers
[17:51] <itsafork> well yeah, like "mainstream" games
[17:51] <itsafork> mmo-rpg's god-knows-what-else-people-play
[17:51] <Unit193> Sure, but most gamers have their "own" games they like
[17:53] <itsafork> well, yeah. but i think what i'm trying to say is; using ubuntu for your gaming pc is a great option
[17:54] <itsafork> or do-able option. or something like that, basically you dont NEED windows to play 90+% of your games
[17:55] <Unit193> Also, some windows only games work ok with wine (Didn't StarCraft2 do a little testing even?)
[17:55] <Unit193> AppDB is their friend ;)
[17:57] <itsafork> exactly!
[18:13] <thafreak> I like it
[18:13] <thafreak> counter strike played BETTER on wine than windows
[18:14] <thafreak> it crashed ALL the time under windows, but never for me under wine
[18:14] <itsafork> good deal!
[18:17] <thafreak> course games like those from the humble indie bundle which are built for linux work best :)
[18:19] <Unit193> IRCer I know like this one :( http://appdb.winehq.org/objectManager.php?sClass=version&iId=19141


[09:25] <soon> Hi folks - I'm new to budgie ... is there a workspace overview functionality that allows for easy re-arrangement of windows between workspaces?
[09:40] <fossfreedom> There are various workspace applets available. I would suggest raising on discourse.ubuntubudgie.org where the community can help better.


[13:25] <astraljava> hggdh: Sorry for the delay. re: harvest, can you tell me if it is correct when it still finds bug 791467? Isn't that already closed?
[13:25] <ubot4> Launchpad bug 791467 in ubuntustudio-meta (Ubuntu Oneiric) (and 3 other projects) "gcdmaster not built on Oneiric: breaks ubuntustudio installation with additional software (affects: 1) (heat: 3)" [High,Fix released] https://launchpad.net/bugs/791467
[13:35] <hggdh> astraljava: no, it is not...
[13:37] <astraljava> hggdh: Why? It's marked invalid and fix released.
[13:38] <hggdh> astraljava: it is not correct because all the bug's tasks are in a final state
[13:38] <hggdh> there is nothing else to be done there
[13:38] <astraljava> Ahh... sorry, misunderstood.
[13:41] <astraljava> hggdh: So I filed bug 924288 about it, then.
[13:41] <ubot4> Launchpad bug 924288 in harvest "harvest finds bugs that have already been resolved (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/924288
[13:46] <hggdh> astraljava: THANK YOU
[13:46] <hggdh> DAMM caps lock
[13:46] <astraljava> Hehe. :)
[14:29] <MxxC> So do i need to provide any more info regarding bug 909996 to have somebody look at it/fix it?
[14:29] <ubot4> Launchpad bug 909996 in b43-fwcutter (Ubuntu) "firmware-b43legacy-installer errors "17: missing" (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/909996
[14:46] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek starting in 14 minutes in #ubuntu-classroom
[23:55] <PaulW2U_> disc