mån 2010-11-01 klockan 10:09 -0700 skrev Adam Williamson:
> I disagree. The evidence you cite does not support this conclusion. We
> implemented the policies for three releases. There are significant
> problems with one release. This does not justify the conclusion that the
> policies should be en
fre 2010-10-29 klockan 08:32 -0400 skrev James Antill:
> I don't think you need to display them, just display something that
> says "this is more than it seems" ... like ACLs. Something as simple as
> "-rwcr-xr-x." instead of "-rwsr-xr-x." for setuid.
I.e. kind of like what "ls --color" does?
R
mån 2010-11-01 klockan 15:12 -0700 skrev Adam Williamson:
> This is a reasonable modification of the idea that an update should only
> require karma for one release (which would be nice if it were true but
> unfortunately isn't). In practice, though, there isn't much wiggle room
> for requiring 'l
[changing topic to split this out to it's own thread]
mån 2010-11-01 klockan 15:12 -0700 skrev Adam Williamson:
> > We also need some obvious ways where users in general can subscribe to
> > testing updates of stuff that they care about, to expand the userbase
> > that performs testing of updates
tis 2010-11-02 klockan 00:32 +0200 skrev alekc...@googlemail.com:
> What can expect user that have system booting with GRUB2 and installing
> Fedora? It is natural to expect that after Fedora installation will be
> bootable both systems Fedora and other distro.
As with all boot loaders it depends
The password change is understandable, but why force an SSH key change
with such short notice?
And what if the SSH key is a hard token (smartcard) which can not be
copied or trivially changed? Switching to a soft key would be mostly
counter-productive from a security point of view. Now I were not
tis 2011-10-11 klockan 10:49 -0700 skrev Adam Williamson:
> There obviously is a _legitimate_ question as to whether you ought to be
> able to add your package into anyone else's update if you aren't a
> provenpackager; it's not necessarily something we'd want to do. But I
> think provenpackagers
mån 2011-10-10 klockan 20:44 +0200 skrev Thomas Spura:
> Forcing only critpath packages being in updates-testing and the rest
> being allowed to push to stable directly would help to fix issues much
> faster.
You could set stable karma threshold to 1. It's then sufficient one
tester gives positiv
ons 2011-10-12 klockan 13:04 -0500 skrev Mike McGrath:
> Lots of people use and share keys across different projects.
There is no security issue in sharing kes across different projects,
other than that it gives a strong hint that you are the same person in
both projects, much stronger than name
ons 2011-10-12 klockan 13:25 -0500 skrev Jon Ciesla:
> Plus, you could have multiple
> keys, all with the same passphrase, for different things, should you so
> desire.
That's effectively one shared key for all. If one of them are
compromized them most likely all of them are, as the attacker cle
ons 2011-10-12 klockan 19:22 +0100 skrev Peter Robinson:
> If your using a hard token you should be using a subkeys I believe and
> not the root key, not sure if that's gpg or ssh or both.
subkeys is not relevant to the SSH world. That's a OpenPGP thing where
the main key should only be used for
ons 2011-10-12 klockan 12:20 -0700 skrev Adam Williamson:
> Sure there is. There's the exact same problem as using the same password
> across multiple projects: if someone compromises the key they have
> compromised all of those projects. If you use a different key for each
> project, an attacker
ons 2011-10-12 klockan 13:49 -0600 skrev Kevin Fenzi:
> If you can't change your token, then I would posit you have a problem.
> What if you KNEW your private key was compromised? Surely there is a
> way to generate a new one...
I can change it, but it means changing it for all sytems I access u
ons 2011-10-12 klockan 14:59 -0500 skrev Mike McGrath:
> 1) People share keys across different projects.
Yes.
> 2) We've found PRIVATE keys on our servers
Which should lead to immediate account suspension, no matter if that key
is the Fedora key or some other key.
And in reality it's not relat
ons 2011-10-12 klockan 15:15 -0500 skrev Jon Ciesla:
> Well, no, actually it just means you just need to use a different key for
> Fedora. There's no reason you can't keep using that key everywhere else
> you're using it.
Sure I could buy another token just for fedora, just don't see what it
wou
ons 2011-10-12 klockan 21:41 +0200 skrev Thomas Spura:
> I set them often to 1, but don't want to upkarma my own update because
> it feels like cheating...
>
> Especially updates, that fix a broken package, are an examples, that the
> current path (with forcing updates in updates-testing) taken i
tor 2011-10-13 klockan 12:32 -0600 skrev Kevin Fenzi:
> Currently there's not a way to do this, but there really should be.
>
> https://fedorahosted.org/fedora-infrastructure/ticket/2977
Not even uploading an empty key file?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.
sön 2011-10-23 klockan 17:04 -0500 skrev Rex Dieter:
> The fail(*), imo, was with 12.999 going stable containing known-regressions.
> So, any suggestions, if any, to prevent any similar series of events?
My suggestions:
Disable automatic push to stable when there is any negative karma,
requiri
sön 2011-10-23 klockan 23:45 -0700 skrev Adam Williamson:
> This would cause significant problems around crunch times. We would wind
> up having to have releng super-push far more updates because we simply
> don't always *have* three days to wait to hit deadlines.
note that I only proposed automa
fre 2011-11-04 klockan 13:12 -0400 skrev Tom Lane:
> Packages that rebuilt successfully with 1.5 658
> Packages that FTBFS for non-libpng reasons186
> Packages that rebuilt with 1.4, but not 1.5 74
> Packages that need help even with 1.4 46
With this data my gut feeling is to go f
fre 2011-11-04 klockan 11:53 -0600 skrev Kevin Fenzi:
> If we do this, next cycle we should NOT do any 'two part' go/no-go
> meetings.
The "two part" meetings were both about critical blockers that were
known and actively being worked on at the time of the meeting. This
situation will happen no
lör 2011-05-14 klockan 12:10 -0400 skrev Dave Jones:
> It used to be a module, but was converted to built-in as we were always
> loading it in the network scripts. A lot of the decisions made in
> those '5 second boot' days seem a bit boneheaded in hindsight.
> For f16, we should do a good re-rev
lör 2011-05-14 klockan 19:33 +0200 skrev Xose Vazquez Perez:
> default is 24010, but it was reduced to 1024 by
> user(included root) in: /etc/security/limits.d/90-nproc.conf
> to prevent accidental fork bombs(see rhbz #432903).
>
> Is it still worth it? The kernel brings oom_kill.
Yes it's neede
ons 2011-11-09 klockan 02:06 +0100 skrev Lennart Poettering:
> That said, I am not particularly keen on having an inflation of subdirs
> in /tmp created at early boot. I'd much prefer if we design our stuff in
> a robust way so that directories are created when they are needed, but
> without them
lör 2011-11-12 klockan 09:04 -0500 skrev Sam Varshavchik:
> For the longest time, I was able to upgrade an existing system by copying
> over the pxeboot vmlinuz and initrd.img, sticking them into menu.lst, and
> directing grub to load them.
This is also how I install. Have worked fine with bot
lör 2011-11-19 klockan 00:23 -0500 skrev Gregory Maxwell:
> This use to be more true, but there are multiple levels of -Wstrict-aliasing
> and
> I would be _highly_ surprised if the default gave a false alarm. I think you
> can reliably say that if you get a warning at the default level then you
tis 2011-11-22 klockan 17:51 + skrev "Jóhann B. Guðmundsson":
> What do people see as pros and cons continuing to use the current
> package ownership model?
ownership is some times misappropriated with others doing all the work,
but it's also of little practical meaning in the end.
Would pro
tis 2011-11-22 klockan 13:03 -0800 skrev Adam Williamson:
> * Any custom choices the package maintainer opts to provide, via some
> kind of interface to Bodhi
* Checkboxes per bug assigned to the update for indicating that the
update have been verified to fix that specific bug.
* When the update
tis 2011-11-22 klockan 14:03 -0800 skrev Adam Williamson:
> The proposal is to treat a PT hitting the panic button even more
> dramatically than a registered user hitting it, the idea being that PTs
> should be somewhat better informed and hence less likely to trigger it
> falsely, and that we hav
tis 2011-11-22 klockan 17:28 -0800 skrev Adam Williamson:
> We could tweak the rules here for sure, that's kind of the attraction. I
> was focusing on the critpath case as an obvious one that benefits, but
> indeed, we could look at interpreting certain negative results more
> aggressively for non
ons 2011-11-23 klockan 12:30 +0100 skrev Vít Ondruch:
> it is interesting that there are still some packages
> from F14 and older Fedora releases. That is sign that these packages are
> un-maintained and they are FTBFS.
Indeed, and many more are. But we do have a process for dealing with
unmain
sön 2010-11-21 klockan 11:00 +0100 skrev Till Maas:
> I guess this can be somehow automated. E.g. change Bodhi to drop the
> karma requirements for packages that had e.g. two subsequent updates
> without any Bodhi feedback and re-enable it if they get feedback.
That would be somewhat counter prod
fre 2010-11-05 klockan 12:53 + skrev "Jóhann B. Guðmundsson":
> Reports came in --><-- Auto responce reply back to the reporter --> QA
> verified try to duplicate bug --> Bug set to maintainer --> Bug stayed
> like that until EOL
You forgot
Bug was actually fixed from upstream relase,
lör 2010-11-06 klockan 14:08 +0100 skrev Till Maas:
> I have no problem to verify a bug when the maintainer is ready to fix
> it. But it is pretty annoying to verify it within a small time window
> regularly just to have it ignored till the next EOL date.
Understood. And the same issue is also on
fre 2010-11-05 klockan 21:37 +0100 skrev Michael Schwendt:
> Something is terribly wrong here, if reporter adjusts F12 -> F13 -> F14
> over a period of N months in reply to the automated NEEDINFO requests and
> still doesn't get any response other than another automated one after
> six more months
mån 2010-11-22 klockan 18:51 +0100 skrev Björn Persson:
> Henrik Nordström wrote:
> > * Slight adjustment of karma to provide choices "Works for me", "Problem
> > still present" and "New problems seen"
> >
> > * "Works for me" is
tis 2010-12-07 klockan 19:20 -0500 skrev Doug Ledford:
> For non-boot devices, loopback works. You only need the hardware if you
> are testing boot time capabilities (which, admittedly, is the far more
> important aspect of testing for this package).
And if you don't have spare systems with more
ons 2010-12-08 klockan 11:41 + skrev Peter Robinson:
> It was my understanding that abrt was suppose to block on backtraces
> without debuginfo but I still regularly get bugs with little or no
> decent info.
True. I accidently filed a such abrt report some time ago. I assumed it
would fetch t
tis 2010-12-07 klockan 20:53 +0100 skrev Andreas Tunek:
> Shouldn't the end of life message reflect that then? It should tell me
> to contact a bug zapper to move the bug report.
I think the reporter can move the bug report as well. At least I have a
memory of doing so on some of the bugs I have
tis 2010-12-07 klockan 10:20 -0800 skrev Jesse Keating:
> While I'm looking into the git setup and ACLs and all this, I have a
> question.
>
> Is anybody seeing any real value of having different commit ACLs per
> Fedora branch? I've seen some argument for EPEL vs Fedora, but is there
> real valu
fre 2010-12-17 klockan 11:22 +0100 skrev Michael Schwendt:
> +1 to some way of automating koji buildroot overrides (perhaps based
> on FAS group membership such as provenpackagers) in order to remove
> the releng bottleneck.
Suggestion on how to express this in the packaging process:
BuildRequire
fre 2010-12-17 klockan 11:08 -0700 skrev Kevin Fenzi:
> For the second point, I'm not sure what the delay time people are
> seeing is. Currently Rex is doing almost all of these overrides.
> Perhaps we could get some more folks to step up to process them? Or
> open them up to provenpackagers or so
mån 2010-12-20 klockan 15:58 -0500 skrev seth vidal:
> So you want contingency fall-through deps?
> ie: BuildRequires: foo = 1.1.1 (but if that's not available foo =
> 1.0.0)?
No, not quite.
pull in foo-1.1.1 from updates-testing if the requirement can not be
satisfied from updates. Applied re
mån 2010-12-20 klockan 16:01 -0500 skrev Tom Callaway:
> I think a simpler idea is a minimal webapp (and perhaps a CLI interface)
> that lets you login with your FAS account and request an override on a
> built package that you have permissions for (and at the same time,
> choose how long the over
mån 2010-12-20 klockan 16:15 -0500 skrev seth vidal:
> So you want to give updates-testing preferential value over updates
> despite their being no e-v-r difference between the pkgs? If so - you
> can do that now with yum's cost value.
No. The stable repositories (updates / dist) always have prio
mån 2010-12-20 klockan 14:42 -0800 skrev Jesse Keating:
> Perhaps you don't understand how the buildsystem works. The build
> system does not use our external "Updates" or "updates-testing"
> repositories. It doesn't use multiple repositories either. It uses an
> internal repository that is the
mån 2010-12-20 klockan 18:12 -0500 skrev Matt McCutchen:
> That will work, assuming the user has permission to do the tagging; it
> is essentially a buildroot override in reverse. So the question is just
> what we want to optimize for: more testing of packages while they are in
> testing, or less
tis 2010-12-21 klockan 11:47 -0500 skrev Colin Walters:
> "But they still have uid 0, which typical system installation allows
> root to do things. For example, /bin/sh is 0755 and /bin is also 0755
> perms. A disarmed root process can still trojan a system. But what if
> we got rid of all the rea
tis 2010-12-21 klockan 18:52 -0500 skrev i.g...@comcast.net:
> Ok, so who says that the files must be owned by root? Make them owned by
> some other user -- say, bin? (or does that have another use that my
> google search isn't coming up with?)
Better to make the process not run as root imho.
Re
ons 2010-12-22 klockan 00:59 +0100 skrev Miloslav Trmač:
> This is possible, but it would be a much larger change to the system.
> To take a particular example, look at /etc/shadow.
>
> It needs to be protected against attackers, so it should not be owned by
> root - let's make it owned by "adm",
tis 2010-12-21 klockan 13:02 -0500 skrev Matt McCutchen:
> updates-testing explicitly. Either variant of the approach has the
> danger though that because a build needs one thing from updates-testing,
> it will end up getting something else from updates-testing that the
> maintainer didn't expect
tis 2010-12-21 klockan 09:50 -0700 skrev Kevin Fenzi:
> Basically it's changing spec files BuildRequires to suit our build
> setup and not for 'the version this package needs to build'.
True. And it's use should be limited to the release branches of a
package, not master/rawhide.
Imho it adds
lör 2010-12-25 klockan 17:09 -0500 skrev Orcan Ogetbil:
> On Sat, Dec 25, 2010 at 5:02 PM, Tom Lane wrote:
> > Michael Schwendt writes:
> >> On Sat, 25 Dec 2010 14:33:37 -0500, Tom wrote:
> >>> I'm still on F13, but theoretically it should be the same no?
> >
> >> You are on x86_64, right?
> >> I w
fre 2011-01-14 klockan 16:16 -0500 skrev Nathaniel McCallum:
> I still think migrating to GNOME shell by default was a mistake if the
> proper fallbacks were not in place. If the developers knew the
> fallbacks were not implemented (this seems to be the case), why was it
> ever enabled by default
These are python packages currently assigned to me but I am not in a
position to keep maintainging them.
If there is anyone interested in taking over them please speak up.
Otherwise I will orphan them in 2 weeks. Thise in CC are either co-
maintainer of one of the packages or have indicated inter
tor 2021-09-23 klockan 11:29 +0200 skrev Miro Hrončok:
>
> However, I think side-tags should be the preferred solution, as their
> impact is
> isolated. Buildroot overrides create temporary broken dependencies
> for
> everybody, while side-tags don't.
For stable releases I think I agree, even w
I recently took over Radare2 maintenance for Fedora after it was
orphaned, and now noticed it is also packaged in EPEL-8.
I am not in a good position to actively maintain the EPEL-8 release. I
am not an EPEL user, no interest in EPEL, and and not very comfortable
with doing "blind" maintenance by
I recently took ownership of Radare2 after it was orphaned,
unfortunately unknowing of the current turmult in the Radare2 project.
Now realizing that it has a dependent Fedora package Cutter (cutter-re)
which is at the edge of this turmult. And pushing an update of Radare2
will break Cutter.
It i
I recently took ownership of Radare2 after it was orphaned,
unfortunately unknowing of the current turmult in the Radare2 project.
Now realizing that it has a dependent Fedora package Cutter (cutter-re)
which is at the edge of this turmult. And pushing an update of Radare2
will break Cutter.
It i
fre 2022-04-01 klockan 12:14 +0200 skrev Jonathan Schleifer:
> Has anyone seen or knows how to contact hno? hno maintains electrum
> and
> is unresponsive on bugs, PRs and direct e-mails.
I am around. But not very active at the computer at home. Expect a week
or two response time normally.
> H
60 matches
Mail list logo
