[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2020-10-11 23:59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2020-10-11 23:59 UTC. Removals: app-crypt/acmebot 20201009-08:04 mgorny d168b61c08d app-misc/mswinurl_launcher 20201009-07:53 mgorny 9d7c12e1bd8 app-misc/mtail 20201009-07:52 mgorny a68262d6a27 app-text/silvercity20201009-07:52 mgorny af36240d2fd app-vim/conque 20201009-08:04 mgorny 9238841ae94 dev-libs/qrosspython 20201009-07:51 mgorny ce5e26e9dab dev-perl/Net-Kismet20201007-07:25 mgorny 6e8341a3a45 dev-python/backports-unittest-mock 20201009-07:21 mgorny 644776f076c dev-python/flask-appconfig 20201007-07:26 mgorny 2b28884c93c dev-python/matplotlib-python2 20201011-14:28 zlogenefb157138b11 dev-python/mini-amf20201007-07:26 mgorny e25efcc86c2 dev-python/oauth 20201009-07:50 mgorny 7297f9b2de3 dev-python/pyinsane20201007-07:24 mgorny 9f6ea350701 dev-python/pysendfile 20201010-06:00 mgorny 0fcca8a5a79 dev-python/redlock-py 20201009-08:03 mgorny e06e907312b dev-python/root_numpy 20201009-08:03 mgorny dffbe638a09 dev-python/rootpy 20201009-08:03 mgorny 50ed73901e8 dev-python/SchemaObject20201009-07:51 mgorny d67d88c8af4 dev-ruby/pygments_rb 20201009-07:50 mgorny f6a29ee7397 dev-tex/dvi2tty20201010-06:00 mgorny a1fc56e3fa9 dev-util/doxy-coverage 20201009-07:49 mgorny 1d6e4b3620f dev-util/mpatch20201009-07:48 mgorny dbdc2f4d7bd dev-util/setconf 20201009-08:02 mgorny 2874f8647d8 dev-vcs/cvs2svn20201009-07:47 mgorny aae2f4c1513 media-sound/codecgraph 20201009-07:38 mgorny 242ab80a603 media-sound/freebirth 20201009-08:09 mgorny a317a27554b net-analyzer/mk-livestatus 20201009-07:23 mgorny 3e77be52575 net-misc/pssh 20201009-07:38 mgorny 5d18c2c1b1b net-misc/ris-linux 20201009-07:37 mgorny 74195dda3fc net-wireless/kismet-ubertooth 20201007-07:25 mgorny 9c0527146e9 net-wireless/mousejack 20201009-07:37 mgorny 57e999f4d36 net-wireless/python-wifi 20201009-07:37 mgorny 924e4a096e0 sci-biology/amos 20201009-07:34 mgorny 1df82e97d59 sci-biology/embassy-meme 20201009-07:33 mgorny 96c3a9acc9e sci-biology/meme 20201009-07:33 mgorny d2b309d1c79 sci-biology/shrimp 20201009-07:32 mgorny 7a7bbd341b0 sci-biology/vienna-rna 20201009-07:22 mgorny 79d0df0bd01 sci-electronics/linsmith 20201007-14:55 tomjbe 4782ebcebd4 sci-misc/gato 20201009-07:32 mgorny 8133e0f14ba sci-physics/rivet 20201009-07:32 mgorny 703a3e4221e sys-cluster/heartbeat 20201009-07:31 mgorny 3f5834ad43f sys-fs/owfs20201009-07:21 mgorny ffd86cfb0f6 www-servers/cherokee 20201009-07:20 mgorny 32b08650cb9 x11-misc/dsx 20201009-07:31 mgorny bdf03aa2b82 Additions: acct-group/croc20201005-13:41 sultan b0287c17b9e acct-group/jabber 20201011-21:39 conikost de00139a70e acct-group/sks 20201008-22:36 samc12728f3082 acct-user/croc 20201005-13:39 sultan ced0eabac20 acct-user/jabber 20201011-21:48 conikost 88dea29ba96 acct-user/pgbouncer20201008-02:30 titanofold 20834a76451 acct-user/sks 20201008-22:37 samb7e200ad5f8 app-crypt/openpgp-keys-miniupnp20201006-08:36 mgorny 5de233ce1e6 dev-cpp/robin-map 20200930-21:19 samadb952e0417 dev-libs/qtcompress20200928-08:52 juippis32fa1fd73e5 dev-python/fastjsonschema 20201011-14:22 mgorny 9b70f573cdc dev-python/pydantic20201008-16:30 sbraz b46fa2605f7 media-libs/quarter 20201005-22:05 reavertm af3bcec7772 media-libs/SoQt20201005-22:04 reavertm 23b04b0d146 net-im/prosody-modules 20201007-21:39 conikost 7421df2888e net-wireless/gr-m2k20201006-20:17 zerochaos 43aea490071 net-wireless/gr-scopy 20201006-19:20 zerochaos dfd79505911 net-wireless/libm2k20201006-20:10 zerochaos 7b8f4150702 x11-misc/revelation20201007-07:40 juippisff3bd31b2d8 -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: dev-python/matplotlib-python2,removed,zlogene,20201011-14:28,fb157138b11 dev-python
[gentoo-dev] Last rites: net-fs/openafs-kernel
# Andrew Savchenko (2020-10-11) # Mask old openafs version and corresponding openafs-kernel with # multiple CVEs. # All kernel module functionality is merged back in the single # net-fs/openafs package using USE="modules" starting from 1.8 branch. # No reverse dependencies, bug #719136. Removal in 30 days. net-fs/openafs-kernel pgpmKnlQLLfii.pgp Description: PGP signature
[gentoo-dev] sys-apps/firejail and sys-apps-firejail lts are up for grabs
Hi, the following packages are up for grabs: - sys-apps/firejail - sys-apps/firejail-lts Best Regards Dennis signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 1/5] verify-sig.eclass: New eclass to verify OpenPGP sigs
On 10/11/20 4:40 PM, Thomas Deutschmann wrote: > > > First of all, calm down. You are reading too much into this. Just > revert your own logic: You obviously like your idea, worked on this > and pushed it to repository. Don't you see that anyone could ask the > same? Who are you? Why do believe that you can force something like > that down to everyone's system? That feature got enabled in developers > profiles by default, it will blow up distfiles with useless data (a > view you can have when you share my concerns and don't see any > problems with current Manifest system; For example we banned stuff in > $FILESDIR before and asked developers to move them to d.g.o when >25kb > in total arguing that large distfile is affecting *any* user... I am > not comparing this 1:1 but to repeat your question: Who are you that > you can decide to force something similar down to everyone). > > > Sure, if I am the only having that opinion and most people see a value > in this and disagree with me... > > I vote for disabling that USE flag in developer profile. There are more than 1 person using it not yet buying or understanding this "draft". I also believe such a profile flag change should be discussed first. -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 1/5] verify-sig.eclass: New eclass to verify OpenPGP sigs
On 2020-10-10 22:36, Michał Górny wrote: On Sat, 2020-10-10 at 22:10 +0200, Thomas Deutschmann wrote: Another example for something that was not thought to the end and which was rushed and pushed to our users. You start this mail with an insult to me. Why do you keep doing this? Do you feel that there is some special need for you to try to diminish me in order to reach your goal? You seem to be obsessed with the idea that I am your perfect enemy... I cannot help you with that. The whole idea started with assumption that not every developer will verify the distfile (an assumption I share). But why should we trust these developers that they will keep an eye on upstream’s used certificate instead? That does not make any sense for me. This sounds like 'perfect is the enemy of good'. If we can't get this done perfectly good, we should just lie down and do not put any effort into making things better. Sort of. Another point I just want to mention was patch 5 of 6 for net-libs/miniupnpc. Did you notice that the ebuild will fetch public key via HTTP instead of HTTPS? Is this question to me or to the public? Because if it's to me, then yes, I've noticed I couldn't use HTTPS there. I'm sorry, I'm not as incompetent as you'd repeatedly trying to prove, you won't win your argument this way. See the first paragraph. I really don't understand why you believe I want to show world how incompetent anyone is. I am very sure that people active in Gentoo know very well that you are *not* incompetent. I am just showing a design flaw without any judgement. This is a technical mailing list. It should be possible to focus on technical aspects. One way to respond to that would maybe a discussion how we can do that better (see robbat2 mail for example). I am fully aware that this is still a draft, which is also part of my problem but I will address that later. This will create a chicken-egg problem here: We will record key information metadata the same way we store information about distfiles which is temper proofed. But because this is happening in an automatic way there is not just a theoretical chance that we will store an attacker’s key in our metadata because who is going to verify they key? The same developer we distrust (or where we just want to avoid to trust) that he/she verified the distfile? What's the alternative? Ignoring upstream signatures entirely unless we can securely fetch the key? Shoving the problem under the carpet and assuming that the developer will have safely set up the key on his devbox while being totally incompetent at putting it in an ebuild? My point here is: You had the idea to improve something. Which is good. Improvement is always appreciated. But it must be an improvement. I expect that during the process, "Hey, I think we can do X better... what do you think about doing it that way... which will address problem Z..." we are all open minded. That means that if we come to the conclusion that something isn't really an improvement or so minor that the complexity and everything belongs to that isn't worth it, that we all realize, "OK, didn't work as expected. Withdraw the idea (maybe just until we find a better way) and move on". Theories are all nice but do you have any proof of that? Preferably one that involves developers who *actually carefully* checked distfiles. Because my theory says developers don't have infinite time to audit everything. I don't think I need a proof for that. I am just picking up your initial argument for this new eclass saying "I don't want to need to trust developer that distfile was checked carefully, if we would add automatism we wouldn't need to trust..." (something I share). I hoped I would have shown everyone that in the end we are only *moving* that trust we don't want to give developers that they carefully checked distfiles to keys. In other words: We haven't changed anything -- we gained nothing. We still have to trust developers that they carefully check something, now just keys instead of distfiles. The previous 'problem' this eclass wanted to improve (solve?) is still there. ...and from my POV we got an additional problem because we now have a system which will tell user, "No... distfile looks good, signature is fine" which weighs the user in a false sense of security (even Google had to learn that when they replaced padlock with "Secure" in browsers -- suddenly users stopped using their own brain because they trusted system too much which was telling them that the site which looks like their bank but wasn't their bank's site was secure). Not to mention when this system will force users to connect to arbitrary key servers... Are you arguing that we should remove commit signatures as well? Or does it happen that with roughly the same technology and the same people, one layer is secure and another similar layer is totally bonkers? No. First you need to understand
Re: [gentoo-dev] [RFC] Refactor display manager openrc init scripts to independent package
On 10/10/20 2:26 PM, Aisha Tammy wrote: - Configuration of display-manager is done similar to xdm by modifying /etc/conf.d/display-manager - Add display-manager to default runlevel and it should start working My counter-proposal at this point would be to handle DMs similarily to how it's done with systemd. In other words, every DM would provide their own init and conf files (or, "service" files) and they'd be controlled This is quite hard as openrc manages tty handling differently than systemd. Currently display-managers work by adding an extra run level in openrc (see https://github.com/gentoo/gentoo/pull/16554/files#diff-6d89a718d595e0c0516c6d6b96bd4cd5R21) It is not possible to do this independently for each of lightdm/gdm/sddm separately, there would be too much redundant copying of code. Would this not be resolved by switching to openrc-init instead of systemv init?
