[07:47] <SmokedCheese> hello! it's possible to set hostname with variables?
[07:58] <SmokedCheese> or should i use something like bootcmd: - hostnamectl set-hostname "hostname-$(http://<IP_ADDRESS>/2009-04-04/meta-data/instance-id)" ?
[12:53] <smoser> SmokedCheese: its not possible right now.  we have a card to do something like that.
[12:53] <smoser> so yeah, your only option is what you have there.
[12:53] <SmokedCheese> okay, thanks!
[14:15] <smoser> SmokedCheese: https://trello.com/c/AYaCdQyT
[14:15] <smoser> that is the card that describes what we'd be looking to do.
[14:17] <smoser> and i just added a section for what i think you were asking for.
[14:30] <SmokedCheese> sweet
[16:14] <smoser> powersj: so... https://code.launchpad.net/~ajorgens/cloud-init/+git/cloud-init/+merge/331660
[16:14] <smoser> ci didnt run. but didnt complaon
[16:14] <smoser> and /me didn't see it cry
[16:14] <smoser> because ajorgens isnt in happy list
[16:14] <smoser> probably need some solution for that
[16:14] <powersj> aah
[16:15] <powersj> let me add him to the white list
[16:15] <blackboxsw> +1 powersj can you make sure robjo is on that too
[16:15] <blackboxsw> he might already be
[16:16] <powersj> blackboxsw: robojo is rjschwei?
[16:16] <blackboxsw> powersj: yep
[16:16] <smoser> powersj: where is that list ?
[16:17] <powersj> smoser: torkoal:~/.jlp/jlp.config
[16:18] <powersj> and done
[16:26] <robjo> my lp userid is rjschwei
[16:26] <robjo> powersj: ^^^^
[16:27] <powersj> robjo: thx
[17:35] <blackboxsw> welcome to the wide world of automated CI votes on your branches robjo
[17:36] <robjo> blackboxsw: thanks, something new to figure out ;)
[17:37] <robjo> on that note, anyone have any time to provide some feedback on the chrony integration on the ML?
[17:39] <smoser> blackboxsw: hm..
[17:40] <smoser> hm..
[17:40] <blackboxsw> hm..
[18:18] <blackboxsw> ok cloud-init status systemctl checks is pushed
[18:19] <blackboxsw> sorry smoser yeah that last paragraph of the blog post was WIP. will ping when done
[18:36] <blackboxsw> ok done.
[19:18] <robjo> smoser: blackboxsw was there a network rendering fix after 17.1 was released?
[19:18] <robjo> reference is https://bugzilla.opensuse.org/show_bug.cgi?id=1064854
[19:18] <robjo> it looks to me as if a V1 config is not properly transformed
[19:19] <blackboxsw> robjo approve https://code.launchpad.net/~rjschwei/cloud-init/+git/cloud-init/+merge/333575 with comments
[19:19] <blackboxsw> approved rather. nothing for you to fix that I can see.
[19:19] <blackboxsw> probably will merge later today
[19:19] <blackboxsw> checking the bug
[19:19] <robjo> this appears to be tested in test_apply_network_config_eni_ub in test_netconfig
[19:20] <robjo> and I fail to see where this transformation would be distro implementation dependent
[19:22] <robjo> The way I see it the transformation should be as follows from V1 config to the debian/ubuntu network specification, which should then end up in the distro implementation which for openSUSE is still _write_network
[19:30] <blackboxsw> robjo: looks there is a distro-dependent component for network renders. I see renderer_configs defined in cloudinit/distros/debian.py which direct what renders to use for debian/ubntu
[19:31] <blackboxsw> checking how that's used
[19:32] <robjo> I am not using the renderer concept yet, because the sysconfig renderer has the path hard coded and the paths between RH and SUSE do not match, that's where the refactoring comes into play that I mentioned in the meeting the other day
[19:33] <robjo> for now I end up in network_state.parse_net_config_data
[19:34] <robjo> In "regular" code flow somewhere would be a call to distro,apply_network_config(), which fails for openSUSE/SLES the exception is then caught and we end up in _apply_network_from_network_config
[19:35] <robjo> in this method the information is supposed to be transformed to the "standard" debian/ubuntu interface configuration, i.e. it should look something like V1_NET_CFG_OUTPUT in the test
[19:36] <robjo> is there a test that covers that specific transformation?
[19:42] <rharper> robjo: so, network_data.json -> v1 config  happens, then, since you're not yet using the sysconfig renderer,  you're getting an already rendered eni config, but the opensuse write_network is re-reading it to convert it to sysconfig; it appears
[19:42] <blackboxsw> generally there is ./tools/net-convert in our repository we use to validate rendering types given a provided network config and specifying whether your are rendering ['eni', 'netplan', 'sysconfig'] output files.
[19:42] <rharper> I don't think we have a v1 -> net_util.translate_network() path
[19:42] <rharper> which is what's happening here
[19:44] <rharper> robjo: and there are no unit tests for net_util
[19:44] <robjo> :(
[19:45] <blackboxsw> meh the problem with 63% unittest coverage, is the other 37%
[19:47] <rharper> whats the delta in rhel sysconfig paths and suse ones?
[19:47] <rharper> that seems like a shorter path (using sysconfig renderer in the suse distro class)
[19:48] <robjo> 'network' (SUSE) vs. 'network-scripts' (RHEL) , yes I also roll my eyes over stuff like this ;)
[19:48] <rharper> man, that wants some temporary symlinking
[19:48] <rharper> if that's it
[19:49] <robjo> well "two ugly" do not really make "one pretty"
[19:49] <rharper> nope
[19:49] <rharper> but the instance boots with networking
[19:50] <rharper> too bad we can't ask sysconfig what paths it's using
[19:51] <robjo> but I suppose I could force the symlink in the cloud-init package, although I I remember correctly I tried to patch the path for 0.7.9 and that failed
[19:51] <rharper> robjo: where duse SUSE put the /etc/sysconfig/network (global settings) file ?
[19:52] <robjo> of course when 17.1 came around I had forgotten all of that and just moved forward since a good chunk of my out of tree code was now included
[19:52] <rharper> on RH, that has NETWORKING=yes and NETWORKING_IPV6=yes ;
[19:52] <robjo> the global settings file is /etc/sysconfig/network/config
[19:53] <rharper> urg
[19:53] <rharper> so both those paths
[19:53] <robjo> I suppose in the rendered we could test the and then switch between 'network' and 'network-scripts' but that's not very pretty either
[19:54] <robjo> s/rendered/renderer/
[19:54] <rharper> well, I was thinking about that as well but; I think there may be other issues
[19:54] <rharper> in that config file, it uses NETCONFIG_* namespace for some variables
[19:55] <rharper> I suspect you'd need a subclass of sysconfig for some things, but others would be fine
[19:56] <rharper> bbiab
[19:56] <robjo> yes, there are NETCONFIG_* settings in that file
[19:57] <robjo> I agree that the proper route is subclassing i.e. refactoring, hence my question during the meeting
[19:58] <robjo> I think the shorter path for now may be to figure out a v1 -> net_util.translate_network()
[19:58] <robjo> unfortunately I am getting lost in network_state.py in parse_config_v1, cannot quite wrap my head around what's happening there
[20:04] <robjo> BTW at least in the code the path from v1 -> net_util.translate_network() at the high level is not too convoluted
[20:05] <robjo> If I put he puzzle together properly it would go along these lines:
[20:08] <robjo> apply_network_config -> this raises an exception which is caught and gets me to _apply_network_from_network_config here the config gets transformed vi network_state.parse_net_config_data() and eni.network_state_to_eni() then we end up in apply_network which finally calls _write_network() and the last method is implemented in the distro subclass and for openSUSE/SLES we end up caling net_util.translate_network()
[20:09] <robjo> my thinking is that either in network_state.parse_net_config_data() or eni.network_state_to_eni() something goes wrong
[20:29] <smoser> blackboxsw: were you looking at centos fail ?
[20:31] <smoser> i verified it does fail here locally
[20:31] <smoser>  ./tools/run-centos --unittest 7 --keep
[20:33] <blackboxsw> smoser: yeah I had forgotten while fixing up disable and the blogpost. but reproduced on 6 and I'm working now
[20:41] <blackboxsw> looks like the URLError text raised is different in centos than ubuntu: 403 Client Error: Forbidden for url: %s versus just "403 Client Error: Forbidden"
[20:41] <blackboxsw> thx ubot5
[20:42] <blackboxsw> I'll update a patch to provide the bad_url if not present in the error message
[20:43] <smoser> nacc: i think you told me of somethign that is like
[20:43] <smoser>  git commit-tree && HEAD
[20:43] <smoser> ie, head after commit-tree
[20:43] <smoser> ?
[20:45] <nacc> smoser: sorry, not followinng
[20:46] <smoser> if i have changes in my working directory
[20:46] <smoser> i wanted to refer to HEAD + changes-to-tracked files
[20:47] <smoser> ithink like this https://stackoverflow.com/questions/2766600/git-archive-of-repository-with-uncommitted-changes
[20:47] <nacc> smoser: you can write-tree
[20:47] <nacc> smoser: and that gives you a treeish
[20:47] <nacc> and git-archive can archive a treeish
[20:47] <nacc> smoser: it depends on what you want to do ... HEAD points to a commit, so it can't point to an uncommited state
[20:47] <smoser> and the yes
[20:48] <nacc> smoser: is there any reason you ca't just do a wip commit?
[20:48] <nacc> (which you might discard later)
[20:49] <smoser> how do you you reset to state before the commit ?
[20:50] <smoser> including 'git add' or other things.
[20:51] <smoser> ie, if i
[20:51] <smoser>  touch foo
[20:51] <smoser>  git add foo
[20:52] <smoser>  git commit -a -m "that wip commit"
[20:52] <smoser>  git reset HEAD^
[20:52] <nacc> smoser: you can alwasy reset --hard to a commit
[20:52] <smoser> then i've lost the fact that 'foo' was added
[20:52] <nacc> smoser: and potentially do a `git clean -fxd`
[20:52] <nacc> smoser: no, it's still inn the commit you created
[20:52] <smoser> yeah, but the state of having been added is lost
[20:52] <nacc> smoser: i mean, i'm not sure i understand the use case, exactly
[20:52] <smoser> except for in that commit
[20:55] <nacc> smoser: oh you want to go back to an index state?
[20:57] <smoser> yeah, that was the goal.
[20:57] <smoser> basically i wanted to collect the tree up as it is right now.
[20:57] <smoser> wierd, i looked at 'git stash create'
[20:57] <smoser> this seems wrong:
[20:57] <smoser>  echo "hi mom" > foo.txt
[20:57] <smoser>  git add foo.txt
[20:57] <smoser>  git stash create
[20:57] <smoser> the stash does not contain the new 'foo.txt'
[20:58] <smoser> oh wait. it does
[21:00] <blackboxsw> powersj: smoser https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/333845 for the ci nightly errors
[21:01] <rharper> robjo: re v1 -> translate; I think at least for the immediate concern, matching the post-up "default gw" -> gateway: <value>  ought to get that working
[21:01] <nacc> smoser: i'm still trying to understad why you want the tree up to now? for a git-archive call?
[21:02] <robjo> rharper: ?
[21:02] <rharper> robjo: by my reading it goes config-drive -> openstack helper convert_network_data_json to v1 config -> v1 config gets rendered to eni, then the eni content get's passed to your class which calls net_util.translate()
[21:03] <robjo> OK, then I am on a wild goose chase
[21:04] <rharper> yes, the https://bugzilla.opensuse.org/attachment.cgi?id=749026
[21:04] <rharper> shows the 2017-11-16 15:26:39,868 - opensuse.py[DEBUG]: Translated ubuntu style network settings # Converted from network_config for distro <class 'cloudinit.distros.opensuse.Distro'
[21:04] <rharper> and then prints out the eni that got converted from v1 config
[21:05] <rharper> in distro base-class, it emits the Warning, thand then does a ns = network_state_parse_config(which is fed the v1 which was converted from the network-data json, you can see the v1 config earlyer in the log)
[21:06] <rharper> then in base distro, it does content = eni.network_state_to_eni() which makes an eni file; and passes that to the distro specify layer (self.apply_network() -> self._write_network())
[21:06] <robjo> I am confused about where the openstack helper comes into play
[21:06] <rharper> converting the config drive network_data.json
[21:06] <rharper> when the Datasource is parsing it's input
[21:10] <rharper> robjo: cloud-init local runs to find the datasource, detects config-drive and runs the ConfigDrive datasource; in it, if there is a file network_data.json, it calls the helper to convert the json into v1 config and storages it in DataSource class property (network-config);  then as cloud-init local continues, if the datasource has a 'network-config' property; it it's read and "rendered"
[21:10] <rharper> 2017-11-16 15:26:39,825 - stages.py[DEBUG]: applying net config names for {'version': 1, 'config': [{'subnets': [{u'routes': [{u'netmask': u'<IP_ADDRESS>', u'network': u'<IP_ADDRESS>', u'gateway': u'<IP_ADDRESS>'}], u'netmask': u'<IP_ADDRESS>', u'type': 'static', 'ipv4': True, 'address': u'<IP_ADDRESS>'}], 'mac_address': u'fa:16:3e:ee:2b:97', u'type': 'physical', 'name': 'eth0', u'mtu': 1500}]}
[21:10] <rharper> there you can see stages applying the v1 config that it got from the configdrive data source (after the network_data.json conversion)
[21:11] <robjo> yes, that very early part I ignored and I started with that data and where I think it would end up in the code
[21:11] <nacc> smoser: sorry for being dense if i'm missing something obvious
[21:12] <robjo> and as I noted in comment #32 in the bug gateway information is missing from the renedered intermediate format
[21:14] <rharper> right, that;s due to hoe the eni is rendered
[21:14] <rharper> the gateway is inside the post-up route add default gw <gatewayip>
[21:14] <rharper> the net_util.translate does not know how to (yet) extract the gateway value from the eni contents
[21:15] <rharper> so, I believe in that net_util.translate, you can check if line has 'post-up' and 'default gw' strings
[21:15] <rharper> and extract out the ip addr in there and use that as the GATEWAY= value in sysconfig
[21:16] <rharper> you can see the v1 dictionary has 'gateway': <IP_ADDRESS> which matches the post-up line; post-up route add default gw <IP_ADDRESS> || true
[21:18] <robjo> OK I think I think I get how that part of the puzzle fits together
[21:23] <rharper> the network_data.json file may have other routes that are not default gateway ones, so there may be additional {pre,post}-{up,down} routes added which will also need converting to the sysconfig syntax; depending on how far you want to take the translator
[21:26] <robjo> well everything that is not "default gw" shoud really go into ifroute-IFACE
[21:28] <rharper> yes, I think so
[21:28] <rharper> we generally only had special handling for default gw, vs. route add -net


[12:15] <tsmithe> ok i've got to go to bed, exams and all
[12:15] <tsmithe> if B-D is fine, then there's that upload
[12:15] <tsmithe> if not, then there's
[12:15] <tsmithe> http://revu.tauware.de/details.py?upid=5562
[12:15] <tsmithe> thanks :)
[12:19] <geser> crimsun: should all build-deps after cdbs be moved to b-d-i?
[12:20] <geser> does it really matter for an arch-all only package? as it got only build once
[12:21] <crimsun> (looking)
[12:22] <DarkSun88> G'night.
[12:26] <crimsun> geser: python definitely needs to be moved.  It should be safe to move them all as you suggest.
[12:29] <geser> ok will move them and upload
[12:31] <ryanakca> would it be worth making a motu-mud team, since there's a pile of unpackaged MUD servers and clients out there? or would it all fall to another team?
[12:33] <crimsun> ryanakca: a subteam of motugames, mayhap?
[12:33] <crimsun> ryanakca: would probably make sense to see to it in Debian first
[12:35] <ryanakca> crimsun: maybe. hmm... yeah
[12:40] <crimsun> what persia typed.
[12:41] <ryanakca> persia: ok
[12:44] <persia> ryanakca: http://wiki.debian.org/Games/Development may be of interest.
[12:49] <persia> Those performing merges: please check the +bugs page for the package, and include a section detailing bugfixes from upstream or Debian in the changelog with (LP: #bugnumber) tags to close any bugs addressed by the new Debian revision.
[12:51] <ryanakca> hmm... what do I do if there's already a package in the repos with the same name as the one I want to package? ex: mcl , http://micans.org/mcl/
[12:51] <ryanakca> (in repo), and http://www.andreasen.org/mcl/ , that I want to package
[12:52] <persia> ryanakca: Pick a new name (mcl-mud maybe?).
[12:52] <ryanakca> persia: ok
[12:54] <ryanakca> persia: hmmm... I don't know if it's worth packaging... abandoned, uses python 2.2... gcc-3.3, etc
[12:55] <persia> ryanakca: Unless you use it, and especially like it, it's probably better to skip then: lots of work to keep it in the archives, and likely lots of bugs that must be fixed in packaging.
[12:55] <ryanakca> persia: ok
[12:59] <persia> More generally, it's not best practice to package everything out there: only the "best-of-class" apps for each category, or programs you find beneficial for your preferred activities.
[01:01] <geser> we have currently over 600 packages that aren't in Debian
[01:01] <geser> if no MOTU looks after them, they don't get updated
[01:03] <persia> I wonder if we shouldn't add the filing of an RFP as a requirement for package inclusion, except where the package would only be interesting to Ubuntu.
[01:05] <geser> does somebody know if http://tiber.tauware.de/~lucas/versions/ tracks gutsy or still feisty?
[01:08] <persia> geser: It looks like feisty to me - I don't see the merges being reported as having happened.
[01:20] <bluekuja> persia, geser can you look at https://bugs.launchpad.net/ubuntu/+source/telepathy-mission-control/+bug/120633?
[01:20] <ubotu> Launchpad bug 120633 in telepathy-mission-control "Sync telepathy-mission-control 4.24-1 from debian unstable" [Undecided,Confirmed]
[01:20] <bluekuja> persia, geser seems that unstable guy made an error on the changelog
[01:20] <bluekuja> written from daniel
[01:21] <bluekuja> I've debdiffed it
[01:21] <bluekuja> and there's no changes
[01:21] <bluekuja> any idea on how can we process it?
[01:22] <persia> bluekuja: 1) It's best to ask the channel generally, rather than specific individuals.  2) That's the result of a Debian sync from Ubuntu.  Nice when it happens.  It's probably safe to sync back, but you might want to check with Daniel.
[01:22] <geser> if he took the ubuntu package and uploaded it to debian unstable, it's ok to credit dholback in the changelog
[01:23] <bluekuja> persia, ok thanks
[01:23] <bluekuja> persia, gonna ping daniel for it
[01:23] <bluekuja> to be sure that we want a sync
[01:23] <bluekuja> thanks guys, gonna sleep
[01:23] <bluekuja> cu tomorrow
[01:25] <geser> cu
[04:08] <TheMuso> Heya folks.
[04:18] <joejaxx> hello TheMuso :)
[04:21] <TheMuso> Hey joejaxx.
[05:02] <StevenK> Maintainer: Ubuntu MOTU developers<EMAIL_ADDRESS>[05:02] <StevenK> XSBC-Original-Maintainer: Ubuntu MOTU Developers<EMAIL_ADDRESS>[05:02] <StevenK> Original-Maintainer: Martin v. Lwis<EMAIL_ADDRESS>[05:02] <Fujitsu> Um... Which package?
[05:03] <StevenK> python-xlib
[05:03] <StevenK> I'm 80% certain it can get sync'd, so the point is moot.
[05:05] <dmb> whats the best way to get a folder in /usr/lib to be in the library search path when creating a package?
[05:05] <dmb> /usr/lib/yourprogramname
[05:15] <zakame> good day MOTUs
[06:08] <brylie> hello, can anybody point me to an article related to creating a metapackage for the apt repository so that the devs of a project can change the name of the .deb and allow anyone with the old version installed to migrate to the new naming standard?
[06:08] <brylie> specifically, the current naming standard is 'python2.x-exe_x.xx.x.deb' and the new name would [hopefully]  be 'exe_x.xx.x.deb'
[06:14] <crimsun> you don't need a metapackage to accomplish that
[06:15] <crimsun> simply amend debian/control's current python2.x-exe entry to Depends: exe
[06:17] <crimsun> it would also be a good idea to amend python2.x-exe's one-line [short]  Description to mention [transitional package]
[06:18] <brylie> ok cool
[06:19] <brylie> I'll forward that info to the devs
[06:20] <brylie> the package hasn't actually made it to the universe repository yet and I want to encourage them to rename the .deb
[06:20] <brylie> so when/if a MOTU submits it it will be more relevant
[06:25] <crimsun> interesting transition.  Why exe and not python-exe?
[07:12] <_MMA_> Hobbsee: You might be interested in this: http://ubuntuforums.org/showthread.php?t=475227
[07:12] <Hobbsee> _MMA_: neat.
[07:12] <Hobbsee> _MMA_: riddell pointed that out yesterday iirc.  looks cool.
[07:13] <_MMA_> Cool. :)
[08:05] <lucas> geser: the cron is disabled due to resources problems on tiber
[08:22] <bonii> j #ubuntu-motu-classroom
[09:14] <Fujitsu> Hmmmmmm. Why has Xorg eaten 230MiB of RAM?
[09:15] <Flannel> Fujitsu: it's hungry
[09:15] <Fujitsu> Obviously. Even Epiphany has eaten less, and I've got at least a hundred tabs open.
[09:17] <lathiat> has it been running for a month? :)
[09:17] <lathiat> epiphany is probably using all that ram for X server resources it leaked ;)
[09:18] <Fujitsu> Hahah. No, it was rebooted a couple of days ago after I left it running on the kitchen table, unplugged.
[09:18] <Hobbsee> hiya lathiat, Fujitsu, Flannel
[09:18] <Fujitsu> Hi Hobbsee.
[09:18] <Flannel> Howdy Hobbsee
[09:24] <tsmithe> geser, are you michael vorlon.ping.de? if so, thanks for the upload and the B-D-I stuff :) why are debhelper and cdbs still kept as Build-Depends?
[09:24] <tsmithe> well, that question could be for anyone
[10:39] <tobiasschulz> all MOTUs: can you check and maybe advocate http://revu.tauware.de/details.py?upid=5552 ?
[10:54] <geser> tsmithe: yes, that's me. debhelper is still in B-D as everything (like dh_clean) which isn't only used in the binary-arch-indep target in debian/rules must be in B-D
[10:54] <geser> the same for cdbs
[11:01] <geser> lucas: ups, didn't notice that the files are outdated (as yesterday was also a 15th). I found this service useful.
[11:04] <tobiasschulz> MOTUs: can you check and maybe advocate http://revu.tauware.de/details.py?upid=5552 ?
[11:06] <pochu> tobiasschulz: any reason you're packaging it as a native package?
[11:09] <tobiasschulz> pochu: ??
[11:09] <tobiasschulz> "native package"?
[11:10] <pochu> tobiasschulz: why the upstream tarball has the "0ubuntu7"?
[11:10] <pochu> And why it hasn't "-0ubuntuX" (the 0 is the Debian revision)
[11:10] <tobiasschulz> it has
[11:10] <tobiasschulz> ...0ubuntu7
[11:11] <tobiasschulz> 0ubuntu8
[11:11] <pochu> Sorry, why it hasn't a slash (-)
[11:11] <pochu> -0ubuntuX
[11:12] <tobiasschulz> why a shlash?
[11:12] <Fujitsu> pochu: That's a minus, hyphen, or dash.
[11:12] <Fujitsu> slash == /
[11:13] <tobiasschulz> why msut there be a - in the version number bofore 0ubuntuX?
[11:13] <tobiasschulz> #
[11:14] <pochu> tobiasschulz: yes, dash :)
[11:14] <pochu> tobiasschulz: It's the policy
[11:14] <Fujitsu> tobiasschulz: Because that's how the Debian versioning scheme works, unless it's a native package (ie. is specifically for Debian; there's no upstream releases as such)
[11:14] <tobiasschulz> there is an upstream release ^^
[11:15] <pochu> tobiasschulz: also, please rename the upstream tarball so it's jeliza_<upstream-release-number>.orig.tar.gz, but skip the ubuntu revision number.
[11:18] <pochu> tobiasschulz: also, since it's the first release, use -0ubuntu1, rather than 7
[11:21] <tobiasschulz> but i've iploaded it 8 times to http://revu.tauware.de/details.py?upid=5552 while i corrected bugs in the package
[11:21] <pochu> It doesn't matter, as long as you don't upload to the archive :)
[11:24] <Kmos> tobiasschulz: you'll learn more with time :)
[11:24] <pochu> As I do :)
[11:41] <Kmos> pochu: liferea v1.2.17 is out, you want to update ?
[11:42] <Kmos> current: https://launchpad.net/ubuntu/+source/liferea/1.2.16b-0ubuntu1
[11:43] <pochu> Kmos: already updated :)
[11:43] <pochu> I'm waiting slomo to sponsor me ;)
[11:43] <Kmos> ha :) ok.. nice work
[12:01] <man-di> Can some someone please look at http://revu.tauware.de/details.py?upid=5564 ? This fixes the runtime dependencies so that you can use every java runtime with it
[12:32] <afflux> the source package swfdec0.4 had a ftbfs due to a dependency problem on 2007-05-03, which seems fixed now (at least it works in my pbuilder). Can someone restart the build-process (or tell me who I have to contact for that)?
[12:34] <pochu> afflux: ask in #ubuntu-devel, any archive admin will reprocess it.
[12:35] <afflux> okay, thank you
[12:36] <crimsun> cd
[12:38] <StevenK> persia: Okay, a few issues with sbuild.
[12:39] <StevenK> persia: Number one, I miss my pdebuild, since it seems I have to make a source package before I can let sbuild loose on it. Secondly, my amd64 sbuild won't build arch all packages.
[12:40] <persia> StevenK: `sbuild -A -d gutsy foo.dsc`, and it's handy to generate the right source first, as that way one can just dput source.changes if everything worked well.
[12:41] <StevenK> persia: But pdebuild does it for me!
[12:42] <persia> StevenK: pdebuild builds a source package, then builds the binary from the source in the manner of the buildds, then gives you all the logs and a dput'able source to upload?
[12:43] <StevenK> persia: It will do everything but log by default. Logging can be turned on.
[12:44] <persia> StevenK: You could always write sdebuild, which would build the source, and call sbuild :)
[12:44] <man-di> persia: time to look at http://revu.tauware.de/details.py?upid=5564 ?
[12:45] <persia> Let's see: first decide if it's -S or -S -sa, then build the source, then sbuild.  Hmm.  I'd use such a script, if it existed.
[12:45] <persia> man-di: Sure.
[12:45] <StevenK> persia: Personally, if I want logs from pdebuild, I pipe it to tee
[12:46] <persia> StevenK: I think this is a care of preference for different automation :)
[12:47] <persia> man-di: You don't need REVU for this.  Just attach the debdiff to 81876, and subscribe U-U-S (and I'm archiving the REVU, as it's hard to distinguish the latest changes from previous changes).
[12:49] <man-di> persia: ok, thx
[12:49] <StevenK> persia: Seems to be. :-)
[12:50] <StevenK> sbuild seems a little fragile, too.
[12:50] <StevenK> persia: Oh, a complete lack of usage information for sbuild is incredibly irritating.
[12:50] <persia> StevenK: That's one of the reasons I prefer it.  I want it to break locally before it breaks on the buildds.
[12:51] <StevenK> persia: I was actually refering to the lvm-snapshot bit, which the buildds don't use. I've seen that go boom twice
[12:51] <persia> StevenK: Yep.  The documentation needs work.  I wanted to have a working sbuild for years, but didn't actually get one working until the instructions were put on the wiki.
[12:52] <persia> StevenK: Are you using the latest schroot, with all the patches?  I'm still holding on to sbuild 0.53, but the latest schroot seemed to fix a lot of the LVM-snapshot issues I was having before.
[12:53] <persia> (Alternately, Kees posted some patches for feisty schroot, if you prefer that)
[12:54] <StevenK> I'm using the schroot in Feisty
[12:55] <persia> StevenK: You need the patches from debian bug 391319 then :)
[12:55] <ubotu> Debian bug 391319 in schroot "schroot: leftover processes cause umount to fail" [Normal,Fixed]  http://bugs.debian.org/391319
[12:55] <persia> (otherwise, yes, it's terribly broken)
[01:00] <man-di> persia: is https://bugs.launchpad.net/ubuntu/+source/libcommons-dbcp-java/+bug/81876 okay this way?
[01:00] <ubotu> Launchpad bug 81876 in libcommons-dbcp-java "Dependency on java2-runtime removed" [Undecided,Confirmed]
[01:01] <persia> man-di: In terms of bug processing that's perfect.  I'll look at the debdiff now (also if you just say "bug nnnnnn", the bot will spew the URL).
[01:02] <man-di> the url was still in m paste buffer so it was easier ;-)
[01:03] <StevenK> Naughty TheMuso!
[01:03] <man-di> persia: thanks for taking a look
[01:03] <StevenK> (His the GPG key id the Debian upload processor complained about)
[01:03] <coNP> Anyone can help me why I cannot sign a package?
[01:03] <coNP> Or better provide a detalied howto?
[01:04] <bluekuja> StevenK, he tried to upload my package :P
[01:04] <bluekuja> StevenK, but he missed archive
[01:04] <bluekuja> ^^
[01:04] <StevenK> He was aiming for Ubuntu?
[01:04] <bluekuja> yea
[01:04] <StevenK> Heh
[01:04] <bluekuja> that's a merge I did
[01:05] <bluekuja> and he was following
[01:05] <bluekuja> ;)
[01:05] <geser> coNP: what's the problem?
[01:05] <coNP> gpg: problem with the agent - disabling agent use
[01:05] <coNP> debsign: gpg error occurred!  Aborting....
[01:05] <coNP> debuild: fatal error at line 1166:
[01:05] <coNP> running debsign failed
[01:06] <persia> coNP: put "DEBUILD_PRESERVE_ENVVARS=DISPLAY" in ~/.devscripts, or disable your gpg-agent.
[01:07] <coNP> persia: many thanks, seems to work now
[01:11] <persia> man-di: Um..  Why do we want to revert that change?  It looks like Mathias intentionally applied it for dapper, and I don't have enough context to know either 1) why it was applied, or 2) why it can be dropped now.
[01:13] <man-di> persia: the fix makes it possible to not install gcj/kaffe when e.g. using eclipse with SUN JDK
[01:13] <man-di> this fix was never correct
[01:17] <geser> persia: see also bug #119560 which was acked by you
[01:17] <ubotu> Launchpad bug 119560 in libcommons-dbcp-java "Please sync libcommons-dbcp-java 1.2.1-5 from Debian unstable" [Wishlist,Fix released]  https://launchpad.net/bugs/119560
[01:17] <geser> and then a merge reintroduced the changes
[01:19] <persia> geser: That's part of why I asked.  I personally think the sync was best, don't understand why the merge was processed, and don't want to be involved in an upload war.
[01:20] <geser> as bluekuja is here, we can ask him why it was merged
[01:21] <bluekuja> geser: didnt see the bug on lp
[01:21] <bluekuja> so I processed it like every merge
[01:21] <bluekuja> I already talked about it with man-di
[01:22] <man-di> ???
[01:22] <bluekuja> man-di, are you talking about libcommons-java ?
[01:23] <bluekuja> you pinged me that day?
[01:23] <persia> bluekuja: Please check more carefully for package bugs and package versions in the future.  Also, based on your comment, I'll upload the reversion for ibcommons-dbcp-java
[01:23] <bluekuja> persia, yeah sorry, really didnt see it on lp
[01:23] <bluekuja> so I cannot do anything
[01:23] <bluekuja> ;)
[01:23] <man-di> bluekuja: libcommons-dbcp-java
[01:23] <bluekuja> man-di, yeah
[01:49] <coNP> Can you please sync revu keyring (I joined u-u-c team in lp recently)?
[01:50] <Hobbsee> coNP: sure, i'tll be ~10 mins, iirc
[01:52] <coNP> Thanks, I guess I can figure it when it is done, since I can start uploading packages then. Am I right?
[01:53] <Hobbsee> coNP: i'll tell you
[01:53] <coNP> oh, thanks :)
[01:53] <Hobbsee> coNP: seeing as i can see the output here :)
[01:53] <coNP> wow :)
[02:00] <Hobbsee> coNP: it's done
[02:00] <Hobbsee> wow, exactly 10 :P
[02:00] <coNP> thanks, Hobbsee
[02:01] <Hobbsee> no problem
[02:01] <coNP> It is a pity I am not done yet. Can someone hint if it is a pbuilder setup error or a dependency error in my package: http://pastebin.ca/569742
[02:02] <Hobbsee> coNP: means you dont have libpango1.0-dev as a build-dep
[02:03] <Hobbsee> (apt-cache search pango, and pick a -dev package that looks likely, and try it)
[02:03] <coNP> Oh, thanks!
[02:04] <Hobbsee> no problem
[02:05] <Q-FUNK> stange that something would depend on pango alone without gtk2.
[02:06] <coNP> it is Openbox
[02:06] <coNP> no gtk.* for sure
[02:06] <DarkMageZ> if openbox doesn't use gtk then what toolkit does it use?
[02:07] <coNP> I guess none
[02:08] <Q-FUNK> coNP: http://icculus.org/openbox/index.php/Help:Installing
[02:08] <coNP> thanks, Q-FUNK
[02:10] <Q-FUNK> coNP: no problemo.  it's generally a good idea to look at a project's homepage before building.  they usually include a fairly accurate description of the dependencies.
[02:11] <coNP> I wanted to update the package and first tried to build without adding anything. Actually I wasn't even sure if it is a pbuilder or a packaging error.
[02:11] <coNP> but now configure is done, make is invoked
[02:12] <Hobbsee> it's a packaging error
[02:12] <Hobbsee> as in, you need the extra build dep
[02:12] <coNP> Okay, thanks. I understand now.
[02:12] <coNP> It is even compiling now properly.
[02:13] <coNP> This dependency was the only one missing
[02:13] <Hobbsee> :)
[02:13] <Q-FUNK> groovy :)
[02:15] <afflux> geser: before you start working on the quodlibet-plugins bug: I just got a mail from gutsy-changes that Andrea Veri has already uploaded -1ubuntu2
[02:16] <SlimG> How do I make my .deb package respond correctly to a apttitude purge  ? I guess I have to add an additional script to remove config files..?
[02:16] <SlimG> s/apttitude/aptitude/
[02:16] <bluekuja> heya TheMuso
[02:16] <man-di> SlimG: thats normally done all by dpkg automatically
[02:16] <bluekuja> afflux, what's the problem?
[02:16] <man-di> SlimG: when the files are known as conffiles
[02:17] <geser> afflux: I know, guess who sponsored the upload :)
[02:17] <Q-FUNK> SlimG: unless your package manually copies files during postinst, it should be removed by dpkg automatically.
[02:17] <man-di> SlimG: configurations files need to handled in *.postrm
[02:17] <Q-FUNK> sync :)
[02:17] <afflux> geser, bluekuja: oops. Maybe the launchpad mailinglist was a bit slow :)
[02:18] <Q-FUNK> coNP: brownie points?  what's the recipe?
[02:18] <coNP> Q-FUNK: :) https://wiki.ubuntu.com/MOTU/Recipes/PackageUpdate
[02:18] <bluekuja> afflux, np ;)
[02:19] <SlimG> man-di: I'm referring to those files stored in $HOME/.appname/  ,I guess these have to be removed with a .postrm file then
[02:19] <Q-FUNK> SlimG: files in someone's home directory should never be touched, as a ground rule.
[02:19] <SlimG> Q-FUNK: not even with purge?
[02:21] <SlimG> Q-FUNK: well, thanks for your ground rule
[02:21] <SlimG> man-di: thanks for your help!
[02:21] <Q-FUNK> SlimG: the user might end up installing a locally-compiled package or re-use configs with a similar package, so no.
[02:21] <Q-FUNK> lovely updating guide he wrote, dholbach.
[02:22] <Q-FUNK> here, I guess i'm just used to the wonders of uscan.
[02:38] <coNP> Oh I guess something went wrong. Can someone help me delete the wrong files from revu?
[02:38] <tobiasschulz> MOTUs: can someone look at this and maybe advocate please: http://revu.tauware.de/details.py?upid=5565
[02:38] <coNP> dput says dcut might help for  official Debian uploads which is not the case I guess
[02:46] <pochu> tobiasschulz: you need to create a file called "compat" in the debian/ dir, with a '5' in it (which is the debhelper compatibility)
[02:48] <Q-FUNK> tobiasschulz: echo 5 > debian/compat
[02:49] <Q-FUNK> sync :)
[02:49] <tobiasschulz> ok
[02:51] <coNP> pochu: can you help me how to delete an uploaded file from REVU?
[02:51] <persia> coNP: Which files?
[02:51] <pochu> coNP: I'm not a REVU admin, but you can archive it, can't you?
[02:52] <coNP> persia: openbox_3.4*
[02:52] <pochu> tobiasschulz: also, you'd have to fix this: http://revu.tauware.de/revu1-incoming/jeliza-0706160705/linda
[02:52] <coNP> I uploaded the wrong files (i386 instead of the source)
[02:52] <coNP> and as I wanted to dput it again it said it were not possible
[02:52] <persia> coNP: Deleted.  Try again.
[02:53] <coNP> persia: thanks
[02:53] <persia> For general consumption: REVU does not support dcut (as far as I can tell).
[02:53] <coNP> Yep, I tried and failed. Therefore I asked if someone can please help :)
[02:54] <pochu> Hobbsee: are you a REVU admin?
[02:54] <Hobbsee> pochu: not admin - but i have access. why?
[02:54] <pochu> siretart and ajmitch are, but they don't seem to be around...
[02:54] <Hobbsee> what do you need?
[02:55] <Hobbsee> no, revu doesnt support dcut, neither does upload.ubuntu.com
[02:55] <xxxxx1> morning all!
[02:56] <coNP> How can I provide a file to a pbuilder that is not in Ubuntu yet? Actually I want to compile obconf that depends on openbox. I only have a self-built package from this version.
[02:57] <geser> is aurora.ubuntuwire.com offline?
[02:57] <persia> coNP: You can either 1) create a local repository, modify sources.list in the tarfile, pbuilder update, or 2) manually install the new software in the tarball.  #1 is much better.
[02:57] <tobiasschulz> pochu: how can i fix that: http://revu.tauware.de/revu1-incoming/jeliza-0706160705/linda
[02:58] <coNP> persia: sorry, which tarball you mean?
[02:58] <persia> geser: Dead for me (I can reach the router).
[02:58] <Hobbsee> ew.  i tend to prefer 2.
[02:58] <persia> coNP: the pbuilder tarfile.
[02:58] <Hobbsee> geser: has been for the last week, i think
[02:59] <persia> Hobbsee: After one is done with experimenting with #2, one needs to regenerate the tarball.
[02:59] <Hobbsee> dpkg-buildpackge -S -as
[02:59] <Hobbsee> coNP: personal package archives.  LP thing.  sor tof exists
[02:59] <persia> (not really yet - hasn't been announced)
[03:00] <geser> is the arch-all packages bug in PPA fixed already?
[03:00] <tobiasschulz> how can i fix that: http://revu.tauware.de/revu1-incoming/jeliza-0706160705/linda
[03:01] <tobiasschulz> ?
[03:01] <mok0> Who is the person in charge of the REVU programming?
[03:01] <Hobbsee> mok0: siretart
[03:01] <Hobbsee> geser: no idea
[03:01] <mok0> Hobbsee: thx
[03:03] <siretart> mok0: yes?
[03:04] <mok0> siretart: Oh, I just thought it would be cool to have an XML feed of the revu comments etc.
[03:05] <mok0> siretart: There's a python module to do it
[03:08] <coNP> How could I check out PPA?
[03:08] <coNP> Is it possible?
[03:08] <mok0> siretart: I guess the correct term is RSS feed
[03:09] <mok0> siretart: just a suggestion
[03:10] <pochu> tobiasschulz: I'm not sure, but try changing "Its" with "It's"
[03:11] <mok0> siretart: gotta go, email me if you want to discuss further
[03:11] <bluekuja> pochu, same thing I said him to do
[03:11] <bluekuja> :)
[03:11] <bluekuja> that char is not allowed
[03:12] <pochu> bluekuja: hmm, I can't see where you told him that :)
[03:13] <bluekuja> pochu, he pmed me ;)
[03:13] <pochu> Ah, that explains it :)
[03:13] <bluekuja> :)
[03:13] <tobiasschulz> ^^
[03:16] <pochu> tobiasschulz: also, create jeliza.desktop inside debian/, instead of usr/share/applications. Then install it with dh_install
[03:19] <coNP> persia: how can I create an own repository? Or maybe add a source package to the pbuilder tgz?
[03:22] <persia> coNP: For real private repository management, I believe falcon is the current recommendation, but you can cheat by uploading to any FTP or HTTP (including <IP_ADDRESS>), with a subdirectory for your private distribution, and a correctly formatted Packages.gz.  Someone else might be able to give more detailed advice.
[03:23] <persia> coNP: Also, dpkg-scanpackages might help (depending on what you do).
[03:29] <tobiasschulz> i've fixed the bug, it was the "" char!
[03:29] <tobiasschulz> http://revu.tauware.de/details.py?upid=5568
[03:34] <DarkSun88> Hi all
[03:35] <coNP> persia: What exactly should I insert to a "Source.gz" file (I guess from debian/control, etc.)
[03:35] <TheMuso> Ok. I have a very frustrating problem with a package. Attempting to upload a merged qjackctl package for someone, and no matter what I try, even using Ubuntu's .orig.tar.gz file, I still get an MD5sum error.
[03:35] <TheMuso> Sid's orig and gutsy's orig have different MD5sums, even though there is no difference in package contents.
[03:35] <Hobbsee> TheMuso: where does teh md5sum error come in?
[03:35] <TheMuso> Suggestions welcome.
[03:36] <TheMuso> Hobbsee: Soyuz says the MD5sum of a file, I assume its the orig, but it doesn't say, doesn't match.
[03:36] <TheMuso> I don't have an email to refer to, as I deleted it in frustration.
[03:37] <Hobbsee> right
[03:37] <man-di> persia: when will the bugfix for libcommons-dbcp-java be marked fix released? Will be it done automatically?
[03:38] <Hobbsee> TheMuso: can you dump the packages somewhere, or maybe uplaod it again, and get the rejected email?
[03:38] <Hobbsee> TheMuso: dunno how best to help, when i cant see the thig
[03:38] <TheMuso> Hobbsee: I have done the latter.
[03:38] <Hobbsee> *thing
[03:38] <Hobbsee> okay
[03:39] <persia> man-di: Um.  Let me check the .changes file.  It's supposed to be automated.
[03:39] <shawarma> TheMuso: The md5sums typically come from different timestamps in the gzip part.
[03:39] <shawarma> TheMuso: Um.. The *differing* md5sums typically.. etc.
[03:39] <persia> coNP: In the root of the target archive directory.
[03:40] <coNP> sorry I might not be clear I know the structure of a repository
[03:40] <coNP> I just don't know what to put in the Sources  file
[03:40] <shawarma> coNP: Are you publishing source files?
[03:41] <TheMuso> Rejected:
[03:41] <TheMuso> MD5 sum of uploaded file does not match existent file in archive
[03:41] <TheMuso> Files specified in DSC are broken or missing, skipping package unpack
[03:41] <TheMuso> verification.
[03:41] <man-di> coNP: dpkg-scansources ... | gzip > Sources.gz does everything for you
[03:41] <coNP> thanks man-di
[03:42] <coNP> shawarma: no I try to build packages depending on other packages built by myself
[03:42] <persia> man-di: Not in this case.  The syntax is (LP: #bugnumber) rather than (LP: bugnumber).  Sorry for missing that.  Please mark "FIx Released" when you think appropriate (some say upload, some say build.  I generally follow build).
[03:42] <shawarma> coNP: Then you don't need a Sources.gz.
[03:42] <TheMuso> http://www.themuso.id.au/ubuntu/qjackctl
[03:42] <TheMuso> changes file and dsc file aren't signed, but thats basically it.
[03:42] <man-di> persia: sorry for my mistake
[03:43] <coNP> shawarma: then how do I tell my pbuilder to use the my brand new source package?
[03:43] <shawarma> coNP: You.. Um.. don't?
[03:43] <shawarma> coNP: You need you brand new *binary* packages?
[03:44] <coNP> Err I am wrong, they build-depend on my brand new source package.
[03:44] <tobiasschulz> (http://revu.tauware.de/details.py?upid=5568):
[03:44] <tobiasschulz> > 2) The package doesnt appear to do anything dur to the build: rule. Is the C++ code intended to compile? If not, why not? (README.Debian-source is a good place for the answer to this question).
[03:44] <tobiasschulz> > 3) If the C++ is intended to be compiled, you may want to check the library packaging guidelines.
[03:44] <tobiasschulz> It's a QT application, so it is compiled using
[03:44] <tobiasschulz> qmake jeliza.pro -o Makefile && make
[03:45] <Hobbsee> TheMuso: looking
[03:45] <shawarma> coNP: No. They build-depend on binary packages.
[03:45] <coNP> Yep. You are right.
[03:46] <persia> TheMuso: I have a qjackctl_0.2.22-2ubuntu1 already installed.  Doesn't one need an upstream version bump before making an upload that includes orig.tar.gz in source.changes?
[03:46] <TheMuso> Hobbsee: As I said, the md5 of the orig in sid is different to Ubuntu's, but I used the ubuntu one for the pkg.
[03:46] <Hobbsee> TheMuso: did you have a bug # that you were working from?  this is a sponsorship?
[03:46] <TheMuso> Hobbsee: Yes.
[03:47] <persia> TheMuso: Which bug?
[03:47] <TheMuso> hang on...
[03:47] <Hobbsee> i've found the problem
[03:47] <bluekuja> persia, I did it
[03:47] <bluekuja> e.g the debdiff
[03:47] <persia> bluekuja: No.  Your sponsor did it :)  You were helping.  Thanks again.
[03:48] <Hobbsee> TheMuso: use this widely.  lionel is your target.
[03:48] <TheMuso> Ok, twas me just not checking if it already existed, just like the original merger didn't.
[03:48] <bluekuja> persia, oh :D
[03:48] <Hobbsee> er, wisely
[03:48] <shawarma> Hobbsee: There's already a 0.2.22-2ubuntu1 in the archive?
[03:48] <shawarma> TheMuso: ^^
[03:48] <Hobbsee> shawarma: yep
[03:48] <TheMuso> shawarma: I know.
[03:48] <shawarma> Hobbsee: Not for you :)
[03:48] <persia> shawarma: yes
[03:48] <TheMuso> I didn't check, as I assumed...
[03:48] <shawarma> So.. Why upload it againg?
[03:48] <lionel> Hobse: What I did ?
[03:49] <lionel> rah
[03:49] <lionel> Hobbsee: What I did ?
[03:49] <TheMuso> bluekuja: DId you check before you filed the bug?
[03:49] <bluekuja> TheMuso, yes
[03:49] <bluekuja> who did it?
[03:49] <Hobbsee> lionel: wasnt what i thought.  i thought you'd sponsored without marking teh bug as such
[03:50] <Hobbsee> TheMuso: lionel's done the merge, without checking if anyone else had first, it looks like.  or bluekuja hasnt seen that lionel's already done the merge.
[03:50] <lionel> Which package?
[03:50] <TheMuso> lionel: qjackctl
[03:50] <persia> bluekuja: Where did you look (remembering libcommons-dbcp-java)?
[03:50] <lionel> Oh. I've done it yesterday yes
[03:50] <bluekuja> persia, I've pushed a bug on lp
[03:51] <bluekuja> for it
[03:51] <lionel> You're talking about the mail we received on ubuntu-motu ?
[03:51] <TheMuso> lionel: Please check if there is already a bug requesting a merge before you do it.
[03:51] <bluekuja> and someone did it
[03:51] <bluekuja> ..
[03:51] <TheMuso> lionel: No, that was an accident by me.
[03:51] <persia> bluekuja: Before doing the merge, did you search on LP for bugs on the package?
[03:51] <TheMuso> merge sponsorship even
[03:51] <TheMuso> persia: he said he did.
[03:52] <persia> bluekuja: My apologies.
[03:52] <bluekuja> persia, lionel did *NOT*
[03:52] <bluekuja> and made the merge
[03:52] <lionel> TheMuso: I think I checked before doing the merge. But I may be wrong
[03:52] <bluekuja> so it's not my fault
[03:52] <TheMuso> Its nobody's fault.
[03:52] <TheMuso> We just need to check before we start the merge, and then just before we upload.
[03:52] <Hobbsee> looks like they've filed on the same day.
[03:52] <TheMuso> persia: Thats what I have been doing.
[03:53] <bluekuja> yeah
[03:53] <lionel> It's a 5min merge, we are not going to spend 1h discussing a 5min merge:)
[03:53] <bluekuja> TheMuso, followed the policy correctly
[03:53] <bluekuja> lionel, yeah
[03:53] <bluekuja> dont worry for it then
[03:53] <TheMuso> Will close the bug.
[03:53] <Hobbsee> TheMuso: already done
[03:54] <TheMuso> Hobbsee: Thanks.
[03:54] <lionel> But I'm sorry If I did not notive something
[03:54] <Hobbsee> :)
[03:54] <Hobbsee> lionel: i'd guess it'
[03:54] <bluekuja> lifeless, np ;)
[03:54] <Hobbsee> s been filed at around the same time, so oh well
[03:54] <bluekuja> *lionel: np
[03:54] <bluekuja> ;)
[03:55] <bluekuja> lionel, qgis FTBFS in debian too
[03:56] <bluekuja> lionel, reported a bug to have it fixed
[03:56] <bluekuja> (all archsa affected)
[03:56] <lionel> I've seen your comment on the bug
[03:56] <bluekuja> *archs
[03:56] <bluekuja> gnight TheMuso
[03:56] <TheMuso> Night folks.
[03:56] <bluekuja> lionel, we will wait till it get fixed in debian
[03:56] <bluekuja> for the merge
[04:05] <coNP> Someone up to review my brand new package (http://revu.tauware.de/details.py?upid=5566)?
[04:22] <xxxxx1> anyone here is running at amd64?
[04:23] <persia> xxxxx1: What do you need tested?
[04:24] <xxxxx1> i've got a "bug" of ecryptfs on ia64 and create a fix branch
[04:24] <xxxxx1> can you test?
[04:24] <xxxxx1> it's *64* related.
[04:25] <persia> xxxxx1: Do you have a testcase?  Is there a bugnumber?
[04:29] <bmm> zakame: are you online? I've uploaded the new ccbuild package with the changelog line added: http://revu.tauware.de/details.py?upid=5560
[04:30] <bmm> thanks!
[04:30] <zakame> np :)
[04:31] <coNP> If I uploaded some packages should I ask someone to review it (explicitly) or just wait?
[04:32] <Hobbsee> coNP: ask explicitely
[04:32] <Hobbsee> -e
[04:32] <zakame> bmm: hmm ccClass and ccFunction are still patched outside of dpatch
[04:33] <bmm> zakame: oh?? Oooh..  Maybe you? http://revu.tauware.de/details.py?upid=556{6,9}
[04:33] <bmm> zakame: Thanks, I'll fix it now, if you find any other problems, please let me know.
[04:34] <zakame> bmm: do check the build as well
[04:35] <bmm> zakame: is that going wrong? I havn't had any problems yet with that... any hints on the problem?
[04:36] <persia> coNP: Best practice is to announce the URL here, with the name of the package, any special considerations (python, java, library, etc.) and whether it is initial review, updated review, or seeking a second advocate.  If there is no response, try again the next day (there is usually a response).
[04:38] <coNP> Okay. It is an Openbox update package, initial review. Two packges: one for Openbox (http://revu.tauware.de/details.py?upid=5566) and one for its configurator, Obconf (http://revu.tauware.de/details.py?upid=5569).
[04:38] <persia> zakame: What's wrong with the build?  It works for me.
[04:38] <bmm> persia: might be a 64bit thing??
[04:39] <zakame> persia: not that there's anything wrong, just that always do a rebuild at every change. :)
[04:40] <persia> zakame: Ah.  My confusion.  I concur.
[04:40] <bmm> zakame: few... thought I had a problem with some weird architecture or someting.... :-D
[04:40] <zakame> hehe... I've recently updated some of my debian packages, and while rebuilding's slow, its worth the time
[04:44] <bmm> How does one check for bashisms?? I'm just guessing at the moment (I know about some things like "{}" etc), but there must be a script or something
[04:44] <Hobbsee> dash -n script, iirc
[04:45] <bmm> thanks
[04:46] <leonel> hello motus
[04:46] <leonel> did this  was canceled ??  bug  115269
[04:46] <ubotu> Launchpad bug 115269 in dapper-backports "[backport]  python-psycopg2 From Feisty to Dapper" [Undecided,Unconfirmed]  https://launchpad.net/bugs/115269
[04:46] <Hobbsee> leonel: ask jdong, we dont control backprots
[04:48] <leonel> Hobbsee: ok
[05:00] <bmm> zakame: I've created a new dpatch and used checkbashisms to find any problems and updated the changelog. Currently I'm running a full rebuild . Did you find anything else?
[05:02] <bluekuja> Hobbsee, do you have a min for a main debdiff (patch)?
[05:17] <bmm> zakame: I've made a new upload with a complete rewrite of the dpatch using checkbashisms to check for problems, updated the changelog and of course a full rebuild to check it all  ;-)
[05:17] <bmm> Any MOTU: ccbuild is looking for it's first advocate of the newest revision http://revu.tauware.de/details.py?upid=5560
[05:22] <bluekuja> persia: :D
[05:23] <bluekuja> persia: nice hint :D
[05:24] <zakame> bmm: what is in test.xx?
[05:24] <bmm> oh ff
[05:24] <bmm> that's my bad. A test program for the checkbashisms, wasn't sure it worked :-S
[05:24] <bmm> bummer.. I'll remove that and repack it :-(
[05:27] <bmm> zakame: I'm ready to do a new upload, do you want that or are you expecting more problems soon?
[05:27] <zakame> cool, go on :)
[05:33] <bmm> zakame: it has arrived http://revu.tauware.de/details.py?upid=5572
[05:36] <zakame> bmm: advocated :)
[05:37] <bmm> Yeah!
[05:37] <zakame> bmm: the package synopsis could still be improved per http://www.debian.org/doc/developers-reference/ch-best-pkging-practices.en.html#s-bpp-pkg-synopsis , but it's not urgent :)
[05:38] <bmm> zakame: I'll take a look at that then, thanks!
[05:43] <zakame> np :D
[06:00] <zakame> gn8 folks :D
[07:09] <porthose> good mourning all
[07:10] <ScottK> good morning (I hope you meant good morning and not good mourning)...
[07:11] <porthose> Could I please get a MOTU to review ampache-<IP_ADDRESS>.  http://revu.tauware.de/details.py?upid=5519
[07:13] <pochu> porthose: The orig.tar.gz shouldn't have the Ubuntu version (the -XubuntuY)
[07:13] <pochu> slomo!
[07:14] <slomo> hi pochu :)
[07:14] <pochu> :)
[07:14] <pochu> slomo: I've packaged liferea 1.2.17, which fixes some memory leaks, and other things. It's at http://emilio.pozuelo.org/~deb, if you can take a look at it...
[07:14] <porthose> k thanks
[07:15] <pochu> slomo: I've tested it, and works fine so far. I haven't changed anything in debian/ but the changelog :-)
[07:15] <slomo> pochu: merged with debian? :)
[07:15] <slomo> pochu: they got 1.2.16something
[07:15] <pochu> slomo: They have just dropped dbus-1-utils, which we've already done
[07:15] <slomo> pochu: and you merged the changelog entry :)
[07:15] <pochu> slomo: so I didn't think it did worth...
[07:16] <pochu> slomo: I didn't, but I can :)
[07:16] <pochu> Gimme a second!
[07:16] <slomo> please do so to keep the delta smaller and save you some work next time ;)
[07:16] <pochu> Right :)
[07:21] <pochu> slomo: uploaded :-)
[07:21] <slomo> pochu: perfect
[07:22] <pochu> Hmm, I haven't mentioned a "Merge with Debian". Is it neccesary?
[07:23] <slomo> yes
[07:27] <slomo> pochu: new version there?
[07:28] <pochu> slomo: Yeah :) http://emilio.pozuelo.org/~deb/
[07:28] <pochu> Just uploaded with the Merge message and that :)
[07:29] <slomo> pochu: ok, looking and it and then uploading .)
[07:31] <pochu> Thanks :)
[07:35] <slomo_> pochu: uploaded
[07:37] <pochu> slomo_: rock on :)
[07:51] <polopolo> hello all, does someoen know how I can import my GPG key from keyserver.ubuntu.com?
[07:52] <Nafallo> gpg --keyserver keyserver.ubuntu.com --recv-key <your key>
[07:52] <polopolo> thank you :D
[07:54] <polopolo> th server is off :(
[07:55] <Nafallo> that would surprise me
[07:56] <polopolo> http://keyserver.ubuntu.com/
[07:56] <polopolo> :(
[07:56] <Nafallo> you forgot the portnumber
[07:56] <polopolo> Can I ask what you mean with <your key>?
[07:56] <Nafallo> anyway, esperanza is up.
[07:56] <polopolo> wich is it then>
[07:56] <polopolo> ?
[07:57] <Nafallo> your fingerprint
[07:57] <Nafallo> in my case 509CBA71
[07:57] <polopolo> ah
[07:57] <polopolo> what is the portnumber then?
[07:58] <polopolo> I know the portnumber know
[07:58] <Nafallo> why not just use the commandline?
[07:58] <polopolo> I lost my key in the reinstall
[07:58] <Nafallo> then you've probably lost the private key too then?
[07:59] <polopolo> I lost the key yes, but uploaded the key to the server
[07:59] <Nafallo> the public key yes...
[07:59] <Nafallo> you should have had backup of your private key...
[07:59] <man-di> polopolo: then you are totally lost
[07:59] <polopolo> ouch fine :(
[07:59] <man-di> polopolo: private key is only on your system normally
[08:00] <polopolo> how can I make it then?
[08:00] <man-di> polopolo: create a new key?
[08:00] <Nafallo> no! it's on the system and in all the secure backupplaces :-)
[08:00] <polopolo> no, backup
[08:00] <man-di> polopolo: and backup the key
[08:01] <man-di> polopolo: then you even cant revoke it when you have no revocation key
[08:02] <polopolo> BRB
[08:02] <polopolo> back in few min
[08:25] <polopolo> for the people who helped my with PGP, I have downloaded my key, and it works :P
[08:47] <tsmithe> geser, thanks :)
[08:55] <LaserJock> hello MOTU land
[08:55] <pochu> Hi LaserJock
[08:55] <LaserJock> hola pochu
[08:58] <ScottK> Hello LaserJock
[08:59] <LaserJock> hiya ScottK
[09:00] <jburd> Are the GNU Autotools manuals available for devhelp?
[09:00] <tsmithe> hi LaserJock
[09:01] <LaserJock> jburd: I don't remember them being in devhelp, but I could be wrong
[09:01] <LaserJock> heah tsmithe, get your packages into Debian yet?
[09:01] <jburd> I remember browsing them in devhelp long ago, but that was probably Gentoo, I think.
[09:02] <LaserJock> hmm
[09:02] <tsmithe> LaserJock unfortunately no; wired's upstream have been a bit slow in getting back to me. so i'm just gonna go ahead and hack about with it
[09:02] <tsmithe> LaserJock, wanna do some reviewing for me later? :p
[09:03] <LaserJock> hmm, I'm not sure I can
[09:03] <tsmithe> heh ok :)
[09:03] <LaserJock> I'm at my  grandfather's house and I don't know if I'll have access to my build machine at home
[09:03] <man-di> tsmithe: just mail me when you are ready with the package
[09:03] <LaserJock> I suppose I could try imbrandon's build farm
[09:03] <tsmithe> man-di, will do for wired; i meant about ubuntustudio's art packages :p
[09:04] <tsmithe> LaserJock, nah don't worry - unless you desperately want to
[09:04] <man-di> tsmithe: aah, I thought its only about wired
[09:04] <tsmithe> nope :)
[09:05] <jburd> There seem to be references to devhelp-book-autotools in warty.
[09:06] <LaserJock> perhaps Debian got rid of them for some reason
[09:07] <jburd> Hmmm.  It's really easier to search devhelp within gedit + documentation plugin you know.
[09:07] <jburd> Just place the cursor on whatever you want lookup and press F7.
[09:08] <jburd> I'd really like http://htmlhelp.berlios.de/wiki/Devhelp_Books  these available.
[09:08] <man-di> LaserJock, jburd: this was AFAIR becuase of GFDL
[09:08] <jburd> Oh
[09:08] <man-di> ...if I remember correctly...
[09:08] <jburd> Bah.  licensing.
[09:10] <LaserJock> man-di: that's what I was thinking
[09:10] <LaserJock> Debian lost a lot of documentation to GFDL "stuff"
[09:10] <man-di> LaserJock: most of it just got moved to non-free
[09:11] <LaserJock> yeah
[09:11] <LaserJock> it caused some issues with TeX
[09:11] <man-di> LaserJock: debian still allows GFDL for main, just not with invariant sections
[09:11] <man-di> LaserJock: and glibc and gcc and a lot more stuff
[09:11] <LaserJock> yeah, but it's pretty common to have an invariant section for the license of the doc
[09:12] <LaserJock> so it seems like there's a lot of stuff that got dumped into non-free
[09:12] <man-di> yes
[09:12] <man-di> how does ubuntu handle this today?
[09:12] <LaserJock> we accept GFDL as far as I know
[09:12] <man-di> LaserJock: always?
[09:12] <LaserJock> as far as I know, yes
[09:13] <LaserJock> we've got some of the non-free doc packages in I believe
[09:13] <man-di> interesting
[09:13] <LaserJock> we also have Creative Commons licenses too
[09:13] <LaserJock> for some things
[09:14] <LaserJock> which Debian doesn't accept
[09:14] <LaserJock> but I think it's a bit more of a case-by-case basis
[09:14] <jburd> I'd really *love* it if free software and open-source licenses cooperated with each other instead of figthing like street cocks.  In the end, nobody wins and everybody loses.
[09:14] <LaserJock> I've never seen a policy doc on it
[09:15] <LaserJock> jburd: well, people have to define free and open-source
[09:15] <LaserJock> and some people are bound to define it a bit differently
[09:16] <LaserJock> Debian tends to take the "strictest" approach to free
[09:17] <jburd> Honestly, I don't really care about definitions.  I hate the fact that I cannot use extremely well-written code in my application simply because of license incompatibilities or the other way around.
[09:18] <LaserJock> well, it certainly better than not being able to do anything, IMO
[09:18] <jburd> GPL does not allow me to use a lot of software written by Apache (which produces really well-engineered stuff).
[09:18] <jburd> Re-inventing the wheel is expensive and a waste of time.
[09:18] <xxxxx1> hello LaserJock
[09:18] <LaserJock> but it's still the software authors right to define how they want their software used
[09:19] <LaserJock> but yes, licensing can be a real pain in the butt
[09:19] <LaserJock> and documentation licensing even more so
[09:19] <jburd> Having to think a thousand times before I can touch someone's "free software" and care about their definitions is a pain.
[09:19] <jburd> Agreed.
[09:20] <jburd> I'd just like to write some software while reusing some really good code and that's that.
[09:20] <LaserJock> sure, once GPL takes over the world it won't be a problem ;-)
[09:20] <jburd> Heh.
[09:20] <LaserJock> hence why it is sometimes called a viral license
[09:21] <luisbg> hey LaserJock =)
[09:21] <LaserJock> luisbg!
[09:23] <LaserJock> personally if I were to write a program I'd probably MIT it or make it non-free, I think
[09:25] <jburd> If everything were up to me, I'd leave everything in public domain.  Do whatever you want to with it.  No warranties.
[09:26] <Burgundavia> jburd: the problem with that is that people will do evil things with it
[09:26] <jburd> Don't they otherwise? :-)
[09:26] <Burgundavia> because what really matters is the community and people, not the code
[09:26] <ScottK> For me it depends on my purpose.  If I'm trying to evangelize a technology via a new program I'd go MIT.  If I'm trying to push Free Software, I'd go GPL.  If I didn't want to distribute source, I'd do it as a service and not distribute at all.
[09:26] <Burgundavia> and while the gpl does not create a community, it creates an incentive to do so
[09:27] <LaserJock> jburd: well, public domain doesn't really work so well. There are several countries where you can't make things public domain
[09:27] <LaserJock> well, the GPL sucks for libraries
[09:27] <Toadstool> jburd: use this http://sam.zoy.org/wtfpl/ instead :)
[09:27] <Toadstool> hi guys
[09:27] <LaserJock> hence the LGPL
[09:28] <LaserJock> I've come across several problems where a community was split because a library was GPL
[09:28] <mwolson> jburd: GPLv3 will be compatible with the Apache license
[09:28] <Toadstool> uh gotta go, tennis time, that was quick
[09:28] <jburd> Heh @ Toadstool
[09:31] <jburd> The GPL reminds me of this "We'll speak your native language as long as it is English."
[09:39] <jburd> Excellent stuff:  http://htmlhelp.dotsrc.org/
[09:40] <jburd> :-)
[09:44] <polopolo> is it a problem if a 32 bit computer package a  64 bit program?
[09:44] <pochu> I don't think it's possible
[09:45] <polopolo> ah o
[09:45] <polopolo> k
[09:45] <pochu> Though it is the other way, afaik :)
[09:56] <DarkSun88> Hi all
[09:56] <DarkSun88> :)
[09:56] <polopolo> hello
[09:57] <pochu> beuno: rock on with the stats :-)
[09:57] <beuno> pochu, thanks  :D   was my pet project, I'm glad I got *something* out there
[10:01] <pochu> It's cool!
[10:01] <pochu> beuno: btw, do you have ubuntu-es.org forums support?
[10:01] <beuno> pochu: nope, we haven't added it, would be great to have local forums added
[10:01] <pochu> Yeah :)
[10:01] <beuno> if would be great if you could file a bug so we can track requests
[10:01] <beuno> :D
[10:01] <pochu> Sure, doing :)
[10:01] <beuno> thanks, it's going to hard to keep track of all requests  :p
[10:01] <pochu> heh
[10:01] <beuno> debconf is really taking up most of my time though
[10:02] <beuno> happily so   :D
[10:04] <pochu> beuno: also, what's 'LoCos (other languages)' purpose?
[10:05] <beuno> pochu: should be other planets
[10:07] <pochu> Doesn't seem to be atm
[10:07] <beuno> no, it doesn't  :p
[10:10] <pochu> beuno: bug 120743
[10:10] <ubotu> Launchpad bug 120743 in ubuntu-stats "Please add support for the ubuntu-es forums" [Undecided,Unconfirmed]  https://launchpad.net/bugs/120743
[10:12] <beuno> pochu: thanks
[10:14] <polopolo> Must you install the program before you package the program?
[10:15] <beuno> polopolo: it would be nice to, yes
[10:16] <polopolo> mmm
[10:18] <polopolo> ok, and I want to package swiftfox, I have a pentium 4, should I package the pentium 4 version, and upload it on the I386 section?
[10:18] <Burgundavia> polopolo: swiftfox has a completely non-free license
[10:19] <polopolo> so not approved for ubuntu?
[10:20] <beuno> polopolo: yes, it just goes into multiverse afaik
[10:20] <polopolo> afaik?
[10:20] <beuno> as far as I know  :D
[10:21] <polopolo> So no problem if I upload?
[10:21] <Burgundavia> umm, I don't think you can even distribute it
[10:21] <beuno> Burgundavia: but multiverse is all non.free software
[10:21] <polopolo> why?
[10:21] <Burgundavia> beuno: multiverse is only for stuff we can legally distribute
[10:22] <LaserJock> beuno: Multiverse is non-free that we can legally distribute
[10:22] <polopolo> lol
[10:22] <LaserJock> heh, Corey beat me to it
[10:22] <beuno> heh
[10:22] <polopolo> hmm ok
[10:22] <polopolo> Then I stop
[10:22] <beuno> you two really spend too much time together...  :p
[10:23] <Burgundavia> polopolo: lets check first
[10:23] <Burgundavia> http://www.answers.com/topic/swiftfox
[10:25] <polopolo> ah I see
[10:25] <polopolo> MPL 1.1
[10:26] <polopolo> Therefor the Swiftfox Debian package would not pass requirement #1 of Debian Free Software Guidelines
[10:26] <polopolo> I see
[10:27] <polopolo> I see not the problem :P
[10:29] <ScottK> It's not the MPL, it's the Trademark on the name.  You can probably call it something like Swift-weasel and package it.
[10:31] <polopolo> so, change the package name and not the proogram ??
[10:31] <polopolo> I think I package another program
[10:36] <polopolo> !bug 120699
[10:36] <polopolo> #bug 120699
[10:36] <ubotu> Launchpad bug 120699 in firefox "[needs packaging]  swiftfox" [Undecided,Unconfirmed]  https://launchpad.net/bugs/120699
[10:36] <polopolo> not working :(
[10:36] <polopolo> https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/120699
[10:37] <polopolo> what must I do then with this bug?
[10:41] <pochu> probably reject it.
[10:52] <tsmithe> hmm revu doesn't want to diff between archived and new uploads, it seems
[10:52] <tsmithe> siretart, ping re ^^
[10:52] <tsmithe> i guess that's the cause
[10:52] <tsmithe> check http://revu.tauware.de/diff.py?upid1=4896&upid2=5582
[10:54] <xxxxx1> bye all
[11:03] <tsmithe> what does "E: ubuntustudio-sounds: copyright-should-refer-to-common-license-file-for-gpl" mean?
[11:04] <tsmithe> lhttp://revu.tauware.de/revu1-incoming/ubuntustudio-sounds-0704240025/ubuntustudio-sounds-0.4/debian/copyright is the file
[11:05] <ogra_> tsmithe, lintian -i :)
[11:06] <ScottK> tsmithe: It means that a copy of the GPL is installed in all Debian systems and you should refer to that instead of putting the whole text in debian/copyright.
[11:06] <tsmithe> ahh of course
[11:06] <tsmithe> thanks
[11:06] <crimsun> you're missing a reference to /usr/share/common-licenses/Artistic
[11:07] <crimsun> and /usr/share/common-licenses/GPL
[11:10] <tsmithe> thanks
[11:39] <Kmos> crimsun: http://revu.tauware.de/details.py?upid=5586
[11:40] <crimsun> Kmos: the Debian maintainer has been active recently; have you conversed with him regarding a newer version in Debian unstable?
[11:41] <Kmos> crimsun: I don't see debian package
[11:41] <Kmos> or talked to him
[11:42] <Kmos> ubuntu can't have their own ? :) i've changed everything necessary
[11:42] <crimsun> I recommend sending him an email inquiring whether he plans to update soon
[11:42] <Kmos> the maintainer can also backport it to debian
[11:43] <crimsun> the problem is not that Ubuntu can{,'t} have its own version.  It's that we don't want orig.tar.gz skew.
[11:43] <Kmos> crimsun: why we need to wait for debian ?
[11:43] <Kmos> .orig.tar.gz is from website of phpmyadmin
[11:43] <crimsun> see above
[11:45] <Kmos> crimsun: i mailed him
[11:45] <crimsun> great
[11:45] <Kmos> so phpmyadmin can only be a debdiff from debian unstable ?
[11:46] <crimsun> no
[11:46] <Kmos> the diff applied correctly to this new version and tested with pbuilder
[11:47] <crimsun> unless you have a good reason to, I recommend you wait for new upstream versions to enter Debian first
[11:47] <crimsun> a good reason _not_ to,
[11:47] <Kmos> for example, i've updated ddclient to 3.7.1 and debian has an old version
[11:48] <crimsun> Kmos: yes, and how active has the Debian maintainer been for ddclient?
[11:48] <Kmos> 3.7.0
[11:48] <Kmos> I think he isn't..
[11:48] <crimsun> right.  Now compare that to the activity of phpmyadmin's maintainer.
[11:51] <Kmos> crimsun: it's different :)
[11:51] <Kmos> i understand now
[11:53] <Lamego> btw, phpmyadmin on feisty is broken
[11:54] <crimsun> we know.  See bug report referenced in -devel.
[11:54] <crimsun> Feel free to propose an SRU.
[11:57] <Lamego> it is far more easy to use a backported version, and I like to spend my time on a more efficient fashion
[11:57] <Lamego> I guess someone noted the problem before the release
[11:58] <Kmos> crimsun: http://revu.tauware.de/details.py?upid=5587
[11:59] <Kmos> crimsun: i needed to remove a patch from it
[11:59] <Lamego> is there any exception case for doing an SRU with a full version update ?
[12:00] <crimsun> SRUs should not be full version updates.
[12:01] <Lamego> My question is, can they be ? I understand they should not be
[12:01] <Burgundavia> Lamego: what app are you talking about?
[12:01] <Lamego> Burgundavia, phpmyadmin
[12:01] <Burgundavia> ahh
[12:01] <Burgundavia> sru are supposed to fix specific bugs
[12:02] <crimsun> Lamego: no.
[12:02] <Lamego> SRU are restricted to sec/critical fixes, to avoid regressions, which is kind of pointless because the released package is itself a regression
[12:02] <Kmos> crimsun: are you checking my ddclient update ?
[12:02] <crimsun> Kmos: no, I'm doing upstream alsa work ATM.
[12:02] <Kmos> :(
[12:02] <crimsun> I don't multitask well.  If you wait a few minutes, I'll get around to it.
[12:02] <Kmos> pochu: can you check http://revu.tauware.de/details.py?upid=5587
[12:03] <Kmos> crimsun: ok
[12:03] <Burgundavia> Lamego: if there is a specific bug, with a specific fix, that is a good candidate for an sru
[12:05] <Lamego> ok, too much work to fix a single bug, when there are are potentially a lot of other bugs to be fixed
[12:05] <crimsun> if everyone thought that way about every bug, then F/LOSS would suck.
[12:07] <Lamego> crimsun, naming a blind update policy as F/LOSS is a bit of an abuse :)
[12:09] <Burgundavia> Lamego: it is not a blind policy update
[12:09] <Burgundavia> it has a clear purpose: to keep stable as stable
[12:09] <Burgundavia> and not "today's crap that might be stable"


[09:10]  * czajkowski shall be in Dublin tomorrow
[09:11]  * moylan1 checks the weather forecast :-D
[09:12] <czajkowski> lol
[09:12] <czajkowski> don't joke
[09:12] <czajkowski> flying with Ryanair!
[09:13] <moylan1> snow joke, the weather looks good.  :-)  there had been speculation for snow on friday but that seems to have evaporated.  http://www.yr.no/place/Ireland/Leinster/Dublin~2964574/hour_by_hour.html
[09:13] <slashtommy> Ryanair are grand, as long as you're checked in before hand and follow their procedures :P
[09:14] <slashtommy> when do you fly?
[09:14] <moylan1> and as long as somebody remembers the duct tape... http://www.dailymail.co.uk/news/article-2052751/Ryanair-plane-taped-window-Sticky-tape-came-loose-mid-air-flight-turned-back.html
[09:15] <slashtommy> erm, you cannot usually get duct tape onto the plane
[09:15] <slashtommy> i was at BHX security when they were confiscating tape
[09:15] <slashtommy> not that i doubt the daily mail ;)
[09:16] <czajkowski> 9:30 tonight
[09:16] <czajkowski> must check in
[09:16] <czajkowski> good reminder
[09:16] <czajkowski> I get in at 11:15pm
[09:18] <slashtommy> aye, check-in for both tonight's flight and the return
[09:18] <moylan1> well safe (and speedy!) trip whatever the weather
[09:19] <czajkowski> nods
[09:19] <czajkowski> thanks
[09:19] <slashtommy> yep, be good to see you if we get the chance
[09:19] <czajkowski> aye
[09:20] <czajkowski> how about saturday for breakie ?
[09:20] <slashtommy> morning!?
[09:20] <czajkowski> good point
[09:20]  * slashtommy would have to check with the ebel
[09:20] <czajkowski> I'll poke in here tomorrow
[09:20] <czajkowski> I have an -ie number
[09:21] <czajkowski> but dont know it
[09:21] <czajkowski> hmm how the hell do I check in
[09:21] <czajkowski> grr
[09:21] <slashtommy> on their website
[09:21]  * czajkowski misses aer lingus
[09:21] <slashtommy> you can do it up to two weeks beforehand ;)
[09:22] <czajkowski> ah
[09:22] <slashtommy> but a €40 fine for each person and each flight, where you fail to checkin before the 4 hour deadline
[09:22] <czajkowski> wow
[09:23] <slashtommy> http://www.ryanair.com/en/terms-and-conditions#regulations-tableoffees
[09:24] <slashtommy> also remember that they are very anal about baggage size
[09:24] <slashtommy> if your bag won't fit in the guage, it will not fly - simple
[09:25] <czajkowski> just bringing my ubuntu laptop
[09:25] <slashtommy> hopefully a change of clothes too
[09:27] <czajkowski> aye not bringing laptop
[09:27] <czajkowski> just cloths in it
[09:27] <czajkowski> perfume make up and stuff then sister has
[09:29] <slashtommy> ryanair are grand though, have a nice flight
[09:34] <czajkowski> checked in
[09:34] <czajkowski> however am now fighting with the wireless printer
[09:34] <czajkowski> who will print the network test page
[09:34] <czajkowski> so it can see the wifi
[09:34] <czajkowski> yet not talk to the laptop
[09:37] <slashtommy> you can ping it?
[09:37] <czajkowski> yup
[09:37] <czajkowski> it's just being difficult
[09:38] <slashtommy> are you printing from the browser or directly from evince?
[09:39] <czajkowski> broswer
[09:39] <czajkowski> should I save to pdf
[09:39] <slashtommy> aye, you may have better luck with that
[09:39] <czajkowski> ok
[09:39] <czajkowski> thanks
[09:39] <slashtommy> ryanair will let you download it as a PDF
[09:40] <czajkowski> yup
[13:20] <czajkowski> ok won't  be in Ireland now
[13:20] <czajkowski> all resolved.
[13:31] <ebel> alright
[13:41] <slashtommy> we will miss you
[13:41] <czajkowski> another time I promise
[13:42] <slashtommy> grand, are you coming back for xmas at all?
[13:49] <czajkowski> yup 21-27
[13:50] <slashtommy> we're also flying to .uk on the 27th
[13:50] <czajkowski> which airport?
[13:50] <slashtommy> DUB->BHX
[13:50] <slashtommy> a short stay of just over 48 hours, which is long enough for a visit to the england
[13:50] <czajkowski> SNN-LONHEATrow
[13:51] <slashtommy> LHR
[13:52] <czajkowski> there we go :)
[20:12] <czajkowski> http://gadgetwise.blogs.nytimes.com/2011/11/29/qa-installing-software-on-linux/
[20:15] <gastro2> aer lingus not a beter option?
[20:15] <gastro2> better*


[03:47] <Mekaneck> maybe it's better to look and ask in the #mate channel, if there is one, since this has nothing to do with ubuntu mate support
[15:26] <superkuh> Unfortunately #mate has been dead for years. But, given there are 2-3 MATE devs it seems very unlikely any gtk3->4 switch is incoming.
[15:29] <Mekaneck> they have to switch to GTK4 at some point, it will happen eventually
[16:09] <finalspacevoid> but that the gtk4 switch is taking its time is not an issue right? i mean we run gtk2 apps still, and they work just fine. so when mate itself is gtk4 isnt so important since the libraries to run gtk2/3/4 apps are all there?
[16:13] <Mekaneck> gtk2 is dead so i don't think there are any gtk2 apps left
[16:17] <finalspacevoid> ahh k, well but ubuntu right now uses gnome 3 but supports gtk4 i think. so just reread my question with that ;-)
[16:17] <vkareh> gtk2 is not dead - plenty of apps use gtk2
[16:18] <vkareh> the beautiful thing about GTK is that you can have any/all versions installed concurrently and they all work
[16:18] <finalspacevoid> ok great, thx!
[16:18] <Mekaneck>     GTK 4 is now stable, and we consider it ready for consumption. That does not mean GTK 3 is dead – we will continue to support and update it for the foreseeable future (the latest release, 3.24.24, quietly went out a few days ago). It does mean, however, that GTK 2 has reached the end of its life. We will do one final 2.x release in the coming days, and we encourage everybody to port their GTK 2 applications to GTK 3 or 4.
[16:19] <Mekaneck> https://blog.gtk.org/2020/12/16/gtk-4-0/
[16:19] <Mekaneck> so... gtk2 is EOL... dead
[16:20] <vkareh> EOL != dead
[16:20] <finalspacevoid> btw have you tried a different window manager/compositor other than marco? do they run well? im missing a expose/overview window picker, marco doesnt support something like this
[16:21] <vkareh> finalspacevoid: try compiz
[16:21] <finalspacevoid> is it still supported/stable/maintained?
[16:21] <vkareh> (you could attempt running muffin, but it will kill your panel if you do so)
[16:21] <finalspacevoid> i think i read ubuntu mate dropped it from default
[16:21] <finalspacevoid> haha ive seen someone run gala (from elementary os) but its not in the repos
[16:22] <Mekaneck> compiz can still be used but it hasn't been developed anymore
[16:22] <finalspacevoid> hmmm k


[23:25] <kirkland> howdy all, I was directed here to show you guys: http://people.ubuntu.com/~kirkland/
[23:26] <kirkland> it's an Ubuntu Documentation Search engine powered by a highly customized Google Search
[23:27] <kirkland> and with search refinements hierarchically organized in a logical manner


[08:15] <len> What do I have to enter for the custom command entry in the nomachine client to get a mythbuntu session?
[08:19] <len> /usr/bin/startxfce4 doesn't work
[08:20] <len> Preconfigured KDE choice works fine to start KDE session