[08:23] <FourDollars> Hi, I would like to make a patch for systemd on cosmic. Which branch should I target on? ubuntu/cosmic-proposed, ubuntu/cosmic-devel, applied/ubuntu/cosmic-devel, or applied/ubuntu/cosmic-proposed?
[08:23] <FourDollars> Regarding https://code.launchpad.net/ubuntu/+source/systemd
[10:18] <juliank> FourDollars: I think you want to submit a merge proposal against https://code.launchpad.net/~ubuntu-core-dev/+git/systemd/+ref/ubuntu-cosmic or just open a bug with a patch
[10:19] <juliank> the importer repo is not really being used
[10:22] <KOLANICH> Hello everybody. Can I speak to someone responsible for maintaining package archives?
[10:29] <KOLANICH> I see I can't. So, here is the question: could you start providing delta debs? https://wiki.debian.org/Teams/Dpkg/Spec/DeltaDebs not debdelta, but delta debs, another format. Because some users are unhappy that to update firefox they have to download whole package. I gjess keeping the deltas between 2 latest versions is enough.
[10:30] <juliank> Oh, KOLANICH
[10:30] <juliank> that was weird
[10:32]  * Laney smells a juliank sockpuppet :P
[10:34] <FourDollars> juliank: I would like to open a bug and append a patch or just make a merge proposal.
[10:34] <juliank> Laney: that does not seem very effective, but I'm happy to hear user interest
[10:34] <juliank> FourDollars: Well then, do it
[10:40] <FourDollars> juliank: ok thx
[11:57] <ahasenack> tjaalton: hey, I noticed the openldap package has a debian/tests directory with some scripts in it, but no debian/tests/control, do you know when those are run?
[11:58] <ahasenack> I don't see openldap listed in http://autopkgtest.ubuntu.com/testlist#index-o either
[12:12] <tjaalton> ahasenack: no idea..
[12:14] <tjaalton> ahasenack: looks like they just happen to share the same directory as autopkgtests
[12:16] <tjaalton> those haven't been touched since 2008
[13:31] <elektromacumba> hello, i'm under ubuntu 18.04.1 x86 and i'd like to customixe my initrd.img.*, but it's not in the usual format like in x64 version, the "file" command say "ASCII cpio archive (SVR4 with no CRC)" instead of classic gzip/cpio format. there is a way to unpack and customize it?
[13:41] <coreycb> sil2100: would you be able to review the bionic upload for bug 1778771 ?
[13:41] <ubottu> bug 1778771 in horizon (Ubuntu Bionic) "Backups panel is visible even if enable_backup is False" [High,Triaged] https://launchpad.net/bugs/1778771
[15:01] <rbasak> !dmb-ping
[15:01] <ubottu> cyphermox, jbicha, micahg, rbasak, sil2100, slashd, tsimonq2: DMB ping.
=== michagogo_ is now known as michagogo
[15:45] <balsaq> i noticed ubuntu does not fully uninstall packages when you ask it to do so leaving bits of useless files in the filesystem
[15:46] <balsaq> the ubuntu software center should fully remove the package when the operator presses the remove button
[15:47] <TJ-> balsaq: give an example please
[15:47] <TJ-> balsaq: "remove" does not touch config files or files altered by the system administrator
[15:47] <wxl> ^^ yeah, you need to purge
[15:48] <balsaq> i noticed that , but i am saying there is no reason why u should have to do extra work to remove a package
[15:48] <balsaq> when u press "remove" it should remove, purge clean or any other step u might need.
[15:48] <wxl> you just need to use the right command and you won't have to
[15:49] <balsaq> i know that too thanks
[15:49] <TJ-> balsaq: no, the idea of "remove" is to keep config files in case the package is re-installed later
[15:49] <balsaq> but there is no reason to make things with extra work for no good reason
[15:49] <TJ-> balsaq: and the tools try to err on the side of caution
[15:49] <balsaq> tj - pardon me  but that is not a good reason
[15:49] <TJ-> balsaq: it is THE reason
[15:50] <xnox> balsaq, use $ apt purge foo  or $ apt remove --purge foo
[15:50] <balsaq> makes noi sense , because if  u want the package back it will put all thos files back
[15:50] <rbasak> Unfortunately "remove" or "uninstall" is a bit vague. Different people have different expectations about what that means. For example, if you remove a database package, do you expect the database to be destroyed? As TJ- says, it's erring on the side of caution.
[15:50] <rbasak> The same applies to local configuration customisations
[15:50] <rbasak> Which is why configuration files are left.
[15:50] <wxl> this is not new behavior............. not by any stretch of the imagination
[15:50] <rbasak> They are typically tiny anyway. Do you have a specific problem when they aren't removed?
[15:50] <balsaq> yes i do
[15:50] <xnox> balsaq, there a few false positives, as currently .postrm scripts cannot declare that they are in-fact no-ops for purge, and thus packages get stuck in rc state, despite being clean on the system.
[15:51] <balsaq> the problem i just told my OS to remove something and it did not do it comletely that is the problem
[15:51] <rbasak> That's not a problem.
[15:51] <wxl> it did exactly what you told it to do
[15:51] <balsaq> it took the head off and left all the guts laying around
[15:52] <wxl> no, it did an `apt-get remove`
[15:52] <balsaq> 99 percent of the time when i person shoosed to remove the software thats exactly what they want
[15:52] <rbasak> We know what it did, but I don't think you're going to get anyone to accept on this channel that it's actually a problem or that the behaviour should be different unless you can give us an actual broken use case.
[15:52] <balsaq> i realize it is not a broken system
[15:52] <rbasak> Please keep in mind that for every person who comes in asking the same thing as you, there are others who expect the complete opposite.
[15:53] <balsaq> but when you do something you may aas well do it right
[15:53] <rbasak> There will be someone who lost a database without expecting the system to do that, for example.
[15:53] <wxl> in fact, there are many more
[15:53] <rbasak> Ultimately the project has to make a decision on what the default behaviour should be for all users.
[15:53] <cjwatson> Can you take this to the bug tracker please?  There's at least an argument that it should be possible to purge packages easily in the Software UI app (although I agree with others here that it's best for it not to be the default removal action, as it's irreversible)
[15:53] <cjwatson> (There may well be a bug for this already - I haven't checked)
[15:53] <wxl> if a user knows nothing, assuming complete purging is a terrible assumption
[15:54] <balsaq> yes cjwatson thank you for that...i dont think it is a bug its just a bit of laziness
[15:54] <wxl> while doing the opposite has no critical effect at all
[15:54] <cjwatson> The bug tracker is where this sort of thing is tracked.
[15:55] <rbasak> If you want the default to be changed, you're going to have to come up with a more compelling reason than "I disagree". There's also little point in arguing for the known cons that were already taken into account when the decision was originally made.
[15:55] <balsaq> it could be developed like this instead:  when the operator presses REMOVE   a  pop up occurs   "do you want to remove this package completely" ?
[15:55] <cjwatson> -> bug tracker
[15:55] <cjwatson> IRC is not a bug reporting mechanism
[15:55] <cjwatson> Anything here will be lost, unless you happen to get lucky and the specific people responsible for the program in question happen to be around
[15:56] <wxl> i agree. this should go to the bug tracker. if a sound argument can be made there, i'm sure it could get resolved.
[15:56] <balsaq> ok if you think so could one of you with experience please report the bug
[15:56] <cjwatson> No, bugs should be reported by the person experiencing the problem
[15:56] <wxl> you have the direct experience with the "problem"
[15:57] <balsaq> well the simply install a snap package and then remove it and whoala you will be the man
[15:57] <cjwatson> Use "ubuntu-bug /path/to/whatever/software/app/you/are/using"
[15:57] <cjwatson> Haha you didn't even mention snaps earlier
[15:57] <cjwatson> The entire discussion above is predicated on the assumption that you were talking about debs
[15:58] <balsaq> well i  have a feeling this will happen using the software center no matter what
[15:58] <cjwatson> No details -> terrible discussion
[15:58] <balsaq> sorry but it came from the software center just as i said
[15:58] <cjwatson> Removing a .deb removes everything except a tiny number of config files
[15:58] <balsaq> all i am saying is if an OP installs from software center and removes from software center it should do it
[15:59] <rbasak> balsaq: I suggest you read: https://www.chiark.greenend.org.uk/~sgtatham/bugs.html - then you might understand our perspective better.
[15:59] <cjwatson> Removing a snap, I don't honestly remember
[15:59] <wxl> beat me to it rbasak!!!
[15:59] <wxl> i literally had that in the clipboard
[16:00] <wxl> tbh i don't know about snaps either. that's something worth exploring at the very least. you should file a bug.
[16:00] <balsaq> i am saying that when a person removes any pkg from software center he should have the choice to fully remove it right at that moment no matter if it snap or deb thats all i meant
[16:01] <wxl> then write a bug report
[16:01] <cjwatson> You need to take this to the bug tracker, since as far as I know none of the people answering here work specifically on the software center UI.
[16:01] <rbasak> If you're not prepared to sort out a bug report that explains what you mean and provides a place where we can clarify details, track progress and make decisions, then what you're saying will be politely ignored.
[16:01] <sladen> balsaq: please repeat the process.  Taking a screenshot before, and after, after every step (eg. every mouse) click.  And attach all of these to a bug report
[16:02] <balsaq> i couldnt possibly explain any better
[16:02] <sladen> balsaq: (as politely as it can be said) at the moment, we haven't got *a clue* about the background, nor the details necessary to even start to look into this
[16:02] <balsaq> ok
[16:02] <balsaq> thanks
[16:02] <cjwatson> Also, the implementation of the software center has changed radically between different versions of Ubuntu, and you haven't mentioned which you are using; a bug report is a good place to capture this.  The ubuntu-bug program can help you file it.
[16:04] <balsaq> i am using the most current one i installed it clean yesterday  it is the lated LT 18 10 ubuntu desktop
[16:04] <wxl> bug tracker
[16:04] <cjwatson> I'm not asking you to tell us here :)
[16:04] <balsaq> oh ok
[16:04] <balsaq> sorry
[16:04] <cjwatson> One of the points of ubuntu-bug is to gather this sort of information automatically so that people don't have to play twenty questions on IRC
[16:19] <equinox> hi all... what's the policy/pattern used for the "-0ubuntu0.18.04" suffixes on package versions? (upstream maintainer working on packaging here)
[16:22] <cjwatson> equinox: As an upstream, you wouldn't normally use that kind of security-update versioning, though it depends slightly on the situation; that comes from https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging
[16:22] <equinox> cjwatson: i need to use /some/ suffix because the shlibs:Depends are different between 16.04 and 18.04 (libjson-c2 vs. libjson-c3)
[16:23] <cjwatson> Oh, well if you're maintaining for multiple series then pretending they're security updates or similar and using the scheme from the wiki page above is reasonable enough
[16:24] <cjwatson> This is presumably in a PPA or similar so you really just need to make sure that the version for the newer series is consistently >= the version in the older series so that upgrades are sensible
[16:24] <equinox> we're actually maintaining back to 12.04 on older branches :D
[16:24] <equinox> yeah
[16:25] <equinox> (how would this work if the package was upstreamed and still needed the suffixes because the build result is slightly different between ubuntu releases?)
[16:32] <cjwatson> It'd effectively be a downstream microbranch to do the backport
[16:33] <cjwatson> Or somebody upstream would continue maintaining a PPA or whatever
[16:33] <cjwatson> Packages in Ubuntu proper don't in general keep rolling to new versions in older series
[16:35] <equinox> true... though if ubuntu rolls over to a new release while our package doesn't, there's again a situation where the same source version ends up with different build output due to shlib version differences
[16:45] <xnox> equinox, we do not rebuild binaries.... each versioned binary is only compiled once, and is copied up. explicit uploads are required for rebuilds.
[16:46] <xnox> ah, but you figured that, hence your question, never mind me
[17:01] <balsaq> ok i have a ubuntu one account
[17:19] <balsaq> wow launchpad timed out after all thiws work thus it didnot sully take my bug report
[17:19] <balsaq> sheeesh
[17:19] <cjwatson> you should be able to go back and try again
[17:20] <cjwatson> it shouldn't have lost the text
[17:22] <balsaq> well i can tell some went thru becasue i saw a note in there that said "simliar problemreported before"
[17:23] <balsaq> apparantly noone knows how to integrte the purge command with the remove button in gnome-software
[17:25] <balsaq> but im glad i have the ubuntu one now i see bugs all the time
[17:29] <balsaq> in fact yesterday my icons from my icon launcher were "sticking" to my mouse pointer on screen as if they were magnetized...was very annoying on a fresh clean installation of ubuntu 18 10.
[17:30] <balsaq> for some reaon it seems to have stopped now...