[01:13] <momken> hello
[01:13] <momken> I want to build an ubuntu server with this architecture
[01:14] <momken> My PC have an SSD for OS partitions (/ and /boot, etc.) and 2x2TB HDDs for Data partitions.
[01:15] <momken> I already have many different ext4, NILFS and BTRFS partitions for different kinds of data (media, docs, projects, backups, etc)
[01:15] <momken> Now I want my server to allow this features:
[01:17] <momken> 1- Only does soft-raid1 (mdadm) for more important partitions (e.g. docs, projects but not media partition containing videos)
[01:19] <momken> 2- Does a level of encryption so that if my HDDs are stolen my data won't be compromised. But obviously, I don't want to enter a passphrase after every boot, because it's a server (mostly headless and without a keyboard) and also may reboot many times due to powerloss
[01:19] <momken> I don't know how to do the encryption part
[01:22] <cryptodan_mobile> how would i upgrade php5 to php7 on server 14.04.2 as well as apace2 to the latest?
[01:26] <cryptodan_mobile> for anyone interested ubuntu 14.04.2 doesnt produce the aacraid error . driver 1.20 of the adaptec raid controller is stable
[01:55] <Kowalski> excuseme
[01:56] <Kowalski> can i create 2 pc with ubuntu server on each pc but count as 1 ubuntu server on network?
[02:05] <cryptodan_mobile> like load balanced?
[02:07] <Kowalski> something like that
[02:08] <Kowalski> i already have 1 ubuntu server
[02:08] <Kowalski> and this server almost full with database,
[02:09] <Kowalski> can i install a new pc with ubuntu server and expand the storage capacity?
[02:09] <Kowalski> oh sorry
[02:10] <Kowalski> can i run ubuntu server on 1 pc, where database server running, but store the database file on another ubuntu server pc
[02:10] <Kowalski> ?
[02:13] <cryptodan_mobile> yes
[02:44] <whislock> You can, but for databases, that's not advisable.
[02:45] <whislock> Kowalski: ^
[04:52] <pheizax> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
[04:52] <pheizax> Make sure to report this IP to any DNSBLs you might think of! That'll totally stop the flood. https://dronebl.org/ I also recommend installing https://github.com/kaniini/antissh
[05:13] <cpaelzer> good morning
[09:34] <cpaelzer> jamespage: does the UCA hold ppc64 binaries (even if they might not be supported) ?
[09:34] <jamespage> cpaelzer: it does and they are supported
[09:35] <jamespage> hmm now you make me ponder that last statement
[09:35] <jamespage> yes it has ppc64el binaries
[09:35] <cpaelzer> fine enough for me
[09:35] <cpaelzer> thanks jamespage
[10:38] <TJ-> Is there a way to configure the qemu default device modes (e.g. SCSI controller using virtio as the default) ?
[11:46] <cpaelzer> TJ libvirt code has defaults per machine type
[11:46] <cpaelzer> TJ-:  to admit I never checked if those defaults can be modified as I always liked that it will fill in sane defaults (and learning with new versions)
[11:46] <cpaelzer> so I could keep my minimal xml and it would do the rest, I see the benefit of overriding defaults thou
[11:47] <cpaelzer> just not sure if that is somewhere already as a feature
[11:48] <TJ-> yeah, I've hit a series of bugs in vagrant-libvirt where it doesn't expose a way to set the device mode and therefore generates a broken libvirt domain XML, which results in the disk image device not being visible to linux kernel, so it drops to the initramfs shell!
[11:50] <TJ-> I'm currently trying to script a workaround that puts "vagrant up" into the background, waits for the domain to start, then does "virsh dumpxml ... | awk 'clever code...' to extract and fix the device entry to add "mode='virtio-scsi' " then calls virsh update-device ... !
[11:50] <cpaelzer> so you'd want to switch the default device mode to get it working
[11:50] <cpaelzer> hmm
[11:50] <TJ-> I was hoping to just set qemu to use something else as the default to avoid this but can't find a way
[11:52] <cpaelzer> I think the defaults for the modes are driver specific and come from the code - at least I would not rememver a config changing that
[11:52] <cpaelzer> it is like "get-config-from-xml, otherwise set foo"
[11:52] <TJ-> yeah, same here. I used to hack on qemu
[11:52] <TJ-> But a man can dream :)
[11:53] <TJ-> Spent the entire weekend hitting bugs in vagrant, vagrant-libvirt, qemu, ansible! An automation tool that should have taken 10 minutes to set up and save me time! Would have been better off doing it manually :D
[11:54] <cpaelzer> I was never too happy with vagrant
[11:54] <cpaelzer> but others are, so I assume as usual it depends on expertise using it
[11:55] <TJ-> much of the problem is incorrect/missing/out-of-date documentation, changes in the way Ruby behaves (syntax)
[11:55] <cpaelzer> that pretty much summarizes my pain with it
[11:56] <TJ-> It's hard to know how much pain to take before ditching it too
[11:57] <TJ-> Once it's working fine, I've got a very complex single-guest scenario to deploy using ansible, which will get iterated thousands of times so I *think* it's worth the pain so far :)
[12:11] <xnox> dpb1, hi!
[12:11] <xnox> have you seen https://bugs.launchpad.net/ubuntu/+source/mailman3/+bug/1775427 ?
[12:22] <ahasenack> xnox: dpb1 is on PTO this week
[13:01] <xnox> ahasenack, thanks
[13:01] <ahasenack> xnox: I added a card to our trello board and assigned it to him
[13:02] <xnox> ahasenack, tah. I'm ok with doing MIRs, but imho i need a product decision whether or not we want /any/ mailman in main; and on the old server iso.
[13:02] <xnox> ahasenack, i.e. drop mailman; or replace mailman with mailman3 in main.
[13:02] <ahasenack> and the latter needs mode deps
[16:02] <Ussat> sudo do-release-upgrade -d , so testing this now on a 16 --> 18 upgrade test system
[16:03] <Ussat> I know the -d flag isnt going to be needed when the switch goes live, but wanted to give a prelim try
[16:04] <ahasenack> just be careful you don't pick cosmic (it shouldn't)
[16:06] <Ussat> OK, so upgrade test went fine but....I thought it would be useing netplan by default ? /etc/netplan is empty
[16:06] <ahasenack> not for upgrades
[16:06] <nacc> Ussat: i think that would only be true on fresh installs
[16:07] <nacc> much like most things, stuff doesn't convert (normally) in the first upgrade path
[16:07] <nacc> it's better for it to work as-is :)
[16:07] <Ussat> OK, thats fair
[16:07] <Ussat> OH...I agree
[16:07] <nacc> Ussat: also, it's not ... 1:1 to convert from eni to netplan
[16:07] <Ussat> I was just noticing it did not, might want to make that known in the docs so people dont freak
[16:08] <Ussat> is there a plan to eventually do a conversion ? I just think (IMHO anyway) having multiple 18.* systems, some with netplan some without would be confusing in the long run
[16:09] <Ussat> I dont think I will convert my existing 16 systems rught away anyway, wil let it bake a while, just to be sure
[16:10] <nacc> Ussat: i don't know the answer to that, sorry
[16:10] <Ussat> NP
[16:11] <Ussat> Had to ask :)
[16:12] <cryptodan_mobile> TJ-: ubuntu server 14.04.2 works flawlessly by the way
[16:13] <cryptodan_mobile> TJ-: any way to get the latest lamp stack on it?
[16:14] <nacc> cryptodan_mobile: 14.04.2? that's eol. You should either be on 14.04.1's kernel (3.13) or 14.04.5's kernel (4.4)
[16:14] <nacc> cryptodan_mobile: if you are fully up to date, both kernels will report 14.04.5, which is what your `lsb_release -sd` should say
[16:15] <TJ-> nacc: it's needed
[16:15] <nacc> TJ-: buggy hardware?
[16:15] <cryptodan_mobile> Cant as any newer ubuntu server causes my server to malfunction
[16:15] <cryptodan_mobile> aacraid bug
[16:15] <TJ-> nacc: the system, A Dell PowerEdge, loses its aacraid with current supported kernels, we needed an old ISO to boot from to do some fixing
[16:16] <nacc> TJ-: even with the 3.13 kernel?
[16:16] <TJ-> nacc: there are a bunch of accraid changes that have broken older hardware
[16:16] <cryptodan_mobile> nacc: 3.13 works
[16:16] <nacc> ok, so use that? rather than an unsupported, unfixed kernel? :)
[16:17] <TJ-> nacc: this was to find out if .2 was also broken
[16:17] <cryptodan_mobile> I was letting TJ- know it is working
[16:17] <nacc> ah ok
[16:17] <nacc> sorry for the noise then
[16:17] <TJ-> nacc: this isn't installed, it's a LiveISO to work from
[16:18] <cryptodan_mobile> Nacc Nacc np and its installed TJ-
[16:18] <TJ-> there are some Fix Committed patches due, but they may not cover this specific issue
[16:18] <nacc> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1653162 ?
[16:18] <TJ-> cryptodan_mobile: to your question: you could pin the current working kernel before doing apt-get dist-upgrade so everything else upgrades
[16:19] <cryptodan_mobile> I'll post that and the driver for aacraid
[16:20] <TJ-> possibly Bug #1770095
[16:20] <TJ-> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1777586
[16:21] <TJ-> possibly also Bug #1777586
[16:21] <cryptodan_mobile> Its funny after 16.04 install its stable but when I add drive i/o it drops the raid controller
[16:21] <cryptodan_mobile> 3 or 4 reboots and no more boot
[16:22] <TJ-> I know with a logn time ago with a PE 6400 the solution was firmware update of the controller
[16:25] <cryptodan_mobile> I maybe able to do that now via command line now that its stable
[16:27] <TJ-> I think I still have floppy disks here with the bootable firmware update on :)
[16:31] <RoyK> TJ-: dd a copy of them - floppies don't last that long ;)
[16:31] <TJ-> RoyK: They've lasted 15 years so far :)
[16:32] <RoyK> that doesn't mean they'll last another 15
[16:32] <TJ-> RoyK: still got some 360K/720K 5.25" floppies here that are readable
[16:32] <RoyK> just use ddrescue to get some copies
[16:32] <TJ-> lastest longer than almost all the HDDs :)
[16:33] <RoyK> TJ-: someone at work had thrown away a 360kB 5,25" floppy drive (DS/DD) - I had to rescue it
[16:33] <RoyK> TJ-: probably because those HDDs were spinning and the floppy wasn't
[16:34] <TJ-> RoyK: I'm on about in storage. Electronics on the HDDs tends to deteriorate
[16:34] <RoyK> when under use, yes, usually not when not in use
[16:35] <RoyK> and mostly, it's a head failure that kills drives
[16:35] <RoyK> not the controller
[16:36] <RoyK> and I know that from an old friend that once started https://www.ibas.no/, who once upon a time was world leading in data recovery
[16:44] <Pcost8300> Hello, how do i disable silent parameters on ubuntu server 14? I have a problem and my provider tells that the server boots and when it tries to go to the Os it goes back to PXE
[16:44] <JanC> I'm pretty sure any 5.25" floppies are > 15yo...  :)
[16:45] <Pcost8300> thank you in advance.
[16:45] <compdoc> Pcost8300, it was booting before?
[16:45] <Pcost8300> yes it was
[16:46] <compdoc> sounds like it cant find the OS
[16:46] <Pcost8300> this problem came recently after years of work
[16:46] <Pcost8300> this has something to do with grub
[16:46] <JanC> Pcost8300: can you select the rescue boot option in GRUB?
[16:47] <JanC> or do anything in GRUB really
[16:47] <Pcost8300> yes i can enter recovery mode
[16:47] <Pcost8300> well i cant see grub because the provider just gave us a powerpanel
[16:47] <JanC> that should not be silent
[16:47] <Pcost8300> im using server4you
[16:47] <JanC> or you can edit the GRUB_CMDLINE_LINUX_DEFAULT parameter in /etc/default/grub
[16:48] <Pcost8300> ok ill give it a look
[16:48] <JanC> then run update-grub afterward (if possible...)
[16:49] <JanC> if you can't, then you might have to edit grub.cfg directly (but it will be overwritten on the next update-grub run, e.g. when upgrading kernels or such)
[16:50] <Pcost8300> ok thank you JanC i will follow your advice
[16:57] <tomreyn> documentation on this providers' PXE boot recovery system, in case you'll need it https://www.server4you.com/community/article/operating-systems/152-about-linux-recovery
[16:58] <TJ-> Hmmm, package virtinst claims to contain virt-image, but doesn't
[17:00] <Pcost8300> thank you tomreyn
[17:01] <nacc> TJ-: no longer mentioned on the upstream virt-manager page, fwiw
[17:01] <nacc> TJ-: removed in 1.1.0 (9/7/14)
[17:02] <nacc> announced in 1.0.0 (2/14/14)
[17:04] <TJ-> nacc: right. I've created a bug
[17:05] <TJ-> Bug #1784424
[17:05] <nacc> TJ-: ack, probably easiest to fix in debian, tbh; i don't think we'd normally add delta for that
[17:08] <Pcost8300> some of the stepts i think cannot be applied to my problem
[17:08] <Pcost8300> using fdisk -l command theres is no * boot flag in any drive
[17:09] <Pcost8300> by the way there are two drives sda and sdb with the same sice en each partition
[17:09] <Pcost8300> 1mb BIOS BOOT  466m linux raid  7.6g linux raid 2.7T linux raid
[17:10] <TJ-> nacc: right... shame we don't have a switch in launchpad to automatically forward the bug report to debian
[17:12] <TJ-> Ahhh coreutils how I love thee! Giving me "timeout" when vagrant provides no way to create a new VM but not start it
[17:12] <TJ-> "timeout 5 vagrant up" :)
[18:07] <cyberspectre> On ubuntu server, the default web directory accessible by http is /var/www/html. I need to be able to scp upload files to that directory with one command, which isn't possible because root. Can this directory be changed to somewhere in the home directory?
[18:08] <nacc> cyberspectre: what is your need to do that?
[18:08] <nacc> cyberspectre: it's not typical to need to be able to scp to your web root
[18:08] <cyberspectre> automated file updates
[18:08] <nacc> you could also consider using userdir or whatever and ~/public-html
[18:08] <nacc> ~/public_html, rather
[18:08] <nacc> cyberspectre: that's so vague as to not be a reasonable response :)
[18:10] <cyberspectre> if I use ~/public_html, will that automatically be available via http?
[18:10] <TJ-> cyberspectre: you could use ACLs to allow a non-root user to traverse/write there
[18:11] <cyberspectre> thanks TJ- ; would it be a better idea (more secure) to use the public_html directory?
[18:12] <TJ-> cyberspectre: well, not if you want to update the server root, but if it's acceptable to use the userdir module and access via http://server/~$USER/
[18:13] <nacc> cyberspectre: which is why i said it was vague; i (still) don't know what you're actually trying to do
[18:15] <cyberspectre> Oh, right, so you'd need to access via that url structure
[18:15] <TJ-> cyberspectre: what I usually do is "sudo chmod -R g+w /var/www/html" and then "adduser $USER www-data" - this allows the www-data group write access to /var/www/html and then adds $USER to www-data group
[18:15] <cyberspectre> nacc, my company has a web server for media files located at company.info
[18:16] <cyberspectre> and I need to set up automated synchronization with a local machine that produces the assets
[18:16] <TJ-> cyberspectre: oh, and "sudo chown -R :www-data /var/www/html
[18:17] <TJ-> depends on which release it is as to whether the directory is owned by www-data or root
[18:18] <cyberspectre> TJ-, in the commands you provided, would you do "adduser $USER" verbatim? Or do you replace with your username
[18:19] <nacc> cyberspectre: just for one local machine?
[18:19] <cyberspectre> nacc, yes
[18:20] <nacc> cyberspectre: then it'd be whatever user is on that machine that can scp to the web server
[18:20] <nacc> cyberspectre: the user it authenticates as on the webe server, that is
[18:20] <TJ-> cyberspectre: well, I'd use $USER if I want to add the user I'm currently using; else I'd specify another username that is valid
[18:20] <cyberspectre> Right, so if that user is "Jeff" then "adduser $Jeff www-data" ?
[18:21] <TJ-> cyberspectre: no... if you're logged in as "ubuntu" then "adduser $USER www-data" will add user "ubuntu" to group "www-data". If you want to add "jeff" you'd do "adduser jeff www-data"
[18:22] <TJ-> "$USER" is an environment variable set when you log in so it is always your current username
[18:23] <TJ-> in the same way that "$HOME" is that user's home directory (same as ~)
[18:25] <cyberspectre> nacc, TJ- thank you guys
[18:25] <cyberspectre> I added the user to that group and now scp works as intended
[18:25] <cyberspectre> Much appreciated!
[18:52] <ahasenack> rbasak: if you are still around, could you please import/refresh ndctl and pmdk?
[19:04] <ahasenack> rbasak: also for tomorrow, I'm starting an apache2 merge, and finding out that all my previous uploads (with the git workflow) do not have rich history, and I'm having to do the reconstruct again
[19:12] <nacc> ahasenack: you don't have to do it again even in that case, you just need to use git-fu
[19:13] <ahasenack> still, I'd like to know if it's something wrong I did on my side, or a bug
[19:13] <ahasenack> as far as I know, I dput'ed only after the upload tag was pushed by someone else
[19:13] <nacc> i'm looing purely from the git side
[19:14] <nacc> which was the last merge? 2.4.33-3ubuntu1 ?
[19:14] <ahasenack> merge? yes. Upload? 2.4.33-3ubuntu3
[19:15] <nacc> which is the one not matching? all of them?
[19:15] <ahasenack> yeah
[19:15] <ahasenack> pick 65084dea Import patches-unapplied version 2.4.33-3ubuntu1 to ubuntu/cosmic-proposed
[19:15] <ahasenack> pick bc275a7e Import patches-unapplied version 2.4.33-3ubuntu2 to ubuntu/cosmic-proposed
[19:15] <ahasenack> pick fad2aea4 Import patches-unapplied version 2.4.33-3ubuntu3 to ubuntu/cosmic-proposed
[19:15] <ahasenack> all these 3
[19:16] <nacc> hrm
[19:16] <nacc> the importer ran on may 15 for 2.4.33-3ubuntu1
[19:16] <nacc> but the upload tag is dated july 9 ?
[19:17] <nacc> oh wait
[19:17] <nacc> let me re-read the metadat to make sure i'm right :)
[19:17] <ahasenack> changelog date is indeed may 15th
[19:17] <nacc> and publishing history says may 23
[19:18] <ahasenack> that's ok, takes a while to review
[19:18] <ahasenack> and migrate
[19:18] <ahasenack> trying to find the mp
[19:18] <nacc> oh wait, it says the tag is may 15
[19:19] <ahasenack> https://code.launchpad.net/~ahasenack/ubuntu/+source/apache2/+git/apache2/+merge/345312
[19:20] <ahasenack> cpaelzer said he pushed the tag on may 15th on a5941629
[19:20] <ahasenack> this is one of those mps where the lp diff is wrong, I wonder if that's related
[19:20] <nacc> shouldn't be
[19:21] <nacc> although i see a commeent of cpaelzer tagging
[19:21] <nacc> and then commits being added?
[19:21] <ahasenack> that last commit is odd, that's from 2.4.33-3ubuntu2 apparently
[19:22] <nacc> ok
[19:22] <ahasenack> that would be https://code.launchpad.net/~ahasenack/ubuntu/+source/apache2/+git/apache2/+merge/345796
[19:35] <nacc> ahasenack: sorry, not able to debug it further right now
[19:35] <ahasenack> sure, np :)
[20:15] <ahasenack> hm, an orig tarball that has debian/ already, and it's not a native package
[20:15] <ahasenack> that's a wrinkle
[20:17] <ahasenack> https://bugs.launchpad.net/usd-importer/+bug/1734657
[21:04] <IT_Rando> So I installed Landscape on an AWS instance running Ubuntu 16.04 and the problems have never seemed to end. The server sets up fine with landscape-quickstart and a little bit of configuration file editing, but then what really screws me over is that package updating for client laptops fails half the time, and that's after opening ports 80 and 443 to my IP. I keep getting the same error message and the
[21:04] <IT_Rando> listed bug is a broken link. I posted on askubuntu about it: https://askubuntu.com/questions/1050482/landscape-package-changer-keeps-crashing
[21:15] <IT_Rando> Does anyone happen to know why my LDS issue, mentioned in https://askubuntu.com/questions/1050482/landscape-package-changer-keeps-crashing, is happening? Or why the link listed in the error report is dead?
[21:16] <xnox> IT_Rando, i think it's best to contact your landscape support team about that? i thought there should be a way to open a support ticket from the landscape UI, no?
[21:16] <xnox> IT_Rando, this time of day is quite here, and i'm not sure you can get paid/SLA support here.
[21:17] <xnox> IT_Rando, ditto askubuntu.com -> is community support / public forum, not landscape support.
[21:17] <IT_Rando> xnox Gotcha. Unfortunately, I have a standalone license for testing purposes for my company, and I'm not gonna have access to the paid support unless I can convince the brass to use it
[21:18] <xnox> IT_Rando, sad =/ maybe you can get in touch with landscape sales people about this, or better open an actual bug report -> $ ubuntu-bug landscape-package-changer
[21:18] <xnox> IT_Rando, and maybe give the bug # to me?
[21:18] <IT_Rando> Gotcha.
[21:19] <xnox> i see that https://bugs.launchpad.net/ubuntu/+source/landscape-client/+bug/1758529 is private
[21:19] <xnox> but it is fix committed and will be released soon
[21:19] <IT_Rando> Oh?
[21:19] <xnox> details are at https://github.com/CanonicalLtd/landscape-client/pull/45
[21:19] <xnox> which are public
[21:19] <xnox> (the bug report, has but reporter's private data in the logs, hence only available to developers to view)
[21:20] <IT_Rando> Oh man, thanks a ton. I was tearing my hair out over here.
[21:20] <xnox> IT_Rando, so i guess you can patch that bit in locally no? https://github.com/CanonicalLtd/landscape-client/pull/45/files
[21:20] <xnox> it's just a few lines to copy & paste =)))))
[21:21] <xnox> IT_Rando, yeah, i'm nobody really. just can view bug triange.
[21:21] <IT_Rando> Thanks! For reference, how'd you find this? Was it in the private bug report?
[21:22] <xnox> IT_Rando, yeah
[21:22] <xnox> IT_Rando, ladscape support would have been able to view that too.
[21:23] <IT_Rando> All right. In the future, if I can't see a bug report, I'll know what that means. And provided this fixes the problem (which it likely will) I'll probably have access to the paid support soon. Thanks again.
[21:23] <xnox> IT_Rando, i can check with landscape devs tomorrow to see if they can scrape private data and make that bug report public, such that it would be visible when the client is fixed in bionic.
[21:23] <IT_Rando> That would be great
[21:23] <xnox> IT_Rando, no problem
[21:59] <oerheks> v/clear
[22:35] <nacc> ahasenack: the tress don't match
[22:36] <nacc> ahasenack: for the upload and import tag
[22:36] <ahasenack> :(
[22:36] <ahasenack> could this be a case of problems because of the empty directories?
[22:37] <nacc> is it docs/ ?
[22:37] <ahasenack> that's the other thing that came to mind
[22:37] <nacc> if so, yes :)
[22:37] <ahasenack> yeah, iirc
[22:37] <nacc> http://paste.ubuntu.com/p/VrNFhK55hR/
[22:37] <nacc> now, in theory, we could detect these kinds of cases, i think
[22:37] <nacc> if the only difference between an upload tag and import tag is the empty directories
[22:38] <nacc> rbasak: --^ ?
[22:39] <rbasak> We could, but is it worth it?
[22:39] <nacc> dunno
[22:39] <nacc> just a thought, as right now, we're discarding relatively valid upload tag data
[22:40] <nacc> (from rich history)
[22:40] <rbasak> I'd like to spend the effort fixing empty directories properly by adding support for them to git, but admittedly that's considerably harder.
[22:40] <nacc> yeah :)
[22:40] <rbasak> In any case, I think improving empty directory handling is quite far down my priority list at the moment.
[22:40] <rbasak> I spent the effort on the workaround on the hope that I'd be able to put it away for a while.
[22:42] <ahasenack> which workaround?
[22:42] <ahasenack> the commit guard?
[22:43] <rbasak> Yes, but also that the importer does actually import the empty directories.
[22:43] <ahasenack> btw, apache has these 2 empty dirs:
[22:43] <ahasenack> docs/manual/style/lang
[22:43] <ahasenack> docs/manual/style/xsl/util
[22:43] <ahasenack> so, it's a given the rich history will always be discarded in such cases?
[22:44] <rbasak> At the moment, yes. Unless you restore the empty directories in your own commits.
[22:44] <rbasak> (which there isn't tooling to do)
[22:44] <rbasak> It's not discarded, btw, just not incorporated.
[22:44] <rbasak> The upload tag will still be present and you can still rebase from it.
[22:45] <ahasenack> ok
[22:45] <nacc> yeah, sorry, 'discard' was the wrong word
[22:45] <nacc> 'not used' :)