(prepared manually, MeetBot-generated version to hopefully follow later)
* ticket 830 define requirements for secondary arch promotion
NOTE: https://fedorahosted.org/fesco/ticket/830#comment:11 sums up
the situation correctly.
* ticket #873 F18 Feature: 256 Color Terminals -
https://fedoraproject.org/wiki/Features/256_Color_Terminals
AGREED: Feature 256 Color Terminals deferred pending discussion on devel@ (+7)
ACTION: mjg59 to start discussion
* ticket #874 F18 Feature: OpenStack Folsom -
https://fedoraproject.org/wiki/Features/OpenStack_Folsom
AGREED: Feature OpenStack Folsom is approved (+9)
* ticket #875 F18 Feature: targetd -
https://fedoraproject.org/wiki/Features/targetd
AGREED: Feature targetd is approved (+9)
* ticket #876 F18 Feature: libstoragemanagement -
https://fedoraproject.org/wiki/Features/libstoragemgmt
AGREED: Feature libstoragemgmt is accepted, please merge it with targetd (+9)
* Next week's chair:
NOTE: The meeting on July 2 is canceled for lack of quorum
ACTION: t8m will chair the meeting on July 9th
* Open floor:
NOTE: Heads up - https://fedoraproject.org/wiki/Features/SecureBoot
was proposed
Full meeting log is below.
Mirek
mitr: #startmeeting FESCO (2012-06-25)
#meetingname fesco
#chair notting nirik mjg59 mmaslano t8m pjones mitr limburgher jwb
#topic init process
zodbot: Meeting started Mon Jun 25 17:00:07 2012 UTC. The chair is
mitr. Information about MeetBot at http://wiki.debian.org/MeetBot.
zodbot: Useful Commands: #action #agreed #halp #info #idea #link #topic.
- Nastavit téma na: (Meeting topic: FESCO (2012-06-25))
zodbot: The meeting name has been set to 'fesco'
zodbot: Current chairs: jwb limburgher mitr mjg59 mmaslano nirik
notting pjones t8m
- Nastavit téma na: init process (Meeting topic: FESCO (2012-06-25))
* notting is here
t8m: hello
pjones: hi
jwb: hi
mitr: nirik told us last time that he won't be able to come,
limburgher voted in tickets.
mjg59: Hi
mitr: mmaslano: here?
mmaslano: yes, hi
mitr: Thanks, let's start...
mitr: #topic #830 define requirements for secondary arch promotion
.fesco 830
Just a quick check:
Robyn had some questions about the outcome of this ticket and the
feature - https://fedorahosted.org/fesco/ticket/830#comment:9
Are there any objections to the summing up by Tomas (
https://fedorahosted.org/fesco/ticket/830#comment:11 ) ?
- Nastavit téma na: #830 define requirements for secondary arch
promotion (Meeting topic: FESCO (2012-06-25))
zodbot: mitr: #830 (define requirements for secondary arch promotion)
– FESCo - https://fedorahosted.org/fesco/ticket/830
mjg59: Nope
jwb: no
pjones: sounds right
notting: that ounds correct
* mitr assumes that's good enough
mitr: #topic #873 F18 Feature: 256 Color Terminals -
https://fedoraproject.org/wiki/Features/256_Color_Terminals
.fesco 873
limburgher was +1 in the ticket
kevin was +1 in the ticket
- Nastavit téma na: #873 F18 Feature: 256 Color Terminals -
https://fedoraproject.org/wiki/Features/256_Color_Terminals (Meeting
topic: FESCO (2012-06-25))
zodbot: mitr: #873 (F18 Feature: 256 Color Terminals -
https://fedoraproject.org/wiki/Features/256_Color_Terminals) – FESCo -
https://fedorahosted.org/fesco/ticket/873
mitr: I like the idea in general, not sure about the specifics
mitr: * Apparently there's no simple way to set TERM=something_old in
~/.ssh/config
mjg59: Sure would be nice if this were something that could be
negotiated between endpoints
mitr: * Using /etc/profile.d/* sounds like too big a hammer, but
perhaps not worth arguing about
mjg59: But fixing that would be breaking decades of UNIX tradition, I'm sure
pjones: yeah, not really solid on the implementation
pjones: I like the idea
* mjg59 remembers the bad old days of XTERM-DEBIAN
notting: that profile.d looks ... wrong
jwb: i'm entirely ambivalent
notting: in that it automatically assumes anything you use that
supports xterm also supports this
pjones: yeah, that's not great.
mjg59: Yeah. Seems like we should be changing the terminal emulators.
mitr: Hm, that profile.d would trigger even when ssh-ing from a
non-Linux system, wouldn't it? And in a way that makes it non-trivial
to override.
notting: mitr: yes.
mjg59: How about we punt this back to devel@ for further discussion of
the implementation?
jwb: sounds good to me
mmaslano: fine
t8m: mjg59, +1
mitr: +1 It will probably generate some noise, but it should help with
the right direction.
notting: +1
mjg59: I can bring it up
mmaslano: +1
mjg59: Might as well take responsibility for even more pointless argument
jwb: you're very good at that
mitr: #agreed Feature: 256 Color Terminals deferred pending discussion on devel@
mjg59: Life skills and all that
mitr: #action mjg59 to start discussion
mitr: #topic #874 F18 Feature: OpenStack Folsom -
https://fedoraproject.org/wiki/Features/OpenStack_Folsom
.fesco 874
limburgher was +1 in the ticket
kevin was +1 in the ticket
* mitr is +1
jwb: this is basically a version bump of an existing stack in Fedora, right?
mitr: jwb: seems so
mjg59: +1
jwb: seems very buzz wordy these days, so +1
t8m: +1 with the feature process disclaimer
t8m:
mmaslano: +1
notting: +1 for folsom packaging blues
pjones: mjg59: I'm +1 to that
pjones: With at the very least a summary of things we've just listed
that we'd like to see addressed
pjones: +1
mitr: #agreed Feature OpenStack Folsom is approved (+9)
mitr: #topic #875 F18 Feature: targetd -
https://fedoraproject.org/wiki/Features/targetd
.fesco 875
limburgher was +1 in the ticket
kevin was +1 in the ticket
* pjones +1
mmaslano: I don't like the name much and I wonder if they speak with
other related projects...
mmaslano: but none of this is blocker
mitr: mmaslano: AFAICT this doesn't directly duplicate any other work
in the storage space
notting: seems fine, +1. this is only iscsi target, not fcoe target?
* mitr was warned about running a web server as root, but is +1 to the idea
pjones: notting: AIUI yeah
pjones: but I may not UI
jwb: there was suggestion of combining this and libstoragemgmt
t8m: +1 to the idea with reservations about the current
implementation, but that can be fixed
mmaslano: +1
jwb: also... we're voting backwards
pjones: jwb: well, they list libstoragemgmt as a dep
jwb: right
notting: so this is the userspace equivalent of lio?
jwb: so we should have, you know, voted on that first
jwb: but hey, whatever
mjg59: +1
mitr: notting: Isn't it a complement to lio - lio providing the iscsi
target, and this providing LUN mgmt?
notting: mitr: that makes more sense now that i read it
mitr: jwb?
jwb: i guess +1
jwb: which means i'm +1 to the next one too apparently
mitr: #agreed Feature targetd is approved (+9)
mitr: #topic #876 F18 Feature: libstoragemanagement -
https://fedoraproject.org/wiki/Features/libstoragemgmt
.fesco 876
limburgher was +1 in the ticket
kevin was +1 in the ticket
Both suggested merging this with the targetd feature
mitr: (I'm sorry about the ordering, I missed the dependency)
notting: +1 to feature, +1 to merge
jwb: +1 to feature, +1 to merge
mitr: +1 to feature, and +1 to merge (given that this situation is
exactly the same as hawkey/dnf last week)
pjones: yeah, I can be +1
t8m: +1 to merge with previous feature (which we accepted)
pjones: to merge as well
mmaslano: +1 for merge
mjg59: +1
mitr: "Feature libstoragemgmt is accepted, suggested to merge with
targetd", is that right?
jwb: yep
pjones: I dunno about "suggested"; we think they should do it.
pjones: I think we're just telling them to do so.
t8m: "Feature libstoragemgmt is accepted, please merge it with
targetd" - we can ask politely
pjones: yes
mitr: #agreed Feature libstoragemgmt is accepted, please merge it with
targetd (+9)
mitr: #topic Next week's chair
* pjones won't be here next week
* mmaslano probably won't be here
* t8m won't be able to attend either
* notting will not be here as well
pjones: So, er, will we have quorum?
jwb: i will not be here
mjg59: I can be, but it doesn't sound useful
pjones: aand that's a no
pjones: I propose not meeting next week.
mitr: And won't be here next wee either
t8m: I can take the chair on 9th July
mitr: #note The meeting on July 2 is canceled for lack of quorum
mitr: #action t8m will chair the meeting on July 9th
mitr: #topic Open Floor
mitr: Anything?
pjones: I've got one
pjones: I don't need voting right now, but since it was put in state
friday and I'd like attention on it earlier rather than later, I
figured I'd make sure everybody here is aware of
https://fedoraproject.org/wiki/Features/SecureBoot
pjones: mjg59 and I intend to demo this at the UEFI Summer Summit the
week of the 16th of July.
pjones: Put in "FeatureReadyForWrangler" state even
t8m: pjones, Scope seems to be "undefined" yet?
jwb: "whole distro" ?
jwb: big sky isn't undefined
t8m: is it really?
pjones: t8m: I really think the field is completely bogus
t8m: shouldn't affect much of userspace
pjones: But let's not argue about that since it's entirely tangential, okay?
pjones: I mean, there's a giant table in "current status" that defines
the scope pretty well
notting: pjones: exciting. i look forward to the polite reserved
discussion that this is likely to bring.
t8m: then you can point at it
t8m: Like see the table in Status
pjones: t8m: sure, will do.
mmaslano: I guess the biggest question is if we want to go this way
mitr: pjones: From a first look, no mention of user-space drivers -
nothing is affected?
mjg59: Some bits of userspace stop working
mjg59: Not a lot that can be done about that
mitr: I'm not sure what the deciding factors will be, but knowing what
will break might be relevant
jwb: mitr, userspace drivers as in UIO?
mjg59: dmidecode's going to break. Because using /dev/mem is a stupid
thing to do.
mitr: jwb: I was more thinking about display drivers and things like
that, which access PCI registers directly
pjones: mjg59: could be reworked as a kernel-level thing though
mjg59: Should be, yes
pjones: though that may be another feature
mjg59: mitr: Only ones left are vesa and via, and vesa's obviously not
a concern with UEFI
jwb: mitr, do we have many of those left supported in Fedora?
mitr: Do we want an explicit notification to devel@ ?
notting: mjg59: surely someone could extend the dmi crud in sysfs
notting: mitr: well, that will come in the meeting announcement
mjg59: notting: Someone could!
pjones: notting: yeah, that's what I meant above
notting: mjg59: * Copyright 2007, Lennart Poettering. ok then!
* mitr goes for
mitr: #note Heads up -
https://fedoraproject.org/wiki/Features/SecureBoot was proposed
pjones: Will have at some point already been proposed yes
notting: mjg59: pjones: nm, we have /sys/firmware/dmi
t8m: I have no problem with the implementation part, I have with the
verisign signed but that is rather Fedora Board question to resolve
mmaslano: yeah, it might be good to file a ticket for them
mitr: t8m: Will you file a ticket with specific concerns, then?
pjones: Anyway, it's not in the correct state to vote on it yet, and I
think it does need to be on our announced agenda before we discuss it
in earnest, but I did want to make sure everybody was aware that this
was coming pretty soon.
mitr: Anything else for open floor?
* mitr will close the meeting in 2 minutes if not
t8m: mitr, I think there are some people who discussed it on devel@
who would be able to better formulate the ticket
pjones: t8m: well, if you don't want to, and they haven't...
mmaslano: pjones: well, I thought feature owners will do it
t8m: pjones, I'll probably ask them to file it and if they don't I'll do it
pjones: mmaslano: the feature owners aren't the people asserting that
the board needs to weigh in?
mitr: mmaslano: It's not clear to me what the board question is
exactly, isn't that better left to someone who wants to ask the board?
mjg59: Well I guess someone probably needs to ask the board to cut a
check for $99
mjg59: Since we don't have a budget of our own
pjones: mjg59: I'd have guessed we'd ask FPL for that, but sure.
mjg59: But we might as well deal with the feature first
t8m: pjones, it might also be that the ticket was already filled - I
can't know as the board tickets are not public
nb: no need for board ticket, just get with robyn to pay the $99
nb: assuming they will take a credit card
jwb: er...
nb: (if all the board ticket is for is asking for money)
notting: but 99% of eng. work is orthogonal to "do we get this bit
signed with that"
pjones: right. And we can implement scheme #2 without that part.
* mitr guesses no other open floor items will be coming...
mitr: #endmeeting
mitr: Thanks all!
mjg59: Did we pick someone to chair on the 9th?
mjg59: Oh, sorry, yes
mjg59: t8m: Sorry, missed you saying that
t8m: hmm seems the meetbot got stuck?
nb: bot died
nb: and then came back
mitr: Oh well
nb: file a ticket on the infra ticket with an attachment of the log
for this meeting
nb: and we can re-process it so it will show up on the meetbot site
mitr: nb: Thanks, will do.
Hi,
Starting from the version 0.4 pylibacl Python extension changed its
license from GPLv2+ to LGPLv2+. As the new license is less restrictive I
don't see any negative implications.
Regards
Marcin
With OpenStack there are quite a large number of daemons per host, each
of which has their own .service unit file.
openstack-glance-api.service
openstack-glance-registry.service
openstack-keystone.service
openstack-nova-api.service
openstack-nova-cert.service
openstack-nova-compute.service
openstack-nova-network.service
openstack-nova-objectstore.service
openstack-nova-scheduler.service
openstack-nova-volume.service
openstack-swift-account.service
openstack-swift-container.service
openstack-swift-object.service
openstack-swift-proxy.service
Currently our OpenStack instructions have such fun commands as:
# for svc in api registry; do sudo systemctl start openstack-glance-$svc.service; done
# for svc in api objectstore compute network volume scheduler cert; do sudo systemctl start openstack-nova-$svc.service; done
What I'd like to be able todo is setup some kind of grouping, so that
you can just start/stop/check status of everything in simple commands
like:
# sudo systemctl start openstack-nova.target
# sudo systemctl status openstack-nova.target
# sudo systemctl stop openstack-nova.target
My naive attempt to make this work was todo
- Create a openstack-nova.target containining
[Unit]
Description=OpenStack Nova
WantedBy=multi-user.target
- Edit each of openstack-nova-XXX.service to change
WantedBy=multi-user.target to WantedBy=openstack-nova.target
But after doing this, stopping/starting the target has no effect on the
running state of units I associated with it. Also I'd like starting/stopping
XXX.target to take account of the enablement state of the individual
XXX-YYY.service files. eg so I can disable say, openstack-nova-network.service
on a host, but still use openstack-nova.target to bulk stop/start all the
other services that are enabled.
Either I'm missing some config change, or what I'm attempting is just not
the kind of functionality that .target files are intended to offer ?
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Hello all,
I suspect this is going to be a weird problem to figure out.
Relevation password manager
https://admin.fedoraproject.org/pkgdb/applications/Revelation Password Manager
Has been found to be unsafe.
http://knoxin.blogspot.co.uk/2012/06/revelation-password-manager-considered…
I would hope it gets fixed at some future point, but something should
probably be done in the short term.
I'm not sure what Fedora precedent is on issues like this. We can't
really revoke such a package, and we also want to give users a warning
to use a different password manager (I'm not entirely sure how to best
do this).
Does anyone have any thoughts?
Thanks.
--
JB
>From Fedora 18 on, Fedora will no longer include the freedom to for a
user to create a fork or respin which is the technological equal of
the Project's output. Instead, this freedom will be available
exclusively from Microsoft for $99 under unspecified conditions.
I wish this were a joke.
http://mjg59.dreamwidth.org/12368.html
Jaroslav Reznik wrote:
> Other possibility is to go directly to 1 GiB but we are not sure
> there's advantage (at least not now).
You would probably want to make the target 1 GB (SI units), not 1 GiB. The
capacity of thumb drives is measured in SI units, so a "1 GB" thumb drive really
is 1000^3 bytes, not 1024^3. (They start out with the binary capacity, but some
fraction of that is used for overhead, leaving some amount between the SI and
binary size. Hence the advertising refers to the SI size.)
> So we'd like to hear from rel-engs, QA etc. what's theirs position
> here.
AFAIK the only QA issue would be getting notified as to what the new target is,
so the size tests can be modified. You probably also want to create a page
https://fedoraproject.org/wiki/Releases/18/Spins with the new size. The
corresponding page currently exists for 16, but not 17 or 18.