[00:00] Your Makefile should only deal with installing the files that need to be in *your* package. [00:00] (And compiling them if necessary.) [00:01] Erk, I just spotted the 'chmod 777' calls in there. Kill those. [00:01] how does enduser get upsource from apt ? [00:01] It's almost never appropriate for a package to ship world-writable directories. [00:01] will do that is not the actual script [00:01] "get upsource"? [00:02] that is inthe make file ? get upsource ? [00:02] Sorry, I still don't understand what "upsource" is. [00:02] I mean how does the make file know that the package /upsource is there like how to mv files that are not there ? [00:03] Well, you can't move files that aren't there. Can you give me a specific example? [00:03] I made a video of the question here http://www.youtube.com/watch?v=fZYgwJVmn2Y [00:03] I'm not going to watch a video, sorry. [00:04] ok so here http://bazaar.launchpad.net/~josephjamesmills/zpanelcp/zpanelcp/files see there is my upstart [00:04] My kids are asleep (so trying to avoid sound) and I have limited bandwidth at this time of night anyway. [00:04] Its cool [00:04] I can make example [00:04] The Makefile runs at build time. It operates on your source code. [00:05] It's not generally allowed to operate on anything else. [00:05] 'make install' should have the effect of installing files into their destination locations, prefixed by $DESTDIR. So for example, to install a binary to /usr/bin/foo: [00:05] install: [00:06] install -d $DESTDIR/usr/bin [00:06] install -m755 bin/foo $DESTDIR/usr/bin/foo [00:06] where the eight spaces at the start of those lines must actually be a hard tab (make syntax) [00:07] It's just about building and installing your own files, nothing more [00:07] so I have other programs that I have packed here is one of the rules file for one http://paste.ubuntu.com/933314/ but Zpanel (what I am workinng on ) hass over 6000 files and if I have to call a var for each one two times that that is 12,000 lines of code + the DEST [00:07] You can always use cp -a and the like [00:07] Or wildcards [00:08] that is the anwser I WANTED \0/ [00:08] Nobody expects a single line of code per file [00:08] that is what I thought but could not figure out workaround because I am new [00:09] Bit of advice from when I was new: don't admit it, just try to make the best imitation of not being new that you can. :-) [00:09] Thanks ! [00:10] * bregma can not believe that cjwatson was _ever_ new [00:10] OMG it is so simple I was overthinging this way to much [00:10] In the case of that rules file you pasted, the way I'd do it would be to create a file debian/install that contains: [00:10] ripper64.png usr/share/icons/hicolor/64x64/app [00:10] ripper.desktop usr/share/applications [00:11] ripper rippergui usr/bin [00:11] wait I can just drop folders? [00:11] and then delete the rest of the rules file and replace it with a copy of /usr/share/doc/debhelper/examples/rules.tiny [00:11] dh_install has special syntax intended to make life easier [00:11] (dh_install is what parses debian/install or debian/*.install) [00:12] It's documented in its man page [00:12] Anyhow, must try to sleep again, night [00:13] now that I know that I can make wild cards \0/ thanks cjwatson get some good sleep tonight you should you really helped me out Thanks again ! [00:14] bobweaver, do you remember the two-line debian/rules file I posted oh, 12 hours ago or so? [00:14] that's what you'll find in /usr/share/doc/debhelper/examples/rules.tiny [00:28] bregma, yea I kinda rember that bregma [02:06] before I go any further does this look correct ? install $(CURDIR)/debian/source/etc/build/config_packs/ubuntu_11_10/* /etc/zpanel/configs/ [02:07] will that cp everything under install $(CURDIR)/debian/source/etc/build/config_packs/ubuntu_11_10 and put it in /etc/zpanel/configs/ [02:07] or can I do [02:08] install cp /debian/source/etc/build/config_packs/ubuntu_11_10/* /etc/zpanel/configs/ [02:08] or does it have to be like this [02:09] install cp /debian/source/etc/build/config_packs/ubuntu_11_10/* $DESTDIR/etc/zpanel/configs/ [02:10] or do I just call the cp /name/of/dir/* /some/dir Under dh_installdirs ? [02:16] bobweaver: I'm missing context, but that looks incorrect; it looks like you're trying to install files into /etc/zpanel/config during the process of *building* the package, rather than installing the package. [02:18] RAOF, so I have to use different tags then at a different point in the make file [02:18] bobweaver: As I said, I'm missing context. What, exactly, are you trying to do? [02:19] you are right thou I am trying to make it so the enduser has them files also on there computers [02:20] using the wild card as there is alot stuff under /etc/zpanel/ [02:21] bobweaver, what happens during packaging is your install command is run to copy the files from a local copy of your source (for example, a bzr checkout) into a temporary staging area under debian/ that mimics the final destination of the installed system [02:21] RAOF, My question it has been kinda anwsered but I am trying to get syntax right :) http://www.youtube.com/watch?v=fZYgwJVmn2Y [02:21] that's why the 'make install' target (or equivalent) needs to work without the packaging system [02:22] and your install script needs to honour the DESTDIR variable [02:22] so your 'install cp /debian/source/etc/build/config_packs/ubuntu_11_10/* $DESTDIR/etc/zpanel/configs/' comes closest [02:23] you can test it yourself by runing your install script and setting DESTDIR to, say, /tmp/shoebox and seeingwhat gets installed into /tmp/shoebox [02:27] if your install script installs everything in the right place and honours $DESTDIR, then you do not need to do anything special in debian/rules, the tiny example knows how to take the files from there and bundle them up into a .deb [02:28] bregma, let me see if I got this right in normal deb packaging for me I alter rule I do not want to do this keep it as is after dh_make but before dh_make I have to make a Makefile called well make file. Do I also have to make a configuration file. ||| Or can I just make a #!/usr/bin/make -f file call it what foo then call foo somehow before the build prosses ? ||| now reading above again thanks [02:30] That is cool about the tiny I was reading about that earlier [02:31] 1) makefile 2) dh_make 3) alter /debian/ 4) fakeroot dpkg-buildpackage -F 5) hope it builds ?? [02:31] makefile = script [02:35] What software are you trying to package? How would you normally install it? [02:39] bobweaver, you probably do not need a configuration script, and using a makefile (called 'Makefile' by convention) will make your debian/rules simpler [02:39] you can use wildcards in your makefile and use the 'cp -r' command for recursive copies of entire directories [02:40] and test it and make sure it does what you expect [02:41] the softeare is a http://bazaar.launchpad.net/~josephjamesmills/zpanelcp/zpanelcp/files it is a control panel I learned how to package on youtube by making script making icons and making callto points (depends scripts) tar all that up run dh_make -e -c gpl3 -f the_tar_i_just_made.tar.gz Now go into the new debian folder and change the depends and wht not in the control file then copyright then massivly alter rule file to [02:41] make the build happen then earse all non using .ex files and make unes that I am using as chmod +x then build with fakeroot dpkg-buildpackage -F [02:41] RAOF, ^^ [02:41] Thanks it is becoming clear bregma [02:42] I am mixing up Makefile ike gcc makefiles with #!/usr/bin/make -f or are they the same and that is just the shebang or are they different types all togeather ? [02:43] once your makefile works, then yes, use dh_make -- I would suggest using a separate tree for packaging from your upstream source tree, but that may be more advanced than you need at this point [02:44] makefiles can be used to build C programs, too [02:44] cool ! [02:44] they're just a collection of rules on how to build files from other files, effectively [02:44] * bobweaver takes a 90lbs weight of shoulders [02:44] I get it [02:44] but [02:45] how does the upsource get there (enduser) ? [02:45] I'm not sure what you mean? [02:45] in the build of dpkg-buildpackage in the source one ? [02:46] like how can a end user cp a file that is not on there computer [02:46] The end user doesn't install a file that's not on their computer. [02:46] There's two cases here: (1) the end user is installing from your source, (2) the end user is installing a .deb [02:47] In the first case, the end user has the file, because they've got your source. [02:47] In the second case, the .deb contains that file and unpacks it into the directory that you copied it to in the build process. [02:47] \o/ [02:48] thatis what I needed to hear [02:48] You can see the files in the deb, and where they'll be unpacked to, by running ‘dpkg --contents $PACKAGE.deb’ [02:49] Oh my I feel like a million bucks thanks RAOF and bregma [02:50] that is where I was confused I could not see that inside the deb contains also the source packages or do I have to call for repo for that ? [02:51] no, the deb is a binary package (although in your case, it's all scripts and stuff) [02:51] I think I get it and see why I was getting errors last night because I had no makefile I get it I think [02:52] off to test brb [02:52] the source package is usually a 'tarball' of the upstream source plus another archive of packaging information, plus a .dsc file describing the other files [02:52] I see Thanks ! [03:41] It is Working !!!! \o/ \o/ [07:00] good morning [08:10] oh === almaisan-away is now known as al-maisan [10:31] ah, micahg responded on the wesnoth bugreport. :) [10:31] micahg: Also, upstream does usually help me backport fixes if needed even though it wouldn't be a supported release anymore. ;) === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan === dholbach_ is now known as dholbach [15:12] cjwatson: okay, thanks for the info === al-maisan is now known as almaisan-away [20:18] tumbleweed: ScottK: I noticed git-annex FTBFS. I can fix it by syncing haskell-bloomfilter (NEW) and then syncing git-annex itself. It's pretty featureful, though — http://packages.debian.org/changelogs/pool/main/g/git-annex/current/changelog — but some of the changes (7.4 compat and the FTBFS fix / library updates) we definitely want. I think it's easiest/best to go for the syncs. [20:18] Yay or nay? [20:19] Yay if you think it best. As long as it's a sync, I don't mind the new. [20:19] ok. want ffe? [20:21] laney: I had an FTBFS on that package in a local chroot [20:21] does it work in LP? [20:22] dunno [20:22] 1 N + Apr 17 Source Builder ( 53K) Log for successful build of git-annex_3.20120406 on amd64 (dist=precise) [20:22] it was a hardlink test failure [20:23] Cases: 54 Tried: 54 Errors: 0 Failures: 0 [20:26] Laney: Yes (re FFe) although you can mostly copy/paste this discussion (assuming you solve micahg's issue) [20:26] I don't believe they are real, but I'll upload to a PPA. [20:27] * micahg has had various hardlink issues in teh past that no one else seems to have, so wouldn't be surprise if this worked on LP [20:28] and it's LP that counts in any event [20:59] I enjoyed writing that FFe for some reason. Something is wrong wih me. [21:00] probably because I got distracted reading about bloom filters [21:00] Laney: you like all sorts of weird things though [21:01] you should see my dungeon [21:01] I don't think my innocent eyes could handle it === almaisan-away is now known as al-maisan [22:12] Hello, [22:12] I'm looking for someone to quickly fix the bug #984054 :) [22:12] Launchpad bug 984054 in cairo-dock-plug-ins (Ubuntu) "package cairo-dock-plug-ins-data 3.0.0.0rc1 failed to upgrade to 3.0.0.1" [Undecided,Confirmed] https://launchpad.net/bugs/984054 [22:12] I propose a bzr branch for merging into lp:ubuntu/cairo-dock-plug-ins => https://code.launchpad.net/~cairo-dock-team/ubuntu/precise/cairo-dock-plug-ins/984054 [22:12] Someone can help me to upload this new version? :) === al-maisan is now known as almaisan-away [22:13] matttbe: yeah, I canin a bit take a look at that [22:13] wow, sily IRC client [22:13] I can take a look at that in a bit [22:13] micahg: thank you :) [22:14] matttbe: FYI, whenever files move between packages, you need to add breaks/replaces for them [22:15] micahg: yeah, I know... I just forgot... I should sleep more :) [22:18] matttbe: I'm not sure that will fix it, which package is that file in now? [22:19] micahg: This file was available in cairo-dock-data /usr/share/cairo-dock/gauges/Battery/background.svg [22:19] and now it's in cairo-dock-plug-ins-data [22:20] matttbe: ok, so you want to break on the version where it moved, not the version in the bug [22:21] otherwise you need to specify the whole 3.0.0.0rc1-0ubuntu1 version for <= [22:21] not only 3.0.0.0rc1 ? [22:21] right, that won't pick up 3.0.0.0rc1-0ubuntu1 [22:21] oh ok, I didn't know, sorry [22:22] matttbe: that's why we have sponsors ;) [22:22] :) [22:22] or rather why the sponsors are supposed to review changes :) [22:22] let this be a lesson to all involved: test package upgrades :P [22:22] indeed :) [22:23] * micahg still needs to add hooks for that to sbuild [22:23] yes, I should have done that... sorry [22:25] but it's strange. A friend has tested this new version and he didn't have this problem. Maybe because cairo-dock-data has been updated before cairo-dock-plug-ins-data [22:25] right === yofel_ is now known as yofel