[00:02] <clivejo> yofel: would you be free to help me do one of those application libs together sometime?
[00:04] <clivejo> grrr
[00:06] <yofel> we'll see. I'll be working overtime the next 2 days at least, so try to ping me and hope I'm not completely k.o.
[00:10] <clivejo> why is it "Merging kubuntu_unstable into kubuntu_unstable_utopic."
[00:11] <clivejo> and "Merging kubuntu_unstable into kubuntu_unstable_pam-auth-update"
[00:24] <valorie> the only tiny hitch in installing kubuntu-desktop is that the recommends could not be installed:
[00:24] <valorie> amarok-doc libqt4-sql-psql moodbar k3b-extrathemes k3b-i18n normalize-audio sox movixmaker-2 kde-config-cddb lame krfb plasma-widget-ktorrent krosspython konqueror
[00:24] <valorie>   libreoffice-kab jovie texlive-binaries unrar python3-pyqt4-dbg skanlite-dbg
[00:24] <valorie> I suppose if I remove the problem ones the rest will install
[00:26] <valorie> yup
[00:26] <clivejo> night all
[00:26] <valorie> movixmaker-2
[00:27] <valorie> sweet dreams clivejo
[00:27] <valorie> and libreoffice-kab
[00:28] <valorie> once I remove those from the list, the remainder of the recommends install with no problems
[09:29] <lordievader> Good morning.
[11:13] <clivejo> sitter: why is pam-auth-update merging "kubuntu_unstable into kubuntu_unstable_pam-auth-update"?
[11:15] <clivejo> http://kci.pangea.pub/job/merger_kwallet-pam/256/console
[11:15] <clivejo> sorry kwallet-pam
[11:25] <sitter> clivejo: because kubuntu_unstable is merged into all kubuntu_unstable_* branches
[11:29] <clivejo> sitter: how to resolve? ask debian to delete the branch or fix the failing merger?
[11:30] <sitter> that's what I suggested last time
[11:30] <clivejo> which one?
[11:34] <clivejo> valorie: I tried to get an account on kubuntu wiki but it wont work, something about <class 'openid.message.InvalidOpenIDNamespace'> and a page load of error messages
[11:41] <mparillo> wiki.kubuntu.org?
[11:51] <clivejo> mparillo: yup
[11:52] <mparillo> I have had the same thing, and I have better luck with wiki.ubuntu.com using google-chrome. Even when you think it dies on you, sometimes you open a new tab, and you find yourself signed in.
[12:20] <BluesKaj> Hi folks
[15:16] <ovidiu-florin> there, I've finally added a picture of myself: https://kubuntu.org/the-kubuntu-team/
[15:26] <ovidiu-florin> I've added @Sick_Rimmit and @Andredelsa as part of the team
[15:26] <ovidiu-florin> on the site team page
[16:34] <soee> i'm glad i have Dell laptop http://www.phoronix.com/scan.php?page=news_item&px=Dell-Firmware-Updates-Linux :)
[17:06] <clivejo> sgclark: ping
[17:11] <sgclark> clivejo: pong
[18:13] <soee> mamarley: NVIDIA 361.28 Linux Driver Released, Makes GLVND Optional :)
[18:13] <mamarley> soee: I believe tseliot is currently working on that one.  I'm not sure whether he is going the GLVND or non-GLVND route though.
[18:14] <soee> mamarley: ok, thanks ;)
[18:14] <soee> mamarley: what is advantage of GLVND ?
[18:15] <mamarley> At the moment, nothing.  In the future, it will be helpful in getting proper Optimus support working.
[18:16] <soee> ok
[19:34] <johnny_> hi
[19:35] <clivejo> hi johnny_
[20:02] <blaze> what's wrong with marble?
[20:04] <clivejo> its confusing !
[20:04] <blaze> i need more information
[20:14] <clivejo> sitter: can you fix KCI to grab libkolab from here https://cgit.kolab.org/libkolab/ ?
[20:15] <clivejo> getting the following error - 00:27:49 hudson.plugins.git.GitException: Failed to fetch from https://git.kolab.org/diffusion/LK/libkolab.git
[20:25] <blaze> lol, i've just seen the logs
[20:36] <ahoneybun> they updated the download page on ubuntu.com
[20:36] <ahoneybun> http://www.ubuntu.com/download/ubuntu-flavours
[20:41] <clivejo> hi DarinMiller
[20:42] <clivejo> blaze: I believe marble is a bit of a mess due to being ported to KF5
[20:42] <clivejo> Im steering clear of it!
[20:43] <clivejo> marble and PIM scare the bejaysus out of me
[20:43] <blaze> clivejo: what do you mean? did you get a package?
[20:44] <blaze> as far as i see there's dependecy problem
[20:44] <clivejo> its on the 15.12.1 to-do list
[20:44] <clivejo> http://qa.kubuntu.co.uk/ppa-status/applications/build_status_15.12.1_xenial.html
[20:46] <DarinMiller> Hi clivejo
[20:47] <clivejo> DarinMiller: I hear you are interested in packaging?
[20:50] <DarinMiller> clivejo: Yes.  It seems to be a little over my head at the moment...
[20:51] <clivejo> any questions?
[20:51] <clivejo> its over my head too!
[20:51] <DarinMiller> clivejo: I feel I am good a trouble shooting, but I am only vaguely familiar with git.   And after watching the channel for a few days, there is a lot more politics involved than I realized.
[20:52] <clivejo> politics?
[20:53] <DarinMiller> I took the git tutorial and intended to download a working package to ensure I could duplicate a success before I tried fixing a broken package.
[20:53] <johnny_> hello people
[20:54] <blaze> DarinMiller: did you ever use launchpad for packaging?
[20:54] <johnny_> i have a problem too
[20:54] <johnny_> ho olaunch a program with monodevelop
[20:55] <johnny_> for see the graphic interface
[20:55] <DarinMiller> But I am not sure even how to download a working package via git.  Also, the package guildeline recommended not doing package management on your main system, so I assume I either need a virutal session or a separate test installation.
[20:55] <clivejo> DarinMiller: our packages are kept on Launchpad
[20:56] <johnny_> other method for open a .exe?
[20:56] <johnny_> without inee
[20:56] <DarinMiller> No, I am very green and have not even used lauchpad for packaging.
[20:57] <clivejo> basically we have packaging on debian git system
[20:57] <clivejo> packaging + source code = package
[20:57] <johnny_> someone for me ?
[20:58] <clivejo> sorry johnny_ this is Kubuntu Development channel
[20:58] <clivejo> we dont use exe files
[20:58] <johnny_> ohh ok
[20:59] <johnny_> why
[20:59] <clivejo> because we run Linux :)
[20:59] <johnny_> lol
[21:00] <blaze> clivejo: mono apps on linux are also .exe, but this is wrong channel for that anyways
[21:00] <clivejo> DarinMiller: this is where we keep our packaging - http://anonscm.debian.org/cgit/pkg-kde/
[21:01]  * clivejo covers hears and la la la's
[21:02]  * clivejo associates mono with mononucleosis
[21:03] <clivejo> and exe with Windozes
[21:03] <DarinMiller> lol :)
[21:03] <clivejo> neither make me feel warma and fuzzy :P
[21:04] <clivejo> !info mono xenial
[21:04] <DarinMiller> 771 packages that must be recompiled for every alpha, beta, RC and 6 month release ??!!! Wow!
[21:05] <clivejo> DarinMiller: have you any questions?
[21:05] <clivejo> have you tried anything out?
[21:05] <clivejo> are you on wily or xenial?
[21:05] <DarinMiller> Both.
[21:06] <clivejo> both on hardware?
[21:06] <DarinMiller> Yes.
[21:06] <clivejo> nice
[21:06] <DarinMiller> I have too much HW.
[21:06] <clivejo> are you testing?
[21:06] <DarinMiller> landing?
[21:06] <clivejo> thats a nice sitution to be in!
[21:07] <clivejo> yup have you landing PPA's enabled?
[21:08] <clivejo> do you know what staging is?
[21:08] <DarinMiller> I was on wiley - not at the moment on any system, but that I be easily recitified.
[21:08] <DarinMiller> pre-landing?
[21:09] <clivejo> yup
[21:09] <clivejo> its the devs first step
[21:09] <clivejo> so when KDE release the source code, the devs start to package it and it goes into the staging PPA
[21:10] <clivejo> the releases are divided into frameworks, plasma and apps
[21:10] <DarinMiller> Ok. I assume that a git branch? Or....
[21:10] <clivejo> the source is actually tarballs
[21:11] <clivejo> for example applications 15.12.1 are here - http://download.kde.org/stable/applications/15.12.1/src/
[21:11] <blaze> and debian repo with packaging information is git
[21:12] <clivejo> I have many names for it :P
[21:12] <DarinMiller> LOL
[21:12] <clivejo> but the machine name is Alioth
[21:13] <clivejo> or debian git
[21:13] <blaze> comes from tv series i guess
[21:14] <clivejo> Then we have the beast we call Kubuntu Continuous Integration KCI
[21:14] <DarinMiller> So how does 188 KDE tarballs spawn into 771 packages on debian?  (Lists from the 2 web links you posted?)
[21:14] <clivejo> tarballs can split into smaller packages
[21:15] <clivejo> the tarballs contain the source
[21:15] <blaze> that's what debian people usually do
[21:15] <blaze> splitting and dividing
[21:15] <clivejo> which Launchpad builds into binary files
[21:16] <clivejo> the packaging then tells Launchpad where to put those files
[21:16] <DarinMiller> you answered my question before I finished typing :)
[21:16] <clivejo> using a control file
[21:17] <blaze> and .install files are necessary most of the time
[21:18] <clivejo> so for example, take kio in frameworks
[21:18] <clivejo> this is the control file - http://anonscm.debian.org/cgit/pkg-kde/frameworks/kio.git/tree/debian/control?h=kubuntu_unstable
[21:18] <clivejo> it splits up into 8 deb files
[21:19] <clivejo> anything -dev is a package used by developers
[21:19] <clivejo> -dbg is debugging symbols
[21:20] <clivejo> but basically that one tarball builds and get put into 8 debian files :)
[21:21] <clivejo> like magic!
[21:21] <DarinMiller> trying to find control file in rabbit hole starting here: http://anonscm.debian.org/cgit/pkg-kde/
[21:21] <DarinMiller> I click on http://anonscm.debian.org/cgit/pkg-kde/frameworks/kio.git/
[21:22] <clivejo> ok on that page you see the branches
[21:22] <clivejo> so kubuntu_wily_archive contains the packaging for wily
[21:23] <clivejo> and kubuntu_xenial_archive is the one we are working on
[21:23] <DarinMiller> OK, but where are the control files hidden?
[21:24] <clivejo> the control file can be different in each one of those branches
[21:24] <clivejo> for example kubuntu_unstable I changed the control file 30 hours ago
[21:25] <clivejo> basically frameworks 5.19.0 are out
[21:25] <clivejo> and in kio, upstream (KDE) have introduced a new library
[21:26] <clivejo> if you click into kubuntu_unstable
[21:26] <clivejo> and click the tree tab
[21:26] <DarinMiller> Nevermind, I see the tree "tab" which give me http://anonscm.debian.org/cgit/pkg-kde/frameworks/kio.git/tree/debian/control?h=kubuntu_unstable link you send above.
[21:27] <clivejo> that shows you the file view
[21:27] <clivejo> in the debian folder is the control file
[21:27] <clivejo> the control file tells Launchpad what packages it splits into
[21:28] <DarinMiller> got it.
[21:28] <clivejo> and then the .install files fine grain that
[21:28] <clivejo> so if you click on libkf5kiogui5.install
[21:28] <clivejo> thats the new package I created
[21:28] <clivejo> and you can see the files that get put in there
[21:30] <DarinMiller>  libkf5kiogui5.install on the "commit" tab?
[21:30] <clivejo> in the file list
[21:31] <clivejo> in the tree tab
[21:31] <clivejo> when we clone that git those become physical files
[21:32] <clivejo> we put them together and send them to launchpad
[21:32] <clivejo> and hope and pray they build :)
[21:32] <DarinMiller> LOL :)
[21:32] <blaze> clivejo: that's the wrong part :)
[21:32] <DarinMiller> Can you not build yourself before committin????
[21:33] <clivejo> DarinMiller: yes we can :)
[21:34] <shadeslayer> someone broke everything
[21:34] <shadeslayer> all of the epochs are screwed
[21:34] <DarinMiller> What would cause a local build to succeed and not the auto build on lauchpad?
[21:34] <clivejo> shadeslayer: ??
[21:34] <shadeslayer> kconfig got it's epoch removed
[21:34] <shadeslayer> broke all of DCI :(
[21:35] <shadeslayer> as did ECM
[21:35] <shadeslayer> our CI CI'd too quickly
[21:35] <shadeslayer> yofel: ^^
[21:35] <shadeslayer> :P
[21:36] <yofel> huh?
[21:36] <clivejo> http://anonscm.debian.org/cgit/pkg-kde/frameworks/kconfig.git/
[21:37] <yofel> shadeslayer: we're still on 5.18 and didn't touch frameworks for weeks
[21:37] <yofel> dci would be debian
[21:37] <yofel> and maxy is aggressively removing epochs
[21:37] <shadeslayer> yofel: https://anonscm.debian.org/cgit/pkg-kde/frameworks/kconfig.git/commit/?h=kubuntu_unstable&id=fe9113c648f6aa995524011b119da798f91e5632
[21:37] <yofel> so live with it
[21:37] <shadeslayer> that :P
[21:37] <yofel> yes well, broken tooling
[21:37] <yofel> sorry
[21:38] <shadeslayer> yeah sorta
[21:39] <yofel> the way we handle epochs is horribly delicate. And "check what you did locally first" is not an intended step in our workflow these days
[21:39] <yofel> ofc. that can majorly screw the CI up, but I'm not sure how to improve the situation
[21:39] <clivejo> DarinMiller: Launchpad is a very clean system, so if it builds locally and not on LP there is probably a package not being installed correctly
[21:41] <clivejo> Launchpad has to be explicitly told what packages to install
[21:42] <DarinMiller> I think I understand.  I could have a package pre--installed on my box that was missed in that dependency requirements so compiles fine locally, but not on a clean install.
[21:42] <clivejo> and those are listed in the Build-Depends: section of the control file
[21:42] <DarinMiller> Ok, makes sense.
[21:42] <yofel> hm
[21:43] <clivejo> Launchpad uses a very very basic, mininal build environment
[21:43] <yofel> shadeslayer: would not auto-merging UNRELEASED stuff from _archive be something worth to try?
[21:44] <shadeslayer> uhm, dunno, see branch workflow wiki page to see what happens
[21:44] <yofel> well, currently that's not a thing
[21:49] <clivejo> DarinMiller: you should get yourself a LaunchPad (LP) account
[21:52] <DarinMiller> Ok.
[21:52] <DarinMiller> signing up now...
[21:54] <DarinMiller> I did not realize the defunct Ubuntu One used launchpad.  I already had the account.
[21:55] <clivejo> LOL yeah
[21:56] <clivejo> thats why I have an AOL address
[21:56] <DarinMiller> ?? LOL
[21:56] <clivejo> I signed up for Ubuntu One years ago
[21:56] <clivejo> and it linked them
[21:56] <clivejo> now Im stuck with it!
[21:58] <clivejo> and valorie is a meanie and wont let me into the Kubuntu club
[21:59]  * clivejo puppy eyes valorie
[22:00] <DarinMiller> This club: https://kubuntu.org/the-kubuntu-team/ ?
[22:00] <clivejo> yup
[22:01] <clivejo> she mustnt be reading this!
[22:03] <clivejo> DarinMiller: do you have a package you know well?
[22:04] <DarinMiller> google-earth :)
[22:05] <clivejo> anything smaller :/
[22:05] <DarinMiller> I had to disect the deb file to enable installation a while back.
[22:06] <clivejo> was it broken?
[22:07] <ovidiu-florin> soee: https://github.com/ovidiub13/KubuntuAdverticaLightChild/issues/5
[22:07] <DarinMiller> yes.  it specified a large "virtual" package that canonical stopped including and the dep list required correcting.
[22:08] <clivejo> DarinMiller: LP is also how users report bugs
[22:08] <soee> ovidiu-florin: vertical pipe makes Kubuntu word and the sentence "separated" a bit (talking about the context)
[22:09] <ovidiu-florin> soee: answer there please
[22:09] <DarinMiller> bugs.kde.org has a launchpad backend or is something different?
[22:09] <clivejo> DarinMiller: and we also have a Trello board
[22:10] <DarinMiller> I have seen the Trello board and find it "cumbersome". :)
[22:10] <clivejo> DarinMiller: not that I know of, LP is more for Ubuntu related stuff
[22:10] <clivejo> like a packaging issue
[22:10] <clivejo> users might request someone to update a package
[22:11] <clivejo> DarinMiller: I find it cumbersome too
[22:11] <DarinMiller> Ok
[22:11] <clivejo> I accidently archived a card, and have no idea how I did it
[22:12] <DarinMiller> How do I update my xenial box to landing? https://launchpad.net/~kubuntu-ppa/+archive/ubuntu/backports-landing only has wiley listed.
[22:13] <ovidiu-florin> clivejo: you can unarchive it
[22:13] <DarinMiller> Trello card?
[22:13] <DarinMiller> ctrl-z ?
[22:15] <clivejo> DarinMiller: backports is to provide updates to previous releases
[22:16] <clivejo> https://launchpad.net/~kubuntu-ppa
[22:16] <clivejo> thats a list of the PPA's we manage
[22:17] <DarinMiller> Wow. So much to learn :)
[22:18] <clivejo> but at least you are interested :)
[22:18] <clivejo> you can see our staging PPA's there too
[22:19] <clivejo> DarinMiller: have you heard of KCI?
[22:20] <DarinMiller> Yes, I see it. I never knew of the ppa list-one of the reasons I was not testing updates landing on xenial.
[22:20] <DarinMiller> Only because you menttioned it earlier: <clivejo> Then we have the beast we call Kubuntu Continuous Integration KCI
[22:21] <clivejo> :)
[22:22] <valorie> sorry, was prepping to clean my house
[22:22] <valorie> clivejo lies, I've been urging him to join "the club" for months!
[22:22] <clivejo> so what it does is takes the very latest source code directly from KDE and tries to build it!
[22:22] <clivejo> stuffing it into our packaging
[22:23] <valorie> also, bugs.kde.org is for KDE bugs, lauchpad bugtracker is for our packaging
[22:23] <clivejo> but often the packaging is wrong, like putting a square in a round hole!
[22:23] <clivejo> http://kci.pangea.pub/
[22:23] <valorie> ah, our packaging is usually great!
[22:24] <valorie> only occasionally missing something
[22:24] <valorie> clivejo: btw did you see the two packages I had remove to get kubuntu-desktop recommends to install?
[22:25] <valorie> movixmaker-2 & libreoffice-kab
[22:25] <clivejo> I did, we need to do something to fix that!
[22:25] <clivejo> maybe yofel can shed some light
[22:25] <valorie> they appear to have changed names or disappeared
[22:26] <clivejo> !info libreoffice-kab wily
[22:26] <valorie> precisely
[22:26] <valorie> anyway, gotta vacuum
[22:27] <clivejo> wonder what is trying to install it
[22:34] <clivejo> yofel: should libkf5kiogui5 be a dev package?
[22:34] <blaze> clivejo: no
[22:35] <blaze> it contains binary library
[22:35] <clivejo> feels odd or wrong adding libkf5kiogui5 as a build dep
[22:36] <blaze> why is it a build dep?
[22:36] <clivejo> lot of FTBFS because of it
[22:37] <clivejo> https://launchpadlibrarian.net/236829496/buildlog_ubuntu-xenial-amd64.ktexteditor_5.18.0+git20160207.0532+16.04-0_BUILDING.txt.gz
[22:37] <clivejo> lot of packages need it to build
[22:38] <blaze> does it contain header files?
[22:38] <clivejo> they just need that lib - "/usr/lib/x86_64-linux-gnu/libKF5KIOGui.so.5.19.0"
[22:38] <sgclark> actually it looks like 5.19 was released and the KIO dep needs a bump. Are you workingin unstable?
[22:40] <sgclark> kiogui is being referenced from the kio headers
[22:40] <blaze> clivejo: i guess it should be in kio-dev deps
[22:40] <clivejo> sgclark: I asked upstream (KDE) and they said libKF5KIOGui was a new package
[22:40] <sgclark> oh I see. interesting.
[22:40] <soee> there https://www.youtube.com/watch?v=WipM3SAYqK4 :)
[22:40] <clivejo> so I created one in control file and libKF5KIOGui.install
[22:41] <DarinMiller> But its for xenial, not wiley no?
[22:41] <clivejo> pushed it to kubuntu_unstable
[22:41] <clivejo> but now packages are FTBFS over it
[22:41] <clivejo> Im starting to think I shouldnt have created a new package :/
[22:42] <clivejo> just installed the files into kio-dev
[22:42] <blaze> no
[22:42] <sgclark> err
[22:43] <clivejo> DarinMiller: we always work on Ubuntu+1 first
[22:43] <clivejo> Xenial is the devel version so we package for it, then backport to previous releases if needed
[22:43] <blaze> kio-dev is a build dependency for everything and it should have libkf5kiogui5 in deps
[22:45] <clivejo> ah so kio-dev depends on libkf5kiogui5
[22:45] <clivejo> not each of the packages
[22:45] <blaze> yep
[22:46]  * clivejo is stupid
[22:47] <blaze> that's the way it works, -dev packages are depending on corresponding binary packages
[22:49]  * clivejo face palms
[22:50] <clivejo> I think thats fixed now
[22:52] <blaze> good, now i can go to sleep
[22:54] <clivejo> sgclark: there is a build dep on libindi-dev in apps, did you package that?
[22:55] <sgclark> no I have not touched that in years, it is a beast to package.
[22:56] <clivejo> kstars apparently needs it :/
[22:57] <sgclark> yup, I have begged for us to be able to use perfectly good packaged https://launchpad.net/~mutlaqja/+archive/ubuntu/ppa
[22:57] <sgclark> without luck
[22:57] <sgclark> shrug. I do not have time to tackle it.
[22:58] <clivejo> oh thats very up to date
[22:59] <sgclark> yes, and I do believe that developer is involved in kstars
[22:59] <clivejo> is it just a build dep?
[22:59] <sgclark> no clue why his packages wouldn't go into archive
[23:00] <clivejo> could we just copy the package to staging so it builds?
[23:00] <sgclark> no it is a ppa, external ppas are banned for CI, perhaps a copy is ok, ask yofel
[23:01] <sgclark> still there is issue in regards to archive though..
[23:01] <clivejo> he must be kstars dev
[23:01] <clivejo> kstars-bleeding - 5:15.12+r5628.247~ubuntu16.04.1
[23:02] <sgclark> yeah fairly certain he is.
[23:02] <clivejo> interesting - KStars is free, open source, cross-platform Astronomy Software. It provides an accurate graphical simulation of the night sky, from any location on Earth, at any date and time. The display includes up to 100 million stars, 13,000 deep-sky objects,all 8 planets, the Sun and Moon, and thousands of comets, asteroids, supernovae, and satellites.
[23:03] <clivejo> Current Maintainer: Jasem Mutlaq
[23:03] <clivejo> same guy


[12:02] <minghua> aptitude is really giving me a headache
[12:03] <lifeless> wow
[12:03] <\sh> ogra: the cube 21h
[12:03] <lifeless> multisync 0.90.18 really is experimental
[12:03] <ajmitch> it wipes all your data?
[12:03] <lifeless> it ignores deletes on the phone
[12:03] <lifeless> can't configure the irmc plugin
[12:04] <ogra> \sh, expect it to go over 1000 then ...
[12:05] <minghua> amazon US is actually selling iBook G4 at $900, not sure about europe though
[12:11] <ogra> in europe you get the cheapest around 1000
[12:12] <\sh> night guys
[12:17] <lifeless> ajmitch: azeem ping
[12:17] <minghua> crimsun: bug #5888 is the first package for scim rebuild.  I'll work on others tonight and tomorrow
[12:17] <Ubugtu> Malone bug #5888: scim-canna: package needs rebuild against libscim8c2a In: Ubuntu, Severity: Normal, Assigned to: Nobody, Status: New https://launchpad.net/bugs/5888
[12:17] <crimsun> minghua: ok
[12:18] <ajmitch> lifeless: pong
[12:18] <lifeless> so
[12:18] <lifeless> opensync 0.18
[12:18] <lifeless> I packaged that version thinking that tracking releases would be a good idea
[12:18] <lifeless> I'm not sure that that is the case :[
[12:18] <ajmitch> but no..
[12:18] <ajmitch> the release is broken?
[12:18] <lifeless> fooked
[12:18] <minghua> crimsun: I believe you prefer my sending all debdiffs to you together instead of bugging you for each package :-)
[12:18] <ajmitch> sigh
[12:19] <ajmitch> do they test it at all before releasing?
[12:19] <lifeless> its not that
[12:19] <lifeless> its that its a noticable step back from multisync - lots of things broken in the rearchitecture FWICT
[12:20] <crimsun> minghua: either way
[12:20] <lifeless> I'm just tracking down a bug in irmc for instance
[12:20] <ajmitch> that's quite unfortunate - I thought they were trying to fix what was lacking
[12:20] <lifeless> 0 length vcal files are reported as 'modified'
[12:21] <ajmitch> yes, I saw in the channel
[12:22] <sistpoty> revu new world order is done :)
[12:22] <ajmitch> sistpoty: revu2 is finished? ;)
[12:22] <minghua> One question: is MoM clever enough to knwo that -XbuildY version doesn't have sourceful changes and sync them automatically?
[12:22] <ajmitch> minghua: yes
[12:22] <sistpoty> ajmitch: no only sorting the list for revu 1
[12:22] <ajmitch> minghua: that's why we use that - it only looks at -XubuntuY
[12:23] <minghua> cool, then I don't need to babysit scim-m17n in dapper
[12:23] <lifeless> ajmitch: the ui to configure irmc is awol
[12:23] <minghua> ajmitch: thanks.  I thought that would be the whole point of differing -XubuntuY and -XbuildY suffices
[12:24] <lifeless> ajmitch: it *looks* to me like their split into parallel hiearchies was not done preserving the old functionalit
[12:24] <lifeless> y
[12:24] <ajmitch> lifeless: it was a ground-up rewrite
[12:24] <ajmitch> and they're filling in the pieces as needed?
[12:24] <lifeless> no
[12:24] <lifeless> definately a lot of old code there, the copyrights tell the tale
[12:25] <lifeless> I think it was a hacknslash job to the new framework
[12:25] <lifeless> and devil take the hindmost
[12:27] <lifeless> that bugs in HEAD anyway, whew
[12:27] <ajmitch> that's a good thing?
[12:27] <lifeless> yes, it means I don't have to backport a fix on an active project
[12:28] <scotth> I'm curious, how do people here upgrade their packages to new upstream versions.  Do you apply the diff or move the debian dir over or start from scratch or is there some automated tool for this?
[12:28] <sistpoty> scotth: uscan/uupdate can automate this process
[12:29] <scotth> sistpoty, thanks
[12:30] <sistpoty> scotth: and if you don't use that, it's usually a good idea to move the debian dir over, as more things will stay the same then will change
[12:30] <minghua> scotth: and maybe consider making all debian/ubuntu specific changes into patches, so all the .diff.gz is limited in debian/ dir
[12:31] <lifeless> for an alternative, I put everyine in bzr
[12:31] <lifeless> then a new upstream is just a new commit in the upstream branch, and a merge.
[12:32] <ajmitch> lifeless: how do you handle moved files in upstream?
[12:32] <ajmitch> you untar new upstream tarball, copy over .bzr?
[12:33] <lifeless> ajmitch: I untar the tarball if the upstream does not use vcs.
[12:33] <lifeless> ajmitch: then check status etc and adjust, the commit
[12:34] <lifeless> ajmitch: but if the upstream uses vcs, its easier still ;)
[12:34] <ajmitch> certainly
[12:34] <ajmitch> but then you don't have an orig.tar.gz that matches upstream, which can be a little annoying
[12:34] <lifeless> I guess thats another reason I largely ignore tarballs for packaging
[12:34] <minghua> hmm, maybe I should do the same thing
[12:34] <lifeless> meh
[12:35] <lifeless> the number of upstreams that release 'orig' tarballs we cant directly use is growing not decreasing
[12:35] <minghua> my upstream used CVS and all my debian packaging stuff is in SVN now
[12:35] <lifeless> -> autoconf dependencies & configure or makefile bugs
[12:35] <ajmitch> lifeless: we've just run into a few issues where debian & ubuntu have packaged a new upstream version separately, with differing tarballs
[12:35] <ajmitch> makes syncing a real pain
[12:35] <lifeless> -> included inappropriate files such as object or GFDL files
[12:35] <ajmitch> that one is annoying
[12:35] <scotth> sistpoty, how do you create a watchfile if none is provided upstream?
[12:35] <lifeless> ajmitch: yeah, I can imagine. Fortunately, as I can't upload to ubuntu yet, that won't happen ;)
[12:36] <sistpoty> scotth: just look at "man uscan"... good source for examples
[12:36] <scotth> lol, of course
[12:43] <minghua> speaking of modifying .orig.tar.gz, what is the conventional way to deal with .tar.bz2 only upstream?
[12:43] <minghua> just bunzip2 and gzip it?
[12:43] <lifeless> yes.
[12:44] <lifeless> unless its insanely big
[12:44] <lifeless> in which case ... evil happens
[12:45] <scotth> is there a good way to find out if a package has a motu maintainer?
[12:45] <ajmitch> most packages in universe don't have a motu that is caring for that specific one
[12:46] <ajmitch> there are some teams that do
[12:46] <lifeless> opensync-debian-team rah rah rah
[12:46] <minghua> I was wondering about that as well
[12:46] <ajmitch> mono team, etc
[12:46] <minghua> it would be nice to have some way to indicate a universe package get more love than others
[12:47] <minghua> which means some MOTU/MOTU-wannabe is building and testing it
[12:47] <crimsun> grep the output from dapper-changes and pipe it through wc -l? ;)
[12:47] <minghua> instead of just simplying syncing/merging from sid
[12:48] <minghua> crimsun: not a bad idea... :-)
[12:48] <scotth> well I'm interested in gajim, ejabberd, and a few other jabber related things.  I notice that gajim is listed in launchpad.net and has a registrant.  Does that mean it has a maintainer kinda?
[12:48] <ajmitch> scotth: for that, there's the MOTU IM team
[12:49] <ajmitch> https://wiki.ubuntu.com/MOTUIM
[12:49] <ogra> scotth, just look who touched it last (changelog) for any package, and talk to this guy if he cares personally, but in general we dont have any personalized packages
[12:49] <scotth> ahh
[12:49] <scotth> makes sense
[12:50] <ogra> most is done in teams here ... no "maintainers" like debian has
[12:50] <scotth> actually it looks like I might want to join MOTUIM
[12:50] <scotth> it looks to be right up my alley
[12:50] <ogra> indeed there are people that care more for certain packages ...
[12:51] <scotth> is it acceptable to add my name to that team in the wiki or should I contact the people listed?
[12:51] <ogra> do both ;)
[12:52] <scotth> cool
[01:09] <lifeless> ajmitch: azeem: anyway, I think we need to upload multisync 0.90 in parallell with 0.8x
[01:09] <lifeless> for a while yet
[01:09] <lifeless> tchau - yum cha time
[01:15] <Riddell> blurg, skim fails to build and I can't work out why or recreate it
[01:15] <Riddell> /usr/bin/fakeroot debian/rules binary-arch
[01:15] <Riddell> make: Nothing to be done for `binary-arch'.
[01:16] <desrt> sistpoty; i talked to the debian upstream guy about ghc.  as it turns out, someone reported the bug that the patch fixes against debian so he plans on integrating the patch (probably not until after the holidays, though)
[01:17] <sistpoty> desrt: thx... I just check timetable when upstreamversion-freeze will be for dapper
[01:18] <desrt> ah.  right.
[01:18] <eruin> is the maintainer of linphone around?
[01:18] <desrt> having a working ghci on powerpc is decidedly in my interests so i'd definitely advocate including the patch for ourselves if debian isn't fast enough :)
[01:19] <minghua> hi Riddell, is the build log somewhere?
[01:19] <Riddell> http://people.ubuntu.com/~lamont/buildLogs/s/skim/1.4.3-0ubuntu3/skim_1.4.3-0ubuntu3_20051217-2251-powerpc-failed.gz
[01:20] <eruin> if liblinphone1 depends on libjack0.100, but liblinphone1-dev depends on libjack0.100 - should I file a bug?
[01:20] <Riddell> eruin: why, that's the same thing?
[01:20] <eruin> well, that makes liblinphone1-dev uninstallable
[01:21] <eruin> oh, my mistake,. liblinphone1-dev depends on libjack0.80 ;)
[01:21] <sistpoty> desrt: we have uvf on jan 19. So i guess it will be better, if I include the patch soon... I still have the possibility to go in sync with debian later on
[01:21] <eruin> poor typing this late
[01:21] <sistpoty> desrt: where can I find your patch? in BTS?
[01:21] <desrt> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=343428
[01:22] <sistpoty> desrt: cool, thx. will care for it during next week
[01:23] <desrt> sistpoty; most excellent.  thanks.
[01:23] <sistpoty> np
[01:23] <Riddell> eruin: looks like a beastie!  I'm taking a look
[01:23] <eruin> Riddell, thanks mate :)
[01:26] <Riddell> eruin: uploaded, keep an eye on http://people.ubuntu.com/~lamont/buildLogs/l/linphone/ to make sure it compiles
[01:32] <sistpoty> Riddell: I just take a look at skim (ubuntu2) and its rules
[01:32] <Riddell> sistpoty: see anything revealing?
[01:32] <minghua> sistpoty: do you mean 0ubuntu3?
[01:32] <sistpoty> Riddell: if I get it right, you should have a target binary-arch... binary should depend on binary-arch
[01:33] <ajmitch> sistpoty: see changelog for 0ubuntu3
[01:33] <sistpoty> minghua: no, I guess my sources are outdated
[01:33] <ajmitch>   * Add fake rule in debian/rules on binary-arch
[01:33] <minghua> sistpoty: Riddell added an empty binary-arch target in debian/rules, but it didn't seem to help
[01:33] <minghua> I was thinking maybe binary-arch should depend on binary-common or something
[01:34] <minghua> I'm building skim -0ubuntu3 in pbuilder right now
[01:35] <sistpoty> compared to dh_make templates and policy hints, binary should depend on binary-arch and binary-indep
[01:36] <sistpoty> however binary-arch is optional according to the policy... maybe sbuild is wrong there
[01:37] <sistpoty> args... no binary-arch must exist (according to policy) and always succeed (even if it has nothing to do)
[01:37] <ajmitch> which is why you often see an empty rule
[01:38] <minghua> sistpoty: you were looking at build-arch, weren't you? ;-)
[01:38] <sistpoty> yes
[01:39] <minghua> yikes, scons sends color terminal control code to its log
[01:40] <Kyral> scons...
[01:40] <Kyral> *shudder*
[01:43] <ogra> sistpoty, but thats a silly and very debianish part of the policy, the ubuntu buildds are more tolerant ...
[01:43] <sistpoty> hehe
[01:43] <ogra> i have some "non policy compliant" ubuntu only packages where i tipped it out
[01:43] <ogra> *riped
[01:44] <ogra> grrr
[01:44] <ogra> *rpped
[01:44] <sistpoty> the only thing that looks odd with rules, is that phony targets are not listed in .PHONY
[01:44] <ogra> ARGH
[01:44] <ogra> r i p p e d
[01:44] <ogra> phew
[01:45] <minghua> StevenK is probably going to be bold pretty soon... :-P
[01:46] <StevenK> I'm already bold. :-P
[01:46] <StevenK> ITYM bald. :-)
[01:46] <minghua> yeah, I meant bald
[01:47] <minghua> StevenK: thanks for correcting, I was actually not sure and looking it up
[01:48] <StevenK> minghua: I suspect you can usually speak English better than I can. :-)
[01:48] <StevenK> It may be my first language, but I still suck at it. :-)
[01:48] <minghua> Riddell: I got exactly the same error with "pbuilder build --binary-arch skim_1.4.3-0ubuntu3.dsc"
[01:49] <minghua> Riddell: so probably the buildd is right
[01:49] <Riddell> hmm, right
[01:50] <minghua> hammer? :-P
[01:50] <ajmitch> drill & hacksaw
[01:50] <Kyral> screwdriver?
[01:50] <StevenK> Kyral: No screws, only a lock.
[01:50] <StevenK> ajmitch: Ouch.
[01:50] <ajmitch> drill out the lock
[01:50] <StevenK> Tried that.
[01:50] <Kyral> yah I concur with ajmitch
[01:50] <Kyral> nm
[01:50] <ajmitch> ah :(
[01:50] <Kyral> Blowtorch?
[01:51] <StevenK> Well, I drilled a hole in the lock, is that the same thing?
[01:51] <sistpoty> ok... /me needs to go to bed now
[01:51] <sistpoty> gn8 everyone
[01:51] <ajmitch> that's usually how it's done
[01:51] <ajmitch> drill out the centre of it so that it can open
[01:51] <StevenK> And I think I bent the bit doing it.
[01:51] <ajmitch> night sistpoty
[01:51] <minghua> Riddell: I _think_ having binary-arch depending on binary-common would solve it
[01:52] <minghua> it looks like a -B build will only call binary-arch, not binary
[01:54] <minghua> the debian/rules of skim doesn't look very professional anyway
[01:59] <eruin> I wonder why my computer loves crashing/overheating so much when I compile gaim
[01:59] <eruin> or rather, ./configure it
[02:00] <LaserJock> if a file is installed from a package it can be found by dpkg -S right?
[02:02] <minghua> LaserJock: only if it's in the package's .list file (i.e., not installed by postinst script, etc.)
[02:03] <LaserJock> minghua: ahhh, can I find it if it is isn't in the .list file?
[02:03] <minghua> and sometimes symlinks confuse dpkg -S as well
[02:03] <minghua> LaserJock: the .list file is in /var/lib/dpkg/info/ if you installed it :-)
[02:05] <eruin> Riddell, linphone_1.1.0-2ubuntu2_20051218-0047-i386-given-back.gz
[02:05] <minghua> LaserJock: I don't know how...  probably looking at the postinst script?
[02:06] <eruin> Riddell, doesn't look too healthy, the poor thing
[02:06] <Riddell> eruin: the i386 buildds seem to be in a mood to do that today
[02:06] <eruin> Riddell, all work, no fun ;-)
[02:07] <LaserJock> minghua: there are posinst script in /var/lib/dpkg/info/ so maybe it's there. I just need to track down where a particular file got installed from
[02:09] <minghua> LaserJock: ah.  I was thinking you just want to know _if_ a certain file is from a certain package, now you want to know _whick package_ it is from...  that's harder :-)
[02:09] <LaserJock> minghua: yeah, there is a file that is creating a bug and nobody knows where it comes from
[02:10] <minghua> LaserJock: maybe first try "readlink -f file" to get rid of symlink problem first?
[02:10] <minghua> LaserJock: bug nubmer?
[02:11] <LaserJock> bugzilla 20183
[02:13] <minghua> where is our friend Ubugtu now?
[02:13] <minghua> Ubugtu: ubuntu 20183
[02:13] <Ubugtu> Ubuntu Bugzilla bug #20183: firefox 1.4.99 upgrade still have compreg.dat, creates issue Product: Ubuntu, Component: firefox, Severity: normal, Assigned to<EMAIL_ADDRESS>Status: NEW https://bugzilla.ubuntu.com/show_bug.cgi?id=20183
[02:15] <Riddell> minghua: seems to have done the trick thanks
[02:15] <minghua> Riddell: no problem.  thank *you* for working on skim :-)
[02:16] <Riddell> well it was freeflying
[02:17] <minghua> Riddell: yeah, but you are the sponsor :-)
[02:17] <minghua> LaserJock: didn't comment #22 say it was shipped in mozilla-firefox 1.0.7?
[02:18] <Riddell> looks like I need to rebuild all the scim modules
[02:19] <minghua> LaserJock: oh never mind, I see comment #25 now
[02:19] <minghua> Riddell: for what reason?  I am working on the libstdc++ allocator transition rebuild right now
[02:19] <Riddell> minghua: oh, if you're doing it that's all good then
[02:20] <minghua> Riddell: if for skim support, then rebuild won't help
[02:20] <minghua> Riddell: yes, and crimsun is sponsoring me :-)
[02:20] <Riddell> ah good
[02:21] <Riddell> it's really good having CKJ types involved
[02:33] <minghua> Riddell: did freeflying say anything about the .orig.tar.gz inconsistancy to you?
[02:34] <minghua> Riddell: I met him on IRC a few days ago and he said he is waiting for William uploading it to debian now
[02:34] <minghua> Riddell: but he didn't say anything about my comments
[02:40] <Tonio_> good night
[03:35] <minghua> now I am finally getting this scim-setup segfault myself.
[04:13] <LaserJock> any MOTUs willing to do a quick review?
[04:13] <bmonty> LaserJock: what kind of review?
[04:13] <LaserJock> REVU review
[04:14] <bmonty> which package?
[04:14] <LaserJock> plotdrop
[04:15] <LaserJock> minghua: do you use gnuplot?
[04:15] <minghua> LaserJock: yes
[04:16] <LaserJock> you might like this package I've got on revu, plotdrop. You can drag n drop data files into it and plot them with gnuplot
[04:16] <LaserJock> it's pretty cool
[04:17] <LaserJock> the homepage is at http://icculus.org/~jcspray/plotdrop/
[04:18] <minghua> LaserJock: sounds cool. thanks
[04:18] <LaserJock> and the author is an Ubuntu user so that is cool to ;-)
[04:25] <LaserJock>  bmonty: a .desktop file is intalled
[04:26] <bmonty> ahh, I see it now :)
[04:27] <LaserJock> so I don't need to keep the comments at the top?
[04:27] <bmonty> LaserJock: nope...you only need the first line
[04:28] <bmonty> the rest of the comments don't really apply IMO
[04:28] <LaserJock> what about # -*- makefile -*-
[04:28] <LaserJock> does that do anything?
[04:28] <bmonty> no
[04:29] <minghua> LaserJock: that's for emacs IIRC
[04:29] <bmonty> even more reason to remove it :)
[04:29] <LaserJock> lol
[04:29] <LaserJock> ok, uploaded
[04:31] <LaserJock> bmonty: not an emacs fan?
[04:32] <bmonty> LaserJock: its not my favorite editor
[04:33] <LaserJock> bmonty: so do you like vim better or something else?
[04:33] <bmonty> I personally like vim better than emacs
[04:35] <LaserJock> I started out with emacs but I am starting to get used to vim. I have to force myself to use each one for a few days at a time. I am getting better at both that way.
[04:37] <LaserJock> sweet, thanks bmonty
[04:37] <bmonty> np
[04:39] <bmonty> LaserJock: plotdrop builds here, I got a couple errors with piuparts but no files that your package touches
[04:43] <JohnnyMast> any one interested in looking @ ttb (revu)
[04:45] <LaserJock> bmonty: ahh, yeah. I need to get piuparts going. I haven't tried that out yet
[04:45] <bmonty> you have a pbuilder, right?
[04:45] <JohnnyMast> bmonty wasnt it you wo also looked at ttb ?
[04:46] <JohnnyMast> hey lukas
[04:46] <bmonty> JohnnyMast: maybe :)
[04:46] <JohnnyMast> bmonty well i have made my fixes
[04:46] <lukas> hey JohnnyMast
[04:46] <JohnnyMast> :D
[04:46] <LaserJock> bmonty: yeah, I have pbuilder and dchroot, but I haven't bothered to get piuparts going yet
[04:46] <JohnnyMast> welcome back home lukas
[04:47] <bmonty> LaserJock: you can use your pbuilder chroot with piuparts check out the -p or -b options
[04:47] <LaserJock> bmonty: sweet, good to know. I will look into that
[04:48] <minghua> crimsun: what I have done tonight is in malone 5894, 5895 and 5896
[04:48] <Ubugtu> Malone bug #5894: chewing (Ubuntu) - scim-chewing: needs rebuild against libscim8c2a In: scim-chewing (Ubuntu), Severity: Normal, Assigned to: Nobody, Status: New https://launchpad.net/bugs/5894
[04:49] <minghua> crimsun: but scim-uim (5896) has some other bug, so you may want to delay that upload, please see my comments on malone
[04:49] <minghua> crimsun: thanks
[04:49] <crimsun> minghua: ok
[04:50] <crimsun> I'll look at 589[45]  then
[04:54] <JohnnyMast> punkrockguy318 nice nick :)
[04:54] <punkrockguy318> JohnnyMast, thank you =D
[04:54] <JohnnyMast> ur a punk rocker ?
[04:56] <JohnnyMast> and Johnny cash ... ring of fire
[04:56] <minghua> crimsun: is it okay to close the bug even if scim-canna hasn't been built on i386 yet? ;-)
[04:58] <JohnnyMast> while ur asking crimsun: (and hes gone)  i do advise you to wait
[04:59] <minghua> JohnnyMast: oh sure
[05:01] <JohnnyMast> but then again its just an advise
[05:01] <zakame> lunchtime all :D
[05:01] <JohnnyMast> luchtime ??
[05:01] <JohnnyMast> its 5 at night man
[05:01] <JohnnyMast> :p
[05:02] <zakame> er its 12 noon here :P
[05:02] <JohnnyMast> oh in that case, i would like one sandwitch with cheese please
[05:02] <JohnnyMast> neh ile make it my self and head to bed
[05:03] <JohnnyMast> mmm thanks man :)
[05:03] <zakame> JohnnyMast: rock on :)
[05:03] <JohnnyMast> :D
[05:04] <JohnnyMast> alright im gone, MOTU`s sand hopefulls sleep well
[05:05] <zakame> gn8 JohnnyMast
[05:05] <JohnnyMast> gn
[05:37] <Kyral> Goodnight MOTU
[05:38] <zakame> gn8 Kyral
[06:09] <zakame> bye all
[06:49] <LaserJock> azeem: ping?
[08:50] <zakame> hey all
[08:51] <minghua> hi zakame, welcome back :-)
[11:02] <Gloubiboulga> hello
[11:07] <pef> Gloubiboulga: salut :)
[11:08] <Gloubiboulga> salut pef :)
[11:30] <sivang> morning all
[11:32] <Gloubiboulga> hello sivang
[11:42] <greenpenguin13> would someone mind fixing bug #21126 please? ive tried myself, but... :-p
[11:42] <Ubugtu> Error: Error getting Malone bug #21126: Bug does not exist
[11:52] <Gloubiboulga> greenpenguin13, gnomemeeting just needs a rebuild I think
[12:01] <sivang> #21126
[12:02] <greenpenguin13> i will have a peek...
[12:04] <siretart> morning
[12:07] <greenpenguin13> afternoon
[12:13] <lifeless> azeem: around ?
[01:08] <herve> hello
[01:08] <zakame> hello herve
[01:54] <azeem> lifeless: hey
[02:07] <tseng> anyone on ppc64?
[02:31] <thierry> with debhelper, how can I put the configure thing before cleaning??
[02:34] <azeem> why do you need that?
[02:36] <StevenK> Presumably clean is running make clean with no Makefile.
[02:39] <thierry> StevenK , azeem : well it's because it's a ruby building apps, so when I do "ruby install.rb clean" before "ruby install.rb config" it complains that he needs to run config before
[02:41] <thierry> azzem , StevenK : so any idea how I could do that?
[02:41] <StevenK> Add a - to ruby install.rb clean so it's non-fatal.
[02:41] <StevenK> "-ruby install.rb clean"
[02:47] <thierry> yeah but where?
[02:48] <StevenK> debian/rules
[02:48] <thierry> ho ok sorry
[02:49] <thierry> I get this dh_testdir
[02:49] <thierry> # Add here commands to compile the package.
[02:49] <thierry> ruby install.rb setup
[02:49] <thierry> install.rb config first
[02:49] <thierry> Try 'ruby install.rb --help' for detailed usage.
[02:49] <thierry> make: *** [build-stamp]  Error 1
[02:49] <thierry> debuild: fatal error at line 765:
[02:49] <thierry> dpkg-buildpackage failed!
[02:49] <thierry> ho ok I see why, forget this
[04:05] <JohnnyMast> good afternoon
[04:06] <JohnnyMast> is the maintainer of kdetv here ?
[04:57] <Riddell> JohnnyMast: hi
[04:57] <JohnnyMast> Riddell hi
[04:57] <Riddell> not sure who that is but it's a KDE package so it's probably my fault
[04:58] <JohnnyMast> well i just wanted to ask one question
[04:58] <JohnnyMast> i have the same setup in configureing and makefiles
[04:59] <JohnnyMast> and they where also created with kdevelop but it install in /usr/local/bin
[04:59] <JohnnyMast> and thats bad when developing a ubuntu package so im wondering what kdetv does
[05:04] <Riddell> JohnnyMast: --prefix=/usr  for ./configure
[05:05] <JohnnyMast> well thats not it ... and yes i know that hack
[05:05] <Riddell> it's not a h
[05:05] <Riddell> it's not a hack, it's how all
[05:05] <JohnnyMast> but thats not supposed to be needed
[05:05] <Riddell> automake programs work
[05:06] <Riddell> JohnnyMast: the kdetv package uses cdbs which will specify the --prefix for ./configure
[05:07] <azeem> JohnnyMast: it is needed because programs usually default to /usr/local for prefix
[05:07] <azeem> which is fine for locally compiled and installed softwre
[05:07] <JohnnyMast> azeem yes for native packages
[05:07] <JohnnyMast> but not for OS software
[05:07] <JohnnyMast> installed via .deb packages
[05:08] <azeem> right, that's why we do --prefix=/usr
[05:08] <azeem> it's not a hack, it is how it is supposed to be
[05:09] <JohnnyMast> i was just wondering the if maintainer took (ubuntu maintainer) care of that else he/she had to use --prefix=/usr
[05:14] <Riddell> --prefix=/usr --sysconfdir=/etc --localstatedir=/var
[05:14] <Riddell> or maybe --sysconfdir=/etc/kde3
[05:14] <Riddell>  --with-qt-dir=/usr/share/qt3 --disable-rpath --with-xinerama
[05:15] <JohnnyMast> Riddell its good to know you know your stuff. Makes reviewing a heck of a lot easyer
[05:28] <JohnnyMast> some one fixing gnomemeeting already if not leave it to me
[05:32] <ogra> you fix main packages ?
[05:33] <JohnnyMast> ow its main ?
[05:53] <siretart>  (I'm speaking of packages which don't exist in Debian yet).
[05:53] <siretart> sry. didn't want to paste
[06:06] <buxy> siretart: hehe, I've seen that you've read my mail then :)
[06:06] <siretart> buxy: sorry? which mail?
[06:07] <buxy> siretart: the one that you pasted
[06:07] <siretart> buxy: aah, that mail. of course :)
[06:07] <siretart> ah, so you are raphael, nice to meet you :)
[06:07] <buxy> siretart: nice to meet you too :)
[06:07] <siretart> buxy: that email is very interesting and promising stuff. I'm currently thinging how to get the most of it. for both debian and ubuntu
[06:09] <buxy> siretart: Yeah, I would love to be able to set a "nice precedent" of successfull collaboration between Ubuntu and Debian :)
[06:10] <siretart> buxy: that would be really really great.
[06:10] <siretart> I'm still thinking about a few details
[06:10] <thierry> whats means : old-fsf-address-in-copyright-file ?
[06:11] <ogra> thierry, what it says ...
[06:11] <thierry> what's an old-fsf-adress ?
[06:11] <buxy> siretart: just tell me what you're thinking...
[06:11] <ogra> f-s-f == free software foundation
[06:11] <buxy> thierry: use "lintian-info" to have more verbose information about the message
[06:11] <ogra> thierry, they moved ...
[06:12] <buxy> ogra: that's the right answer, explaining people how to learn themselves :)
[06:12] <siretart> buxy: if I understand you correctly, then you want to have something like REVU, but what is also a frontend to a more or less public svn archive, yes?
[06:12] <siretart> buxy: and I'm currently think if and how this could be implementable
[06:12] <ogra> buxy, true ... but some background knowledge might help as well :)
[06:13] <buxy> siretart: yes, a public svn repo, where the mentors can directly work on their packages
[06:13] <buxy> ogra: of course
[06:13] <siretart> buxy: do you think we can place that on alioth? or shall we use another server for that?
[06:13] <buxy> and where the reviewers can see the history and the evolution of the package in the hands of the "applicant"
[06:14] <ogra> siretart, hmm, doenst the launchpad supermirror offer that anyway
[06:14] <buxy> siretart: I'm an alioth admin, so yes we can use alioth if needed
[06:14] <ogra> so you'd only need a branch script that puts it on alioth
[06:15] <buxy> ogra: any pointer to that "supermirror" thingy ?
[06:15] <ogra> no idea, we were shown it live at ubz, i dont know where the specs for it are
[06:15] <siretart> buxy: the 'supermirror' is a service provided by canonical, which imports public cvs and svn repositories to bzr archives
[06:16] <ogra> in general its a huge centralized bzr archive of the whole world on launchpad
[06:16] <siretart> buxy: you know, I designed REVU so that newbees can see how uploading with dput works.
[06:17] <siretart> but I see what you try to acheive with svn, so thats promising
[06:17] <siretart> buxy: have you thought about hacking up something based on trac?
[06:17] <buxy> siretart: we can still have an associated "binary repositorie" so that people can upload those with dput ... and test their tool
[06:18] <siretart> buxy: revu does only accept sourceful only uploads, just like the ubuntu archive
[06:18] <siretart> binary uploads are ignored
[06:18] <ogra> but with elma we'll also have binarys there ...
[06:18] <ogra> so debian could grab them
[06:18] <siretart> we rather want buildlogs than binaries
[06:19] <buxy> siretart: we can have a two-way working: either work directly in svn, or work at home and upload with dput and then a script injects it into svn
[06:19] <siretart> and debian would want to have them rebuild by a 'trusted' DD anyway
[06:19] <ogra> yes, but its a side effect, we wont need but we could keep them for debian
[06:19] <buxy> ogra: elma ?
[06:19] <ogra> s/need/need them/
[06:19] <siretart> buxy: thats sounds promising. so nobody is actually forced to use svn
[06:19] <ogra> buxy, elmo automated ;)
[06:20] <ogra> buxy, our automatic buildd admin for revu2
[06:20] <siretart> buxy: elma is a bad joke about a script, which we want to use for the next version of revu. It will build uploaded packages and attach the buildlog to the detail page
[06:20] <buxy> ok nice
[06:21] <ogra> siretart, i oppse the bad in the above sentence .... its a tribute ;)
[06:21] <ogra> *oppose
[06:21] <ogra> or a praise :)
[06:22] <siretart> ogra: you're right :)
[06:24] <siretart> buxy: well, my current project and plan is to get this one implemented: https://wiki.ubuntu.com/REVU2Spec
[06:25] <siretart> buxy: and I think having an svn under the hood should be achievable
[06:26] <buxy> Yes I've seen your spec already
[06:26] <buxy> it's quite good
[06:26] <siretart> buxy: the current plan is to use launchpad for authentication, though. I'm pretty sure that many DDs will object in using launchpad
[06:27] <buxy> Right, I wanted to mention that ... if you could factorize that part of the code in a easily replaceable module, that would be cool
[06:27] <siretart> but hacking around the authentication part shouldn't be that hard. revu2 is already quite modular (thanks to sistpoty!)
[06:28] <siretart> buxy: only one class would have to be rewritten, not that much of trouble
[06:29] <buxy> How do you handle all the stuff requiring root rights ?
[06:29] <buxy> I mean recompiling a package is not a trivial task ...
[06:30] <siretart> buxy: sudo
[06:30] <buxy> in particular since the package cannot be really trusted.
[06:30] <siretart> buxy: we won't do anything which needs root rights automatic
[06:31] <siretart> buxy: rebuilds are semi automatic, so a human needs to do a first check first. then he is able to request a build
[06:33] <buxy> siretart: do you plan to generate a history associated to an applicant ?
[06:34] <buxy> I mean so that you can easily review the evolution of someone when you must decide if he deserves to be MOTU/DD ?
[06:34] <siretart> buxy: there will be an overview page listing all sourcepackages he contributed
[06:34] <siretart> based on the information in the database
[06:36] <buxy> in that part it would be nice to be able to come back to "svn commits" they made, or come back to changelog of uploads they made
[06:37] <buxy> as well as comments of reviewers associated to those "uploads"
[06:38] <ogra> but we look into -changes anyway if we review someones application for MOTUship at the TB
[06:39] <siretart> buxy: ah, I see what you mean
[06:39] <ogra> there is no detailed review of someones single packages
[06:39] <ogra> that would cost to much time ...
[06:40] <ogra> usually the persons who worked with him get asked to give an opinion on his collaboration and packaging skills
[06:40] <buxy> ogra: keep in mind that Debian has different opinion on what needs to be reviewed before accepting someone for DD
[06:40] <ogra> i know
[06:40] <buxy> ogra: in Debian also we ask the opinion of the sponsor
[06:41] <ogra> as we do ...
[06:41] <buxy> but if we can handle the complicated case, you can still decide based on what you want :)
[06:41] <ogra> but note that we dont have a single sponsor for a MOTU hopeful
[06:41] <siretart> buxy: well, the expected workflow of an applicant is, that he mainly tries to get 'his' packages into shape. so for completely new packages, I didn't notice any 'group maintenance' in the past
[06:41] <ogra> only group reviews ...
[06:42] <buxy> siretart: I see more and more projects on alioth to start packaging new apps in team mode (from the beginning)
[06:42] <siretart> buxy: so the workflow described in the Revu Spec is based on what we have seen while running revu1
[06:42] <buxy> siretart: I understand that, that's why I started this discussion now,
[06:42] <siretart> buxy: which is a good thing, I think
[06:43] <buxy> so that we can see bit further and create something usefule for more people and which will last longer
[06:43] <siretart> buxy: yes, I think get what you want.
[06:45] <siretart> buxy: summary: this 'group maintenance' workflow what you propose is imo very promising, but it doesn't fit 100% in the workflow process which we desinged for revu
[06:45] <ogra> or into the MOTU process ...
[06:45] <siretart> I think I should think a bit more about how 'group maintenance' could be clarified, and write some lines about that
[06:46] <ogra> even if we have teams, the teams still dont *own* any packages in ubuntu
[06:47] <siretart> I think what buxy actually wants is to 'track' 'contributions'
[06:47] <siretart> which we actually want too
[06:47] <siretart> but a 'contribution' in the model of 'group maintenance' is a bit more fine granular
[06:47] <ogra> that enables us to keep a low entry threshold for MOTU hopefuls, most stuff you learn, you learn by doing, and the non personalized package approach we have allows you to make mistakes, since someone else can quickly pick your broken package and fix it without begging for NMU rights ...
[06:48] <siretart> buxy proposes to identify 'contribtutions' with svn commits
[06:48] <ogra> its fine as long as we dont overcomplicate the entry process for new MOTUS ...
[06:49] <siretart> ogra: I think for us MOTUs we will stick with revu, and work on revu2. what buxy proposes is way more far reaching
[06:49] <ogra> yup
[06:49] <siretart> but I'm definitly interested in helping with implementing it!
[06:50] <buxy> ogra: I have the same goal for Debian, I want external people join and help us even without being DD
[06:50] <buxy> so that they can learn by doing
[06:50] <ogra> what buxy proposes sounds very fine for the debian model, it will improve a lot ...
[06:51] <buxy> but I need transparency on what they do so that we can better judge people, better train them and so that the work of reviewers is simplifed
[06:51] <ogra> buxy, but isnt that what mentors was supposed to do once ?
[06:51] <buxy> ogra: mentors.debian.net ?
[06:51] <siretart> buxy: besides, do you need to be a DD to create an alioth project or can anyone apply for one?
[06:51] <buxy> siretart: anyone can apply
[06:51] <siretart> nice. good to know
[06:52] <ogra> buxy, yup
[06:52] <ogra> at least thats how i understood it ...
[06:52] <buxy> but an alioth project is only approved if it's related to Debian in one way or another
[06:52] <siretart> sure
[06:52] <buxy> ogra: sure, but what they did is not enough yet, and they were in CC of my mail, I want them to help us too ! :)
[06:53] <buxy> siretart: wiki.debian.org/Alioth and AliothFAQ if you want to learn more about alioth
[06:53] <ogra> oh, i didnt look at the recipient list, right :)
[06:58] <buxy> ogra: BTW collaborative maintenance doesn't mean "maintained by a formalized list of people"
[06:59] <buxy> my proposal will help bring decentralized management of packages into Debian
[06:59] <ogra> buxy, but the "group maintenance" attempt put together with debians way of having personalized packages sounds like it
[07:00] <ogra> its hard to imagine (at least for some DDs i can think of) that you will be able to change the world :) but my best wishes are with you indeed
[07:01] <buxy> ogra: whatever you think, I'm changing the way Debian works ...
[07:01] <buxy> :-)
[07:01] <siretart> :)
[07:01] <buxy> it takes time but it's possible
[07:02] <ogra> crossing my fingers for you, it would rock if it worked :)
[07:02] <siretart> buxy: if you want truely distributed management of packages, then I'm not sure if svn fits your model
[07:02] <buxy> if you check what I said in 2002 when I tried to get Debian Leader ... I announced most of the work that I did in the last 3 years and this work
[07:02] <buxy> lead to more packages being now "group maintained" when there was none in 2002
[07:03] <buxy> siretart: I've heard lots of good things about svk
[07:03] <ogra> i think i read your papers back then :)
[07:03] <siretart> buxy: good point.
[07:03] <buxy> siretart: and frankly I'm not interested in a discussion about VCS
[07:04] <buxy> I'm maintaining alioth and we offer SVN/baz/bzr/tla repo for maintenances
[07:04] <siretart> right
[07:04] <buxy> and SVN is *way* more popular (at least in the Debian world)
[07:04] <siretart> I just noticed that you used 'svn commits' in the discussion above
[07:04] <siretart> and svn-buildpackage is imo the best of the *-buildpackages around
[07:06] <buxy> I don't if it's the best, but it exists
[07:06] <buxy> and it works and many people already use it
[07:08] <buxy> if I want to make Debian evolve, I have to follow the natural path of Debian ... if 70% of Debian uses SVN, I have to use SVN to have a good chance that poeple will use the new infrastructure
[07:11] <siretart> right
[07:12] <siretart> and after all, svn isn't that bad at all. in fact, I like it :)
[07:12] <shawarma> Have any of you tried the new Gaim?
[07:13] <shawarma> I'm assuming you've noticed the 2.0.0beta1 release. :-)
[07:16] <greenpenguin13> bug 21126...
[07:16] <Ubugtu> Error: Error getting Malone bug #21126: Bug does not exist
[07:16] <ogra> meh, still no gobby 0.3.X
[07:24] <Hieronymus> Can someone please review http://revu.tauware.de/details.py?upid=1232 (bulldozer package)?
[08:11] <JohnnyMast> does any one know a vlc tweak to broadcast your cam OUTside my lan ?? .... for now the httpd that vlc creates only works inside the lan
[08:37] <ajmitch> morning
[08:37] <LaserJock> morning ajmitch
[08:41] <LaserJock> ajmitch: up for a quick REVU review? I just need one more advocate for plotdrop and I am leaving town for a couple of weeks so I would like to get if done today or tomorrow.
[08:42] <ajmitch> not right now sorry
[08:42] <ajmitch> maybe later today
[08:42] <LaserJock> ok, that's fine
[08:43] <tseng> link please
[08:43] <LaserJock> http://revu.tauware.de/details.py?upid=1235
[08:47] <tseng> LaserJock: done.
[08:48] <LaserJock> tseng: thanks so much
[08:48] <tseng> nps
[08:51] <Hieronymus> Will someone review my bulldozer package, please?
[08:51] <Hieronymus> http://revu.tauware.de/details.py?upid=1232
[08:52] <ajmitch> tseng: plotdrop will ftbfs
[08:53] <ajmitch> and a quick look at the makefile shows that it might screw up the chroot it's built in
[08:53] <tseng> ajmitch: go me, i didnt build it
[08:53] <ajmitch> (ftbfs due to gtk+ breakage)
[08:53] <ajmitch> unless seb fixed that
[08:53] <tseng> what part am i looking at?
[08:53] <ajmitch> I just built it on tiber quickly
[08:53] <tseng> in the source itself?
[08:53] <LaserJock> ajmitch: what?
[08:54] <tseng> i only reviewed the diff, i am lazy
[08:54] <ajmitch> LaserJock: does your makefile respect DESTDIR after it's been patched?
[08:54] <ajmitch> because +$(MAKE) PREFIX="/usr"
[08:55] <ajmitch> that part is ok
[08:55] <ajmitch> but abusing PREFIX later on..
[08:56] <ajmitch> anyway, I'm late for work
[08:56] <LaserJock> ajmitch: where?
[08:57] <LaserJock> oh, in install?
[08:59] <LaserJock> all I know is it builds fine in my pbuilder. I do patch the Makefile (maybe I am not doing it right though).
[09:26] <ajmitch> sigh, I hate having to go to work & use windows
[09:26] <Kyral> lol
[09:26] <Kyral> I know the feels
[09:26] <Kyral> feeling even
[09:27] <Kyral> I had to help my uncle print his boarding pass
[09:27] <Kyral> the only computer I had access to had WinMe + AOL Dialup
[09:27] <ajmitch> & my wrist seems to be getting a little stuffed from using the mouse here
[09:27] <Treenaks> ajmitch: that's _possible_ ?!
[09:28] <ajmitch> Treenaks: not only is it possible
[09:28] <ajmitch> but I'm going to do it in a few days
[09:28] <Treenaks> omg!
[09:29] <ajmitch> yes, very funny
[09:38] <hub> can someone review http://revu.tauware.de/details.py?upid=1238
[09:38] <Mirno> omg!
[09:38] <hub> now that if build from source
[09:39] <Mirno> Kyral: Hi
[09:39] <hub> (it broke because of bad code + gcc being stricter)
[09:39] <Kyral> hello Mirno
[09:40] <Mirno> hello Kyral
[09:41] <Mirno> is icc free of charge ?
[09:42] <Kyral> ICC?
[09:42] <Mirno> Intel C Compiler
[09:42] <Kyral> Intel has their own C Compiler?
[09:42] <siretart> yeah
[09:42] <siretart> it optimizes great
[09:43] <ajmitch> for anything but an amd chip ;)
[09:43] <Mirno> Kyral: yes it's a much bette roptimizer than gcc
[09:43] <ajmitch> hi siretart
[09:43] <Kyral> I dunno I just use GCC
[09:43] <siretart> huhu ajmitch
[09:43] <Mirno> Kyral: me too
[09:43] <Mirno> Kyral: I was considering to try icc
[09:43] <hub> Mirno: if only Intel could provide this to gcc
[09:43] <hub> ....
[09:43] <Mirno> hub: yes if only ... :=)
[09:44] <Mirno> hub: do you know if it's free of charge ?
[09:44] <hub> Mirno: I know it is not free softw3
[09:44] <hub> software
[09:44] <Mirno> hub: yes that i know
[09:44] <hub> so for the rest I'm not caring at all
[09:45] <Mirno> but do they cherge forit ?
[09:45] <Mirno> ok hub
[09:45] <siretart> Mirno: for noncommercial/private use its free. not sure for educational purposes but I think too
[09:46] <Mirno> siretart: ok, thank you very much :)
[09:46] <Mirno> siretart: (hi BTW)
[09:46] <siretart> huhu Mirno
[09:47] <siretart> Mirno: ah, good that I catch you ;)
[09:47] <siretart> Mirno: have you already seen http://debian-unofficial.org?
[09:48] <Mirno> siretart: no
[09:50] <Mirno> One unofficial repository to rule them all.
[09:50] <Mirno> huhu
[09:50] <siretart> Mirno: I'm currently in contact with him. what he does is in my opinion quite similar to plf, I think
[09:51] <Mirno> siretart: yes
[09:51] <Mirno> siretart: but he does it for debian
[09:51] <Mirno> siretart: :)
[09:51] <siretart> Mirno: well, he is a DD
[09:51] <siretart> (well, not yet, he is in NM, but anyway)
[09:52] <siretart> Mirno: he wouldn't object much in having a http://ubuntu-unofficial.org
[09:52] <Mirno> siretart: DD as in Dolby Digital ? :)
[09:52] <siretart> Mirno: DD as in debian developer
[09:52] <Mirno> siretart: so ?
[09:53] <siretart> Mirno: I thought you might be interested in knowing
[09:55] <Mirno> siretart: well I don't understand why we should take this domaine name and why should we ask him for it ?
[09:56] <siretart> Mirno: no, I don't mind about the domain name
[09:56] <siretart> Mirno: I rather mind about the repository's package policy and the packages he actually has
[09:58] <Mirno> siretart: he is willing to port them ?
[10:01] <siretart> Mirno: AFAIK he accepts buildds
[10:01] <Mirno> siretart: what is "AFAIK" ? :)
[10:01] <siretart> as far as I know
[10:01] <siretart> or better, I think
[10:01] <Mirno> siretart: and what is "builds" ?
[10:02] <Mirno> siretart: you mean binary deb ?
[10:02] <siretart> Mirno: a build daemon is a machine autobuilding packages
[10:03] <Mirno> siretart: you propose I provide a ubuntu machine so he can build his packages for ubuntu ?
[10:03] <Mirno> s/propose/suggest/
[10:04] <siretart> I currently dont suggest anything
[10:04] <siretart> I'm considering how we can collaborate with him
[10:04] <Mirno> siretart: I don't understand what you have in minde :)
[10:05] <siretart> Mirno: currently I'm at the stage in thinking how to compare his repository with what we already have in multiverse
[10:05] <siretart> Mirno: and then look whats left. what we can include in multiverse, and what would have to go to some other repository
[10:06] <Mirno> siretart: ok
[10:06] <siretart> Mirno: please don't misunderstand me, but for my taste, the plf acceptance policy is far too lax. thats why I cannot recommend using them with clean concience.
[10:07] <Mirno> siretart: as you wish :)
[10:19] <siretart> Mirno: http://tiber.tauware.de/~siretart/unofficial/not-in-ubuntu thats the list of packages in debian-unofficial but not in multiverse
[10:19] <Mirno> siretart: ok
[10:19] <Mirno> thx
[10:19] <siretart> so I need to go through the list and comment about their status
[10:20] <siretart> Mirno: for libdvdcss, he has no problems with hosting it, because he says it was legal in CH *shrug*
[10:20] <siretart> for java, it is a bit more complicated, because sun makes YOU responsible when you are redistributing it
[10:21] <siretart> for skype, he told me it was no problem. you just have to report that to skype and update it everytime they release a new version
[10:22] <siretart> so we cannot have skype in ubuntu, because we cannot update in past releases
[10:23] <Amaranth> updates and/or backports?
[10:24] <ajmitch> siretart: interesting, what did you use to get that list?
[10:25] <siretart> ajmitch: I downloaded the 'Sources' files, concatenated them, extracted the source package name with grep-dctrl
[10:25] <ajmitch> siretart: just grep packages files?
[10:25] <ajmitch> ah, using source package namesd
[10:25] <siretart> ajmitch: did some sort magic, then diffed it and edited the '-' away with vim
[10:25] <ajmitch> nice
[10:25] <siretart> the manual foo and magic
[10:25] <siretart> ;)
[10:25] <ajmitch> yep
[10:26] <hub> siretart: dvdcss is legal in a lot of countries :-)
[10:26] <ajmitch> much better than nasty hackish scripts like mine
[10:26] <siretart> hub: interesting
[10:26] <Kyral> But because the US Government is run by the RIAA...
[10:26] <ajmitch> hub: but mirrors would end up carrying it & we can't push it to there
[10:26] <siretart> ajmitch: well, I assume your hackish scripts are non-interactive
[10:26] <hub> ajmitch: I get the point :-)
[10:26] <hub> I was just saying
[10:26] <ajmitch> siretart: of course
[10:26] <ajmitch> siretart: and now sistpoty is using them to update the merge lists
[10:26] <siretart> cool!
[10:27] <siretart> perhaps I should put the list on the ubuntu wiki
[10:27] <siretart> for public commenting them
[10:27] <Kyral> what are these?
[10:28] <ajmitch> siretart: we'll do a similar interface for unmet deps later as we do for merges now
[10:28] <hub> can someone advocate this http://revu.tauware.de/details.py?upid=873
[10:28] <ajmitch> siretart: if we had enough RAM I'd like to use britney on tiber
[10:28] <hub> and this http://revu.tauware.de/details.py?upid=1238
[10:28] <ajmitch> but apparantly it really loves the memory
[10:29] <ajmitch> maybe ask kamion about getting the scripts
[10:30] <siretart> ajmitch: how much ram does she need?
[10:30] <ajmitch> well we only need to do an installability test
[10:30] <siretart> I never used britney
[10:30] <ajmitch> but imagine holding the whole dependency tree in memory
[10:31] <ajmitch> and resolving all the virtual depends, conflicts, etc
[10:31] <siretart> but running them on universe would be really interesting
[10:31] <siretart> ajmitch: perhaps you could place a ready to run example on tiber, so I can run her on my machine?
[10:31] <ajmitch> which is why I didn't continue writing my pure python version
[10:31] <ajmitch> siretart: I grabbed the source on tiber
[10:32] <ajmitch> but it requires python-apt, and some other packages
[10:33] <ajmitch> sorry,  libapt-pkg-dev
[10:33] <siretart> ajmitch: thanks
[10:33] <siretart> how to use/configure her?
[10:33] <ajmitch> no idea
[10:33] <ajmitch> well I have an idea
[10:33] <ajmitch> but it's not well documented
[10:34] <siretart> ah, exactly my problem :)
[10:34] <ajmitch> as like any of the 'evolved' debian scripts ;)
[10:34] <ajmitch> which have just grown in place on debian
[10:36] <siretart> and she doesn't like amd64 :/
[10:36] <lfittl> Does anybody know why the i386 buildd gives back some packages lately? (http://people.ubuntu.com/~lamont/buildLogs/m/mdf2iso/0.3.0-0ubuntu1/)
[10:36] <JohnnyMast> siretart do you have some time to review 2 packages ?
[10:37] <siretart> sorry, I'm too tired now :(
[10:37] <seth_k|lappy> anyone want to review a merge for a KDE package, noteedit? Should be quite quick; very small debdiff
[10:37] <JohnnyMast> any one else ? that i could tackle for a revu ?
[10:41] <seth_k|lappy> lfittl, i386 buildd is messed up, it'll be fixed
[10:42] <lfittl> seth_k|lappy: k, thanks for the information :)
[10:49] <greenpenguin13> bug #21126 is fixed but still listed on bugzilla
[10:49] <Ubugtu> Error: Error getting Malone bug #21126: Bug does not exist
[10:53] <siretart> seth_k|lappy: which bugno?
[10:57] <ajmitch> JohnnyMast: I'll review kryptor later, but my first impression is that the diff is too big (generated files), and you've got numerous spelling errors, some of which really do matter (eg in debian/rules)
[10:58] <JohnnyMast> ajmitch alright im looking forward to it
[10:59] <ajmitch> JohnnyMast: and you don't need libx11-dev & libx11-6 in build-depends
[10:59] <JohnnyMast> ajmitch toucht that already
[10:59] <ajmitch> build-depending the library as well as the headers is unnecessary, and kdelibs4-dev pulls it in anyway
[11:15] <LaserJock> ajmitch: do you still have problems with my plotdrop packaging?
[11:17] <Kyral> anyone know what "warning: assignment discards qualifiers from pointer target type" means?
[11:18] <Mithrandir> Kyral: you have something like void foo(const char *bar) {char *baz = bar } in your code.
[11:19] <Mithrandir> (hence discarding "const" in the example)
[11:19] <ajmitch> LaserJock: dunno, I haven't tried building it or testing, etc
[11:19] <lifeless> does motus take care of multiverse too ?
[11:19] <ajmitch> LaserJock: and I see nothing new on REVU
[11:19] <ajmitch> lifeless: yep
[11:19] <Kyral> Mithrandir: its an assignment statement
[11:20] <LaserJock> ajmitch: you said earlier that it was FTBS
[11:21] <Kyral>  s = gtk_entry_get_text (GTK_ENTRY (entry_gs));
[11:22] <ajmitch> LaserJock: yes, mainly because libgtk2.0-dev might be missing some xdmcp dependency
[11:22] <ajmitch> or the pbuilder needs updated
[11:22] <Kyral> I don't see anyting wrong with the assignment
[11:22] <Kyral> then again I don't know what gtk_entry_get_text returns
[11:22] <LaserJock> ajmitch: it worked for me fine
[11:23] <Kyral> Okay...can someone who knows the GTK Libs look over this?
[11:26] <ajmitch> LaserJock: ok it built
[11:26] <Kyral> could someone who knows the GTK Libs look at http://revu.tauware.de/revu1-incoming/easychem-0512141655/easychem-0.6/dialogs.c lines 963 and tell me whats wrong there?
[11:27] <LaserJock> ajmitch: what about my use of PREFIX in the install rule in debian/rules. Is that not ok?
[11:27] <ajmitch> not really
[11:27] <buxy> ajmitch & sirestart: britney has an author however, and he still lives, so you can contact him (even on IRC)
[11:27] <ajmitch> it works
[11:28] <ajmitch> buxy: I know that..
[11:28] <desrt> Kyral; wrt. the comment?
[11:28] <Kyral> desrt: no the assignment near it
[11:28] <Kyral> s = whatever
[11:28] <desrt> looks fine to me.
[11:29] <Kyral> hmm, GCC is spittng out a warning
[11:29] <desrt> oh
[11:29] <desrt> s should be const char *
[11:29] <desrt> not char *
[11:29] <ajmitch> buxy: funnily enough I had even thought of asking someone about it, once I had looked at it a bit
[11:29] <Kyral> desrt: so in the declaration I should chanage it to const * gchar?
[11:29] <desrt> Kyral; yes
[11:30] <desrt> 'assignment discards qualifiers from pointer target type' ?
[11:30] <desrt> or some such?
[11:30] <Kyral> ah
[11:30] <Kyral> but what...if I change it to declare const
[11:30] <Kyral> then the = wouldn't work...
[11:31] <desrt> const char *s; means that the char that s points to is const
[11:31] <desrt> not s itself
[11:31] <desrt> that would be char * const s;
[11:31] <Kyral> so the = would be right?
[11:31] <desrt> yes.  assigning to a pointer of type (const char *) is fine.
[11:31] <ajmitch> Kyral: you're spending a lot of effort on this warning
[11:31] <Kyral> ajmitch: I wanna fix it :D
[11:32] <Kyral> so it will be accepted into Universe LD
[11:32] <Kyral> You called it to my attention so :D
[11:32] <desrt> what package is this?
[11:32] <Kyral> EasyChem
[11:32] <desrt> oh.  you're not talking to me :)
[11:33] <Kyral> builds fine, but ajmitch noted that the warning could be bad on AMD64
[11:33] <ajmitch> Kyral: it won't be
[11:33] <desrt> Kyral; it's a trivial warning in this case
[11:33] <ajmitch> I didn't really look at what the warning was
[11:33] <Kyral> ajmitch: then can you advocate so I can forget this thing for a while
[11:33] <desrt> Kyral; read the gettext() manpage for example
[11:33] <desrt> from gettext:
[11:33] <desrt> BUGS
[11:33] <desrt>        The  return type ought to be const char *, but is char * to avoid warn
[11:33] <desrt>        ings in C code predating ANSI C.
[11:34] <Mithrandir> Kyral: const vs non-const is just as harmful on i386 as on amd64.
[11:34] <desrt> gettext actively does exactly what that warning is warning you about :)
[11:34] <Kyral> someone just get me one more vote lol
[11:34] <desrt> (ie: using a 'char *' to store a const char pointer)
[11:35] <desrt> did keyboardcast get accepted yet?
[11:35] <desrt> crikey.  no.
[11:35] <desrt> advocate #1120, people :p
[11:37] <LaserJock> ajmitch: if you don't mind, could you briefly explain why my use of PREFIX was wrong? Do I need to modify the Makefile more?
[11:37] <Kyral> yah someone just please advocate EasyChem


[09:39] <rmg51> Morning
[12:09] <teddy-dbear> Morning peoples, dogs, turkeys, hamsters and everything else