| smoser | slangasek, if you're sitting there twiddling your thumbs, and you have any ideas on https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1611074 i'd like to hear them. | 00:55 |
|---|---|---|
| ubottu | Launchpad bug 1611074 in cloud-init "Reformatting of ephemeral drive fails on resize of Azure VM" [High,Fix committed] | 00:55 |
| slangasek | hard to type and twiddle at the same time | 00:55 |
| smoser | i ususally peck with my nose. | 00:56 |
| smoser | it wastes time that way too | 00:56 |
| smoser | slangasek, one thing that seems wrong... but i'm not sure its entirely related. | 00:57 |
| smoser | http://paste.ubuntu.com/23488127/ | 00:57 |
| smoser | when i run that script well after boot, sometimes i hit line 29.. that is to say systemd magically mounts the partition for me. | 00:57 |
| slangasek | smoser: but in this context you're repartitioning it from a booted state? in which case the x-systemd.requires won't protect you | 00:59 |
| smoser | correct. | 00:59 |
| smoser | but i'd still find it odd and wrong to umount anad then have something magically mount for me. | 00:59 |
| smoser | and i'im not convinced that its not related. | 01:01 |
| smoser | most certainly, systaemd generator writes those files based on the stale fstab | 01:01 |
| slangasek | it doesn't seem incorrect for systemd to automount for you a device that it discovers via udev, post-boot, whose deps are satisfied | 01:01 |
| smoser | it seems to me that that should be a 'once' thing. | 01:01 |
| smoser | no other mount service continually mounts automatically for you. | 01:02 |
| xnox | unless there is .automount unit; or udev got retriggered for the device; "stop" the .mount unit manually? | 01:02 |
| smoser | especially wrong when it could be mounting garbage of a filesystem that just happend to be at the place where you put the new partition. | 01:02 |
| slangasek | xnox: in this context, udev has gotten retriggered for the device yes | 01:02 |
| xnox | check the generator and the .automount / .mount units in /run/systemd ?! | 01:03 |
| slangasek | smoser: so don't label your garbage with the exact same name that you were using to mount it by in /etc/fstab? | 01:03 |
| slangasek | because this is the exact same code used to automount a removable device when you plug it in | 01:03 |
| slangasek | which you might remove, and want to mount again | 01:04 |
| xnox | use $ wipefs -a -> to wipe garbage off the partition? | 01:04 |
| smoser | slangasek, you've not gotten a chance at that point to write a filesystem. | 01:04 |
| smoser | and xnox your case doesn't even help... its really busted. | 01:04 |
| smoser | yes, you can be careful and get aroudn this | 01:04 |
| smoser | but it is nonsense. | 01:04 |
| smoser | ie, if you want to repartition a disk, you have to: | 01:04 |
| slangasek | smoser: yes, because your fstab refers to the partition in a way that triggers the mount before you've created a filesystem | 01:04 |
| smoser | a.) unmount everythin | 01:04 |
| smoser | b.) seek to the new partition table offsets and wipe any filesystem stuff that might possibly be there. | 01:05 |
| slangasek | so if you're expecting to be able to do this online, post-boot... don't refer to the filesystem by a device name that shows up before the filesystem is created? | 01:05 |
| smoser | c.) partition it | 01:05 |
| smoser | d.) mkfs the partition | 01:05 |
| smoser | you have to do 'b' because where you put the new partition might have had a valid filesystem signature. even from an attack of some sort. | 01:06 |
| xnox | wipefs does support offset argument -o | 01:07 |
| smoser | interestingly, udev in all its auto-glory watches rw opens on /dev/devices | 01:07 |
| xnox | smoser, i had hallarious bug reports in d-i w.r.t. serial re-installers in virtual machines, that use host LVM volumes as backing device stores. | 01:07 |
| smoser | and rescans partitiontables for you automatically when wipefs closes | 01:07 |
| smoser | so... lots of fun. | 01:07 |
| smoser | right. this magic is quite nonhelpful when you dont want it. | 01:08 |
| xnox | smoser, because create a fresh volume, may just align with old volume, and give you perfectly valid filesystem signatures, to bust the installations in funny ways. | 01:08 |
| smoser | thats what im' saying | 01:08 |
| smoser | *and* that data could actually be an attack | 01:08 |
| slangasek | if you don't want it, that's called 'noauto' | 01:08 |
| smoser | in your /etc/fstab entry, yes. | 01:09 |
| smoser | which was stale | 01:09 |
| smoser | and is still magically present when you remove it | 01:09 |
| slangasek | how is it stale | 01:09 |
| smoser | because /etc/fstab isn't the thing that is doing these mounts | 01:09 |
| slangasek | ? | 01:09 |
| smoser | its stale because its present from before the stop | 01:09 |
| xnox | systemd-fstab-generator | 01:09 |
| smoser | and then the new disk attached. | 01:09 |
| slangasek | it's stale /with respect to what/? | 01:09 |
| slangasek | your example script doesn't show any editing of /etc/fstab | 01:10 |
| xnox | so unmount; remove ftab; systemctl daemon-reload (which should retrigger generators, and remove stale .mount generated units); do things; write new ftab; mount things ? | 01:10 |
| smoser | sure. but that doesnt matter, slangasek. | 01:10 |
| slangasek | it shows systemd following the instructions it's been given, faster than you're expecting | 01:10 |
| smoser | i can do it, it doesnt stop the .mount service | 01:10 |
| smoser | no one expects to edit /etc/fstab and stop a service to partition a disk. | 01:10 |
| smoser | (i have specifically taken the line out of /etc/fstab) | 01:11 |
| smoser | so yes, best case what you're suggesting is that i have to | 01:11 |
| smoser | a.) edit /etc/fstab | 01:11 |
| smoser | b.) systemctl daemon-reload | 01:11 |
| smoser | c.) partition , mkfs | 01:11 |
| smoser | d.) edit /etc/fstab | 01:11 |
| smoser | e.) mount | 01:11 |
| smoser | and 'b'probably doesnt work during boot | 01:12 |
| smoser | i dont know that, but i suspect as many systemd things do not | 01:12 |
| slangasek | isn't the *actual* problem you're trying to solve that systemd should not automount the disk at boot time, before cloud-init has run? | 01:13 |
| slangasek | if so, let's please solve that problem, and not have a proxy battle about how automounting is designed in systemd | 01:15 |
| slangasek | if not, I don't understand the scope of the bug so please explain it to me | 01:15 |
| smoser | yes thats the problem. but i think it is related to the magic that i'm seeing. | 01:15 |
| smoser | its possible its not. | 01:15 |
| smoser | but essentially, cloud-init is doing the same thing as the script during boot, and then failing to mkfs because something has mounted the device. | 01:16 |
| smoser | i' not certain its related to this, but it seems similar. | 01:16 |
| slangasek | /rules.d/80-iio-sensor-proxy.rules | 01:17 |
| slangasek | haaate | 01:17 |
| slangasek | smoser: in the case where it has failed at boot, what are the contents of /run/systemd/generator/mnt.mount ? | 01:18 |
| smoser | i'll recreate. it'll take me a bit. | 01:19 |
| smoser | anything else you might want from before the failed boot ? | 01:19 |
| slangasek | smoser: I don't know well enough what all I would want; I would really want to debug it interactively | 01:21 |
| smoser | slangasek, i can let you in before and after. | 01:24 |
| smoser | slangasek, my attempts to simplify fail | 01:25 |
| smoser | ie, i've booted system... then just partitioned the existing disk and put ntfs on partition 1 | 01:25 |
| smoser | and then rebooted | 01:25 |
| smoser | which is much the same as stop, new ephemeral diska ttached, start | 01:25 |
| smoser | but i believe the start after resize has slower disks at first | 01:26 |
| smoser | and so we hit it there but not on the "warm" reboot disks | 01:26 |
| smoser | at least i've not seen it my way | 01:26 |
| smoser | slangasek, if you want ssh smoser@40.122.215.16 | 01:38 |
| smoser | that is prior to resize | 01:38 |
| slangasek | smoser: and without an up-to-date /etc/fstab? | 01:38 |
| slangasek | /dev/disk/cloud/azure_resource-part1/mntautodefaults,nofail,comment=cloudconfig02 | 01:38 |
| smoser | no modifications to that. | 01:38 |
| smoser | yeah | 01:38 |
| smoser | i saved a bunch of stuff in first-boot | 01:39 |
| slangasek | so you'll be manually changing that before resizing? | 01:39 |
| smoser | we can reboot ( which will do that) | 01:39 |
| smoser | or we can manually do it | 01:39 |
| smoser | i'm apt to reboot, and collect those logs and state and such | 01:39 |
| smoser | and then resizse | 01:39 |
| smoser | so far, launch, add proposed && install cloud-init , collect some info | 01:40 |
| slangasek | smoser: if you rely on fstab being updated via reboot, then indeed you could be fighting with the systemd fstab generator | 01:41 |
| slangasek | oh | 01:41 |
| slangasek | you mean reboot once, to regenerate fstab; then reboot again for the resize? | 01:41 |
| smoser | right. | 01:41 |
| slangasek | yeah, +1 | 01:42 |
| smoser | ok. rebooted, ran 'save-old-data second-boot' | 01:43 |
| smoser | and | 01:43 |
| smoser | /dev/disk/cloud/azure_resource-part1/mntautodefaults,nofail,x-systemd.requires=cloud-init.service,comment=cloudconfig02 | 01:43 |
| smoser | and now api resize | 01:44 |
| slangasek | smoser: right - fstab looks good, /run/systemd/generator/mnt.mount still wrong but that's as expected | 01:46 |
| smoser | wrong ? | 01:46 |
| slangasek | smoser: /run/systemd/generator/mnt.mount was generated by systemd-fstab-generator before cloud-init updated /etc/fstab, therefore it has the wrong dependencies | 01:47 |
| smoser | right. | 01:47 |
| smoser | slangasek, ok. its back up, and it reproduced | 01:51 |
| smoser | and, slangasek, thank you for your help. | 01:51 |
| slangasek | smoser: ok. 'systemctl status mnt.mount' told me 'Warning: mnt.mount changed on disk. Run 'systemctl daemon-reload' to reload unit' | 01:52 |
| slangasek | smoser: but 'systemctl show mnt.mount' does show the correct dependencies for the running unit | 01:53 |
| smoser | right. | 01:54 |
| slangasek | smoser: 'systemctl list-dependencies' makes me somewhat suspicious, mnt.mount isn't shown as depending on cloud-init.service | 01:55 |
| smoser | and nothing actually changed in the /etc/fstab, its just that systemd recognized probably a timestamp cahnge in /etc/fstab and says its out of date. | 01:55 |
| smoser | slangasek, it does show it | 01:55 |
| smoser | at least | 01:56 |
| smoser | systemctl list-dependencies mnt.mount | 01:56 |
| smoser | does | 01:56 |
| slangasek | yes | 01:56 |
| smoser | thats interesting | 01:58 |
| slangasek | smoser: and cloud-init.service is where the resize happens. And cloud-init.service is Type=oneshot. | 01:58 |
| smoser | right. | 01:58 |
| slangasek | so After=cloud-init.service is basically "start this as soon as you've exec()ed the other one" | 01:58 |
| slangasek | systemd.service(5), Type= | 01:58 |
| slangasek | e | 01:59 |
| slangasek | er | 01:59 |
| slangasek | no, sorry | 01:59 |
| slangasek | that's completely wrong, I should read more carefully teh description of oneshot ;) | 01:59 |
| smoser | hmm. | 02:00 |
| smoser | RemainAfterExit is odd though | 02:00 |
| smoser | wrt oneshot and requires | 02:00 |
| smoser | "RemainAfterExit= is particularly useful for this type of service" | 02:01 |
| smoser | s/useful/confusing/ | 02:01 |
| smoser | what would that even mean.. if the thing remains, you could essentially never be After | 02:01 |
| slangasek | smoser: it means that it's listed as 'active', but no changes to the behavior of After | 02:01 |
| smoser | that makes more sense. | 02:02 |
| slangasek | smoser: '/usr/bin/cloud-init init' wouldn't background for any reason, would it? | 02:02 |
| smoser | well... it could start some processes | 02:02 |
| smoser | that backgrounded | 02:02 |
| smoser | but it wont. | 02:02 |
| slangasek | so the top-level cloud-init process is still running while the partitioning/mkfs is happening | 02:03 |
| smoser | yeah | 02:03 |
| smoser | but it might start a daemon of some sort | 02:03 |
| slangasek | smoser: why does 'systemctl status cloud-init' show the job's last status change at 01:49:06, but the last journal output entries at 01:49:07? | 02:05 |
| smoser | try monotnoic | 02:05 |
| smoser | the clock bounces all over the place on those system.s | 02:05 |
| slangasek | heh | 02:05 |
| smoser | but i dont know if you can get monotonic on status | 02:06 |
| smoser | can you ? | 02:06 |
| slangasek | doesn't appear so | 02:06 |
| slangasek | but if I compare stamps from mnt.mount and cloud-init.service, mnt.mount is definitely after | 02:06 |
| slangasek | smoser: and the timestamp shown in /var/log/cloud-init.log for mkfs.ext4 is 2016-11-17 01:49:09, which is definitely later than what was reported in the journal for either job... so seems less likely to be due to a clock bounce | 02:07 |
| smoser | journalctl -o short-monotonic --no-pager --full | 02:08 |
| smoser | and you can see | 02:08 |
| smoser | [ 256.905798] reprovm systemd[1]: Time has been changed | 02:08 |
| smoser | so one really wierd thing that happens on azure... | 02:09 |
| smoser | we bounce eth0 (ifdown ; ifup) | 02:09 |
| smoser | because thats how you publish your hostname (if the user modified it) to the platform | 02:09 |
| smoser | i dont think its related... but it means dhcp hooks and possibly time jumps and lots of general wierdness. | 02:10 |
| smoser | so i'm just mentioning | 02:10 |
| slangasek | smoser: well, hard to be sure without monotonic log output for cloud-init.log itself then | 02:10 |
| smoser | well, you can get it.. | 02:11 |
| smoser | from journalctl | 02:11 |
| smoser | as cloud-init writes to journal its stdout | 02:11 |
| * slangasek looks | 02:11 | |
| smoser | so the time obviously differs by when it got seen versus when it got written | 02:11 |
| smoser | but, kind of no way to avoid that | 02:11 |
| slangasek | smoser: well, journalctl -u cloud-init.service is only showing me a handful of lines, not all the output in /var/log/cloud-init.log | 02:12 |
| smoser | hm.. | 02:12 |
| smoser | just journalctl -o short-monotnoic | 02:13 |
| smoser | i see | 02:13 |
| smoser | [ 23.003468] reprovm systemd[1]: Mounted /mnt. | 02:13 |
| slangasek | smoser: and the output shown in journalctl -u cloud-init.service also does not appear in /var/log/cloud-init.log | 02:13 |
| smoser | right. | 02:14 |
| smoser | because it is set to write debug to log | 02:14 |
| smoser | but less verbose to stdout | 02:14 |
| smoser | we can cahnge that and try again | 02:14 |
| slangasek | smoser: actually, this log did finally show me what I needed | 02:14 |
| slangasek | with -o short-monotonic | 02:14 |
| slangasek | [ 22.998682] reprovm systemd[1]: Started Initial cloud-init job (metadata service crawler). | 02:14 |
| slangasek | [ 24.812954] reprovm cloud-init[1077]: Failed to exec of '['/sbin/mkfs.ext4', '/dev/sdb1']': | 02:15 |
| slangasek | the job was marked 'started' 2 seconds before the mkfs was run | 02:15 |
| slangasek | so cloud-init does somehow seem to be backgrounding this | 02:15 |
| slangasek | rather, this doesn't look at all like it's running mkfs from the cloud-init.service | 02:16 |
| slangasek | but from cloud-config.service | 02:16 |
| slangasek | so... wrong dep? | 02:16 |
| smoser | well, cloud-init.service is supposed to be running them. | 02:18 |
| smoser | is there a way to tell journalctl not to rotate | 02:18 |
| smoser | whenver i give it fire hose, i find later that it can't show me stuff saying its rotated | 02:19 |
| smoser | you're right, it certainly does seem to be running fromcloud-config, but it should not be. | 02:20 |
| slangasek | it's configurable, i don't recall how. you can also touch the file to get an on-disk journal, which we don't do by default, then you don't have to rotate to avoid running out of memory | 02:20 |
| slangasek | ok | 02:21 |
| smoser | oh. | 02:21 |
| slangasek | but I'm guessing you can take it from there to figure out why it's being run from the wrong part of cloud-init :) | 02:21 |
| smoser | yeah. thank you. | 02:21 |
| cpaelzer | good morning | 06:42 |
| pitti | Good morning | 07:26 |
| cpaelzer | pitti: h | 07:36 |
| cpaelzer | i | 07:36 |
| cpaelzer | pitti: FYI on the gnutls thing I mentioned hitting libvirt yesterday | 07:36 |
| cpaelzer | pitti: it seems we need to revert that change in gnutls instead of adapting libvirt | 07:36 |
| cpaelzer | pitti: I added a gnutls task to the bug I was working on and currently prepping an upload for a ppa to try it out | 07:37 |
| cpaelzer | pitti: that was bug 1641615 | 07:37 |
| ubottu | bug 1641615 in libvirt (Ubuntu) "FTBFS of libvirt 2.1 in zesty" [High,Confirmed] https://launchpad.net/bugs/1641615 | 07:37 |
| pitti | cpaelzer: that's only gnutls30, right? I thought 28 was still the default (not sure if there's a transition going on) | 07:52 |
| cpaelzer | pitti: I must admit the gnutls package versioning is hard at first so IÄm not sure I get it completely yet | 07:54 |
| cpaelzer | pitti: it is libgnutls30 with headers in libgnutls28-dev out of source gnutls28 | 07:54 |
| cpaelzer | pitti: did that make sens to you? | 07:54 |
| pitti | not off-hand -- I haven't looked into this at all | 07:54 |
| cpaelzer | pitti: the changelog says you did the merge which is why I was highlighting you :-) | 07:55 |
| pitti | oh right, this isn't a transition; it's just weird naming | 07:56 |
| tuxinator | anybody that may help me with my ubumirror problem? hard to offer a mirror server to the community if the actual mirror scripts don't work as expected :D | 08:16 |
| cpaelzer | hi tuxinator I've seen your request like three times but have no experience around that | 08:19 |
| cpaelzer | tuxinator: but I really appreciate the support willing to provide a mirror - maybe the right people are not here on the itme you are asking ... ? | 08:19 |
| cpaelzer | tuxinator: have you tried asking at https://lists.ubuntu.com/mailman/listinfo/ubuntu-mirrors ? | 08:20 |
| cpaelzer | tuxinator: there also seems to be a #ubuntu-mirrors IRC channel on freenode - thou I'm not sure on that one | 08:21 |
| cpaelzer | surely there the request won't be drowned in so many other messages | 08:21 |
| cpaelzer | tuxinator: there also is mirrors@ubuntu.com - not sure which mail is for the offical mirrors and which for mirror clones of any sort | 08:24 |
| caribou | pitti: has systemd unit masking (i.e. linking the unit to /dev/null) a recent introduction in systemd ? | 09:51 |
| pitti | caribou: no, that has existed basically forever | 09:53 |
| pitti | (for sure "forever" in ubuntu) | 09:54 |
| caribou | pitti: ok thanks just wanted to be sure | 09:54 |
| infinity | TheMuso: I don't understand why you dropped pulseaudio-equalizer. Yes, its deps are in universe, but it's perfectly fine for a source in main to produce a binary in universe. | 10:13 |
| infinity | TheMuso: Seems like an entirely pointless delta from Debian. | 10:14 |
| cjwatson | LocutusOfBorg: please file a bug against the git-build-recipe project about that | 11:42 |
| cjwatson | tuxinator: I asked you a question to try to narrow down your problem but you didn't reply | 11:42 |
| LocutusOfBorg | cjwatson, probably I was disconnected | 11:44 |
| LocutusOfBorg | will look to logs | 11:44 |
| cpaelzer | pitti: on bug 1641615 I created a gnutls fix - since you made the merge could you take a look at reviewing and sponsoring that? | 11:44 |
| ubottu | bug 1641615 in libvirt (Ubuntu) "gnutls api breakage in 3.5.6" [High,Confirmed] https://launchpad.net/bugs/1641615 | 11:44 |
| LocutusOfBorg | oh was directed to tuxinator the second sentence | 11:45 |
| pitti | cpaelzer: ack, queueing | 11:46 |
| === _salem is now known as salem_ | ||
| cpaelzer | pitti: thanks and if possible keep me up to date so I can follow with the matching libvirt un-fix which is needed now (or push that along if you e.g. push that via bileto - its debdiff is on the bug as well) | 11:50 |
| tuxinator | cpaelzer: thanks | 11:58 |
| tuxinator | cpaelzer: actually there is no hurry :D | 11:58 |
| === hikiko is now known as hikiko|ln | ||
| === JanC_ is now known as JanC | ||
| === hikiko|ln is now known as hikiko | ||
| mdeslaur | pitti: hi! are we going to get postgresql-9.6 in zesty, or should I revert the pgmemcache package back to supporting 9.5? | 13:50 |
| mdeslaur | pitti: I'll just revert it for now so I can get my other stuff migrated | 14:01 |
| pitti | mdeslaur: I haven't thought much about this; TBH, I think we should avoid major version bumps in the non-LTS releases, as that simplifies maintenance | 14:07 |
| pitti | and noone in their right mind would use a 9-month release for a server/production setup anyway | 14:07 |
| pitti | mdeslaur: so I was going to leave it at 9.5 until people complain loudly :) | 14:07 |
| mdeslaur | pitti: sounds good, thanks! | 14:07 |
| bswartz | if I wanted to fix a bug in an ubuntu package file (the .dsc file) where would I go to submit that change? | 14:22 |
| pitti | cpaelzer: this is all backported from trunk, right? | 14:22 |
| cpaelzer | pitti: yes | 14:23 |
| cpaelzer | pitti: the git ids are from gnutls | 14:23 |
| pitti | cpaelzer: note, as these symbols are not really from upstream 3.5.6, .symbols must be stricter | 14:23 |
| pitti | + gnutls_ocsp_resp_get_responder2@GNUTLS_3_4 3.5.6-4ubuntu2~ | 14:23 |
| pitti | cpaelzer: ^ like this | 14:23 |
| cpaelzer | pitti: true, but there is no 3.5.7 nor a 3.5 release | 14:23 |
| pitti | cpaelzer: (fixing here, just OOI) | 14:23 |
| pitti | s/OOI/FYI/ | 14:23 |
| pitti | TLAs are hard! | 14:24 |
| pitti | cpaelzer: ack, thanks; uploaded | 14:25 |
| pitti | cpaelzer: either reupload libvirt after it built/published everywhere, or bump the build dep to that version | 14:25 |
| === cpaelzer_ is now known as cpaelzer | ||
| Odd_Bloke | rbasak: If I want to request a package be added to a packageset, I should send an email to devel-permissions@lists.u.c and then add it to the agenda for an upcoming DMB meeting, right? | 14:38 |
| rbasak | Odd_Bloke: correct. It shouldn't be a requirement to add it to the agenda, but no harm if you do - if anything it gives us a place to assign it to someone to deal with if it doesn't get looked at before a meeting. | 14:40 |
| === foxtrot is now known as tex | ||
| === tex is now known as texas | ||
| kdub | anyone know a trick to get a foreign build-dep to work within a cross-compile chroot? (eg, apt-get build-dep <pkg>:arm64) | 15:28 |
| kdub | it always seems to get tangled up trying to install and run foreign packages (eg, python) | 15:29 |
| === texas is now known as foxtrot | ||
| === JanC is now known as Guest90855 | ||
| === JanC_ is now known as JanC | ||
| === alan_g is now known as alan_g|tst | ||
| === alan_g|tst is now known as alan_g | ||
| nacc | doko: i think i figured out the freeradius issue; will send to debian and z-p | 16:54 |
| nacc | so freeradius has a /var/log/freeradius/wtmp and /var/log/freeradius/utmp file. One of it's autopkgtests just runs `radlast` which looks at that wtmp file. However, by default, that file doesn't see to exist. Normally, what would be responsible for creating that file? A debian postinst step? The freeradius daemon itself? | 18:05 |
| nacc | *see -> seem | 18:06 |
| nacc | ah i think i see what is supposed to happen -- the 'unix' driver creates the wtmp file on the first accounting with freeradius | 18:46 |
| nacc | not sure how that worked in 16.04 w/ the same tests, will go investigate | 18:46 |
| nacc | ah ha, in 16.04, postinst created the files | 18:56 |
| bswartz | if I wanted to fix a bug in an ubuntu package file (the .dsc file) where would I go to submit that change? | 19:11 |
| nacc | bswartz: which package? | 19:15 |
| nacc | bswartz: it sort of depends, but the normal way for a user without upload rights to submit, is to open a bug, and put a debdiff in the bug | 19:15 |
| bswartz | nacc: xfce4-clipman-plugin | 19:16 |
| bswartz | nacc: I did open a bug but I'm not 100% it was in the right place | 19:17 |
| nacc | bswartz: bug #? | 19:17 |
| bswartz | https://bugs.launchpad.net/ubuntu/+source/xfce4-clipman-plugin/+bug/1641802 | 19:17 |
| ubottu | Launchpad bug 1641802 in xfce4-clipman-plugin (Ubuntu) "xfce4-clipman-plugin should depend on libqrencode-dev" [Undecided,New] | 19:17 |
| nacc | bswartz: have you worked on debian or ubuntu packages before? (just trying to konw where to start to help you out) | 19:26 |
| bswartz | nacc: I've hacked on all kinds of things -- modifying .dsc files seems to be particularly easy | 19:27 |
| bswartz | I'm not sure what the offcial workflow is for testing a change though | 19:27 |
| nacc | bswartz: right, you generally wouldn't chagne the .dsc file directly | 19:27 |
| bswartz | In my case I simply couldn't stand my eye's bleeding at how bad the xfce4-clipman plugin in Ubuntu is compared to Fedora, so I decided to fix it for myself | 19:27 |
| nacc | bswartz: so here's my suggestion just to get you going: | 19:28 |
| nacc | in an appropriate directory: pull-lp-soure -cd xfce4-clipman-plugin | 19:28 |
| nacc | bah | 19:28 |
| nacc | -d (not -cd) | 19:28 |
| nacc | and pull-lp-source | 19:28 |
| nacc | and actually, in your case, just pull-lp-source (no -d flag either) | 19:29 |
| nacc | so let me start over! :) | 19:29 |
| nacc | pull-lp-source xfce4-clipman-plugin | 19:29 |
| nacc | cd xfce4-clipman-plugin-<tab> | 19:29 |
| nacc | make some changes | 19:29 |
| nacc | dch -i | 19:29 |
| nacc | describe your changes and put the right version in | 19:29 |
| nacc | (as well as targeting the correct release) | 19:30 |
| nacc | dpkg-buildpackage -S -nc -d -uc -us | 19:30 |
| nacc | cd .. | 19:30 |
| nacc | debdiff xfce4-clipman-plugin_<old version>.dsc xfce4-clipman-plugin_<new version>.dsc | less | 19:31 |
| nacc | (review the diff) | 19:31 |
| nacc | if it looks good, you can do: | 19:31 |
| bswartz | pull-lp-source: Warning: Distribution data outdated. Please check for an update for distro-info-data. See /usr/share/doc/distro-info-data/README.Debian for details. Or specify a distribution. | 19:31 |
| bswartz | I'm on xenial | 19:31 |
| nacc | debdiff xfce4-clipman-plugin_<old version>.dsc xfce4-clipman-plugin_<new version>.dsc | lp-attach <bug #> | 19:32 |
| nacc | bswartz: hrm, are you up-to-date? | 19:32 |
| bswartz | I thought I was | 19:32 |
| nacc | bswartz: i thought they had rolled out hte zesty data to the older distributions | 19:32 |
| bswartz | turns out some things did need updating, I'm dist-upgrading now | 19:35 |
| nacc | bswartz: ok, that will probably just make xenial aware that zesty exists (so it can recognize the name, etc) | 19:35 |
| nacc | doko: jgrimm: freeradius autopkgtests pass now, uploaded and sent the fix to debian | 19:36 |
| jgrimm | thanks nacc | 19:40 |
| bswartz | nacc: now I am, and it fixed that problem | 19:41 |
| nacc | bswartz: cool | 19:41 |
| bswartz | nacc: where do I express the build dependencies other than in the .dsc file? | 19:48 |
| nacc | bswartz: debian/control in the source pacakge | 19:49 |
| bswartz | aha! | 19:49 |
| nacc | bswartz: sorry :) | 19:49 |
| nacc | bswartz: right so you'd edit that file, updat the changelog and then rebuild the source pacakge (which will generate a new .dsc in the parent directory) | 19:50 |
| Unit193 | -clipman-plugin is currently in sync with Debian, it'd be faaaaar better to fix it there. | 19:52 |
| nacc | bswartz: and to be clear, note that you first need to fix anything in zesty and then follow https://wiki.ubuntu.com/StableReleaseUpdates for getting it into older releases, if applicable | 19:52 |
| nacc | Unit193: excellent point, i figured that might be the response in the bug | 19:53 |
| bswartz | nacc: why did lp-attach launch lynx? | 19:53 |
| bswartz | >_< | 19:53 |
| nacc | bswartz: hrm, not sure? maybe it tried to open the bug? if you piped to it, it doesn't do that, at least last i used it | 19:53 |
| nacc | bswartz: you can also manually take the debdiff and attach it to the bug | 19:54 |
| bswartz | it's trying to do an openid transaction | 19:54 |
| nacc | bswartz: oh because you need to be auth'd to use it | 19:54 |
| bswartz | oh well I can sort this out with a real web browser later | 19:54 |
| nacc | bswartz: sorry, forgot that bit (i'm always auth'd at home) | 19:54 |
| bswartz | thanks or you help | 19:54 |
| bswartz | Unit193: what is the process for debian? do they use launchpad too? | 19:56 |
| Unit193 | Generally file a bug and attach a debdiff. | 19:56 |
| bswartz | Unit193: file a bug in launchpad? what project? | 19:56 |
| nacc | bswartz: you can use `reportbug -B debian` | 19:57 |
| nacc | bswartz: no, debian uses bugs.debian.org | 19:57 |
| bswartz | k | 19:58 |
| === alexisb is now known as alexisb-afk | ||
| hjd | I'm having a strange issue here. My zesty vm seems to be unable to ping or browser .org domains (for instance http://debian.org). Anyone know if this is a known issue or what the cause might be? My host (16.04) has no problems. | 20:42 |
| === alexisb-afk is now known as alexisb | ||
| bswartz | hjd: why do you mention .org domains? do .com domains work fine? | 20:49 |
| hjd | Yes, various .com domains, .no domains and launchpad.net all work. I first thought it was something with debian.org, but I tried some other random .org domains and they all keep failing for some reason | 20:51 |
| bswartz | hjd: I'd recommend testing whether DNS is resolving okay and if not, use a different resolver | 21:20 |
| bswartz | hjd: if DNS is resolving for those org domains then you have a routing or firewall problem | 21:21 |
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| sladen | hjd: type 'host foo.org' on the commandline and see if that resolves | 21:34 |
| hjd | sladen: http://paste.ubuntu.com/23492450/ | 21:39 |
| hjd | I can ping the ip adresse just fine, but if I try to ping wikipedia.org I only get "Name or service not known" | 21:40 |
| sladen | hjd: is there a difference depending on if you 'ping 2620:0:862:ed1a::1' or if you 'ping 91.198.174.192' ? | 21:42 |
| bswartz | sladen: you mean ping6 | 21:42 |
| sladen | bswartz: yes, the aim is to see whether it might be IPv4 vs. IPv6. The particular choice of tools is optional :) | 21:44 |
| hjd | IPv4 works, IPv6 Network is unreachable | 21:44 |
| bswartz | hjd: if it turns out your problems are related to IPv6 being prefered over IPv4 then you can easily change the preference with this one-liner: | 21:45 |
| bswartz | echo 'precedence ::ffff:0:0/96 100' | sudo tee -a /etc/gai.conf | 21:45 |
| hjd | bswartz: Hm... didn't seem to make a difference. | 21:56 |
| hjd | Anyway, it's getting late, but thanks for the help all :) | 21:57 |
| === salem_ is now known as _salem | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!