| sirdidymus | how should I install ceres? update the sources to ceres and apt dist upgrade? anything I should be aware of? couldn't find an iso | 03:44 |
|---|---|---|
| gnarface | that would work | 03:59 |
| gnarface | probably | 03:59 |
| gnarface | the only thing you should really be aware of is sometimes it doesn't work and you can't really predict it | 03:59 |
| gnarface | if you're following the correct path very strictly, you'd update to testing first then unstable, but it matters less the less software you actually have installed | 04:00 |
| gnarface | the basic process is no different from debian before, a lot of work went into preserving that type of behavior | 04:07 |
| rwp | sirdidymus, Normally one installs Stable and upgrades from there. | 06:08 |
| rwp | sirdidymus, Since Testing is almost ready for release if you upgrade from Stable Beowulf to Testing Chimaera first then you can help us test that upgrade path. Please report any problems. Then from there to Unstable Ceres is only a very small upgrade right now. | 06:08 |
| adhoc | evening | 08:10 |
| adhoc | is there a recommended IDS for devuan ? | 08:10 |
| gnarface | it should have whatever debian has | 08:10 |
| adhoc | on my todo list is setting up a honeypot for my local network | 08:11 |
| adhoc | so any spurious services that shouldn't be running get pointed there,etc | 08:11 |
| plasma41 | adhoc: and IDS stands for...? | 08:36 |
| rwp | adhoc, Are you talking about the "aide" package? That's what I think of when I hear intrusion detection system. | 08:36 |
| adhoc | intrusion detection system is what I had in mind | 08:43 |
| enyc | hrrm | 09:28 |
| mdt | hi, today i found something weird on my system, some __pycache__ directories are drwxr-x--- (most dirs are fine, it's 9 from ~1300). ok, i use umask 027 as root but that should not influence the creation of files that are considered to be used by everyone. or am i wrong? is this a bug? | 11:34 |
| luna-is-here | mdt: Are you talking about __pycache__ in /usr ? | 11:42 |
| mdt | luna-is-here: /usr/**/__pycache__ - yes | 12:01 |
| luna-is-here | mdt: Did you install the packages via apt or pip? If they were installed via apt, I would consider this as a bug. Can you name an example package? | 12:36 |
| mdt | luna-is-here: i never install via pip systemwide | 14:46 |
| mdt | luna-is-here: you can try yourself: `find /usr -name __pycache__ | xargs ls -ld | grep -- ---` ;) for me it is blinker, click, serial, sortedcontainers, werkzeug, ... | 14:48 |
| luna-is-here | mdt: Well I did and the permissions were all correct. | 14:48 |
| mdt | luna-is-here: what's your `umask`? | 14:50 |
| luna-is-here | mdt: 0022 | 14:50 |
| luna-is-here | So its different. | 14:50 |
| mdt | sure, with 022 everything's fine, no question | 14:50 |
| luna-is-here | Are you running Beowulf or Chimaera? | 14:51 |
| mdt | but any installation should , no must be independent from umask | 14:51 |
| luna-is-here | mdt: I agree. | 14:51 |
| mdt | strange, i had it with python3-tk so i installed that very package on another system with umask 027 but that system desnt have that afterwords for the directory whie it has it for other packages. may it be in one of the debian helper packageswhich got fixed inbetween? | 15:00 |
| luna-is-here | So. | 15:01 |
| luna-is-here | I just tried this in a container. | 15:01 |
| mdt | but i still have it ffor crypto-policies which creates the dir once you run update-crypto-policies and that does it this way | 15:01 |
| luna-is-here | Set umask to 027 and installed python3-blinker. Permissions are as expected. | 15:01 |
| mdt | good. can you try crypto-policies? run update-crypto-policies and check /usr/share/crypto-policies/python/*/__pycache__ | 15:02 |
| luna-is-here | Is only available in crypto-policies ceres, if I see this correctly. | 15:07 |
| luna-is-here | Okay. So tried this in ceres. I installed python3-blinker and crypto-policies with umask 027. Then I ran update-crypto-policies. Permissions look fine. | 15:14 |
| luna-is-here | Hm... | 15:21 |
| luna-is-here | So I have a theory. | 15:21 |
| luna-is-here | Python regenerates the files in __pycache__ when the source files are newer than the cache files. Maybe you had some issue with you timestamps, where running some python script as root and python regenerated the files? | 15:22 |
| luna-is-here | Another possibility: Maybe an upgrade changed the python patch level to an incompatible one. | 15:28 |
| luna-is-here | And then python regenerated. | 15:28 |
| mdt | i run ntp so timestamp should be fine | 17:17 |
| mdt | i dont tamper with python3 (i dont have python2) | 17:18 |
| mdt | i am out of ideas, let me investigate further... | 17:18 |
| luna-is-here | Running a program written in Python will cause the python cache to be regenerated if the .pyc files are older than the .py files or if the .pyc files were generated with an incompatible Python version. | 17:20 |
| luna-is-here | Not sure if this would change the permission though. | 17:20 |
| mdt | yes, that's why py package do that step manually during install, probably adjusting umask, at least in the current version. my theory: because my system has older dirs those suffer from old code that doesnt adjust the umask. still some packages lack the pre-generation step. it seems this crypto-policies is such a package. | 19:29 |
| mdt | https://paste.debian.net/1202168/ shows the problem | 19:52 |
| fab_ | pass mynona | 21:47 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!