[08:57] <melmoth> anyone knows if one has to worry if a zookeeper "agent-state" is "not started" on a Maas deployed openstack architcture ?
[08:57] <melmoth> everythng else seems ok, services are there and running
[08:57] <melmoth> so zookeeper seems to work, but still, it s worrying.


[13:02] <holman> beantaxi: Responding to your last comment (I haven't caught up on the whole thread): Currently tools aren't distributed separate from cloud-init itself, so I commonly run tools locally by setting PYTHONPATH=/path/to/cloud-init/git/repo cloud-init.cmd.main --help, which which is useful for example for schema validation without cloud-init being installed.
[13:30] <SDes91> In cloud-init how to just create a user but not set a password? I wish the user to exist but it becomes active only when the admin user creates a password for them manually
[14:02] <holman> SDes91: lock_passwd defaults to true, I think the behavior you desire is default unless you change that setting.
[14:03] <holman> SDes91: So just use the `users` key. Examples here: https://cloudinit.readthedocs.io/en/latest/topics/examples.html#including-users-and-groups
[14:11] <SDes91> holman tried it out. Works. I can get the SSH prompt when trying to login into the machine with this user but since the password isn't set it fails after 3 attempts. Serves my purpose
[15:03] <beantaxi> holman: Thanks -- I cloned the repo, created a cloudinit virtualenv, did a pip install -r requirements.txt, and then `$ PYTHONPATH=/path/to/cloudinit python -m cloud-init.cmd.main --help`, and it looks like that will do what you suggest. Thanks!
[15:06] <beantaxi> It'd be nice to streamline that, into a single executable eg `cloud-init-tool`, but offhand I don't know how I'd do that without adding a line or 2 to setup.py which would then require a full install
[15:08] <aciba> beantazi: That's already the case. You can access that cli via `cloud-init`: https://github.com/canonical/cloud-init/blob/main/setup.py#L352
[15:13] <holman> It's not very convenient is it.
[15:17] <beantaxi> aciba: I was just reading the cloudinit setup.py source and noted that :) If a pip install-from-source of cloud-init into the venv is free of side effects, then I could just run cloud-init and that'd be nice
[15:18] <beantaxi> holman: Not particularly but I appreciate that most folks are fine just writing cloud config files in their fave text editor, without need for any tools, and so everything I'm asking about is pretty niche
[15:31] <holman> beantaxi: +1, but also maybe not so niche anymore - schema validation (which has improved lately) is a quick-and-easy solution to suggest when users have user-data issues, but if getting it setup is inconvenient they are less likely to try that first before asking.
[16:41] <minimal> holman: I guess it would be possible for distros to create a subpackage to install for just the schema validation
[16:42] <minimal> am thinking about this now for Alpine ;-)
[16:58] <ExeciN> I just installed ubuntu server 22.04.1 and I want to use this installation as a reference to deploy some more VMs. Where can I find the cloud-init configuration for this installation?
[17:02] <blackboxsw> ExeciN: so are your talking about using a Ubuntu live server  install, that should emit a /var/log/installer/autoinstall.-user-data file that can be used in subsequent live installs via something like https://ubuntu.com/server/docs/install/autoinstall-quickstart
[17:05] <blackboxsw> ExeciN: if you are talking about just cloning a VM golden image that was created on your favorite cloud  platform, you might be wanting to do something like `sudo cloud-init clean --logs; rm /etc/machine-id; sudo shutdown -h now` and then take a snapshot or clone of your image to reuse when launching other VM instances
[17:40] <ExeciN> blackboxsw: I was talking about the first one. thanks
[18:08] <beantaxi>  holman: I can't think of how Docker would help ... have y'all considered a 'cloud shell' sort of setup, where folks could do all their config validation and testing in an SPA?
[20:49] <cjp256> are there any known issues with cloud-init in -proposed?
[20:49] <cjp256> specifically: 22.3-13-g70ce6442-0ubuntu1~22.04.1
[20:50] <blackboxsw> cjp256: not at the moment. holman was running through our SRU valifation on all platforms and I **think** our integration validation was coming up green
[20:50] <cjp256> after an upgrade, the subsequent reboot falls back to iid-datasource on Azure
[20:50] <blackboxsw> I'll check out CI on this, because -proposed on specific clouds may not have completed yet
[20:50] <cjp256> do not know why yet, but looking into it
[20:53] <blackboxsw> cjp256: 22.3-13-g70ce6442-0ubuntu1~22.04.1 passed all existing integration tests for us Sep 3, 2022 12:22:12 AM
[20:54] <blackboxsw> only a minor known integration test assert failure which was already fixed in tip of main.
[20:55] <blackboxsw> https://jenkins.canonical.com/server-team/view/cloud-init/job/cloud-init-integration-jammy-azure/95/ (though I think that URL's not visible to others outside of canonical)
[21:10] <cjp256> doesn't repro if i build my own deb from 22.3.1
[21:10] <cjp256> did it just get pulled from -proposed? :D


[04:43] <poningru> hey guys quick question
[04:44] <poningru> I have a 01:00.0 Network controller: Broadcom Corporation BCM94311MCG wlan mini-PCI (rev 02)
[04:44] <poningru> with hardy running 2.6.24
[04:44] <poningru> should it be using the b43 driver?
[04:45] <poningru> I had ndiswrapper installed
[04:45] <poningru> but now its not working
[04:48] <crimsun> yes, it should be using b43.
[04:54] <poningru> I am going to assume no one has said anything
[07:29] <kraut> moin
[08:53] <sivang> hi all
[14:34] <Kano> hi,when will be rc6 merged?
[15:01] <zul> Kano: probably not til the new year
[15:05] <Kano> not the answer i wanted to hear
[15:09] <zul> well it is christmas basically
[15:09] <Kano> next monday evening
[15:09] <Kano> not before
[15:10] <Kano> not today
[15:11] <BenC> Kano: the kernel devs (and all of canonical for that matter) are on holiday till Jan 2
[15:12] <Kano> what was the option to disable abi checks?
[15:12] <BenC> It's on the wiki
[15:13] <Kano> but doesnt that change the version?
[15:13] <BenC> skip_abi=true
[15:13] <Kano> ok, will try my own patchset then
[15:14] <Kano> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/177725
[15:14] <ubotu> Launchpad bug 177725 in linux "pnpacpi: exceeded the max number of mem/IO resources" [Undecided,New]
[15:15] <Kano> do you know if that is fixed in rc6?
[15:15] <Kano> also a mini mac did not boot with current 2.6.24
[15:28] <Kano> also does somebody know how to add a hook for initramfs to add a blacklist option
[15:28] <Kano> i have such an optin a custon initrd for kanotix, as i need to blacklist prism54
[15:29] <Kano> sometimes ehci-hcd
[15:37] <Kano> prism54 is also loaded together with p54pci but my card only needs p54pci
[15:40] <Kano> softmac cards never work with prism54
[17:14] <zul> have a good christmas everyone
[19:29] <Keybuk> so, if I have a built kernel source
[19:29] <Keybuk> and I've changed the code to one module
[19:29] <Keybuk> how do I rebuild just that one module?
[19:33] <soren> "make M=/path/to/module modules" I belive.
[19:33] <soren> The top-level makefile is richly commented. I'm certain there's an example describing just that.
[19:33] <soren> Keybuk: ^^
[19:41] <Keybuk> thanks
[19:42] <JanC> someone should fix gcc/make to know that by itself  ;)
[19:44] <Keybuk> that seems to try and build an external module
[19:56] <soren> Keybuk: Stop pointing it at an external directory?
[19:57] <Keybuk> that didn't work
[19:57] <Keybuk> make path/to/module.ko worked from the top level
[19:58] <soren> Hmm... I'm sure I've done in-tree builds the same way. Oh, well.
[20:05] <mjg59> Keybuk: Yeah, that's the way I always do it
[20:05] <mjg59> Keybuk: You can actually do it from an unbuilt tree as well, as long as you mkdir .tmp_versions
[21:33] <Keybuk> mjg59: so far, I know it's not just insertion that's broken
[21:33] <Keybuk> but any kind of detection of the card
[23:28] <Torgoton> Hey all. The folks in #ubuntu-installer sent me here. I'm trying the bare minimum install on a very old machine, using only the linux and initrd.gz files. Dapper and Edgy start the installer, but Feisty and Gutsy both crash, even when using the 386 versions. I can point you to the gutsy crash output if you like. Also, my keyboard gets mapped all crazy, but I can start an install (with dapper and edgy) if I use a serial console.
[23:30] <ln-> you are very optimistic by assuming that someone cares.
[23:31] <Torgoton> Indeed. An optimist I am.
[23:31] <Torgoton> I thought someone might care that the kernels built for low-spec machines crash on some of them.
[23:32] <ln-> let me quote what i was told about a crash:
[23:32] <ln-> 12:36 < amitk> ln-: If you want JustWorks (TM), you have to either help during beta testing or get a support contract. It is unrealistic to expect that a distribution will hit all your target usecases.
[23:34] <Torgoton> I was hoping it would hit this one. I know the wiki is a community project and could be out of date, but it claims a 486 with 32MB RAM will be just enough machine for the job.
[23:35] <Kano> haha, you get better pcs for free ;)
[23:35] <Torgoton> This machine has 36MB RAM, but I paid a lot for it... when it was new... 15 years go.
[23:36] <Kano> now you have to pay when you want to give it back ;)
[23:36] <Torgoton> It's a ThinkPad 750P, and I have Woody on it, and the netboot files for Dapper, Edgy, Feisty and Gutsy, and I can load each of them with Lilo.
[23:36] <Torgoton> indeed, kano!
[23:38] <ln-> insignificantly small number of people run ubuntu on 486, i doubt anyone cares to investigate and fix your problem.
[23:38] <Torgoton> In-, do you need a hug? Where's the holiday spirit?
[23:38] <Torgoton> If anyone else cares, here's the Gutsy crash output: http://paste.ubuntu-nl.org/49098/
[23:40] <ln-> i'm only telling the facts.
[23:40] <Torgoton> Where I'm from, programmers tend to like challenges, especially low-level programmers... like the kind who would know about CPU initialization.
[23:44] <johanbr> Torgoton: I think your best best might be to build your own minimalistic kernel and see if the error still occurs.
[23:45] <JanC> I remember that mdz (I think it was him?) ran Ubuntu on a soekris in the past
[23:45] <JanC> but that might have been dapper or even an older version  ;)
[23:46] <JanC> Torgoton: is this a real 486 _with_ FPU ?
[23:46] <Torgoton> janc, it's a 486SL which is supposed to have the FPU.
[23:47] <JanC> hm, SL ?  I would have to check what that was again  ツ
[23:47] <Torgoton> I'm pretty technical (i've written i960 initialization code years ago), and a long-time linux use, but mostly with Fedora.
[23:47] <Torgoton> so I am comfortable running suggested commands and capturing logs.
[23:48] <JanC> ah, 486SL = low power 486DX, yeah, that should have a FPU I guess
[23:48] <Torgoton> and as I wrote, Dapper and Edgy boot fine (except for the keyboard thing)
[23:50] <JanC> AFAIK the -386 kernel is compiled with the 486DX as lowest supported CPU in mind
[23:51] <Torgoton> (and yet they call it the 386 kernel :) )
[23:51] <JanC> IIRC it's impossible to make a secure i386 kernel
[23:52] <JanC> some bug in that CPU  ;)
[23:52] <Torgoton> What?! a bug? in the CPU?!?
[23:54] <JanC> "invalid opcode" → sounds like it tries to do something not supported by your CPU ?
[23:55] <JanC> I know nothing more about it  ツ
[23:55] <Torgoton> well, I'll capture the Feisty output and see what's different.
[23:56] <Torgoton> BTW, anyone know the kernel parameter to make it not mess with the keyboard? Is it keyboard=reset or something like that?
[23:56] <JanC> how does it mess with the keyboard?  ツ
[23:57] <Torgoton> I type shift, and it shows "v"... the arrows, tab, space and enter don't work in the installer.
[23:57] <JanC> and it doesn't do that with debian?
[23:57] <Torgoton> not with Woody.
[23:58] <Torgoton> 2.2.20 kernel
[23:58] <JanC> I wonder if this is just a weird keyboard and recent kernels just don't include support for it anymore (at least by default) ?
[23:58] <Kano> Torgoton: maybe 486SX?
[23:58] <Torgoton> Kano, nope. 486SL.
[23:59] <JanC> Kano: 486SL has all DX features + some power saving features, according to wikipedia


[02:57] <furkan> is dpms broken in Wily for anybody else? i just noticed it today so i think it might have been a recent update
[02:57] <furkan> i recall the same thing happened to me with 15.04 and it turned out to be a kernel bug which was fixed in short order
[02:59] <furkan> so i'll probably try a different kernel but just thought i'd check to see if it's a known bug


[01:55] <RAOF> Would you believe it?    There goes the flickering!
[03:30] <DanaG> okay, so I got the magic trackpad... and it doesn't scroll or anything.
[03:32] <DanaG> Is something I should go to #ubuntu for?
[03:38] <RAOF> It should do 2, 3 & 4 finger gestures under Unity, IIRC.
[03:40] <DanaG> ah, what I'd want is the same as regular Synaptics, at least.
[03:40] <RAOF> You *should* be able to get synaptics to claim it by judicious editing of config files; you'll lose gesture support there, though.
[03:41] <DanaG> Scrolling (2-finger and/or edge, though Gnome devs think nobody could possibly ever want both), and middle and right button are most important.
[03:41] <RAOF> I _think_ gesture support should handle 2 finger scroll, though.  Again, only under Unity
[03:41] <DanaG> Stupid apple... 2-finger right-click, but where the heck's my MIDDLE button?
[03:41] <DanaG> I use middle way more than I use right, when browsing.
[03:42] <DanaG> Oh, and when I hold the lower edge, all movement stops.
[03:43] <DanaG> Correction: as long as two fingers are on the board, literally nothing happens when I move the fingers.
[04:32] <bjsnider> DanaG, what device is this?
[04:34] <DanaG> Magic Trackpad.
[04:40] <DanaG> I won't go to +1 until I can get... ATI driver... to work with new X server.
[04:50] <RAOF> fglrx?  We haven't got a new X server in Natty yet.
[04:53] <DanaG> hmm, is there anything else significantly new in natty, anyway?
[04:53] <RAOF> Well, new kernel.
[04:53] <RAOF> (Slightly) newer mesa.
[04:53] <RAOF> New -intel,...
[04:53] <DanaG> Radeon uses too much power... runs warm and noisy.
[04:54] <DanaG> Random aside: why is it even called a "trackpad", anyway?  You touch it, not track it!
[04:54] <DanaG> I'm tracking my mouse.... oops, it got away!
[04:54] <RAOF> Even if you set dynpm?
[04:54] <DanaG> Yeah, last time I checked, dynpm didn't use lowest-power modes, and even with fixed low, it still uses like 8 watts more than fglrx.
[04:55] <DanaG> Hey, if a trackpad is called such because it "tracks" you... then we should call webcams WATCHcams, because they WATCH you. =þ
[04:56] <DanaG> ah, I'm switching the "magic" thing to Synaptics.
[04:58] <DanaG> Regression with the change from hal to xorg.conf.d: changing .conf file doesn't take effect merely by reattaching device!
[05:00] <DanaG> Well, either that, or the 60-magictrackpad.conf isn't what defines the driver.
[05:00] <DanaG> I changed it to say synaptics, and it's still using udev.
[05:01] <RAOF> evdev, you mean.
[05:01] <DanaG> er, yeah.
[05:02] <DanaG> Say, does using /etc/X11/xorg.conf.d still break everything by making it ignore /usr/share/X11/xorg.conf.d/ ?
[05:03] <RAOF> I don't think so.
[05:03] <DanaG> I created a new file (61) with identifier "Magic Trackpad, damnit"... and it doesn't use the file.
[05:04] <DanaG> I used to be able to do this for synaptics: change the fdi file, then unload and reload psmouse.
[05:05] <DanaG> Well, time to ctrl-alt-backspace, then.  grr.
[05:09] <DanaG> Okay, restart did it... though now i'm screwed by the "can't have both" limitation.
[05:10] <DanaG> Built-in touchpad won't do multi-finger... so I get edge scrolling with magic.
[05:10] <DanaG> Well, it WILL do multifinger with exactly one Windows driver that seems to patch the firmware.... and some people refuse to believe that that could possibly be true.
[05:10] <RAOF> Magic should do two finger scroll with Synaptics I believe.
[05:11] <DanaG> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/546697
[05:11] <RAOF> Although cnd is the guy with the hardware, who wrote the driver, and who's doing the multitouch implementation :)
[05:11] <ubot4> Launchpad bug 546697 in xserver-xorg-input-synaptics (Ubuntu) "enable multitouch support on older touchpads, as supported by driver v<IP_ADDRESS> (dup-of: 554980)" [Medium,Confirmed]
[05:11] <ubot4> Launchpad bug 554980 in xserver-xorg-input-synaptics (Ubuntu) "Two finger scroll not working on all old touchPads (emulation approach). (affects: 30) (dups: 3) (heat: 141)" [Medium,Confirmed]
[05:12] <DanaG> RAOF: the problem is that Gnome won't let me enable BOTH types of scrolling at once.
[05:12] <DanaG> And those damn developers: the special windows driver IS NOT FREAKING EMULATION!
[05:12] <RAOF> I'd guess you could probably twiddle the properties yourself with xinput
[05:13] <DanaG> RAOF: tried that... gnome later resets it.
[05:13] <DanaG> If I have gpointing-device-settings installed, I get enable...disable...enable...disable...enable every second or so.
[05:13] <RAOF> Sweet!
[05:16] <DanaG> I hate those devs that REFUSE to accept that a driver could ever possibly patch the firmware!
[05:17] <DanaG> wait, in that thread, the person is not a dev.
[05:18] <DanaG> But in the other discussion... the one where the person sniffed the PS/2 traffic of the new touchpads, all I wanted was them to try that sniffing with the special driver.
[05:19] <DanaG> Really hackish thing I'm considering trying: sniffing PS/2 traffic with my Xilinx board, and dumping it over serial.
[05:20] <DanaG> Sorry about the rant.
[05:21] <DanaG> Anyway: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/467258
[05:21] <ubot4> Launchpad bug 467258 in gnome-settings-daemon (Ubuntu) (and 2 other projects) "Touchpad: simultaneous two-finger and edge scrolling (affects: 3) (heat: 17)" [Wishlist,Triaged]
[05:26] <DanaG> I must say, wouldn't Synaptics as default have been a better default for the Magic?
[05:27] <DanaG> Anyway, I'm off to go try the thing with Windows.
[05:27] <DanaG> Got it for work, mainly... and they use Windows.
[07:00] <DanaG> I hope we can at least get drivers to the level of NVIDIA, or preferably, fglrx, in terms of packaging.
[07:00] <DanaG> Some day, I mean.
[07:01] <RAOF> In terms of packaging?
[07:02] <DanaG> Yeah.  Can't beat: ./ati-driver-installer-whatever.run --buildpkg Ubuntu/maverick
[07:02] <RAOF> Ah.
[07:02] <RAOF> Well, I think you can; the edgers PPA is pretty kickarse.
[07:03] <DanaG> I mean for arm, though.
[07:03] <DanaG> Does edgers do that?
[07:03] <RAOF> When the ARM ppa buildds are up, yes.
[07:06] <DanaG> Spiffy.  So no more asking TI for permission?
[07:07] <DanaG> For me, 99% of my 3D stuff in Linux is compiz.  It just doesn't feel as nice without it.
[07:07] <RAOF> Oh, permission to redistribute their drivers?  Ah.  Different question.
[07:07] <RAOF> They *do* have a PPA for it already, I think.
[07:07] <RAOF> At least for the OMAP boards.
[07:08] <DanaG> Last time I used a beagle, you had to download a huge package from TI, and then use their failure of a build script.
[07:09] <DanaG> "make" did "make clean" on a hardcoded target dir that didn't exist.
[07:18] <DanaG> For me, 90% of the 3D stuff I do in Linux is Compiz, so GLX is mandatory.
[07:19] <DanaG> Oh, and oddly enough, last time I checked power usage on battery with ATI binary, it was lower WITH Compiz and Aero than without!
[07:22] <RAOF> Not totally odd; you get less redraw with a compositing manager.
[07:23] <DanaG> I'll have to try Radeon on alpha... If power usage is tolerable, I may switch.
[07:23] <RAOF> Actually drawing stuff and then blitting a texture costs more than blitting a texture :)
[07:23] <DanaG> The difference between fglrx and Radeon was like 10 watts.
[07:24] <DanaG> All those silly people who recommend disabling it...
[07:24]  * RAOF wonders if he's mentioned that fglrx has more lines of power management code than the radeon kernel module, mesa driver, and DDX in total?
[14:04] <hyperair> Sarvatt: it seems compiz is hanging at another X call now.
[14:04] <hyperair> http://paste.debian.net/101860/
[14:33] <Sarvatt> hyperair: so what happens, it just hangs?
[14:43] <hyperair> Sarvatt: yep, compiz hangs, X hangs.
[14:43] <hyperair> no wait
[14:43] <hyperair> compiz hangs
[14:43] <hyperair> X doesn't hang
[14:43] <hyperair> killing compiz brings X back
[14:43] <Sarvatt> it might be useful to attach to the X process and get a bt there
[14:43] <Sarvatt> ah
[16:02] <hyperair> Sarvatt: does xorg-edgers have pixman dbgsyms?
[16:02] <hyperair> ah it does
[16:03] <Sarvatt> -dbg yeah
[16:03] <hyperair> Sarvatt: it seems that Xorg is stuck in libpixman
[16:03] <hyperair> and compiz is stuck waiting on XGetWindowProperty again
[16:03] <Sarvatt> what libx11 again?
[16:06] <hyperair> Sarvatt: http://paste.debian.net/101876/
[16:06] <hyperair> Sarvatt: the one from xorg-edgers maverick?
[16:07] <hyperair> Installed: 2:1.3.4+git20100720.554da76e-0ubuntu0sarvatt4
[16:15] <Sarvatt> hyperair: you use a dock?
[16:15] <hyperair> Sarvatt: yes i do. docky.
[16:15] <Sarvatt> on the left side of the screen like unity?
[16:16] <hyperair> yep
[16:16] <hyperair> wait, how did you know?
[16:16] <hyperair> O_o
[16:16] <Sarvatt> yah looks like its just drawing that, nothing odd there
[16:16] <hyperair> you could tell that from the backtrace?
[16:16] <Sarvatt> yep
[16:16] <hyperair> hmm
[16:16] <hyperair> but it hung there?
[16:17] <Sarvatt> the last thing it drew I'm guessing
[16:18] <hyperair> li see.
[16:19] <hyperair> how strange.
[16:19] <Sarvatt> i'm not seeing any obvious locking problems at least :(
[16:23] <hyperair> =\
[16:23] <hyperair> but XGetWindowProperty shouldn't block
[16:23] <hyperair> meaning it's not compiz's fault, or is it? =\
[16:23] <hyperair> hmm
[16:24] <Sarvatt> do you have a backtrace of the hang with  libxcb1-dbg installed by any chance?
[16:27] <hyperair> nope
[16:28] <hyperair> oh yeah, it particularly likes happening when i'm busy killing indicator-applet
[17:10] <Azelphur> bryceh: been trying for a while to figure out how to get ubuntu-bug to work, tried asking in ubuntu-uk and they told me to use apport-collect which just says "no additional information collected" so I'm kinda stuck with providing the ubuntu-bug info you wanted :(
[17:10] <Azelphur> been trying to do it since yesterday
[17:10] <Azelphur> I did file the bug though, https://bugs.launchpad.net/xorg-server/+bug/687412
[17:10] <ubot4> Launchpad bug 687412 in ubuntu (and 1 other project) "X crashes after a while on 9500GT in arecord (affects: 1) (heat: 6)" [Undecided,New]
[17:36] <apw> bryceh, Sarvatt, where are we with nouveau and 3d ?
[17:37] <apw> its not going to be there any time soon i assume?
[19:16] <bryceh> apw, it depends...  we've been discussing it but it's be easier to decide, if upstream was supporting it
[19:16] <apw> bryceh, does that mean it is even an option?
[19:25] <Azelphur> bryceh: https://bugs.launchpad.net/ubuntu/+bug/687412 I filed that bug, someone marked it as invalid for some reason
[19:25] <ubot4> Launchpad bug 687412 in ubuntu (and 1 other project) "X crashes after a while on 9500GT in arecord (affects: 1) (heat: 6)" [Undecided,Invalid]
[19:26] <Azelphur> I couldn't get ubuntu-bug to work, spent a day trying and asked in ubuntu-uk, they told me to use apport-collect that didn't work either, not my day :(
[19:29] <tjaalton> you didn't specify the package
[19:29] <Azelphur> ah
[19:29] <Azelphur> don't remember it asking me to specify a package when filing
[19:30] <Azelphur> I did set it to also effects X.Org though
[19:30] <tjaalton> it's not a package, but a project
[19:30] <Azelphur> oh
[19:31] <Azelphur> tjaalton: how do I set a package?
[19:37] <tjaalton> choose the ubuntu project and enter the name?
[19:38] <Azelphur> tjaalton: I clicked also affects project typed ubuntu in the box and it says there is no project named Ubuntu
[19:38] <Azelphur> I tried using the search, it says there are too many projects with the name Ubuntu
[19:38] <tjaalton> nbo
[19:38] <tjaalton> no
[19:38] <tjaalton> it lists "ubuntu" there because you didn't say which package had the bug
[19:38] <tjaalton> forget the projects
[19:39] <Azelphur> :S
[19:39] <tjaalton> click ubuntu, enter the name of the package
[19:39] <Azelphur> ah
[19:40] <tjaalton> dunno what to think of the backtrace
[19:40] <tjaalton> it's looping somehoe
[19:40] <Azelphur> and the package name is xserver-xorg, should I change it's status too?
[19:40] <tjaalton> w
[19:40] <Azelphur> tjaalton: bryceh said it could be caused by arecord triggering an event which it hooks creating a loop
[19:40] <Azelphur> iirc
[19:41] <tjaalton> so the server didn't crash, but it's flooded?
[19:41] <Azelphur> yes it crashes, I drop back to gdm
[19:42] <tjaalton> is it immediate?
[19:42] <Azelphur> tjaalton: nope, it takes a while
[19:43] <tjaalton> so the real bug is what triggers the loop
[19:43] <tjaalton> the server then runs out of resources or so. that could be an nvidia bug
[19:44] <tjaalton> but the backtrace is pretty much useless
[19:44] <Sarvatt> we never saw anything in the logs that it was actually a crash though the other day, its still possible that it could just be some oddball mythtv session stuff dropping it back to login for some reason
[19:44] <Azelphur> Sarvatt: surely if gdb picks up on the crash it's a crash and not a proper exit
[19:45] <Azelphur> also this issue doesn't happen with the old graphics card I had in there (6600GT)
[19:45] <tjaalton> the same driver?
[19:46] <Azelphur> I think the 6600 uses an older nvidia driver, so before I upgraded I used jockey to deactivate the driver, installed the 9500, then used jockey again
[19:46] <Sarvatt> X sends lots of signals gdb stops on..
[19:48] <Azelphur> I could try swapping the 9500 back out with the 6600
[19:48] <Azelphur> to see if it still happens
[19:49] <tjaalton> you said on the bug that you don't know what triggers it?
[19:49] <Azelphur> that's right, it happens at random
[19:49] <tjaalton> just like the best bugs should
[19:49] <Azelphur> haha, I know it's a terrible description
[19:50] <Azelphur> but it happens when the keyboard is on the other side of the room with nobody nearby
[19:50] <Azelphur> there's no pattern to it I can see as of yet, I will keep trying to figure it out though
[19:50] <Azelphur> as I say I plan on stopping x11vnc which should stop arecord from being enabled so I can see if that stops it from happening, and switching back to the 6600 to see if that stops it
[19:50] <Azelphur> and I want to start logging the times of the crashes
[19:51] <bryceh> apw, yes, it's an option
[19:55] <Azelphur> tjaalton: should I change the status from invalid to new again when specifying a package?
[19:58] <bryceh> Azelphur, I already did
[19:58] <Azelphur> bryceh: ty :D
[19:58] <bryceh> it probably got set as invalid because it didn't have a detailed enough description
[19:59] <Azelphur> yea, I admit the description was crap but I don't have a lot to go on
[19:59] <Azelphur> getting the files you requested now :)
[20:01] <bryceh> we get so many bugs, that developers tend to focus on bugs that have good descriptions and complete log information, and it's fairly plain how the bug comes about
[20:07] <Sarvatt> too bad it's not reliably happening 1 minute after login like it is for these people http://ubuntuforums.org/showthread.php?t=1612704
[20:07] <Sarvatt> they have nothing in their logs either
[20:09] <Sarvatt> Azelphur: try passing -noxrecord to x11vnc?
[20:09] <Sarvatt> no clue how its starting in mythbuntu
[20:09] <Azelphur> yea was just about to say I should try that :)
[20:10] <Azelphur> probably in init.d or something, I'll find it :p
[20:11] <Sarvatt> grep -R x11vnc /etc/
[20:12] <Azelphur> it's one attachment per comment right?
[20:13] <Azelphur> Sarvatt: it's not in there, easy enough for me to find I know the maintainer of mythbuntu quite well, I can prod him :)
[20:13] <Sarvatt> apport-collect -p xorg 687412 ?
[20:15] <Azelphur> Sarvatt: haha, I tried to use that in the first place but didn't know that I needed to specify a package, that explains why I never got it to work. Running it now :)
[20:15] <Sarvatt> yeah it's not documented very well :(
[20:16] <Sarvatt> or at all
[20:16] <vish> is it OK to keep getting "Program received signal SIGPIPE, Broken pipe." http://paste.ubuntu.com/541127/ ? it seems to be occurring when opening/closing animations with compiz..
[20:16] <vish> seems i am noticing this because i'm debugging X, but during normal usage it would just be like a fraction of a sec stuck and then starting of the animation
[20:16] <Sarvatt> vish: handle SIGPIPE nostop
[20:16] <Azelphur> Sarvatt: that gives him all the files he asked for, right?
[20:17] <Sarvatt> Azelphur: yea
[20:17] <Azelphur> cool
[20:17] <vish> Sarvatt: ah , will all that arg , but is that normal? or should it not be doing that?
[20:17] <Sarvatt> vish: yep its normal
[20:17] <vish> cool..
[20:17] <Azelphur> next on my list is to try with -noxrecord then to see if that stops it from happening.
[20:18] <Sarvatt> vish:  you want to nostop on SIGUSR1 and SIGUSR2 too or it'll stop on input events and stuff
[20:19] <vish> Sarvatt: ok, sure, thanks..  this SIGPIPE seems more common for me.
[21:00] <Sarvatt> Azelphur: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/525066
[21:00] <ubot4> Launchpad bug 525066 in xorg-server (Ubuntu) "x11vnc able to segfault xorg (affects: 2) (heat: 23)" [High,Triaged]
[21:21] <Azelphur> Sarvatt: looks like the same crash but mine happens at random while the machine is logged in, nothing to do with the login screen
[21:21] <Azelphur> I can try to reproduce that bug though :)
[21:22] <Sarvatt> they're just saying to boot it up to the login screen not that the login screen has any significance to it from how I read it
[21:22] <Azelphur> so they are saying X crashes as soon as the open a VNC session?
[21:32] <Patricia> ola
[21:32] <Patricia> ingles ou portugues?
[21:32] <Patricia> Hi
[21:32] <Patricia> English our Portuguese?
[21:33] <Patricia> because the intel video card, hangs with compiz?
[21:33] <Patricia> 82945G/GZ
[22:13] <RAOF> apw: Nouveau 3D status is roughly what it was for Maverick - installing libgl1-mesa-dri-experimental will get you 3D, it'll probably work, but kindly don't bug anyone if it doesn't.
[22:14] <RAOF> apw: One difference is that we've enabled the 3D driver for the old cards (TNT2 → Geforce3) in the most recent mesa upload.
[22:15] <apw> RAOF, thanks
[22:16] <RAOF> We should also look at jocky-ifying libgl1-mesa-dri-experimental, so it's presented to users as an alternative to the binary blob.
[22:21] <apw> RAOF, thats an interesting idea
[22:22] <RAOF> Should be relatively simple too, and allow users to try Unity on the livecd.
[23:10] <Sarvatt> Azelphur: I think I might have a patch for you to try
[23:16] <Sarvatt> Azelphur: uploading it to https://launchpad.net/~sarvatt/+archive/green, will take an hour or so to show up
[23:17] <Sarvatt> http://patchwork.freedesktop.org/patch/2166/
[23:23] <Sarvatt> Azelphur: heading out for the night, let me know how it goes if you get a chance to test it
[23:25] <Patricia> because the intel video card, hangs with compiz? 82945G/GZ
[23:26] <RAOF> Patricia: That card should work; could you provide more details, like: What Ubuntu release are you using?  How often does compiz hang?  What, exactly, happens when compiz hangs?
[23:27] <Patricia> Ubuntu 9.10
[23:27] <Patricia> our
[23:27] <Patricia> Ubuntu 10.04
[23:27] <Patricia> our
[23:27] <Patricia> Ubuntu 10.10
[23:27] <Patricia> latch completely
[23:27] <Patricia> whatever version ubuntu 9.10 after hangs
[23:28] <Patricia> to return the computer, just restarting the reset button
[23:29] <Patricia> the period of catch is about 5 seconds after activating compiz
[23:29] <Patricia> everyone who has this video card does not work, compiz
[23:30] <Patricia> :/
[23:42] <JanC> I have 2 laptops with (a variation of) that videocard which seem to work okay
[23:43] <JanC> it's probably the most-used GPU ever...
[23:43] <Patricia> Unfortunately all they are activating compiz, this fighting, I collect data from other users of that board in #ubuntu-br
[23:43] <Patricia> and does not work
[23:43] <JanC> Patricia: is this with the default compiz settings?
[23:44] <Patricia> ¬¬
[23:44] <Patricia> or not the time to fiddle around
[23:45] <Patricia> you activate the effect and already hangs
[23:45] <Patricia> yes default settings


[01:45] <mup> PR snapcraft#2638 closed: remote-build rebased on 3.7 <Created by cjp256> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2638>
[04:44] <mup> PR snapd#7149 opened: cmd: add snap model command; daemon: add /v2/model, /v2/model/serial REST APIs <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7149>
[05:16] <mborzecki> morning
[05:49] <mborzecki> zyga: mount-ns test failed in pedronis' #7147, i've restarted the job, but in case you want to inspect the log it's here: https://paste.ubuntu.com/p/VYHQhc6zhQ/
[05:49] <mup> PR #7147: client,cmd/snap: stop depending on status/status-code in the JSON responses in client <Created by pedronis> <https://github.com/snapcore/snapd/pull/7147>
[06:14] <mborzecki> rawhide daily cloud compose doesn't even boot on GCE :/
[06:24] <mborzecki> zyga: nvm, i looked at the log and it's /run/netns leaking which should already be fixed in master
[06:34] <zyga> good morning
[06:34] <zyga> mborzecki: I saw a failure last night, something leaks another mounted core
[06:35] <zyga> looking at the log now
[06:35] <zyga> mborzecki: hmm, odd, it is netns
[06:35] <zyga> I'll look
[06:35] <mborzecki> zyga: btw. that's how rawhide compose boots on GCE: https://paste.ubuntu.com/p/kKMwb6zgFW/
[06:36] <zyga> mborzecki: quickly :D
[06:36] <mborzecki> zyga: haha
[06:41] <zyga> I have an idea on how to find broken tests
[06:41] <zyga> But let me get coffee first
[06:44] <zyga> We can use something like HOST.txt to ensure the mount table is not corrupted at each step
[06:44] <zyga> I wish diff had a “first like difference” more
[06:44] <zyga> mode*
[06:58]  * zyga runs a quick test to look for leaky netns
[07:02] <zyga> hey pedronis, mvo
[07:06] <pedronis> zyga: here mount-ns failed: https://api.travis-ci.org/v3/job/562563021/log.txt  need to merge master?
[07:06] <mvo> hey zyga
[07:06] <zyga> pedronis: I'm debugging that, I assumed master _was_ merged and that some other test is leaking netns
[07:06] <zyga> pedronis: which PR is this?
[07:07] <zyga> pedronis: (that as in I got pinged by mborzecki earlier today and I'm running a scan of all the tests for netns leaking)
[07:07] <pedronis> completely innocent one, the ones that does make(chan error, 1)
[07:07] <zyga> ah, I remember it
[07:07] <zyga> give me 30 minutes please
[07:09] <pedronis> we have various red (many for different reasons)
[07:12] <zyga> brb
[07:17] <zyga> re
[07:45] <zyga> hmm, I ran a pass through all tests on Xenial, nothing leaked netns
[07:45]  * zyga checks the logic
[07:45] <zyga> pedronis: your PR must have the netns unmount patch landed before the mount-ns test landed
[07:46] <zyga> so I must be missing something
[07:46] <pedronis> I can try to merge master in it again, if that might help
[07:47] <pedronis> zyga: another one failed on mount-ns
[07:47] <pedronis> https://api.travis-ci.org/v3/job/562748283/log.txt
[07:48] <pedronis> also recent
[07:49] <zyga> oh, that's odd
[07:49] <zyga> something remounted /dev/pts
[07:50] <zyga> different mode, different gid
[07:50] <zyga> oh boy :)
[07:50] <zyga> our tests are doing interesting stuff
[07:51] <pedronis> I know snap-confine does things with dev/pts
[07:51] <pedronis> I don't see it mentioned in the yaml
[07:51] <zyga> not on the host
[07:51] <zyga> this is the HOST filesystem
[07:52] <zyga> nothing should change that
[07:52] <mvo> zyga: 7148 also fails in mount-s
[07:53] <mvo> zyga: mount-ns with the unified cgroup being "nsdelegate"
[07:53] <zyga> hmmm, perhaps I should switch it to manual
[07:53] <zyga> it seems there are lot of tests that leak here and there
[07:53] <zyga> and running the test dozens of times before was not enough
[07:53] <zyga> ideally I'd run a sequence of (a, mount-ns) for a in all tests
[07:53] <mvo> and fails on ubuntu-core-16 with a bigger diff
[07:54] <pedronis> yea, seems premature to have it on
[07:57] <zyga> https://github.com/snapcore/snapd/pull/7150
[07:57] <mup> PR #7150: tests: switch mount-ns test to manual <Created by zyga> <https://github.com/snapcore/snapd/pull/7150>
[07:57] <zyga> please merge it
[07:58] <mup> PR snapd#7150 opened: tests: switch mount-ns test to manual <Created by zyga> <https://github.com/snapcore/snapd/pull/7150>
[08:02] <mborzecki> at least it's good that we're catching things
[08:04] <ogra> mvo, pedronis do we have a way to use the force-reboot in snapd for non-snap upgrades ... it just struck me that we allow "snap set system someconfigtxt-option foo" on RPi which should theoretically always use a reboot to make the bootloader config change active
[08:05] <pedronis> ogra: only upgrades of core or kernels reboot atm
[08:05] <mborzecki> jdstrand: worked on the idea from your blog post about preparing images for local spread, came up with this cloud init config https://gist.github.com/bboozzoo/f14302d4fc3418200fe28a2d547d3780
[08:05] <ogra> right, but is it a function that could easily be used here ?
[08:05] <pedronis> not without some thinking/design
[08:06] <pedronis> it strange to schedule a reboot from just a set
[08:06] <ogra> ah. k
[08:06] <ogra> sure, but in this case it is a bootloader config you are changing
[08:07] <zyga> mvo: you mentioned that Sergio had a branch of spread that can run a sequence without randomised fuss?
[08:08] <pedronis> zyga: yes, he spoke about it, you probably can ask him were it lives, don't know if there's PR
[08:08] <pedronis> or it's just local to him
[08:31] <Chipaca> mvo: gentle reminder about #7142
[08:31] <mup> PR #7142: boot, o/snapst, o/devicest: limit knowledge of boot vars to boot <Created by chipaca> <https://github.com/snapcore/snapd/pull/7142>
[08:31] <Chipaca> ubuntulog2: ubuntulog3: WAT
[08:31] <zyga> jamesh: ack, I'll look
[08:31] <mborzecki> zyga: finally running the whole suite locally with fedora rawhide image
[08:31] <jamesh> thanks
[08:31] <zyga> jamesh: thank you :)
[08:32] <jamesh> zyga: I've updated the icon theme PR now that EnsureTreeState is merged.  Once it passes CI, it is probably ready for a real review.
[08:32] <zyga> jamesh: super
[08:32] <zyga> mvo: https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=snapd :-(
[08:33] <pedronis> jamesh: thanks
[08:33] <zyga> jamesh: I see what happened there, it's my fault, sorry; I'll re-trigger it after the new test is disabled
[08:37] <zyga> two more buggy tests found
[08:45] <mup> PR snapd#7151 opened: tests: remove local revision of core <Created by zyga> <https://github.com/snapcore/snapd/pull/7151>
[08:45] <mup> PR snapd#7152 opened: tests: unmount leftover /run/netns <Created by zyga> <https://github.com/snapcore/snapd/pull/7152>
[08:46] <zyga> Chipaca, pedronis: ^ those are the two leakers
[08:47]  * zyga looks for more
[08:59] <mborzecki> ehh, why does spread not include -smp <some-reasonable-number> in qemu command line
[09:01] <zyga> mborzecki: I patched my local build but yeah
[09:01] <zyga> mborzecki: also "kvm" is a debian specific thing, I don't have it on suse
[09:01] <mborzecki> zyga: heh, have a wrapper :P
[09:55] <mup> PR snapd#7150 closed: tests: switch mount-ns test to manual <Created by zyga> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7150>
[10:01] <mup> PR snapd#7153 opened: gadget: select the right updater for given structure <Gadget update> <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7153>
[10:04] <zyga> Chipaca: https://github.com/snapcore/snapd/pull/7151/files updated
[10:04] <mup> PR #7151: tests: remove local revision of core <Created by zyga> <https://github.com/snapcore/snapd/pull/7151>
[10:05] <zyga> found two more leaky tests
[10:10] <Chipaca> zyga: what happens if you force the mount-ns test to run after everything else?
[10:10] <zyga> Chipaca: how do I force it?
[10:10] <zyga> Chipaca: I didn't try but I'm working around the issue by running a variant of that test in prepare/restore logic
[10:10] <zyga> it triggers instantly on flaky tests
[10:11] <zyga> I'm expanding how much I measure so that I can fix issues one by one rather than see a wall of tests to look at
[10:11] <Chipaca> zyga: priority: 1 or something?
[10:11] <zyga> Chipaca: uh?
[10:11] <Chipaca> ah
[10:11] <zyga> no idea
[10:11] <Chipaca> zyga: priority: -100
[10:11] <Chipaca> zyga: default priority is 0
[10:11] <Chipaca> zyga: bigger numbers → runs earlier
[10:11] <zyga> I can try
[10:11] <Chipaca> zyga: negative numbers are supported
[10:12] <zyga> thanks for the idea :)
[10:12] <Chipaca> this is backwards from what i'd expect of a priority, but it's documented :-)
[10:12] <Chipaca> zyga: https://github.com/snapcore/spread/#ordering-tasks
[10:16] <mup> PR snapd#7154 opened: packaging/debian-sid: merge debian upload changes back into master <Created by mvo5> <https://github.com/snapcore/snapd/pull/7154>
[10:28] <mup> PR snapcraft#2637 closed: unit tests: make lifecycle tests more robust <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2637>
[10:30] <mup> PR snapd#7152 closed: tests: unmount leftover /run/netns <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7152>
[10:31] <mup> PR snapcraft#2539 closed: errors: Add InvalidAppCommand errors for non-existent and not-found <Created by clobrano> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2539>
[10:32] <clobrano> \0/
[11:07] <mborzecki> hm gadget updates is down to 2-3 patches at most now (not counting snap-image)
[11:09] <mup> PR snapd#7155 opened: tests: remove locally installed core in more tests <Created by zyga> <https://github.com/snapcore/snapd/pull/7155>
[11:15] <mborzecki> pedronis: https://github.com/snapcore/snapd/pull/7147 is green, merge?
[11:15] <mup> PR #7147: client,cmd/snap: stop depending on status/status-code in the JSON responses in client <Created by pedronis> <https://github.com/snapcore/snapd/pull/7147>
[11:16] <pedronis> mborzecki: yes, please
[11:16] <mup> PR snapd#7147 closed: client,cmd/snap: stop depending on status/status-code in the JSON responses in client <Created by pedronis> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7147>
[11:25] <pedronis> thx
[11:26] <Chipaca> 1hr18min travis run
[11:26] <Chipaca> go, worker, go!
[11:26]  * Chipaca ⇝ lunch
[12:06] <mborzecki> anyone seen this? https://paste.ubuntu.com/p/4KyGXgvXpy/ initialize-device failing on f31 in some weird way
[12:08] <ogra> why would f31 (assuming classic) do initialize-device at all ?
[12:08] <pedronis> ogra: ?
[12:09] <ogra> isnt that a core thing ?
[12:09] <pedronis> no, it's classic too
[12:09] <ogra> oh, i'm mixing it up ...
[12:09] <ogra> sorry
[12:09] <pedronis> both seeding and registration exist both on classic and core
[12:10] <ogra> yeah
[12:13] <zyga> mborzecki, pedronis: is that sensitive to gpg on the system?
[12:13] <mup> PR snapcraft#2639 opened: deprecations: add deprecation notice for version-script (dn10) <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2639>
[12:14] <pedronis> zyga: no, we don't use gpg on prod system, only the development tooling
[12:14] <pedronis> uses it
[12:14] <pedronis> we use ssh-keygen though
[12:14] <pedronis> I think
[12:15] <zyga> aha
[12:17] <pedronis> a 2nd review of #7128 would be great (it's small but might need somebody that looked at remodeling code before)
[12:17] <mup> PR #7128: overlord: DeviceCtx must find the remodel context for a remodel change <Remodel :train:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7128>
[12:24] <mup> PR # closed: snapd#7142, snapd#7143, snapd#7145, snapd#7148
[12:31] <mup> PR snapcraft#2640 opened: cli: improve help for push-metadata <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2640>
[12:34] <mup> PR snapcraft#2641 opened: ant plugin: correct default channel and improve help <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2641>
[12:53] <ijohnson> pedronis: thanks for the review on 7149
[12:54] <ijohnson> pedronis: do you have any recommendations on how to test actually remodelling? is there an easy way to do so on classic, or should I build my own core image with a self signed model assertion and then update the model assertion?
[12:55] <pedronis> ijohnson: it's complicated in both cases, we don't let remodel devices that don't have a serial
[12:57] <pedronis> well that might be overstating it, but interesting kind of remodeling probably don't work or shouldn't without a serial
[13:01] <pedronis> ijohnson: btw regarding output of snap commands, Chipaca is probably the best person to discuss things with
[13:01] <pedronis> (related to my yaml-like output comments)
[13:01] <ijohnson> ack, thanks
[13:04] <jdstrand> mvo: hey, could you (assign someone to?) respond to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932815
[13:04] <jdstrand> not sure why buster wasn't updated for a newer snapd 2.38 and don't know the plans, otherwise I would've
[13:04] <jdstrand> s/a newer/the newer/
[13:09] <Chipaca> mvo: btw, wdyt? https://bugs.launchpad.net/snapd/+bug/1837460
[13:09] <Chipaca> mvo: (post-standup)
[13:09] <mup> Bug #1837460: snap refresh slows down computer dramatically <snapd:New> <https://launchpad.net/bugs/1837460>
[13:11] <jdstrand> ackk: I haven't circled back around to https://launchpad.net/bugs/1831473, but should today
[13:12] <mup> Bug #1831473: Can't run /usr/bin/systemd-detect-virt from inside snap <maas> <snapd:New for jdstrand> <https://launchpad.net/bugs/1831473>
[13:12] <ackk> jdstrand, hi, thanks!
[13:13] <ackk> jdstrand, btw is there a way to strace a process run from a "snap run --shell" ?
[13:13] <ackk> jdstrand, I've resorted to creating a shell script that basically prints the pid, calls "read" and then execs the actual command, so I can attach with strace, but it's a bit cluncky :)
[13:19] <Chipaca> ackk: no
[13:19] <Chipaca> ackk: because by the time you're in the shell inside you can't strace
[13:26] <mup> PR snapd#7154 closed: packaging/debian-sid: merge debian upload changes back into master <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7154>
[13:41] <mvo> jdstrand: I uploaded 2.40 to unstable now
[13:41] <mvo> jdstrand: but that does not help, does it?
[13:42] <mvo> Chipaca: oh, interessting
[13:42] <mup> PR snapd#7156 opened: packaging/debian: use correct version for apparmor Depends <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7156>
[13:47] <mup> PR snapd#7156 closed: packaging/debian: use correct version for apparmor Depends <Created by jdstrand> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/7156>
[13:51] <jdstrand> mvo: it doesn't help buster, no
[13:51] <mup> PR snapd#7157 opened: packaging/debian-sid: use correct apparmor Depends for Debian <Simple 😃> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7157>
[13:51] <jdstrand> mvo: fyi, https://github.com/snapcore/snapd/pull/7157
[13:51] <mup> PR #7157: packaging/debian-sid: use correct apparmor Depends for Debian <Simple 😃> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7157>
[13:51] <zyga> brb
[13:52] <jdstrand> mvo: (unrelated to that Debian bug. just something I noticed was incorrect
[13:52] <jdstrand> )
[13:52] <mvo> jdstrand: nice
[13:53] <cachio> zyga to use the spread I sent you just use
[13:54] <cachio> do -> spread -order <test list>
[13:54] <cachio> this will execute the tests following the order in the order list
[13:54] <cachio> also you should use -workers 1
[13:55] <cachio> this will make to use 1 worker so you don't need to update hte spread.yaml
[13:55] <cachio> please, tell me if you have any problem
[13:59] <ackk> Chipaca, I see so I guess the script trick is the only way
[14:07] <zyga> re
[14:07] <zyga> cachio: thanks! is your patch close to being merged usptream?
[14:07] <cachio> zyga, no
[14:08] <zyga> oh, why not?
[14:08] <cachio> zyga, need reviews
[14:08] <cachio> there are 2 PR related to this
[14:08] <zyga> understood
[14:08] <cachio> 1 for the order
[14:08] <cachio> 1 for setting the number of workers
[14:09] <cachio> also you can use -show-output if you want to see the output on real time
[14:10] <cachio> zyga, once we are able to run spread tests on google on any PR it will be really easy to add tests for all these features and make sure they work well
[14:11] <zyga> cachio: ping us for reviews
[14:11] <zyga> I'm sure both me and mborzecki would happily review that
[14:12] <cachio> zyga, ok, once I add the tests for validating those features I'll ping you for a review for sure
[14:12] <cachio> mvo, any news about the spread tests on gce?
[14:12] <cachio> is the key enabled?
[14:22]  * zyga takes a break while tests run
[14:25] <mup> PR snapd#7088 closed: tests: manually stop the gvfsd-metadata process <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7088>
[14:28] <mborzecki> zyga: running test 72/353
[14:31] <zyga> 7/350
[14:34] <ogra> =0.02
[15:17] <mup> PR snapd#7146 closed: UC20: cmd/snap-verify: sketch of snap-verify <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/7146>
[15:23] <mup> PR snapd#7146 opened: UC20: cmd/snap-verify: sketch of snap-verify <Created by pedronis> <https://github.com/snapcore/snapd/pull/7146>
[15:24] <Chipaca> did we ever get back to #6679
[15:24] <Chipaca> ?
[15:24] <mup> PR #6679: many: implement user removal <Created by cmatsuoka> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/6679>
[15:29] <mup> PR snapd#7158 opened: tests: part5 making tests work on ubuntu-core-18 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7158>
[15:30]  * cachio lunch
[15:48] <ogra> ARGH !
[15:48] <ogra> so multipass eats 100% CPU after a reboot of my laptop ... since i dont use it anyway (i did a few times though and there are a few GB of images apparently) i thought i'D remove it ...
[15:49] <ogra> ogra@acheron:~$ snap remove multipass
[15:49] <ogra> Save data of snap "multipass" in automatic snapshot set #1                                                    \error: cannot perform the following tasks:
[15:49] <ogra> - Save data of snap "multipass" in automatic snapshot set #1 (tar failed: context canceled)
[15:49] <ogra> ogra@acheron:~$ snap remove --purge multipass
[15:49] <ogra> error: unknown flag `purge'
[15:49] <ogra> (indeed i ctrl-C'ed the first command)
[15:49] <ogra> how do i proceed to get it gone ?
[16:09] <cmatsuoka> Chipaca: not yet, it was preempted by core20
[16:10] <ijohnson> ogra: refresh core snap to edge
[16:10] <ijohnson> then you have --purge
[16:10] <ijohnson> otherwise you can set the core config option to never save snapshots
[16:11] <ijohnson> snap set system snapshots.automatic.retention=no
[16:13] <ogra> ijohnson, ah, thanks ...
[16:14]  * ogra does the latter
[16:25]  * zyga runs some more tests with more checks
[17:11]  * zyga is upset a bit
[17:11] <zyga> checking again
[17:11] <mup> PR snapcraft#2642 opened: remote-build: detect early build errors <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2642>
[17:59] <zyga> yess
[17:59] <zyga> finally
[18:00] <mup> PR snapd#7157 closed: packaging/debian-sid: use correct apparmor Depends for Debian <Simple 😃> <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7157>
[18:40] <zyga> mborzecki: making good progress here :)
[18:41] <zyga> mborzecki: cannot wait to see this pass everything
[18:41] <mborzecki> zyga: hm? hm?
[18:41] <zyga> mborzecki: iterating on the dirty test detector, got it in the right spot now, fixing tests as I go :)
[18:41] <zyga> mborzecki: even the diff it produces is super readable
[18:41] <mborzecki> zyga: aah
[18:42] <mborzecki> zyga: btw. looking at spread logs, lxd seems to have problems with cgroupsv2
[18:43] <zyga> mborzecki: would be worth asking stgraber
[18:44] <mborzecki> zyga: https://paste.ubuntu.com/p/Cz7qszmxPD/
[18:45] <zyga> IO error
[18:45] <zyga> could be anything
[18:45] <zyga> but yeah, worth looking
[18:52] <cachio> zyga, hey, do you know any way to do iptables on core?
[18:52] <cachio> is there a snap for that?
[18:52] <zyga> cachio: I don't know, perhap with one of the newer tools
[18:52] <zyga> but I haven't used any for a very long time
[18:53] <zyga> nftables? not sure
[18:54] <cachio> zyga, I'll try that
[18:54] <cachio> thanks
[18:59] <mup> PR snapcraft#2641 closed: ant plugin: correct default channel and improve help <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2641>
[20:00] <mvo> cyphermox:  quick question about "semaphoreci", I pushed pr#93 to netplan but it needs a new build-dependency - can I add this somehow myself (i.e. is there something equivalent to .travis.yml)
[20:17] <mup> PR snapcraft#2640 closed: cli: improve help for push-metadata <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2640>
[20:50] <zyga> 419/426
[20:50] <zyga> all passed
[20:54]  * zyga tweaks the detector to be more strict and re-runs
[20:54] <zyga> I think now all tests are 100% good in not leaking mounts
[20:54] <zyga> but we'll see
[21:21] <mup> PR snapd#7159 opened: tests: add functions to make an abstraction for the snaps <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7159>
[22:51] <mup> PR snapcraft#2643 opened: project, cli: clean up snap asset messages <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2643>


[00:06] <micahg> mahfouz1: I'll file it as an enhancement request
[00:06] <micahg> it's currently win only
[00:06] <micahg> but they might make it optional on linux
[02:28] <mahfouz1> micahg: yes, would be great, since they might stop some of the add-ons with that functionality
[02:29] <mahfouz1> If it's not implemented in linux, then that functionality might get lost
[05:51] <xangua> hello there, i managed to install official mozilla firefox(from ubuntuzilla) and other mozilla based apps (songbird and flock) in ubuntu, but they dont follow my font settings; is there a way i can fix this¿¿
[05:52] <micahg> xangua: we only support the Ubuntu versions
[05:52] <xangua> i also could see this problem in the mozilla testing build PPA
[05:52] <micahg> xangua: k, there are a few bugs for fonts in firefox-3.5
[05:53] <micahg> which specific font setting?
[05:53] <micahg> half size?
[05:53] <xangua> antilasing
[05:53] <xangua> the font looks ugly :S
[05:53] <micahg> xangua: I think you should look at bug 379761
[05:54] <xangua> micahg: thanks, i'll see it
[05:54] <micahg> xangua: there's also bug 67226
[09:15] <BUGabundo_work> morning
[14:36] <gnomefreak> micahg: you around?
[14:37] <micahg> gnomefreak: yes
[14:37] <gnomefreak> micahg: did you ask me about sunbird/seamonkey ~2-3 weeks ago?
[14:37] <micahg> yep
[14:38]  * micahg still needs to get the -dev packages right
[14:38] <gnomefreak> micahg: ok cool, feel free to package them i have run into some personal problems and they wont be cleard up for atleast 3 more weeks.
[14:38] <micahg> gnomefreak: sorry to hear that
[14:38] <micahg> gnomefreak: I'm a little behind myself (TB3 isn't out yet )
[14:39] <gnomefreak> micahg: its ok it should be easly taken care of just have to wait until i can
[14:39] <gnomefreak> ah
[14:39] <micahg> k
[14:44] <gnomefreak> any plans on grabbing Debians instabird package to include in Lucid?
[14:45] <gnomefreak> looks like Mike is asking -mentors(Debians) to test atm
[14:48] <micahg> gnomefreak: idk, I can ask asac
[14:48] <micahg> there's a lot to do this cycle already with the FF3.6 migration
[14:48] <gnomefreak> micahg: ok thanks, if i see him i will ask him but not sure how long i will be here. i have a whole bunch of emails to clean up
[14:49] <gnomefreak> micahg: ah
[14:49]  * micahg also has to package pyxpcom
[14:51] <micahg> 6 weeks to alpha 3 so I should be able to make it
[14:51] <gnomefreak> cool
[15:05]  * BUGabundo_work hugs gnomefreak
[15:22] <ccheney> asac: any ideas about http://pastebin.ubuntu.com/355243/
[15:29] <asac> ccheney: yes. you lack the type definition somewhere
[15:29] <asac> e.g. probably you have the typdef, but not the struct
[15:39] <micahg> asac: gnomefreak wanted to know if we were interested in instabird from debian
[15:44] <asac> micahg: if it enters testing it probably automatically comes to us, doesnt it?
[15:44] <micahg> asac: it should before freeze, I was wondering if we needed to do anything special with it
[15:46] <gnomefreak> asac: any reason Debian is still using icedove-* for extenstions? i thought this was going to be changed
[15:47] <gnomefreak> or even ice*-*
[15:47] <asac> gnomefreak: its a slow process
[15:48] <asac> as long as no new get added i am happy
[15:48] <asac> hi btw
[15:48] <asac> hope you are all fine ;)
[15:48] <gnomefreak> asac: ok. and hi :)
[15:48] <asac> micahg: we will see once it arrives. if it fails to biuld/start we need to check
[15:48] <gnomefreak> we shall see
[15:48] <micahg> asac: k
[15:48] <ccheney> asac: the typedef for sockaddr_un ?
[15:49] <micahg> asac: not using bind dn to d/l a directory in TB is a minor issue on TB2, right?
[15:50]  * ccheney thinks he must have forgotten something important wrt C
[15:51] <ccheney> ah nm i see why i got confused
[15:51] <ccheney> its defined but at a lower level than glib
[15:52] <micahg> asac: nm
[15:53]  * ccheney needs to write code more often, he is getting too rusty
[15:54] <ccheney> hmm even with adding the proper header it seems to not work :(
[15:54] <asac> ccheney: whatever type is used in those lines
[15:54] <asac> doesnt have the full struct there
[16:01] <gnomefreak> was it Karmic that we are not renaming Shiretoko to firefox-3.5 or just Lucid?
[16:01] <micahg> gnomefreak: Jaunty
[16:01] <gnomefreak> micahg: ok thanks
[16:01] <ccheney> asac: yea appeard to be sockaddr_un which is in sys/socket.h but after including it still failed in the same way
[16:01] <micahg> and it they'll probably get migrated to firefox 3.6 anyways gnomefreak
[16:02] <asac> ccheney: unlikely to be sockaddr_un if its in socket.h
[16:03] <ccheney> oh i misread the contents of the header, i need more caffeine
[16:03] <ccheney> looks like its linux/un.h actually
[16:04] <ccheney> or sys/un.h
[16:04]  * ccheney does a test build and gets caffeine
[16:05] <gnomefreak> micahg: why are we backporting 3.6 to stqable releases?
[16:06] <micahg> gnomefreak: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-new-firefox-support-model
[16:08] <ccheney> yipee that fixed it :)
[16:11] <micahg> asac: got time for anothe build failure?
[16:11] <gnomefreak> micahg: thanks will look in a min
[16:11] <asac> micahg: post it
[16:12] <asac> ccheney: i would expect you wouldnt need to pull in anything that isnt in glib headers
[16:12] <asac> so maybe they copied that header?
[16:12] <asac> in glib2.0?
[16:13] <ccheney> its included via gio/gnetworkingprivate.h
[16:14] <micahg> asac: /bin/sh: Syntax error: end of file unexpected (expecting "}")
[16:14] <asac> right. so pull that in
[16:14] <asac> micahg: thats a syntax error
[16:15] <asac> ;)
[16:15] <micahg> right, http://launchpadlibrarian.net/37762020/buildlog_ubuntu-lucid-amd64.thunderbird-3.0_3.0.2~hg20100111r4629%2Bnobinonly-0ubuntu1~umd1_FAILEDTOBUILD.txt.gz
[16:15] <micahg> it's in TB3.0 and XUL1.9.3
[16:15] <micahg> in lucid only
[16:15] <micahg> so my guess is a toolchain issue on amd64
[16:15] <micahg> oh, and amd64 only
[16:15] <asac> try to find if its a recent commit
[16:15] <asac> thats causing this
[16:17] <gnomefreak> ok will be AFK for a while. im sure i have hundreds of updates from the past month or so.
[16:21] <ccheney> i'm confused as to how the get_type functions work
[16:21] <ccheney> they look like this extern __typeof (g_inet_address_get_type) IA__g_inet_address_get_type __attribute((visibility("hidden"))) G_GNUC_CONST;
[16:21] <micahg> asac: they're different branches and the issue started the same day
[16:21] <ccheney> that is the only referenced code i can find but i am not sure what that does but it doesn't look a function definition
[16:22]  * micahg guesses he should look at lucid uploads for that day :)
[16:38] <micahg> asac: is there a way to tell which file is failing?
[16:38]  * micahg can't find a common commit between the branches
[16:41] <asac> micahg: i would think something in /build/buildd/thunderbird-3.0-3.0.2~hg20100111r4629+nobinonly/build-tree/mozilla/mozilla/modules/libpr0n/build
[16:44] <micahg> asac: yep, but those files haven't touched in quite a while
[16:44] <asac> i think we need to reprduce it locally and keep the tree to investigate
[16:45] <micahg> ok, I'll have to do that later
[16:45] <micahg> it's lucid only though
[16:45] <micahg> can I ask pbuilder not to purge?
[16:46] <asac> check what was uploaded since last build success
[16:46] <asac> maybe sh
[16:46] <asac> etc.
[16:46] <asac> you shouldnt use pbuilder for core stuff for development/triaging
[16:46] <micahg> asac: there was a dash upgrade
[16:46] <asac> just to try if clean build works
[16:46] <micahg> asac: I don't have lucid
[16:46] <asac> setup a chroot
[16:46] <micahg> asac: k
[16:47] <asac> debootstrap is your friend
[16:47] <micahg> asac: is there a bzr trick to build in a chroot?
[16:47] <asac> so dash update feels like a good thing to look at
[16:47] <asac> if you hvae it locally build fail you can try tro downgtrade
[16:47] <asac> micahg: you mount your /home in chroot
[16:47] <asac> then you can just use it as usually
[16:48] <asac> bindmount
[16:48] <asac> there is some wiki page how to setup a good chroot for development
[16:48] <asac> you also need to bindmout more stuff like /proc /dev etc.
[16:48] <micahg> k, I'll look later
[16:48] <micahg> have to get ready for work now
[16:49] <asac> kk
[16:50] <micahg> asac: BTW, I created a pyxpcom LP project
[16:50] <micahg> and made mozilla team the maintainer
[16:50] <asac> sounds good
[16:50] <asac> mainter? or owner?
[16:50] <asac> maintainer
[16:52] <micahg> maintainer is owner I think
[16:53] <micahg> projects have maintainers/teams have owners AFAIK
[16:57] <asac> ok ;)
[17:17] <ibkanat> asac I was told to ask you about MCP51 Ethernet in lucid
[17:18]  * BUGabundo_work ducks
[17:18] <ibkanat> doesnt work for me
[17:20] <thunderstruck> we do not have any packages that recommend packages not in archives do we?
[17:20] <micahg> thunderstruck: we shouldn't...you have an example?
[17:20] <micahg> thunderstruck: oh, yeah, maybe
[17:21] <thunderstruck> micahg: bug 506528
[17:21] <micahg> possibly recommending debian versions of ff/tb
[17:21]  * thunderstruck could use examples if we have any for mozilla
[17:21] <thunderstruck> damnit
[17:22] <gnomefreak> much better :)
[17:22] <micahg> gnomefreak: I knew it was you anyways :)
[17:22]  * gnomefreak should fix that for irc
[17:22] <micahg> gnomefreak: well, when we remove something, we endeavour to migrate all rdepends
[17:23] <micahg> gnomefreak: I think you're better off filing specific bugs if you see something rather than a broad based bug like that
[17:23] <gnomefreak> well it makes no sense that we have people go outside our repos since we do not support it and it may be hard for new users
[17:23] <micahg> gnomefreak: indeed, it's probably either something from a debian import or something legacy in most cases
[17:24] <gnomefreak> micahg: i have no way to know them other than goiing through each package and trying to install them
[17:24] <micahg> gnomefreak: I suggest posting to the ubuntu-devel-discuss ML
[17:24] <gnomefreak> IMHO its better to have people remove them during packaging
[17:25] <micahg> soryr
[17:25] <micahg><EMAIL_ADDRESS>[17:25] <gnomefreak> will do
[17:25] <micahg> no
[17:25] <micahg> that's not right...
[17:25] <micahg> hold on
[17:26] <ccheney> asac: any idea about the weird IA get_type functions?
[17:26] <ccheney> asac: i'm not sure what i am supposed to copy over and how to make the get_type functions to work
[17:26] <micahg> gnomefreak: no, I was right, I think
[17:26] <gnomefreak> yep you were :)
[17:26] <micahg> k
[17:34] <asac> ccheney: which one?
[17:36] <asac> fta2: i marked https://code.edge.launchpad.net/~network-manager/network-manager-applet/network-manager-applet.head.daily as abandoned
[17:36] <asac> so it doesnt show up in the active branch list
[17:36] <ccheney> eg g_inet_address_get_type
[17:36] <asac> so if you get troubles because of that just shoot
[17:36] <ccheney> they seem to have no function body
[17:36] <asac> usually those get defined by G_TYPE_DEFINE macros
[17:36] <asac> search for those in .c files
[17:36] <asac> rather G.*TYPE_DEFINE
[17:37] <ccheney> well there is like this:
[17:37] <ccheney> #define G_TYPE_INET_ADDRESS        (g_inet_address_get_type ())
[17:37] <ccheney> and then
[17:37] <ccheney> GType     g_inet_address_get_type        (void) G_GNUC_CONST;
[17:37] <ccheney> but no body for the g_inet_address_get_type itself
[17:37] <ccheney> it has some sort of weird IA_(blah) stuff but i don't understand how that stuff works
[17:38] <ccheney> eg - extern __typeof (g_inet_address_get_type) IA__g_inet_address_get_type __attribute((visibility("hidden"))) G_GNUC_CONST;
[17:38] <ccheney> that doesn't actually do anything does it?
[17:38] <ccheney> except set the symbol as inivisible in gcc(?)
[17:39] <asac> yes, that hides it
[17:39] <ccheney> in another area i see: extern __typeof (g_inet_address_get_type) g_inet_address_get_type __attribute((alias("IA__g_inet_address_get_type"), visibility("default")));
[17:39] <asac> dont know what __typeof
[17:39] <asac> that defines that g_inet_address_get_type is rather IA__g_inet_address_get_type
[17:39] <asac> aka alias
[17:41] <ccheney> ah so i need to copy both of those to my header?
[17:41] <ccheney> and then it should just work i guess?
[17:41] <asac> most likely
[17:41] <asac> yes
[17:41] <asac> both defs and the impl for IA___
[17:41] <asac> if there is any ... otherwise there must be a G_DEFINE.*TYPE or something in the ia_ source
[17:41] <ccheney> i don't see any impl for the IA__
[17:42] <ccheney> hmm ok
[17:42] <asac> as i said, thats generated by a macro
[17:42] <asac> you can build with -save-temps
[17:42] <asac> and see what gets created and try to find that
[17:42] <ccheney> oh ok
[17:52] <asac> _DEFINE_TYPE_WITH_CODE (GInetAddress, g_inet_address, G_TYPE_OBJECT, _g_networking_init ();)
[17:52] <asac> ./gio/ginetaddress.c
[17:53] <ccheney> ok
[18:24] <jcastro> asac: what you tweeted is a feature
[18:25] <jcastro> it only searches the beginning of URLs, not the title
[18:25] <asac> really?
[18:25] <asac> sucky then ;)
[18:25] <jcastro> so if it's wiki.ubuntu.com/Whatever/Whatever
[18:25] <asac> thats what i thought
[18:25] <jcastro> if you search for Whatever it doesn't find anything
[18:25] <asac> well. it definitly searches the url
[18:25] <jcastro> but if you have whatever.blah.com it finds it
[18:25] <asac> i can find stuff in the middle of urls at least
[18:25] <asac> thats not true ;)
[18:25] <jcastro> are you sure it's not the title of the page?
[18:26] <asac> https://wiki.ubuntu.com/ARM/Thumb2PackageReviewList
[18:26] <asac> go to that page
[18:26] <asac> afterwards you will find it by Thumb2
[18:26] <asac> hmm
[18:26] <asac> oh so you say it searches the title?
[18:26] <asac> just not the url?
[18:26] <jcastro> correct
[18:26] <jcastro> sec, I have the upstream bug
[18:26] <jcastro> they do it for performance reasons
[18:26] <asac> dont mind. firefox behaviour is definitly rockier ;)
[18:27] <jcastro> FF fills in as it finds them iirc
[18:27] <asac> ok
[18:27] <jcastro> FF returns better results imo
[18:27]  * asac thinks that the performance isnt that great atm either
[18:27] <asac> yes
[18:27] <asac> ff rocks ;)
[18:27] <asac> i often go back to it because i just cannot find the url in chromium ;)
[18:28] <asac> but thanks for clarifying.
[18:28] <jcastro> http://code.google.com/p/chromium/issues/detail?id=367&can=5&colspec=ID%20Stars%20Pri%20Area%20Type%20Status%20Summary%20Modified%20Owner%20Mstone%20OS#c7
[18:28] <jcastro> I was wondering that last week too because it drives me mad
[18:28] <asac> thats the other annoying thing ;)
[18:28] <asac> the URL of issues is always busted if you use find
[18:28] <jcastro> you only have one "other" annoying thing? :p
[18:28] <asac> and posting takes effort to strip it (of course different front)
[18:29] <asac> yes, otherwise i am happy ... oh wait!!
[18:29] <asac> there is this voip problem in combination with pulse ;)
[18:29] <asac> that regularly gives me real pain and heart attacks
[18:29] <asac> when i need to dial in somewhere and folks dont hear me etc.
[18:30] <asac> so now i alwasy first call google search
[18:30] <jcastro> I have been pretty lucky so far.
[18:30] <asac> then if that works, dial in somewhere ;)
[18:30] <asac> have you tried google search call service?
[18:30] <jcastro> no I have some voice thing on my g1 that does that
[18:30] <jcastro> where you go "I need to find the nearest pizza place"
[18:31] <asac> sure its the same?
[18:31] <asac> darn
[18:31] <asac> yeah
[18:31] <asac> ok
[18:31] <jcastro> and it returns "Your request for finding carburators and marbles is pending."
[18:31] <asac> i am happy ot have it to test my voip ;)
[18:31] <asac> echo service always takes like a minute before i can test my own void
[18:31] <asac> voice
[18:31] <asac><PHONE_NUMBER>411
[18:31] <asac> thats the number ;)
[18:33] <asac> the other thing most annoying is my internet sucking
[18:50] <asac> fta2: btw, feel free to upload gyp to archive as often as you want ;)
[18:50] <asac> like after landing of licenseing issues etc.
[18:50] <asac> not that i need to tell you that ;)
[19:25] <fta> asac, sure. btw, what's the status of the chromium review action point?
[19:31] <asac> fta: i need all license full textx referred to in the whitelist
[19:31] <asac> with that we are fine
[19:31] <asac> MINUS
[19:31] <asac> Ms-Pl
[19:31] <asac> that license is GPL incompatible
[19:31] <asac> aka illegal to distribute ... a
[19:52] <asac> fta: so if you feel like it help on finding the full license texts somewhere is appreciated. will probably take another week otherwise : ... and i would love to just upload :)
[19:58] <fta> there's a new beta available, i'm working with upstream to have the channels updated (there's a wrong DEPS file and/or a too strict gclient)
[19:58] <and`> asac: will it be uploaded into Debian as well?
[19:59] <and`> asac: I would love seeing it there as well
[19:59] <asac> and`: once its went through our archive admins i will try.
[19:59] <asac> but i guess that will get rejected in debian for a bit longer
[19:59] <asac> or take a year to review ;=)
[19:59] <asac> and`: you can help ;)
[19:59] <and`> asac: sure
[20:00] <asac> find the full license texts referred to in the whitelist of licnsecheck.pl
[20:00] <asac> and make a file dep-5 file tail
[20:00] <asac> with those
[20:00] <asac> e.g. License: BSD (3-clause)
[20:00] <asac> ...
[20:00] <asac> http://pastebin.com/f5b903399
[20:00] <asac> thats the licensecheck with the whitelisted license
[20:01] <asac> they are somewhere in the chromium orig ;)
[20:01] <asac> we just need to prepare a dep-5 style file with them all
[20:01] <asac> http://people.canonical.com/~asac/tmp/copyright.full -> that might give an good indication where to look for that in the source tarball ;)
[20:01] <and`> asac: to summarize it: it's a pain :)
[20:01] <asac> well. I went through massive pain already ;)
[20:02] <asac> so a bit pain on other shoulders is acceptable ;)
[20:02] <asac> its minor pain
[20:02] <and`> yes, understood what you mean, did that with some GNOME packages but they had far less source files than chromium has :D
[20:02] <asac> compared to going through all files like i did ;)
[20:02] <asac> and`: you dont need to make the dep-5 file
[20:02] <asac> i just need the License parts
[20:02] <asac> e.g.
[20:02] <asac> License: ...
[20:02] <asac> FULL license text
[20:02] <asac> we already have the actual copyright stuff
[20:03] <asac> http://people.canonical.com/~asac/tmp/copyright.full
[20:03] <asac> that was the main pain i went through
[20:03] <and`> omg :D
[20:03] <asac> and`: in the first paste there are like 20 licenses. those wee need to collect
[20:03] <asac> somewhere
[20:03] <asac> either in dep-5 or as individual files so we can generate the dep-5
[20:03] <asac> and append that to the copyright.full thin i posted
[20:05] <asac> uploads to debian will definitly happen without testsuite and without -dbg package. at least until fta is uploader and can push th binaries through his big pipe :)
[20:05] <asac> i dont feel like uploading 1G ;)
[20:05] <asac> ccheney: all moving smoothlie?
[20:05] <and`> asac: I can help with letting it through
[20:05] <asac> yeah ;)
[20:05] <asac> first help on the LICENSE files please
[20:05] <fta> asac, aren't we supposed to just put links to the well known licenses, instead of the full texts
[20:06] <asac> fta: we still need to add the short form for those that are in well known
[20:06] <asac> but htose are not my concern
[20:06] <asac> my concern are all the bsd variants and the bsd-like and stuff like that
[20:06] <asac> there are plenty that arent in common :)
[20:07] <fta> asac, why would you need to upload dbg? (there's no more testsuite debs btw)
[20:07] <asac> but and` probably knows better what to do
[20:07] <asac> fta: there is no testsuite debs anymore?
[20:07] <asac> did we drop that?
[20:07] <asac> great!
[20:07] <fta> yes, months ago
[20:07] <asac> or was that never there and my brain is choking
[20:07] <asac> ok
[20:07] <asac> and no -dbg?
[20:07] <asac> i assume we probably want those
[20:08] <asac> esp. in debian there is no dbgsym
[20:08] <and`> asac: yes, don't fully count on me these days for doing it extra-fast, just finished holidays and need to prepare exams and stuff, so it will take some time : /
[20:08] <asac> and`: do it in small chunk
[20:08] <asac> each license you collect is a clear win ;)
[20:08] <asac> we need this this week
[20:09] <asac> otherwise world is going to die
[20:09] <and`> lol
[20:10] <fta> asac, dbg is there, but you don't upload that.. unless debian needs binary debs too??
[20:10] <and`> fta: yes, Debian uses binary uploads
[20:10] <and`> so no -dbg ;)
[20:11] <fta> 78.6MB (dbg)
[20:11] <and`> uploading that would be simply crazy :D
[20:11] <fta> testsuite-deb used to be 800MB++
[20:11] <fta> dbg
[20:12] <and`> fta: when uploading it to Debian you need to make sure that those are not built
[20:12] <and`> otherwise it will be harder to have it accepted
[20:12] <fta> 80MB is not that big, openarena-data is way bigger
[20:12] <fta> imho, -dbg is mandatory
[20:13] <fta> otherwise, byebye crash reports
[20:13] <asac> fta: debian needs them thats the point why i complaining ;)
[20:13] <asac> you basically push all sources + all binaries for one arch + all
[20:13] <and`> well, as long as chromium-browser doesnt directly depend on an 80 mb package, that's fine
[20:13] <asac> thats why i refuse to do security updates in debian nowadays
[20:14] <asac> they should fix their retarded system first
[20:14] <and`> asac: well, binary uploads are a pain but prevents broken packages to get in
[20:14] <asac> well. thats a dubious point
[20:14] <and`> ppl don't test-build their packages and that's why we have tons of FTBFS
[20:15] <asac> it also ensures that you never know whether your binary was actually biuld from clean source
[20:15] <fta> so there's no way to have chromium in debian, not enough arch coverage
[20:15] <asac> debian just sticks to old models
[20:15] <and`> asac: DDs know how to build properly a package
[20:15] <asac> then they should also know that they should test a package before uploading
[20:15] <asac> so you can upload source only ;)
[20:16] <asac> fta: why?
[20:16] <asac> not enough arch coverage?
[20:16] <and`> well, that's not a direct procedure, if you know you need to do a binary upload you *have to* build it before
[20:16] <asac> what does that mean?
[20:16] <asac> and`: yes, but if it fails you can just fix it and continue. or workaround and sign and upload :)
[20:16] <and`> someone might say 'well, I'm sure it will build fine', he does a source upload and then another FTBFS
[20:16] <asac> all happened
[20:17] <asac> point is: binary only doesnt give you much
[20:17] <asac> if the sources dont build the damange is zero
[20:17] <asac> except wasting some buildd time
[20:17] <fta> asac, the plethora of arches debian supports, we can't provide those binaries
[20:17] <asac> -> which was reasonable at some point in the 90th ;)
[20:17] <asac> fta: doesnt matter
[20:17] <asac> you upload with any ... if it never built on an arch its not a problem that it fails
[20:18] <asac> idea is that porters can then start on that
[20:18] <asac> only a RC bug if it previously built on an arch, but then doesnt
[20:18] <and`> asac: well, I don't think building a package is such a pain before uploading (it might be if you maintain huge packages, but that's not what normally happens)
[20:18] <asac> as that would be a regression for usres on upgrades
[20:18] <asac> building not, but uploading if you upload big packages
[20:18] <asac> also building is a pain
[20:18] <and`> yes, I agree with you on that
[20:18] <asac> i would never be able to do security updates for mozilla in the same scala we do it in ubuntu
[20:18] <and`> I never had huge packages so that's why I'm not complaining atm
[20:19] <asac> like two branches to 5 releases
[20:19] <asac> -> never
[20:19] <asac> ;)
[20:19] <asac> right. but once you see your dsl provider being flaky and the whole upload being for nothing because the dbg package doesnt finish ;)
[20:19] <asac> you know what i mean
[20:19] <and`> asac: well, forwarding the fix to Debian would be enough :)
[20:19] <asac> also then you have to send a dcut upload to first remove stuff from the incombing queue
[20:19] <asac> another paranoid thing in debian
[20:19] <asac> they are scared that someone would overwrite your uploads ;)
[20:20] <asac> and`: i sent patches for quite some time to debian folks for mozilla
[20:20] <asac> they often didnt even have the time to test them
[20:20] <asac> nor upload
[20:20] <asac> security patches
[20:20] <and`> how many years ago? :)
[20:20] <asac> not so long
[20:21] <asac> 9month or so
[20:21] <asac> or 1 year at most
[20:21] <asac> e.g. when firefox 1.5 went EOL for us
[20:21] <asac> i stopped doing backports
[20:22] <asac> and since my patches often didnt get uploaded and i refuse to do that for a bit over a year now because of said reasons
[20:22] <asac> i stopped doing that
[20:22] <asac> (also i dont like it anymore)
[20:22] <and`> unfortunately I saw that you left your packages a bit unmaintained in Debian (e.g icedove et all), and I didnt get why you stopped
[20:22] <asac> not really
[20:22] <asac> icedove 2 is tbird 2 which was dead for ages
[20:22] <asac> now we have 3
[20:23] <asac> if you say unmaintained because of no bug triage thats a different issue
[20:23] <asac> i just refuse to proxy for loads of bugs
[20:23] <asac> i did the same for ubuntu
[20:23] <and`> I don't see an upload from you in Debian since some time aparts sponsoring, which is ok since you have tons of stuff to do
[20:23] <asac> now we can connect bugs with upstream in ubuntu and let the users talk directly
[20:23] <and`> but someone else might see it in a different view
[20:23] <asac> and`: because icedove had no release
[20:23] <asac> i stopped security updates because of said reasons
[20:24] <and`> well, you didnt maintain icedove only
[20:24] <asac> enigmail is same issue ;)
[20:24] <and`> or was it the only package?
[20:24] <asac> mostly ... i also helped on iceape and did security for all mozilla packages
[20:24] <asac> including xulrunner etc.
[20:25] <and`> I would love seeing you a bit more involved in Debian as you were in the past, but that will be mostly impossible
[20:26] <and`> I understand your points, I just think that if you don't have the time to follow those packages anymore, orphaning them would have been the right choice
[20:26] <asac> which packages
[20:26] <asac> all packages are good ;)
[20:26] <asac> icedove is fine
[20:26] <and`> I saw some of them got orphaned
[20:26] <asac> not sure what you are saying
[20:26] <asac> which ones?
[20:26] <and`> with cause: not properly maintained
[20:27] <and`> they were orphaned by glandium
[20:27] <and`> if I remember it right
[20:27] <asac> he orphaned xulrunner
[20:27] <asac> none of my packages i hope
[20:27] <asac> then i wanted to take it so i can sync debian and ubuntu
[20:27] <asac> and he said he didnt orphan it for real ;)
[20:28] <asac> iceape got orphaned, but that was a joint effort of debian mozillateam
[20:28] <asac> and the debian mozillateam is a joke, because it waas me and mike ... and mike being unwilling to coorporate since i joined ubuntu
[20:28] <asac> made that void
[20:28] <asac> anyway, recently there is now more stuff going on there
[20:29] <asac> but mostly by extension team
[20:29] <and`> 8 RC bugs in icedove and 4 on iceowl, more than 400 open bugs, well maybe the bug tracker needs to be refreshed / cleaned a bit removing fixed / old reports
[20:29] <and`> but for sure it needs work, like bluez does atm
[20:29] <asac> feel free to work on the bug tracker
[20:30] <and`> bluez does not have a maintainer anymore and that's a big issue since every bluetooth interface depends on it
[20:30] <asac> if folks file bugs against an old icedove version that will not have any fixes for sure its not my business ;)
[20:30] <gnomefreak> 2.* is dead now isnt it?
[20:30] <asac> its for ages practically dead
[20:30] <asac> thats why it doesnt make sense to put work into it
[20:31] <and`> sure, but I read that the maint is Ubuntu Mozilla Team so cleaning up the bug tracker should be a maintainer's work
[20:31] <gnomefreak> right
[20:31] <asac> iceowl is dead too
[20:31] <asac> nly extension survives
[20:31] <gnomefreak> 1.0b*\
[20:31] <and`> luckily the ext team seems a bit more active after some time, at least that
[20:31] <asac> also the only way to get anyone contribute to mozilla stuff seems to be to do just nothing
[20:32] <asac> yes, but extensions are easy and fun work
[20:32] <asac> mozilla software is painful and you dont find anyone helping out ...
[20:32] <and`> starting someone in doing mozilla-related work is a pain, I know
[20:32] <and`> and that's why I don't see any new face here since 4 years
[20:32] <asac> extensions are a good stepping stone, but the step is quite big
[20:33] <gnomefreak> we have a bunch of people working on mozilla apps. since upload priv... are hard to come by in Debian it makes it a bit harder to find willing people (as far as i see it)
[20:33] <asac> like check the qa page out: http://packages.qa.debian.org/i/icedove.html
[20:33] <asac> 21 security vuln -> what a mess
[20:33] <and`> gnomefreak: well, no one ever asked me to sponsor anything moz-ext related since now
[20:33] <asac> why do i need to spend time and clean stuff up that others claim without knowing anything
[20:34] <and`> gnomefreak: so I don't think it's a sponsoring / missing priv problem
[20:34] <asac> and the non-maintainer upload was because i asked him to upload his minimal change ... another painful thing that QA says its a NMU just because someone else uploads it for you
[20:35] <and`> asac: you can easily ignore the NMU error if you are sure you aren't hijacking the package :)
[20:36] <asac> how ignore. the bug wasnt closed
[20:36] <asac> just because of this
[20:36] <asac> what a mess ;)
[20:36] <asac> but you are right, i probably should just leave the whole project :)
[20:36] <asac> and orphan all mozilla packages ;)
[20:37] <and`> asac: well, I just would like to see some more Ubuntu ppl contributing back to Debian
[20:37] <asac> but we saw how great that worked with iceape ... its gone
[20:37]  * micahg wonders if it's worth becoming a DD
[20:37] <cyphermox_> and`: some do!
[20:38] <and`> cyphermox: luckily you are right, some do :)
[20:38] <asac> and`: i did the work everyone claimed to be impossible before i did it for years
[20:38] <asac> i backported mozilla packages
[20:38] <asac> before i was in debian, there was no security for firefox
[20:38] <asac> now that i am not doing it anymore, it will work until upstream EOLs the branch
[20:38] <asac> then good bye
[20:38] <and`> asac: just think about the python mess in Debian, that's what I define *crazy*
[20:38] <asac> when i did the whole patches, ensuring everything was there, i was still ranted at
[20:39] <gnomefreak> bug 113201
[20:40] <fta> asac, as LATEST.txt is still broken, i've extended g-o-s to accept stuff like CHANNEL=4.0.288.1  (in addition to CHANNEL={beta,Beta,dev,Dev})
[20:41] <and`> asac: I know that you alwais wanted to give back to Debian and I appreciate that, I just hope I gonna see your name again somewhen, I would feel happy, really
[20:42] <micahg> gnomefreak: do you need feedback?
[20:45] <gnomefreak> micahg: for what?
[20:45] <micahg> for that bug?
[20:46] <gnomefreak> micahg: no there was no title in my email for the bug
[20:46] <micahg> gnomefreak: k
[20:46] <gnomefreak> wait yes i do
[20:46] <micahg> heh
[20:46] <gnomefreak> i commented on the bug if anyone sees this in 3.5 3.6
[20:47]  * gnomefreak thought i just did :(
[20:47]  * micahg usually lets upstream sort it out if it's open
[20:47] <micahg> they seem to be trying to figure out if it's fixed or not on 1.9.1
[20:48] <micahg> but I wouldn't bother updating FF3.0 bugs to FF3.5 at this point since we might end up moving them again in 3 months
[20:48] <micahg> at least the triaged ones
[20:48] <gnomefreak> k
[20:48] <micahg> the untriaged, go for it
[20:49] <micahg> gnomefreak: asac still has to decide which source package to use for ff3.6
[20:49] <asac> blocked on understanding what channels mohzilla will maintain
[20:49] <asac> [reed]: any decision yet?
[20:50] <asac> e.g. will you have stable/beta/dev like chrome?
[20:50] <asac> i catched that in some discussion
[20:50] <[reed]> hmm
[20:50] <asac> but mconnor said it might be more complex/different when i last asked
[20:51] <gnomefreak> micahg: im still going through >6000 emails. so far will exception to the 1 1/2 hour meeting i have been doing it all day
[20:51] <asac> having such channels would definitly help us to pick the package names in a long term stable fashion
[20:51] <asac> like firefox firefox-beta firefox-trunk
[20:52] <asac> or firefox firefox-next firefox-dev firefox-daily
[20:52] <micahg> gnomefreak: I still have 4k unread and I go through it daily :)
[20:53] <gnomefreak> just catching up from from dec 14th
[20:53] <gnomefreak> s/just/still
[20:56] <ccheney> asac: i think so, had a late lunch and now looking at it again
[20:56] <ccheney> asac: it changed the failure in any case :)
[20:57] <asac> which might mean progress ;)
[21:09] <gnomefreak> be back i lost my glasses :(
[21:10] <gnomefreak> dog food bag of all places
[21:12] <gnomefreak> should we add a trunk build of enigmail for non-released tb versions? or please add trunk builds of it atleast in our daily PPA?
[21:19] <gnomefreak> ok gone for the day.