[03:32] <racsox> can someone help me, I'm trying to access a folder from windows that I shared using samba but i have no  access
[03:32] <locknet> best way is using cifs-utils man
[03:32] <locknet> dont waste time with samba
[03:33] <racsox> ok, let me try
[03:33] <locknet> sudo apt install cifs-utils
[03:34] <locknet> sudo mount -t cifs -o username=$windows_user,password=$windows_user_password //WIN_SHARE_IP/$shared_name /mnt/winshare
[03:34] <locknet> that's the command example
[03:35] <locknet> it works perfect
[04:20] <racsox> maybe because the folder I want to share is part of a snap, it's not working
[09:14] <geodb27> People : hi !
[11:15] <snuffy666> o/
[12:02] <icey> hey jamespage, on a package that has the Vcs-Git set to debian's salsa, but that we have patches for, how should I propose a change that you could look at?
[12:37] <jamespage> icey: which package?
[12:42] <icey> python-scrypt
[12:42] <icey> jamespage: grabbed it for https://bugs.launchpad.net/ubuntu/+source/python-scrypt/+bug/1695899
[12:47] <teward> that's... an old MIR o.O
[12:47] <teward> is it still alive?
[12:47] <icey> the package is in main, but one of the asks on it wasn't completed teward :-D
[12:48] <teward> cc sarnold because Security is where this was left of with
[12:48] <teward> jamespage: ^ think Security in 2017 had some concerns with how -scrypt was handling a few things see https://bugs.launchpad.net/ubuntu/+source/python-scrypt/+bug/1695899/comments/4
[12:48] <teward> icey: are you proposing fixing the issues in comment 4 or such?
[12:49] <icey> teward: well, issues 3 and 3 in comment 4
[12:49] <teward> err:duplicateissuesidentified
[12:49] <teward> icey: did you mean 2 and 3?
[12:49] <icey> gah yes
[12:51] <teward> i think there's two options - patch the issue in groovy separately, independently from the git repo on Salsa, or wait for Debian to catch up
[12:51] <teward> either way it'd need a security review again
[12:51] <icey> teward: it's already in main, afaict
[12:51] <teward> because 2017 -> 2020 is a long wait xD
[12:52] <icey> python3-scrypt:
[12:52] <icey>   Installed: (none)
[12:52] <icey>   Candidate: 0.8.0-0.3ubuntu1
[12:52] <icey>   Version table:
[12:52] <icey>      0.8.0-0.3ubuntu1 500
[12:52] <teward> so it is
[12:52] <icey>         500 http://us.nova.clouds.archive.ubuntu.com/ubuntu groovy/main amd64 Packages
[12:52] <teward> !paste
[12:52] <icey> sorry
[12:52] <teward> icey: then I don't think there's anything to be done here?  Unless you want it updated in Debian separately for some reason
[12:52] <teward> :P
[12:53] <icey> teward: well, it's still a critical important bug that my team is a subscriber for ;-)
[12:53] <teward> ah
[12:53] <teward> I'd check with the Security team and the release team then
[12:53] <icey> and it looks like the package itself already has a patch that we're carrying
[12:53] <teward> its possible it was already done and the bug just wasn't closed.
[12:54] <icey> teward: it isn't...
[12:54] <teward> > it isn't < then how is it in main :p
[12:54] <icey> see comments 7 & 8?
[12:54] <icey> I just opened https://github.com/holgern/py-scrypt/pull/3 against upstream to work on the test improvement, in addition to having a patch to propose on the package itself until it lands upstream
[12:55] <teward> heh well 'upstream' counts in two places here
[12:55] <teward> (1) Debian
[12:55] <teward> (2) Ubuntu
[12:55] <teward> s/Ubuntu/Git/
[12:56] <teward> so even if they fix it 'upstream' it needs ot be in Debian to sync to remove any delta
[12:56] <teward> short-term solution is patch it for Groovy and then later resync it when the delta drops
[12:56] <icey> well, yes - I proposed the PR against upstream's upstream
[12:56] <teward> (it's a bandaid fix)
[12:57] <teward> no, IRC, i don't have any unread messages here, thank you
[12:57] <teward> *kicks his IRC client*
[12:57] <icey> heh
[12:58] <teward> icey: i just had to do some evil upstream nitpicking to fix things in xca in Debian a couple days ago, including snag something not yet released to fix an issue.  My two cents is, if you want the bug off your radar *now* then bandaid it with another ubuntu delta/revision
[12:59] <teward> otherwise you'll have to wait for ${UNDETERMINED_TIME_PERIOD} until ti's fixed upstream and trickles to Debian
[13:49] <geodb27> Is that normal that the "assisted partitioning (full disk with lvm)" of the installer of ubuntu-20.04.1-legacy-server or any other item of this installer menu don't allow to create many lv with associated sizes and mount-points ? This used to work as of 18.04 ubuntu install iso.
[13:57] <RoyK> geodb27: IIRC you need to use manual partitioning or perhaps even the classic installer for this to work. Newer ubuntu is meant to be so supereasy to install, your sick old granny can do it, but to make that work, they hid all the fun
[13:59] <geodb27> RoyK: Thanks for your answer. I've launched the install many times, and there is no option (even manual partitioning) that allows me to do what I want. It alwas end with a / and a swap partition. Sometime with even an efi partition I don't want at all. Why the hell did they brake all that was working not that bad before ?
[13:59] <geodb27> *always
[14:03] <geodb27> I've even tried the ubuntu-20.04.1-live-server-amd64.iso (somehow a little better, with this one the partitioning works as I want). However, with this one, the new cloud-init re-install process is so not well documented (no complete example, only the ability to create a user for the system in user-meta). An example of the content of a file, but no idea of how to name it and where to dispose it... Well, all this sucks... I
[14:03] <geodb27> think I'll go and stay with my ubuntu-18.04 and head on with a "do-release-upgrade"...
[14:06] <sdeziel> geodb27: for the live-server install, have you been through https://ubuntu.com/server/docs/install/autoinstall-quickstart and https://ubuntu.com/server/docs/install/autoinstall-reference ?
[14:07] <geodb27> sdeziel: indeed, I went to these places. There is no example of how to partition the disk(s), create lvm(s) and so on.
[14:11] <RoyK> geodb27: AFAICS you just choose "custom storage layout"
[14:11] <RoyK> geodb27: I just ran the installer in a vm and it looked ok from there
[14:12] <sdeziel> geodb27: https://curtin.readthedocs.io/en/latest/topics/storage.html covers partitioning and LVM
[14:13] <geodb27> RoyK: from the live or legacy iso ? From the live, indeed it works fine. My point is that I'd like to automate the process as I did with 18.04 in one way or another. debconf-installer can't be used anymore from what I've read and cloud-init is not that well documented for me (or I haven't searched what I should have) and I can't find any procedure to have it all done on it's own.
[14:14] <RoyK> seems legacy is EOL
[14:14] <RoyK> oh - to automate it - no idea - sorry
[14:15]  * RoyK stopped using ubuntu on servers several years ago and went back to debian
[14:16] <geodb27> Oh, thanks for the link, I'll dig into it. However, with just a glance, the begining of the doc claims : here is a config example (so far, so good). But, this is an example of the *content* of some file that describes the config. What is this file (where is it placed, how should it be named and so on)... That what's all the docs I've read leak... Anyway, you're not responsible of this. I'll read on, more carefuly the link you
[14:16] <geodb27> pointed me to. Thank you so much :-)
[14:17]  * geodb27 need ubuntu as a server at least for lxd...
[15:27] <ChmEarl> in focal, did something change in `d-i partman-auto`? I always get a win95 primary partition unless I use an expert recipe
[15:28] <ChmEarl> this a xen domU, where I wanted a single primary root partition
[15:29] <ChmEarl> I'm able to get no_efi, so no ESP, but always the installer creates a win95 fat32