cjwatson | Your Makefile should only deal with installing the files that need to be in *your* package. | 00:00 |
---|---|---|
cjwatson | (And compiling them if necessary.) | 00:00 |
cjwatson | Erk, I just spotted the 'chmod 777' calls in there. Kill those. | 00:01 |
bobweaver | how does enduser get upsource from apt ? | 00:01 |
cjwatson | It's almost never appropriate for a package to ship world-writable directories. | 00:01 |
bobweaver | will do that is not the actual script | 00:01 |
cjwatson | "get upsource"? | 00:01 |
bobweaver | that is inthe make file ? get upsource ? | 00:02 |
cjwatson | Sorry, I still don't understand what "upsource" is. | 00:02 |
bobweaver | I mean how does the make file know that the package /upsource is there like how to mv files that are not there ? | 00:02 |
cjwatson | Well, you can't move files that aren't there. Can you give me a specific example? | 00:03 |
bobweaver | I made a video of the question here http://www.youtube.com/watch?v=fZYgwJVmn2Y | 00:03 |
cjwatson | I'm not going to watch a video, sorry. | 00:03 |
bobweaver | ok so here http://bazaar.launchpad.net/~josephjamesmills/zpanelcp/zpanelcp/files see there is my upstart | 00:04 |
cjwatson | My kids are asleep (so trying to avoid sound) and I have limited bandwidth at this time of night anyway. | 00:04 |
bobweaver | Its cool | 00:04 |
bobweaver | I can make example | 00:04 |
cjwatson | The Makefile runs at build time. It operates on your source code. | 00:04 |
cjwatson | It's not generally allowed to operate on anything else. | 00:05 |
cjwatson | '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 |
cjwatson | install: | 00:05 |
cjwatson | install -d $DESTDIR/usr/bin | 00:06 |
cjwatson | install -m755 bin/foo $DESTDIR/usr/bin/foo | 00:06 |
cjwatson | where the eight spaces at the start of those lines must actually be a hard tab (make syntax) | 00:06 |
cjwatson | It's just about building and installing your own files, nothing more | 00:07 |
bobweaver | 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 |
cjwatson | You can always use cp -a and the like | 00:07 |
cjwatson | Or wildcards | 00:07 |
bobweaver | that is the anwser I WANTED \0/ | 00:08 |
cjwatson | Nobody expects a single line of code per file | 00:08 |
bobweaver | that is what I thought but could not figure out workaround because I am new | 00:08 |
cjwatson | 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 |
bobweaver | Thanks ! | 00:09 |
* bregma can not believe that cjwatson was _ever_ new | 00:10 | |
bobweaver | OMG it is so simple I was overthinging this way to much | 00:10 |
cjwatson | 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 |
cjwatson | ripper64.png usr/share/icons/hicolor/64x64/app | 00:10 |
cjwatson | ripper.desktop usr/share/applications | 00:10 |
cjwatson | ripper rippergui usr/bin | 00:11 |
bobweaver | wait I can just drop folders? | 00:11 |
cjwatson | 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 |
cjwatson | dh_install has special syntax intended to make life easier | 00:11 |
cjwatson | (dh_install is what parses debian/install or debian/*.install) | 00:11 |
cjwatson | It's documented in its man page | 00:12 |
cjwatson | Anyhow, must try to sleep again, night | 00:12 |
bobweaver | 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:13 |
bregma | bobweaver, do you remember the two-line debian/rules file I posted oh, 12 hours ago or so? | 00:14 |
bregma | that's what you'll find in /usr/share/doc/debhelper/examples/rules.tiny | 00:14 |
bobweaver | bregma, yea I kinda rember that bregma | 00:28 |
bobweaver | before I go any further does this look correct ? install $(CURDIR)/debian/source/etc/build/config_packs/ubuntu_11_10/* /etc/zpanel/configs/ | 02:06 |
bobweaver | 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 |
bobweaver | or can I do | 02:07 |
bobweaver | install cp /debian/source/etc/build/config_packs/ubuntu_11_10/* /etc/zpanel/configs/ | 02:08 |
bobweaver | or does it have to be like this | 02:08 |
bobweaver | install cp /debian/source/etc/build/config_packs/ubuntu_11_10/* $DESTDIR/etc/zpanel/configs/ | 02:09 |
bobweaver | or do I just call the cp /name/of/dir/* /some/dir Under dh_installdirs ? | 02:10 |
RAOF | 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:16 |
bobweaver | RAOF, so I have to use different tags then at a different point in the make file | 02:18 |
RAOF | bobweaver: As I said, I'm missing context. What, exactly, are you trying to do? | 02:18 |
bobweaver | you are right thou I am trying to make it so the enduser has them files also on there computers | 02:19 |
bobweaver | using the wild card as there is alot stuff under /etc/zpanel/ | 02:20 |
bregma | 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 |
bobweaver | 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 |
bregma | that's why the 'make install' target (or equivalent) needs to work without the packaging system | 02:21 |
bregma | and your install script needs to honour the DESTDIR variable | 02:22 |
bregma | so your 'install cp /debian/source/etc/build/config_packs/ubuntu_11_10/* $DESTDIR/etc/zpanel/configs/' comes closest | 02:22 |
bregma | 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:23 |
bregma | 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:27 |
bobweaver | 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:28 |
bobweaver | That is cool about the tiny I was reading about that earlier | 02:30 |
bobweaver | 1) makefile 2) dh_make 3) alter /debian/ 4) fakeroot dpkg-buildpackage -F 5) hope it builds ?? | 02:31 |
bobweaver | makefile = script | 02:31 |
RAOF | What software are you trying to package? How would you normally install it? | 02:35 |
bregma | 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 |
bregma | you can use wildcards in your makefile and use the 'cp -r' command for recursive copies of entire directories | 02:39 |
bregma | and test it and make sure it does what you expect | 02:40 |
bobweaver | 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 <email> -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 |
bobweaver | 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 |
bobweaver | RAOF, ^^ | 02:41 |
bobweaver | Thanks it is becoming clear bregma | 02:41 |
bobweaver | 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:42 |
bregma | 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:43 |
bregma | makefiles can be used to build C programs, too | 02:44 |
bobweaver | cool ! | 02:44 |
bregma | 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 | |
bobweaver | I get it | 02:44 |
bobweaver | but | 02:44 |
bobweaver | how does the upsource get there (enduser) ? | 02:45 |
RAOF | I'm not sure what you mean? | 02:45 |
bobweaver | in the build of dpkg-buildpackage in the source one ? | 02:45 |
bobweaver | like how can a end user cp a file that is not on there computer | 02:46 |
RAOF | The end user doesn't install a file that's not on their computer. | 02:46 |
RAOF | There's two cases here: (1) the end user is installing from your source, (2) the end user is installing a .deb | 02:46 |
RAOF | In the first case, the end user has the file, because they've got your source. | 02:47 |
RAOF | 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 |
bobweaver | \o/ | 02:47 |
bobweaver | thatis what I needed to hear | 02:48 |
RAOF | You can see the files in the deb, and where they'll be unpacked to, by running ‘dpkg --contents $PACKAGE.deb’ | 02:48 |
bobweaver | Oh my I feel like a million bucks thanks RAOF and bregma | 02:49 |
bobweaver | 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:50 |
bregma | no, the deb is a binary package (although in your case, it's all scripts and stuff) | 02:51 |
bobweaver | 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:51 |
bobweaver | off to test brb | 02:52 |
bregma | 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 |
bobweaver | I see Thanks ! | 02:52 |
bobweaver | It is Working !!!! \o/ \o/ | 03:41 |
dholbach | good morning | 07:00 |
Rhonda | oh | 08:10 |
=== almaisan-away is now known as al-maisan | ||
Rhonda | ah, micahg responded on the wesnoth bugreport. :) | 10:31 |
Rhonda | micahg: Also, upstream does usually help me backport fixes if needed even though it wouldn't be a supported release anymore. ;) | 10:31 |
=== al-maisan is now known as almaisan-away | ||
=== almaisan-away is now known as al-maisan | ||
=== dholbach_ is now known as dholbach | ||
pabelanger | cjwatson: okay, thanks for the info | 15:12 |
=== al-maisan is now known as almaisan-away | ||
Laney | 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 |
Laney | Yay or nay? | 20:18 |
ScottK | Yay if you think it best. As long as it's a sync, I don't mind the new. | 20:19 |
Laney | ok. want ffe? | 20:19 |
micahg | laney: I had an FTBFS on that package in a local chroot | 20:21 |
micahg | does it work in LP? | 20:21 |
Laney | dunno | 20:22 |
Laney | 1 N + Apr 17 Source Builder ( 53K) Log for successful build of git-annex_3.20120406 on amd64 (dist=precise) | 20:22 |
micahg | it was a hardlink test failure | 20:22 |
Laney | Cases: 54 Tried: 54 Errors: 0 Failures: 0 | 20:23 |
ScottK | Laney: Yes (re FFe) although you can mostly copy/paste this discussion (assuming you solve micahg's issue) | 20:26 |
Laney | I don't believe they are real, but I'll upload to a PPA. | 20:26 |
* 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:27 | |
micahg | and it's LP that counts in any event | 20:28 |
Laney | I enjoyed writing that FFe for some reason. Something is wrong wih me. | 20:59 |
Laney | probably because I got distracted reading about bloom filters | 21:00 |
ajmitch | Laney: you like all sorts of weird things though | 21:00 |
Laney | you should see my dungeon | 21:01 |
ajmitch | I don't think my innocent eyes could handle it | 21:01 |
=== almaisan-away is now known as al-maisan | ||
matttbe | Hello, | 22:12 |
matttbe | I'm looking for someone to quickly fix the bug #984054 :) | 22:12 |
ubottu | 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 |
matttbe | 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 |
matttbe | Someone can help me to upload this new version? :) | 22:12 |
=== al-maisan is now known as almaisan-away | ||
micahg | matttbe: yeah, I canin a bit take a look at that | 22:13 |
micahg | wow, sily IRC client | 22:13 |
micahg | I can take a look at that in a bit | 22:13 |
matttbe | micahg: thank you :) | 22:13 |
micahg | matttbe: FYI, whenever files move between packages, you need to add breaks/replaces for them | 22:14 |
matttbe | micahg: yeah, I know... I just forgot... I should sleep more :) | 22:15 |
micahg | matttbe: I'm not sure that will fix it, which package is that file in now? | 22:18 |
matttbe | micahg: This file was available in cairo-dock-data /usr/share/cairo-dock/gauges/Battery/background.svg | 22:19 |
matttbe | and now it's in cairo-dock-plug-ins-data | 22:19 |
micahg | matttbe: ok, so you want to break on the version where it moved, not the version in the bug | 22:20 |
micahg | otherwise you need to specify the whole 3.0.0.0rc1-0ubuntu1 version for <= | 22:21 |
matttbe | not only 3.0.0.0rc1 ? | 22:21 |
micahg | right, that won't pick up 3.0.0.0rc1-0ubuntu1 | 22:21 |
matttbe | oh ok, I didn't know, sorry | 22:21 |
micahg | matttbe: that's why we have sponsors ;) | 22:22 |
matttbe | :) | 22:22 |
micahg | or rather why the sponsors are supposed to review changes :) | 22:22 |
Laney | let this be a lesson to all involved: test package upgrades :P | 22:22 |
micahg | indeed :) | 22:22 |
* micahg still needs to add hooks for that to sbuild | 22:23 | |
matttbe | yes, I should have done that... sorry | 22:23 |
matttbe | 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 |
micahg | right | 22:25 |
=== yofel_ is now known as yofel |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!