=== Zic_ is now known as Zic [01:43] someone here know a document about tarball.mk on cdbs? [01:50] hi persia, can you open tasks in Bug #240549 ? [01:50] Launchpad bug 240549 in fetchmail "fetchmail denial of service CVE-2008-2711" [High,In progress] https://launchpad.net/bugs/240549 [01:50] Thanks [01:52] emgent: Yes, but it's *always* better to ask generally, rather tha poking a specific person :) [01:54] emgent: There's no nominations to approve? What needs doing? Which releases are affected? Please nominate some stuff, and ask someone to approve. [01:54] heheh ok persia sorry :P [01:54] persia: i cant nominate it. [01:54] ok done [01:55] launchpad timeout first.. now work fine [01:56] emgent: Great. Now check rmadison, and ask for approval in the right channel :) [01:56] * persia isn't core-dev [01:56] saw first to write debdiff [01:57] uok sorry, and thanks :) [03:44] running build_scripts [03:44] creating /tmp/buildd/twitteiro-1.1/build/scripts-2.5 [03:44] error: Is a directory [03:44] make: *** [python-build-stamp-2.5] Error 1 [03:44] someone can help me why this is happening? [04:07] Hello. Can anyone recommend to me some good resource for: packaging from a foreign (non Debian) source, and: working with a previous version of (ubuntu) sources in order to update it. [04:10] genii: What are you trying to do? Update an existing package from a new upstream source? [04:11] persia: I think that is what it amounts to. Specifically the pdfedit is at 0.3.2 currently for Hardy, want to package 0.4.1 [04:12] genii: OK. What's the current version in Debian? [04:12] unstable? [04:12] * persia points at packages.qa.debian.org as an easy way to dig up this sort of information [04:12] Ah, thanks [04:12] Unstable typically, but if your preferred version is in experimental, that can also be interesting. [04:13] Like the Chinese curse. [04:13] Latest in either case in 0.4.1-1 [04:13] *is [04:13] ScottK: Yes, well :) [04:14] genii: Great. Next check the current version in Ubuntu (https://launchpad.net/ubuntu/+source/pdfedit) [04:14] Can it be then backported? [04:14] !backports | genii [04:14] genii: If new updated Ubuntu packages are built for an application, then they may go into Ubuntu Backports. See https://help.ubuntu.com/community/UbuntuBackports - See also !packaging [04:15] genii: You've jumped ahead :) Yes, the next step is a backport: https://help.ubuntu.com/community/UbuntuBackports [04:16] genii: I hope you found that easier than trying to package it from scratch... [04:18] persia: 0.4.1 has not yet seemed to have made it from 8.10 to 8.04 yet through backports. [04:18] genii: Is there an open request yet? [04:19] persia: A user in #kubuntu was recommended to make one, unsure if it was done. [04:21] persia: If the scenario was only to have 0.4.1 in Hardy for myself, it would not be a large issue. The sources compile without incident. But then I embarked on a strange journey when trying to find how to package it for Launchpad. [04:21] genii: Have you looked at launchpad.net/hardy-backports/+bugs ? [04:22] I will look now. [04:22] genii: Understood. The idea is to reduce duplication of work, so everyone can share. [04:22] The difficulty is that there is a somewhat complex process involved to make sure that work isn't duplicated. [04:23] At the conclusion of your journey, you should expect that everyone who wants the updated version will be able to use it, as a result of your research. [04:25] persia: Looks like they made a request (with no reply as of yet) https://bugs.launchpad.net/hardy-backports/+bug/240427 [04:25] Launchpad bug 240427 in pdfedit "Please backport pdfedit v0.4.1 fom intrepid to hardy" [Undecided,Invalid] [04:26] genii: OK. I believe the next step is for someone to build the intrepid pdfedit on hardy, and report on their success. You'll need to use pbuilder or prevu for the build. [04:27] ScottK: Would it be acceptable to use sbuild or cowbuilder for a test build? If so, could the process page be updated? [04:28] genii: Given your previous effort to update the package, are you up for the test build? [04:28] persia: Yes. The page is written primarily for non-developers, so the more accessible tools are emphasized. [04:28] ScottK: OK. It just says "No other build methods will be accepted" in bold print, meaning I'm not likely to backport anything :) [04:29] persia: I might need to defer today, this is 14 hours now on the computer [04:29] genii: OK. To answer your original question, the easiest thing for you to do is to download the intrepid source and compile for hardy. [04:29] * ScottK looks at the page. [04:30] persia: I'm pretty sure that was meant to exclude checkinstall and friends. [04:30] persia: OK. With the pbuilder? [04:30] If you follow the backports process, and update the bug when you do so, anyone else interested in the updated pdfedit will be able to use the backport (after enough testers have confirmed it). [04:30] ScottK: I also. I'm just being (perhaps surprisingly) pedantic. [04:30] Sure. [04:30] genii: pbuilder would work (as would tomorrow if you want a break). [04:30] I'm the last one to be critical of pedantry. [04:31] persia: I'll try tomorrow when I log in from work in about 10 hours [04:31] * persia considers the value of lp.net/~ubuntu-pendants [04:31] persia: Should I come back here at that time? [04:31] genii: Thanks. Good luck with it. [04:32] genii: Come back if you have questions (or just idle to see answers to other people's questions). There's no requirement to be on IRC while you build or test pdfedit. [04:32] why are we talking about pedancy? [04:33] * genii sips coffee and looks for his Advils [04:33] nxvl: pedantry :) [04:33] oh yes [04:33] just a typo [04:33] i'm SO tired [04:33] nxvl: Capital 'W' :P [04:33] bimberi: huh? [04:34] nxvl: more pedantry ;) [04:34] in Why. Sorry, back to lurking and learning for me. [04:34] persia: OK, thanks for the tips.You'll see me tomorrow :) [04:35] genii: Probably not, as I hope to be asleep then, but someone else will be here. [04:35] Heh :) [04:35] persia: Fixed. [04:35] Later, gentle-people [04:35] * ScottK goes back to ordering groceries. [04:35] ScottK: Thanks. Now if only I wanted to edit a PDF today... [04:58] ScottK: proposal++ [05:26] ScottK: I think it's going to be a bit hard to bootstrap your new decision making process. [05:27] wgrant: How do you mean? (specifically, where is it likely to fail) [05:28] persia: Well, we've got to make a decision on a new way to make decisions, which will be hard enough that it can't be made at a meeting. [05:30] wgrant: Ah, right. I was thinking that it might be a sensible pilot of the new process to use the new process to decide if the new process should be used (mind you, I'm not sure the new process as written will be the new process, but haven't yet organised my objections) [05:40] persia: I think one needs to be awake to be able to make sense of what you just said. I did, but there are that many occurrances of "new process" that it could make people's head spin. :p [05:41] Pfft, only 5. [05:41] And at least they do all refer to the same thing. [05:41] Except one. [05:42] Right. Next time I'll use "foo" :) [05:42] lol === persia_ is now known as persia [06:42] good morning [07:02] good morning === LucidFox is now known as LucidFox_away === LucidFox_away is now known as StargateFox [08:09] <\sh> TheMuso: bug #239719 that's a totally new upstream version, or did I miss something from the debdiff? [08:09] Launchpad bug 239719 in youtranslate "[SRU] YouTranslate! in Gutsy and Hardy doesn't work." [Medium,New] https://launchpad.net/bugs/239719 [08:14] \sh: I didn't check the version number, as I was more concerned at first with the changelog and what was changed before checking the version, so once I find something, I don't usually progress further with reading the diff. [08:14] <\sh> TheMuso: I'll talk to siegfried about it... [08:15] \sh: Ok. === freeflyi1g is now known as freeflying [08:50] ScottK: I just prepared a draftt based on what we discussed yesterday: https://wiki.ubuntu.com/StableReleaseUpdates/Draft [08:51] Hello, how can I create a diff between 2 diff files ? [08:52] AnAnt: Interdiff is the program for that. Note that it can be confused by certain classes of patches. [08:53] DktrKranz: From my reading of the meeting log, it appeared that one criticism of the current policy was that it was established by MOTU SRU. While the draft looks reasonably clear to me, please be sure to arrange that it gets appropriate validation this time so that we don't have to question it again (and can instead discuss possible specific changes). [08:54] thanks [08:56] DktrKranz: Also, it's likely worth reviewing the specific language to make sure the filtered include at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification still works. [08:57] oh... really [08:59] Well, I presume so. Best to have testers and developers looking at the same thing. [09:04] how about a universe sponsoring 5-a-day? we have a lot of good stuff waiting for upload! https://bugs.launchpad.net/ubuntu/+bugs?field.subscriber=ubuntu-universe-sponsors [09:04] * dholbach processed a bunch of them today [09:05] Why 5? [09:05] do 10 if you like :) [09:05] 10-a-day-and-night ? [09:05] Koon: :-) [09:05] * persia prefers to look at clearing the queue, but admits it's currently a bit of a mess. === StargateFox is now known as LucidFox [09:06] do-as-much-as-you-can-a-day-but-please-more-than-five [09:07] persia: PerformingSRUVerification adjusted, thanks for noticing it [09:08] DktrKranz: Erm. Might not want to adjust the page until the draft is applied. [09:08] persia: it takes directly from StableReleaseUpdates, not from /Draft. [09:08] Ah. That's perfect then :) Ignore the last. [09:08] (and it appears like it will work with /Draft cleanly as well) [09:10] I didn't check, but I guess so, since I took tokens present in both pages [09:10] DktrKranz: I had guessed you had checked, as it works so cleanly. Lucky accident then :) [09:11] yes! [09:11] oh, this is cool: http://edos.debian.net/weather/ [09:13] DktrKranz: How hard would it be to port? Might be interesting as a means to attract attention to some of the porting architectures. [09:14] persia: it should be based on edos-debcheck, I think it doesn't require much work. I'll try to look if it's on Debian QA SVN already === RAOF_ is now known as RAOF [09:49] lo, i've been suggested this room for my question. when running dpkg-buildpackage on a project i get "dpkg-shlibdeps: failure: no dependency information found for" - anyone know where this is fixed ? i have a depends line in my debian/control file. [09:51] Doris: Sounds like you're depending on a broken library; the library package should be shipping a .shlibs file, which tells dpkg-shlibdeps what the dependencies should be. [09:56] persia: debian weather is not online, we asked zack if he could publish it somewhere, he'll do soon. So we can look at it :) [09:57] DktrKranz: Cool. I'm thinking it might be also interesting for the SRU crowd: watch the weather improve. Might also be a good metric for our release-readiness as we get to that part of the cycle. === asac_ is now known as asac [09:58] especially for lpia, since it is now an official port (if I'm not wrong) [09:59] I think lpia is in the same class as everything else on ports.ubuntu.com. [09:59] launchpad.net/ubuntu/intrepid states it's official [09:59] Of course, we can't quite compete with Debian (I expect the sysadmins would revolt if we tried to add that many m68k buildds) [10:01] DktrKranz: Interesting. Last I looked there was a lot of hackery involved in lpia. Getting that clean this cycle will be a bit of work. [10:01] raof, the one it depends on is one of mine too, so that's fixable. thanks. :) i take it this shlibs file normally lives in the debian dir too ? [10:01] what *IS* lpia? [10:01] i386 with even more added specialness. [10:01] persia: we lack real hardware to test, even if we have PPAs for test builds... but that's not enough :/ [10:01] directhex: Low Power Intel Architecture. It's things like the A110 and Atom. The IA is essentially IA-32, but there's a couple minor differences. [10:01] Doris: The debian library packaging guide should give specifics. dh_makeshlibs is probably what you want to look at. [10:02] Also, the toolchain is a little different, and optimised for a different usecase. [10:02] persia: Ah, so LPIA builds should be used on Atom? [10:02] kk thanks :) [10:02] persia, i was under the impression atom was a "normal" i386 [10:02] DktrKranz: At least you can buy it now. I have an A110 laptopishthingy [10:02] directhex: It's backwards compatible. [10:02] persia, why give one low-power x86 its own arch, but not another? [10:03] * DktrKranz should upgrade his hardware at some point... having a 9-year-old PC as primary box is not so cool [10:03] wgrant: For best performance, for some use cases. One might argue that one ought use amd64 on the Intel desktop series in the same way. [10:03] directhex: How do you mean? [10:03] persia: Does Atom do EMT64? [10:03] I recall is lacked either vmx or emt64. [10:03] wgrant: Nope. [10:04] Right. [10:04] It's also hardlocked for a maximum of 1GB RAM. [10:04] Ow. [10:04] The A110 shares those shortcomings, but still only gets me 3-hour battery life. [10:04] Hopefully the post-945 Atom chipset will improve on that... [10:05] The poulsbo stuff? Maybe. [10:06] . [10:06] persia, i'm failing to find a reference for how lpia differs from x86 [10:07] persia, if we're talking minor compiler flag details whilst it'll still run i386 executables (+ vice versa) then what's special about lpia compared to other needs-special-love x86, like via's CMOV-free C3 chips? [10:07] * wgrant is hoping to replace his home router/servery thing with something Diamondville-based at some point. [10:10] directhex: I don't have a good answer to that question. I do know that someone in #ubuntu-mobile was talking about trying to run lpia on a Geode earlier today (but haven't heard results). [10:11] Geodes are remarkably slow :( [10:11] wgrant, really? you REALLY think it's remarkable? i'd say it's depressingly expected, personally [10:12] wgrant: Well, depends on your definition. I've some slower processors around running linux if you want to have a comparison... [10:13] persia: ARMs, or some old x86? [10:13] wgrant: low-clock ARMs. Somewhere I have an old 486DX/50 tablet, but I've not tried to load Ubuntu on it. [10:15] The oldest thing I've run Linux on is our 486DX/50 laptop, and that was about 8 years ago. [10:16] i ran redhat on a cyrix dx2/66 once. the experience made me swear off linux for about 5 years [10:16] Actually, I might have installed something on our Cyrix 40MHz desktop before that, but I forget... [10:18] wgrant: Well, if you want to talk about history, I'll be able to trot out some ancient examples. [10:18] Bes current is the H340, which I believe is a 50MHz ARM [10:19] s/Bes/Slowest/ [10:19] linux on mp3 players isn't a good thing [10:20] directhex: Why not? How is it different than linux anywhere else? [10:20] Admittedly, 320x240 isn't much space, and input is limited, but... [10:20] persia, my player shipped with a terrible linux-based firmware. rockbox was a vast improvement [10:21] directhex: Isn't rockbox linux? [10:21] and the h3xx series have a <=140mhz coldfire chip. never running at that speed though [10:21] persia, absolutely not. it's their own kernel [10:21] Aha! [10:22] * persia is multiply enlightened, and clearly ought uninstall linux from that machine. [10:23] persia, http://www.rockbox.org/twiki/bin/view/Main/RockboxKernel [10:34] hi sylvaing :) [10:34] hi [10:35] lionel, ;-) [10:43] slomo_: you need to attach the debdiff to bug 239317 [10:43] Launchpad bug 239317 in thoggen "GST-Plugin Prevents use with Region 1 DVDs" [Undecided,New] https://launchpad.net/bugs/239317 [10:44] Riddell: done [10:46] now poke motu-sru :) === devfil_ is now known as devfil === LucidFox is now known as JapaneseFox [11:30] superm1: coreavc, a codec package without a codec? [11:34] superm1: "On Debian & Ubuntu systems, a complete copy of the LGPL v2 can be found under /usr/share/common-licenses/GPL-2" bad copy and paste? [11:36] superm1: is there anything from upstream which indicates the source is GPL? [11:38] superm1: are the patches for mplayer and xine used? if not how does this package get used? [12:12] Riddell, is it a debconf-powered package, like quake2-data or msttcorefonts? [12:12] directhex: doesn't seem to be [12:28] I'm getting a FTBFS when attempting to build the vegastrike package from sid. Builds fine on sid/hardy pbuilders but not in an intrepid one. Error: http://pastebin.ubuntu.com/20831/ [12:29] pythontastic [12:29] Quite [12:48] Any insights appreciated ;) [12:49] don't look at me, i handle monoish things [12:55] Laney: I guess I'd be looking at any Ubuntu differences in boost to see if anything looked like a likely culprit. [12:56] ScottK: I've looked at boost, and the same version is in Intrepid and Hardy. [12:56] (builds fine in Hardy) [12:56] Oh. [12:56] * ScottK dunno then. [12:56] * ScottK would guess somehow the new compiler flags are screwing with you, but has no idea how. [12:57] Laney: have you compared the version of boost-python (or how the package is called) in intrepid and sid? [12:59] geser: sid has -11 and intrepid has -4ubuntu3. But good idea, I'll check the BST [12:59] BTS === JapaneseFox is now known as LucidFox [13:02] Laney: I'm getting the same FTBFS with Miro, but I'm yet to really investimigate. [13:02] Laney: you might try if using the boost packages from Debian unstable inside your pbuilder helps (if they're installable), so you might know if you need to get boost merged first [13:04] RAOF: I'll let you know if I find anything out [13:04] geser: Will do, thanks [13:29] ahhhh [13:30] oops, wrong window [13:34] RAOF: Debian bug #468061 looks promising. Building boost ATM to test. [13:34] Debian bug 468061 in libboost-date-time-dev "libboost-date-time-dev: Breaks compilation of deluge-torrent with g++-4.3" [Important,Closed] http://bugs.debian.org/468061 [13:37] heya heya [13:37] Hurrah! norsetto's here. Everything will now be done in the next six hours :) [13:38] persia: are you still awake? [13:38] :D [13:38] persia: can I share your drink? Seems powerful [13:38] gaspa: Yes. I've a late meeting tonight. Tuesdays and Thursdays are the days I'm most likely to be around late. [13:39] * gaspa write down this sentence.. [13:39] persia: about nbs. you said that packages.u.c isn't reliable for that. What should i use instead, in your opinion? [13:41] gaspa: http://people.ubuntu.com/~ubuntu-archive/NBS/ [13:42] gaspa: The rmadison interface is fairly reliable. If you can't get that to work, you could ask LP, but there's no good API. [13:42] norsetto: yes, that's ok.... but i need sourcename, and some other infos. [13:42] persia: ok, i'll take a look [13:42] gaspa: You could also pull a packages file, but you'd need to pull for each architecture, which makes it a bit messy. [13:42] i see. [13:43] gaspa: Hmm. Looking again, it seems that rmadison doesn't support ports.ubuntu.com. If you could figure out how what is required, it'd be nifty (although only as an optional switch) [13:46] what about the output of "apt-cache madison "? it also lists the source package name (if one has a deb-src line) [13:49] geser: I don't want to depend totally on local sources.list. apt-cache could be a first approach to speed up the process. but i need also a static place(like packages.u.c, but more updated) where get infos. [13:50] for example, now, i do a local request to get sourcename, and if there isn't in apt-cache output, i fall back to packages.u.c [13:52] gaspa: what about wget the Sources.gz from archive.u.c and use grep-dctrl on it? or do you want additional dependencies for the script neither? [13:53] geser: not now... yes, it could be fine archive.u.c... [13:54] at least i could try and see if it's not too slow. [13:55] gaspa: as a.u.c is only updated hourly, you could refetch the Sources.gz only if they're missing or older than one hour [13:57] well... the nbs get refreshed every 6 hours, so a more fine timing is pretty unusefull. [14:04] geser, persia: just for curiosity, why 6 hours? [14:05] gaspa: That's the cron configuration for the script that generates them. [14:06] gaspa: whats your idea for the nbs? [14:07] norsetto: using a inverse approach, looking the package that depends on them... 'cause they're the ones that should be fixed. [14:07] norsetto: http://iogaspa.altervista.org/nbs/reversenbs.xml [14:09] persia: ok, i meant if there was a _particular_ reason... but don't mind. :) just curiosity [14:10] gaspa: Well, it used to be when we bothered the maintainer, so it went into daily cron. Then someone in Australia pointed out that running it at the beginning of the European workday wasn't ideal for their workflow, so it moved to 6 hours. [14:10] :D [14:10] If there are enough people chasing it quickly enough to justify more frequency, it could be arranged to be as often as hourly, but currently there isn't much value gained. [14:11] i agree. [14:15] norsetto: given your question, now i want feedback from you. [14:16] * norsetto gives feedback to gaspa [14:17] * gaspa gives thanks to norsetto [14:21] RAOF and geser: Updating to the sid version of boost fixed the FTBFS. Thanks for your help. [14:21] (I wonder if it's worth me doing the merge) [14:22] Laney: IMHO it doesn't make much sense to sync vegastrike now if it's know it will FTBFS until boost gets merged [14:22] If you package your Python application as a .deb package with debhelper, then you don't need a setup.py, right? [14:23] I mean, packaging with debhelper makes setup.py (and distutils) obsolete? [14:24] amikrop: not really, debhelper only helps you with common task during package building but it doesn't make distutils obsolete [14:25] geser: How setup.py (distutils) could be combined with debhelper? [14:25] amikrop: In your build rule call python setup.py build [14:25] isn't calling setup.py the equivalent of make install for a C program? [14:26] amikrop: In your install rule call python setup.py intall (and then there's an option to tell it where to install). [14:26] geser: Pretty much. [14:26] geser: Well, "setup.py build" is "make all", and "setup.py install" is "make install". [14:26] * persia notes that make does more than C [14:26] ScottK, geser: Aha. Right. [14:26] amikrop: if you don't need something special, package a python using distutils with cdbs should be quite easy [14:27] I see. [14:27] amikrop: If you want to use debhelper, stepic is a reasonable example. [14:27] ScottK: What is "stepic"? [14:28] geser: I meant the boost merge [14:28] amikrop: It's a python package that uses debhelper and distutils. https://launchpad.net/ubuntu/+source/stepic [14:29] ScottK: Cool, thanks. [14:31] ScottK: Actually, how I get the whole dir (with debian/ inside)? [14:32] apt-get source stepic or dget https://launchpad.net/ubuntu/hardy/+source/stepic/0.3-1/+files/stepic_0.3-1.dsc 0 I'd recommend the later if you don't have intrepid sources in your sources.list [14:35] ScottK: Actually, if I apply the .diff to .orig.tar.gz will I have the result? [14:36] If you have the source package and you want to unpack it, the best way to do it is dpkg-source -x filename.dsc [14:36] What is the compat file for? [14:37] I should have said dget -x above. That would have unpacked it too. [14:37] cyberix: It specifies the lowest major version of debhelper with which the package is compatible [14:37] cyberix: It says what Debian packaging compatibility level the package supports. It's roughly equivalent to the major version number of debhelper needed to build the package. [14:37] dholbach: i show your video on Friday before starting :D it was kewl [14:38] So why isn't build-dep enough? [14:38] ScottK: OK, thanks. [14:39] cyberix: Because using debhelper isn't actually required. Almost everyone does, but there are other ways to do it. [14:40] cyberix: Also because you might build-dep on debhelper 6 for some specific feature, but still have your debian/rules in debhelper 4 format (assuming you are sufficiently lazy, or just doing a quick patch to a package) [14:41] .oO( ScottK is already in T&S ) [14:41] POX_: I have also had to work on Manoj's packages, so I know debhelper isn't a requirement. [14:42] :) [14:48] http://launchpadlibrarian.net/15377022/buildlog_ubuntu-intrepid-i386.multisync0.90_0.92.0~svn355-1_FAILEDTOBUILD.txt.gz <-- looks like a Dependency problem, right? The package builds fine in my pbuilder so I guess it was a temporary problem [14:49] Kopfgeldjaeger: Maybe. Is your pbuilder up-to-date? [14:49] ok, in fact it doesn't work in my pbuilder [14:49] It worked before my pbuilder update... so there's a problem with an update [14:53] POX_: thanks for uploading pyelemental again [14:54] norsetto: I've changed debian/copyright a little bit before uploading [14:54] POX_: ok, I didn't see that [15:10] I have no idea, if my package would work with debhelper earlier than 5 [15:15] Heya gang === Guest6394 is now known as santiago-ve [15:20] Hi bddebian [15:21] Heya geser [15:24] geser: Sie moechten Ihre Zeit fuer Ihr Vermoegen anwenden? [15:24] geser: (no idea what that means) [15:25] * norsetto now also receives spam in german and russian [15:26] * jpds doesn't know the last two words in that sentence [15:26] actually that sentence is pretty wrong [15:26] norsetto: they want to use your time for your fortune. [15:26] grammarwise [15:27] apparently. [15:27] apachelogger: that's what i thought, too. [15:27] he, not only german spam, but also wrong german spam:-) [15:27] rofl [15:28] norsetto: show the wrong german spam :P [15:28] well, I spare you all the rest of the email [15:29] norsetto: forwand it to me =) [15:29] hm [15:29] thinking about it [15:29] sebner: you gonna get it anyhow, its spamming a whole bunch of ubuntu.com addresses [15:29] I think sebner is a mail address aggregator for spamm0rs :P [15:30] * sebner hides. they discovered his secret. He is the spamking and uses his adress/contacts to spam the whole world xD [15:31] norsetto: I just fixed the issues in mi2svg [15:31] cyberix: good, thanks [15:32] Riddell, its a codec wrapper [15:32] Riddell, like how wine is a windows binary loader [15:32] Riddell, the upstream website indicates it's GPL [15:32] Riddell, but its not in their .orig.tar.gz [15:32] it's on code.google.com [15:32] i filed a bug with them to include the GPL with orig.tar.gz [15:33] which should be documented in the debian/rules part that pulls it [15:34] norsetto: no problem, please point out any further problems [15:34] Riddell, and that -dev package is intended to be built against. after this gets pulled in i'll get patches set up appropriately for the other packages that can use it [15:49] superm1, you planning on patching myth et al with coreavc support then? [15:49] directhex, well i'm going to provide two libmyth-0.21's [15:49] one with coreavc support [15:49] one w/o [15:49] since upstream hasn't made it conditional to include it yet [15:51] the build process for doing it like this is a little annoying now [15:51] but i guess stuarta will have it as an option for 0.22 [16:14] join #freebsd [16:14] er === luisbg_ is now known as luisbg [16:52] i tried to upload a fonts package to my PPA, and i got the following message: Rejected: Unable to find distroseries: unstable [16:53] Ekushey: use intrepid instead of unstable in your changelog === _neversfelde is now known as neversfelde [16:54] Trying to use dpkg triggers. Figured out that I need a packages .triggers file. However, where do I put the action for the trigger? [16:54] in the postinst or preinst? [16:56] sebner, so i'll just have to replace unstable to intrepid and rebuild the package? is that all? [16:56] Ekushey: yep [16:57] thanks sebner [16:58] np [17:27] Hello. I was here yesterday, getting some insight into the backport process. In this case pdfedit current version in 8.10 back to 8.04. It was suggested to compile the Intrepid sources with pbuilder and test. I have the sources but am not certain what arguments to pass to pbuilder at this point. === thekorn_ is now known as thekorn [17:32] * genii puts on a pot of coffee [17:33] genii: You can build the intrepid version using prevu: https://wiki.ubuntu.com/Prevu [17:34] Laney: For Hardy? [17:34] genii: Yeah [17:34] * genii reads the wiki [17:44] How does prevu differ from using pbuilder? [17:46] Hm. Prevu is giving me "/home/user.pbuilderrc does not exist" ... will this cause any issue? [17:46] genii: No. [17:46] ScottK: OK [17:46] cody-somerville: prevu is a simplified wrapper around pbuilder for non-developers to test backports. [17:47] genii: That just means the default config in /etc gets used. [17:50] !prevu =) [17:50] Factoid prevu =) not found [17:50] !prevu [17:50] prevu is an automated, personal backporting utility. Check out https://wiki.ubuntu.com/Prevu for more details [17:50] ha [17:50] If I have already a deb-src for Intrepid in my sources will it get confused? [17:52] It shouldn't. [17:53] OK [17:55] <\sh> moins ScottK [17:56] heya \sh. [18:10] So how in the world do I accomplish this: binary packageA in a source package containing 10 packages needs to be triggered when any of the other binary packages change. [18:10] I've created debian/triggers, and set it to activate foo-update [18:10] and debian/packagea.triggers, and insured it was set to interest foo-update [18:11] And implemented code in packagea.postinst that detects if $1 is triggered, and does work. [18:11] The code in packagea is never executed, as far as I can tell, and nothing even tries to make it be. [18:12] And even if I slap it around enouhg, it does evenentually run the triggers.... but BEFORE some dependcies have been set up [18:14] when i try to apt-get install a package that i built, i get the "WARNING: The following packages cannot be authenticated!" message. how do i remove it? [18:16] Ekushey, have a signed repository, e.g. don't try to access your PPA directly [18:17] directhex, i'm very new to this, this is the first package that i uploaded to my PPA [18:18] downloading anything from PPA will give this warning? [18:18] Ekushey, PPA archives aren't signed. you need to mirror them elsewhere (and sign them in the process) to avoid the problem [18:20] ok, thanks... i need to study more about it [18:49] is there a way i can delete the amd64 build of a package from my PPA? [18:50] i don't think so. you can delete the entire source package & all binaries, though [18:54] directhex, so what i can do is change "Architecture: any" to "Architecture: i368" on the control file, rebuild and reupload to PPA? [18:56] yeah, that'd work. why're you hatin' on amd64 though? do real people really use i386 in this day & age? [18:57] directhex, this is the actual problem: https://launchpad.net/~ubuntu-bd/+archive/+builds?build_text=&build_state=failed [18:58] amd64 and lpia build failed, only i386 build worked [18:58] why is a font architecturey? O_o [18:58] surely ttf files are arch independent? [18:59] should be :) [19:00] "any" and "all" aren't the same thing [19:00] shouldn't it say "Architecture: all" so it's arch-independent? [19:00] yeah [19:00] "all" means a single _all.deb [19:00] "any" means a _i386.deb, _amd64.deb, _arm.deb and so on [19:00] oh... so that is the mistake that i did [19:01] i'm rebuilding it then [19:01] should i delete the current package from my ppa, or will it update itself when i reupload [19:02] * Ekushey is a 1-day old packager ;) [19:02] Increment the revision number and upload again will take care of it. [19:03] ScottK, i add it on the changelog? [19:04] Yes. Add a new debian/changelog entry with a higher revision number. [19:04] Use dch -i to get the initial template for the entry. [19:09] ScottK, the version number was 0.1-1, the new one is 0.1-1ubuntu1. is that OK? [19:10] Ekushey: I'd suggest 0.1-1ubuntu1~ppa1 [19:10] That way you can increment as needed (the ppaX part) without affecting 'real' revision numbers. [19:11] alright, thanks! [19:12] i'd suggest something alphabetically earlier than "ppa" [19:13] if you're building packages against hardy, then you want something alphabetically earlier than "hardy", to ensure official backport packages will supercede your ppa (e.g. an official backport of foopackage 0.3-2ubuntu1 to hardy will be numbered 0.3-2ubuntu1~hardy1) [19:15] directhex, so what should i put? [19:15] is there any wikipage explaining the versioning issues? [19:15] * ScottK agrees with directhex actually. [19:16] I actually use Xubuntu1~release1~ppa1 [19:16] Not a simple one. [19:18] so i should make it like 0.1-1ubuntu1~hardy1~ppa1? [19:19] Yes. That's better than my initial suggestion. [19:20] well it really depends on when you intend the package to be in use i think [19:21]