[00:00] goodhabit: I don't understand your question. [00:05] dpkg-source: warning: extracting unsigned source package (./wired-0.6.orig.tar.gz) [00:05] dpkg-source: error: syntax error in source control file ./wired-0.6.orig.tar.gz at line 1: line with unknown format (not field-colon-value) [00:05] What can I do with it? === santiago-php is now known as santiago-pgsql [00:31] ah that stinks bryce is not in here :\ [00:33] i wanted to talk to him about including my Xorg patch :D [00:34] and it needs to get in before freeze as it would create a new binary package off of the xorg-server source package [00:34] joejaxx: What does it do? [00:35] it gives us KDrive :D [00:35] I've seen that scroll past in the configure output, but what does it do? [00:35] it is tiny X [00:36] xserver* [00:36] a tiny* [00:36] Ok, that makes sense. Eventually :) [00:36] yeah [00:36] i am probably going to use it for fluxbuntu :) [00:36] i am using it now but i have not gotten xinerama to work correctly [00:38] What does the ordinary Xorg xserver have that XDrive doesn't? [01:41] Anyone got time for a review? http://revu.ubuntuwire.com/details.py?package=libopenfx === apachelogger__ is now known as apachelogger [02:21] Heya gang [02:21] hi bddebian [02:21] Yo bddebian [02:22] Hi LaserJock, RAOF [02:22] * pochu waves [02:22] Hi all [02:22] * ion_ is about to go to bed [02:23] I just took my first shot at shooting and tonemapping an HDR photo. :-) [02:23] (There’s a lot of room for improvement, of course) [02:30] Licensing sucks :( [02:31] eh? [02:31] Yep [02:32] As in: reviewing debian/copyright for packages on revu. [02:33] Depends on how much pleasure you take out of telling people, "Hey, you suck." [02:33] heh [02:34] ya gotta start somewhere, heh :-) === ember_ is now known as ember [03:23] Wow. Translating pypy is an excellent way to generate excessive system load. [03:23] heh [03:24] for me, apparently so is scrolling in a Web browser while using the "normal" compiz config. [03:24] yay, exa. [03:25] Gah, I don't know how to test this libapache2-mod-xmlrpc2 properly :-( [03:27] crimsun, i talked now with kees about ubuntu-hackers team === RAOF_ is now known as RAOF [03:27] emgent: ok [03:27] he will talk with infra team monday [03:27] and go to ufficializzation :) [03:27] emgent: excellent. [03:28] ^^ [03:28] ubuntu-hackers? [03:28] LaserJock, yep [03:28] https://edge.launchpad.net/~ubuntu-hackers [03:29] fascinating [03:29] yep :) [03:30] what kind of thing would the team even do? [03:30] Wow. Enough system load to cause irssi to timeout, apparently. [03:32] LaserJock, team for infra debug and ubuntu community (and not) system. [03:32] penetrations test, auditing and builting patch [03:32] hmm [03:33] only about infra system (webapps etc..). [03:34] "The team of hackers Ubuntu aims to take care of security problems in Ubuntu Services as Launchpad, REVU, Forums, website and other community systems. [03:34] The team will also aims to organise the "Ubuntu Hack Day", a day dedicated to hacking tests on the structures of the community with auditing and penetrations tests." [03:34] emgent: but is there enough need for a team? [03:34] yep, because now ubuntu-security and motu-swat work only for packages. [03:34] seems like encouraging a community infrastructure team that wrote/tested, etc. [03:35] this is a indipendent group (motu-swat branch) [03:35] kees thinks that. [03:35] Could we pick a different name though. Us honest hackers would rather that stereotype wasn't furthered. [03:35] yeah [03:35] uhm ok np. [03:35] * keescook really would like to avoid the "what does 'hacker'" mean situation. :P [03:35] I assumed it was a team *writing*, etc. for Ubuntu infra [03:36] monday kees will talk with infra team and council. [03:36] I would simply like to avoid confusion about the name, though.. [03:36] waiting him :P [03:36] I don't have a solution for the name part exactly, but it does seem like people interesting in _finding_ security issues in ubuntu need a place to coordinate [03:37] my initial suggestion is to just make it all motu-swat [03:37] hmm [03:37] that sounds feasible [03:37] since the audience of people interested in helping with security (either through fixes or through finding new issues) is somewhat small, I don't want to arbitrarily segment them up. :) [03:37] i think branch to motu-swat [03:38] regardless, the entire idea of performing "organized pentesting of Ubuntu infrastructure" needs some level of validation from the IS staff. :) [03:39] agreed. I'm frankly far more interested in app fuzzing. [03:39] solving the details of which team and what name is just a matter of making a judgement call everyone likes. [03:39] crimsun: yeah, I'd love to see more of that too. [03:39] crimsun: what is that again? [03:40] LaserJock: `apt-cache show fuzz` will give you some idea :-) [03:40] :) [03:41] * keescook wants to fuzz the X.org video drivers -- at least one issue in the past has come up in the nvidia driver [03:41] well keescook we will wait your news :P [03:42] emgent: cool. :) what do people think of having a recurring meeting for ubuntu security topics too? [03:42] we're starting to have enough different things going on that maybe we should try to coordinate a bit. [03:42] keescook, for me ok [03:43] keescook, date? :) [03:44] emgent: heh, I'm not sure. perhaps Wed? I will send email to the ubuntu-devel and ubuntu-hardened mailing lists when I get home tomorrow [03:44] send to me too. [03:44] in 26 and 27 i'm to Siena (Ubuntu italia meeting) [03:44] next week it's perfect [03:46] Wednesday it's ok for me [03:47] * keescook nods and crawls to bed for real now [03:48] lol [03:50] Anyone know why we have octave2.1-forge, but octave2.9-forge was recently removed? - \sh_away? [03:51] ScottK: I seem to remember some issue around the etch release that required both packages. I don't expect we still need octave2.1-forge at this point. [03:51] we're gonna remove both 2.1 and 2.9 when 3.0 gets in [03:51] Cool [03:52] I'm double checking [03:52] on \sh_away's affected package list for the transition. [04:00] hmm, it's too bad I know next to nothing about security :/ [04:00] in general I think QA and security to very interesting [04:00] *to be [04:00] LaserJock: No better way to learn than to help out fixing things. Reading CVEs can be very informative. [04:01] Reading CVEs tends to give a nice idea of what *not* to do. [04:01] StevenK: Depends on your goal :p [04:01] Heh [04:03] I did read up a bit while working on moodle MIR [04:04] it'd really be cool to have a resource for people writing our webapps, etc. to go to to make sure everything's tight [04:05] Rule 1: No PHP. [04:05] lol [04:05] :) [04:07] ah, easier said then done I'm afraid [04:07] there are so many goodies in PHP [04:08] All depends on your priorities. [04:08] and what you've got to work with [04:08] \sh_away: My review is complete. I found a couple of meta packages that need looking at, I think that was it. All added to the bug anyway. [04:09] LaserJock: You've got a lot to work with. It's FOSS. [04:09] well, when it's not my server it's a bit limiting [04:09] and when most of the good apps are PHP it's harder :/ [04:10] but I know what you mean [04:11] ScottK, LaserJock: I suspect octave2.9-forge was removed because it was removed in Debian testing/unstable. [04:12] That'd make sense. [04:12] I am trying to learn Ruby though so I have a bit more in my toolbox [04:12] ScottK, LaserJock: There doesn't seem to be an octave3.0-forge in sight, though. [04:12] Maybe it's all perfect now that 3.0 is out and no more extra goodies are needed? [04:12] LaserJock: BTW thanks for the mail reminder about \sh_away's work on octave3.0. I talked with him on IRC. [04:12] minghua: ok good, I was afraid maybe I was stepping on toes [04:13] I just wanted to make sure everybody was on the same page [04:13] There's a semi-automatic removal of anything removed from Debian that doesn't have rdepends or Ubuntu variation. I thought that was good, but it might also cause this type of issue: anyone have any ideas for noticing? [04:16] hi tuxmaniac [04:16] bug 186095 [04:16] Launchpad bug 186095 in ubuntu "hardware destroyed!" [Undecided,New] https://launchpad.net/bugs/186095 [04:17] brilliant! [04:17] * persia fondly remembers the IBM 5150 [04:17] Kewl. [04:17] LaserJock: Yeah, it was good, no toes stepped on. I talked with \sh_away _after_ getting your commenting on his bug. [04:20] LaserJock, [04:20] LaserJock, can you please review http://revu.tauware.de/details.py?package=alliance . I have been advertising from yesterday :-( [04:21] tuxmaniac: I'm trying but I have a full disk :( [04:21] bddebian, oh you are still around. :D [04:21] bddebian, its morning in India already :-) [04:26] OK, I have this: in a rules file that works on the command line but gives missing '))' on build. Any clues?? [04:26] echo Ion:ApiVersion=$$((cat /usr/include/ion3/version.h; echo ION_API_VE [04:26] RSION) \ [04:26] | cpp -P | tail -1 | sed 's/"//g') >>debian/mod-xinerama-for-ion [04:26] .substvars [04:26] Gah, sorry, bad pase [04:27] bddebian: Didn't we drop ion3 for licensing reasons? [04:27] Seems to be back afaict [04:27] Debian has a 20080103 or so version [04:28] aah looks like \sh_away has been going bizzerk with octave3.0 sync. Great to see and hope it gets into hardy! A wonderful milestone it shall be. [04:28] bddebian: My understanding is that the license for io3 requires distribution of the latest snapshot, which we can't support. Debian has it, but only because they have an RC bug preventing it reaching lenny. Ubuntu has no such mechanism. [04:28] s/io3/ion3/ [04:28] Ahhh [04:28] * bddebian thinks persia knows everything [04:29] * persia is certain that is a false statement, and is willing to provide mathematical proofs [04:29] Now go fix survex for me ;-P [04:29] * persia cringes [04:33] * persia wonders if there are any spelunkers about [04:36] Not me :) [04:39] Oooh, looks pypy has finished locking my box :) === RAOF_ is now known as RAOF [04:45] Is there one of the texlive psuedo packages that installs the texlive-lang-* packages or do I need to build-dep on each texlive-lang- ? [04:47] Ah, texlive-common? [04:48] well, texlive-lang-all [04:52] Is there any way I can see which package versions a particular Hardy alpha contained? [04:54] LucidFox: Your best chance is to download the CD, but many users call something "Alpha 2" when they have been doing daily updates. [04:59] And the alpha-2 label means nothing for universe anyway. [05:27] Lack of copyright headers in source files isn't grounds for rejection from NEW, as long as there's a statement that the software is licensed under the GPL, right? [05:30] RAOF: I believe in that case ~ubuntu-archive would *like* you to make sure of the terms of the license of the headers, but right, it's not deathly necessary [05:30] and not, IMO, cause for rejection [05:30] though of course I'd be the worst, most liberal archive admin in the world === santiago-pgsql is now known as santiago-ve [05:31] RAOF: Depends on the archive admin. There have been several rejections for that. Ask upstream to follow the instructions in the GPL about how to apply the GPL to their source first, and only push to the archive admins if upstream won't fix it. [05:32] Right. [05:35] If I wanted to get involved with the MOTU team, then would I need to set up a separate partition or make sweeping changes to my desktop system? I have been reading the MOTU documents, but I am still unclear what would be the physical requirements. [05:36] desertc: There are no physical requirements. [05:36] No, not really. There are a variety of tools for building packages in a clean system without actually having a clean system :) [05:37] It is strongly recommended that you set up either pbuilder or sbuild. pbuilder seems to want a fairly large /tmp, and sbuild wants it's own partition area (I set aside 19.99 GB for sbuild). [05:39] RAOF: There also has to be a full copy of the license in the tarball. [05:39] desertc, I personally feel pbuilder is better for a start. Since I am also in the beginning stages. [05:39] I see. Good to know. Setting up a partition would not be a big deal. I can always add another hard drive via USB. I just was picturing having to have 09.04 configured or something. [05:39] um 08.04 :) [05:39] ScottK: Yeah, it's got a copy of the GPLv2 in there, and it says that it's GPLv2 licensed. It's just that none of the source files have any copyright attribution at all. [05:40] desertc: Nope. There are MOTU who run Dapper or even Debian. [05:40] desertc, though I have not tried sbuild, pbuilder is a breeze to get started. [05:40] RAOF: You're probably OK then [05:40] I will take a look at pbuilder and idle here. Hope to get a handle on how to help soon. [05:40] RAOF: copyright attribution is different than licensing. It is acceptable for the collective work to be under a collective copyright (although discouraged), but doing that doesn't match the instructions in the GPL for licensing. [05:41] desertc: My main desktop is still dapper. I've got servers on Gutsy and (until tomorrow - the last one dies - Feist), a Gutsy laptop and an Edgy install on my wife's laptop. [05:41] desertc: What interests you? A common way to get started is to look at problems with software you use or like, and try to get them resolved. [05:41] ScottK: Wanna help me close the ITP, then? :) [05:41] RAOF: It's late and I'm going to bed. [05:41] Good night all. [05:41] Fair enough. Sleep well! [05:42] Gnight ScottK [05:43] desertc, most of the info you might need are there here https://wiki.ubuntu.com/PbuilderHowto with respect to pbuilder [05:43] tuxmaniac: thanks for the link :) [05:44] * persia notes that the official buildds run sbuild, and points at https://help.ubuntu.com/community/SbuildLVMHowto [05:45] persia, thanks. I think I shall try that out on my home machine. [05:45] How much space (est) does pbuilder require? [05:45] * RAOF notes that sbuild-on-lvm can also be quite a lot faster than pbuilder. [05:45] or sbuild [05:45] desertc: Lots less. Something like 50MB per chroot tarball. [05:46] And then a variable ammount of space while building. [05:46] Err. pbuild requires lots less. sbuild-on-lvm requires 4-5GB per chroot + 4-5GB per simultaneous build. [05:47] Is sbuild is recreating the environment of the entire OS? And pbuilder is just for the individual package? [05:47] (taking a guess here) [05:48] They're both doing the same thing, but different technical means. [05:48] Similar things. They are only about as close as apt-get and aptitude. Each has a few unique features, and the codebases are different. [05:48] pbuilder creates a minimal ubuntu system then tars it up. Each time it builds, it unpacks that tarball under /tmp and then chroots into it. [05:50] sbuild-on-lvm has a separate lvm logical volume containing the minimal system, then uses snapshots to build in. The reason why each lv has to be big is so that you've got enough space to install the build-dependencies & build the package. [05:50] hmm! thanks for the explanation! [05:51] If you choose pbuilder, be sure to either have a fair amount of space available on /tmp, or if using tmpfs, a large swap partition. [05:52] can I have two pbuilder chroot tar? since I am on a limited bandwidth, its not simple to clean up everytime I build a different package. I mean two pbuilder ch tar for the same dist? [05:53] You should be able to have a local apt cache, which will do what you want. [05:53] I forget if pbuilder is set up to do that out of the box. [05:53] tuxmaniac: Both pbuilder and sbuild clean up after each build. You want a local mirror (or cache) to not download everything with each build. [05:54] That would be --aptcache option, or APTCACHE variable in pbuilderrc. [05:55] I have a CS background, but I've not put any of it to use since college. I was thinking I might like to start working toward programming linux code, and I thought this might be a good way to get started on that path. I also have work training in QA, so I think I can be pretty handy. [05:56] Most importantly, I have a lot of control over my time these days, which is awesome. :) [05:56] There's really not that much programming involved in MOTU work. [05:56] desertc: MOTU only very rarely actually touches the linux package :) [05:56] At least, the actual *packaging* part. [05:56] It will help me work toward it, by giving me a better understanding of the Ubuntu system. [05:56] RAOF: Depends. There can be for bugfixing, or library porting (and we can always use more library porters) [05:56] The bug finding/fixing, yes. [05:57] You don't want me programming anything right now anyway. I probably would have trouble with helloworld() at this point. [05:57] In that case, bugfixing may well be a nice gentle reintroduction :) [05:58] desertc, I get memory leaks with my hello world sometimes [05:58] :D [05:58] :) I was leading QA efforts for a popular open source project a short while ago, and I am burnt out from dealing with developers. ;) [06:00] All features and no bug fixes. Made me understand the importance of groups that hold the projects together at a high level, like the Ubuntu Project. :) [06:01] Or did you mean actually making the programmatic changes myself, RAOF? Hmm! Interesting idea. [06:01] Okay, sorry to take over the conversation, I'll keep looking at pbuilder and sbuild. [06:01] desertc: Oh, yes. Making the changes yourself. [06:02] It's quite a different skill to be able to dive into some totally unfamiliar code and find the bug :) [06:06] Anyone want to close an ITP? http://tinyurl.com/2249zg for the DDs among us. [06:06] RAOF: What does it break? Should it really be priority "extra"? [06:07] * persia is not a DD, but picky about priority extra [06:08] * RAOF *always* forgets priority :( [06:08] Thanks. [06:09] Okay - this will sound a bit noobish, but what does an Ubuntu programmer program? Aren't Ubuntu packages derived from Debian, for the most part? [06:09] I suppose there is the installation and the upgrade software.. [06:09] desertc: It's mostly maintenance coding. Looking through code from upstream or from Debian and fixing bugs or improving integration. [06:09] Ah, gotcha. Thanks [06:10] Most fixes end up being patches that go to Debian or to Upstream, and are dropped in the next release. [06:12] In MOTU work, you do a bit of compiling with the package source, right? [06:13] sorry - I should read and not keep asking questions that I can find myself :-) === Hobbsee_ is now known as LongPointyStick === Hobbsee_ is now known as LongPointyStick [07:02] * RAOF hit's miro again, in the hope that it'll work if you give it a kick. [07:02] * RAOF is taken away by the society against cruelty to apostrophes. [07:03] * persia hands RAOF a white coat and a clipboard as defence against arbitrary societies [07:06] * Hobbsee hides in the white padded room, to avoid wor [07:06] k [07:07] * persia hands Hobbsee a white jacket with long sleeves and extra straps [07:08] * Hobbsee gets out her whip [07:08] woe betide anyone who decides to do *anything* stuipd tonight. [07:12] !channels [07:12] A list of official Ubuntu IRC channels, as well as IRC clients for Ubuntu, can be found at https://help.ubuntu.com/community/InternetRelayChat - For a general list of !freenode channels, see http://freenode.net/faq.shtml#channellist - See also !Guidelines [07:51] tjaalton: Re: the java X bug. Is it confirmed fixed for gcj & icedtea? [07:52] Hmph. [07:53] cln jumped from using cln-config to using pkg-config. [08:02] * persia wonders if anyone ever grabbed the first 38 libldap rdepends [08:04] persia: I thought you had 19 of them? [08:05] StevenK: I did 19, and you did 19, but I thought there were 78 or so in total. Do I misremember? [08:05] persia: For universe it was only 58 or so [08:05] I have 2 left, I think [08:06] I have 3 that didn't work smoothly. I was just considering pushing the simple cases in "" - haskel if nobody else had yet. [08:11] Hello all [08:14] Miro taunts me with new boost dependencies. I shall set it on fire! [08:22] How many libtorrents are there? [08:28] RAOF: I think there should only be three [08:29] Ah. Which one is Miro embedding now... [08:33] persia: I'm not sure, haven't tried myself [08:35] tjaalton: I'm just wondering if it's only a hypothetical closure. I haven't encountered the issue, but it would be unfortunate if it still existed for new hardy installs using icedtea. [08:35] (or openJDK, but I don't expect that to be ready for hardy) [08:36] Right. It's not the libtorrent that we have in our archives, anyway. === civija_ is now known as civija [08:42] persia: the upstream bug says that it's fixed, but doesn't mention the version [08:43] tjaalton: Hmmm. I don't expect our X to need any further modification, but just wondered if our Java did. Maybe all is good (and maybe soon we can drop the sun java blobs) [08:43] we can't touch them, so it just needs to be mentioned on the release notes.. [08:44] tjaalton: We can't touch the sun-* blobs, but we can touch icedtea, which is why I mention it at all. [08:44] oh right [08:44] Most things that work with sun-* should work with icedtea, and we should be patching icedtea like anything else in universe to demonstrate good practice, and encourage more open java. [08:45] I believe it's fixed there already, someone just needs to test it :) [08:49] Accursed script kiddies! Stop hitting my password-disabled ssh server, damn you! [08:54] tjaalton: Do you have any good test case? Testing first against gcj, I don't seem to have a jconsole binary, and don't understand fcitx well enough to be comfortable breaking my scim. [08:54] try eclipse [08:55] first check that /etc/eclipse/java_home has gcj/icedtea on top [08:57] tjaalton: I don't have any Sun-* installed. Shouldn't it do the right thing without any conffile mangling? [08:57] * minghua is awaken by the mentioning of scim. [08:57] persia: yep [08:58] minghua: We're discussing bug #87947. Not really a scim thing. [08:58] Launchpad bug 87947 in libx11 "xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed." [Medium,Fix released] https://launchpad.net/bugs/87947 [08:58] it's just that one of the test cases uses fcitx [08:58] Heh, xcb issues. [08:59] tjaalton: If the bug exists, eclipse should crash on first run? [08:59] * persia tries installing Sun Java to see if it breaks eclipse [08:59] persia, tjaalton: I don't think 87947 is in any way related to input methods. [09:00] persia: I think so.. [09:00] minghua: I agree. It's just that I didn't want to mess with my scim configuration, so wanted another test case [09:01] persia, tjaalton: Sun Java is known to be (or have been) broken with xcb. Old Xorg used to have problem with xcb for input methods, but as the bug states, it has been fixed. [09:01] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6532373 [09:01] that's the upstream bug [09:01] gone -> [09:02] Actually, scim used to break with xcb as well. [09:02] tjaalton: eclipse doesn't seem to show it either with or without sun-java. [09:02] * minghua once got a bug about this, but Xorg maintainers took it back after a few days and eventually fixed it. [09:04] minghua: Does icedtea fix the problem with sun java? I've never encountered the bug, and so have a hard time testing to see if it is fixed. [09:05] * persia doesn't like telling users "it's a problem with non-free software" when there is a free software replacement available. [09:05] persia: I've never encountered it either. [09:05] tjaalton: Could you please find a test case, and verify whether it was fixed or not? I'm happy to help test. [09:05] So hardy has xcb enabled now? I didn't notice any difference. [09:11] Does anyone know why python-profiler is in multiverse? [09:12] There's a licensing issue in linking gpl code with openssl, isn't there? Do I remember that correctly? [09:13] * minghua hopes not. [09:13] GPL code linked with openSSL is downright non-distributable. [09:14] RAOF: The GPL code needs to offer a specific exception to allow linking against OpenSSL, if I remember correctly. [09:14] Yes, that was what I was afraid of. [09:14] Well, it seems miro is now undistributable. [09:17] RAOF: You could patch it to not link against SSL for now. It's not a problem to distribute source. [09:17] persia: Non-DFSG-free restrictions for the python-profiler case, it seems: http://mail.python.org/pipermail/python-dev/2005-February/051450.html [09:18] minghua: OK. That makes sense. Thanks. [09:18] * persia is trying to reduce multiverse usage === Ubulette_ is now known as Ubulette [09:55] Anyone have any hints for injecting a local package into an sbuild session? [09:56] persia: sbuild takes .dsc files [09:57] persia: or what do you mean with injecting? Installing it in the chroot rather than building it? [09:57] azeem: Right. I have two packages. One build-depends on the other. I could use a local archive of a PPA, but would like to just be able to tell sbuild I want this specific local package also installed in the chroot. [09:57] ah [09:57] s/of a PPA/or a PPA/ [09:57] that's not so trivial I think, yeah [09:57] I usually install it manually in the chroot [09:57] azeem: In the base chroot? Doesn't that affect your future builds? [09:58] well, and try to remember to remove it again afterwards ;) [09:58] deborphan is good for that [09:58] hrm [09:58] azeem: install/purge cycles are supposed to be clean, but aren't always :( Be careful with that. [09:59] persia: well ok, but it's no different to installing any other build-depens, that can potentionally happen all the time [09:59] azeem: Depends on how you use sbuild. I always use it in a snapshot LVM volume, which I discard after each build. [10:01] persia: Can't you login into your LVM snapshot chroot then? [10:01] minghua: That's my workaround for now, but as I'm setup to discard chroots after use, I end up using debuild, which doesn't keep the logs in the same place. I was hoping for something simple (and should probably be using a local archive) [10:03] yeah, I guess a local archive is the easiest then [10:03] Well, a PPA is easier, but the latency from here to there makes downloading annoying. [10:04] persia: Make a PPA mirror! :-) [10:05] minghua: Now there's an idea I never imagined promoted. [10:16] folks i've got a small app up for revu if someone else would like to take a glance: http://revu.tauware.de/details.py?package=project-x === Ibalon is now known as zakame [10:21] Hello ppl; I have cleared the last stoppers from pochu on http://revu.tauware.de/details.py?package=falconpl [10:22] I think it should be clean now. Is there someone willing to have a look? === Hobbsee_ is now known as LongPointyStick === LongPointyStick is now known as Hobbsee [11:08] Hi can a REVU admin resync REVU uploaders keyring? [11:09] Coper: starting now. Takes about 20 minutes. [11:09] persia: okej, thanks [11:12] Hello. I am newbie. Can somebody teach me how to make packages (allready done with google, with ubuntu links). Just advice me how to solve some troubles. [11:12] ? [11:13] habit_: describe your troubles, and maybe somebody will be able to help you [11:17] I have done with dependencies, with dev packages needed for compilation, so, 'make' works fine and create binaries. 2nd step I have opened ubuntu packaging manual. At the begining as I understood I need to do 'dpgk -x source_tarball.tar.gz [11:18] Oups, mistake, dpkg-source -x [11:18] habit_: That's not quite how I'd start. [11:19] If you have a working upstream that compiles from source, the first step is usually tar xzf upstream-tarball [11:19] But dpkg-source returns an error. [11:19] dpkg-source acts on Debian source archives, not random upstream tarballs [11:21] Then, move the upstream tarball to $(package)_$(version).orig.tar.gz and change the directory name to $(package)-$(version). Create a "debian" directory in the new working directory, and add your control, copyright, and rules file. Step down one directory, and create your copyright file with dch. [11:21] At this point, `debuild -S -sa` should generate you a source package, which you could later use with dpkg-source -x [11:23] One question - i didn't understood what actually I must do with 'tar xzf' [11:23] habit_: Unpack the upstream tarball [11:26] Guys, I'm sorry for maybe very stupid questions, but I'm totally newbie with computers :) So 1. I must unpack sources, create there 'debian' directory with needed description files and then I must run @ that directory (root unpacked sources directory I mean) 'debuild -S -sa' [11:26] Right? [11:27] habit_: Yes. You also have to make sure to rename the upstream tarball and unpack directory. [11:28] persia, the renaming is for later making "right-way tarball"? So I can just delete original tarball? [11:28] Now I have wired-0.6 wired_0.6.orig.tar.gz wired_0.6.tar.gz directory and files. [11:29] habit_: No. debuild expects you to be in a directory named $(package)-$(version), and may behave oddly if you are not. It also expects the upstream tarball to be in the parent directory and named $(package)_$(version).orig.tar.gz, and will likely be unable to build a source package if it is missing (or may build a native package, but that isn't what you want). [11:30] Ah. Yes. You want wired-0.6 and wired_0.6.orig.tar.gz. You don't need wired_0.6.tar.gz [11:31] What files I must put into DEBIAN folder? [11:32] That is part of the binary package, and will be generated from the contents of the debian/ directory in the source package. [11:33] Now I have wired_0.6 wired_0.6.orig.tar.gz . Wired_0.6 - is unpacked wired_0.6.orig.tar.gz, but with debian folder into them. [11:33] Right? [11:35] habit_: Right. When you make the source, you will also get wired_0.6-0ubuntu1.diff.gz and wired_0.6-0ubuntu1.dsc. [11:36] Make the source mean 'cd wired_0.6 && debuild -S -sa' [11:36] ? [11:37] habit_: You might want to run `dget http://launchpadlibrarian.net/10123377/wired_0.5.1%2Bdfsg2-0tsmithe3.dsc` to see previous packaging work on wired, and contact Toby to collaborate. [11:37] habit_: Yes. That would be making the source. [11:37] One more question. What files must contain DEBIAN directory? [11:38] AH, sorry ) [11:38] Just saw your link. [11:39] habit_: Note that wired is a fairly complex package, as it incorporates all of a library, an application, and some plugins. You might want to try packaging something simpler to become familiar with the process first. [11:40] Actually I think I will not familiar never with it :) [11:40] As I think that it for "power users" and developers. [11:40] I am only normal user.. [11:40] Whatewer ) [11:45] persia, cannot find toby's contact. dget doesn't work also. [11:45] How I can search it? [11:45] habit_: check the changelog [11:46] Grr. I thought dget was supposed to work with launchpad now :( [11:46] woops [11:47] habit_: dget http://ppa.launchpad.net/tsmithe/ubuntu/pool/universe/w/wired/wired_0.5.1+dfsg2-0tsmithe3.dsc [11:48] Now I must make debian folder like @ that file and do 'cd wired_0.6 && debuild -S -sa' yep? [11:48] I think I'm really annoing :( [11:48] But if I will take it once, I'll help next newbie :) [11:49] habit_: https://wiki.ubuntu.com/PackagingGuide/Recipes/PackageUpdate may be helpful [11:51] persia: BTW, debian policy suggests now to use '~' in version names [11:52] rzr: In what context? ~ has been supported for a while. Is there a new update to policy including that? Are they now supposd to be used more often? [11:53] I saw that days ago in /usr/share/doc/debian-policy/changelog.gz [11:53] * Bug fix: "[PROPOSAL] Document ~ behavior in version numbers", thanks [11:53] to Nicolas FranÃ§ois and Marc Brockschmidt (Closes: #382612). [11:54] It's just an update to policy to reflect existing usage of ~. [11:54] rzr: Right. '~' has been there for a while. 3.7.3.0 finally included documentation of this behaviour. Next question: did I tell you something this contradicts? [11:55] persia: I have still problems with getting a email with my password in REVU. [11:55] Coper: REVU doesn't send emails with passwords. Have you uploaded anything? [11:56] persia: i dont think so this makes me think we you pasted the wired dsc [11:56] Yes I think everything is uploaded. [11:57] rzr: Ah. Yes. That package wasn't ready for the archives. I just thought it would be a good reference for habit when trying to start out, as it at least included the package split correctly, and handled a lot of the DFSG removals. [11:57] (and was the same upstream) [12:00] When I try to recover password for my email, REVU says that there is no account. And my fil is not listed on the site. [12:01] Coper: Which package did you upload? [12:01] console-freecell [12:02] smater: dcut doesn't work on REVU. Just wait 10 minutes and upload again. [12:03] Coper: Get your password from http://revu.ubuntuwire.com/lostpw.py?email=lars@dunemark.se and look at your package from http://revu.ubuntuwire.com/details.py?package=console-freecell [12:05] dcut is a Debian-ism [12:05] It doesn't work for Ubuntu either [12:06] StevenK: Maybe someone could patch dput to not tell the user to use it? [12:06] persia: Maybe one could use it to sharpen their Python skills? :-) [12:07] * persia goes to look at dput... [12:07] * StevenK chuckles [12:07] persia: I've got patches in dput, so if you want to run stuff past me, sure [12:07] persia: okej, the problem was that I was looking at http://revu.tauware.de/ [12:07] Coper: Same site. Same code. Different name. [12:07] (same data too) [12:07]