[00:00] <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:01] <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:02] <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:03] <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:04] <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:05] <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:06] <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:07] <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:08] <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:09] <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:10]  * 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:11] <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:12] <cjwatson> It's documented in its man page
[00:12] <cjwatson> Anyhow, must try to sleep again, night
[00:13] <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:14] <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:28] <bobweaver> bregma,  yea I kinda rember that bregma
[02:06] <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:07] <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:08] <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:09] <bobweaver> install cp /debian/source/etc/build/config_packs/ubuntu_11_10/*  $DESTDIR/etc/zpanel/configs/
[02:10] <bobweaver> or do I just call the cp /name/of/dir/* /some/dir        Under dh_installdirs ?
[02:16] <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:18] <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:19] <bobweaver> you are right thou I am trying to make it so the enduser has them files also on there computers
[02:20] <bobweaver> using the wild card as there is alot stuff under /etc/zpanel/
[02:21] <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:22] <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:23] <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:27] <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:28] <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:30] <bobweaver> That is cool about the tiny I was reading about that earlier
[02:31] <bobweaver> 1) makefile 2) dh_make 3) alter /debian/ 4) fakeroot dpkg-buildpackage -F 5) hope it builds ??
[02:31] <bobweaver> makefile = script
[02:35] <RAOF> What software are you trying to package?  How would you normally install it?
[02:39] <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:40] <bregma> and test it and make sure it does what you expect
[02:41] <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:42] <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:43] <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:44] <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:45] <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:46] <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:47] <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:48] <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:49] <bobweaver> Oh my I feel like a million bucks thanks RAOF  and bregma
[02:50] <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:51] <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:52] <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 !
[03:41] <bobweaver> It is Working !!!! \o/ \o/
[07:00] <dholbach> good morning
[08:10] <Rhonda> oh
[10:31] <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. ;)
[15:12] <pabelanger> cjwatson: okay, thanks for the info
[20:18] <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:19] <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:21] <micahg> laney: I had an FTBFS on that package in a local chroot
[20:21] <micahg> does it work in LP?
[20:22] <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:23] <Laney> Cases: 54  Tried: 54  Errors: 0  Failures: 0
[20:26] <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: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] <micahg> and it's LP that counts in any event
[20:59] <Laney> I enjoyed writing that FFe for some reason. Something is wrong wih me.
[21:00] <Laney> probably because I got distracted reading about bloom filters
[21:00] <ajmitch> Laney: you like all sorts of weird things though
[21:01] <Laney> you should see my dungeon
[21:01] <ajmitch> I don't think my innocent eyes could handle it
[22:12] <matttbe> Hello,
[22:12] <matttbe> I'm looking for someone to quickly fix the bug #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:13] <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:14] <micahg> matttbe: FYI, whenever files move between packages, you need to add breaks/replaces for them
[22:15] <matttbe> micahg: yeah, I know... I just forgot... I should sleep more :)
[22:18] <micahg> matttbe: I'm not sure that will fix it, which package is that file in now?
[22:19] <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:20] <micahg> matttbe: ok, so you want to break on the version where it moved, not the version in the bug
[22:21] <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:22] <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:23]  * micahg still needs to add hooks for that to sbuild
[22:23] <matttbe> yes, I should have done that... sorry
[22:25] <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