=== arraybolt3_ is now known as arraybolt3
cjwatsonmitya57: fixed11:39
cxlHi 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
cjwatsonguruprasad: ^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
guruprasadcxl, checking now12:15
cxlguruprasad: thanks12:19
guruprasadcxl, 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 in12:22
guruprasadIf you wish, you can change your Launchpad username - see https://help.launchpad.net/YourAccount/NewAccount for details.12:23
mitya57cjwatson: thanks!13:30
cxlguruprasad: Noted, thank you13:37
surfzoidI'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
cjwatsonsurfzoid: 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
cjwatsonsurfzoid: 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
cjwatsonsurfzoid: It could also just be that you're missing some build-dependencies.16:23
surfzoidcjwatson: locally i can do qmake & make & make install, i also suceffully build rpm on fedora COPR16:23
cjwatsonsurfzoid: Sure, but that doesn't mean it's Launchpad's fault either.16:23
cjwatsonsurfzoid: 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 something16:24
surfzoidcjwatson: unlucky it is more complicated, those 3 lib came from an opensource sdk and are include in my qt project without source code16:25
surfzoidcjwatson: yes of course, i' m noob with lp and deb but sure there is a good sgntaxe to provide somewhere'16:25
cjwatsonsurfzoid: 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
surfzoidcjwatson: it could be more clear with the project file :P https://github.com/surfzoid/QtVsPlayer/blob/main/QtVsPlayer.pro16:26
cjwatsonTesting with make etc. is notoriously bad at making sure that your project will build in a clean environment.16:26
surfzoidi 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 rpath16:28
surfzoidcjwatson: is github worflow are clean?16:28
cjwatsonsurfzoid: Ah, it looks like something in the recipe build process has dropped the .so files from the source package16:29
cjwatsonsurfzoid: 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 missing16:29
surfzoidcjwatson: hooooo i never think about that since few day i brake my head!16:29
cjwatsonLet's see if I can see why that's happening16:30
surfzoidcjwatson: i had read so many doc and test so many combination, how prevent that!16:31
surfzoidcjwatson: one hundred thank yu16:31
surfzoidi cannot say in control :source : https://github.com/loimu/zeit/archive/refs/tags/v%{version}.tar.gz16:34
surfzoidsomething like that?16:34
cjwatsonNo, I'm trying to work out what the best fix is16:38
cjwatsonI 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 work16:38
surfzoidcjwatson: and more complicated? my dirty work arround is in rule : wget https://github/missinglib /corectpath16:40
cjwatsonHowever, is there in fact a tarball released by upstream here that you want to use as a base?16:40
cjwatsonYour dirty workaround won't work, don't bother with that16:40
surfzoidcjwatson: my goal is to bridge lp and github, on github i se tag as release number to build pkg with this number16:41
cjwatsonIs there an upstream release tarball that you could use if I can help you integrate it?16:42
surfzoidcjwatson: to bild all rpms i use  https://github.com/surfzoid/QtVsPlayer/archive/%{version}/%{name}-%{version}.tar.gz this is wath u ask?16:44
surfzoidthis select the good tag of release https://github.com/surfzoid/QtVsPlayer/releases16:45
cjwatsonyes, please wait16:47
surfzoidcjwatson: with pleasure16:47
cjwatsonHm, 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
surfzoidcjwatson: hhaaa my first launchpad expire will be celebrity :P16:52
surfzoidthe strange is someone write "del so", 16:54
cjwatsonI don't know what that last sentence means17:02
cjwatsonI think https://code.launchpad.net/~cjwatson/launchpad-buildd/+git/launchpad-buildd/+merge/439758 is the least unreasonable fix here17:03
surfzoidcjwatson: somewhere in launchpad, a dev say "drop .so files" that's strange17:03
cjwatsonNo, somewhere in dpkg17:03
cjwatsonAnd 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 disallowed17:04
cjwatsonBut for recipes I think we probably do want to avoid invoking that default ignore list, because there's no reasonable way to override it17:04
surfzoidcjwatson: 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 agrement17:06
cjwatsonsurfzoid: And that's what my patch above will do17:06
cjwatsonIt 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 future17:07
surfzoidcjwatson: haaa i searched a way to mergw your patch with my recipe:P in fact you have modified launchpad, right?17:08
surfzoidcjwatson: yu made a good choice17:08
cjwatsonSeparately, I do still think the rpath you're setting is a bit wrong for Ubuntu17:10
cjwatsonHonestly, you shouldn't be setting rpath at all here17:10
cjwatsonYou're shipping the libraries to the default system library path, so rpath is pointless.  Just drop that bit17:10
surfzoidcjwatson: well mageia ask me to do like that17:10
cjwatsonAnd all the postinst/prerm nonsense to manage /usr/lib6417:10
cjwatsonMageia might ask for that, but that's no reason to ship it that way on Ubuntu17:11
surfzoidcjwatson: /usr/lib$ARCH/qtvsplayer/ in fact17:11
surfzoidcjwatson: i m not sure this useless i did that for my RPI417:12
cjwatsonOh, well in that case it's just that the prefix is wrong17:12
surfzoidagain i m noob with pakaging:P17:13
cjwatsonWe 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
surfzoidwe can imagine a patch of the .pro file just before build17:14
surfzoidcjwatson: but debian use /usr/lib64 ?17:14
cjwatsonNo, Ubuntu is the same as Debian here17:15
cjwatsonThe Debian world did multi-arch libraries in a different (and more extensible) way17:15
surfzoidDEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)17:15
surfzoidDEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)17:15
surfzoidcjwatson: 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 system17:17
cjwatsonYeah this is why it's better to minimize the amount of messing around you do in postinst/prerm etc. scripts17:17
surfzoidhum very complicated the debian world :-D17:18
cjwatsonSimpler, actually!17:18
cjwatsonIf 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
surfzoidwhen we think, linux is unix, just text files17:19
cjwatsonThe 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
cjwatsonSo, 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
surfzoidin fact postinst is a worarround with sdk lib, the playctrl search openal in the same lib, path of it, so i just smlink17:22
cjwatsonJust ship the files in the right place to start with, and kill the postinst.17:22
surfzoidand prerm clean correctly17:23
cjwatsonYou 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
surfzoidcjwatson: replace libxx/qtvsplayer by libxx17:24
cjwatsonAnd 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
surfzoidcjwatson: i think qt "hard code the path in the executable17:24
cjwatsonAnyway, I think I've given all the advice I can usefully give you, and it's dinnertime.17:24
surfzoidcjwatson: i thank yu and habe a good lunch17:25
wontfix[m]Are bzr branches on lp, git compatible?21:35
cjwatsonwontfix[m]: In what sense?22:09
wontfix[m]Are old bzr repos/branches on lp git client compatible?22:15
arraybolt3wontfix[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
cjwatsonAt 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
cjwatsonPersonally 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
cjwatsonBetter 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
cjwatsonIME it's best to just suck it up and use bzr for those.22:41
cjwatsonOtherwise 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!