| micahcowan | Hello. Is it never appropriate to install to /usr/lib64 (on 64-bit systems), versus /usr/lib? | 00:06 |
|---|---|---|
| StevenK | lrwxrwxrwx 1 root root 3 2007-03-27 07:17 /usr/lib64 -> lib | 00:06 |
| RAOF | That is correct. It is never appropriate to install to /usr/lib64 on a 64-bit system (for Debian/Ubunt) | 00:07 |
| StevenK | Just install to /usr/lib | 00:07 |
| micahcowan | That's what I suspected; thank you. And yeah, I knew the symlink | 00:07 |
| directhex | this is an old topic, for which i blame solaris | 00:07 |
| RAOF | And the lack of multiarch. | 00:07 |
| micahcowan | But only just discovered that installing to /usr/lib64 will produce bad things in Conflicting packages, if one of them has /usr/lib. | 00:07 |
| micahcowan | A check of /var/lib/dpkg/info/*.list seemed to indicate that nobody was installing to /usr/lib64 (only lib64 even had a reference to it, and it was to the directory (symlink) only) | 00:08 |
| directhex | RAOF, i wouldn't mind if there were consistency on the "lib64 as libdir" distros, but there is not | 00:08 |
| directhex | micahcowan, do you want the full story, or the short version? | 00:08 |
| micahcowan | Hm, I'm curious, but don't stress yourself to satisfy my curiosity ;) | 00:09 |
| Davedan | I have a package that uses debconf to ask for a user's mail. Am I suppose to move this to a /etc/package.config file? If not can I later access this data from a python script? | 00:12 |
| persia | Davedan, You are supposed to write out a configuration somewhere. | 00:12 |
| Davedan | is the debconf database temporary for the installation stage or kept for good? | 00:13 |
| DktrKranz | directhex, I hadn't time to check MD2, and probably won't have tomorrow :( | 00:13 |
| persia | Davedan, It's not purged, but it's not guaranteed to remain, and users can purge values at will. | 00:14 |
| directhex | micahcowan, okay. back in days of yore, there was sparc, and solaris. then sparc64 appeared, and solaris needed to run it. now, sparc64 was MUCH slower in 64-bit mode than 32-bit mode, so people would take their normal system (in lib) and have a few select 64-bit libs for 64-bit apps alongside it (in lib64) | 00:14 |
| directhex | micahcowan, make sense so far? | 00:14 |
| Davedan | persia: ok, so I'll move it to a config file in the posinst. I guess I don't need to purge the db myself? | 00:15 |
| persia | Davedan, In other words, once your package is installed, it's not safe to rely on debconf until the next time your package is reconfigured, at which time you can reuse (or not) debconf data depending on how the user called the reconfigure. | 00:15 |
| micahcowan | directhex, sure | 00:15 |
| persia | No, you don't: leave that to the user. | 00:15 |
| Davedan | persia: thanks | 00:15 |
| directhex | micahcowan, so lib64 was a "companion" dir to the primary os, which was 32-bit. | 00:15 |
| directhex | micahcowan, now, problem is, not every 64-bit chip is as terrible as sparc64 - most chips are as fast (or faster) with a 64-bit native system | 00:16 |
| RAOF | That's not actually true. | 00:16 |
| directhex | RAOF, no? | 00:17 |
| RAOF | 64bit is generally slower; x86-64 is the exception to the rule, because they relaxed some of the worst restrictions in IA32 | 00:17 |
| directhex | RAOF, itanium & x86-64 are faster. which other arches really matter? | 00:17 |
| RAOF | Does itanium _have_ a 32bit native mode? | 00:18 |
| lifeless | RAOF: it has a makes-coffee native mode | 00:18 |
| directhex | and itanium is the example i want to point to here - when itanium linux appeared, since the system needed to be 64-bit, it made sense to use the normal system libdir (lib) for all the system libs. this is the case on all distros | 00:18 |
| lifeless | RAOF: (and yes) | 00:18 |
| directhex | RAOF, itanium 1 did, 2 does not | 00:18 |
| RAOF | directhex: Are you sure you don't mean IA32? | 00:18 |
| lifeless | directhex: oh, they dropped it? | 00:18 |
| directhex | lifeless, they did. it's emulated in EFI now | 00:19 |
| RAOF | IA64 code is always 64-bit, and is totally different to IA32 code. | 00:19 |
| lifeless | kk | 00:19 |
| lifeless | RAOF: IA64 != Itanium's 64 bit native mode | 00:19 |
| directhex | RAOF, which of us has a half-million quid itanium box? :p | 00:19 |
| Davedan | persia: is it better to create an empty config file before the postinst and then edit it accourding to the debconf or create it only in the postinst? | 00:20 |
| RAOF | lifeless: Really? What _was_ Itanium's native mode? | 00:20 |
| RAOF | directhex: I'm guessing you :) | 00:20 |
| directhex | RAOF, IA64 is what itanic deals with normally. but it can execute i386 code too | 00:20 |
| directhex | via hardware on itanium1, and transparent emulation on itanium2 | 00:20 |
| lifeless | directhex - I thought that IA64 wass intels rebranding of AMD's 64-bit extensions | 00:20 |
| persia | Davedan, I generally think it's better to create it in the postinst, because then it's easier to remember not to clobber it on upgrade, but rather only create it on install. | 00:20 |
| directhex | can even do x86-64 | 00:21 |
| directhex | lifeless, no, that's em64t or "intel64" | 00:21 |
| RAOF | directhex: Right. But that's very, very different to the difference between x86 and x86-64. | 00:21 |
| directhex | lifeless, confusing innit :) | 00:21 |
| Davedan | persia: ok | 00:21 |
| lifeless | oh bah yes | 00:21 |
| lifeless | directhex: yeh, I dove into this deeply about 6 years back, did some squid tweaks for itanium-1 | 00:21 |
| directhex | RAOF, well, from the perspective of a booted system, the important point remains that it's a 64-bit arch where libdir is /usr/lib | 00:21 |
| lifeless | promptly forgot it all :( | 00:21 |
| directhex | RAOF, even on suse | 00:22 |
| lifeless | does itanium-2 still run hppa natively/ | 00:22 |
| RAOF | directhex: Right. /usr/lib should be always the "native" format. | 00:22 |
| directhex | lifeless, dunno, don't care | 00:22 |
| lifeless | :P | 00:22 |
| directhex | RAOF, we say that as debbuntu people, of course | 00:22 |
| micahcowan | :) | 00:22 |
| RAOF | directhex: Yup. | 00:22 |
| directhex | RAOF, and i believe it. the brokenness is suse/redhat on x86-64 (but NOT ia64) use lib64 as libdir, for no good goddamn reason | 00:22 |
| directhex | /usr/lib is your system lib folder, regardless of arch. that seems simple enough to me | 00:23 |
| directhex | and is simple enough on suse for itanic. it's only on x86-64 that they go nits | 00:23 |
| directhex | nuts | 00:23 |
| RAOF | Right. If you're going to do that, you might as well go for the system-triple /usr/lib-ia64-linux-something and /usr/lib-x86-64-linux-something and /usr/lib-IA32-linux-something. | 00:23 |
| directhex | RAOF, /emul/ia32-linux ? :) | 00:24 |
| RAOF | Why bother with /emul? It's not like the CPU's actually emulating it. | 00:25 |
| directhex | (ia64 suse; amd64 etch) | 00:25 |
| directhex | i think it's called emul for historic reasons, i.e. itanium :) | 00:25 |
| directhex | and since itanium and x86-64 needed the same set of 32-bit libs for day-to-day use, the name stuck. except on ubuntu where we use lib32 | 00:25 |
| RAOF | But Itanium _didn't_ emulate, at least at first? It had native IA32 instruction decoding h/w. | 00:25 |
| directhex | tbh i have a headache | 00:26 |
| RAOF | :) | 00:26 |
| ajmitch | RAOF: native & very slow, wasn't it? | 00:26 |
| RAOF | Oh, yes. | 00:26 |
| RAOF | So slow that I believe the software-translation that Itanium 2 does is faster. But it was still native :) | 00:27 |
| micahcowan | Ha! | 00:27 |
| directhex | t'is troo | 00:27 |
| lifeless | love the graph: http://en.wikipedia.org/wiki/IA-64 | 00:27 |
| lifeless | RAOF: its gets meta, 'what is emulation' - what was that ia32 comaptible totally-emulated chip | 00:28 |
| ajmitch | crusoe? | 00:28 |
| RAOF | Yay for Transmeta. | 00:28 |
| RAOF | ajmitch: indeed. | 00:28 |
| micahcowan | I used to work for Transmeta. | 00:28 |
| ajmitch | a rather interesting concept | 00:28 |
| RAOF | Sweet. That sounded like a cool idea. | 00:28 |
| micahcowan | But as a software guy in a tools group... never knew much about our chips. | 00:28 |
| directhex | jms@orac:~> grep -c IA-64 /proc/cpuinfo | 00:28 |
| directhex | 256 | 00:28 |
| micahcowan | Got to see Linus at the occasional company picnic, tho' :D | 00:29 |
| directhex | yup yup | 00:29 |
| * Laney enters a life without Facebook | 00:29 | |
| Laney | O brave new world! | 00:29 |
| directhex | Laney, i'm proudly free of web 2.0 trappings | 00:29 |
| Laney | good man | 00:29 |
| ajmitch | directhex: nice, but I'd hate to see the power bill for that system :) | 00:29 |
| directhex | well, except my website uses wordpress as a CMS (but not a blog engine). and my youtube & digg accounts. actually, i suck | 00:30 |
| directhex | ajmitch, honestly? | 00:30 |
| Laney | It's become less useful for social organising recently anyway | 00:30 |
| directhex | ajmitch, the meters say we've used 1.5 million units across all systems in our room in the past 15 months | 00:30 |
| Laney | identi.ca marches on! | 00:30 |
| ajmitch | I remember jbailey complaining about how noisy & power-hungry the ia-64 box he had was | 00:31 |
| directhex | ajmitch, very awesome: our 256 core box, with 1 TiB of RAM, is as easy as a linux desktop to admin. not awesome: a SUSE desktop | 00:31 |
| StevenK | Haha | 00:32 |
| lifeless | RAOF: update your loom | 00:33 |
| RAOF | lifeless: Update the bzr-loom package in Jaunty | 00:33 |
| RAOF | Alternatively, I could do that, of course. | 00:34 |
| lifeless | RAOF: Let me show you my upstream hat | 00:35 |
| RAOF | lifeless: You're not sure that a new loom will make that error go away? | 00:35 |
| lifeless | RAOF: its a versioned mismatch in command calling | 00:36 |
| lifeless | I use loose versioning in loom to avoid spuriously forcing upgrades, but the cost is sometimes it breaks. Its fixed in loom trunk, for several months. | 00:36 |
| RAOF | I suspected as much. Why would you like _me_ to update my loom, though? | 00:36 |
| lifeless | because you're reporting the problem? | 00:37 |
| * StevenK blinks | 00:37 | |
| StevenK | A K-line for nhandler? | 00:37 |
| persia | Probably over-agressive mibbit throttling. | 00:38 |
| RAOF | lifeless: But I want it fixed in Jaunty. Do you want testing of the new upstream loom with Jaunty's bzr? | 00:39 |
| lifeless | RAOF: I suggest updating the package then :) | 00:40 |
| RAOF | Right. That's what I (or someone else) will do :) | 00:40 |
| micahcowan | directhex, thanks for the history :) | 00:41 |
| persia | Um. Shouldn't the verification that it fixes the given repository be done prior to the upload to jaunty? | 00:41 |
| ajmitch | persia: uploads are tested these days? | 00:43 |
| RAOF | persia: Yeah, obviously. But it's easy to test; anyone with any bzr tree can duplicate the error. | 00:43 |
| persia | ajmitch, Well, not like when you had the whip, but sometimes. | 00:43 |
| RAOF | s/can/should be able to/. | 00:43 |
| ajmitch | persia: don't worry, I was going to sponsor an upload yesterday but it failed testing :) | 00:44 |
| persia | ajmitch, See, even when you try :) | 00:44 |
| AdamDH | can I use intrepid to build packages for januity? | 00:59 |
| AdamDH | or do I have to be running januity? | 00:59 |
| micahcowan | pbuilder! | 01:01 |
| AdamDH | so I can do dpkg-buildpackage -S -rfakeroot and then sudo pbuilder build ../*.dsc as normal? I was getting unmet dependancies as the dependandices will not appear till jaunty | 01:02 |
| micahcowan | I'm guessing that chroot was not a jaunty one? | 01:03 |
| micahcowan | https://wiki.ubuntu.com/PbuilderHowto has good info on setting up mutliple chroots, and setting up chroots for other versions of Ubuntu. | 01:03 |
| AdamDH | thanks I will take a look | 01:05 |
| AdamDH | ah thanks micahcowan that seemed to be the problem | 01:06 |
| persia | AdamDH, Be aware that you may not be able to build all source packages for Jaunty in intrepid: sometimes debian/rules clean does more than one expects. | 01:11 |
| persia | (e.g. some clean rules use ant in a way that compiles more of the package in order to delete the created files, and others run ./configure on clean). | 01:12 |
| directhex | merge request filed on gnome-subtitles. the app transition is done | 01:17 |
| AdamDH | why would I get dh_testdir: Command not found? | 01:17 |
| directhex | i'll mail thanks tomorrow | 01:17 |
| ScottK | AdamDH: You don't have debhelper installed is the usual reason. | 01:17 |
| AdamDH | does debhelper have to be a build depend? | 01:18 |
| directhex | yes | 01:18 |
| micahcowan | in those cases, what, qemu to the rescue, etc? | 01:19 |
| _16aR_ | Hmmm a package which isn't in the queue but not in the packages.ubuntu.com ... Does it exist somewhere ? or maybe has it be dropped? | 01:19 |
| persia | _16aR_, packages.ubuntu.com is sometimes as much as several days out of date. Check launchpad for authoritative information, or use rmadison. | 01:20 |
| _16aR_ | (I precise : it was in the queue) | 01:20 |
| _16aR_ | persia: ok :) Thanks | 01:21 |
| _16aR_ | rmadison found it :) | 01:21 |
| * Panarchy says Hi | 01:25 | |
| * _16aR_ just do it | 01:25 | |
| _16aR_ | Hi | 01:25 |
| Panarchy | What is the easiest way to create a .deb package? I need one that can include: -That I am the maintainer of the package- | -A description (and name) of the package- | -The version of the package/tool- | -And any dependencies the packages needs to be installed- | 01:27 |
| === orospakr` is now known as orospakr | ||
| directhex | all of the above are part of debian/control | 01:28 |
| Panarchy | ? | 01:30 |
| persia | !packaging | 01:32 |
| ubottu | The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports | 01:32 |
| persia | Panarchy, Basically, you need to create four extra files: changelog, control, copyright, and rules. In the simple case, rules can be copied form examples provided in the debhelper package. | 01:33 |
| directhex | persia, dh7 minimal style! | 01:33 |
| Panarchy | ah | 01:33 |
| Panarchy | is changelog description (for 1st package made) | 01:34 |
| directhex | your first changelog entry usually says "initial packaging" and possibly a bug number for an ITP bug | 01:34 |
| directhex | in changelog format | 01:34 |
| persia | No, the description is in the control file. The changelog for the first revision is typically "Initial Packaging" the package name, the version, and the packager's name. dch --create will generate a template. | 01:34 |
| Panarchy | persia, you've been the most help so far | 01:35 |
| Panarchy | I am in the middle of another project, if you wouldn't mind, can you tell me what you've just told me here on my topic: http://ubuntuforums.org/showthread.php?t=1072332 | Thanks | 01:35 |
| persia | Nope. I don't write in the forums. | 01:36 |
| persia | There's a log of what's been written here at irclogs.ubuntu.com though. | 01:36 |
| cpscotti | cant Panarchy just c&past | 01:36 |
| cpscotti | duh | 01:36 |
| Panarchy | persia: You don't write on the forums? Okay, can I quote you on the topic? | 01:37 |
| persia | Panarchy, Anything I write here is for public dissemination. | 01:40 |
| Panarchy | http://ubuntuforums.org/showthread.php?p=6752680 | 01:42 |
| persia | On the other hand, I don't really want credit for what directhex wrote :) When quoting people, please be careful to assign appropriate attribution (I'm not nearly as concise as directhex). | 01:44 |
| directhex | persia, you can take credit for what i wrote, as long as you take credit for helping to add mono-related things into ubuntu. sounds like a deal to me! | 01:45 |
| Panarchy | But you gave me more detail... I can quote directhex as well I guess | 01:45 |
| persia | But I didn't do that either :) | 01:45 |
| persia | Panarchy, You already did: it's just about appropriate attribution. | 01:45 |
| Panarchy | ... | 01:46 |
| Panarchy | I'm confused | 01:46 |
| Panarchy | If you want, tell me what to edit that post with, and I'll fix it up | 01:46 |
| persia | Compare the quote in your post with the log carefully, and check the names of those who wrote each chunk. | 01:47 |
| Panarchy | ah | 01:48 |
| Panarchy | I see | 01:48 |
| mrooney | What makes a package an "application" that shows up in Add/Remove? | 01:48 |
| persia | mrooney, Having a desktop file that gets put into app-install-data. | 01:48 |
| mrooney | persia: ahhh! | 01:48 |
| persia | Often the archive is scanned to include the files, so it's having the desktop file that is the key bit. If it's a server application, it's a bit trickier: you might ask on #ubuntu-server for some hints on how to do those. | 01:49 |
| persia | (because obviously you don't want the .desktop file to actually show in the desktop menu for a server). | 01:49 |
| Panarchy | Okay, fixed: http://ubuntuforums.org/showthread.php?p=6752680 | 01:50 |
| mrooney | persia: I am putting it in share/applications, should it be put somewhere else? | 01:50 |
| persia | Panarchy, Thanks for taking the trouble to be accurate. | 01:50 |
| mrooney | persia: or are you saying it is out of my control? | 01:51 |
| persia | mrooney, For a GUI application that would reasonably be launched by the user from the menu, it goes in /usr/share/applications (well, technically, it's an custom XDG path, but we all cheat). If it's another type of application, you need to do someting else, but I don't know what. | 01:51 |
| RAOF | persia: /usr/share/applications _is_ (one of) the XDG path(s). | 01:52 |
| persia | RAOF, Only because it's configured that way for Ubuntu. The spec recommends using /usr/share/applications as a fallback additional path in addition to those defined in the menu files, but it doesn't mandate it. | 01:52 |
| persia | (or at least it didn't last time I checked) | 01:52 |
| mrooney | persia: so, I have done my part and have the desktop file showing up in the menu when it is installed, then it should automatically get added to that list somehow? | 01:52 |
| mrooney | *if Ihave | 01:53 |
| persia | mrooney, That's been my experience. Usually there's only one scan per milestone, at most, so it might be a fwe weeks to a month. | 01:53 |
| RAOF | persia: "To those defined in the menu files?" Am I thinking of the same thing? What's defined in the menu files? | 01:53 |
| persia | RAOF, In Ubuntu, we keep them in /etc/sdg/menus | 01:54 |
| persia | They define the search paths and structure for the menu | 01:54 |
| RAOF | Oh, my my! I _am_ thinking of something different! | 01:55 |
| persia | Although the implementation in our gnome-menus is a little extended, and includes some hardcoding of stuff. | 01:55 |
| persia | s/sdg/xdg/ | 01:55 |
| Panarchy | Automation: I'd be very interested if I could select all the folders (or tar.gz archives) and have them all automatically say that I am the maintainer, then allow me (via prompts) to insert the name of the tool, the version number, and a description... also what dependencies are needed. Do you know of a script/tool that will allow this to be done? | 01:55 |
| persia | Of what are you thinking? | 01:55 |
| RAOF | I think I'm thinking of the XDG basedir spec, actually. | 01:55 |
| persia | Panarchy, pkg-binary-mangler does some of that, but you'd have to write the rest. | 01:55 |
| persia | RAOF, That's *completely* different :) | 01:56 |
| persia | RAOF, Anyway, for our gnome-menus implemenation, the files could as easily fo in /etc/X11/applink or /usr/share/gnome/apps or /usr/share/control-center-2.0/capplets but we don't prefer those. | 01:58 |
| persia | That's what I thought you meant by ...(one of)... | 01:59 |
| maxb | On the subject of desktop files, does anyone know whether it's valid to list a multilevel relative path in an Icon= value? i.e. Icon=somesubdir/somefile.xpm to be found relative to /usr/share/pixmaps/ ? (It doesn't work, but is it technically valid - i.e. do I complain to gnome or to the upstream with the dodgy .desktop) | 01:59 |
| persia | maxb, That's valid, but wrong. | 02:00 |
| Panarchy | I just posted a question about the automation of .deb package creation here: http://ubuntuforums.org/showthread.php?t=1072928 | 02:00 |
| persia | maxb, If you're not using the icon cache, you need an absolute path, but you want to use the icon cache. | 02:00 |
| mrooney | persia: so since my package was accepted recently, wait until alpha 5 and see if it is there, and if not then ask questions again? | 02:01 |
| persia | So you'd just use Icon=somefile and put somefile.xpm or somefile.svg or somefile.png (or all three) into the directories scanned by the icon cache, and the menu implementation picks the most suitable icon. | 02:01 |
| maxb | persia: So, you're saying that gnome is wrong to not be finding the icon, but upstream is wrong to be doing that too? | 02:02 |
| mrooney | persia: (the package shows up fine in apt-cache search) | 02:02 |
| persia | mrooney, I'd wait until Alpha 6. | 02:02 |
| persia | maxb, Yes, but upstream is more wrong. | 02:02 |
| mrooney | persia: well thanks, I'll keep following it :) | 02:03 |
| persia | mrooney, Right, but someone has to manually run the scanner and update app-install-data, which isn't likely to happen right away, because people are rushing for Feature Freeze, and then the Alpha 5 freeze hits on Tuesday. | 02:03 |
| mrooney | persia: any plans to make it to barcelona for UDS? | 02:03 |
| persia | mrooney, I intend to be there, although it's still months away. | 02:04 |
| mrooney | persia: yes indeed. I can't wait for the announcement | 02:05 |
| hggdh | heh. who knows, this time I might be able to make it to UDS... | 02:13 |
| mrooney | hggdh: I've heard that one before ;) | 02:26 |
| hggdh | mrooney, yes, I know. Last year I had an assignment at the same time on a different city (Mississauga, Canada), and could not make it. This time I intend to get to Belgium to visit my son; from Belgium to Spain is just a small hop... | 02:28 |
| * hggdh hopes so, at least | 02:29 | |
| ajmitch | I guess UDS will be coming up rather soon | 02:32 |
| === _[PUPPETS]Gonzo is now known as [PUPPETS]Gonzo | ||
| anakron_ | ping Laney | 03:38 |
| anakron_ | HI all | 03:38 |
| dholbach | good morning | 06:43 |
| didrocks | hi dholbach o/ | 06:57 |
| dholbach | hiya didrocks | 06:58 |
| iulian | Morning dholbach. | 07:04 |
| dholbach | hiya iulian | 07:04 |
| dholbach | morgs: I was checking a few sugar related sponsoring bugs - do you know why setup.py is not being used to install all the files? | 07:10 |
| dholbach | morgs: I'm not suggesting deviating from Debian there, but just curious | 07:11 |
| dholbach | morgs: also: do you know why .po files are installed in the package? | 07:13 |
| slytherin | persia: in case you haven't seen already. Netbeans 6.5 is uploaded. :-) | 07:58 |
| persia | slytherin, I did see. Nice work. | 07:58 |
| persia | I've also enountered a couple packages on REVU that used netbeans for development now, which means a loop is forming :) | 07:59 |
| slytherin | persia: There is one small issue though, for which I will file bug. The ide shows an update notification at the start. Not sure what the notification is as I didn't have time to check. | 07:59 |
| persia | Well, that's going to be hard to drop, unless you feel like doing a *lot* of packaging. It's part of the netbeans module manager which downloads modules from netbeans on request, and tracks the versions of installed modules. | 08:01 |
| persia | It shouldn't pop-up by default (and didn't for the last couple versions), but pulling it out would mean we needed to handle netbeans plugins within the distro, which I don't think there's enough interest to do yet (we have enough trouble with Java libraries). | 08:01 |
| persia | Anyway, I have to run. Have a good afternoon. | 08:02 |
| slytherin | persia: not it doesn't pop up. It shows a icon in right bottom corner. | 08:02 |
| persia | Oh, yeah, I don't think we can fix that easily without disabling the plugins manager, which I don't think we can do without a lot of thought. | 08:03 |
| slytherin | hmm | 08:03 |
| petski | Anyone so kind to sponsor the upload of the debdiff attached to bug 77980 ? | 08:18 |
| ubottu | Launchpad bug 77980 in mtop "mtop failed to install (wrong/no password)" [Medium,Fix committed] https://launchpad.net/bugs/77980 | 08:18 |
| === tonyyaru1so is now known as tonyyarusso | ||
| directhex | DktrKranz, monodevelop 1.9.2 has been uploaded to experimental. should i get a debdiff up now, or wait until people have tested via ppa? | 08:36 |
| DktrKranz | directhex: 1.9.2 is "2.0beta"? | 08:37 |
| directhex | DktrKranz, yes | 08:37 |
| DktrKranz | ok, I guess we should not diverge from Debian too much | 08:38 |
| directhex | DktrKranz, gnome#. but that's a pretty minor change | 08:39 |
| DktrKranz | really | 08:39 |
| AndrewGee | Hey all. Any MOTUs available to review my package, gpxviewer? It's an application that allows users to look at GPS traces files in GPX format. Thanks :) http://revu.ubuntuwire.com/details.py?package=gpxviewer | 09:04 |
| ikonia | AndrewGee: I'd certainly be interested in looking at the finished package | 09:06 |
| directhex | my word, an ikonia | 09:06 |
| geser | slytherin: Hi, if you get bored :) could you please give a nudge to libjboss-buildmagic-java? It build-depends on itself and need some bootstrapping. | 09:07 |
| AndrewGee | ikonia: Okay :) | 09:08 |
| slytherin | geser: I will try today. I will check if the circular build dep is really required. | 09:08 |
| ikonia | directhex: a rare one | 09:13 |
| directhex | indeed. would you like a package? | 09:14 |
| ikonia | directhex: if you have you think I'd like | 09:14 |
| directhex | ikonia, i have a monodevelop 2.0, excellent vintage... or for something younger with more zing, a moonlight plugin | 09:15 |
| ikonia | directhex: give me something to play with, I'm interested | 09:17 |
| ikonia | your moonlight work interests me | 09:17 |
| directhex | ikonia, intrepid or jaunty? | 09:17 |
| ikonia | you can give me both, I've got both running here | 09:18 |
| ikonia | compare and contrast | 09:18 |
| directhex | well for intrepid, use deb http://ppa.launchpad.net/directhex/ppa/ubuntu intrepid main | 09:19 |
| directhex | for jaunty, wait a few hours & use apt:moonlight-plugin-mozilla | 09:19 |
| ikonia | ooh super | 09:20 |
| directhex | is it possible to mark a package as "actually, don't bother scheduling a build, it'll FTBFS and the buildds are busy enough as it is"? | 09:27 |
| geser | you could ask an archive admin to rescore it but why upload a version that will FTBFS? | 09:29 |
| directhex | geser, it turns out there's an upstream configure check which bails on non-x86-or-amd64 | 09:30 |
| directhex | when it shouldn't | 09:30 |
| geser | ah, so it will only FTBFS on some archs and not on all | 09:31 |
| geser | ask an archive admin in #ubuntu-devel to score it down on those archs | 09:31 |
| quadrispro | hi guys, could you take a look at -> http://revu.ubuntuwire.com/p/theorur ? | 09:35 |
| === hanska is now known as Guest76317 | ||
| savvas | RAOF: broken script? :) | 09:57 |
| === Guest76317 is now known as hanska | ||
| === hanska is now known as hanska__ | ||
| savvas | ouch :p | 09:57 |
| === hanska__ is now known as hanska | ||
| Laney | stefanlsd: What is different on your wordpress diff? | 10:01 |
| Laney | is it just the permissions? | 10:02 |
| stefanlsd | Laney: aah. use Pedro's. i actually did all the work before i found the bug... | 10:04 |
| Laney | why did you still attach it then? | 10:05 |
| stefanlsd | thought there was a bigger diff. didnt diff the two patches | 10:06 |
| Laney | right, uploading | 10:07 |
| stefanlsd | Laney: thx! | 10:08 |
| stefanlsd | ember: sorry, your diff is good :) | 10:08 |
| Laney | ember: I don't know what that new debdiff was, but I had already uploaded | 10:11 |
| Laney | sorry | 10:11 |
| Laney | . o O (yay Wordpress 2.7.1 in Jaunty) | 10:13 |
| === JanC_ is now known as JanC | ||
| ember | stefanlsd next time if you want to change or add something use the previous patch or simply ask | 10:22 |
| ember | thanks Laney _o/ | 10:22 |
| stefanlsd | ember: yeah. didnt notice the bug as i worked on the previous merge. | 10:25 |
| luisbg | hello people :) | 11:08 |
| geser | TheMuso: ubuntustudio-icon-theme is in DEPWAIT if you didn't notice it yet, because of the versioned dependency on libmagick9-dev (looks like the package didn't transition yet to the new names) | 11:11 |
| luisbg | james_w, thanks a lot for the comment | 11:25 |
| luisbg | fixed all :) | 11:26 |
| james_w | luisbg: cool | 11:27 |
| luisbg | \o/ | 11:28 |
| james_w | luisbg: you mean you relicensed __init__.py? | 11:30 |
| luisbg | the LGPL was a screw up | 11:30 |
| luisbg | yes | 11:30 |
| james_w | cool | 11:30 |
| luisbg | some copy pasting FAIL | 11:30 |
| james_w | advocated | 11:31 |
| luisbg | the .pyo files happened because I runned the app from source just to check the changes didnt affect anything... and then I forgot to erase those files | 11:31 |
| james_w | http://revu.ubuntuwire.com/p/freemix if another MOTU wants to advocate | 11:31 |
| james_w | heh | 11:31 |
| luisbg | james_w, w00t!! | 11:32 |
| james_w | I also advocated three small bzr related packages that should be simple | 11:32 |
| * luisbg hugs james_w | 11:32 | |
| * james_w hugs luisbg | 11:32 | |
| james_w | can't wait to have it in the archive :-) | 11:32 |
| luisbg | after my blog post I've had a bunch of quality feedback emails | 11:32 |
| luisbg | which make me really happy | 11:32 |
| * Laney has a looksee | 11:44 | |
| Laney | luisbg: You should link to a versioned GPL in debian/copyright | 11:46 |
| Laney | /u/s/c-l/GPL-2 or so | 11:46 |
| Laney | and mention the version in your Debian packaging statement | 11:46 |
| Laney | "GPL-2 or later" or similar | 11:46 |
| luisbg | Laney, doing so | 11:51 |
| luisbg | Laney, in line 27 I do | 11:52 |
| luisbg | 27 Public License can be found in `/usr/share/common-licenses/GPL'. | 11:53 |
| luisbg | debian/copyright | 11:53 |
| Laney | luisbg: That just links to the newest GPL (GPL3 in this case) | 11:54 |
| Laney | If you want GPL2 then you should mention /usr/share/common-licenses/GPL-2 | 11:54 |
| luisbg | ahhh ok | 11:54 |
| luisbg | fixing it | 11:54 |
| Laney | and please mention the version (with "or later") on the last line | 11:55 |
| luisbg | Laney, fixed :) its up in revu | 11:57 |
| Laney | brilliant, +1 | 11:57 |
| Laney | james_w: Take it away! | 11:58 |
| luisbg | Laney, thanks!!! you advocated faster than I commented the diff :P | 11:58 |
| * luisbg hugs Laney | 11:58 | |
| james_w | luisbg: ./src/__init__.py: LGPL (v2.1 or later) | 12:00 |
| james_w | luisbg: did you revert that change? | 12:00 |
| Laney | /var/revu/revu1-incoming/freemix-0902181257/freemix-0.2/src/__init__.py: GPL | 12:00 |
| Laney | luisbg: Wait | 12:01 |
| luisbg | how did that happen | 12:01 |
| Laney | headers say GPL1+ | 12:01 |
| james_w | oops | 12:01 |
| luisbg | weird, let me check | 12:01 |
| Laney | sorry | 12:02 |
| * Laney removes +1 | 12:02 | |
| * Laney learns something about licensecheck | 12:02 | |
| luisbg | ouch! :P | 12:02 |
| luisbg | fixing it | 12:02 |
| luisbg | sorry for the inconvenience guys | 12:06 |
| luisbg | Laney, fixed, sorry :( | 12:11 |
| james_w | luisbg: did you upload? | 12:19 |
| sistpoty|work | hi folks | 12:33 |
| * directhex submits debdiff to fix moon on non-x86 | 12:39 | |
| directhex | i hope | 12:39 |
| directhex | wait a sec..... | 12:39 |
| directhex | no, it's fine, diffstat confused me | 12:40 |
| === _neversfelde is now known as neversfelde | ||
| luisbg | james_w, yes > http://revu.ubuntuwire.com/details.py?upid=5212 | 12:50 |
| Laney | luisbg: the files are still gpl1+ | 12:52 |
| luisbg | Laney, huh, which file? let me check | 12:53 |
| Laney | src/ | 12:53 |
| luisbg | headers? | 12:53 |
| Laney | yes | 12:53 |
| luisbg | true | 12:53 |
| luisbg | gimme a sec | 12:54 |
| Laney | (although maybe this is OK with the 'or later versions' thing) | 12:54 |
| luisbg | better to fix it anyway :) | 12:55 |
| luisbg | Laney, fixed and uploaded.... http://revu.ubuntuwire.com/details.py?upid=5213 | 13:00 |
| Laney | why are debdiffs broken :( | 13:00 |
| * Laney pokes RainCT | 13:01 | |
| luisbg | Laney, they arent broken | 13:01 |
| Laney | don't they show changes to the orig? | 13:01 |
| luisbg | the changes I did from the previous to the current version are in the orig file | 13:02 |
| Laney | it'd be cool if they did | 13:02 |
| luisbg | yes it would :) | 13:02 |
| RainCT | they should be displayed | 13:03 |
| RainCT | that page just runs debdiff | 13:03 |
| RainCT | and it works.. | 13:04 |
| RainCT | I guess both files contain the same, because I've just downloaded them both and diff doesn't show any difference | 13:05 |
| RainCT | Laney, luisbg ^ | 13:05 |
| Laney | the license headers definitely changed | 13:05 |
| luisbg | Laney, -1 +2 :) | 13:05 |
| RainCT | err right | 13:06 |
| RainCT | but debdiff doesn't show this o.O | 13:06 |
| Laney | luisbg: Your watch file doesn't match anything | 13:06 |
| luisbg | Laney, can you explain that further please? | 13:06 |
| Laney | run uscan --verbose --report in your tree | 13:06 |
| RainCT | so.. debdiff is broken? XDD | 13:07 |
| hggdh | dholbach, ping -- re. bug 317602 (and good morning/afternoon) | 13:07 |
| ubottu | Launchpad bug 317602 in libpst "Please upgrade libpst from upstream at www.five-ten-sg.com/libpst" [Undecided,New] https://launchpad.net/bugs/317602 | 13:07 |
| luisbg | Laney, no matching hrefs for watch line | 13:07 |
| luisbg | I just run it in pitivi (where I got my inspiration for watch) and it says the same :( | 13:08 |
| dholbach | hiya hggdh | 13:08 |
| Laney | a lot of watch files are broken | 13:08 |
| luisbg | Laney, :S do you have an example of one working? just to know how to fix mine | 13:08 |
| luisbg | dholbach, wow! that was quick | 13:08 |
| hggdh | dholbach, I am confused there | 13:08 |
| Laney | luisbg: If you put your releases in their own directory | 13:08 |
| Laney | http://foo/files/ for example | 13:08 |
| Laney | then yours would work | 13:08 |
| Laney | and allow directoryindexing I think | 13:09 |
| Laney | (would work if you modified the path, of course) | 13:09 |
| Laney | or else you can tell uscan to scan the HTML of a page and return matching hrefs | 13:09 |
| dholbach | hggdh: can you elaborate? | 13:10 |
| hggdh | dholbach, the upstream source comes already primmed with dh_make. Whoever did it did not go farther than just running dh_make, so the *.ex | 13:11 |
| hggdh | which forced me to huh, re-do it | 13:11 |
| dholbach | hggdh: you could re-pack the tarball without the packaging | 13:12 |
| hggdh | dholbach, ah, OK. I was told that I should try hard to minimise changes... | 13:12 |
| AnAnt | Hello, is Ian Jackson here ? | 13:12 |
| c_korn | hello, I know you guys are busy. but could someone revu jeuclid? it has been rejected because of missing entries in debian/copyright. I informed the maintainer (Sylvestre Ledru) and he fixed it: http://revu.ubuntuwire.com/p/jeuclid (it is the last missing dependency to build scilab-5.1 which has been milestoned for jaunty) | 13:13 |
| dholbach | hggdh: between the Ubuntu and the Debian packaging :) | 13:13 |
| dholbach | hggdh: so a diff -ruN libpst-{oldversion,newversion}/debian is understandable and minimal | 13:13 |
| luisbg | Laney, so I have to check the directory structure of my website? heh | 13:13 |
| luisbg | let me check | 13:13 |
| Laney | luisbg: You don't have to, that's just the easiest way to get it to work | 13:14 |
| Laney | see any gnome application | 13:14 |
| hggdh | dholbach, then, another question: Debian is using "pure" dh_make, and I moved to CDBS -- which makes the ./rules much more simpler. Would this be an issue? | 13:14 |
| dholbach | hggdh: we generally try to keep the delta as small as possible - all changes we introduce we need to merge again when things change in Debian | 13:15 |
| dholbach | hggdh: I'd try to tell the upstream folks to remove the debian/ directory in one of the next releases and remove it from the tarball for now | 13:16 |
| hggdh | dholbach, indeed, and I fully accept it. The issue here is unless Debian moves to the new fork, we will not be able to merge with Debian anymore on libpst | 13:16 |
| dholbach | hggdh: it still should be pretty straightforward to merge the changes that are in the .diff.gz, no matter which tarball we use | 13:17 |
| slytherin | c_korn: why not wait for the packages to get accepted in Debian and then ask for an FFE in Ubuntu? | 13:17 |
| luisbg | Laney, " => Package is up to date" uscan win! :) | 13:19 |
| Laney | \o/ | 13:19 |
| hggdh | dholbach, and I *did* ask upstream about the half-done debianisation. I was told that this was it, and live with it. I was going to try again with a complete package | 13:20 |
| dholbach | hggdh: we can probably have a get-orig-source target in debian/rules that re-works the tarball for us | 13:20 |
| dholbach | does anybody have a good example for that? | 13:20 |
| * directhex writes a big long mail to the mailing lists | 13:20 | |
| directhex | dholbach, a good get-orig-source? | 13:21 |
| hggdh | directhex, yes | 13:21 |
| dholbach | directhex: yeah, one that does some tarball munging | 13:21 |
| hggdh | with changes | 13:21 |
| directhex | dholbach, please to be waiting | 13:21 |
| Laney | gnome-do has one | 13:21 |
| Laney | gnome-do-plugins, even | 13:21 |
| luisbg | Laney, http://revu.ubuntuwire.com/details.py?upid=5215 .. new debian/watch | 13:22 |
| hggdh | got'em, will adapt from there | 13:22 |
| directhex | http://svn.debian.org/wsvn/pkg-cli-apps/packages/monodevelop-database/trunk/debian/rules?op=file&rev=0&sc=0 | 13:22 |
| directhex | dholbach, hggdh, ^^ | 13:22 |
| hggdh | directhex, thanks | 13:23 |
| hggdh | dholbach, so, we should still maintain compatibility with a debian package that will have been obsoleted completely (like trashed)? | 13:25 |
| dholbach | hggdh: I'm sure that if we come up with a good solution and we forward that, the Debian folks will appreciate it (sooner or later) | 13:25 |
| dholbach | hggdh: it's not like the packaging itself is broken, in this case it's the upstream releases, no? | 13:26 |
| Laney | luisbg: +1 again | 13:27 |
| Laney | nice work | 13:27 |
| luisbg | Laney, \o/ nice! | 13:27 |
| luisbg | Laney, thanks a lot for the help! | 13:27 |
| hggdh | dholbach, well, not quite. There are two forks for this package: Debian, and 5-10. Debian has not been developed, while 5-10 has. The only option I see for Debian is to abandon their fork, and use 5-10 | 13:27 |
| * luisbg starts dancing around #ubuntu-motu trying to get the attention of an archive admin to push freemix to universe :) | 13:28 | |
| hggdh | in other words: Debian does *not* use the same upstream, Debian *is* the upstream here | 13:28 |
| Laney | luisbg: It just needs a second +1 who will then upload | 13:28 |
| dholbach | hggdh: really? that's weird | 13:28 |
| luisbg | Laney, james_w old's +1 doesnt count if I have done uploads after it? | 13:28 |
| c_korn | slytherin: well, I have no idea when the package will be in debian. because of the new debian release the queue seems to be frozen | 13:29 |
| Laney | no, new uploads expire advocations | 13:29 |
| luisbg | Laney, ok then... | 13:29 |
| hggdh | dholbach, tell me about it... the thing here is we need the shared library provided by 5-10; Debian does not have it, and will not have it, unless they either develop it themselves, or use 5-10 | 13:29 |
| Laney | luisbg: you could ask him for another quick review | 13:29 |
| * luisbg starts dancing around #ubuntu-motu trying to get the attention of a MOTU to do the second +1 on freemix :P | 13:29 | |
| luisbg | Laney, I dont know if he is around anymore | 13:29 |
| RainCT | Can some MOTU please try uploading a package (70MB) for me? I've already tried twice and there .orig.tar.gz always hangs at the last byte for me :/ | 13:29 |
| slytherin | c_korn: But Debian release has happened already. So it means that package may be cleared in few days | 13:29 |
| Laney | RainCT: It always seems to hang for ages there for me | 13:30 |
| dholbach | hggdh: ugh :-(( | 13:30 |
| c_korn | ok and a FFE for jeuclid and scilab won't be rejected. would be sad because I already got xmlgraphics, fop and java-wrappers into jaunty | 13:30 |
| hggdh | dholbach, and this is why I moved from pure dh_make to CDBS -- I figured it would not make any difference after all, and Debian could -- eventually -- use our package | 13:31 |
| RainCT | Laney: But does it work? Yesterday I waited 30 minutes and it didn't do anything.. | 13:31 |
| Laney | RainCT: Maybe it's proportional to the size of the file | 13:31 |
| luisbg | RainCT, you can try with my package... its just tiny :P | 13:32 |
| RainCT | heh | 13:32 |
| Laney | I don't know what it does at the end of the file, but the last byte always takes a long time to me | 13:32 |
| Laney | for* | 13:32 |
| luisbg | RainCT, 130kb | 13:32 |
| dholbach | hggdh: which package is going to make use of it? | 13:32 |
| hggdh | dholbach, evolution, for the Outlook importer plugin | 13:32 |
| Hobbsee | Laney / RainCT: it appears to be a router bug, or something. There's a dput bug open about it | 13:33 |
| hggdh | dholbach, there are additional advantages for the 5-10 fork: they deal with Outlook 2007, and Debian does not | 13:33 |
| Laney | Hobbsee: where? | 13:33 |
| Laney | debian? | 13:33 |
| dholbach | hggdh: did you talk to seb128 about it - shall we continue in #ubuntu-desktop? | 13:33 |
| Hobbsee | Laney: launchpad, last i checked ;) | 13:33 |
| Hobbsee | iirc there's a debian one too | 13:34 |
| hggdh | dholbach, moving to #desktop | 13:34 |
| RainCT | (I'm about to leave -will leave it running- and will probably not have time to try again.. I guess I'll get a FFe for it if the upload fails again?) | 13:34 |
| hggdh | dholbach, seb is not there. | 13:34 |
| RainCT | (-without it another package is uninstallable-) | 13:35 |
| slytherin | RainCT: which package is it? Where can I find the source package? I will try about 3 hours from now. | 13:35 |
| james_w | luisbg: uploaded, thanks | 13:37 |
| * luisbg runs around #ubuntu-motu looking for james_w, "there you are", and hugs him | 13:37 | |
| james_w | :-) | 13:37 |
| luisbg | :) | 13:37 |
| Laney | \o/ | 13:37 |
| luisbg | Laney, thanks! | 13:38 |
| Laney | thank *you* | 13:38 |
| * luisbg gets his oscar acceptance speach out of his pocket... :p | 13:39 | |
| Laney | just found that dput bug, interesting | 13:39 |
| luisbg | dput bug? | 13:39 |
| Laney | bug 193848 | 13:39 |
| ubottu | Launchpad bug 193848 in dput "dput stalling forever during upload without returning error" [Medium,Confirmed] https://launchpad.net/bugs/193848 | 13:39 |
| RainCT | slytherin: glest-data 3.2.1. The tarball is here: http://pkg-games.alioth.debian.org/tarballs/ | 13:40 |
| Laney | RainCT: you could dput from alioth I guess | 13:40 |
| luisbg | ahhh | 13:40 |
| RainCT | Laney: ehmm.. good point :P | 13:41 |
| Laney | if you trust that box to hold your key, that is | 13:41 |
| directhex | Laney, alioth is 100% secure! | 13:42 |
| StevenK | Laney: It doesn't *need* to hold your key | 13:42 |
| RainCT | Laney: which key? | 13:42 |
| StevenK | Laney: Learn about debsign, and that you don't need the entire source locally to sign something | 13:42 |
| StevenK | Storing your private key on a machine you don't control is something I certainly don't recommend | 13:43 |
| Laney | oh? | 13:43 |
| RainCT | Laney: the .changes file is already signed | 13:43 |
| StevenK | You also need to sign the .dsc | 13:43 |
| RainCT | so just scp'ing it there should be enough | 13:43 |
| Laney | I was thinking in terms of having to avoid downloading a huge orig tarball | 13:44 |
| Laney | but yes | 13:44 |
| RainCT | Laney: ah, the tarball is hosted at alioth :) | 13:44 |
| Laney | you could make an unsigned dsc/changes and sign that locally | 13:44 |
| Laney | StevenK: thanks for the education | 13:44 |
| slytherin | /me waits for a 'mono is evil' reply to directhex's mail. :-P | 13:44 |
| Laney | slytherin: /me obliges | 13:44 |
| directhex | slytherin, wouldn't be the first time | 13:44 |
| Hobbsee | oh dear, not another one... | 13:44 |
| StevenK | Laney: Absolutely, generate the .dsc and changes remotely, grab them, sign them and then copy them back. Works a charm and doesn't mean downloading a large tarball | 13:45 |
| directhex | Hobbsee, not yet. not that i know of anyway | 13:45 |
| Hobbsee | heh | 13:45 |
| slytherin | directhex: just kidding. Congratulations for the bug transition. | 13:45 |
| directhex | Hobbsee, at least the people on the ML aren't quite mad enough to use accusations of time travel | 13:45 |
| Hobbsee | directhex: haha | 13:45 |
| Laney | haha | 13:46 |
| Laney | that email | 13:46 |
| Laney | it brings a tear to the eye! | 13:46 |
| directhex | Hobbsee, you laugh, but boycottnovell said mono is only in debian because of pressure from ubuntu, ignoring the 2 year gap between debian's mono packages existing and warty existing... | 13:46 |
| Hobbsee | directhex: oh, way cool! | 13:46 |
| StevenK | Hah | 13:46 |
| Hobbsee | i wasn't aware of that one | 13:46 |
| Laney | have they picked up on moon yet? | 13:47 |
| luisbg | hey Hobbsee | 13:47 |
| Hobbsee | hiya luisbg! | 13:47 |
| directhex | Hobbsee, they also assumed i was flying to redmond to discuss strategies, because miguel de icaza was going with a guy named "joseph" - and that must mean me | 13:47 |
| directhex | Laney, no. i'm waiting with baited breath! | 13:47 |
| Hobbsee | directhex: obviously! | 13:47 |
| * Laney sends an anonymous tip | 13:47 | |
| directhex | Laney, t'is still in binary new, and won't build on non-x86ish until the 0ubuntu2 is sponsored :/ | 13:47 |
| slytherin | directhex: where is the bug? | 13:48 |
| directhex | Hobbsee, and some other stuff... you sorta start to lose track after a certain level of crazy | 13:48 |
| Hobbsee | heh | 13:48 |
| Hobbsee | yes | 13:48 |
| directhex | slytherin, bug 330917 | 13:49 |
| ubottu | Launchpad bug 330917 in opensuse "configure fails on every arch other than i386 and amd64" [Unknown,Confirmed] https://launchpad.net/bugs/330917 | 13:49 |
| RainCT | uhm.. | 13:50 |
| * RainCT wonders why he got thanked for the mono transition :P | 13:51 | |
| Laney | ssh, take the praise! | 13:51 |
| directhex | RainCT, gbrainy | 13:51 |
| slytherin | directhex: your debdiff doesn't indicate that you have actually run the autoreconf | 13:51 |
| Laney | slytherin: It's run at build time | 13:51 |
| RainCT | Laney: but that e-mail mentions "mono"! how can they write my name next to it???? XDDDDD | 13:52 |
| * RainCT hides | 13:52 | |
| slytherin | Laney: how, is that handled in debian/rules? | 13:52 |
| slytherin | oh, wait, I see | 13:52 |
| RainCT | directhex: yeah well.. I had to do that one so that you stop annoying me ;) | 13:52 |
| slytherin | Laney: directhex: I am not sure running autoreconf at the build time is really preferred way. | 13:53 |
| directhex | RainCT, i only apologized to sponsors & archive admins for obnoxious badgering. you don't earn that privilege! | 13:53 |
| Laney | directhex: you fail at running update-maintainer, btw | 13:54 |
| directhex | ehm..... yes, yes i do | 13:55 |
| * Laney sponsors gnome-subtitles | 13:55 | |
| Laney | I want the glory of turning the last cell green | 13:55 |
| directhex | i'm absolutely terrible at running update-maintainer | 13:55 |
| Laney | so am I | 13:55 |
| directhex | perhaps because i do too much packaging at gone midnight | 13:56 |
| Laney | but the fatal error always reminds me. How does that not get you? | 13:56 |
| RainCT | wow, alioth is fast :) | 13:56 |
| RainCT | I want their internet connection! | 13:56 |
| Laney | heh | 13:56 |
| Laney | how many hops between alioth and upload.u.c? | 13:56 |
| RainCT | 30MB uploaded in 10 seconds | 13:56 |
| RainCT | wooo it's up | 13:56 |
| RainCT | \o/ | 13:57 |
| directhex | slytherin, it's the method taken in some of our other packages, so i used it here..... personally i favour "punch upstream in the arm until they fix it & upload a 1.0.1 bugfix tarball", but that's slower | 13:57 |
| slytherin | directhex: well, I haven't sponsored any other packages in mono, so can't really force my preference here. | 13:58 |
| RainCT | now it's going to take up longer for Launchpad to send the "Accepted" mail than uploading 70MB took.. lol | 14:00 |
| james_w | Laney: the fatal error is only for those where $DEBEMAIL =~ /@ubuntu\.com/ | 14:00 |
| RainCT | ah, there it is :) | 14:00 |
| Laney | aha | 14:01 |
| RainCT | Which fatal error? With debuild? | 14:01 |
| Laney | directhex: done | 14:01 |
| Laney | yes RainCT | 14:01 |
| RainCT | And couldn't you have asked james_w yesterday? :P | 14:01 |
| RainCT | I had to change the maintainer of glest{,-data} to myself to be able to debuild them.. hehe | 14:02 |
| RainCT | anyway, I guess I should stop spamming the channel :) | 14:02 |
| Laney | I guess you can do DEBEMAIL=foo debuild -S | 14:03 |
| Laney | to get around it | 14:03 |
| RainCT | yeah, but I didn't know yesterday :) | 14:03 |
| Laney | education! | 14:03 |
| RainCT | we can't all be as wise as james_w ;) | 14:03 |
| LucidFox | Okay, today is a historical day for me... | 14:05 |
| LucidFox | I'm going to upload my first packages signed with my female name | 14:05 |
| slytherin | directhex: Have you already found anyone to sponsor the moon debdiff? | 14:05 |
| RainCT | james_w: Btw, do you know if bzr-git works fine, or even better, are there more tools like debcommit (like a debtag for example :P) which are VCS agnostic? | 14:06 |
| james_w | bzr-git is improving quickly | 14:06 |
| james_w | mr might interest you | 14:06 |
| james_w | debrelease can tag from debian/changelog if that is what you are looking for | 14:07 |
| persia | Does mr also do the right thing for bzr packages? | 14:07 |
| RainCT | james_w: Thanks for the info, I'll have to check both out. I always have problems remembering the commands for SVN, and don't even want to see git :) | 14:08 |
| james_w | persia: in what way? | 14:08 |
| persia | james_w, The little I've heard about mr seems to focus on git and svn. I just wondered if 1) there was bzr support, and 2) it matched your recommendations of usage (as you seem to be the expert on bzr package management currently). | 14:09 |
| james_w | persia: I didn't think it had to do with package management | 14:11 |
| slytherin | directhex: have you already found anyone for the sponsorship for the moon bug? | 14:12 |
| persia | james_w, package maintenance maybe? | 14:12 |
| james_w | persia: yeah, that too | 14:12 |
| james_w | http://kitenet.net/~joey/code/mr/ | 14:14 |
| persia | Can one just do mr up; ${some_hacking}; mr commit; and expect it to work sensibly? | 14:14 |
| james_w | I believe that is the point | 14:15 |
| persia | I'm sure it's the point: I just didn't know if the mr handling of bzr package maintenance matched your recommended best practices. | 14:16 |
| james_w | I've never looked | 14:16 |
| * persia apologizes for being unclear. | 14:16 | |
| james_w | I don't see why it wouldn't though | 14:17 |
| persia | Ah :) | 14:17 |
| ScottK | directhex: I thought you'd appreciate this: http://www.kdedevelopers.org/node/3896 | 14:28 |
| * persia idly considers http://paste.ubuntu.com/119695/ as an even more minimal dh7 rules file | 14:28 | |
| mok0 | persia: cute! | 14:41 |
| persia | mok0, Yes, but probably opaque. Anyway, it's more characters than rules.tiny, even if fewer lines. | 14:41 |
| mok0 | persia: and whoever changes rules.tiny risks to break everything... | 14:42 |
| * mok0 uploaded a package closing 9 LP bugs :-) | 14:43 | |
| Laney | #1? | 14:44 |
| mok0 | Laney: unfortunately, no | 14:44 |
| bddebian | Heya gang | 14:44 |
| mok0 | Yo bddebian | 14:44 |
| bddebian | Hi mok0 | 14:44 |
| ScottK | mok0: Did anyone discuss with you your changes to the debian/copyright examples on the wiki? | 14:45 |
| mok0 | ScottK, no | 14:45 |
| mok0 | ScottK, but I know they are wrong | 14:45 |
| persia | mok0, Several of us think it's premature to *replace* all mentions of the previous format, although mentioning the new format as an acceptable option is certainly sensible. | 14:45 |
| ScottK | mok0: I think it would have been good to add examples of the new format, but I think removing the old ones was a mistake. | 14:46 |
| mok0 | ScottK, I see. Personally, I would like to see all new packages have the new copyright format, therefore I don't think it's the right place to display it, | 14:46 |
| mok0 | There could be a reference though | 14:47 |
| ScottK | mok0: I can understand that personal preference, but there is no policy requirement for it and I think it raises the barrier for new contributors. | 14:47 |
| mok0 | ScottK, on the contrary, the new format is much terser and easy to understand | 14:47 |
| mok0 | ScottK, you actually don't need to copy the clause as of the latest updates | 14:48 |
| ScottK | I also think it's perfectly within your rights to say, "The new copyright format isn't required, but if you want me to sponsor it, you'll use it." | 14:48 |
| ScottK | mok0: It has many addiitonal rules about correctness. | 14:48 |
| mok0 | So it's just the 4 header lines + N license stanzas | 14:48 |
| ScottK | So it's more complex to learn to write. | 14:48 |
| slytherin | I agree that new format is easy to understand but that does not necessarily mean we should remove everything related to old format. | 14:48 |
| mok0 | ScottK, those rules are similar to control | 14:49 |
| ScottK | mok0: True but irrelevant. | 14:49 |
| Davedan | I'm using dh_make to build a template for a package. What part is responsible for removing files when the packaged is removed? My package adds a conf file under etc and a script under usr/share/ | 14:49 |
| mok0 | slytherin: I can put a link to a page where it is displayed | 14:49 |
| ScottK | The point is it adds new complexity to packaging. | 14:49 |
| persia | mok0, I argued the same point earlier; The point that convinced me is that the content of the two formats is the same, but the new format has additional requirements in syntax, which creates more opportunities to make mistakes. | 14:49 |
| mok0 | ScottK, I don't agree. | 14:49 |
| slytherin | Davedan: it depends on how you are adding those files. If you are handling them in debian/rules then there is no special handling required for uninstallation. | 14:50 |
| ScottK | mok0: I've never written the new format. Can I do it without learning anything new? | 14:50 |
| mok0 | persia: There are examples you can use | 14:50 |
| mok0 | ScottK, pretty much | 14:50 |
| persia | As much as the new format is simple, it is still in flux, and we still don't have tools to autogenerate a sample, or test correctness. | 14:50 |
| ScottK | mok0: That's a no. | 14:50 |
| persia | mok0, Sure. I also prefer the new format: my point is only that there are additional ways that new packagers can make mistakes, and we don't have any way to validate in an automated fashion. | 14:51 |
| mok0 | The feedback I have gotten from REVU is that uploaders think it is easier | 14:51 |
| mok0 | People like it | 14:51 |
| ScottK | mok0: You are imposing additional requirements that aren't requirements. As a sponsor you are free to do that for stuff you sponsor, but not to change MOTU policy (and that is the practical effect of changing all the docs). | 14:51 |
| Davedan | slytherin: my config file is created in the postinst because it require user input that was acuired with debconf. The script is added using debian/install should I move both to debian/rules? | 14:51 |
| mok0 | ScottK; I can put a link to the old copyright format | 14:52 |
| ScottK | mok0: I think it should be the other way around. The docs should reflect what policy requires with links to alternatives. | 14:52 |
| slytherin | Davedan: if you are using postinst to add the file then you should remove it in postrm in my opinion. | 14:52 |
| mok0 | ScottK, I absolutely am against that | 14:52 |
| ScottK | mok0: The current new copyright format is a draft proposal that can still change. | 14:52 |
| persia | mok0, You're against the documentation matching policy? | 14:52 |
| persia | (and does change, regularly) | 14:53 |
| mok0 | ScottK, yes but it can be changed by programs | 14:53 |
| mok0 | persia: no | 14:53 |
| persia | mok0, No, it can't: there's no parsers available. | 14:53 |
| Davedan | slytherin: and what about the script file that is added using debian/install ? should I add it using debian/rules? | 14:53 |
| mok0 | persia: parser can be written | 14:53 |
| persia | mok0, That's the source of the complaint: that until policy changes (and I hope it does), we ought keep the old format as default, and point people to the new format if they find it easier. | 14:53 |
| mok0 | Well, I stand on my position | 14:53 |
| ScottK | mok0: Not relevant. | 14:54 |
| ScottK | That's still imposing a maintenance burden. | 14:54 |
| persia | mok0, Once it's written, and accepted, I'll agree it's not harder to get right. | 14:54 |
| mok0 | I don't have anything else to add | 14:54 |
| persia | mok0, So, the point of the conversation is to avoid a wiki war. The first mention was someone suggesting they would revert all your changes. | 14:55 |
| mok0 | I am the one who has been doing most reviews this cycle, and it's a waste of everybodys time if people have to write the old format first and then I ask them to change it | 14:55 |
| persia | In the interest of building consensus, how do you think we ought proceed? | 14:55 |
| mok0 | persia: just revert it then | 14:56 |
| ScottK | mok0: I appreciate all the work you are doing, but that does not give you the right to dictate for everyone. | 14:56 |
| mok0 | ScottK, I am not | 14:56 |
| ScottK | mok0: That's what changing all the docs does. | 14:56 |
| mok0 | ScottK, I said we could have a link to the old format | 14:56 |
| mok0 | ScottK, that's because uploaders I work with use those docs | 14:57 |
| ScottK | mok0: So you've unilaterally changed the new, unapproved, still subject to change, format as the primary one. | 14:57 |
| mok0 | ScottK, yep | 14:57 |
| ScottK | I don't care if it's both in the docs. | 14:57 |
| persia | mok0, I'm not comfortable there is consensus in reverting all your work if you don't agree. | 14:57 |
| mok0 | persia: if everyone else agrees what can I say? | 14:58 |
| ScottK | But the standard method (dictated by policy) should be primary. | 14:58 |
| ScottK | mok0: If you want to do this, there is a procedure for changing ubuntu-policy. | 14:58 |
| mok0 | ScottK, whatever | 14:58 |
| Juli_ | slytherin, persia : Hi, thank you a lot for uploading the netbeans package. I've seen your discussion about the problem with update icon in the right corner. Do I understand you correctly: you don't want to see that update icon? | 14:58 |
| ScottK | mok0: I suggest you follow that policy and see if there is support in the developer community to change in Ubuntu. | 14:58 |
| persia | mok0, I don't know that everyone else agrees. I agreed with you when I last woke up, and was convinced. | 14:59 |
| slytherin | Juli_: I will report a bug sometime next week with all the necessary information. | 14:59 |
| Juli_ | slytherin: ok, I'll be waiting. Thanks! | 14:59 |
| persia | Juli_, Well, we generally don't prefer that applications update themselves from external sources, as it makes it hard to publish bugfixes, etc. Just hiding the UI doesn't help much. | 15:00 |
| slytherin | persia: I believe auto-update-by-itself is not the case here. azureus does that. :-( | 15:01 |
| Juli_ | persia: it is impossible to switch off update center, you know. | 15:01 |
| * Laney is being spammed by britney | 15:02 | |
| persia | Juli_, Yes, I know, and I also know that none of NetBeans, Debian, and Ubuntu have the combined resources to package all the useful plugins available from update center. | 15:02 |
| slytherin | Juli_: hows does the update centre work? where will it download the updates? | 15:03 |
| slytherin | I don't mind people downloading plugins through auto update center. But I think at no point of time they should be able to update the whole application itself. | 15:04 |
| Juli_ | slytherin: ok, I'll collect all the information about UC and send it to | 15:04 |
| sistpoty|work | mok0: are there tools for the new copyright format yet? | 15:04 |
| mok0 | persia: Just revert my change. I understand that the culture here is nothing ever must change. I've contributed lots of suggestions and documentation in the hope that it gets picked up but no-one cares a damn. Then when I change some documentation that makes my work easier, everybody complains. I am simply fed up with this culture of nothing-must-change-before-we-all-agree-but-we-never-come-to-decisions-anyway | 15:04 |
| Juli_ | slytherin: I think I can do that | 15:04 |
| slytherin | Juli_: Don't do it right now. I will file a bug after more investigation. | 15:04 |
| mok0 | sistpoty|work: Its RFC822 format, | 15:04 |
| persia | mok0, I disagree strongly with that assertion. I've seen lots of things change, and I expect this to change, I've just been convinced it's premature. | 15:05 |
| sistpoty|work | mok0: but are there tools to e.g. list which source file corresponds to which license? or s.th. that would fit in with licensecheck? | 15:05 |
| mok0 | sistpoty|work: You could even make a program or webpage that helps you generate it | 15:05 |
| Juli_ | slytherin: ok, and I'll also investigate what i can do | 15:05 |
| mok0 | persia: It's not an assertion, it's my personal impression | 15:05 |
| sistpoty|work | mok0: sure, I've actually been thinking about doing that, but I'd prefer if I could just use such a tool instead of having to write one myself :P | 15:06 |
| mok0 | sistpoty|work: so do I :-) | 15:06 |
| sistpoty|work | mok0: and so far I haven't sadly found one tool... and hence I'm thinking that the new format is not of too much use for myself yet | 15:06 |
| sistpoty|work | :/ | 15:06 |
| persia | slytherin, One issue is that some plugins require new modules, and some of those modules happen to be bits we packaged. Update Center would have a hard time determining what jars came from packaging and what jars came from Update Center, with the current implementation. | 15:06 |
| sistpoty|work | mok0: (apart from a not yet applied patch against lintian, which seems to need more work) | 15:07 |
| sistpoty|work | (or was it against licensecheck?, not too sure) | 15:07 |
| === pochu_ is now known as pochu | ||
| mok0 | sistpoty|work: The modules in python-debian could parse it, with minor additions | 15:07 |
| slytherin | persia: if theer is any configuration which says 'dont update the modules i tell you' then we could ship that configuration by default. | 15:07 |
| mok0 | sistpoty|work: look at how the changes file class etc. are defined, it's a few lines of code | 15:08 |
| sistpoty|work | mok0: i.e. parse the actual copyright format or just the rfc 822 format? the former would allow me to at least check if it's syntactically correct, the latter not | 15:08 |
| persia | slytherin, I don't know of that configuration, but I'll admit to not having looked at the Update Center code in about 7 years :) | 15:08 |
| mok0 | sistpoty|work: the copyright format | 15:08 |
| persia | Juli_, ? | 15:08 |
| sistpoty|work | mok0: oh, cool... /me needs to checkout these... thanks! | 15:08 |
| mok0 | sistpoty|work: it's 100% similar to debian/control, except the keywords | 15:08 |
| slytherin | persia: I haven't looked at all. :-) | 15:08 |
| Juli_ | persia: it will be useless configuration I afraid | 15:09 |
| sistpoty|work | mok0: it's not that trivial iirc, the keywords are specified in the wiki together with the version where such a keyword is valid... does python-debian do that already? | 15:10 |
| persia | Juli_, Yeah, that's what I thought. How much has the Update Manager code changed? Is it still mostly the same? | 15:10 |
| mok0 | sistpoty|work: Do you mean like using a DTD? python-debian does not do that. | 15:11 |
| sistpoty|work | mok0: yep, something like that... hm... | 15:11 |
| mok0 | sistpoty|work: It's structured into the code | 15:11 |
| Juli_ | slytherin: hmmm... I think I know an engineer who is working on UC. I can ask him everything you want to know, but I want to understand what is expected behaviour of the IDE for you | 15:12 |
| slytherin | Juli_: right, that is the reason I said, wait for next week. :-) | 15:12 |
| sistpoty|work | mok0: ok, I'll give it a look nonetheless... thanks again for the hint :) | 15:12 |
| mok0 | sistpoty|work: in any case, it's really not necessary to implement a who lot of keywords, just the header and the license stanzas | 15:12 |
| mok0 | s/who/whole | 15:13 |
| Juli_ | persia: i think not so much changes for this problem | 15:13 |
| sistpoty|work | mok0: and the version where one is valid (which sounds like the most work to me) | 15:13 |
| mok0 | sistpoty|work: You mean the Formatspefication? | 15:14 |
| sistpoty|work | mok0: yes | 15:14 |
| sistpoty|work | mok0: so that I could e.g. check if a machine readable copyright is actually correct or not ;) | 15:14 |
| mok0 | sistpoty|work: But there are no versions implemented yes afaik | 15:15 |
| persia | One it's possible to validate using a tool available in the distro (even only in the development release), I'd probably be more strongly in favour of instructing everyone to switch. | 15:15 |
| mok0 | persia: Is there a validator for debian/control? | 15:16 |
| persia | mok0, Well, lintian tries awfully hard to be one. | 15:16 |
| Juli_ | persia: slytherin: One idea: I think it is possible to introduce specific Update center for the packaged netbeans. We can put there only allowed updates. | 15:16 |
| slytherin | Juli_: got to go, will discuss later. | 15:17 |
| persia | Juli_, That's an interesting case, and might then allow migrating to distro-packaged modules in the future for parallel lines of support. Let's discuss by mail or in the bug slytherin will file, and think about the implications. | 15:17 |
| mok0 | persia: in that case it's probably best to wait until lintian gets the checks | 15:18 |
| Juli_ | persia: ok, will discuss later. | 15:18 |
| persia | mok0, That's the viewpoint I've come to as well. We just have to get the new format to stabilize enough that we can get patches applied. squeeze opening ought help, or if the format is known-stable, we could do an Ubuntu-specific patch (but I'd *hate* for the format to change after that, invalidating lots of files). | 15:21 |
| mok0 | wiki reverted, I wont touch it again | 15:23 |
| directhex | ScottK-desktop, heh. you learn to dodge the peanuts after a while | 15:25 |
| persia | mok0, On the contrary, please do once we can declare the new format to be the default. | 15:25 |
| mok0 | persia: You know I can't figure out when it's ok to do what | 15:25 |
| mok0 | persia: Instead of updating the introduction to motu, I wrote a draft which nobody cares about. | 15:26 |
| persia | mok0, I know how that feels. I wrote MOTU/Contributing a long time ago, and it was ignored when MOTU/GettingStarted was created. | 15:27 |
| persia | mok0, My best advice would be to schedule a MOTU Meeting, and arrange for a decision to be taken. | 15:27 |
| mok0 | persia: that whole wiki is a f.cking mess and nobody gives a damn... except when you try to update it with things that are useful. | 15:28 |
| directhex | ScottK-desktop, i'd love to see people have a play with Qyoto - i'm not dogmatic about gtk, and it'd be nice if people with a c# background could develop high quality kde apps | 15:29 |
| persia | mok0, There's been a couple attempts to clean it up, and the MOTU/Leaders position of Wiki General is currently unfilled (I stepped down in Gutsy, and nobody else wanted it). | 15:29 |
| mok0 | persia: don't look at me | 15:29 |
| mok0 | persia: I tend to work and do things and that's not popular around here | 15:30 |
| persia | mok0, I'm not looking at you, just describing the nature of the issue. | 15:30 |
| mok0 | persia: good :-) | 15:30 |
| persia | (mind you, if you volunteered, that's welcome :) ) | 15:30 |
| mok0 | Ok, sorry, I am in a bad mood I should take a break | 15:30 |
| persia | And doing things *ought* be popular! | 15:30 |
| mok0 | persia: it's not | 15:31 |
| mok0 | persia: you can't do things that haven't been decided, and no decisions are ever made | 15:31 |
| mok0 | persia: It | 15:31 |
| persia | That's because nobody every schedules MOTU Meetings. We have a decision process. We just need to use it. | 15:32 |
| persia | s/every/ever/ | 15:32 |
| mok0 | persia: well nobody has the power to decide when motu meetings are going to be | 15:32 |
| persia | mok0, On the contrary, any MOTU has the power to decide when MOTU Meetings are scheduled (although it's polite to give over a week's notice, and they are traditionally on Fridays). | 15:33 |
| mok0 | persia: they should just be scheduled every 2 weeks regularly | 15:34 |
| mok0 | persia: those that show up decide | 15:34 |
| persia | They used to be, but I lost track of scheduling them and sending out announcements, etc. and nobody else picked it up. | 15:34 |
| persia | Would you be up for coordinating the scheduling, and sending the announcements, and rotating the time? | 15:35 |
| mok0 | persia: Ask me another day | 15:35 |
| * persia still has too big a stack of things-that-ought-to-have-been-done-last-cycle | 15:35 | |
| persia | mok0, I'll try to remember :) | 15:35 |
| loic-m | Does anybody know how some upstream maintain a debian directory while not shipping it in there tarball (and not providing two tarball either)? | 15:44 |
| LucidFox | loic-m> smplayer maintains a separate debian-rvm directory for upstream packaging | 15:45 |
| LucidFox | in the tarball | 15:45 |
| LucidFox | or do you mean having a debian directory in the VCS but not tarball? | 15:45 |
| sistpoty|work | loic-m: I'm using a different repository for debian directories that I maintain upstream wise | 15:45 |
| persia | loic-m, They just exclude it from the VCS export when generating release tarballs. | 15:45 |
| loic-m | LucidFox: So they ship it, and other packagers remove it? | 15:46 |
| LucidFox | loic-m> They ship it, but since it's called debian-rvm rather than debian, it doesn't interfere with Debian/Ubuntu packages | 15:46 |
| LucidFox | upstream has a script to build its own packages using this directory | 15:46 |
| persia | loic-m, That happens sometimes, and sometimes it's overridden (or one uses --ignore for debhelper), but we generally ask upstream not to include debian/ in the release tarballs. | 15:46 |
| loic-m | To be more specific, xvidcore upstream says they tried not shipping debian/ before, but Debian users complained | 15:47 |
| loic-m | And i don't know if there's a solution that would solve that issue, LucidFox idea doesn't sound bad | 15:47 |
| loic-m | I just need to see if there's a solution that would address both issues (individual users that want to build their own packages, and maintainers that prefer not to repackage the tarball) | 15:48 |
| LucidFox | I applied the same idea to arora, and added a debian-upstream directory and a script that temporarily symlinks it to debian, builds the package, and removes the symlink | 15:49 |
| jelmer | is there any change somebody could re-review bzr-webdav on REVU ? | 15:53 |
| jelmer | It was already advocated by james_w earlier, but I just uploaded a version that merged a newer upstream release, and that seems to've bumped it back down again | 15:53 |
| persia | jelmer, Indeed, new uploads cancel advocations. That said, many reviewers only accept latest-upstream, so it's probably good you uploaded. | 15:54 |
| loic-m | persia: can you explain in what situation it's overriden (and what "overriden" means in that context)? | 16:02 |
| persia | loic-m, When it doesn't need to be moved aside, and by replacing large chunks of it with patches in diff.gz | 16:06 |
| DktrKranz | directhex: thanks for including my name :) | 16:07 |
| Laney | DktrKranz: You love a good transition, eh? ;) | 16:07 |
| loic-m | persia: ok. In the case of xvidcore though, there's already been an Ubuntu packaging for quite a while | 16:08 |
| directhex | Laney, he's got a world of libs in front of him :p | 16:08 |
| Laney | yay! | 16:08 |
| DktrKranz | Laney: we managed a toolchain transition via SRUs, so yes, I love transitions :) | 16:09 |
| Laney | woop | 16:09 |
| DktrKranz | this does not imply I did it correctly ;) | 16:09 |
| persia | loic-m, So, if you take the xvidcore upstream, delete debian/ add the Ubuntu debian/ edit to match the new upstream, you end up masking the upstream debian/ in diff.gz, unless upstream included some file that isn't in the Ubuntu packaging, in which case you either need to repack or pass --ignore to debhelper. | 16:10 |
| loic-m | Is there a quick way to check if a binary (or a binary package) has been compiled with assembler support (nasm/yasm)? | 16:10 |
| loic-m | persia: I'm not sure I'm up to decide if we want to to match the new upstream debian | 16:13 |
| persia | loic-m, Fair enough. I'd recommend giving a merge a try, and asking here for review of any bits you have questions about. | 16:14 |
| loic-m | persia: Ubuntu's packaging differs quite a bit, and I've got no clue if upstream packaging is really up to date (the changelog have been done for a while by a dev that says he doesn't know much about packaging) | 16:14 |
| persia | That said, it's close enough to FeatureFreeze, you might find reviewers short of time. | 16:14 |
| persia | If the upstream packager says he doesn't know much about packaging, I'd recommend just using the Ubuntu packaging as a base. | 16:15 |
| loic-m | persia: I already have a working packaging | 16:15 |
| persia | Then what's the problem? | 16:15 |
| loic-m | persia: I asked like two days ago if it was ok to start working on it, since I didn't want to spend time on it for nothing | 16:16 |
| loic-m | persia: and I already spent a lot of time on it too, and also got in touch with upstream | 16:16 |
| persia | These are good things... | 16:16 |
| loic-m | persia: I'm mostly trying to make sure I don't say anything wrong to upstream | 16:17 |
| loic-m | persia: see http://list.xvid.org/pipermail/xvid-devel/2009-February/thread.html | 16:18 |
| persia | Our recommendation is that upstream not ship debian/ in the release tarball. When upstream wants to do it, we usually patch it heavily in diff.gz or repack if required. | 16:18 |
| loic-m | persia: that'zs my draft answer: http://paste.ubuntu.com/119732/ | 16:18 |
| persia | loic-m, 1) Debian Users != Debian Packagers | 16:19 |
| loic-m | persia: I already wrote get-orig-source for repackaging, but I'd like to see if there's solutions i can offer upstream so we don't have to repackage in the future | 16:19 |
| persia | Also, it doesn't matter what name is used in the tarball: dpkg does the right thing. | 16:20 |
| loic-m | persia: I know, but ideally Debian users should have somewhere else to turn than upstream | 16:20 |
| persia | Just patch it in the diff.gz | 16:20 |
| loic-m | persia: you're talking about the xvidcore directory name, or the debian/ ? | 16:20 |
| persia | 2) Ideally, directory indexing would be enabled for http://downloads.xvid.org/downloads/ | 16:20 |
| persia | the xvidcore directory name doesn't matter in the least, because dpkg is smart. | 16:21 |
| persia | debian/ can be patched in diff.gz | 16:21 |
| loic-m | persia: so that's what I could propose to upstream for 2) ? | 16:21 |
| persia | Actually, I got confused. s/2/1B/ | 16:21 |
| loic-m | persia: about debian, I already remove debian during repackage of the archive | 16:21 |
| persia | You probably don't need to do that. Try not doing it, and see if it works. Most of the time you can just patch it in diff.gz. | 16:22 |
| directhex | DktrKranz, anyway, i think it's massively important to tell people when they've helped you out, hence the email | 16:23 |
| loic-m | persia: you mean leave upstream debian, the copy/paste our files, and edit the files with the same names? | 16:23 |
| loic-m | s/the/then | 16:23 |
| persia | Well, I'd leave the upstream debian/ in the upstream tarball, delete it from the package directory, and add the Ubuntu packaging and see what happened when I built a source package and unpacked it. | 16:24 |
| persia | If there were extra files that were leftovers from the upstream tarball, I'd delete the contents (patch can't delete a file, but it can reduce it to 0 bytes), and try again. | 16:24 |
| persia | If the result built, I'd call it done, and be happy not to need to repack. | 16:24 |
| loic-m | persia: I'm getting lost. I thought that kind of patching in the diff.gz was messy (I hate it when I encounter it in a package) and that also mean it won't apply if upstream modify debian/ substantially | 16:26 |
| loic-m | persia: I although got advised to repack each time I had to deal with an upstream debian/ | 16:27 |
| persia | Well, I prefer messiness to repacking, but yes, it's messy and ugly. | 16:27 |
| persia | I suspect that most of the people who advised you learned to do that before --ignore was introduced :) | 16:27 |
| loic-m | persia: considering I already wrote the get-orig-source rule, and considering i won't ever want to look at xvidcore packages if I follow your advices, do you mind if I don't follow your advice this time? | 16:28 |
| persia | Not at all :) | 16:28 |
| persia | I'm even more unlikely to look at the xvidcore packages. | 16:29 |
| loic-m | persia: ok, that's good ;) | 16:29 |
| loic-m | persia: about upstream, your advice is to drop trying to get them to change the debian/ situation, and drop the advice to name the folder xvidcore-version? | 16:30 |
| persia | Renaming the folder is pointless: doesn't really help us, and requires them to change their scripts. | 16:32 |
| persia | If you use uscan, you end up with a renamed orig.tar.gz anyway, which dpkg can use. uupdate can also use it. | 16:32 |
| persia | Describing the reasons why you would prefer to drop debian/ (or use something like debian-upstream/) is worth it. | 16:33 |
| === dholbach_ is now known as dholbach | ||
| persia | Tell them you can repack (bad because you can't preserve md5sum compatibility with the download from their website), or patch it (bad because it makes maintenance harder), but you can't use it directly. | 16:33 |
| loic-m | persia: that's really good arguments (and I never thought about the md5sum problem), thanks a lot | 16:35 |
| persia | loic-m, If they don't want to not have debian/ let them have it: it's not that important. | 16:36 |
| persia | The important thing is getting directory indexing enabled on /downloads/ | 16:36 |
| loic-m | persia: about the directory name, without the get-orig-source target I end up with a directory "xvidcore" and debuild throws errors (pbuilder might not care though) | 16:36 |
| persia | When you package it, name the directory correctly. That matters. The contents of the tarball don't matter. When the tarball is unpacked, it's done in a way that uses the correct directory name (check the dpkg source for details) | 16:37 |
| loic-m | persia: "directory indexing" I'll ask - I don't really know what it is though - is it a html page generated/indexed automatically, each time a tarball is added/removed in a directory? | 16:38 |
| loic-m | persia: thanks for the clarifications | 16:38 |
| persia | It basically shows the files in the directory, with no HTML page. The NBS page is a good example of the result. | 16:38 |
| loic-m | persia: I'll do that | 16:38 |
| Wulfie | hello folks, I have a package I wish to get included into Universe. I can have a mostly complete package ready for tomorrow but I am concerned it has not had the testing it requires. If I submit a package and it needs to be updated can that happen after the Feb 19 feature freeze? | 16:39 |
| sistpoty|work | Wulfie: if it makes it in by feature freeze, bugs can be fixed afterwards | 16:40 |
| loic-m | Now, about the few source files missing a copyright and a license, I think we're not as hard on it as Debian, so it should be ok, no? | 16:40 |
| persia | Wulfie, bugfixes are welcome. New features are not. Be aware there is a largish queue of stuff that is awaiting review, so your package may not get the attention in time. | 16:40 |
| sistpoty|work | Wulfie: however we try to restrict new packages to only enter after feature freeze if there's a very, very, very, very good rationale for it ;) | 16:40 |
| persia | loic-m, No, it's not OK. We permit more licenses than Debian in our "free" components, but we do require things be licensed appropriately. | 16:41 |
| * sistpoty|work missed a very, as I hope we'll soon be 5 people in motu-release again *g* | 16:41 | |
| Wulfie | I was reading on the wiki it requires two MOTU's to review regardless of the queue and things may be able to side-step. Do you think there would be interest from the MOTU to review a free Cedega package? | 16:41 |
| sistpoty|work | Wulfie: I assume many MOTUs are quite busy due to the impeding feature freeze, but asking here for reviews is the best thing you can do right now ;) | 16:43 |
| Wulfie | sistpoty|work: thanks | 16:43 |
| loic-m | persia: the files has been in Ubuntu for a while - most of xvidcore source files have copyright+license headers, a few (about 10) don't have anything, mostly amd64 asm | 16:47 |
| loic-m | persia: but upstream explicitely says all the code is released under GPL-2+ | 16:47 |
| loic-m | persia: I'm not sure what's the legal opinion on the matter | 16:48 |
| persia | loic-m, If you're not changing the copyright status of a file, it's usually safe (but that's a bug, and it's the sort of bug that could be the basis for removal in some cases, depending on the specifics). | 16:48 |
| persia | If you're adding new files without licensing, or dropping/changing licensing on files, it's a good idea to check with an archive-admin. | 16:48 |
| loic-m | persia: those files have been in xvidcore source packages for quite a while, so it should be ok | 16:50 |
| persia | Well, it's not really OK, but it's not worse, which is good enough. | 16:51 |
| persia | If you can get upstream to add proper licensing support (perhaps by submitting a patch based on their description of the state of things) for a future release, that would be lovely. | 16:51 |
| loic-m | persia: just for my information, if I wanted to help upstream (thinking about another project not packaged yet) solve those kinds of issues, is it enough to mail the supposed authors and request them to release the failes with a compliant header? | 16:51 |
| loic-m | persia: the authors for those files where students, they're not on the project AFAIK, but upstream might still have their contact info | 16:52 |
| ScottK | Or upstream may have other information that lets them safely add the information. | 16:53 |
| persia | loic-m, I generally recommend preparing a patch that would include the appropriate headers, etc, and sending it to both the upstream project and the copyright holder, asking the copyright holder to authorise it's application in the VCS. | 16:53 |
| loic-m | persia: I'll try to get the authors names upstream (I don't know who wrote the files) and do that if they can remember who wrote it | 16:54 |
| persia | loic-m, You might also check the VCS logs to see if it's attributed to someone there. | 16:55 |
| c_korn | can't I upload using debuild -S -sd when orig file already uploaded before? | 16:55 |
| ScottK | c_korn: No to revu | 16:56 |
| ScottK | No/Not | 16:56 |
| c_korn | hm, ok | 16:56 |
| persia | ScottK, Good point. | 16:56 |
| loic-m | Is there a way to check a binary and see if asm support has been enabled ? I'm testing a slowdown between xvidcore 1.1.2 and 1.2.1, and can't tell if 1.2.1 has or not asm enabled (even though it's enabled in the control file) | 16:58 |
| loic-m | ScottK: thanks. Indeed they do for some of the files (at least they know the license the files have been produced under, not sure if they tracked who wrote what during the code sprint at the university) | 16:59 |
| ScottK | loic-m: Well at least getting the license right is a start. | 17:00 |
| loic-m | ScottK: indeed | 17:01 |
| === cody-somerville_ is now known as cody-somerville | ||
| sistpoty|work | hm... what range does a char have on armel, powerpc? is it somehow unsigned there? (looking at http://launchpadlibrarian.net/22809018/buildlog_ubuntu-jaunty-armel.fauhdlc_20090213-0ubuntu1_FAILEDTOBUILD.txt.gz) | 17:04 |
| sistpoty|work | ^ the comparison is if (digitValue == -1) , and digitValue is: char digitValue; | 17:04 |
| tedb | Hi all -- I work at a midsize ISP and am thinking about how I can host an Ubuntu repo mirror for our customers. I was referred to this chan from #ubuntu. Has anyone done that? | 17:05 |
| persia | tedb, Although it will feel like an endless maze, I'd recommend #ubuntu-mirror (or #ubuntu-mirrors). Some of the mirror admins hang out there. | 17:06 |
| ScottK | sistpoty|work: NCommander is probably the best one to ask about that. | 17:06 |
| tedb | ah ok, thanks persia! | 17:06 |
| sistpoty|work | NCommander: read the question above? ;) | 17:06 |
| c_korn | what is the MOTU Team's mail address I should set as Maintainer in debian/control? | 17:07 |
| persia | c_korn, ubuntu-motu@lists.ubuntu.com | 17:07 |
| NCommander | hrm? | 17:09 |
| NCommander | sistpoty|work, ? | 17:09 |
| sistpoty|work | NCommander: what range is a "char" on powerpc, armel? is it somehow unsigned? | 17:09 |
| sistpoty|work | NCommander: http://launchpadlibrarian.net/22809018/buildlog_ubuntu-jaunty-armel.fauhdlc_20090213-0ubuntu1_FAILEDTOBUILD.txt.gz | 17:09 |
| NCommander | a part of me wants to say yes | 17:10 |
| NCommander | But [citation needed] on my part. | 17:10 |
| sistpoty|work | NCommander: it's a comparison of a char against -1 which fails | 17:10 |
| NCommander | I think chars in general are supposed to be unsigned, I don't remember seeing a case where a signed char didn't toss a warning | 17:10 |
| sistpoty|work | NCommander: on all other arches apart form armel and powerpc :P | 17:11 |
| NCommander | some compiler backends are picker than others ;-) | 17:11 |
| sistpoty|work | heh | 17:11 |
| __iron | ScottK: around ? | 17:18 |
| AndrewGee | Hey. Still looking for a MOTU to review gpxviewer :) It's an application to look at GPS tracks. Would appreciate a review :) Thanks. http://revu.ubuntuwire.com/details.py?package=gpxviewer | 17:18 |
| ScottK | __iron: Sort of | 17:19 |
| __iron | ^^ | 17:19 |
| __iron | ScottK: pm | 17:20 |
| quadrispro | sistpoty|work: hi Stefan, what do you think about syncing/merging new ghc6 from debian? | 17:37 |
| ScottK | quadrispro: You know that means you have to rebuild all the rdepends, right? | 17:38 |
| sistpoty|work | quadrispro: one day before FF starting a haskell transition? I don't really think that's a good idea | 17:38 |
| ScottK | In the right order .... | 17:38 |
| quadrispro | eh, I agree with you, I'm just looking at user requests | 17:39 |
| quadrispro | bhe, we will do it for jaunty+1 | 17:39 |
| sistpoty|work | well, if ghc6 only meant support for haskell development, I'd agree, as I have the feeling that haskell devs always cry for the latest version | 17:40 |
| ScottK | sistpoty|work: It occurs to you to mention that we did https://wiki.kubuntu.org/Kubuntu/Ninjas/DependencyGraph for KDE build sequencing. I thought the format might be useful for documenting how you do a Haskell transition. | 17:40 |
| sistpoty|work | however there are also some apps in the archive (I assume darcs being the most prominent) which really shouldn't be broken as a result | 17:40 |
| quadrispro | ScottK: it looks really useful! | 17:41 |
| ScottK | sistpoty|work: Maybe in the future a ghc6-next package with the latest. | 17:41 |
| sistpoty|work | ScottK: nice... I tried to make a similar graph some time ago, but I must admit that the haskell world changed a bit and my graph was useless :( | 17:41 |
| ScottK | quadrispro: It was really hard to keep track of before. | 17:41 |
| ScottK | sistpoty|work: One of the nice things is it's easy to change. Took me about 5 minutes the first time I updated it. | 17:41 |
| sistpoty|work | ScottK: oh, *now* I see it, that's a dot graph... good idea :) (I just used a graphic program directly :/) | 17:43 |
| ScottK | It was apachelogger's idea. | 17:44 |
| quadrispro | it's really easy to prepare... good | 17:44 |
| quadrispro | ScottK: have you got some minutes to spend in a little review? | 17:45 |
| ScottK | quadrispro: Not currently. I'm trying to fix an upstream release I hope to get in before FF. | 17:46 |
| quadrispro | ah ok ;) | 17:46 |
| * quadrispro going to have dinner | 17:46 | |
| === jmarsden_ is now known as jmarsden|work | ||
| * sistpoty|work wonders if such a graph could be created automatically with the help of build-rdeps (and maybe a tiny script around it) | 17:47 | |
| persia | sistpoty|work, Most definitely, although I suspect you'd get better performance parsing a (possibly constructed) apt-cache directly into some data structure, and using that. | 17:51 |
| Laney | Can I upload a new version of a package that still sits in binary NEW? | 17:52 |
| sistpoty|work | persia: I'm actually out for ease of writing, as I wouldn't create such a diagram more than once per cycle :P | 17:52 |
| === ssweeny_ is now known as ssweeny | ||
| persia | sistpoty|work, Oh, I was thinking it might be interesting to have a general tool that took a set of source packages as arguments and generated such a graph as part of ubuntu-dev-tools to ease transitions and management for everyone. | 17:53 |
| persia | Perhaps with an optional release argument so one could check the impact of an SRU or the like. | 17:54 |
| sistpoty|work | persia: sure, why not... but even then, who thinks it's too slow could still send patches :) | 17:54 |
| persia | Well, it would be a rewrite. I could probably create something that constructed an arbitrary apt-cache, and pushed it into some data structure, but I'm not sure I could write the bit that used that to build useful sets, or graphs therefrom. | 17:55 |
| sistpoty|work | persia: well, if you'd write such a thing, then I wouldn't need to :P (and also it was just an idea, more in the terms of write s.th. but don't spend more than 10 minutes doing so) | 17:57 |
| persia | Well, I was more offering to collaborate :) I have scripts that generate arbitrary apt-caches and others that parse structured text, so could probably toss that part together quickly (but not before FF). I'm just not confident with my ability to convert the data structure into something that dot can parse, etc. | 18:02 |
| ScottK | persia: From a ghc6 perspective this isn't needed until next release cycle anyway. | 18:03 |
| ScottK | So no rush. | 18:03 |
| ScottK | I could see other uses though. | 18:03 |
| sistpoty|work | heh... /me hopes persia will have forgotten about my idea by then, or at least that I had it so that I don't need to actually write code *g* | 18:04 |
| persia | True, but I'd still need someone for the other half. | 18:04 |
| persia | sistpoty|work, I think it's a brilliant idea, and I'm not telling you to write code. I just know I won't get around to writing all of it (although I could write some of it quickly). | 18:04 |
| sistpoty|work | heh | 18:05 |
| Laney | persia: If you push up a branch people (maybe even me) could assist | 18:05 |
| persia | Laney, OK. What language would be least bad for that? Personally, I'd prefer make, but could fall back to shell or perl. | 18:06 |
| sistpoty|work | anyway, /me calls it a day now and decides to head home... cya | 18:07 |
| ScottK | Python probably has the most chance of getting help. | 18:07 |
| Laney | No preference, and no real reason it should be one single language if it's modular enough | 18:07 |
| Laney | I'd probably use Python | 18:07 |
| persia | Right. Somehow I don't think my branch would be useful :) | 18:09 |
| ScottK | persia: Even a working prototype in make or whatever would be helpful. | 18:09 |
| persia | ScottK, The problem is mostly that I don't know dot and probably will block completing it on learning it, which would delay things considerably. | 18:10 |
| ScottK | OK. | 18:10 |
| persia | Would a script that just generated limited textual data recursively from some set of starting points be useful? | 18:11 |
| persia | (assuming the textual data to be well-formed and documented). | 18:12 |
| ScottK | I would imagine so. | 18:23 |
| persia | OK. That's relatively easy then. I'll toss up a PoC branch sometime after FF. | 18:25 |
| === jorge___ is now known as jcastro | ||
| === bluesmoke_ is now known as Amaranth | ||
| loic-m | I've got a package that doesn't want to get build with asm code anymore | 19:10 |
| loic-m | the control file is identical | 19:10 |
| persia | It built before? | 19:11 |
| loic-m | And debuild checks for nasm/asm... where should I look for to troubleshoot the error? | 19:11 |
| loic-m | It builds as version 1.1.2 | 19:11 |
| loic-m | version 1.2.1 builds, but without assembler support | 19:11 |
| loic-m | I figured a way to check (not just timing an encode): 1.1.2 fails to build i386 bin on an amd64 arch, which is expected. | 19:12 |
| loic-m | 1.2.1 doesn't fail, which means it doesn't use the asm code | 19:12 |
| anakron | HI all | 19:12 |
| anakron | ping Laney | 19:12 |
| anakron | :) | 19:13 |
| persia | loic-m, Are the build scripts the same? | 19:13 |
| loic-m | I'm at a loss... Upstream ship with a debian/, and I've got the same pb with their packaging > no asm in the resulting binaries | 19:13 |
| persia | I suspect a difference in the build system for the package. | 19:13 |
| loic-m | persia: build scripts? What are those?$ | 19:13 |
| persia | anakron, It's best practice to provide content with pings, like: | 19:13 |
| loic-m | you mean configure/make? | 19:14 |
| persia | anakron, Hey: I'm reading your ping, and noticed it didn't contain any content. | 19:14 |
| persia | loic-m, Yep. | 19:14 |
| anakron | :) ok | 19:14 |
| anakron | Did you talk with my brother mruiz persia? :) | 19:14 |
| persia | I have. | 19:15 |
| anakron | i make a mistake persia in all my desktop bugs | 19:16 |
| persia | Oops! Lots of patches to file, I suspect :) | 19:16 |
| anakron | i set path to icons instead it's name | 19:16 |
| anakron | XD | 19:16 |
| anakron | like 4 | 19:16 |
| anakron | so im changing this | 19:17 |
| anakron | some things like icon path | 19:17 |
| anakron | and xpm icons | 19:17 |
| persia | Remember also not to use an extension for the icons | 19:17 |
| anakron | im changing this | 19:17 |
| Laney | anakron: hi! | 19:19 |
| anakron | you are my mentor | 19:19 |
| Laney | \o | 19:19 |
| anakron | sorry, but i read it yesterday because i got lots of mails and the one that says it is from 15 days ago | 19:20 |
| anakron | :) | 19:20 |
| loic-m | persia: There's differences, and some of them (maybe most of them, at least in configure) are related to nasm/yasm, partly for detection (could be the problem) but they go way over my head | 19:20 |
| persia | loic-m, That's probably it then. Might ask upstream. | 19:21 |
| Laney | anakron: It's no problem | 19:22 |
| Laney | so have you worked on any bugs yet? | 19:22 |
| anakron | mmm | 19:22 |
| anakron | i made some patches | 19:22 |
| anakron | like 0 | 19:22 |
| loic-m | persia: I'll do that, hopefully they can figure it out | 19:22 |
| anakron | ops! | 19:22 |
| anakron | like 10 | 19:22 |
| anakron | but accepted by ubuntu, 3 | 19:22 |
| anakron | some to upstream | 19:22 |
| loic-m | persia: thanks for the advices (I was only looking in debian/) | 19:22 |
| anakron | and im repairing some of them now | 19:23 |
| Laney | cool | 19:23 |
| Laney | ping me for sponsorship on a couple | 19:23 |
| anakron | ok | 19:24 |
| Laney | I will see if I can find something fun to work on | 19:25 |
| slytherin | the new queue size is growing by the hour. :-) | 19:27 |
| stefanlsd | FF happens at the end of thursday right? so we got like 24 hours or so? | 19:28 |
| directhex | slytherin, you pinged me earlier, can you please remind me why? | 19:29 |
| slytherin | stefanlsd: depends on the timezone for FF | 19:29 |
| slytherin | directhex: did you get anyone to sponsor your debdiff for moon? | 19:30 |
| directhex | slytherin, i think Laney is doing it right now - i realised i have a large itanium box at work & tested that configure & build work with the patch | 19:30 |
| Laney | sure am | 19:30 |
| slytherin | ok | 19:30 |
| stefanlsd | and stuff subscribed with u-u-s is still considered in before FF? | 19:30 |
| Laney | I forgot what I was doing and looked at REVU though | 19:31 |
| * Laney is absent-minded | 19:31 | |
| slytherin | stefanlsd: not sure. | 19:31 |
| stefanlsd | mm. i think it was like that last FF | 19:31 |
| === asac_ is now known as asac | ||
| stefanlsd | Laney: can i grab that smstools merge? | 19:35 |
| Laney | what merge? | 19:36 |
| Laney | (yes) | 19:36 |
| stefanlsd | Laney: yeah. k | 19:36 |
| chubby | hello | 19:41 |
| chubby | i have an problem with ubuntu 8.10 and network manager within umts | 19:41 |
| Gumby | Hi all, I asked this question in #ubuntu and was told I might have a better chance of finding the answer here | 19:41 |
| chubby | where i can specify the device file for my umts card? | 19:42 |
| Gumby | Does anyone here know what specifies which config files are placed in a packages .conffile locate in /var/lib/dpkg/info/ ? I am trying to figure this out so a package I am creating does not have a specific file overwritten during a package version upgrade. | 19:42 |
| loic-m | persia: the nasm/yasm problem with xvidcore is apparently solved in tatest nasm upstream | 19:44 |
| loic-m | http://sourceforge.net/tracker2/?func=detail&aid=2593349&group_id=6208&atid=106208 | 19:45 |
| persia | Ah. That's a little harder to pull at this point in the cycle. | 19:45 |
| ubottu | Sourceforge bug 2593349 "-v outputs to stderr due to post-2.05.01 change" [Pri: 5,Closed fixed] | 19:45 |
| slytherin | loic-m: backport the fix | 19:47 |
| slytherin | chubby: This is a developer channel. Please ask in #ubuntu | 19:48 |
| loic-m | slytherin: that's out of my league | 19:49 |
| chubby | slytherin: i came from there | 19:49 |
| slytherin | loic-m: why? | 19:49 |
| persia | chubby, You were sent here? | 19:50 |
| loic-m | slytherin: because I don't know programming, because I'll have to learn to use a few tools I've not used before (svn for example) | 19:51 |
| slytherin | loic-m: git in this case | 19:52 |
| slytherin | loic-m: ni any case that is part of the activity you are doing with xvidcore | 19:52 |
| loic-m | slytherin: I've actually found the patch, since there are not many commits it was easier than expected. It's at http://repo.or.cz/w/nasm.git?a=commitdiff;h=2186415f017c3bc6886d20c3d878b67453128e6a | 19:55 |
| loic-m | slytherin: however, nasm only works for i386, amd64 code in xvidcore needs yasm, and the only information I have is that "latest version from Subversion works" which makes it a bit hard (Ubuntu only has stable version) | 19:57 |
| slytherin | loic-m: I can try build on powerpc sometime tomorrow if you create a source package | 19:59 |
| loic-m | slytherin: source package for nasm, yasm or xvidcore? | 20:00 |
| loic-m | slytherin: xvidcore ppc asm code uses gcc, nothing else, so you wouldn't see any issues | 20:01 |
| slytherin | loic-m: whichever package is currently giving trouble | 20:01 |
| loic-m | slytherin: xvidcore is giving trouble, because it won't use asm code on i386 and amd64 | 20:04 |
| loic-m | slytherin: however to build i386 asm you need an i386 arch, to build ia64 asm you need amd64 | 20:05 |
| slytherin | oh, I think I misunderstood the issue | 20:05 |
| loic-m | slytherin: I already have packages at https://launchpad.net/~loic-martin3/+archive/ppa, but they don't have asm enabled and are 2-3 times slower | 20:05 |
| loic-m | slytherin: that's ok. Probably will have to wait till Jaunty+1 when we get all new and shinny yasm packages | 20:06 |
| slytherin | LOL. Most of the packages held back from Debian testing have suddenly started migrating to testing. I received over 200 mails in debian java mailing list alone. :-D | 20:12 |
| persia | Yep. Squeeze is really active :) | 20:13 |
| anakron | ping Laney : hey, i upload a debdiff file https://bugs.launchpad.net/ubuntu/+source/pgdesigner/+bug/315411 | 20:21 |
| ubottu | Ubuntu bug 315411 in pgdesigner "Application doesn't appear in programs menu" [Low,Triaged] | 20:21 |
| === RAOF_ is now known as RAOF | ||
| ScottK | How about this, an upstream that I get better communications with via LP bugs on the Ubuntu package than I do the upstream mailling list ... | 20:24 |
| persia | ScottK, Excellent find. Foster those. | 20:28 |
| Laney | anakron: (looking after I've finished this level on world of goo) | 20:32 |
| kpirc | I'm looking for a reviewer for my package "cadabra" on REVU (it's a computer algebra system). Any takers? | 20:34 |
| Laney | kpirc: You left it a bit late ;) | 20:34 |
| stefanlsd | Adri2000: ping | 20:35 |
| kpirc | Laney: It was first uploaded in July last year... | 20:35 |
| directhex | [svn-buildpackage] Tagging monodevelop-java (1.9.2-1) | 20:35 |
| Laney | :( | 20:36 |
| Adri2000 | stefanlsd: pong | 20:36 |
| stefanlsd | Adri2000: heys. you do the dad stuff right? | 20:37 |
| Adri2000 | yes | 20:37 |
| stefanlsd | Adri2000: have you guys considered a way to notify people about new merges (maybe something they could opt into...) | 20:38 |
| Adri2000 | bug #118273 | 20:39 |
| ubottu | Launchpad bug 118273 in merge-o-matic "Mail support" [Wishlist,Confirmed] https://launchpad.net/bugs/118273 | 20:39 |
| kpirc | Laney: any chance someone will look at this now? I've been trying for several days to get someone's attention, no luck so far (there should be a proper queue for this). | 20:40 |
| Adri2000 | stefanlsd: see ^. no new feature will be added to DaD, so if that ever happens, it will be done in MoM | 20:41 |
| stefanlsd | Adri2000: kk. thanks for the bug info | 20:41 |
| Laney | kpirc: Unfortunately probably not for Jaunty (freeze is tomorrow). Hopefully we will have a better situation for 9.10 | 20:41 |
| kpirc | Laney: I was hoping the same when the Intrepid freeze was getting close... | 20:42 |
| Laney | kpirc: Hassle more earlier is the best way currently :( | 20:42 |
| AdamDH | once I have all my files in place, whats the best way to actually build the package? seen a few ways just trying to work out the best way | 20:45 |
| Geek`N`Proud | Hi everyone, I would like to know if a bug report I have filed has been written correctly: https://bugs.launchpad.net/ubuntu/+bug/331228 | 20:48 |
| ubottu | Ubuntu bug 331228 in ubuntu "HTML shows on dialog when new themes are applied (gnome-appearance) " [Undecided,New] | 20:48 |
| Geek`N`Proud | I've never filed a bug with LP before :$ | 20:48 |
| Geek`N`Proud | it only appears to affect Ubuntu Jaunty.. so is there any way I can mark it as only affecting that build? | 20:49 |
| anakron | its not necessary if you say it in the bug report | 20:50 |
| anakron | you filed it right | 20:50 |
| AdamDH | i take it if I go into the source package and do dpkg-buildpackage -rfakeroot -d is the best way to build the package? | 20:53 |
| slytherin | AdamDH: best as in easiest? | 20:54 |
| AdamDH | slytherin: well I am a new maintainer, just working on some packages, going to put them in my ppa when happy and see what you guys think, just finding it hard sometimes as there seems to be a few ways to go about it, I am at that stage where I want to build my package now I have written the files correctly | 20:55 |
| Geek`N`Proud | thanks anakron :) | 20:55 |
| Geek`N`Proud | doh :$ | 20:55 |
| AdamDH | I did pkg-buildpackage -rfakeroot -d and it worked correctly also used pbuilder | 20:58 |
| === Geek`N`Proud is now known as Geek`N`Proud` | ||
| === Geek`N`Proud` is now known as Geek`N`Proud | ||
| xnox | Package I'm working on uses libtool 1.5 | 21:07 |
| xnox | On my machine i have libtool 2.2.4 | 21:07 |
| Amaranth | wow | 21:08 |
| xnox | Lintian says that libtool is acient =D | 21:08 |
| xnox | I'm trying to relibtoolize, but I'm failing so far. | 21:08 |
| persia | relibtoolize | 21:08 |
| xnox | Any pointers? | 21:08 |
| Amaranth | xnox: Is this package from 2002 and never updated or something? | 21:08 |
| xnox | Amaranth: Last release was 2 weeks ago. When i questioned them about libtool I got response. "I really don't know what that does...." | 21:09 |
| Amaranth | What project is that? | 21:09 |
| * xnox wants to physically bash upstream with libtool manual | 21:10 | |
| xnox | Amaranth: GnomeSword / Xiphos | 21:10 |
| Amaranth | oh, I guess 1.5 isn't that old | 21:10 |
| Amaranth | I thought it was replaced in dapper but it wasn't until intrepid | 21:10 |
| persia | xnox, http://people.debian.org/~keybuk/libtool-updating.html is old, but mostly correct | 21:11 |
| xnox | Amaranth: I really don't know when 1.5 was released but I'm not going to put their package up for revu unless I figure out how to fix it. | 21:11 |
| persia | Ah, but it's also gone :( | 21:11 |
| loic-m | How can I tell pbuilder to use a version of a package in my ppa instead of the one in the repos? | 21:11 |
| RAOF | loic-m: Add your PPA to the pbuilder's sources.list | 21:11 |
| xnox | persia: thanks. got that up from the way back machine ;-) | 21:13 |
| persia | xnox, One of my concerns is that if it's gone, it might have been for a reason. | 21:13 |
| loic-m | RAOF: I can't find it. I'm using pbuilder script from ubuntu-dev-tools, and it doesn't ship it, nor does the pbuilder package | 21:14 |
| RAOF | loic-m: You'll want to pbuilder login --save-after-login, and edit the /etc/sources.list file in there. | 21:15 |
| loic-m | RAOF: thanks, I'll try | 21:15 |
| anakron | hi all, again | 21:22 |
| loic-m | RAOF: thanks, it worked. At least I know yasm 7.2 isn't new either to allow building xvidcore with i386 asm... | 21:24 |
| xnox | persia: ltconfig is no longer needed by/for libtool? | 21:26 |
| persia | xnox, I don't know. I just remembered an email message, and when I dug it up it had that link. | 21:27 |
| xnox | Ok, thanks | 21:27 |
| AdamDH | Once I have the packages in my ppa how do I go about getting them officaly into ubuntu? | 21:33 |
| directhex | is anyone from motu-release about? | 21:33 |
| directhex | AdamDH, revu | 21:33 |
| Laney | !revu | 21:33 |
| ubottu | REVU is a web-based tool to give people who have worked on Ubuntu packages a chance to "put their packages out there" for other people to look at and comment on in a structured manner. See https://wiki.ubuntu.com/MOTU/Packages/REVU | 21:33 |
| Laney | but it is too late for Jaunty | 21:33 |
| AdamDH | Laney so I would have to wait to the next cycle but I can keep them in my ppa to be used for now? | 21:34 |
| Laney | yep | 21:34 |
| persia | Laney, Technically there are 146 minutes left, but yes, it's awfully tight. | 21:34 |
| AdamDH | my first loads of packages, a cross compiler | 21:34 |
| Laney | persia: Right. I mean practically, nobody is going to review it in this time | 21:35 |
| directhex | ScottK, iulian, either of you about & available? | 21:35 |
| AdamDH | Its to close for me! I will wait to the next cycle and get a few people here to look over to make sure I have done things right | 21:35 |
| AdamDH | its a steep learning curve but after my first package the rest seemed eaiser | 21:35 |
| riot_le | what means 146 Minutes? Minutes till Freeze? | 21:39 |
| Amaranth | yeah | 21:39 |
| savvas | Can someone give me a hand on how to write a proper changelog for my first merge attempt? They say I'm missing something in the changelog, but I don't see what: https://bugs.launchpad.net/ubuntu/+source/libmtp/+bug/315679 http://bazaar.launchpad.net/~medigeek/libmtp/bug-315679/annotate/head%3A/debian/changelog | 21:39 |
| ubottu | Ubuntu bug 315679 in libmtp "Please merge libmtp 0.3.0-1ubuntu3 (main) to 0.3.6-1 from Debian (experimental)" [Wishlist,Confirmed] | 21:39 |
| directhex | riot_le, aye | 21:40 |
| riot_le | thats really sad, i told yesterday that there is a Project that needs review of 2 Devs but didnt found one who can take a look at | 21:40 |
| anakron | ping Laney : hi, i have one question, how i can apply some patches with quilt | 21:40 |
| anakron | because im doing https://bugs.launchpad.net/ubuntu/+source/qtpfsgui/+bug/309740 again | 21:41 |
| ubottu | Ubuntu bug 309740 in qtpfsgui "no menu icon" [Undecided,Confirmed] | 21:41 |
| Laney | anakron: A better (IMO) way to fix that bug is to use dh_link to symlink the icon into /usr/share/pixmaps/ | 21:41 |
| savvas | anakron: you mean https://wiki.ubuntu.com/PackagingGuide/PatchSystems#quilt%20(example%20package:%20xterm) ? | 21:41 |
| RAOF | savvas: What they mean is - the merged package should have all the debian/changelog entries from Debian unmodified. At the end, you add a new "merge" entry. | 21:44 |
| riot_le | anyone here can give me a answer to this question: Whats the main problem around the feature freeze time? Are there so much new Projects which want be added to universe or is it more the new versions of existing packages? | 21:45 |
| geser | riot_le: if you mean REVU: it's always slow independent of any freeze | 21:47 |
| riot_le | geser: no i mean, that anyone is stressed and pissed at FF-Time | 21:47 |
| geser | riot_le: after that you need an exception to get new packages or new upstream version (!= bugfix versions) into the archive | 21:48 |
| savvas | RAOF: aaaaah, you mean I had to include all the old changelog entries from Debian as well? | 21:48 |
| geser | so everyone tries to avoid this paperwork | 21:48 |
| RAOF | savvas: Yes, exactly. | 21:49 |
| savvas | darn, that was simple - ok, thanks :) | 21:49 |
| riot_le | geser: i know, but i think that an exception is much harder to get than the normal process | 21:49 |
| persia | riot_le, That's preceisely where reviewers are hard to find rigth now: they are all focusing on their own stuff, and don't want to get exceptions either, so most of the work that would have been scheduled through Monday or so is trying to be done now. | 21:50 |
| savvas | RAOF: do I still need the "Merged with Debian" and document all the debian past changes in 0.3.6-1ubuntu1 entry? | 21:50 |
| RAOF | savvas: You only document the merge changes - ie: the things that are different from the Debian package. | 21:52 |
| savvas | ah goody! | 21:52 |
| savvas | I'll get right on to fix this | 21:52 |
| RAOF | The merge changelog should be something like: Merge from Debian experimental. Remaining Ubuntu changes $LIST_OF_CHANGES | 21:53 |
| riot_le | persia: sure i understand | 21:54 |
| persia | savvas, Well, and document any other changes you make: as long as you're working on a package it's worth checking around to see if there are other useful bugfixes that can be applied. | 21:56 |
| savvas | persia: will do! Any new changes I include should go in "Remaining Ubuntu changes" list (with all the other older ubuntu changes) or as a new item? | 22:00 |
| RAOF | savvas: New item. | 22:00 |
| RAOF | (s) | 22:00 |
| savvas | ah so new ones go separately, got it | 22:01 |
| AdamDH | why is my clean rule not been ran? http://www.pastebin.ca/1341446 | 22:02 |
| * persia deprecates pastebin.ca *harder* | 22:03 | |
| AdamDH | been looking over it for an hour or so cannot see why | 22:03 |
| savvas | AdamDH: try using clean:: instead of clean: (I could be wrong though) | 22:04 |
| directhex | Laney, if you were me, would you add the merges for the plugin packages to bug 330519? | 22:07 |
| ubottu | Launchpad bug 330519 in monodevelop "The road to Monodevelop 2.0" [Undecided,New] https://launchpad.net/bugs/330519 | 22:07 |
| AdamDH | i think it should be a : just looking over the upstream binutils source see how they did the clean | 22:08 |
| quadrispro | hi guys! are we already in FF? | 22:08 |
| Laney | directhex: if you make it affect those packages sure | 22:09 |
| nhandler | quadrispro: Not for a few hours | 22:09 |
| persia | 110 minutes | 22:10 |
| quadrispro | ok | 22:11 |
| AdamDH | any ideas why clean is not been ran http://www.pastebin.ca/1341446 ? | 22:11 |
| AdamDH | im out of ideas now | 22:11 |
| persia | AdamDH, Could you stick that on paste.ubuntu.com? I'll take a quick look (but pastebin.ca crashes my browser reliably). | 22:15 |
| AdamDH | persia, thanks here it is http://paste.ubuntu.com/119843/ | 22:15 |
| savvas | does it matter if you use spaces instead of tabs in debian/rules? | 22:15 |
| xnox | Anyone wants to review a package? =D http://revu.ubuntuwire.com/details.py?upid=5207 and http://revu.ubuntuwire.com/details.py?upid=5225 | 22:16 |
| persia | savvas, Very much so | 22:16 |
| xnox | I'd love to get those into Jaunty =D | 22:16 |
| * xnox is so sorry about the timing | 22:16 | |
| persia | xnox, package names might attract more people (but it may well make no difference at all) | 22:16 |
| savvas | AdamDH, that rules file has space characters instead of tabs | 22:17 |
| savvas | ah no wait | 22:17 |
| savvas | the raw file looks ok, sorry :) | 22:17 |
| AdamDH | should be tabs | 22:18 |
| persia | AdamDH, I think you just have too many tabs. | 22:18 |
| AdamDH | everything else runs tho? | 22:18 |
| geser | hmg: Hi, you are responsible for the x2go packaging? | 22:18 |
| persia | No ,sometimes it should be tabs, and sometimes it should be spaces. They have different meanings. | 22:18 |
| AdamDH | so I ruled that out | 22:18 |
| sven777 | would a MOTU be so kind as to review my package? Thanks in advance! http://revu.ubuntuwire.com/p/lmalinux | 22:18 |
| AdamDH | so where do I need spaces and tabs in my rules? | 22:19 |
| xnox | Ok here it goes. I'm looking for a sponsor for two packages Xiphos (previously known as GnomeSword) and Sword it selft (backend library). These were produced by Debian/Ubuntu Crosswire Packaging Team. It is a massive improvement over out-of-dated lintian-not-clean packages in the repo. | 22:19 |
| hmg | geser: hello, yes - i'm one ov the developers and we are running a repo here: http://www.x2go.org/deb/ | 22:19 |
| xnox | Xiphos http://revu.ubuntuwire.com/p/xiphos and Sword http://revu.ubuntuwire.com/p/sword | 22:20 |
| geser | hmg: I know already, riot_le told me | 22:20 |
| persia | AdamDH, You need spaces between rule declarations and dependencies, and a *single* tab for each line within a rule. | 22:20 |
| hmg | geser: he said, you are looking for the initial orig tar.gz | 22:20 |
| ivoks | hi guys | 22:21 |
| === udienz1 is now known as udienz | ||
| ivoks | what's the procedure when pulling package from debian, when there's no source in ubuntu? (we didn't merge it yet) | 22:21 |
| hmg | geser: but we've no patches applied, because it is the first build - and I thought you'll need to build the sources again, because we won't be the maintainer | 22:21 |
| AdamDH | thanks persia will try that | 22:21 |
| geser | hmg: yes, a non-nativ package consists of the unmodified upstream tarball (as .orig.tar.gz) and the packaging delta (the whole debian dir) in a diff.gz | 22:22 |
| hmg | geser: as we have it in our debian repository - I know | 22:22 |
| geser | hmg: ideally the upstream source and the packaging should be separate | 22:23 |
| hmg | geser: the problem is, that everybody I've asked told me something different how to contribute a project to ubuntu | 22:24 |
| ajmitch | ivoks: just request a sync as usual, I believe | 22:24 |
| * ajmitch doesn't know how new packages would be treated with FF upon us | 22:24 | |
| ivoks | right... i haven't done that in years; i see it didn't change :) | 22:24 |
| hmg | geser: I see - so I should redo the packages and put them ... where? | 22:25 |
| geser | ivoks: request a sync (+ FF exception as FF starts in a few minutes) | 22:25 |
| geser | hmg: a random example from REVU: http://revu.ubuntuwire.com/p/webilder | 22:26 |
| geser | hmg: it's always a little bit hard when upstream does also the packaging as both gets easily mixed | 22:26 |
| geser | hmg: the .orig.tar.gz is the upstream code as can be download from the upstream homepage | 22:27 |
| === hanska is now known as hanska_ | ||
| hmg | geser: do I need to start the rfp again after adding the neew packages/diffs/files? | 22:28 |
| geser | hmg: the packager add then the debian dir (with all needed files) and when he builds the source package then dpkg-buildpackage (or debuild) will put all changes (e.g. the debian dir or any needed patches) into the .diff.gz | 22:28 |
| geser | hmg: rfp? | 22:29 |
| hmg | geser: request for packaging | 22:29 |
| geser | hmg: no, as it's an improvement of the current packaging | 22:30 |
| AdamDH | clean is working now | 22:30 |
| persia | hmg, No. If you've already filed an RFP, changing your tarballto better match the recommendations only makes it easier for the packager | 22:30 |
| hmg | geser: ok, I'll upload the new files and add a notice to the rfp bug | 22:31 |
| AdamDH | but where is the correct place to install the source I am doing cd src && $(MAKE) install DESTDIR=$(CURDIR)/debian/msp430-binutils but I get dh_compress: Can't cd to debian/msp430-binutils: No such file or directory ? | 22:31 |
| hmg | persia: thank you! | 22:32 |
| geser | hmg: I've given two packages a quick look, and both need some work on the packages, e.g. the .ex files, remove those you don't need | 22:33 |
| geser | hmg: and for x2goclient-gtk please fill the fields in the copyright file | 22:33 |
| geser | and also read how the automatic detection of needed libraries works, you shouldn't list them in debian/rules | 22:34 |
| hmg | geser: is there a chance of FF except to get enough time for the wanted changes? | 22:37 |
| geser | hmg: you can at least try. Independent of it you can work on the packaging and in case it isn't ready for jaunty, you have packages for jaunty+1 and can request a backport to jaunty once they are in (if using -backports is ok for your users) | 22:40 |
| quadrispro | bye! | 22:42 |
| maxb | AdamDH: what is $(MAKE) evaluating to? I'm not sure you should use $(MAKE) in a debian/rules | 22:44 |
| andersk | $(MAKE) is set by make itself. | 22:45 |
| maxb | yeah, but will it include extra options ever? | 22:45 |
| geser | hmg: do you know already about the Packaging Guide? https://wiki.ubuntu.com/PackagingGuide | 22:46 |
| maxb | In which case, passing down magic from the debian buildprocess into the upstream make may not be desirable | 22:46 |
| maxb | I can't work out how else AdamDH's $(MAKE) install could end up executing debhelper | 22:46 |
| geser | AdamDH: try $(MAKE) -C src install DESTDIR=... | 22:47 |
| AdamDH | what would be the correct line? | 22:47 |
| AdamDH | I have used that line before and got a deb built with the files inside | 22:47 |
| maxb | geser: Would you really expect any different behaviour from -C over cd ? | 22:48 |
| geser | maxb: I don't know what happens to $(CURDIR) | 22:48 |
| maxb | geser: I would say that $(CURDIR) would be evaluated when the command line is being constructed, anyway | 22:49 |
| geser | true, so it shouldn't make a difference | 22:49 |
| maxb | AdamDH: pastebin full debian/rules and full buildlog | 22:50 |
| hmg | geser: this was an special version for ubuntu - it is still possible to install x2go by using our repo. I had a long talk to some ubuntu members, which requested a lot of changes to get this project fit into ubuntu (no patches to nx, no qt client, no kdelibdependency, ...). There was no time left to do the packaging as you wanted it... so I think, this is gine wrong... | 22:50 |
| hmg | geser: but as I said, everybody who wants to install x2go can use our repo - so there is no major problem despite of the special ubuntu version which would fit more in the context of ubuntu | 22:51 |
| AdamDH | maxb the rules is here http://paste.ubuntu.com/119843/ where do I find the build log? | 22:51 |
| maxb | on the console :-) | 22:51 |
| maxb | copy+paste | 22:51 |
| maxb | or redirect it | 22:51 |
| AdamDH | MAXB: http://paste.ubuntu.com/119854/ | 22:53 |
| AdamDH | thats the inportant bit the rest is just compile output | 22:53 |
| AdamDH | *important | 22:53 |
| maxb | uh | 22:54 |
| maxb | well your make install obviously isn't installing the stuff there, then | 22:54 |
| maxb | so find out why | 22:56 |
| AdamDH | what would cause that? | 22:57 |
| AdamDH | actually I think that entire line is wrong and CURDIR is not the best thing to do | 22:59 |
| AdamDH | I will rewrite it | 22:59 |
| savvas | AdamDH: I removed some of the tabs and used spaces were I think they should be used, try it: http://paste.ubuntu.com/119855/ | 23:00 |
| AdamDH | thanks savvas just giving that a go now | 23:05 |
| savvas | You had some extra spaces/tabs after "clean:", e.g. "clean: " - I think that's what made it not run | 23:06 |
| AdamDH | the upstream binutils uses something like $(MAKE) -C builddir-single \ | 23:09 |
| AdamDH | CFLAGS="$(CFLAGS)" prefix=$(pwd)/$(d_bin)/usr \ | 23:09 |
| AdamDH | mandir=$(pwd)/$(d_bin)/usr/share/man \ | 23:09 |
| AdamDH | infodir=$(pwd)/$(d_doc)/usr/share/info install so might try something like that | 23:09 |
| AdamDH | sorry about the paste | 23:09 |
| maxb | AdamDH: having a remove-patch-stamp is a bit nonsensical | 23:09 |
| maxb | If anything, remove-patch needs to remove the apply-patch-stamp | 23:10 |
| AdamDH | maxb: I might remove the remove patch and the script for that | 23:10 |
| AdamDH | some one sugeested I needed to clean the upstream source after I applied my patches so I added that | 23:10 |
| maxb | also, "cd $(CURDIR)/" is a rather useless construct :-) | 23:11 |
| maxb | your clean target needs to properly clean the package source. However, since (presumably) everything you patch is going to get removed in "rm -rf src" anyway, unapplying the patch is not an issue | 23:13 |
| maxb | AdamDH: why are you writing your own packaging from scratch anyway, though? | 23:15 |
| maxb | Wouldn't it make far more sense to borrow the packaging system from one of the binutils-some-other-embedded-system packages already in Ubuntu? | 23:15 |
| AdamDH | there was nothing close | 23:16 |
| AdamDH | so I started from scratch as its a cross compiler | 23:16 |
| AdamDH | the binutils allready in utils the rules is about 900 lines and I dont need all those targets | 23:16 |
| AdamDH | *ubuntu | 23:16 |
| maxb | binutils-avr? binutils-h8300-hms? binutils-m68hc1x? I see three likely candidates | 23:16 |
| maxb | binutils-z80. four | 23:17 |
| savvas | does anyone remember the link with the bzr branches of ubuntu packages? | 23:17 |
| nhandler | savvas: http://package-import.ubuntu.com/ | 23:19 |
| savvas | great, thanks nhandler :) | 23:19 |
| nhandler | You're welcome savvas | 23:19 |
| AdamDH | maxb will take a look | 23:23 |
| savvas | nhandler: you wouldn't happen to know what is the link http://bazaar.ubuntu.com for? | 23:24 |
| maxb | AdamDH: skip the -h8300-hms one, I don't think that's what you're looking for | 23:25 |
| nhandler | savvas: I don't know. It might be where they hope to move the branches to. james-w would have more information | 23:25 |
| savvas | they sure have some weird files in there :P http://bazaar.ubuntu.com/anacron@bazaar.ubuntu.com/=meta-info/http-blows | 23:26 |
| AdamDH | the avr one is what I was after thanks I can use that to improve my rules | 23:28 |
| AdamDH | is $(BUILD_TREE) a correct makefile tag? | 23:30 |
| === pochu_ is now known as pochu | ||
| AdamDH | maxb: everything seems to work apart from the install part | 23:40 |
| maxb | $(BUILD_TREE) is just an ordinary custom variable | 23:40 |
| maxb | AdamDH: is this package on revu? | 23:41 |
| AdamDH | not yet | 23:42 |
| AdamDH | its running configure and make fine | 23:42 |
| maxb | please paste a buildlog that includes the malfunctioning install | 23:42 |
| AdamDH | you want the entire log? | 23:43 |
| maxb | probably easier to give it all that worry about what is and is not useful | 23:45 |
| AdamDH | its just running now will pastebin it when its finished | 23:48 |
| === sdh_ is now known as sdh | ||
| AdamDH | pastebinit -i log.txt -f bash seems to be taking its time! | 23:51 |
| AdamDH | maxb: http://paste.ubuntu.com/119865/ | 23:55 |
| maxb | I don't think you wanted -f bash :-) | 23:56 |
| maxb | It's tried to syntax-highlight it as a shellscript | 23:56 |
| AdamDH | i did that one as text as well after bash went wrong | 23:57 |
| AdamDH | it you go to the bottom it shows the error | 23:57 |
| maxb | oh | 23:58 |
| maxb | haha | 23:58 |
| maxb | dh_clean | 23:59 |
| maxb | You just deleted what you built | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!