[12:07] <rbasak> smoser: o/
[12:07] <rbasak> Could you help me with an "upstream" ssh-import-id release please?
[12:07] <rbasak> Does it need uploading to pypi?
[12:08] <rbasak> And why are we maintaining a debian/changelog in the master branch?
[13:50] <smoser> rbasak: https://gist.github.com/smoser/3cd61fe6e08f0c0955ef949350897d15
[13:50] <smoser> i put that togetther when i did a 5.10 release.
[13:51] <smoser> emailed powersj and som eother canonical folk.
[13:53] <smoser> i have no strong feeligns against maintenance of debian/changelog in upstream. but i do find it useful to have some way to build a package from upstream code easily.
[13:57] <rbasak> smoser: perfect, thanks! I'm reluctant to change established processes on my first touch.
[13:58] <rbasak> I would just use a temporary branch off the packaging branch and merge in master to there to "easily" build a package from upstream code.
[14:00] <smoser> rbasak: i do have strong feelings against the "don't maintain packaging upstream" vibe that i get in these circles.
[14:00] <smoser> i have written this down before, but odn have a link to it.
[14:00] <powersj> rbasak, forwarded the email scott sent for 5.10
[14:00] <rbasak> The reason I favour having a separate packaging branch
[14:00] <smoser> maintaining packaging upstream accepts that upstream changes cause packaging changes, and allows one commit to address them both.
[14:00] <rbasak> You do an upstream release, and then discover during packaging that you need packaging changes.
[14:01] <rbasak> Then what?
[14:01] <smoser> then you fix it.
[14:01] <rbasak> Fix it where?
[14:01] <rbasak> Another upstream release?
[14:01] <rbasak> That seems backwards
[14:01] <smoser> thats a good point.
[14:02] <rbasak> That's the entire and only reason I prefer a separate packaging branch
[14:02] <smoser> but *not* doing it upstream means "let the distro deal with it".
[14:02] <rbasak> They can both be "upstream"
[14:02] <smoser> but if they're not in the same repo, they can't be the same commit.
[14:03] <rbasak> Not sure what you mean there, but I support the packaging branch being in the same upstream repo
[14:03] <rbasak> Just that the upstream release tag shouldn't encompass the packaging
[14:03] <smoser> sorry... not in same branch
[14:03] <smoser> if packaging and upstream are in different branches (or repos), then you cannot sanely link an upstream commit to a change in packaging.
[14:04] <smoser> and then when you go to port that upstream change back to a SRU or something, you miss the packaging change that went with it.
[14:05] <rbasak> I think that's valid but I think that problem is relatively rare in practice. It'd require two oversights rather than just one.
[14:06] <smoser> its absolutely not rare in practice for me.
[14:07] <smoser> i would say (granted over 10 year period) that it happened to me or one of my projects a ten times.
[14:07] <smoser> i really like it that 'merge' or cherry-pick will fail if it can't be applied.
[14:11] <rbasak> Oh there's one more issue
[14:11] <rbasak> Uploads to Ubuntu outside VCS
[14:11] <rbasak> They'd be easier to track in VCS if the packaging branch were separate I think?
[14:14] <smoser> well.. it stillworks.
[14:14] <smoser> fwiw, the changelog is apita. and i do *not* recommend maintaining that upstream.
[14:15] <smoser> iv'e used (or seen) several different mechanisms for this, and they all have warts.
[14:16] <smoser> i'm absolutely not in aposition to spend effort to change anything at this point (or stop someone else willing to invest time in making improvements). but i'd like to avoid having someone drive-by-commit a change like that.
[14:16] <smoser> (as you seem to respect "I'm reluctant to change established processes on my first touch.")
[14:27] <teward> i think the only case where i disagree with the statement of "if packaging and upstream are in different branches (or repos), then you cannot sanely link an upstream commit to a change in packaging" is specific if i'm nitpicking something from nginx upstream development repos for their oss-pkg branch
[14:28] <teward> if only because the cases are rare, and when i do pick it that way it's only out of necessity
[14:28] <teward> (otherwise we pull right from Debian which uses Salsa's repos where src and debian/ branches are combined)
[14:28] <teward> but hey, that's a special case 'cause i'm pretty fluent in the nginx package to begin with :P
[23:22] <chrisowen> I am not sure what channel to ask this in so Ill just see where I get directed.  So after some help to fix the typo I have a fstab line that reads //192.168.3.107/Store/WebSite  /media/winshare1 cifs credentials=/etc/cifs-credentials,file_mode=0755,dir_mode=0755 0 0The problem I see is when I browse a website that is in that path  as <Directory
[23:22] <chrisowen> /media/winshare1>        Options Indexes FollowSymLinks        AllowOverride All        Order deny,allow        Allow from all        Require all granted</Directory>in the apache2.conf file.  When the page shows the graphics show broken but actually do exist so I am trying to figure out how to fix this.
[23:26] <chrisowen> http://192.168.3.101/Graphics/under_construction_Bang_Head.gif gives error the image at that location can not be displayed because or errors but I can open it with a paint program and it displays properly.....  Which adds to the confusion
[23:30] <TJ-> chrisowen: examine the apache logs, possibly after enabling debug messages for the site
[23:30] <chrisowen> mostly gif files in the folder that is smb shared from a freenas server to the ununtu server where it is mounted
[23:30] <chrisowen> apache log is there a document that I can read on how to do that?
[23:31] <TJ-> chrisowen: what kind of file-system actually hosts the files, on the NAS?
[23:31] <chrisowen> the nas is a z something format using smb as the shared directory
[23:31] <TJ-> chrisowen: my bet is there's a permissions issue, and the apache www-data user doesn't have directory traversal (+x) or file read (+r) permissions for the paths being requested
[23:32] <chrisowen> that is what I was thinking but not sure where to do that
[23:32] <chrisowen> this all was working on the server when it was all local
[23:33] <chrisowen> but after 3 drives failed and the rebuild I put it on the nas that I have been using for a while since it has a shadow drive raid
[23:35] <chrisowen> Everything is now working from the raid so my next fix wont take forever as this has, I am still fixing servers I lucked out to have 1/3 of it backed up most of it was the data not all of it though
[23:36] <chrisowen> so I am trying to figure out which needs the permision the share is via the admin connection
[23:37] <TJ-> chrisowen: you should be able to reproduce the issue without apache; if apache is using the "www-data" user, then simply switch to using that account and then try navigating to the files in /media/winshare1 you're having problems with
[23:38] <TJ-> chrisowen: as in "sudo su www-data"  (and 'exit' to get back to your regular user account)
[23:39] <chrisowen> hmmmm
[23:42] <chrisowen> root@apache:/etc/apache2# sudo su www-dataThis account is currently not available.You see if I plead for some one to fix this I wont learn but if I get a few ideas on how then I can beat my head until I figure it out  So I think I might have the answer  I am logged in as sudo su to make all the edits that I needed to fix my typo and updates and the
[23:42] <chrisowen> like so maybe I did not locate the error????
[23:43] <chrisowen> so maybe apache does not have the account?
[23:44] <chrisowen> I can cd  /media/winshare where the folder exists that contains the web site
[23:45] <chrisowen> permissions seems like the right path
[23:46] <TJ-> chrisowen: are you sure apache2 is installed?
[23:47] <TJ-> On mine if I check for the account like this I see: getent passwd www-data
[23:47] <chrisowen> well service apache3 status says it is........
[23:47] <TJ-> www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
[23:47] <chrisowen> apache2
[23:48] <chrisowen> root@apache:/etc/apache2# getent passwd www-datawww-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
[23:48] <chrisowen> lol loos like yours
[23:52] <chrisowen> This is the external link to the server via the firewall http://owentechnologysolutions.com/ so you should see what it is not supposed to look like.... There is a back ground and thumbnails, the text is all that is sent.  On another twist file:///Z:/WebSite/owentechnologysolutions.com/index.html works correctly
[23:52] <TJ-> chrisowen: ahhh, you need to set the shell to use, sorry: "sudo su -s /bin/bash www-data "
[23:53] <chrisowen> ok im using that user now
[23:55] <chrisowen> I am thinking something like this maybe sudo find my_directory -type d -exec chmod 2750 {} \;
[23:55] <chrisowen> I think the winshare des not have permissions???
[23:56] <TJ-> chrisowen: first just explore the share as that user to find out if you can reproduce the issue
[23:56] <TJ-> if you can, then you can decide how to fix it
[23:57] <chrisowen> locally Apache would have created and assigned the permissions but since this is a external share the permissions would not have been given???
[23:58] <TJ-> chrisowen: usually apache's default directory is /var/www/html and it owns that so no problems
[23:59] <chrisowen> www-data@apache:/media/winshare1$ cd /media/winshare1/owentechnologysolutions.comwww-data@apache:/media/winshare1/owentechnologysolutions.com$This works and I can see all the contents
[23:59] <TJ-> now you've got www-data user trying to traverse directories and read files in a file-system that doesn't even *know* of the www-data user, so you'll have to relax permissions on the NAS to allow 'others' to traverse/read those directories, OR set up some kind of user ID mapping in the mount options
[23:59] <TJ-> chrisowen: can you load the files in that directory?
[23:59] <TJ-> chrisowen: reading directory entries isn't the same as reading the files those entries describe