**** BEGIN LOGGING AT Sun Feb 06 02:59:57 2011 Feb 06 03:11:01 KC9SJQ, You might try #ubuntu : nothing should be different because you're on a pandaboard or even running ARM. Be warned it's fairly crowded and busy there. Feb 06 03:11:20 Yeah, I've been there before Feb 06 03:11:52 I just wanted to make sure that there was nothing endian based in the cups protocol that could cause an issue. Feb 06 03:11:57 Thanks, persia Feb 06 03:12:26 armel is the same endianness as i386 :) Feb 06 03:13:24 That said, there *might* be an issue with miscompilation or similar, but that's a bit more unlikely. Feb 06 03:13:26 well, so much for that consern Feb 06 03:13:36 hehe, thanks. Feb 06 03:13:49 The other option would be to upgrade the 10.04 system to 10.10 so you are working with the same software stacks, and then see if you can find a difference. Feb 06 03:14:11 I don't know anything about the printer stack, so can't help you precisely, sorry. Feb 06 03:16:38 Well, I'll do so next time I'm in the office (faster internet, slow here, none at home) just to throw that out. Feb 06 03:16:43 Thanks for your advise Feb 06 03:16:53 Good luck. Feb 06 10:08:48 Do you guys know of a good book about the debian package system? The rest of my team would appreciate it... Feb 06 12:27:51 sveinse, Is if being offline the important part? What sort of material do you seek? Feb 06 12:32:23 some text material for teaching the team of how the apt repo is constructed and how deb pkgs are created. A book would be nice, simply because it's easier to read for first timers than a reference sheet :D Feb 06 12:33:09 I don't know of any good books on it, and I've been vaguely suspicious of the idea, as it is continually evolving. Feb 06 12:33:26 I myself had great support from a debian book with a chapter about deb pakaging many years ago Feb 06 12:33:45 http://www.debian.org/doc/maint-guide/ tends to be fairly up-to-date, and structured to read through. Feb 06 12:34:35 I agree, and the picture isn't as clear as one would expect as there are many ways to rome in the dpkg world Feb 06 12:34:43 Oh, indeed. Feb 06 12:35:40 The concepts tend to remain the same though, at least for the basic changelog, control, copyright, and rules. Feb 06 12:36:49 What goal do you see as the end-state for people having learned stuff? Creating new packages? Patching packages? Feb 06 12:44:04 Well. Quickly explained we are creating a commercial (embedded) product, where we chose to use Ubuntu. One reason for Ubuntu was its target for armv7 and that it's using the well-developed deb/apt distribution which solves *a lot* in terms of after sales support and upgrade. Feb 06 12:45:48 Now, today we have focused on getting the prototypes up and running, and thus all our code exists as compiled code outside of any debs. The next month, I need to transfer this code into deb packages. So the goal would be that our team can learn to make and buld deb pakages Feb 06 12:46:49 http://www.debian.org/doc/devel-manuals Feb 06 12:46:52 lots of pdfs Feb 06 12:46:58 Oh, that's all? For software for which you are the original developers? Feb 06 12:47:05 There will be three categories of packages: ubuntu vanilla (unmodified), modified pacakges and our own custom. Feb 06 12:47:26 The two first are easy. apt-get source and then modify it is the easy part Feb 06 12:47:27 unmodified is trivial. custom is incredibly easy. modified is hard. Feb 06 12:47:58 May you always select such benign packages to modify :) Feb 06 12:48:18 But if it's your own code, it's easy, as follows: Feb 06 12:48:25 1) make a release tarball Feb 06 12:49:07 2) name it ${SOFTWARE}_${VERSION}.orig.tar.gz Feb 06 12:49:14 3) unpack it Feb 06 12:49:21 4) create a directory "debian" Feb 06 12:49:36 5) cp /usr/share/doc/debhelper/examples/rules.tiny debian/rules Feb 06 12:50:21 6) create a debian/copyright file: http://dep.debian.net/deps/dep5/ is a reference but once you have one, the rest are likely to be copy & paste Feb 06 12:50:51 7) create a debian/control file: http://www.debian.org/doc/debian-policy/ch-controlfields.html lists all the useful fields. Feb 06 12:51:00 8) echo 7> debian/compat Feb 06 12:51:18 9) `dch --create` to create a debian/copyright file Feb 06 12:51:36 10) `debuild -S -us -uc` to create an unsigned source package. Feb 06 12:53:06 There's some work ongoing to more aggressively automate generation of debian/copyright, but at this point it seems mostly to be talk about it: I've seen scripts, but nothing very formal yet. Feb 06 12:53:23 9 is wrong :) Feb 06 12:53:39 you mean debian/changelog there ;) Feb 06 12:53:56 There's been a lot more work to automate generation of debian/control, but everything I've seen has been implementation language specific. Feb 06 12:54:14 ogra, Oh, heh. Command is right, explanation is wrong. Feb 06 12:54:44 persia, thanks. Then the more difficult parts (for me as some kind of sys.admin to this): Feb 06 12:54:51 This is what I get for trying to type my 10-steps-to-package-anything instructions from memory when I ought to go to bed :) Feb 06 12:54:59 heh Feb 06 12:56:20 1) I need to copy the official debs to our own repo (since we have ultimate product responsibility). I'm working on a tool I've named "apt-fetch" to get and build a debian repository from a --get-selection list Feb 06 12:57:21 2) The steps above is for native building. The management wants us to use the build farm and not native compilation. Hence I'm planning on looking into xdeb & friends Feb 06 12:58:00 3) Setup our own build server for rebuilding & uploading the packages Feb 06 12:58:22 I don't have any good solution for 1) . For a while, there was a package called "falcon" in the archives that was a sensible small archive management suite, but it's gone. Feb 06 12:58:25 the above has notrhing to do with native/non-native Feb 06 12:58:39 its just to create a debian source packge Feb 06 12:58:49 Regarding 2) the steps above are entirely about building a source package. How you create the binary package is entirely up to you. Feb 06 12:59:25 persia, 1) is actually not so hard. I'm considering publishing the tool to the community later on it there are any interest for it Feb 06 12:59:26 I believe that you end up with a package that ought respond well to cross-compilation with those instructions (although I actively discourage the use of cross-compilation) Feb 06 13:00:13 sveinse, There's regular interest in a small archive management suite, as dak or Soyuz or similar are painful, and there are too many variants of hackish scripts using apt-ftparchive and similar. Feb 06 13:00:38 But the issue in the past has usually been that nobody who wasn't running a distro wanted to maintain it, and most of them don't scale to running a full distro. Feb 06 13:01:47 For 3), debomatic is one of the easiest ways to set up an automated build environment: https://launchpad.net/debomatic Feb 06 13:02:36 The tool I'm writing (in python) is taking a sources.list and a --get-selections list, and it downloads everything from the servers building exact same file structure as used on the servers (hence pool/ and dists/). Releases and Packages are however stripped for non-relevant packages. Feb 06 13:02:45 It doesn't currently have built-in cross-compilation support, but there's some docs on how it might be implemented, and it's based on pbuilder, which has lots of hooks. Feb 06 13:03:53 Are you aware of the apt-fetch on CPAN? It does something entirely different, but has a similar name. If you want to popularise your suite, I'd suggest a different name. Feb 06 13:04:15 persia, no I don't. Thanks Feb 06 13:04:28 Also, while that's useful in terms of creating a partial mirror, it will need some extension to be able to handle updates with new packages and resign, etc. Feb 06 13:05:31 Yes, I plan to add that. We will pull updates from the ubuntu repos a regular intervals, so we need to handle that exact situation Feb 06 13:05:43 Also for your customisations, etc. Feb 06 13:06:27 I don't tend to follow them that much, but you might check with the gNewSense or Mint folk, as some of the more complex Ubuntu derivatives who maintain their own repositories: they may also have useful tools. Feb 06 13:06:45 Regarding cross compilation of ubuntu, we actually were capable for putting together a working system for compiling apps Feb 06 13:08:05 Basically we create a rootfs with rootstock and then unpack one on the host computer and installs everything needed for dev on it. The compiler's --sysroot handles that kind of building perfectly (for us). Feb 06 13:08:25 However the new of --sysroot being a mistake in the cross compiler were a blow to me. Feb 06 13:09:01 hrw has indicated I should use xdeb instead, but I havent gotten around experimenting with it yet Feb 06 13:09:10 That's not a very safe way to build packages, because of build-dependency management. Feb 06 13:09:31 Sure, we did that to SW not having any debian dependencies yet Feb 06 13:10:21 The worry is that it will build against whatever headers or libraries you happen to have in the rootfs. Feb 06 13:10:51 For Ubuntu, we try to build packages in a minimal environment, so as to reduce the chance of unexpected library linking, etc. Feb 06 13:11:34 I suppose it depends how aggressive your precompilation configuration automation is: if you're using autotools to maximal advantage, it can end up making a lot of difference. If you have a very basic Makefile, it matters less. Feb 06 13:12:22 xdeb is definitely interesting, and worth looking at, but you may find that you want to bundle that inside pbuilder or sbuild or something to assure build repeatibility and clean builds. Feb 06 13:13:32 all deps is manual as of today. I should mention we base the applications SW on Qt (w/qws) which we must build ourselves Feb 06 13:14:03 Why must you build it yourselves? Feb 06 13:14:21 I haven't decided if we should let the developers build the binary packages (manually) or I we need to invest in an automated source->binary build server Feb 06 13:14:40 I strongly advise investing in an automated source -> binary build server. Feb 06 13:14:42 Well, I haven't found qt in ubuntu without X11 Feb 06 13:15:16 The software side is easy (see debomatic above), and it avoids opportunities for an unbelievable array of potential mistakes. Feb 06 13:16:22 Ah, if you don't want X, that's trickier. Yeah, I'm not sure we do that. Feb 06 13:17:14 We specifically don't intend to support embedded use (in the sense of small devices intended to be part of a larger system), but rather focus on devices expecting full interaction (phones, handhelds, tablets, laptops, desktops, servers, etc.) Feb 06 13:17:19 So for the overall view of this, you'll all have to excuse me for asking a lot of question. There's a lot of things to take up on this (being ubuntu, non-native enviroment, build server, etc.) Feb 06 13:17:41 Asking questions is fine. That's why there is this channel. Feb 06 13:17:57 Mind you, there's a price: we're expecting you to answer the same questions when someone else asks them later :) Feb 06 13:19:20 that's fine! and likewise, being a commercial product, we intend to honour every obligation in respect of FOSS licenses. Feb 06 13:20:07 Oh, excellent! That's always lovely to hear. Feb 06 13:20:22 Can you share the form-factor yet? Feb 06 13:22:30 I can't tell much. Two devices, one deeply embedded (box with connectors) and one display unit with 5.7" display with capacitive touch. All based on omap3 Feb 06 13:23:12 Oh nifty. When it gets announced, please share the URLs. Feb 06 13:23:23 These are a system, and thus the customer will not know the presence of Linux nor ubuntu Feb 06 13:23:47 Sure. Trust me, as an engineer on this, I'd love to share. But not yet Feb 06 13:23:55 Indeed. Sounds like something for factory automation or in-vehicle use, or similar (no, don't give me hints). Feb 06 13:24:21 That said, if you're building an open platform, I'm sure we can find ways to repurpose it, if we like the shape :) Feb 06 13:25:11 :D tivoization will always be an issue/opertunity (depending on which side of the table you're on) Feb 06 13:25:56 If you're doing it that way, take extra care with the licenses: there's heaps of GPL3 code in Ubuntu that you'd want to work around. Feb 06 13:27:10 But this has been a really long 5-minutes-check-backscroll-before-I-sleep, so I'll catch you another time. Good luck with your training and setup of your build/distribution system. Feb 06 13:27:26 persia, thanks a lot. It's been a pleasure Feb 06 18:39:46 since some days, I'm testing the ubuntu pre-installed for omap3 Feb 06 18:40:04 the problem is the hdmi resolution Feb 06 18:40:21 I'm not that rich, and my screen is 1024x768 Feb 06 18:40:45 the image tries to start using 1280x720 or something Feb 06 18:41:08 so I folllowed this page: https://wiki.ubuntu.com/ARM/BeagleEditBootscr Feb 06 18:41:33 everything went fine, I modified the boot.scr (located in the vfat partition .. and so on Feb 06 18:41:47 and the result is "resolution not accepted" Feb 06 18:42:06 how can I change the resolution for true ? Feb 06 18:43:07 I must add : both maverick and natty give the same issue Feb 06 18:45:22 the card is beagleboard xM , perfectly working with Angstrom shipped with Feb 06 18:46:00 xM v2 / A8 / no NAND / 512 MB RAM , and so on Feb 06 18:46:25 thanks in advance for any hint Feb 06 19:09:49 omaps modesetting code sucks Feb 06 19:27:29 Baybal: I followed ubuntu way, but maybe I did something wrongly ? Feb 06 19:27:55 simply code is somehow weird Feb 06 19:28:00 it needs rewriting Feb 06 19:28:13 it's 5 minutes jib, yet nobody made it Feb 06 19:28:33 Baybal: do you have links ? Feb 06 19:28:38 no Feb 06 19:29:12 Baybal: I'm trying to setup the BB, because I'd like to port a big software on ARM family, so I'm simply stuck at the preliminary steps Feb 06 19:29:47 Baybal: but I can try to help (if I got the skills) Feb 06 19:30:45 you need to hack into omapfb Feb 06 19:33:38 Baybal: ok Feb 06 19:34:18 ideally it should be able to reinitialize the hardware and set sane video mode Feb 06 19:34:41 preferably basing on data from ddc Feb 06 19:38:36 Baybal: I'll start with adding the serial, per see what exactly happens. In fact, I'm not sure the bad resolution is the only issue Feb 06 19:38:46 but this is a good candidate Feb 06 19:38:49 imho Feb 06 19:40:01 * ericb2 just wondering why things work well with Angstrom, and not with Ubuntu **** ENDING LOGGING AT Mon Feb 07 02:59:56 2011