[18:44] <Unit193> awordnot: ...Figured maybe I should just let you know, seems the last update to the overlay is incomplete?  Line 10 of https://github.com/Xfce-Classic/gentoo-overlay/blob/master/xfce-base/libxfce4ui/libxfce4ui-4.15.8.ebuild and https://github.com/Xfce-Classic/gentoo-overlay/blob/master/xfce-base/libxfce4ui/Manifest
[18:46] <awordnot> Unit193: woops, thanks for catching that
[18:47] <brainwash> you seen this? https://gitlab.xfce.org/xfce/xfce4-settings/-/commit/a1e225612639b186dfd354fd6b2588a04ca1e140
[18:47] <ubot3> Commit a1e2256 in xfce/xfce4-settings "Drop subtitles from settings dialogs (Fixes #239)"
[18:48] <brainwash> makes me wonder if a xfce4-settings-nocsd is necessary
[18:50] <brainwash> settings-manager has a new search bar also
[18:50] <brainwash> which is revealed on button click
[19:21] <Unit193> brainwash: Hrm, just to be clear.  Do you use xfce4-docklike-plugin?
[19:22] <brainwash> no
[19:22] <brainwash> but the plugin works
[19:22] <brainwash> at least one month ago :)
[19:23] <brainwash> why you ask?
[19:24] <Unit193> You've mentioned it a few times, I package it for the PPA, I'm not aware of anyone on IRC that actually uses it (read: no feedback ever.)
[19:24] <Unit193> (I'll never know if it's broken. :D )
[19:27] <brainwash> the github page mentions the ppa
[19:27] <brainwash> I assume people actually use it
[20:30] <Unit193> bluesabre: Are we moving the packaging repos to github too?
[20:37] <Unit193> https://code.launchpad.net/~xubuntu-dev/+git xfdash and now thunar-shares are the only ones to care about.
[21:58] <Unit193> bluesabre: Also, let it be on record makefiles are terrible,  but I believe I fixed the docs.
[21:59] <bluesabre> Unit193: Yes, we probably should move the packaging repos to github as well. And awesome!
[22:00] <Unit193> OK, I'm game for that.  Though I really like Launchpad's push to create.  Should I move or you good to?  I'm going to have krytarik look at it, and if we both agree then commit, push, upload, tag, etc. :P
[22:00] <Unit193> FYI, some translations have broken strings, but that's OK.
[22:11] <Unit193> http://paste.openstack.org/show/6TvWg05e1zygNOtvgACD/
[22:13] <bluesabre> Unit193: if you can move it, please do. Otherwise I can tackle it a bit later.
[22:14] <Unit193> I'll do them, then.
[22:14] <bluesabre> Much appreciated!
[22:15] <Unit193> bluesabre: And sorry, but lastly are you going to finish and import Greybird .13 or should I see if I can?  Just use gbp import-orig and forget about his own home-grown style of importing..
[22:16] <bluesabre> Unit193: I think it even failed when I tried gbp import-orig... I ran out of options myself there.
[22:17] <Unit193> https://salsa.debian.org/desktop-themes-team/greybird-gtk-theme/-/commits/upstream/latest/ looks like it worked then. :3
[22:23] <Unit193> bluesabre: You good with http://paste.openstack.org/show/WSvk96QQCLQWpB9JT0Uo (The diff: http://paste.openstack.org/show/yqyKmGJVoOJZtOEjJWz3)?
[22:25] <bluesabre> Unit193: looks good to me
[22:27] <Unit193> Will upload in a sec.
[22:28] <Unit193> https://salsa.debian.org/desktop-themes-team/greybird-gtk-theme/-/commits/debian/master
[22:31] <bluesabre> Yay
[22:31] <bluesabre> What was the blocker... upstream-vcs-tag?
[22:34] <Unit193> Yes, note before you commented it out, committed, re-added. :>
[22:35] <Unit193> Anything else, sans the docs (kry is gone, but I really want *someone* to review it..)
[22:37] <bluesabre> heh, I was a smart dev once
[22:38] <Unit193> Got one up on me, then.
[22:38] <bluesabre> :D
[22:38] <bluesabre> I can spot check the docs package if kry doesn't show for a bit
[22:38] <Unit193> I'll sync greybird once it is available.
[22:39] <bluesabre> Awesome. ochosi probably planning another release to coincide with xfce 4.16 so the slimmer CSDs are available
[22:39] <Unit193> http://paste.openstack.org/show/vY0oNkPW3wftGyLxnQnB is my full local version, please comment if something bothers you!  Eh...I really don't want to get into maintaining a theme..
[22:40] <bluesabre> Since you fixed it, I can probably package and ping one the next one
[22:40] <Unit193> I'll be happy to sponsor, yeah!
[22:45] <Unit193> Fun fact: Running clean before the build like that, means mkdir -p happens right in the middle of the clean target, thus deleting the directory.  Then things can't be copied.
[23:06] <Unit193> "greybird-gtk-theme_3.22.13-1_source.changes ACCEPTED into unstable"
[23:11] <bluesabre> :D
[23:15] <bluesabre> jphilips: doing some xfce release work this weekend, but can review next week. For the changes I already landed, I focused on the items that already had some consensus. On https://docs.google.com/document/d/1hzvQURi8l--GrfqsxP9c0tWNUzrkbZjZTiVxGUegALg/edit#, I crossed out the ones I included and added comments for the ones I couldn't do.


[15:27] <Prf_Jakob> Hmm I'm trying to use the xorg-pkg-tools to build packages for libdrm and mesa.
[15:27] <Prf_Jakob> on raring
[15:27] <Prf_Jakob> but they fail for various different reasons.
[15:28] <Prf_Jakob> ./auto-xorg-git -fn -p libdrm -a 0ubuntu0bwh -d origin/debian-experimental -r gutsy -w <path>
[15:28] <Prf_Jakob> failes because it can't merge origin/debian-experimental
[15:29] <Prf_Jakob> that was the line that "xorg-pkg-all.sh" script used.
[15:34] <Sarvatt> its extremely clunky and undocumented, you want ./auto-xorg-git -r saucy -g -a 0ubuntu0bwh -d origin/debian-unstable -t '+' -p libdrm for libdrm though, mesa isn't working with xorg-pkg-tools at the moment because the patches against the packaging to make git work hasn't been updated in awhile
[15:37] <Prf_Jakob> ah okay
[15:37] <Prf_Jakob> if I'm on raring should I do "-r raring" or will that fail?
[15:38] <Sarvatt> -r raring is fine, just sets the release in debian/changelog (what release it'll build for in a ppa)
[15:39] <Sarvatt> with multiarch you really want to be using a ppa to build things since you'll need i386 and amd64 packages to have the same version
[15:39] <Prf_Jakob> ah okay thanks
[15:39] <Prf_Jakob> hmm
[15:40] <Sarvatt> unless you dont use wine/steam/whatever
[15:40] <Prf_Jakob> not really
[15:40] <Prf_Jakob> okay I got a error but it continued...
[15:41] <Sarvatt> there's a guy doing 9.3 mesa releases, https://launchpad.net/~oibaf/+archive/graphics-drivers/
[15:41] <Prf_Jakob> first it complains about detatched heads when checking out origin/debian-unstalbe
[15:41] <Sarvatt> urg, he didn't bump the libxatracker1 package name after the soname change... thats going to cause problems
[15:41] <Prf_Jakob> dh: unable to load addon autoreconf: Can't locate Debian/Debhelper/Sequence/autoreconf.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl .) at (eval 20) line 2.
[15:41] <Prf_Jakob> BEGIN failed--compilation aborted at (eval 20) line 2.
[15:41] <Sarvatt> Prf_Jakob: sudo apt-get build-dep libdrm
[15:41] <Sarvatt> you dont have dh-autoreconf installed, that should grab it
[15:41] <Prf_Jakob> thanks
[15:42] <Prf_Jakob> Sarvatt: oh right :/
[15:42] <Sarvatt> it also doesn't error out gracefully, might have to rm -r libdrm or fakeroot debian/rules clean inside the libdrm dir before running it again
[15:44] <Prf_Jakob> ah okay
[15:44] <Prf_Jakob> okay its build libdrm now at least
[15:45] <Prf_Jakob> ugh can I skip the signing step?
[15:45] <Prf_Jakob> or do I need to setup a key?
[15:46] <Sarvatt> not if you want it in a ppa?
[15:46] <Prf_Jakob> I just want to hand the packages to somebody
[15:47] <Sarvatt> oh its just making a source package for upload, you want to debuild -uc -us -b inside the libdrm dir to actually build the binaries
[15:47] <Sarvatt> dont need to sign
[15:47] <Prf_Jakob> I guesss I can edit the script for that
[15:48] <Prf_Jakob> oh hey it builds
[15:49] <Prf_Jakob> well libdrm built
[15:53] <Sarvatt> i'll try to get mesa git with auto-xorg-git beaten into shape soon and ping you when its ready Prf_Jakob, really busy with baytrail intel fun this afternoon though
[15:54] <Sarvatt> Prf_Jakob: is it git or 9.2 branch you're interested in?
[15:54] <Prf_Jakob> Sarvatt: yupp, just changing the debuild line got me binaries straight out of the script.
[15:54] <Prf_Jakob> Sarvatt: let me double check


[05:18] <Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-sis/+bug/162265
[05:18] <Sarvatt> :D
[08:30] <RAOF> Sweet.  nouveau KMS now works on my nv4b.
[09:06] <ripps> Can someone here tell me how to make a persistant xorg-edgers liveusb
[11:16] <Duke`> hum I wonder why I have i915 module loaded by default on my desktop box where there is no intel hardware, but amd+ati
[11:58] <RAOF> Duke`: Because the initramfs unconditionally modprobes i915, and it doesn't go away.
[12:12] <Duke`> ok
[20:38] <alex_mayorga> hello, can anyone tell if I might be bitten by this one https://bugs.freedesktop.org/show_bug.cgi?id=21623 if I go into karmic?
[21:41] <dash1> I have a problem with getting max resolution (1600x1200) on an external Dell 2001 FP from my Dell Latitude X1 (i915) on newer Ubuntu versions. I had 1600x1200 with Ubuntu 8.04 with an elaborate xorg.conf, but I can't seem to get it now. And isn't elaborate xorg.confs out of vogue these days, anyway? Any ideas?
[21:56] <dash1> On an up-to-date Karmic the problem is really bad: if I connect the external monitor and start gnome-display-properties both screens gets garbled. It goes better if I start x with the external monitor connected, but then I only get 800x600 on both screens. If I try to get 1200x768 on the laptop screen, it gets garbled again.
[22:25] <RAOF> dash1: My initial guess would be Virtual size issues; a laptop monitor + 1600x1200 will almost certainly hit the "no more than 2048 in any dimension" (pseudo-)limit
[22:32] <dash1> RAOF: I don't think that Virtual size is the problem.  Isn't 2048x2048 a limit for DRI? I have defined "Virtual 2880 1600" and although I then loose DRI, I think it should work.
[22:34] <RAOF> So, I said pseudo-limit because I believe that the actual limit on newer intel chips is 4096x4096, and I _think_ that newer mesa+DDX+kernel exposes this limit.
[22:34] <RAOF> Which would be relatively untested, because the limit was previously 2048.
[22:35] <dash1> ROAF: OK. And i915 is an old chip that can't do more than 2048x2048 at all?
[22:35] <RAOF> i915 is the driver for all new intel chips.  Got a better identifier? :)
[22:36] <RAOF> (lspci | grep VGA will do)
[22:37] <dash1> Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)
[22:37]  * RAOF 's GM45 (identified as "Mobile series 4") has GL_MAX_TEXTURE_SIZE=4096
[22:37] <RAOF> I don't know about that chip.
[22:37] <RAOF> glxinfo -l will spit out all the mesa limits, at least.
[22:39] <dash1> Which of the limits am I looking for? GL_MAX_VIEWPORT_DIMS is 4096x4096
[22:40] <dash1> GL_MAX_TEXTURE_SIZE is 2048
[22:42] <dash1> I think it maybe has to do with a warning I see in the Xorg.0.log file: (WW) EDID preferred timing clock 162.00MHz exceeds claimed max 160MHz, fixing
[22:45] <dash1> And later it says that Modeline "1600x1200"x60.0   162.00 ...  and even later (II) intel(0): Not using default mode "1600x1200" (vrefresh out of range)
[22:46] <RAOF> That'd be for the laptop's internal screen, probably.
[22:47] <RAOF> I think it might be time to file a bug (with "ubuntu-bug -p xserver-xorg-video-intel", which will pick up all sorts of extra useful information) if you haven't already.  I'm not really an intel expert.
[22:48] <dash1> OK. I think I'll do that. But it was OK to get a little reality check first. So thanks for the help. :)


[03:28] <jam> wpk: I'd rather we connect to any mongo, because in actuality the mgo driver is doing *exactly* that. With the caveat that we should be tracking some sort of "state addresses" rather than assuming api addresses - port + state port == state addresses.
[10:41] <wpk> jam: If we'd be tracking state in state - that'd be awesome. But until then - I think that's good-enough hack
[10:43] <wpk> jam: btw, one of the problems I've had with openstack was that it was reporting two of the same subnets (rfc1918 ones)
[10:44] <wpk> jam: I have a 'hack' for now (ignore if exists) but it has to be solved for this to be working properly...
[13:51] <jam> wpk: if I read the code correctly, we support specifying a network to use in Openstack. If we do, then the ListSubnets work should be restricting it to only that network
[14:50] <wpk> jam: not if using GBP


[10:01] <KingJ> What's the best way to upgrade my controller/model from 2.4-beta3 to 2.4-rc1? If I run juju upgrade-model -m controller or juju upgrade-juju I just get 'no upgrades available' returned. I've already updated the client to 2.4-rc1
[11:37] <KingJ> aha juju upgrade-juju --agent-stream=devel seems to be the magic command


[13:47] <rick_h_> bwuhahahaha, waterproof camera arrival. You'll all get a lot more pics of the fish catch now!
[13:54] <jrwren> waterproof but not underwater? do you dislike phone cameras?
[13:55] <rick_h_> I don't trust my phone in a kayak out in the open
[13:55] <rick_h_> this thing has a floating strap and can be submerged floating while I fish it out of the lake if I drop it
[13:55] <jrwren> ah, cool!
[13:56] <rick_h_> paying full price for cell phones makes you a little bit more cautious about where you stick it :)
[13:57] <devinheitmueller> I don’t know if you’re interested but Lennart Poettering did a systemd talk last night here at NYLUG.  https://www.youtube.com/watch?v=PDHTcB63NXs&feature=youtu.be
[13:58] <devinheitmueller> Might be worth Scott taking a look prior to MUG’s talk on July 14th to see if he wants to steal any materials.  :-)
[14:00] <jrwren> full price? You mean like $599 instead of free or $99 ?
[14:00] <jrwren> who does that? :)
[14:09] <cmaloney> Good morning pt. 2
[14:10] <cmaloney> devinheitmueller: Thanks for the link
[14:10] <devinheitmueller> np.  Hope it helps.
[14:12] <jrwren> 2h40m. anyone got a summary?
[14:13] <cmaloney> "Hi, I'm Lennart and I wrote systemd. Here's why it's awesome"
[14:13] <devinheitmueller> I think the video was a livestream so it started before the actual talk.  Hence you can likely fast forward through the parts where people are just standing around drinking beer and finding their seats.
[14:14] <devinheitmueller> I’ve personally had some unpleasant exchanges with Lennart in the past, and I have to say though that I was actually pretty impressed.
[14:16] <devinheitmueller> Having some background behind the motivation behind some of the design decisions, and why they just didn’t extend Upstart was pretty useful.  I came out of it feeling less like there’s a consipiracy for systemd to take over the world.
[14:22] <cmaloney> Yeah, same with pulseaudio
[14:22] <cmaloney> there's some good thinking in there.
[14:23] <jrwren> all that is in the systemd FAQ. I read it, and was no longer anti-systemd
[14:24] <jrwren> err, not faq, but this: http://0pointer.de/blog/projects/the-biggest-myths.html
[14:25] <devinheitmueller> I think for many it was just a huge shift from the traditional sysvinit thinking (and there is lots of added complexity with any parallel init system).  Hence I can appreciate people trying systemd, running into to some case where it didn’t behave the way they would have expected, and then been bewildered with the process of debugging what went wrong.
[14:25] <jrwren> i never understood what "traditional sysvinit thinking" was. There was always init pid 1 and it did whatever it did. That changed a lot over the years.
[14:26] <devinheitmueller> Plus many were/are irked by systemd’s importing of functionality that was previously done by standalone processes (udev, networking, etc).  That said, I came out of the talk appreciating that there was some pretty good rationale for some of these decision.
[14:26] <jrwren> Maybe because I admined BSD for years along with linux, I was thinking about things differently? I don't know.
[14:27] <devinheitmueller> I think many are still of the mindset where they think about runlevels and linear startup (i.e. init scripts running in order).  Plus it was relatively easy to hack an existing init script to add debugging when things didn’t do what you expected.
[14:27] <jrwren> could be.
[14:27] <jrwren> it hasn't been that way for many years.
[14:28] <devinheitmueller> Who hasn’t jammed “set -x” into the top of an init script so they could see what it was doing at boot?  That sort of thing can be harder with systemd.
[14:28] <jrwren> upstart has been in ubuntu for 4+yrs, right?
[14:28] <jrwren> and upstart was in at least 1 debian release.
[14:28] <jrwren> and iirc upstart was in a rhel release and a few fedora releases.
[14:28] <jrwren> it has been harder with upstart just the same :)
[14:29] <devinheitmueller> I think upstart better preserved some of the older conventions though by being able to run things like the existing “service” commands and reliance on shell scripts for the actual business logic.
[14:29] <devinheitmueller> Some of this is certainly a comfort issue.  People get set in their ways and learn a subset of commands they use regularly, and then along comes this thing that is totally different and requires to you learn a whole new set of commands to manage.
[14:30] <jrwren> you are wrong on teh second point.
[14:30] <devinheitmueller> Am I?
[14:30] <jrwren> on teh first point, yes, making service _ start/stop work is great.
[14:31] <jrwren> devinheitmueller: yes, there is fallback to /etc/init.d/ scripts, but it did not rely on them.
[14:31] <jrwren> in fact, it was often very confusing to see if /etc/init.d script was being used v. /etc/init upstat job because both would exist.
[14:32] <jrwren> you had to know that the /etc/init job would be used and /etc/init.d script ignored.
[14:32] <devinheitmueller> Entirely possible.  I’ll be the first to admit I haven’t done any Linux server admin in several years, and the use cases for my Ubuntu desktop have “just worked”.
[14:32] <jrwren> yes, its nice.
[14:32] <jrwren> and systemd is nice too.
[14:32] <jrwren> so if you have used upstart, systemd is not much of a change.
[14:33] <jrwren> even the shell scripts thing is being worked around in the complex cases, so services still use shell scripts to start.
[14:39] <jrwren> e.g. a systemd service with ExecStart=/etc/init.d/yourservice systemd-start
[14:39] <jrwren> looks to be the pattern from debian/ubuntu
[14:40] <jrwren> and that way you can have service packages which work with 3+ init systems easily.


[13:47] <FrancisANDRE> Hello Launchpad
[13:48] <FrancisANDRE> I have an issue building a recipe with git
[13:55] <cjwatson> FrancisANDRE: what's the issue?
[13:56] <FrancisANDRE> The log states: fatal: Couldn't find remote ref HEAD
[13:56] <cjwatson> oh, the question you filed
[13:56] <cjwatson> saw it but hadn't had a chance to look into it yet
[13:56] <FrancisANDRE> Yes
[13:56] <FrancisANDRE> https://answers.launchpad.net/launchpad/+question/601357
[13:57] <FrancisANDRE> ok
[13:59] <cjwatson> just trying to reproduce it locally now
[14:00] <FrancisANDRE> ok thanks for having a look at it
[16:29] <mvo> I couldn't find it on the LP help, I wonder if there is a way for the code importer from svn to also pull in the external. I'm wonderng because I would love to auto-build a snap from lp:josm but the repo has some external items it seems and those are not in the code import. wonder if there is a way to get them somehow into LP too?
[16:32] <cjwatson> afraid not, I think you'd probably have to pull those in explicitly in snapcraft.yaml somehow
[16:32] <mvo> thanks cjwatson
[16:35] <cjwatson> FrancisANDRE: answered now
[18:56] <mapreri> is it possible to configure a git repo to send emails with diffs to a mailing list, without having that mailing list exist as a user?
[18:56] <mapreri> (user or team)
[19:25] <dobey> mapreri: i don't think so
[19:26] <dobey> mapreri: ie, i don't think there is any way to "subscribe" someone who is not a user/team to a "branch" on lp
[19:28] <mapreri> ack
[19:35] <cjwatson> Also that kind of git subscription isn't implemented yet
[22:05] <mapreri> cjwatson: if that's the case, what's the "revision notification" thing I can see on the details of my subscription?
[22:06] <mapreri> I now notice that before I didn't specify that I was interested in what can be called commit emails, emails for every commit containing the diff of them.