[03:33] <infinity> pitti: Hrm.  It seems like a misfeature that pkgstripfiles removes files from -doc packages.
[03:33] <infinity> pitti: (In the case I'm looking at, it strips all the upstream changelogs out of glibc-doc)
[03:35] <infinity> pitti: Opinions?  I'm thinking of just making clean_upstream_changelogs() return if the package is a -doc.
[03:56] <BenC> infinity: well, I am using -proposed…are the buildd's not?
[03:58] <infinity> BenC: They are, yes.  You can see in the build logs exactly what it's doing.
[03:58] <infinity> BenC: And replicating it should be easy.
[03:58] <BenC> infinity: I ran the exact same apt-get command as in the chroot, and I didn't see the dep problems
[03:58] <infinity> BenC: Anyhow, haskell in proposed is deep in painful transition land, I wouldn't hold out much hope for any of it moving soon (given that many packages still need upstream fixes)
[03:59] <infinity> BenC: Then you didn't have the same sources.list and an up-to-date apt-cache.  I can reproduce it trivially here.
[03:59] <BenC> infinity: I ran it from a pristine chroot with updated raring packages, using an updated cache
[04:00] <BenC> *up-to-date
[04:05] <infinity> BenC: Just reproduced here again, to make sure I wasn't crazy.
[04:05] <infinity> http://paste.ubuntu.com/1603451/
[04:06] <infinity> Anyhow, like I said, we need to sort out that transition anyway, and this will all fall out of that.
[04:11] <BenC> Works for me…
[04:14] <infinity> Not sure what to say. :P
[04:14] <infinity> Your computer is special?
[04:16] <BenC> I meant, leaving it alone and letting it all sort itself out "works for me" :)
[04:16] <infinity> Well, that's kinda the only option right now anyway.
[04:17] <infinity> Either that, or I remove all of *ghc* *haskell* from proposed.  But I see no reason to not just do the transition, it'll just take some effort (most of which needs to happen in Debian right now).
[04:24] <quadrispro> hi everybody
[04:28] <quadrispro> slangasek, bug #1110326 is done now
[04:33] <quadrispro> cheerio
[07:15] <lifeless> infinity: you've climbed around eglibc before, right? wth is close defined ?
[07:23] <infinity> lifeless: man 2 close?
[07:23] <lifeless> infinity: the source, not the header :)
[07:23] <lifeless> infinity: I've found a stub version, and a hurd version
[07:24] <lifeless> infinity: I seem incapable of finding the common case version :(
[07:24] <sarnold> that's my usual experiences with the eglibc sources :/
[07:24] <lifeless> sarnold: I'm glad I'm not alone.
[07:26] <mjt> it is a syscall lifeless
[07:26] <mjt> there's no source for it in glibc
[07:26] <infinity> ^
[07:26] <mjt> they do some syscall magic in one go for all syscalls in a generated file
[07:26] <lifeless> oh; I had assumed it would still need a thunk
[07:27] <mjt> yeah it does
[07:27] <mjt> but these are auto-generated
[07:27] <mjt> i don't know the process. this reminds me of a file named SYSCALLS somewhere in the sources
[07:28] <lifeless> ./sysdeps/generic/sys/syscall.h perhaps
[07:29] <lifeless> mjt: thank you, tells me what I needed anyhow ;)
[07:29] <infinity> lifeless: Well, more likely to be in linux sysdeps (or arch-specific), but...
[07:30] <infinity> close           -       close           Ci:i    __libc_close    __close close
[07:31] <infinity> Actually, sysdeps/unix/syscalls.list for the simple ones like close()
[07:31] <lifeless> infinity: thanks!
[07:31]  * lifeless is now grabbing linux source...
[07:31] <sarnold> aha, thanks :)
[07:31] <lifeless> I'm digging into why close(1) blocks when doing dd to a block device.
[07:32] <infinity> lifeless: Standard answer.
[07:34] <lifeless> infinity: whats that ?
[07:35] <infinity> lifeless: "Because it hates you" was the implied answer (other answers are even less CoC friendly). :P
[07:35] <lifeless> infinity: ah! naturally.
[07:35] <infinity> lifeless: But in all seriousness, happy hunting.  That's getting too close to the vfs layer for my liking.  There's a reason I sit firmly on this side of syscalls. :)
[07:36] <lifeless> infinity: hah :). So, you'll love it when I say 'and then I need to establish behaviour with iscsi in the mix
[07:37] <infinity> lifeless: I suspect you'll find that, short of fundamental constraints imposed by VFS features and/or bugs, behaviour like what you're looking at may be entirely filesystem-specific.
[07:37] <infinity> lifeless: So you may be better off starting with iscsi and working backward.
[07:38] <infinity> lifeless: But ymmv, maybe blocking close is a fundamental vfs assumption.
[07:38] <lifeless> infinity: well, there is no fs in play
[07:38] <infinity> Oh, right, block device.
[07:38] <lifeless> infinity: I need to understand both local behaviour, and the behaviour with tgtd etc
[07:38] <infinity> Well, one layer lower, then.  Fun.
[07:39] <lifeless> so that I can decide how to ensure The Right Thing happens.
[07:39] <infinity> Sounds like a fantastic learning experience for someone who's not me.  Enjoy. :P
[07:39] <lifeless> infinity: it is actually.
[07:39] <mjt> if you want to know why dd blocks this way, do a kernel stack dump first
[07:39] <mjt> if strace tells you it is in close, that'll be in kernel not in glibc
[07:40] <infinity> (My usual response to kernel questions is "whine at a kernel engineer")
[07:40] <lifeless> mjt: can you do that without rebooting ?
[07:41] <mjt> even for a non-kernel-engineer it might be sometimes enlightening, since the stack sometimes show functions which suggest something.  Somethingh like, "wait_on_alloc_pages"
[07:41] <lifeless> mjt: sorry, s/rebootiong/rebuilding/
[07:41] <mjt> lifeless: echo t > /proc/sysrq_trigger  and see your dmesg (kern.log) -- search the hung dd pid in there
[07:42] <mjt> (it will generate a ton of info, trace of all running tasks!)
[07:42] <lifeless> thank
[07:43] <lifeless> interestingly, while I had a blkid task caught by 'hung for > 120s' that didn't seem to catch the dd; perhaps 1G isn't enough to block that long.
[07:43] <mjt> and if you don't understand what's in there, -- this is the basic info any kernel engineer will ask you about, so if you include that stack trace right away it'll save you a roundtrip
[07:43] <mjt> wait.
[07:44] <mjt> you dd sleeping on close -- close of the file you just wrote?
[07:44] <mjt> huge file?
[07:44] <lifeless> mjt: block device
[07:44] <mjt> the same thing
[07:44] <mjt> is it the thing to which you just wrote a ton of gigs of data?
[07:44] <lifeless> specifically, dd of=/dev/sdb1 ...
[07:44] <lifeless> and yes.
[07:45] <mjt> so it is kinda expected it blocks
[07:45] <lifeless> close is blocking until nr_writeback hits 0
[07:45] <mjt> yeah
[07:45] <lifeless> mjt: why? No fsync/fdatasync/sync calls.
[07:46] <mjt> well. this is grey area indeed. but it is the only way to know if the writes succeeds or not.
[07:46] <mjt> much better way to write to block devices is to use of=direct
[07:46] <mjt> er
[07:46] <mjt> oflag=direct
[07:46] <mjt> and a reasonable blocksize (say, bs=1M)
[07:47] <mjt> this way write will be smooth, it wont affect the rest of the system, it wont trash your block cache
[07:47] <mjt> and it will be significantly faster too
[07:48] <lifeless> mjt: well, yes, and on the initiating machine I will be doing that.
[07:48] <lifeless> mjt: but I'm mainly trying to establish all the parameters righ tnow
[07:49] <lifeless> mjt: the bigger picture goal is to ship a GB or so from machine A to a block device on machine B, as fast as the network will handle it, without waiting for it to hit disk - and then for machine B to validate the data itself one way or another, flush to disk and reboot.
[07:50] <StevenK> lifeless: nc ?
[07:50] <lifeless> mjt: currently using iscsi for that, but I'm suspecting a userspace process on the target is better suited
[07:50] <lifeless> as it can orchestrate things more directly
[07:50] <lifeless> StevenK: indeed
[07:50] <lifeless> StevenK: I inherited the current code.
[07:51] <lifeless> mjt: would nonblocking cause close to not block (but not arbitrarily cancel any of the IO ?)
[07:51] <infinity> StevenK: Heh.  It never ceases to amaze me the number of useful things one can abuse a concept as simple as nc for.
[07:51] <StevenK> I would have thought ISCSI would be a little heavy handed, TBH.
[07:51] <mjt> lifeless: just try it
[07:51] <lifeless> StevenK: you can also use rsync with the block device patch, but it doesn't scale to Big Disks, which some folk mighy use.
[07:51] <StevenK> infinity: Haha. nc is wonderful, I find myself reaching for it more
[07:52] <mjt> lifeless: but still, direct i/o is way to go there, since it will be faster than using buffer cache
[07:52] <lifeless> mjt: heh - so I can; the main concern is knowing what the guarantees are, not the 'what happens when I try'
[07:52] <StevenK> lifeless: nc and tar? Nice, simple and fast?
[07:52] <lifeless> mjt: our network is faster than the target hard disk, buffer cache is a big win :)
[07:52] <infinity> StevenK: *nod*... It's very classic UNIX in it's simple tool that can be slotted into thousands of usecases.
[07:52] <lifeless> mjt: [for the whole story]
[07:53] <mjt> lifeless: and your app on node B will validate what? content of buffer cache?
[07:53] <lifeless> mjt: so, ideally O_DIRECT on the source machine avoids buffering there, but we want buffer cache on the target.
[07:53] <lifeless> mjt: do a sync, then O_DIRECT read of the partition I think.
[07:54] <mjt> and how is the size of data compared with the amount of RAM on B?
[07:54] <lifeless> mjt: tiny fraction
[07:54] <mjt> will whole thing fit in ram?
[07:54] <lifeless> mjt: typical cases are 500M->1G data, RAM is - well, lots more than that, I can't say more :)
[07:54] <mjt> speaking of guarantees, -- as i said it is a grey area already even without O_NONBLOCK
[07:55] <mjt> and may depend on the underlying stack, i dunno
[07:56] <lifeless> yeah, thus my climbing through source rather than simply asking the lazyweb : though I sure do appreciate the info you have shared.
[07:56] <mjt> (i didn't know close(block device) waits till writes are complete, until now)
[07:56] <mjt> and this is definitely in kernel. not glibc :)
[08:00] <mjt> lifeless: btw, how your source disk speed compared with the target disk speed? :)
[08:00] <lifeless> mjt: don't care, source will be cached.
[08:00] <mjt> with O_DIRECT?
[08:01] <lifeless> mjt: O_DIRECT on writes, not reads; oflag=direct
[08:01] <mjt> ok. count me officially confused. ;)
[08:02] <mjt> so it looks like the only thing you need is to stop close() from blocking. that's kernel question.
[08:02] <lifeless> mjt: indeed
[08:03] <lifeless> mjt: well, I need to get the behaviour when iscsi is in the picture pinned down.
[08:04] <lifeless> mjt: but thats just a matter of time :)
[08:57] <lifeless> mjt: infinity: for your interest;
[08:57] <lifeless> with tgtd serving out a block device, and dd to that via a regular iscsiadm connection
[08:58] <lifeless> oflag=direct has minimal impact on performance, either way the close() at the end waits for all data to have traversed the network. but it does not wait for it to hit disk at the far end - it buffers quite happily.
[08:58] <lifeless> oflag=direct does of course avoid wasting the senders buffer cache
[08:59] <lifeless> this is without the sync or direct flags set in tgtd
[08:59] <lifeless> could do that, but it would actually be counter what we want... which is to clear the network as quickly as possible - we wouldn't be able to tell when dd finished vs when teh disk finished.
[09:00] <lifeless> so I'll need to do something fugly on the far end to tell (or switch to nc :))
[09:00] <lifeless> StevenK: ^
[11:07] <Quintasan> hello
[15:57] <tomreyn> hi
[15:58] <tomreyn> is it possible, as an upstream, to get access to apport submitted error reports for packages in ubuntu? if so, what's the process?
[16:43] <Elbrus> tomreyn: in principle, anybody can subscribe to a package
[16:43] <Elbrus> in launchpad, go to the bugs in the package
[16:44] <Elbrus> click link "subscribe to bug mail"
[17:06] <tomreyn> Elbrus: i don't think bug reports still get created for apport submissions
[17:07] <tomreyn> Elbrus: i'm referring to crash logs
[17:07] <Elbrus> tomreyn: sorry, didn't know that
[17:07] <Elbrus> I thought they did
[17:08] <tomreyn> it feels like canonical wants more information to be internal only now than in the past.
[17:09] <tomreyn> of course this can be just an architectural change and this information which used to be publically accessible just has not yet been made accessible again (about a year after the change took place), or i just lack the knowledge on how to access it.
[17:15] <penguin42> https://errors.ubuntu.com/  has teh stats but none of the detail
[17:17] <stgraber> tomreyn: the new workflow is essentially: crash => upload to errors.ubuntu.com => when we notice it happens often => file a public bug report and link it
[17:17] <stgraber> tomreyn: so fixes will still be linked to bug reports, but we won't have bug reports with thousands of duplicates anymore
[17:18] <penguin42> stgraber: I think tomreyn's original question was what happens to an upstream if they're interested in watching for bugs on their package
[17:18] <stgraber> tomreyn: for privacy reason the details of the crashes on errors.ubuntu.com are currently restricted to Canonical employees but I believe this is being worked on so that other people may access those provided they sign an NDA
[17:20] <stgraber> penguin42: upstreams should monitor Launchpad. Any frequent crasher will be forwarded there once we know for sure it's a bug.
[17:21] <penguin42> stgraber: Yeh that's a bit restricting for them, but I can understand the privacy stuff to want to filter peoples coredump stuff - but backtraces without the data should be safe
[17:23] <tomreyn> inded, we would never sign an SDA. we would, however, be quite happy to have access to any data which can be made available without endandering the submitters' privacy.
[17:23] <tomreyn> and i believe this is very much automatable.
[17:24] <stgraber> penguin42: they are most of the time, the problem is that they aren't 100% of the time. We can't know that every single piece of software in the archive won't show user credentials in an exception for example
[17:24] <tomreyn> sure, it does take a bit of time, but not too much
[17:24] <stgraber> tomreyn: then what you want to look at is Launchpad, because that's where we forward those crashes after they've been looked at and cleaned up
[17:24] <tomreyn> s/SDA/NDA/
[17:25] <penguin42> stgraber: You could show purely the sequence of symbols/offsets in the backtrace with NO data
[17:27] <tomreyn> right. and that's appreciated. from my experience the process of reviewing crash logs could take anywhere between a day and a year when they were public, so, if the situation is the same now (but I would assume it is worse since fewer people will likely have access to these, so fewer reviewers, too), i'm not sure whether this is worth too much for upstreams.
[17:27] <stgraber> penguin42: true, rendering the backtrace mostly useless in the process (at least in python, which we happen to have a lot of, the actual exception text is what's most relevant, the problem is, it's also the bit that can contain any string including exposing potential private information)
[17:27] <tomreyn> do you have statistics on this?
[17:29] <tomreyn> to not be misunderstood, i do understand how the users' privacy must come first, and I actually appreciate this.
[17:29] <penguin42> stgraber: Ah, I'm more of a C person, just the symbol stuff would often be useful there
[17:29]  * tomreyn seconds penguin42
[17:29] <stgraber> penguin42: right, C should be fairly easy to automatically forward, just retrace, send the backtrace and don't attach the core
[17:30] <penguin42> stgraber: Yeh, possibly missing out the parameter data
[17:34] <tomreyn> stgraber: are you in a position to stifle a discussion on this internally? if so, this would be great for us and many, many other free software projects in Ubuntu.
[17:35] <penguin42> I don't think stifle is the required op here
[17:35] <tomreyn> whoops, right, i meant trigger :)
[17:35] <tomreyn> sorry, not an english native speaker here
[17:35] <penguin42> tomreyn: start
[17:35] <tomreyn> sounds good
[17:37] <stgraber> tomreyn: well, the right people have been highlighted above and I'm sure they'll see that discussion, so that's pretty much done. Generally, we definitely want more people to have access to that data, but we need to process step by step, the first and easiest one appears to be the NDA for those who're fine with that, and hopefully finding ways of exposing relevant data without any user data at a later point
[17:42] <tomreyn> It's good to know that the relevant people will be aware now how this is a strong nice-to-have for open source developers now. I can see how an NDA can seem the most logical solution for a business which deals with other businesses or organisations. I would bet, however, that signing an NDA is not an option for a large share, possibly the majority, of those who develop the software which forms Ubuntu.
[17:43] <tomreyn> So if Canonical wants to get a step closer to the free / open source software community again without risking anything on the other and and investing very little this could be a good way.
[17:43] <penguin42> agreed
[17:43] <tomreyn> (and something one could blog about)


[00:17] <bryce> of course wouldn't you know it, as soon as I'm ready to put this fix in, launchpad goes down!
[00:27] <CShadowRun> Murphy's law +1
[00:58] <NCommander> CShadowRun, whenever your ready to fix something, Launchpad goes down?
[00:58] <CShadowRun> NCommander yup, that's murphys law
[00:59] <CShadowRun> Murphys law: Anything that can go wrong, will go wrong
[00:59] <NCommander> :-)
[00:59] <CShadowRun> and it always happens at the most annoying time too.
[01:01] <NCommander> CShadowRun, Murphy's Law only fails when trying to prove Murphy's Law, thereby succeeding
[01:02] <CShadowRun> haha
[01:02] <NCommander> :-)
[04:46] <alex_mayorga> bryce: ping
[04:47] <alex_mayorga> Hi, can anyone take a quick look at bug 213171 please?
[09:50] <bryce> http://www2.bryceharrington.org:8080/X/PkgList/versions_current.html  <-- updated for karmic
[15:14] <lesshaste>  my X just spontaneously rebooted with this helpful backtrace (see end of log) http://pastebin.com/f373a4ba0
[16:27] <mnemo> lesshaste: fglrx doesn't support xserver 1.6 yet so right now you are recommended to use the -ati driver for radeon cards on jaunty.. see this bug for details: https://bugs.launchpad.net/ubuntu/+source/fglrx-installer/+bug/313027
[16:27] <lesshaste> mnemo: that's very interesting but I am hardy
[16:28] <lesshaste> mnemo: I am on hardy
[16:28] <mnemo> oh, I see.. ok
[16:29] <tjaalton> mnemo: the latest version does support it, and jaunty has a prerelease version that also supports 1.6..
[16:30] <mnemo> oh I see
[16:30] <lesshaste> mnemo: the problem is my lack of debug symbols I assume
[16:30] <lesshaste> how can I get those?
[16:31] <mnemo> lesshaste: probably this will work.. sudo apt-get -y install xserver-xorg-core-dbg libgl1-mesa-dri-dbg
[16:31] <mnemo> but you cant get debug symbols for fglrx afaik
[16:32] <lesshaste> ok thanks.. is that what is missing in my backtrace?
[16:33] <mnemo> no yours seems to have only X symbols missing
[16:34] <mnemo> in general, you can determine in what package a file ships using for example the command "dpkg -S /usr/bin/X" and then you can see if there is a blah-dbg package for that... and if there isn't you can enable ddebs repos and then install package_name-dbgsym
[16:34] <lesshaste> thanks.. I am installing the packages you mentioned
[16:34] <lesshaste> and we'll see for next time.. one that I don't understand is that I never get anything in /var/crash
[16:35] <lesshaste> I have  enabled=1 in /etc/default/apport
[16:36] <mnemo> tjaalton: do you know if jaunty will ship a new mesa7.4 based on the upstream stable branch?
[16:36] <lesshaste> does an X crash not trigger apport?
[16:37] <mnemo> lesshaste: apport is disabled in stable release but you can force it to start by running "sudo force_start=1 /etc/init.d/apport start"
[16:37] <mnemo> (maybe thats the same as enable=1 that you mention? not sure)
[16:38] <mnemo> tjaalton: because I have found an extremely attractive cherry pick for -ati this morning
[16:38] <lesshaste> mnemo: thanks
[16:38] <lesshaste> just tried it
[16:43] <mnemo> tjaalton: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/368049
[17:03] <lesshaste> mnemo: out of interest..are all these drmOpenDevice: lines in my log normal?
[17:21] <jbarnes> bryce: what's the url for the xorg blueprints?
[17:24] <tjaalton> mnemo: not sure
[17:25] <tjaalton> mnemo: also, the package should be changed to mesa
[17:25] <tjaalton> afk, bbq ->
[17:26] <jbarnes> bryce: heh nevermind... /me looks at /topic
[19:44] <pwnguin> what's going on with bug #214668?
[19:44] <pwnguin> bugwatch moved it from fix released to confirmed


[04:05] <Firefishe> I'm on Xenial.  I'm getting some repository error messages, and would like to ask for some help deciphering them, please.  Here's my paste output from Terminal:  https://paste.ubuntu.com/25736154/
[04:05] <Firefishe> Also, what is the command line syntax for pulling in all extant repository keys?
[04:19] <drostie> Firefishe: do you have any interesting things you want to say about your setup?
[04:19] <drostie> also what do you mean 'all extant repository keys' -- all packages that you custom-installed?
[04:21] <Firefishe> drostie: I though there was a command for pulling in all keys for listed and active repos.
[04:21] <Firefishe> drostie: I set this thing up about a month ago, and I've left it alone for a bit.  I don't remember why I initially set up the repos the way I did.
[04:22] <drostie> Oh, you mean into your keyring? like PPAs?
[04:23] <drostie> yeah, looking over it you have a bunch of PPAs. hm.
[04:24] <Firefishe> drostie: I do recall that I'm using another server, rather than Main, as Main was getting to be a bit slowish.
[04:25] <Firefishe> drostie: Incidentally, what's the latest LTS?  Is Xenial deprecated now?
[04:26] <drostie> xenial should still be in its support window I think but I could double-check.
[04:26] <drostie> Latest LTS would be 17.04 which would be Zesty.
[04:27] <Firefishe> 17.04 is LTS?
[04:27] <drostie> Oh no, 17.04 was not LTS, you're right.
[04:28] <Firefishe> ya...I"ll stick with Stable.
[04:29] <drostie> yeah, that's no problem.
[04:30] <Firefishe> drostie: I appreciate the help.  I'll have to research the ppa's to see what I was doing.  That said, is there a way to get a stock sources.list ?  If I, say, rename the old one, move it to another directory to save it, and reboot, will the system default?
[04:31] <Firefishe> Or, I guess rebooting really isn't an issue.  If I update with apt-get, will it throw errors?
[04:32] <drostie> @Firefishe I would definitely rename it but it's only, like, one line that you need
[04:33] <Firefishe> drostie: That one line:  I'm assuming it's a repo index line?
[04:33] <Firefishe> drostie: I'm just trying to eliminate my error messages.
[04:34] <Firefishe> drostie: Well, time to put on my mad scientist foil hat, change the name, and xperixenialment. muaha.
[04:35] <Firefishe> ;-)
[04:36] <drostie> yeah like in my case it would be `deb http://us.archive.ubuntu.com/ubuntu/ xenial main universe multiverse restricted`
[04:38] <Firefishe> drostie: I guess I could also just revert through synaptic.
[04:39] <drostie> Firefishe: but there's some stuff about it in /etc/apt/apt.conf
[04:39] <Firefishe> I don't like the newer package managers.  I much prefer synaptic.
[04:39] <drostie> sorry, about *issues* in apt.conf
[04:39] <drostie> like if you need a proxy and one isn't configured in there, or if you need*ed* a proxy and now you don't.
[04:40] <Firefishe> I don't see apt.conf anywhere.  There's an /apt.conf.d/ directory.
[04:40] <Firefishe> That is:  /etc/apt.conf.d  rather
[04:40] <Firefishe> Gads...I"m bad tonight
[04:41] <Firefishe> Thats:  /etc/apt/apt.conf.d/
[04:41] <Firefishe> <--Can be taught with mind control, lasers, and nano brain micro-droids. ;-)
[04:42] <drostie> it also suggests that you might test whether your network is just dropping packets to the right place with wget -qO- http://archive.canonical.com/ubuntu/dists/xenial/InRelease  | head
[04:44] <Firefishe> drostie: The output of that command gave me standard output with what looks like a bunch of binary characters.
[04:44] <Firefishe> What is head?
[04:44] <drostie> just truncates to only the first several lines.
[04:45] <Firefishe> I don't think I have packet issues, actually.  I think it's just the repos.
[04:45] <Firefishe> Probably those ppas.
[04:45] <drostie> Firefishe: here's what that gives for me: https://paste.ubuntu.com/25736313/
[04:46] <drostie> No "binary characters"
[04:47] <drostie> with that said it's worth moving these files and seeing if apt has sane defaults when the files it's looking for aren't there, but it *is* messing with `apt` so definitely don't do anything you can't undo with a livecd.
[04:49] <drostie> also worth checking if any other mirrors do the right thing if archive.canonical.com doesn't.
[04:50] <Firefishe> Let me paste my output.  It's really weird.
[04:52] <Firefishe> drostie:   https://paste.ubuntu.com/25736331/
[04:52] <Firefishe> What terminal/desktop are you usng?
[04:52] <Firefishe> using
[04:52] <Firefishe> I'm using unity/gnome-terminal
[04:53] <drostie> I mean it's a custom shell config but I use zsh underneath.
[04:53] <Firefishe> Yeah, I"m using bash.
[05:00] <drostie> Firefishe: maybe try wget -qO- http://archive.canonical.com/ubuntu/dists/xenial/InRelease >/tmp/wat && file /tmp/wat ?
[05:00] <drostie> if that doesn't work maybe gunzip </tmp/wat reveals some weird gzipping?
[05:01] <Firefishe> with the `?'  -- ??
[05:01] <Firefishe> question mark, or not
[05:01] <drostie> No question mark :D
[05:01] <Firefishe> k :-D
[05:03] <Firefishe> drostie: That saved it, but the file can't be opened.
[05:04] <Firefishe> I'm wondering if I'm missing some encryption tools?
[05:09] <drostie> Firefishe: hmmm. does it happen for all web sites or just that domain?
[05:09] <drostie> like can you wget normal http:// stuff?
[05:10] <Firefishe> could you repaste that please?
[05:10] <drostie> repaste what?
[05:10] <Firefishe> the output paste link.
[05:11] <drostie> this? https://paste.ubuntu.com/25736313/
[05:15] <Firefishe> yes, thank you
[05:18] <drostie> also worth trying with https, maybe it's one of those "check OK to access this network" pages that's on a malfunctioning http server that doesn't do https correctly.
[05:22] <Firefishe> drostie: Sorry, connection issues.
[05:23] <drostie> yeah I can imagine, last thing I said to you was:
[05:23] <drostie> also worth trying with https, maybe it's one of those "check OK to access this network" pages that's on a malfunctioning http server that doesn't do https correctly.
[05:30] <Firefishe> wow
[05:31] <Firefishe> drostie: I just switched the url's to "https" and I get what seems to be a continuous update loop using apt-get.
[05:31] <Firefishe> drostie: This is getting stwange.
[05:31] <Firefishe> ;-)
[05:35] <drostie> yeah. what changed?
[05:36] <drostie> like did you move to a new home? It can't be that you booted up a long-dead computer if you're running xenial.
[05:36] <Firefishe> It's nine years old, actually.  Still working fine.
[05:36] <Firefishe> brb...rest room
[05:47] <Firefishe> back
[05:47] <Firefishe> drostie: My unit is a 2008 Asus G50V(t) RoG Gaming Laptop
[05:48] <Firefishe> drostie: It's a beast! :-D
[05:55] <Firefishe> have to reboot
[10:08] <salvo> ciao
[10:09] <salvo> !list
[13:09] <BluesKaj> Hiyas all
[14:36] <mmedt> hi
[14:36] <mmedt> I need a good editor for my AMP html project
[14:36] <mmedt> I am new on linux
[14:55] <EvilClown> @mmedt welcome to kubuntu
[15:07] <oerheks> !ide
[16:50] <dougl> morning folks
[17:24] <dougl> I am thinking about backing up my OS drives as my installs of Mac OS's are broken and not going to recover - I have learned enough about Macs to know I don't like to be force fed...
[17:25] <dougl> When my desktop in 17.04 goes into suspend mode will my job of copying lots of files to ext4 partitions get inter8pted?>
[17:29] <dougl> or will it not go into suspend mode?
[17:39] <BluesKaj> 'Morning dougl, I think you would get a notifier popup
[17:40] <BluesKaj> how are you backing up your data ? with rsync?
[18:52] <dougl> BluesKaj, thanks for the info... just a straight copy of data from hfs+ by root cuz that is all I know
[18:53] <dougl> BluesKaj, I would probably temporarily turn off power management
[19:32] <hobbybike> list
[19:32] <hobbybike> salve
 Hi guys, … a short question, I yesterday had the possibility by a certain command, to let me the KDE plasma version to let. I can not remember the command now, and I seek in vain for it, so I now turn to you: "lsb_release" and "uname" are not. The output was done with "plasma 5.10.5" or something like that. Can someone of you help me?
[23:06] <acheronuk> plasmashell -v
[23:06] <acheronuk> kf5-config -v
 Thanks for the quick help :)