| === davidm_ is now known as Guest75348 | ||
| KC9SJQ | Howdy all, I wonder if I can get help with a question. | 01:55 |
|---|---|---|
| KC9SJQ | I am running a pandaboard with ubuntu 10.10, and have just installed a new Samsung CLP-325 printer | 01:56 |
| KC9SJQ | In printer and server settings, I turn on all sharing. | 01:56 |
| KC9SJQ | On a second computer, an asus 1015 (intel atom 450) running ubuntu x86 10.4, I can see the shared printer when I "Find a network printer" and give the ip, but from the laptop, attempting to print the test page gives a "Printer Not connected" error | 01:58 |
| KC9SJQ | Thoughts? | 02:03 |
| KC9SJQ | Anything? | 02:41 |
| persia | 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. | 03:10 |
| KC9SJQ | Yeah, I've been there before | 03:11 |
| KC9SJQ | I just wanted to make sure that there was nothing endian based in the cups protocol that could cause an issue. | 03:11 |
| KC9SJQ | Thanks, persia | 03:11 |
| persia | armel is the same endianness as i386 :) | 03:12 |
| persia | That said, there *might* be an issue with miscompilation or similar, but that's a bit more unlikely. | 03:13 |
| KC9SJQ | well, so much for that consern | 03:13 |
| KC9SJQ | hehe, thanks. | 03:13 |
| persia | 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. | 03:13 |
| persia | I don't know anything about the printer stack, so can't help you precisely, sorry. | 03:13 |
| KC9SJQ | Well, I'll do so next time I'm in the office (faster internet, slow here, none at home) just to throw that out. | 03:16 |
| KC9SJQ | Thanks for your advise | 03:16 |
| persia | Good luck. | 03:16 |
| === davidm_ is now known as Guest34918 | ||
| sveinse | Do you guys know of a good book about the debian package system? The rest of my team would appreciate it... | 10:08 |
| persia | sveinse, Is if being offline the important part? What sort of material do you seek? | 12:27 |
| sveinse | 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 | 12:32 |
| persia | I don't know of any good books on it, and I've been vaguely suspicious of the idea, as it is continually evolving. | 12:32 |
| sveinse | I myself had great support from a debian book with a chapter about deb pakaging many years ago | 12:33 |
| persia | http://www.debian.org/doc/maint-guide/ tends to be fairly up-to-date, and structured to read through. | 12:33 |
| sveinse | I agree, and the picture isn't as clear as one would expect as there are many ways to rome in the dpkg world | 12:34 |
| persia | Oh, indeed. | 12:34 |
| persia | The concepts tend to remain the same though, at least for the basic changelog, control, copyright, and rules. | 12:35 |
| persia | What goal do you see as the end-state for people having learned stuff? Creating new packages? Patching packages? | 12:36 |
| sveinse | 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. | 12:43 |
| sveinse | 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 | 12:45 |
| ogra | http://www.debian.org/doc/devel-manuals | 12:46 |
| ogra | lots of pdfs | 12:46 |
| persia | Oh, that's all? For software for which you are the original developers? | 12:46 |
| sveinse | There will be three categories of packages: ubuntu vanilla (unmodified), modified pacakges and our own custom. | 12:46 |
| sveinse | The two first are easy. apt-get source and then modify it is the easy part | 12:47 |
| persia | unmodified is trivial. custom is incredibly easy. modified is hard. | 12:47 |
| persia | May you always select such benign packages to modify :) | 12:47 |
| persia | But if it's your own code, it's easy, as follows: | 12:47 |
| persia | 1) make a release tarball | 12:48 |
| persia | 2) name it ${SOFTWARE}_${VERSION}.orig.tar.gz | 12:48 |
| persia | 3) unpack it | 12:48 |
| persia | 4) create a directory "debian" | 12:48 |
| persia | 5) cp /usr/share/doc/debhelper/examples/rules.tiny debian/rules | 12:49 |
| persia | 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 | 12:49 |
| persia | 7) create a debian/control file: http://www.debian.org/doc/debian-policy/ch-controlfields.html lists all the useful fields. | 12:50 |
| persia | 8) echo 7> debian/compat | 12:50 |
| === davidm_ is now known as Guest43458 | ||
| persia | 9) `dch --create` to create a debian/copyright file | 12:50 |
| persia | 10) `debuild -S -us -uc` to create an unsigned source package. | 12:51 |
| persia | 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. | 12:52 |
| ogra | 9 is wrong :) | 12:53 |
| ogra | you mean debian/changelog there ;) | 12:53 |
| persia | There's been a lot more work to automate generation of debian/control, but everything I've seen has been implementation language specific. | 12:53 |
| persia | ogra, Oh, heh. Command is right, explanation is wrong. | 12:53 |
| sveinse | persia, thanks. Then the more difficult parts (for me as some kind of sys.admin to this): | 12:54 |
| persia | 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 :) | 12:54 |
| ogra | heh | 12:54 |
| sveinse | 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 | 12:55 |
| sveinse | 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 | 12:56 |
| sveinse | 3) Setup our own build server for rebuilding & uploading the packages | 12:57 |
| persia | 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. | 12:57 |
| ogra | the above has notrhing to do with native/non-native | 12:58 |
| ogra | its just to create a debian source packge | 12:58 |
| persia | Regarding 2) the steps above are entirely about building a source package. How you create the binary package is entirely up to you. | 12:58 |
| sveinse | 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 | 12:59 |
| persia | 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) | 12:59 |
| persia | 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. | 12:59 |
| persia | 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. | 13:00 |
| persia | For 3), debomatic is one of the easiest ways to set up an automated build environment: https://launchpad.net/debomatic | 13:01 |
| sveinse | 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. | 13:02 |
| persia | 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. | 13:02 |
| persia | 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. | 13:03 |
| sveinse | persia, no I don't. Thanks | 13:03 |
| persia | 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. | 13:04 |
| sveinse | 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 | 13:05 |
| persia | Also for your customisations, etc. | 13:05 |
| persia | 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. | 13:06 |
| sveinse | Regarding cross compilation of ubuntu, we actually were capable for putting together a working system for compiling apps | 13:06 |
| sveinse | 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). | 13:07 |
| sveinse | However the new of --sysroot being a mistake in the cross compiler were a blow to me. | 13:08 |
| sveinse | hrw has indicated I should use xdeb instead, but I havent gotten around experimenting with it yet | 13:08 |
| persia | That's not a very safe way to build packages, because of build-dependency management. | 13:08 |
| sveinse | Sure, we did that to SW not having any debian dependencies yet | 13:09 |
| persia | The worry is that it will build against whatever headers or libraries you happen to have in the rootfs. | 13:09 |
| persia | For Ubuntu, we try to build packages in a minimal environment, so as to reduce the chance of unexpected library linking, etc. | 13:10 |
| persia | 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. | 13:11 |
| persia | 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. | 13:11 |
| sveinse | all deps is manual as of today. I should mention we base the applications SW on Qt (w/qws) which we must build ourselves | 13:13 |
| persia | Why must you build it yourselves? | 13:13 |
| sveinse | 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 | 13:13 |
| persia | I strongly advise investing in an automated source -> binary build server. | 13:14 |
| sveinse | Well, I haven't found qt in ubuntu without X11 | 13:14 |
| persia | The software side is easy (see debomatic above), and it avoids opportunities for an unbelievable array of potential mistakes. | 13:14 |
| persia | Ah, if you don't want X, that's trickier. Yeah, I'm not sure we do that. | 13:15 |
| persia | 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.) | 13:16 |
| sveinse | 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.) | 13:16 |
| persia | Asking questions is fine. That's why there is this channel. | 13:17 |
| persia | Mind you, there's a price: we're expecting you to answer the same questions when someone else asks them later :) | 13:17 |
| sveinse | that's fine! and likewise, being a commercial product, we intend to honour every obligation in respect of FOSS licenses. | 13:18 |
| persia | Oh, excellent! That's always lovely to hear. | 13:19 |
| persia | Can you share the form-factor yet? | 13:19 |
| sveinse | 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 | 13:22 |
| persia | Oh nifty. When it gets announced, please share the URLs. | 13:22 |
| sveinse | These are a system, and thus the customer will not know the presence of Linux nor ubuntu | 13:22 |
| sveinse | Sure. Trust me, as an engineer on this, I'd love to share. But not yet | 13:23 |
| persia | Indeed. Sounds like something for factory automation or in-vehicle use, or similar (no, don't give me hints). | 13:23 |
| persia | That said, if you're building an open platform, I'm sure we can find ways to repurpose it, if we like the shape :) | 13:23 |
| sveinse | :D tivoization will always be an issue/opertunity (depending on which side of the table you're on) | 13:24 |
| persia | 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. | 13:25 |
| persia | 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. | 13:26 |
| sveinse | persia, thanks a lot. It's been a pleasure | 13:27 |
| ericb2 | since some days, I'm testing the ubuntu pre-installed for omap3 | 18:39 |
| ericb2 | the problem is the hdmi resolution | 18:39 |
| ericb2 | I'm not that rich, and my screen is 1024x768 | 18:39 |
| ericb2 | the image tries to start using 1280x720 or something | 18:40 |
| ericb2 | so I folllowed this page: https://wiki.ubuntu.com/ARM/BeagleEditBootscr | 18:40 |
| ericb2 | everything went fine, I modified the boot.scr (located in the vfat partition .. and so on | 18:41 |
| ericb2 | and the result is "resolution not accepted" | 18:41 |
| ericb2 | how can I change the resolution for true ? | 18:41 |
| ericb2 | I must add : both maverick and natty give the same issue | 18:42 |
| ericb2 | the card is beagleboard xM , perfectly working with Angstrom shipped with | 18:44 |
| ericb2 | xM v2 / A8 / no NAND / 512 MB RAM , and so on | 18:45 |
| ericb2 | thanks in advance for any hint | 18:45 |
| === davidm_ is now known as Guest79175 | ||
| Baybal | omaps modesetting code sucks | 19:09 |
| ericb2 | Baybal: I followed ubuntu way, but maybe I did something wrongly ? | 19:27 |
| Baybal | simply code is somehow weird | 19:27 |
| Baybal | it needs rewriting | 19:27 |
| Baybal | it's 5 minutes jib, yet nobody made it | 19:27 |
| ericb2 | Baybal: do you have links ? | 19:28 |
| Baybal | no | 19:28 |
| ericb2 | 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 | 19:28 |
| ericb2 | Baybal: but I can try to help (if I got the skills) | 19:29 |
| Baybal | you need to hack into omapfb | 19:30 |
| ericb2 | Baybal: ok | 19:33 |
| Baybal | ideally it should be able to reinitialize the hardware and set sane video mode | 19:33 |
| Baybal | preferably basing on data from ddc | 19:34 |
| ericb2 | 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 | 19:38 |
| ericb2 | but this is a good candidate | 19:38 |
| ericb2 | imho | 19:38 |
| * ericb2 just wondering why things work well with Angstrom, and not with Ubuntu | 19:39 | |
| === ogra is now known as Guest14562 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!