| === ro is now known as dax | ||
| === sil2100_ is now known as sil2100 | ||
| sil2100 | doko: hello! We would need to get miral included in main: https://bugs.launchpad.net/ubuntu/+source/miral/+bug/1651384 | 10:44 |
|---|---|---|
| ubottu | Launchpad bug 1651384 in miral (Ubuntu) "[MIR] miral" [Critical,New] | 10:44 |
| doko | sil2100: last work day this year, I try to have a look, but otherwise this has to wait til 2017 | 10:45 |
| sil2100 | doko: thanks! | 10:47 |
| sil2100 | greyback: ^ | 10:49 |
| === JanC_ is now known as JanC | ||
| caribou | Is it possible to get someone from the SRU team to get cloud-init v0.7.8-49-g9e904bb-0ubuntu1~16.04.3 into xenial-proposed pls ? | 11:29 |
| xnox | i have just realised that I have just two more work days before I'm done for the year \o/ | 11:58 |
| slashd | for sru, could you please take action on "os-prober" [1.70ubuntu3.2] waiting in the Xenial upload queue (importance : CRITICAL) in order for the pkg to be available in -proposed for testing. This solve a missing dependency in 1.70ubuntu3.1 (currently in -proposed) patch that solve a possible risk of corruption. Again .3.1 is already in proposed, I would like the SRU to go on top and 3.1 should definitely not land in -updates | 14:48 |
| slashd | without 3.2 debdiff on top | 14:48 |
| === scottt is now known as Guest37114 | ||
| === rcj` is now known as rcj | ||
| === rcj is now known as Guest61336 | ||
| === Guest61336 is now known as rcj | ||
| slangasek | stgraber, infinity, kees, mdeslaur: TB meeting now? | 17:00 |
| mdeslaur | slangasek: whoops...sorry...did anyone show up? | 17:16 |
| GunnarHj | bdmurray: Saw you asked about bug #1633678. Yes, indeed I hope that somebody will upload it - that's why ubuntu-sponsors is subscribed. The proposed uploads are in the linked PPA. | 17:29 |
| ubottu | bug 1633678 in freshplayerplugin (Ubuntu Yakkety) "Compability issue with adobe-flashplugin" [High,In progress] https://launchpad.net/bugs/1633678 | 17:29 |
| bdmurray | GunnarHj: ack, uploading | 17:41 |
| GunnarHj | bdmurray: Great, thanks! | 17:41 |
| tzero | hi guys, new to packaging/maintainership; so far it seems that the packaging process is just a collection of arcane memorization. What's the deal with upstream tarballs? What do maintainers generally do for your normal github project? | 17:54 |
| nacc | tzero: have you read the packaging guide (probably the debian one) | 17:54 |
| tzero | nacc: yep, have it up now; wiki.d.o/Packaging/Intro ; it's probably benign, but debuild -us -uc gripes about a lack of upstream tarball | 17:55 |
| nacc | tzero: right, so you need an orig.tar.gz (roughly) which corresponds to the upstream you are based off of | 17:55 |
| rbasak | tzero: Github will give you a tarball for any tag. | 17:55 |
| tzero | what if the project is just a normal github project? with anything more complex than a hello world application the process seems to fall apart | 17:56 |
| nacc | tzero: oftentimes this can be obtained (if the pacakge already exists) with `pull-debian-source`/`pull-lp-source`. Given your question, i assume you need it from upstream directly, which rbasak indicated. From a packaging perspecitve, you could write a debian/watch file and add the github example | 17:56 |
| nacc | then uscan/uupdate will download the upstream tarball as specified | 17:56 |
| tzero | what's the common workflow for just iterating on a set of packaging files in-place? since I'm maintaining the application itself, I can change anything needed, but don't want to have to create tags that aren't needed | 17:57 |
| rbasak | tzero: it's useful to keep in mind that Debian will package anything. Release tarballs are a lowest common denominator. There does exist tooling to make things easier for your case, but that does necessarily add complexity. | 17:57 |
| nacc | tzero: well, the tags rbasak mentioned are for upstrema releases | 17:57 |
| nacc | tzero: which you should already be doing as an upstream :) | 17:58 |
| nacc | tzero: not sure i follow what you mean by 'iterating on a set of package files' in place? just do it? | 17:59 |
| tzero | hmm.. so if I create a tag of the current state of things, I can pull a tarball to get around the " | 18:02 |
| tzero | "error: can't build with source format '3.0 (quilt)': no upstream tarball found at" | 18:02 |
| tzero | sorry, IRC client line break issues... | 18:02 |
| nacc | tzero: well you tag upstream (totally independent of packaging) | 18:03 |
| nacc | tzero: then you can, for instance, setup debian/watch (see `man uscan`) to refer to the github page for downloading upstream tarballs | 18:03 |
| nacc | tzero: there is also debmake (amongst many other tools) to start with an upstream tarball (again, this should alrady exist, independent of packaging) and setup some basic debian-ization | 18:05 |
| tzero | isn't there a chicken-and-egg problem where I'm working on the files under debian/, I'd have to push those to github, download the upstream tarball, and test if it works? I'd just like to test the package building locally, before pushing the debian/ directory to github and revealing my ignorance to the world :) | 18:05 |
| nacc | no | 18:05 |
| nacc | tzero: debian/ is *not* in the upstream tarball normally | 18:06 |
| tzero | OHH! | 18:06 |
| nacc | tzero: i think you're making it way more complicated :) | 18:06 |
| nacc | tzero: upstream tarballs are 'pristine' in some sense -- unaltered upstream sources | 18:07 |
| nacc | tzero: you may want to read `man dpkg-source` | 18:07 |
| nacc | tzero: specifically (in your case) the "Format: 3.0 (quilt)" section to understand how the package gets built | 18:08 |
| tzero | hmm, so unlike RPM, the intermediary source package is required in this case | 18:08 |
| nacc | tzero: what do you mean by "intermediary source package"? There is an 'orig' tarball, which is not a package, and then a source package (which is what you're building now) and that builds (possibly many) binary packages | 18:09 |
| tzero | I'm just trying to get a generic concept of what's going on.. in RPM-land, the spec builds either the source package (.src.rpm) or the "desired end result" (.rpm); in arch and gentoo land, it's much more straightforward. but with dpkg/deb/dsc, it seems like the "spec" file builds a dsc, which then is used to create the desired end result (.deb) | 18:12 |
| nacc | yes it's different in .deb | 18:12 |
| nacc | there is no 'spec' for one thing :) | 18:13 |
| nacc | a source package is a '.dsc' file basically | 18:13 |
| nacc | as the .dsc file includes hashes of the tarballs used | 18:14 |
| nacc | and the binary packages that get built from it | 18:14 |
| nacc | you then build a source package into binary packages | 18:14 |
| tzero | ah ha... gotcha, thanks | 18:15 |
| tzero | I appreciate the patience and hand-holding; I'll read through some more stuff and see how it goes; thanks again | 18:18 |
| nacc | tzero: just keep asking questions :) | 18:19 |
| tzero | I stumbled on pdebuild at some point, it build some .deb files, but those didn't contain any of the application files at all. Is that a wrapper utility over the standard debuild? I found little mention of the .install file, but that seems necessary | 18:22 |
| nacc | tzero: i don't think you want to use pdebuild/pbuilder | 18:23 |
| nacc | tzero: i would suggest using sbuild at this point | 18:23 |
| nacc | tzero: or dpkg-buildpackage itself, if you want | 18:23 |
| tzero | and dpkg-buildpackage being the lowest-level of those utilities? | 18:31 |
| nacc | tzero: yes, aiui | 18:37 |
| infinity | tzero: FWIW, in your above example, spec files and debian/rules are pretty much 100% analogous. Yes, the way Debian developers prefer to work is to build a .dsc and then feed the .dsc to sbuild to produce debs, but that's no different than building an .srpm and feeding that to a build script to build an .rpm. It's just that people in RPM land tend to be more reckless. ;) | 19:11 |
| infinity | tzero: The "reckless" option in deb land is there too, just "dpkg-buildpackage -b" and boom, you have .deb binaries, no need to build the source package first (or just dpkg-buildpackage with no options will build source and binary in one go). | 19:12 |
| tzero | infinity: whoa, dpkg-buildpackage -b is great | 19:27 |
| === slashd- is now known as slashd | ||
| tzero | is there a better way to determine where files should be placed into the filesystem other than override_dh_install? by default, a package.install file containing lines such as 'usr/lib/python*/foo.py' only get included if I prefix the path to 'debian/package' | 19:50 |
| tzero | and even then, lintian says the files would actually be installed into '/debian/package/usr/lib/...' | 19:50 |
| tzero | without the .install file, the package only contains the default text files like COPYRIGHT, etc. If it makes a difference, the project has both GTK and Qt frontends, which are distributed as separate packages | 19:53 |
| rbasak | tzero: you're packaging a Python thing? We have helpers for Python, so if you have a setup.py that works, the packaging effort becomes minimal. See dh_python3(1). | 20:00 |
| dobey | tzero: generally, you shouldn't need to override_dh_install; by default just having usr/blah/foo in the .install files in multiple-binary-package scenarios should work. only if the files aren't installed via normal build system install rule, would there normally be a problem there | 20:04 |
| dobey | you shouldn't build with the prefix set to /debian/package | 20:05 |
| dobey | the defaults should be sufficient | 20:05 |
| tzero | oh, less is more I guess, whatever blog I initially read said to define a bunch of things | 20:15 |
| infinity | tzero: Less is definitely more in the new dh(1) style rules files. An ideal package should require zero overrides, and that's the best position to start from. | 20:20 |
| infinity | tzero: If something is particularly troublesome, but you feel like it's a something that dozens of other people should surely have suffered (like python modules), you'll often find there's a "dh --with foo" module that does all the heavy lifting. | 20:21 |
| infinity | tzero: And the added advantage of modules like dh-python, dh-systemd, etc is that they also make sure that, even if your upstream is vaguely Fedora or Arch centric, or just plain old /usr/local FHS, you'll often get magically mangled into something that plays nicely with Debian policy and other packages on the system. | 20:22 |
| tzero | oh, neat | 20:23 |
| tzero | is this a relatively new development in debhelper/cdbs? | 20:23 |
| infinity | Depends on how one defines "new". | 20:24 |
| infinity | dh(1) came to being in debhelper 7. Which was in 2008. But for some of us, that's indeed new. :) | 20:25 |
| infinity | The subsequent years have involved educating people to stop using cdbs and old-style debhelper rules. | 20:25 |
| infinity | And people writing clever addon modules to keep debian/rules tiny in the face of complex problems. | 20:26 |
| nacc | so i think the reason that php-horde-crypt is current stuck in excuses (and failing it's own autopkgtest) is that gpg by default doesn't have any secrets stored. THe debian autopkgtest 'pass' because in their env there is no /usr/bin/gpg and therefore all tests are skipped :/ | 20:28 |
| nacc | any ideas on how to fix that up? or is there a well-established 'set up gpg secrets for testing' example? | 20:28 |
| infinity | nacc: One could argue that the testbed shouldn't have gpg installed, but unlike builds, where we want minimal pollution to build reproducibly, it's almost better to have slightly dirty systems for running tests. | 20:29 |
| infinity | nacc: But, that debate aside, if the tests attempt to test a thing when gpg is there, I'd say that (a) gpg is an undeclared test dep, and (b) it should be made to pass said tests. | 20:30 |
| nacc | infinity: agreed, i can work on (b), although i think primarily it's just lacking a 'configure a fake gpg secret' (based upon some cursory debugging so far that gpg basically complains about there being no secrets) | 20:31 |
| nacc | infinity: but yeah, it probably should be an explicit dep and the tests should be fixed, you're right | 20:32 |
| infinity | nacc: As for well-established snakeoil. I dunno. Probably not. But I'd suggest pregenrating an ascii-armored keypair and shipping it with the tests. Generating keys at runtime is problematic (see, for instance, the kernel hack that starts generating a key at the beginning of the build and hopes enough entropy has been generated by the end that one showed up in the background). | 20:32 |
| infinity | And, yes, the kernel has lost that race before. :P | 20:32 |
| nacc | infinity: good idea on the keypair | 20:32 |
| infinity | Though I think the current iteration of upstream makefiles are more resilient to that, and wait correctly. | 20:32 |
| === NComman`` is now known as NCommander | ||
| === NCommander is now known as Guest25482 | ||
| === JanC is now known as Guest67153 | ||
| === JanC_ is now known as JanC | ||
| vertago1 | I am trying to get a package development environment setup for the avahi package but when I check it out with bzr the debian folder is missing. Is there a step I am missing? | 22:31 |
| nacc | vertago1: is avahi actually maintained in bzr? | 22:31 |
| vertago1 | possibly not | 22:31 |
| vertago1 | It is on launchpad | 22:31 |
| nacc | vertago1: it's not in bzr | 22:32 |
| vertago1 | ok, so I should use debian's tools? | 22:32 |
| nacc | vertago1: i'd recommend using `pull-lp-source` | 22:32 |
| vertago1 | I am getting an error with that command so I think I will just forego using bzr with what I am working on then | 22:35 |
| vertago1 | I was trying to figure out the least-headache-way of creating a patch in an existing source package to fix an upstream bug. | 22:36 |
| nacc | vertago1: my quick and dirty method: | 22:39 |
| nacc | vertago1: pull-lp-source <srcpkg name> | 22:39 |
| nacc | vertago1: cd <srcpkg name-version> | 22:39 |
| nacc | vertago1: git init . [note this can issues if the upstream also uses git and they provide any .git* files in the tarball] | 22:40 |
| nacc | vertago1: git add . | 22:40 |
| nacc | vertago1: git commit -m <msg> | 22:40 |
| nacc | vertago1: do some changes and either commit them as a quilt patch if it's to the source | 22:41 |
| nacc | s/either// | 22:41 |
| sarnold | man I have trouble believing -git- is in the quick-and-dirty variant :) | 22:41 |
| nacc | vertago1: add a changelog entry | 22:41 |
| vertago1 | I know git fairly well so it should work for me. | 22:41 |
| nacc | sarnold: it's mostly so `git diff` tells you what you broke^Wchanged | 22:41 |
| nacc | vertago1: so you're backporting an upstream fix? | 22:42 |
| vertago1 | no I am writing a fix to hopefully push upstream | 22:42 |
| nacc | vertago1: oh, why do you need the ubuntu package at all then? | 22:42 |
| vertago1 | it makes testing it easier | 22:42 |
| nacc | vertago1: for testing? | 22:42 |
| vertago1 | one of the packages is avahi-daemon | 22:42 |
| vertago1 | so if I can install the package I don't have to mess with the daemon config. | 22:43 |
| vertago1 | I just need to add some checks so that avahi-daemon doesn't send invalid utf8 strings over dbus | 22:43 |
| nacc | vertago1: understood | 22:43 |
| vertago1 | *try to send | 22:43 |
| nacc | cpaelzer: i think you need an AA to help usher strongswan through, btw | 23:22 |
| nacc | cpaelzer: it's in the new queue due to new binaries | 23:22 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!