| === arraybolt3_ is now known as arraybolt3 | ||
| cjwatson | mitya57: fixed | 11:39 |
|---|---|---|
| cxl | Hi all, I can't login to launchpad for some reason and it said to come and complain about it here :) | 11:58 |
| cxl | (Error ID: OOPS-cd19171334b3ad28f9561e94cd96c5b1) | 11:58 |
| cjwatson | guruprasad: ^ | 12:03 |
| === cjwatson changed the topic of #launchpad to: Help contact: guruprasad (05:00-13:00 UTC) | Launchpad is an open source project: https://dev.launchpad.net/ | This channel is logged: http://irclogs.ubuntu.com/ | User Guide https://help.launchpad.net/ | Support and spam reporting: https://answers.launchpad.net/launchpad | ||
| guruprasad | cxl, checking now | 12:15 |
| cxl | guruprasad: thanks | 12:19 |
| guruprasad | cxl, you had an existing Launchpad account with the same email address that was causing the issue. I have now merged the new account into the old one and you should now be able to log in | 12:22 |
| guruprasad | If you wish, you can change your Launchpad username - see https://help.launchpad.net/YourAccount/NewAccount for details. | 12:23 |
| mitya57 | cjwatson: thanks! | 13:30 |
| cxl | guruprasad: Noted, thank you | 13:37 |
| surfzoid | Hi | 16:05 |
| surfzoid | I'm trying to build a deb of my qt project on launchpad, locally on m RPI400 it compil perfect, but sound like launchpad don't manage well rpath : https://launchpadlibrarian.net/657995979/buildlog_ubuntu-kinetic-amd64.qtvsplayer_1.0.39-0~202303271523~ubuntu22.10.1_BUILDING.txt.gz i'm a pure noob with deb and launchpad, is there a easy workaround in the deb files? | 16:06 |
| cjwatson | surfzoid: Launchpad doesn't go deep enough in your build to be able to affect this one way or another. You should be able to reproduce the exact same failure locally using sbuild (see https://wiki.ubuntu.com/SimpleSbuild for setup advice). | 16:21 |
| cjwatson | surfzoid: Because of this it's hard for us to offer advice, though from a brief glance at that build log, "-Wl,-rpath=/usr/lib64/QtVsPlayer" looks pretty odd - /usr/lib64 isn't really a path you find on Ubuntu. | 16:22 |
| cjwatson | surfzoid: It could also just be that you're missing some build-dependencies. | 16:23 |
| surfzoid | cjwatson: locally i can do qmake & make & make install, i also suceffully build rpm on fedora COPR | 16:23 |
| cjwatson | surfzoid: Sure, but that doesn't mean it's Launchpad's fault either. | 16:23 |
| cjwatson | surfzoid: Where are you expecting to get libPlayCtrl from, for example? It doesn't seem to be built earlier in the build, and it doesn't seem to be part of your build-dependencies, unless I'm missing something | 16:24 |
| surfzoid | cjwatson: unlucky it is more complicated, those 3 lib came from an opensource sdk and are include in my qt project without source code | 16:25 |
| surfzoid | cjwatson: yes of course, i' m noob with lp and deb but sure there is a good sgntaxe to provide somewhere' | 16:25 |
| cjwatson | surfzoid: I really think you should start by setting up something like sbuild that will give you a clean build environment locally, without pollution from your environment or any build-dependencies you might have forgotten to mention. | 16:26 |
| surfzoid | cjwatson: it could be more clear with the project file :P https://github.com/surfzoid/QtVsPlayer/blob/main/QtVsPlayer.pro | 16:26 |
| cjwatson | Testing with make etc. is notoriously bad at making sure that your project will build in a clean environment. | 16:26 |
| surfzoid | i got in mind a workarround but surely dirty, i got this kind of troubles when build rpm, qmake/qt don't search lib where i setup them but in rpath | 16:28 |
| surfzoid | cjwatson: is github worflow are clean? | 16:28 |
| cjwatson | surfzoid: Ah, it looks like something in the recipe build process has dropped the .so files from the source package | 16:29 |
| cjwatson | surfzoid: If you fetch and unpack the .dsc and .tar.xz files from https://launchpad.net/~surfzoid/+archive/ubuntu/qtvsplayer/+packages, you'll find that those prebuilt .so files are missing | 16:29 |
| surfzoid | cjwatson: hooooo i never think about that since few day i brake my head! | 16:29 |
| cjwatson | Let's see if I can see why that's happening | 16:30 |
| surfzoid | cjwatson: i had read so many doc and test so many combination, how prevent that! | 16:31 |
| surfzoid | cjwatson: one hundred thank yu | 16:31 |
| surfzoid | i cannot say in control :source : https://github.com/loimu/zeit/archive/refs/tags/v%{version}.tar.gz | 16:34 |
| surfzoid | something like that? | 16:34 |
| cjwatson | No, I'm trying to work out what the best fix is | 16:38 |
| cjwatson | I mean you could not use a recipe and instead build and upload the source package yourself, that's definitely an option, but it's more work | 16:38 |
| surfzoid | cjwatson: and more complicated? my dirty work arround is in rule : wget https://github/missinglib /corectpath | 16:40 |
| cjwatson | However, is there in fact a tarball released by upstream here that you want to use as a base? | 16:40 |
| cjwatson | Your dirty workaround won't work, don't bother with that | 16:40 |
| surfzoid | cjwatson: my goal is to bridge lp and github, on github i se tag as release number to build pkg with this number | 16:41 |
| surfzoid | **use | 16:42 |
| cjwatson | Is there an upstream release tarball that you could use if I can help you integrate it? | 16:42 |
| surfzoid | cjwatson: to bild all rpms i use https://github.com/surfzoid/QtVsPlayer/archive/%{version}/%{name}-%{version}.tar.gz this is wath u ask? | 16:44 |
| surfzoid | **build | 16:44 |
| surfzoid | this select the good tag of release https://github.com/surfzoid/QtVsPlayer/releases | 16:45 |
| cjwatson | yes, please wait | 16:47 |
| surfzoid | cjwatson: with pleasure | 16:47 |
| cjwatson | Hm, I almost wonder whether this is something we'd be better off changing in our recipe machinery. This really isn't especially easy :-( | 16:51 |
| surfzoid | cjwatson: hhaaa my first launchpad expire will be celebrity :P | 16:52 |
| surfzoid | **experience | 16:52 |
| surfzoid | the strange is someone write "del so", | 16:54 |
| cjwatson | I don't know what that last sentence means | 17:02 |
| cjwatson | I think https://code.launchpad.net/~cjwatson/launchpad-buildd/+git/launchpad-buildd/+merge/439758 is the least unreasonable fix here | 17:03 |
| surfzoid | cjwatson: somewhere in launchpad, a dev say "drop .so files" that's strange | 17:03 |
| cjwatson | No, somewhere in dpkg | 17:03 |
| cjwatson | And this usually is a reasonable thing to do when building source packages, certainly those intended for upload to Debian where prebuilt binary files are quite strictly disallowed | 17:04 |
| cjwatson | But for recipes I think we probably do want to avoid invoking that default ignore list, because there's no reasonable way to override it | 17:04 |
| surfzoid | cjwatson: we should have the choice, in my case, the lib are from an opensource sdk of hikvision manufacturer, i ask then autorization to distrib it and they are agree and give me an agrement | 17:06 |
| cjwatson | surfzoid: And that's what my patch above will do | 17:06 |
| cjwatson | It doesn't give you an answer for absolutely right now because it needs to be reviewed and deployed first, but I think it's probably less unreasonably-complicated work for you than any of the other options I can think of, and it reduces our support load for the future | 17:07 |
| surfzoid | cjwatson: haaa i searched a way to mergw your patch with my recipe:P in fact you have modified launchpad, right? | 17:08 |
| cjwatson | Yes | 17:08 |
| surfzoid | cjwatson: yu made a good choice | 17:08 |
| cjwatson | Separately, I do still think the rpath you're setting is a bit wrong for Ubuntu | 17:10 |
| cjwatson | Honestly, you shouldn't be setting rpath at all here | 17:10 |
| cjwatson | You're shipping the libraries to the default system library path, so rpath is pointless. Just drop that bit | 17:10 |
| surfzoid | cjwatson: well mageia ask me to do like that | 17:10 |
| cjwatson | And all the postinst/prerm nonsense to manage /usr/lib64 | 17:10 |
| cjwatson | Mageia might ask for that, but that's no reason to ship it that way on Ubuntu | 17:11 |
| surfzoid | cjwatson: /usr/lib$ARCH/qtvsplayer/ in fact | 17:11 |
| surfzoid | cjwatson: i m not sure this useless i did that for my RPI4 | 17:12 |
| cjwatson | Hm | 17:12 |
| cjwatson | Oh, well in that case it's just that the prefix is wrong | 17:12 |
| surfzoid | again i m noob with pakaging:P | 17:13 |
| cjwatson | We don't use /usr/lib64 on Ubuntu. References to /usr/lib64 should be replaced by something like /usr/lib/$(DEB_HOST_MULTIARCH) (i.e. /usr/lib/x86_64-linux-gnu for amd64 builds) | 17:14 |
| surfzoid | we can imagine a patch of the .pro file just before build | 17:14 |
| surfzoid | cjwatson: but debian use /usr/lib64 ? | 17:14 |
| cjwatson | No, Ubuntu is the same as Debian here | 17:15 |
| cjwatson | The Debian world did multi-arch libraries in a different (and more extensible) way | 17:15 |
| surfzoid | DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH) | 17:15 |
| surfzoid | DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH) | 17:15 |
| surfzoid | cjwatson: but in my first deb from my worflow github i did a noob mistake, rm -fr /usr/lib64 a debian user say me, your deb had destroyed my system | 17:17 |
| cjwatson | Yeah this is why it's better to minimize the amount of messing around you do in postinst/prerm etc. scripts | 17:17 |
| surfzoid | hum very complicated the debian world :-D | 17:18 |
| cjwatson | Simpler, actually! | 17:18 |
| cjwatson | If you just ship files in the right place to begin with then you don't need to mess around with little shell script fragments at all. | 17:19 |
| surfzoid | when we think, linux is unix, just text files | 17:19 |
| cjwatson | The reason why "rm -fr /usr/lib64" broke a Debian system was that I skipped a detail above for simplicity. There is one place where /usr/lib64 is used for necessary cross-distribution compatibility, and that's /usr/lib64/ld-linux-x86-64.so.2. Which is errrr rather important for getting anything at all to run. | 17:20 |
| cjwatson | So, sure, if you randomly nuke the system's dynamic linker then indeed nothing will work afterwards :-) | 17:21 |
| cjwatson | (Actually /lib64, but /lib64 and /usr/lib64 are the same thing these days.) | 17:22 |
| surfzoid | in fact postinst is a worarround with sdk lib, the playctrl search openal in the same lib, path of it, so i just smlink | 17:22 |
| cjwatson | Just ship the files in the right place to start with, and kill the postinst. | 17:22 |
| surfzoid | and prerm clean correctly | 17:23 |
| cjwatson | You can move them around in debian/*.install or debian/rules if you need to - you don't have to patch the .pro file or whatever. | 17:23 |
| surfzoid | cjwatson: replace libxx/qtvsplayer by libxx | 17:24 |
| cjwatson | And if you do need symlinks you can just ship them properly in the actual .deb (e.g. debian/*.links files can be used to help with that). | 17:24 |
| surfzoid | cjwatson: i think qt "hard code the path in the executable | 17:24 |
| cjwatson | Anyway, I think I've given all the advice I can usefully give you, and it's dinnertime. | 17:24 |
| surfzoid | cjwatson: i thank yu and habe a good lunch | 17:25 |
| wontfix[m] | Are bzr branches on lp, git compatible? | 21:35 |
| cjwatson | wontfix[m]: In what sense? | 22:09 |
| wontfix[m] | Are old bzr repos/branches on lp git client compatible? | 22:15 |
| arraybolt3 | wontfix[m]: I do not believe so. bzr is fundamentally different from Git in how it operates, and it is still in use in some areas. So you will need a separate bzr client for it. | 22:25 |
| cjwatson | At various times there've been git plugins like git-remote-bzr that can let you use git with bzr remotes, but I'm not sure any of them are currently maintained. | 22:36 |
| cjwatson | Personally I think it's usually unwise to rely on anything like that in the long term, as opposed to as something quick to aid a migration. They're often pretty fragile. | 22:38 |
| cjwatson | Better to just use the corresponding VCS tool if you can. | 22:38 |
| wontfix[m] | It doesn't look like some of these packages are going to convert to git anytime soon. | 22:38 |
| cjwatson | IME it's best to just suck it up and use bzr for those. | 22:41 |
| cjwatson | Otherwise you can end up in the worst of both worlds ... | 22:41 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!