| === fta_ is now known as fta | ||
| === RAOF__ is now known as RAOF | ||
| james_w | hi serialorder | 01:11 |
|---|---|---|
| ryanakca | Could one make a package such that for foobar-a , patch_1.diff is applied, but for foobar-b, patch_1.diff isn't? | 01:36 |
| serialorder | hi james | 01:38 |
| james_w | ryanakca: foobar-a and foobar-b are binary packages? | 01:39 |
| ryanakca | james_w: *nod* | 01:41 |
| RAOF | It'll need some makefile trickery, and you'll obviously need to build the source twice, but it's possible. | 01:41 |
| ryanakca | RAOF: thanks | 01:42 |
| RAOF | The last thing I touched that did something similar was making libasound2-plugins build 32 & 64 | 01:43 |
| RAOF | bit binary packages on the appropriate archs. That's not a good example, though, because there's all sorts of madness that's specific to biarch builds. | 01:43 |
| ryanakca | RAOF: Thanks :) | 01:44 |
| === jtechidna is now known as JontheEchidna | ||
| === nellery_ is now known as nellery | ||
| Laibsch | good morning | 06:30 |
| Laibsch | I am trying to get http://mentors.debian.net/debian/pool/main/g/gourmet/gourmet_0.14.2-1.dsc into shape for inclusion. I think it is almost there, except for one thing; "E: gourmet: file-directly-in-usr-share usr/share/gourmet-0.14.2.egg-info" | 06:31 |
| Laibsch | http://wiki.debian.org/DebianPythonFAQ suggested to pass the option "--single-version-externally-managed" to the "setup.py install" call, but that did not work out "error: option --single-version-externally-managed not recognized" | 06:31 |
| Laibsch | Any suggestions? | 06:31 |
| Laibsch | james_w: Sorry for the late response. Did you have a chance to push those wordpress changes. If it helps, I can still prepare an intrepid debdiff. | 06:32 |
| dholbach | good morning | 06:34 |
| Hobbsee | morning horsemen | 06:36 |
| dholbach | hi Hobbsee | 06:36 |
| awmcclain | Anyone know of a way to cache your GnuPG passphrase without using Seahorse? | 07:09 |
| Hobbsee | pinentry-gtk2? | 07:10 |
| siretart | gnupg-agent? | 07:10 |
| awmcclain | Thank you! | 07:12 |
| awmcclain | Is there any way to give (pre-cache) my passphrase to gpg-agent before it's actually asked? | 07:21 |
| Hobbsee | is there any good reason to do so? | 07:27 |
| awmcclain | Hobbsee: I'm using autoppa to upload the ~30 packages I maintain, and it dies if you need to enter a passphrase. :( | 07:29 |
| Hobbsee | awmcclain: well, you can't put it in a textfile, and get it to read that. | 07:30 |
| Hobbsee | therefore, you're going to have to physically type it in once anyway. | 07:30 |
| awmcclain | Hobbsee: That's fine. I just want to be able to have gpg-agent cache it _before_ I run autoppa. | 07:31 |
| Hobbsee | consequently, the suggestion would be that you debsign a .dsc file manually (or something similar), then run autoppa afterwards, when it should still be cached. | 07:31 |
| awmcclain | Hobbsee: Perfect. I need to brush up on the individual deb helpers. I couldn't remember which would prompt me for a signature. | 07:32 |
| Hobbsee | awmcclain: ah, cool. | 07:32 |
| awmcclain | Just want to prime the pump. | 07:32 |
| awmcclain | Well, crap. debuild --no-tgz-check -S is still prompting for a passphrase. | 07:38 |
| jmarsden | awmcclain: debuild -S -uc -us | 08:00 |
| awmcclain | jmarsden: But that doesn't launch debsign? | 08:02 |
| jmarsden | Right, I thought you didn't want to sign the package? | 08:02 |
| Hobbsee | jdong: ping? | 08:02 |
| awmcclain | jmarsden: No, I'm trying to sign it, but using the cached key in gpg-agent. I think the problem is that debsign isn't configured to use gpg-agent. | 08:03 |
| === dholbach_ is now known as dholbach | ||
| awmcclain | (Really, I'm trying to get autoppa not to break) | 08:03 |
| jmarsden | Are signed packages required for PPA upload? if not, then not signing them should avoid all passphrases and thereby achieve your goal.\ | 08:04 |
| awmcclain | jmarsden: They are, unfortunately. :-| | 08:05 |
| Hobbsee | jmarsden: they are, for very good reasons. | 08:06 |
| jmarsden | OK. I've always signed mine, but I've never had a need to automate PPA upload either, I'm not that prolific. | 08:07 |
| awmcclain | Hobbsee: Very good, yes. Unfortunately for me, I should say. | 08:08 |
| === dmb is now known as Guest88424 | ||
| Hobbsee | awmcclain: well, i'm sure someone can upload a whole bunch of packages, doing various things, under your name, instead, if you really wish :P | 08:08 |
| awmcclain | Hobbsee: No thanks! I'd rather just get my gpg caching working. :D | 08:09 |
| Hobbsee | haha ;) | 08:09 |
| * Hobbsee wonders where all the crackporters are. | 08:09 | |
| Hobbsee | really odd, to not even have *one* around | 08:10 |
| awmcclain | Hrm. Slowly making progress. The real issue is that I'm doing all this just on a console. | 08:16 |
| awmcclain | Is pinentry a GUI thing? Seems like it depends on QT or GTK. | 08:22 |
| Hobbsee | it used to have a console based one,iirc. | 08:24 |
| james_w | morning all | 08:32 |
| james_w | Laibsch: I haven't yet, sorry. I'll look at it this morning. | 08:32 |
| Laibsch | great, thanks | 08:32 |
| Laibsch | let me know if there is anything I can do to help | 08:32 |
| === fta_ is now known as fta | ||
| james_w | slytherin: around? | 10:59 |
| james_w | slytherin: for lucene, does having that patch break anything? | 11:00 |
| slytherin | james_w: I wonder if that patch will apply at all. If it does, it will not break anything, simply bypass a unit test. | 11:02 |
| james_w | k | 11:02 |
| slytherin | james_w: I think it is better to wait till I file a bug. Just today lucene2 in Debian got updated to use libdb4.6-java as build and runtime dependency. | 11:06 |
| james_w | ok. I'll wait | 11:07 |
| === echidnaman is now known as JontheEchidna | ||
| savvas | does anyone have a source of an debian package that uses svn-buildpackage ? | 13:32 |
| white | savvas: foo2zjs | 13:34 |
| white | savvas: svn.debian.org/svn/foo2zjs | 13:36 |
| savvas | thanks white :) | 13:38 |
| slytherin | savvas: I believe any packages that is team maintained in some svn (pkg-java, pkg-mono) can be build using svn-buildpackage. | 13:45 |
| savvas | slytherin: I'm actually reading about frostwire, since their code is in svn | 13:47 |
| savvas | some say there's a problem with some libraries, but I don't know what | 13:48 |
| lfaraone | How long does it take after I dput for somethign to get to REVU? | 14:00 |
| === txwikinger2 is now known as txwikinger | ||
| james_w | Laibsch: hi, still around? | 15:11 |
| Laibsch | yes | 15:11 |
| Laibsch | any trouble? | 15:11 |
| ScottK | lfaraone: I think around 10 minutes. | 15:12 |
| james_w | Laibsch: sorry for the delay, I'm on it now | 15:12 |
| james_w | Laibsch: would you update the description of the bug as described in the SRU page? | 15:13 |
| james_w | !sru | 15:13 |
| ubottu | Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates | 15:13 |
| Laibsch | james_w: Are you referring to "Procedure - section 2.1 to 2.5"? | 15:19 |
| Laibsch | I think all the points there were covered in the bug, although there is not one nice, single paragraph to point to | 15:19 |
| Laibsch | I can add that if that is what you are looking for | 15:19 |
| james_w | yeah, please edit the description, it helps the SRU teams a lot | 15:19 |
| geser | Hi bddebian! | 15:22 |
| bddebian | Heya gang | 15:23 |
| bddebian | Hi geser | 15:23 |
| sebner | hi bddebian | 15:23 |
| sebner | geser: you also plan a multi vote like persia? ^^ | 15:24 |
| bddebian | Hi sebner | 15:24 |
| Laibsch | james_w: take a look | 15:33 |
| Laibsch | I think it should be a good balance between verbose and concise | 15:34 |
| james_w | Laibsch: the dev branch thing means jaunty, not upstream | 15:34 |
| Laibsch | Oh, I see | 15:34 |
| james_w | I believe this was folded in to the merge for Jaunty, correct? | 15:34 |
| Laibsch | yes | 15:35 |
| james_w | Laibsch: diffs attached to the bug for your review | 15:44 |
| didrocks | james_w: (hi) I have a question about your last mail | 15:46 |
| james_w | hi didrocks | 15:46 |
| didrocks | james_w: does the "dpkg-statoverride call" has to be in the init script? | 15:47 |
| geser | sebner: first I need to read my collect mails from today | 15:47 |
| james_w | didrocks: that's kind of my question | 15:47 |
| sebner | geser: heh =) | 15:47 |
| didrocks | james_w: from what I understand (but I maybe wrong), it's just for replacing the "chmod 777", right? | 15:48 |
| didrocks | (and as the init script is launched as root, this is possible) | 15:48 |
| james_w | I'm not sure what you mean | 15:48 |
| didrocks | james_w: sorry, trying again : the best pratice is to used dpkg-statoverride in the init script, instead of using chmod/chown option to enable everyone to write in /var/run | 15:49 |
| Laibsch | james_w: Looks good, the date in the hardy patch is Nov 14th, but I guess that is rather irrelevant | 15:49 |
| Laibsch | thanks for the clean-up | 15:50 |
| savvas | Does anyone know a cdbs package that compiles using ant and ant.mk ? I'd like to see an example | 15:50 |
| james_w | didrocks: ah, no, dpkg-statoverride allows the admin to tell packages not to chown/chmod certain files/directories. The init scripts I have seen that chmod/chown do not respect this. | 15:51 |
| james_w | Laibsch: cool, thanks, I'll upload | 15:51 |
| didrocks | james_w: but in this case, I do not understand how, after a reboot, the right directory in /var/run is still writable for everyone | 15:52 |
| james_w | why should they be writeable to everyone? | 15:53 |
| didrocks | I was thinking you were talking about this case (when chown/chmod was needed in init script) | 15:54 |
| didrocks | but that was because I didn't understand the dpkg-statoverride use | 15:54 |
| didrocks | so, now, I think it's ok :) | 15:54 |
| didrocks | thanks a lot james_w. Will look closely at the discussion about this point :) | 15:55 |
| === thekorn_ is now known as thekorn | ||
| iulian | Heya | 17:11 |
| james_w | directhex: hey, you about? | 17:24 |
| james_w | directhex: I've cot a bit of confusion with gmcs on ia64, and I would like you to tell me how it should look so I know what is broken | 17:25 |
| james_w | directhex: mono-gmcs doesn't seem to contain gmcs, but it's an Arch: all package. | 17:31 |
| sebner | james_w: afaik mono-gmcs contains gmcs1. gmcs2 is in mono-devel | 17:32 |
| james_w | I don't know how much to trust the Contents.gz, but they differ across arches | 17:33 |
| james_w | ia64 has gmcs2 in mono-gmcs and gmcs in mono-devel it seems | 17:33 |
| sebner | O_o | 17:34 |
| james_w | with gmcs in mono-gmcs and no mono-devel on i386 | 17:34 |
| sebner | james_w: well, at least I had to install mono-devel so monodevelop alpha2 configure finds gmcs | 17:34 |
| sebner | on i386 | 17:34 |
| james_w | this package may have built either side of mono2.0 being uploaded | 17:35 |
| === mcasadevall is now known as NCommander | ||
| jdong | wow, network-manager sets up ad-hoc NATs. | 17:58 |
| jdong | I didn't know that. | 17:58 |
| slytherin | jdong: As per my observation, the only thing that NM doesn't manage is firewire point to point network. | 17:59 |
| jdong | never tried that before, so I can't say. | 18:02 |
| jdong | I did find it a bit counterintuitive that "Set up wireless network" defaults to setting up a NAT | 18:02 |
| jdong | although the functionality is nice, I would've liked it to be a bit more clear that's what it does. | 18:02 |
| Tetracomm | Hello. | 18:11 |
| Tetracomm | Does anyone know if checkinstall packages will ever become acceptable? | 18:11 |
| sebner | Tetracomm: never ever ;) | 18:12 |
| guille_ | hi all | 18:13 |
| slytherin | Tetracomm: without changes? no. | 18:13 |
| guille_ | does exist a mail list for packages? | 18:13 |
| slytherin | guille_: hi | 18:13 |
| slytherin | guille_: what kind of mailing list? | 18:13 |
| guille_ | not sure what kind. actually i'm trying to build mysql with sphinxse (an storage engine) an package it; but no way to do it. i would like to ask people who knows | 18:14 |
| slytherin | guille_: Considering that mysql is in main, you will have better luck if you ask on #ubuntu-devel channel. | 18:16 |
| guille_ | slytherin: ok, thank you | 18:17 |
| Tetracomm | Something needs to be done about the overcomplicated package creation process. | 18:29 |
| jdong | what is overcomplicated? | 18:30 |
| slytherin | Tetracomm: what is overcomplicated? | 18:30 |
| * lamont grumbles at jpds | 18:30 | |
| Tetracomm | The package creation process. | 18:30 |
| Tetracomm | It is too difficult. | 18:31 |
| jdong | can you be more specific? | 18:31 |
| jdong | what part(s) did you find to be difficult? | 18:31 |
| broonie | You may want to use CDBS or similar if you're packaging something noddy enough. | 18:31 |
| lamont | jpds: if you wanna send me your nmap diff, it'll probably get uploaded and synced faster | 18:33 |
| slytherin | geser: any idea if java packages will ever need ${shlibs:Depends}, ${misc:Depends} ? | 19:09 |
| leslieviljoen | hey ppl! I was wondering: are packages "owned" by certain motu's? I reported a certain bug almost a year ago, including a patch. Today I mailed the Debian maintainer and he said he'd never seen it. Who's supposed to inform upstream? | 19:20 |
| azeem | the Debian maintainer is not necessarily upstream | 19:21 |
| slytherin | leslieviljoen: No. Packages are now owned by certain motu's. It has some advantages and at least one disadvantage that you mentioned. | 19:21 |
| azeem | well, depends on what you're talking about | 19:21 |
| leslieviljoen | in this case, the Debian maintainer was upstream | 19:22 |
| leslieviljoen | so is there a way of finding out if anyone is attending to something? do the devs handle bugs randomly? | 19:23 |
| geser | slytherin: I assume that dh_shlibdeps won't work for java packages, so ${shlib:Depends} is useless here, but one could perhaps use ${misc:Depends} for automagic dependencies on jars in other packages (if it's somehow possible to discover the dependencies) | 19:23 |
| geser | leslieviljoen: you might look at the "also notified" list but that is no guarantee that those people are really interested in the package | 19:25 |
| slytherin | geser: I guess jaranalyzer is supposed to determine dependencies. Never actually used it though. | 19:25 |
| leslieviljoen | so they are handled on a "I'm interested in that" basis? | 19:26 |
| leslieviljoen | So it comes down to this: I'm interested in fixing certain things, and I'm capable of doing it, I just don't know how to get my fixes into the repos. At least not in under a year. | 19:28 |
| leslieviljoen | What should I do? | 19:29 |
| lamont | leslieviljoen: patches sent to the bug report tend to get attention faster than bugs with no patches | 19:30 |
| leslieviljoen | Well look here: https://bugs.launchpad.net/wajig/+bug/174261 | 19:32 |
| ubottu | Ubuntu bug 174261 in wajig "auto-install ignores noauth option" [Undecided,New] | 19:32 |
| leslieviljoen | It's a tiny problem but I fixed it almost a year ago. Upstream hasn't even heard of it yet. | 19:33 |
| leslieviljoen | (well they did today) | 19:33 |
| leslieviljoen | I made that fix to release a script that can find regressions in desktop packages: that script was a response to another bug I reported | 19:34 |
| leslieviljoen | so there seems to be a break-down in the link between launchpad and upstream - if there is any link | 19:36 |
| leslieviljoen | is there any reason not to report bugs directly upstream as opposed to launchpad? | 19:56 |
| geser | yes, as Ubuntu patches some packages/software a bug might be because of that patching so upstream can't really do anything about it | 19:57 |
| geser | and for the users it's easier to report bug reports at one place | 19:58 |
| geser | the downside is that we don't have enough manpower to distribute those bug reports to the different upstreams (after checking if it's really an upstream bug) | 19:58 |
| leslieviljoen | but I can easily check that | 20:01 |
| leslieviljoen | maybe I should become a motu | 20:01 |
| leslieviljoen | I just don't have consistent stretches of time | 20:01 |
| slytherin | leslieviljoen: that shouldn't stop you from trying | 20:02 |
| leslieviljoen | don't the motu's have set responsibilities? | 20:02 |
| leslieviljoen | ie. don't you need a certain minimum consistent amount of time to contribute? | 20:03 |
| directhex | if the patch is NOT in the packaging, then i'd STRONGLY recommend you file the bug upstream *yourself* and link the bug in launchpad | 20:03 |
| directhex | because chinese whispers are bad - you'd do a much better job of communicating the problem & answering questions than having a packager relay your issue without neccessarily fully understanding the issue | 20:03 |
| james_w | directhex: hey, did you see my question earlier? | 20:05 |
| === santiago-pgsql is now known as Guest31387 | ||
| james_w | directhex: it boiled down to which package is now supposed to ship /usr/bin/gmcs? | 20:05 |
| leslieviljoen | directhex: thanks for the advice. the problem is very rarely in the packaging though. | 20:06 |
| directhex | james_w, no, i didn't, sorry. things were exploding at work | 20:06 |
| james_w | directhex: no problem, it's not urgent | 20:06 |
| === Guest31387 is now known as santiago-ve | ||
| directhex | james_w, we now ship 'generic' scripts in mono-devel - which means things like "sn" (as opposed to sh1 for .net 1, sn2 for .net 2), "al" (as opposed to... blah blah). and gmcs comes into that category | 20:07 |
| geser | leslieviljoen: MOTUs contributing in their free time, so its up to everyone how much time he's ready to spend (no commitments) | 20:08 |
| james_w | directhex: aha, so a package that wants to use gmcs should B-D on mono-devel, rather than mono-gmcs? | 20:08 |
| directhex | james_w, if you're asking due to a build dep, then the advice is to actually override the compiler you use to force 'csc', which is a debian-specific script pointing to the default c# compiler, which is gmcs for now (but might go back to being mcs in the future - upstream were talking about merging them) | 20:08 |
| directhex | james_w, http://wiki.debian.org/Teams/DebianMonoGroup/Mono20Transition#head-67c13a005dab7f510b0fd1ee8db7a30689e89669 | 20:09 |
| james_w | directhex: nice, thanks. I'll work on that part and then consult you about anything else needed for the transition. | 20:09 |
| directhex | james_w, yes, please don't hesitate to ask | 20:09 |
| directhex | james_w, 2.0 passed debian NEW literally 150 minutes ago, so the transition is entering full swing there too. in experimental,mind | 20:11 |
| serialorder | i am working on a merge and the ubuntu version used automake 1.10.1 while the new debian version uses 1.10 this leads to a few extra things in the Makefile.in, which version should I keep? | 20:12 |
| directhex | (ubuntu is still newer though, 2.0.1-0ubuntu2 > 2.0-1. 2.0.1-0ubuntu2 is being referred to as 2.0.1-1~pre3 in private repo; ~pre4 exists but has a bugfix which does not affect buildds) | 20:13 |
| leslieviljoen | ok, will read up on how to motu, thanks chaps | 20:14 |
| directhex | leslieviljoen, if you're interested in a specific package, also worth considering is helping ubuntu by helping debian - especially if the package version is a debian version (i.e. nobody from ubuntu has made ubuntu changes) or a 0ubuntuX (ubuntu has a newer version than debian), then helping debian helps BOTH distros, as well as hundreds of debian-based distros | 20:17 |
| slytherin | serialorder: what are those extra things? | 20:19 |
| serialorder | there are three | 20:21 |
| serialorder | <<<<<<< dasher-4.7.0-0ubuntu2 (ubuntu) | 20:21 |
| serialorder | # 2003, 2004, 2005, 2006, 2007, 2008 Free Software Foundation, Inc. | 20:21 |
| serialorder | ======= | 20:21 |
| serialorder | # 2003, 2004, 2005, 2006 Free Software Foundation, Inc. | 20:21 |
| serialorder | >>>>>>> dasher-4.7.3-1 (debian) | 20:21 |
| serialorder | <<<<<<< dasher-4.7.0-0ubuntu2 (ubuntu) | 20:21 |
| serialorder | DSYMUTIL = @DSYMUTIL@ | 20:21 |
| serialorder | ======= | 20:21 |
| serialorder | >>>>>>> dasher-4.7.3-1 (debian) | 20:21 |
| serialorder | <<<<<<< dasher-4.7.0-0ubuntu2 (ubuntu) | 20:21 |
| serialorder | MSGFMT_OPTS = @MSGFMT_OPTS@ | 20:21 |
| serialorder | MSGMERGE = @MSGMERGE@ | 20:21 |
| serialorder | NMEDIT = @NMEDIT@ | 20:21 |
| serialorder | ======= | 20:21 |
| directhex | blurp | 20:21 |
| serialorder | MSGFMT_OPTS = @MSGFMT_OPTS@ | 20:21 |
| serialorder | >>>>>>> dasher-4.7.3-1 (debian) | 20:21 |
| leslieviljoen | is there any ubuntu team that just browses the bugs and reports them upstream if need be? Is that triaging? | 20:22 |
| superm1 | !pastebin | serialorder | 20:22 |
| ubottu | serialorder: pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic) | 20:22 |
| leslieviljoen | I am re-reporting my launchpad bugs in debian right now. | 20:22 |
| slytherin | leleobhz: yes, there is bug-squad. there channel is #ubuntu-nugs | 20:26 |
| slytherin | serialorder: please use pastebin for pasting anything more than two lines. | 20:26 |
| slytherin | serialorder: The difference look unnecessary to me unless they were done intentionally. | 20:27 |
| serialorder | sorry guys, didnt know | 20:27 |
| superm1 | that reminds me... is there a nice GUI tool for handling when this 3 way merge stuff gets spewed into one file? meld works wonders on a 3 way diff with 3 files | 20:31 |
| serialorder | slythering that is what i was thinking, there is nothing in the changelog to indicate it was intentional | 20:31 |
| slytherin | serialorder: so drop it | 20:32 |
| * slytherin calls of the day | 20:35 | |
| slytherin | s/of/off | 20:35 |
| === DreamThi1f is now known as DreamThief | ||
| === ogra_ is now known as ogra | ||
| mathiaz | kirkland: ok - what's your question with iscsitarget? | 21:47 |
| === kompulsa_dot_com is now known as Tetracomm | ||
| kirkland | mathiaz: hey, so there appears to be a separate, but related bug in the iscsi_trgt.ko kernel module provided by l-u-m | 21:47 |
| kirkland | mathiaz: i've talked to smb and rtg, and they're going to work on that from the kernel side | 21:47 |
| jmarsden|work | http://packages.ubuntu.com appears to be down -- are others still able to access it? | 21:48 |
| kirkland | mathiaz: basically, the ubuntu module won't unload properly | 21:49 |
| kirkland | mathiaz: and the init script unloads that module on "stop" action | 21:49 |
| mathiaz | kirkland: ok | 21:49 |
| kirkland | mathiaz: exiting non-zero if it cannot unload the module | 21:49 |
| kirkland | mathiaz: which cause the package upgrade to fail | 21:50 |
| kirkland | mathiaz: in the merged init script, i cleaned up a number of things, including lsb-izing it | 21:50 |
| kirkland | mathiaz: but i also made the module unload throw the warning/error, but it does not exit non-zero | 21:50 |
| kirkland | mathiaz: i was looking for a second opinion on that | 21:52 |
| mathiaz | kirkland: right - how important is it to unload the modules on stop? | 21:53 |
| kirkland | mathiaz: i also considered trying to put something in the pre-rm, that would soften the problems with the initscript "stop" failing, such that the package could be upgraded | 21:53 |
| kirkland | mathiaz: i'm not sure ... the daemon is killed first, and that seems to happen well | 21:53 |
| mathiaz | kirkland: hm - right package upgrades. | 21:53 |
| kirkland | mathiaz: i can't get the module to unload at all, must reboot | 21:53 |
| mathiaz | kirkland: IIRC you could try to put some code in the new prerm script | 21:54 |
| kirkland | mathiaz: the "easy" work around is to a) stop the init script, ignore the error, b) move the init script out of the way, c) do the package upgraded | 21:54 |
| kirkland | mathiaz: yes, that would definitely work | 21:54 |
| kirkland | mathiaz: i thought maybe we'd see if a working module might be added to the kernel first | 21:54 |
| kirkland | mathiaz: but mainly, i was looking for a second opinion, and to alert someone about the potential issue | 21:55 |
| === santiago-pgsql is now known as Guest95544 | ||
| mathiaz | kirkland: yes - but that wouldn't help in the case of upgrades | 21:55 |
| kirkland | mathiaz: i also submitted a debian bug, with the patch | 21:55 |
| kirkland | mathiaz: i haven't heard anything back from them yet | 21:55 |
| mathiaz | kirkland: right - so you'd suggest to wait for the kernel fix before uploading a merge? | 21:56 |
| kirkland | mathiaz: sorry, no i uploaded the merge already | 21:56 |
| kirkland | mathiaz: and i noted in a bug report that a), b), c) workaround, if you're having trouble with the upgrade | 21:57 |
| kirkland | mathiaz: i'm asking you now if you think a maintainer script would be required | 21:57 |
| mathiaz | kirkland: yes | 21:58 |
| kirkland | mathiaz: okay ... next question... there is a prerm script auto-generated by debhelper | 21:58 |
| mathiaz | kirkland: well - technically debhelper doesn't generate a prerm script - it substitutes some code in existing maintainer script | 21:59 |
| mathiaz | kirkland: the templates for the maintainer scripts can be found under /usr/share/debhelper/dh_make/debian | 22:00 |
| === Guest95544 is now known as santiago-ve | ||
| * lamont notes that packages.ubuntu.com is happy agaain | 22:06 | |
| Nafallo | jmarsden|work: packages.u.c back. | 22:06 |
| jmarsden|work | Nafallo: thanks | 22:06 |
| Nafallo | meeh. stupid scroll up :-) | 22:06 |
| lamont | heh | 22:07 |
| nhandler | Could someone give me a hand with merging loadlin from Debian? It FTBFS (http://paste.ubuntu.com/76599/). | 22:37 |
| jdong | nhandler: try -fno-stack-protector in CFLAGS? | 22:38 |
| DktrKranz | nhandler, try passing -fno-stack-protector to CFLAGS | 22:38 |
| jdong | *tells ke<noping>es to look away* | 22:38 |
| james_w | https://wiki.ubuntu.com/CompilerFlags#-fstack-protector | 22:39 |
| nhandler | I'm building it again right now. In the mean time, I'll read through that wiki page. Thanks jdong, DktrKranz, and james_w! | 22:41 |
| DktrKranz | nhandler, as ke<noping>es says, it's better to fix it properly, but if you're in a hurry... | 22:42 |
| nhandler | Well, the -fno-stack-protector didn't solve the issue. It still FTBFS with the same error | 22:43 |
| jdong | well loadlin probably doesn't use stdlib anyway | 22:44 |
| DktrKranz | nhandler, be sure CFLAGS are handled by debian/rules. If not, you need to adjust Makefile (or whatever) manually | 22:47 |
| nhandler | DktrKranz: debian/rules is handling the CFLAGS | 22:49 |
| DktrKranz | nhandler, try to pass -U_FORTIFY_SOURCE too | 22:49 |
| DktrKranz | buffer overflows are easier to track | 22:50 |
| nhandler | DktrKranz: Nope. -U_FORTIFY_SOURCE didn't fix it either. | 22:54 |
| NCommander | DktrKranz, -U? | 22:54 |
| NCommander | Why do you want to undefine it? | 22:54 |
| DktrKranz | NCommander, testing purposed | 22:56 |
| NCommander | ah | 22:57 |
| DktrKranz | nhandler, my bet is debian/rules doesn't pass CFLAGS to inner Makefile | 22:57 |
| james_w | would anybody like to review my changes in http://paste.ubuntu.com/76605/ ? | 22:59 |
| nhandler | DktrKranz: You might be right. The rules file sets up the CFLAGS variable. However, the only time it uses it is when deeling with freeramdisk. (http://paste.ubuntu.com/76603/) | 23:01 |
| DktrKranz | nhandler, if you have a Makefile in parent directory, try adjusting it by inserting -fno-stack-protector after gcc invocation | 23:02 |
| DktrKranz | james_w, at a first glance, it seems good (it follows the recipe provided by CompilerFlags) | 23:06 |
| james_w | thanks DktrKranz | 23:09 |
| nhandler | DktrKranz: Nope. Adding -fno-stack-protector to the make file didn't do any good either. | 23:14 |
| kirkland | mathiaz: hmm, i'm having some strange problem with dh_installdeb | 23:16 |
| kirkland | mathiaz: my diff currently looks like this: http://pastebin.ubuntu.com/76612/ | 23:19 |
| mathiaz | kirkland: where does the init script fail currently? In prerm? | 23:22 |
| kirkland | mathiaz: well, the substitution claimed by dh_installdeb isn't currently happening | 23:22 |
| kirkland | mathiaz: there must be a debian/rules step missing | 23:22 |
| kirkland | mathiaz: but dh_installdeb appears to be present in the two places i'd expect it | 23:22 |
| DktrKranz | nhandler, I need to look at it then | 23:25 |
| nhandler | DktrKranz: No problem. I'll probably just put the merge up for grabs. I have no personal reason for doing it. In the end, it would just be another MOTUs solution that I would use. If nobody handles it by DIF, I'll take another look at it. | 23:26 |
| DktrKranz | nhandler, ok. I'll leave soon (quite late here), I'll have a look at it tomorrow (if I remember, of course) | 23:28 |
| nhandler | Thanks again for your help DktrKranz | 23:29 |
| directhex | james_w, which package are you working on mono transition for, OOI? it would be great if you could take ownership on http://wiki.debian.org/Teams/DebianMonoGroup/Mono20TransitionTODO to avoid duplication of effort | 23:29 |
| james_w | directhex: it was banshee. I requested the sync, and so got stuck with the build failure email | 23:29 |
| directhex | ah, right | 23:29 |
| directhex | well, slomo will receive appropriate kicks up the butt. since mono 2 is now in experimental, he'll get the same FTBFS there until he makes a 1.4.1-2 | 23:30 |
| james_w | yup | 23:30 |
| james_w | I'll see if I can get something that builds for him to start from | 23:31 |
| directhex | although no sign of meebey tonight (grrr!) | 23:31 |
| kirkland | mathiaz: ^ thoughts? | 23:33 |
| mathiaz | kirkland: looking at the package now | 23:34 |
| kirkland | mathiaz: thx | 23:34 |
| mathiaz | kirkland: but a quick comment regarding your pastbin - why not put the logic in failed-upgrade? | 23:35 |
| directhex | james_w, are you a banshee user, then? | 23:35 |
| mathiaz | kirkland: it seems that this is the place to handle a failure of the prerm script from the existing package | 23:35 |
| james_w | directhex: nope | 23:35 |
| snikker | when i try to make a .deb package, i've got this warning: "dpkg-gencontrol: warning: unknown substitution variable ${shlibs:Depends}" and in "${misc:Depends}", can you help me? | 23:44 |
| mok0 | snikker: they are defined in debian/control | 23:45 |
| mok0 | snikker: you can safely delete it | 23:46 |
| azeem | snikker: it means nothing had to be substituted | 23:46 |
| azeem | AIUI | 23:46 |
| snikker | yes, they are there, isn't right? | 23:46 |
| azeem | well, apparently they are not needed | 23:46 |
| azeem | snikker: what programming language is your package in? | 23:46 |
| mok0 | snikker: you can also leave them, it's not a serious problem | 23:46 |
| azeem | *if* they are really not needed | 23:47 |
| snikker | it's an service menu for kde4... so i can ignore it? | 23:47 |
| azeem | eh | 23:47 |
| azeem | kde4 is not a programming language | 23:47 |
| azeem | is it in C++? | 23:47 |
| mok0 | snikker: so it's just image and text files? | 23:48 |
| kirkland | mathiaz: i suppose it could be handled there | 23:48 |
| snikker | if the servicemenu is in c++? no, it's just a text file (file.desktop) | 23:48 |
| azeem | ok then | 23:48 |
| azeem | snikker: then you can ignore it and/or delete it indeed | 23:48 |
| snikker | azeem: ok, thanks... | 23:49 |
| snikker | azeem: but suppose that i've got a c/c++ file (instead of text file) and i receive this warning, what i must do? | 23:50 |
| mok0 | snikker: then you wouldn't get the warning | 23:52 |
| azeem | all c/c++ programs need at least the C/C++ system libraries, so if you get the ${shlibs:Depends} warning, it might mean the package build process failed to build or install the program | 23:53 |
| azeem | the ${misc:Depends} warning might not be a problem | 23:53 |
| snikker | azeem: ok, but if i've got a ${shlibs:Depends}, how can i check what's the problem? | 23:55 |
| snikker | there is a way for check it? | 23:55 |
| azeem | no, you will have to carefully manually inspect the .deb you get | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!