=== asac_ is now known as asac [01:34] can anyone point me to documentation about lpia? [01:34] ie what flags it uses, where it sets them [01:34] or is it some secret non documented process === santiago-pgsql is now known as santiago-ve [01:46] sharms, lpia is no longer a 'supported' architecture starting with karmic [01:48] superm1: yeah I just have a dell mini 9 with the default dell load, and I was trying to figure out exactly how lpia worked [01:48] unfortunately they didnt document almost anything about it [01:48] but dpkg-buildpackage should tell me what I need to know, its just disappointed [01:48] this stuff should be more open [01:50] sharms, i believe basically gcc should be preconfigured right if you install it [01:50] shouldn't need to worry too much about what flags are needed and what not [01:50] superm1: lpia has been dropped from support? [01:50] ajmitch, it's just chugging along in case its needed in the future [01:50] but no media will be generated from it i believe [01:50] there was a session at UDS to discuss this [01:51] which are the true 'supported' architectures now ? [01:51] superm1: it is important for me to know exactly how they compile packages. You would think somewhere on the wiki it would say 'For LPIA we use these compile flags: ' [01:51] and obviously the majority of us weren't at UDS nor do we have time to dig through 100+ wiki pages [01:51] ajmitch, i386, arm*, and amd64 [01:51] ppc chugs along on ports [01:51] i forget what the decision was about hppa and sparc though [01:52] "discussed at UDS" does irritate me at times for stuff that could be better communicated :) [01:52] where's Ncommander? thought he worked specifically on those arches [01:52] I agree, I wish the wiki was used a bit more [01:52] sharms, i'd apt-get source glibc and take a look at the flags that are applied in debian/rules [01:52] they should surely be there [01:52] sharms: this is the sort of thing that should have made it to ubuntu-devel-announce [01:52] or gcc - i'm not which is the main source package [01:52] ajmitch: it was sent to devel-announce, but had 0 details [01:53] ausimage, hrm? [01:53] lwn.net post also didnt have details, just people asking for details [01:53] and obviously no responses [01:53] lpia switches [01:53] lpia builds with -Os, and a set of tune flags which I don't remember off hand [01:53] sharms: I don't see anything beyond the "community-supported ARM release" on u-d-a [01:53] however, lpia is completely unsupported (and has never been recommended for general usage) [01:53] and hppa eol [01:53] NCommander: right but it shipped on my dell, so I have an interest in it [01:54] We decided at UDS to leave it building, but remove all kernels and such, so its effectively EOL [01:54] sharms, that's OSG ubuntu, and not consistant with the main archive [01:54] sharms, distribution upgrades and the like from machines pre-installed with ubuntu are not supported. [01:54] *OSG's [01:54] that's not correct - it depends on if there is a custom repo in place [01:54] ok maybe you don't understand. I am a developer. I write software. I am simply looking for information on the LPIA settings [01:55] the dell netbooks that ship intentionally have a custom repo, and upgrades aren't supported [01:55] I do not want support, just transparent development [01:55] get it? [01:55] any other dell machines that ship with ubuntu have standard repos and can do standard upgrades and what not [01:55] superm1, sharms, for lpia/hardy, then the only difference is we target i686 unless that was changed by OSG [01:55] superm1, then I'm mistaken. My bad. [01:55] superm1, but I thought dell shipped i386 on all machines that didn't have custom repos. [01:56] NCommander, which is true, and dist upgrades are supported just fine [01:56] superm1, right, my mistake. [01:56] sharms, what model of Dell machine do you have? [01:56] Dell Mini 9 [01:57] those definitely ship with lpia and custom repos [01:57] sharms, right, which runs a customized version of Ubuntu from Dell [01:57] again I dont want support, I just want to know what files where changed to enforce the LPIA compile settings on the distro [01:57] sharms, there is no change. Hardy i386 and lpia are identicial except the later builds against i686 [01:57] and that might not even be true for OSG's archives or hardy [01:57] and being that I see lpia-wrapper is in karmic, someone has to know what files those are [01:57] sharms, I wrote lpia-wrapper [01:57] sharms, it was an experiment in building the archive with -Os for karmic only. [01:58] So they named it lpia, but really its just Ubuntu i686? [01:59] sharms, no. Originally, lpia was to be optimized for the Intel atom processor, and was bootstrapped with the gutsy cycle [01:59] sharms, that never happened, so lpia and i386 are functionally equivelent [01:59] Except for minor incompatibilities caused by the lpia architecture string. [01:59] (aka, why you can't just install skype without playing on the command line) [02:00] sounds like a mess [02:00] ajmitch, s/sounds like/is/g [02:01] I appreciate the info, can you point me to what file stores the default DEB_BUILD_OPTIONS? [02:01] sharms, its in /usr/share/ somewhere, but there is no difference for lpia vs i386 [02:01] ha ok [02:02] so lpia was a vicious lie foisted upon us, and we can drop all those diffs that we carry for packages to make them build on lpia? [02:02] ajmitch, no, we need those still [02:03] ajmitch, that's the arch-string incompatibility I brought up before. [02:03] There isn't many of them left [02:04] I've been killing lpia-only diffs this go round as I get time [02:04] carrying deltas againt debian for an effectively EOL arch does cause some headaches :) [02:05] ajmitch, its not officially EOL until we kill the port outright, the problem is there is a chance we might actually need the lpia port in the semi-future, hence why it didn't get the ax along with the hppa port. [02:05] this is why I bitch about the lack of information beyond "We discussed it at UDS" :) [02:06] ajmitch, where was that said? [02:06] I havent heard any of this information except right here right now [02:06] no mailing list communication of it, nor wiki [02:06] what sharms just said [02:07] both you & superm1 replied with "We discussed" or "We decided" [02:07] not your fault, just that it hasn't got beyond that point [02:08] ajmitch, sharms, well, I won't speak for the Hardy/lpia used in the custom Dell repos. I know fairly little about it, so I'm not sure if everything I just said w.r.t. to compiler flags is revelent to it [02:08] But with Gutsy-Jaunty, lpia was essentially i386 Ubuntu compiled targetting i686 [02:09] NCommander: I'm not caring about the compiler flags, just about the arch being supported & something to care deeply about fixing breakage one [02:09] ajmitch, its never been supported in the main archive. [02:09] NCommander: with respect to Ubuntu, not Dell, Matthias Klose sent a mail to Ubuntu Announce about lpia specifically saying: "uses different optimizations options in the compiler, [02:10] different configuration and build options for some packages." [02:10] but with absolutely no details anywhere else [02:10] * ajmitch must have always got the wrong impression that it was then [02:10] ajmitch, the only reason its supported for PPAs is because you can easily virtualize i386 :-) [02:10] which makes it hard to get involved with understanding it, when the wiki has no info and the mailing lists turn up no results other than people guessing what they are, and some moblin guys suggesting what might be good flags [02:10] sharms, that was earlier this cycle, right? [02:10] I wouldnt know because further information isnt available except here on IRC :) [02:11] sharms, most people do development on i386 or amd64, so there isn't a lot of people who would be interested in the i386-lpia differences === mathiaz_ is now known as mathiaz [02:11] (or those people could be sadistic like me, and use an ia64 desktop) [02:11] right, but if I want to fix a bug, finding some kind of information would be great [02:11] NCommander: I don't envy your power bill [02:12] ajmitch, the same circuit also powers three sparcs, my laptop, three ARM boards, the powermac, a powerbook, a PReP PPC, the TV, and the XBox 360 [02:12] ajmitch, I'm kinda wondering if the next machine will finally blow the breaker. [02:12] 3-phase power? ;) [02:12] NCommander: and someone had to discuss compiler flags, build options and configurations somewhere. It just wasn't done anywhere in the open that people can reference [02:13] Klose didnt just go off as a lone cowboy and set all that up I am sure [02:13] ajmitch, the power bill isn't too bad. I make up for it in the heating costs of a weekend. [02:13] NCommander: if you know the right people to poke, get lpia renamed to lpia (unnofficial) on https://edge.launchpad.net/ubuntu/karmic [02:14] pages like that are what mislead me [02:14] ajmitch: it is only misleading because you didnt hear the uds discussion :) [02:14] ajmitch, that probably should also have armel as official :-/ [02:14] sharms: I obviously needed to stay up until 4AM to listen in on it :) [02:15] NCommander: if armel is official, then yes it should be :) [02:15] ha [02:15] * NCommander isn't even sure who can flip that switch [02:15] It requires a duck and that's all I know [02:15] sharms: UDS was about 10 or 11 hours behind my timezone, made listening in on anything a bit hard [02:15] Wouldn't signalling a port as official require it to be moved to a.u.c? [02:16] yeah it would be cool to see more blog entries etc about technical ideas [02:16] TheMuso, no, that's just for mirroring reasons. lpia has been marked official since hardy(?), and its on ports.u.c [02:16] so I can atleast google it [02:16] NCommander: oh right. [02:16] sharms, *cough* I have meant to send an email about that, but it slipped off my TODO list [02:17] NCommander: well the info is much appreciated, regardless of date presented :) [02:17] I probably need a RT ticket to get the (unofficial) flag changed [02:17] do the magic, I don't care how :) [02:18] wow, the last upload to dapper was more than two months ago [02:19] I guess the list of critical bugs to get fixed has shrunk a bit [02:19] apart from security stuff [02:20] ajmitch, in dapper? [02:20] do dapper-security uploads go through dapper-changes? [02:21] because I'm sure there have been things to get fixed in those 2 months [02:21] iirc, there is a bug that prevents -security uploads from going to -changes [02:21] right, so -changes is underrepresenting the number of uploads, no big problem === Guest54546 is now known as santiago-ve [03:18] IIRC it's a misfeature, not a bug but the result is the same. [03:56] hello everyone, newbiew here [03:56] I took a debian package and try to port it to ubuntu [03:56] indeed I put it at my ppa https://launchpad.net/~andphe/+archive/ppa [03:56] Andphe: What package? [03:57] v4l2ucp [03:57] right now I'm trying to add it a menu entry and a icon [03:57] I read doc about dh_installmenu, but not sure how to proceed [03:58] this is the rules file [03:58] http://paste.ubuntu.com/193158/ [03:58] I added the cp line to copy the icon [03:58] The package is already in Ubuntu in Karmic. [03:58] but not sure where to put the dh_installmenu [03:58] You might look at that version. [03:58] ScottK really ? [03:58] that is a great and bad news [03:59] v4l2ucp | 1.3-0ubuntu1 | karmic/universe | source, amd64, i386 [03:59] because the package is in karmic but I wasted my time [03:59] well [03:59] thank you [03:59] No problem. [03:59] I'll take a look [03:59] ;( [03:59] I'd guess you likely learned something in the process, so I doubt it was a waste. [03:59] * Andphe going to cry to another place [04:00] yep I learned something :) [04:00] figthing with the menu issue [04:00] thanks again [04:00] bye [04:00] Bye. [04:08] get back [04:09] the karmic one doesn't have a menu neither [04:09] nor a icon [04:14] Andphe: at least for gnome the menu item is .desktop file... and the format is fairly simple [04:15] ausimage: as I understand having a v4l2ucp.menu file the dh_installmenu helper would do the trick [04:15] right ? [04:15] having this rules file http://paste.ubuntu.com/193158/ [04:16] where should go the dh_installmenu line ? [04:16] not sure... but creating the a desktop file to be included is quite easy [04:16] I personally just place the desktop file where it is supposed to be [04:16] I see [04:17] though I am just learning all the ropes too :) [04:17] finally found a example [04:17] http://www.togaware.com/linux/survivor/rules.html [04:17] http://paste.ubuntu.com/193168/ <== my desktoop [04:17] * Andphe trying [04:17] Thanks for share [04:17] *er my desktop menu file... [04:18] yw [04:42] anyone know why dch is not picking up my version changes? [04:42] * ausimage thinks hand edits were far simpler to manage at this rate :/ [04:43] ausimage: dch edits the changelog, it doesn't look at diffs or anything [04:43] lifeless... I thought it would advance my versions automatically... [04:44] I am now stuck with a cli editor to write a new stanza... :( [04:45] should it not at least check the version info in the directory name itself? [04:46] no [04:46] you tell dch what you want it to do [04:46] dch --help [04:47] I looked... [04:47] :/ [04:47] could not tell which switch advances the versioning [04:48] a nice gui editor.... select copy paste click click done.... ;) [04:51] dch -i, dch --nmu, dch --qa will all advance the version [04:52] which does the app versioning? [04:52] ??? [04:53] the way I read the switches they only affected the package versioning [04:53] Unless it is a native package, of course [04:53] Upstream does the app versioning [04:53] I am the upstream... for the package... [04:54] Then you set the version :) [04:54] and when I use dch I would expect to see the version in the directory :/ [04:54] directory name [04:54] No, dch will never adjust an upsteam version [04:54] Nor does it change the dir name afaik [04:55] it did I think once for me [04:55] Well unless it is a native package I should say. [04:55] Was it a native package? [04:56] um that time it was I think... only cause it can't seem to realize the taz.gz is still in the parent dir :/ [04:58] bddebian and last few package turns I made with my package it has wanted me to -0ubuntu in addition to the orig for the tarball... [06:03] I was wondering if someone could tell me why my package builds on jaunty but not karmic... [06:03] it is in revu here http://revu.ubuntuwire.com/details.py?upid=6023 [06:04] I did nothing to the package 'cept change karmic to jaunty :/ [06:05] from my ppa log of the karmic build it claims a dir path is missing :/ from soovee-common [06:05] ausimage, Do you have a karmic buildlog? [06:06] https://edge.launchpad.net/~ausimage/+archive/soovee/+build/1069853/+files/buildlog_ubuntu-karmic-i386.soovee_1.07.2-0ubuntu-1~jaunty~ppa1_FAILEDTOBUILD.txt.gz [06:06] persia is that ok? === fabrice_sp_ is now known as fabrice_sp [06:07] dh_install: soovee-common missing files (debian/tmp/usr/lib/python2.6/dist-packages/soovee_app/pages/*), aborting [06:07] I guess Python in Karmic is putting them somewhere else [06:07] yup... but it does not complain about it with jaunty [06:07] oh ahh :/ [06:07] Hard coding python version is bad, too [06:07] You know, things are allowed to change from Jaunty to Karmic? [06:08] yeah... but I was not aware of what did [06:08] and I did not know how else to set the *.install lists [06:09] I think you'll want to play with dh_install --list-missing [06:09] * ausimage has already been accused of using a bigger tool than necessary when it comes to packaging ;) [06:09] Bigger *hammer* [06:09] with the changelog pointing at karmic ? [06:09] But you might also want to try to find someone who has experience splitting python packages: there may be an especially good way to do things in an automated fashion. [06:10] oh yeah that would be nice... [06:10] Doesn't matter what the changelog says. It matters what you build against. === MooKow is now known as LordKow [06:10] Also, you ought to delete debian/souvee.install: it's a useless file. [06:10] k that I can do... [06:11] changelog.sch.save looks like a leftover as well. [06:12] cleaned that up [06:14] dh 7 needs to support applying patches and then cdbs can completly die [06:14] persia it looks like dh_install needs me to build first :/ [06:14] StevenK, dh --with-quilt [06:15] cause it does not seem to find the dir eitherway... [06:15] ausimage, Just add --list-missing in your rules file, build, and examine the build log. [06:15] persia: ARGH [06:15] persia: But Quilt BURNS [06:15] StevenK: what don't you like about it? [06:15] StevenK, Then write a --with addon for your favorite patch system :p [06:15] ajmitch: It's a sledgehammer of a patch system [06:15] same thing persia... [06:16] And I invariably break my kneecaps while swinging it [06:16] ausimage, Yes, the error is expected. It's the other information in the log that will tell you what you aren't installing. [06:16] Having to quilt new ; quilt add ; edit ; quilt refresh ; quilt omg-it-hurts ... [06:17] You ought only need to push -a, add, pop -a. [06:17] If I'm modifying a patch that is at the top of the stack, yes [06:18] i thought install got its files after building :/ [06:18] It requires too much workflow to use effectively [06:19] Different definitions of "build". There's "build" in the sense of converting source into the target format (usually just copying stuff around for python), and "build" in the sense of creating binary packages. [06:19] StevenK, Then write more addons. It oughtn't be hard to create a dpatch add-on. simple-patchsys probably requires a bit more effort. [06:20] i think it is convert source into target part.... [06:20] What? [06:21] k that is wierd... i did a dpkg-build package with it set as karmic build and it built [06:22] though I know not to put weight in that [06:22] :S [06:24] I guess I need to ask another python packager for help on this.... [06:24] anyone know who qualifies? [06:24] StevenK, Debian bug #527255 probably contains sufficient guidance if you're actually going to do it... [06:24] Debian bug 527255 in debhelper "debhelper still needs manual modification in debian/rules to involve" [Wishlist,Closed] http://bugs.debian.org/527255 [06:27] persia it seems that pythoncentral might be borked :/ [06:27] it shows the files in lib.linux-i686-2.6lib.linux-i686-2.6 [06:28] i meant lib.linux-i686-2.6 not python-2.6 [06:30] * ausimage is overtired and might be reading that right :/ [06:31] ausimage, I can't tell you what is right, because I don't know. I can only point you at tools that can help you figure out what might be right. [06:32] ah sorry... [06:33] No need to be sorry. I just didn't want you to think I was ignoring you :) [06:34] good morning [06:38] hey dholbach ! Good morning [06:38] hi fabrice_sp [06:40] dholbach, did you see my answer in #384936? [06:40] bug #384936 [06:40] Launchpad bug 384936 in gmerlin "libgmerlin0 cause a coredump in new version of openmovieeditor because the lib package miss the plugins" [Undecided,Confirmed] https://launchpad.net/bugs/384936 [06:40] no not yet [06:40] ok [06:41] fabrice_sp: I hope the Debian maintainers adopt the change [06:41] nhandler: great work on getting the perl session on the schedule! [06:44] dholbach, we can wait, as I can't get the gmerlin-avdecoder merge sponsored, so no new openmovieeditor that will make use of that lib... :-( [06:44] morning dholbach [06:47] hiya ajmitch [06:51] dholbach: good mourning, when you have time, can we talk about bug #385066? [06:51] Launchpad bug 385066 in icon-slicer "Sync icon-slicer 0.3-2 (universe) from Debian unstable (main)." [Wishlist,New] https://launchpad.net/bugs/385066 [06:51] porthose: sure [06:52] I think the change in src/main.c should have been applied with a patch sytem [06:52] but it wasn [06:52] wasn't [06:53] porthose: icon-slicer doesn't use a patch system in Ubuntu right now, so it seems that the maintainer was happy to directly patch the source [06:54] * fabrice_sp remembers a similar discussion :-) [06:55] but I thought all changes outside of the debian directory should be applied with a patch system? [06:55] porthose: that depends on the preference of the maintainer [06:56] porthose: there are lots of packages that directly apply patches (especially native packages or packages that have the full source in a version control system) [06:57] ok, guess I need to do some more detective work, thanks ;-) [06:57] no worries [06:57] fabrice_sp: I'll take a look at gmerlin-avdecoder in a bit [06:57] (sorting out some other stuff right now) [06:58] porthose, that's quite easy to detect: just have a look at debian diff file. If it contans change to the source, no patch system needed :-) [06:58] that's what I am doing right now :) [06:58] may i ask an apt-mirror question? [06:59] fabrice_sp, porthose: or run "what-patch" from the ubuntu-dev-tools package :) [06:59] dholbach, thanks! :-) As it's a new package from Debian Multimedia, it's not so easy to find someone willing to look at it :-) [06:59] !ask | qiyong [06:59] qiyong: Please don't ask to ask a question, simply ask the question (all on ONE line, so others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) [07:00] how can I get apt-mirror to mirror two arch's ? [07:00] List them in the config file [07:00] set defaultarch i386 amd64 [07:00] ^doesn't work [07:01] set defaultarch i386, amd64 [07:01] ^neither [07:01] My apt-mirror manual page doesn't list defaultarch at all? [07:01] fabrice_sp, porthose: Note that debian/README.source, if present, should provide detailed advice on how a package is to be patched. Also, be aware that in some cases there will be a mix of patch systems and non-patch systems, for annoying reasons related to how the some of the patch systems work: in these cases, use the patch system if possible. [07:03] qiyong: http://ubuntuforums.org/archive/index.php/t-599479.html [07:04] persia, in general, I use the existing patch system (basically, if there is a patches directory in debian), otherwise, look at the diff file to see if some files has been modified [07:04] StevenK: so? [07:04] what is Nuku-Nuku? a bot? [07:05] fabrice_sp, In most cases, that ought work. [07:05] StevenK: i want to mirror both amd64 and i386 [07:05] qiyong: I refuse to spell it out for you, read the documentation. [07:06] fabrice_sp: yeah, it's a bot [07:06] StevenK: i get it :) [07:06] StevenK: deb-arch [07:07] Hobbsee, I can't seem to remember the right syntax. Can you make it go away again, unless you know it to be an approved bot? [07:09] persia: it's lucidfox's - the best way to get it gone is to probably request it not be here. I'm not sure why it's here to start with [07:10] Hobbsee, Oh, suddenly I have a reasonable path to solution. Thanks. [07:10] persia: you're welcome [07:10] I can't complain about a bot, given the somewhat indirect nature of my own access, but I do intend to complain about the annoying responses I get all the time. [07:12] persia: yeah, it certainly shouldn't be triggering on ! and should be changed. [07:13] or at least, if it wants to stay in ubuntu land [07:13] Right. non-triggering bots for various purposes (personal logging, intermediation of access, etc.) seem reasonable, so long as they are mostly indistinguishable from normal users. [07:14] Active bots seem to violate the "no bots" policy fairly clearly. [07:14] indeed. I think ! is the standard, so it's probably just an oversight. I'll point it out, or you're welcome to - you'll probably see LucidFox first [07:15] Perhaps. I'm at least motivated, as I've been becoming increasingly annoyed by that bot for the past several weeks. [07:17] so what are we talking about in here that has the screen all filled up? [07:18] fabrice_sp: is there a reason the debian-multimedia folks don't use those build-deps? [07:20] fabrice_sp: it ftbfs for me - I just added a comment to REVU [07:22] dholbach: Are you around? [07:23] Stupendoussteve: yes [07:24] dholbach, I'll check. Thanks [07:25] Oh: it FTBFS because of a change in karmic. I have to check the correct changes [07:26] dholbach: In your comment on bug #374350 you asked why I updated config.sub to 2008. I actually don't really know. That is to say, the a previous Ubuntu delta updates config.sub to a 2007 version without it being mentioned in any changelog [07:26] Launchpad bug 374350 in ssed "Please merge ssed 3.62-6.3 (universe) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/374350 [07:26] Stupendoussteve: some packages will automatically update config.{sub,guess} if available and that's fine [07:27] Stupendoussteve: I just wasn't sure if there was a reason why you mentioned it :) [07:27] ... if there was a specific reason [07:27] I see. Is it something that I shouldn't bother doing myself in a merge? [07:27] Stupendoussteve: if the package builds as expected without updating, I wouldn't bother [07:28] It's not usually done as part of a merge, although some packages auto-update at source-build time (which I personally find to be the *most* annoying of the three possible times to update) [07:28] I see, I'll remove that part when I work on the other changes [07:28] Stupendoussteve: let me know when you updated it and I'll take a look again [07:28] That package was confusing. If I used mergemaster the deb-ubuntu diff was 80KiB, but the diff from previous to new Ubuntu versions ended up being like 4KiB, something fishy [07:44] Erm, how do I stop the update-manager from popping out? [07:46] iulian: check release notes of jaunty [07:48] slytherin: Aha! Got it, thanks. [08:08] dholbach: Patch in bug #374350 looks better now [08:08] Launchpad bug 374350 in ssed "Please merge ssed 3.62-6.3 (universe) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/374350 [08:11] dholbach, gmerlin-avdecoder is in the NEW queue of Debian (http://ftp-master.debian.org/new/gmerlin-avdecoder_1.0.0-1.html). How long does it take to have it accepted? automatic merge would do the trick [08:12] (and by the way: debian added the same build dependency, except libmjpegtools :-) ) [08:13] fabrice_sp_: nice... no idea how long it will take, but I think it's fine to merge from NEW... or something [08:17] Stupendoussteve: good work - uploaded [08:17] NEW isn't public, so it's non-trivial to merge and guarantee matched orig.tar.gz [08:17] Better to wait until closer to DIF. [08:19] let's wait, then. It has been uploadded by the same guy as gmerlin, so I think it should go fast [08:20] 2 days ago [08:22] another question: when dealing with bug #383825, I found a FTBFS in koffice. Is it better to open a new bug report, attach the debdiff, and subscribe main sponsors?? [08:22] Launchpad bug 383825 in texlive-bin "[karmic] libpoppler4 -> libpoppler5 transition" [Undecided,Confirmed] https://launchpad.net/bugs/383825 [08:25] fabrice_sp_, If you can fix more than one thing in a single bug, that's a win. Save the bug numbers, as there is a limited supply. [08:26] persia, ok. I'll attach the debdiff to this one, then. Thanks for your answer! [08:26] fabrice_sp_, Thanks for fixing the bug :) [08:26] :-D [08:27] Don't forget to mention everything in the changelog entry though: the sponsors will be checking to make sure your changelog matches the changes, even if you fix a few extra bugs along the way. [08:34] sure === fabrice_sp_ is now known as fabrice_sp === cjwatson_ is now known as cjwatson [09:29] sharms: I don't know if it was explicitly stated by anyone in the discussion last night, but just to be clear, there's no "secret" buildd magic involved in lpia - it's entirely in packages, so for example you can just look at the gcc-4.3 etc. source package to see the default compiler flags. There is no default setting of DEB_BUILD_OPTIONS on lpia or any other architecture. [09:34] Well, there's DEB_BUILD_OPTIONS=parallel=n+1, but that's true for every architecture. [09:34] (and only on the buildds) [09:40] is this line ok in debian/install with debhelper >= 7: data/etc/ ./ [09:42] savvas, Yes, but it's awfully odd. What is it intended to do? [09:43] hm.. you're right [09:43] I guess conffiles should be better :) [09:43] savvas, What are you trying to accomplish? [09:44] I have some configuration files that need to be installed [09:44] * persia glares at "amd64 not in arch list: amd64 arm armel hppa i386 powerpc sparc kfreebsd-i386 kfreebsd-amd64 ppc64 lpia -- skipping" [09:44] http://paste.ubuntu.com/193311/ [09:45] savvas, You want "data/etc/* etc/" (assuming such a glob won't have false matches) [09:47] that's better, thanks! [09:47] er.. just for the record, debian/conffiles isn't the place for such files? [09:50] I generally don't put anything in debian/conffiles, and trust debhelper to just mark anything I stick in /etc as a conffile (although I forget which bit of magic does this) [09:51] I heard that too, thanks again :) [09:52] heard or saw, can't remember actually :P [09:52] Ah, it's dh_installdeb. "In V3 compatibility mode and higher, all files in the etc/ directory in a package will automatically be flagged as conffiles by this program, so there is no need to list them manually in package.conffiles." [09:58] debian/conffiles never caused files to be installed anyway [09:58] it simply flagged files that had already been installed by some other method [10:07] hi, does the MOTU mono team have a channel or shall I just ask here? [10:07] I am working with package of a mono app (iFolder) [10:07] and will need sponsoring from you guys [10:07] :) [10:08] to get it into Karmic [10:08] hi huayra [10:08] your best bet is #debian-mono on OFTC [10:08] if anyone here knows about mono apps package, please point me towards sn.exe [10:09] I thought debian used to hang @ freenode [10:09] they used to [10:09]