16:00:24 #startmeeting fpc 16:00:24 Meeting started Thu Apr 23 16:00:24 2015 UTC. The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:24 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:24 #meetingname fpc 16:00:24 #topic Roll Call 16:00:24 The meeting name has been set to 'fpc' 16:00:27 Howdy. 16:00:42 You must have been hovering over the middle button. 16:00:52 #chair tibbs 16:00:52 Current chairs: geppetto tibbs 16:00:59 ha 16:01:16 maybe I'm just a bot ;) 16:02:07 Sometimes I feel that way. Especially lately. Trying to figure out where all the time goes. 16:02:42 Hi 16:02:55 * racor is here 16:03:26 /me is around, though not on FPC 16:03:56 #chair mbooth 16:03:56 Current chairs: geppetto mbooth tibbs 16:04:01 #chair racor 16:04:01 Current chairs: geppetto mbooth racor tibbs 16:04:05 sgallagh: hey :) 16:04:29 limburgher orionp Rathann SmootherFr0gZ spot tomspur: FPC ping 16:04:57 Why do you ping spot? 16:05:19 he's still on the FPC 16:05:25 afaik 16:05:32 https://fedoraproject.org/wiki/Packaging_Committee?rd=Packaging:Committee 16:05:39 Says... no. 16:06:00 huh 16:06:15 * tomspur is here 16:07:40 I was looking at who to ping for the two meetings I ran badly, and was kind of wondering why he was in your list. 16:07:58 #chair tomspur 16:07:58 Current chairs: geppetto mbooth racor tibbs tomspur 16:08:14 Well we have quorum now 16:08:33 #topic Schedule 16:08:37 https://lists.fedoraproject.org/pipermail/packaging/2015-April/010604.html 16:08:51 #topic #525 Request for bundling exception: plotnetcfg, contains parson library 16:08:56 https://fedorahosted.org/fpc/ticket/525 16:09:17 Parson seems pretty big for a bundled thing. 16:09:35 And... they could always achieve their "copy the binary around" goal just by static linking, so I don't get it. 16:10:02 yeh, probably shouldn't have said shared library 16:10:26 I was initially heavily -1 … but I expected it to be bigger than 1k lines 16:10:30 For Fedora that really shouldn't matter. 16:10:35 so I'm somewhat on the fence, now 16:11:29 * lubko notes both the packager & the reviewer are on the channel now, in case anyone has questions not answered in the ticket 16:12:12 How do they feel about a static lib … keeps the ability to cp the binary to random debian systems or whatever, and doesn't bundle? 16:12:52 static linking is fine, except that parson is not really a shared/static library 16:13:23 it has it's own github 16:13:27 well, building it as a library would need parson upstream changes. at this point it wouldn't really help, since plotnetcfg uses a version that's different from released version of parson 16:13:57 jbenc: Please elaborate - I don't get it. 16:13:58 Would it really? I mean, you just compile it and run ar. 16:14:14 lubko: that will probably change in the next plotnetcfg version, as upstream merged the necessary features into the stable branch recently 16:14:52 racor: parson is a copylib, it's intended usage is to copy the two (rather small) files to your own project 16:14:54 lubko: So is plotnetcfg going to diverge from upstream parson forever? 16:15:28 racor: upstream parson does not provide any mechanism to build a .so file 16:15:29 jbenc: What you are saying to me reads: I don't want if 16:15:48 jbenc: not .so … .a 16:15:53 nor .a 16:16:08 of course, one can always write his own makefile 16:16:09 jbenc: as tibbs said, .a just means running ar after a normal compile 16:16:14 jbenc: You've convinced me to vote -1 16:17:34 lubko: ping ^ 16:17:50 geppetto: i don't think so 16:18:13 jbenc: Maybe extend the upstream parson Makefile to build the .so/.a? 16:18:14 geppetto: jbenc said they're going to converge with an new release 16:18:23 Ok, cool 16:18:29 what if we got an exception for versions we're packaging currently? 16:18:53 So how about a tmp. bundling exception for 1 release, and then make a static lib. of parson and use that? 16:18:55 tomspur: that's of course possible, there's no versioning upstream, though 16:18:58 and I'll promise to try to convince upstream to support building as a library and then we'll reconsider it with next release? 16:19:41 maybe the upstream will just be willing to add a version, or even a SONAME and we'll be set then 16:20:24 well, as we've said … just adding a ar command to create a static. lib. is almost no work 16:20:46 Anyway, seems like you are fine with my proposal … so I'm +1 on that 16:21:04 tibbs: mbooth: tomspur: racor: Vote? 16:21:09 I can +1 a temp exception. 16:21:21 But lets be clear on what "one release" means. 16:21:33 +1 for a temporal exception until the "next release" (whatever that is) 16:21:46 Sounds like after upstream merged the changes? 16:21:59 tibbs: Given we are close to F22, I assumed F22 16:22:20 +1 for exception for F22, but not for f23 16:22:22 Yeah, OK in F22, please fix by F23 release. 16:22:23 So, this is to be fixed properly in F23? 16:22:26 Ok 16:22:28 yeh 16:22:29 +1 for that 16:23:08 Please use Provides: bundled(parson) 16:23:30 * tomspur was talking about the "next release" of parson. If they are not numbering and copying around parson, it's hard to define a release there 16:23:50 Don't really need a release if you're using a static library. 16:23:54 orionp: You here? 16:24:23 Just call the package parson-0-1.foo.rpm. 16:24:32 thank you 16:24:46 tomspur: in general we don't go on upstream releases … as they might happen tomorrow or 10 years from now 16:25:13 Fedora releases are a bit more scheduled that way :) 16:25:40 tomspur: did you vote? 16:25:47 geppetto: yes, +1 16:25:57 ahh, I see it now, yeh 16:26:27 #action Allow tmp. bundling exception for F22, but use at least static. lib for F23. (+1:5, 0:0, -1:0) 16:26:41 #topic #524 static UID for ceph 16:26:48 https://fedorahosted.org/fpc/ticket/524 16:27:01 * orionp is here finally - user's machine was broken... 16:27:15 #chair orionp 16:27:15 Current chairs: geppetto mbooth orionp racor tibbs tomspur 16:27:22 Welcome 16:27:48 .fpc 524 16:27:49 geppetto: #524 (static UID for ceph) – fpc - https://fedorahosted.org/fpc/ticket/524 16:28:18 it's weird … the more I read this the more I want to give it -1 16:28:28 it seems like they really don't need it at all 16:28:45 and giving them a low uid isn't going to really help them anyway 16:28:53 It helps them in some situations. 16:29:08 But its limited and they automatically deal with the weird situations anyway. 16:29:18 yeh, that's what I mean 16:29:35 I have trouble believing they are saving much from not having to run the chown script 16:29:42 If they new in advance the systems between which they would swap the disks, they can just do ACLs. 16:30:48 I don't want to be a dick here, and of course all of the other distros are going to accommodate so we kind of look like asses. 16:31:10 But, you know, if they could get all distros to agree on what the UID would be, I think I'd go along with it. 16:31:30 But otherwise, I just don't see the point. 16:31:31 yeh, but at least debian are going to accommodate in a different (incompatible) way 16:31:40 yeh 16:31:50 Now, how many backing files are typically on a ceph volume? 16:32:01 Here before it was mentioned that the files were huge. 16:32:14 Which means there probably aren't very many of them, and a chmod wouldn't take very long. 16:32:16 yeh, I thought they weren't small 16:32:24 If there are millions then I would be more concerned. 16:32:54 yeh, and I guess they could have 100MB files and a 1TB drive 16:33:21 It still doesn't take long to chown 10K files. 16:33:27 yeh 16:33:37 Or setfacl once and be done. 16:33:44 ha 16:33:59 You really like ACLs huh ?:) 16:34:05 Who doesn't? 16:34:10 everyone else :) 16:34:17 OK, I mean, if you have NFS4 involved, your brain melts. 16:34:19 tibbs|w: Anyone who's ever tried to use them? 16:34:29 I find ACLs absolutely trivial to use, honestly. 16:34:51 I find it far more trivial to not use them :-D 16:34:53 Don't really see what's hard about them; I use them all over and they're great. 16:34:57 But anyway.... 16:35:09 I have made a little progress on the UID fixing thing. 16:35:40 The setup "maintainer" is amenable. 16:35:41 cool, you think it will be ready in the next couple of weeks? 16:36:00 Well, the support is in upstream anaconda. 16:36:09 And I actually have a hack that needs no support in anything. 16:36:18 is that going to be in F22? 16:36:24 No, 23 unfortunately. 16:36:55 But the pull request was at least merged. 16:36:59 * geppetto nods 16:37:11 The section is %pre-install. Runs immediately after filesystems have been created. 16:37:55 Anyway, for the hack, just spawn a subshell that loops waiting for /etc/passwd and the other three important files to exist, and then cat some extra lines onto them. 16:38:18 Immediate UID fixing, works in all releases, has been possible to do it all along. 16:38:30 I just never thought of spawning the subshell in the background in %pre. 16:38:52 So, they want this and they have to do it in kickstart? They're good. 16:39:23 Now, still doesn't help with installing from live media. Though maybe there's another way to deal with that; I haven't ever used any live media.. 16:39:39 Ever? :) 16:39:42 Nope. 16:39:43 Are ceph consumers really using live media? 16:40:08 maybe a dev. has it on his dev. box? 16:40:13 geppetto: To be fair, I've never installed from live media either :-) 16:40:13 The last time I installed from any form of media was, I think, RHL7.something. 16:40:25 But that was just a CD. 16:40:59 I only do PXE or boot from the PXE images on a stick. 16:41:02 wow … I feel like a newbie now :) 16:41:25 Even when I install my home machines. 100mb/s internet is fast enough. 16:41:55 yeh, I don't have anything close to that :p 16:42:13 Just crappy comcast. 16:42:19 * geppetto nods 16:42:29 mbooth: tomspur … what do you think? 16:42:32 Anyway, I don't think anyone's really +1 at this point for the ceph thing. 16:42:38 orionp: racor You too :) 16:42:58 But again if the distros can get together, I would go along in the spirit of cooperation. 16:43:03 yeh 16:43:11 Except that we already know that isn't going to happen, so I guess it's an empty offer. 16:43:14 I was +1 last week … assuming they couldn't fix it up 16:43:24 Maybe even if we can agree with suse; I haven't thought about it. 16:43:41 But now I know they can fix it up, and debian are going to use a number we can't give out 16:43:55 I also don't see the point 16:44:01 IIRC, I was at 0 last week. 16:44:05 I'm leaning against it, but not strongly 16:44:14 Maybe if they said the fixup would often take like 1 minute, and they really don't want it to take that long 16:44:29 * geppetto shrugs 16:44:49 There are lots of other filesystems (e.g. parallel) that build on top of other stores like this 16:45:38 Indeed. 16:45:44 And do they have the same goal of swapping disks? 16:45:55 Maybe we could give them all one UID? 16:46:01 (actually half serious) 16:46:09 And it just feels like a "nice to have" rather than critical need - and admins who care will enforce common UID on their own 16:46:41 orionp: I guess the goal is having it work "out-of-the-box" 16:47:13 #action We don't see the point, given that Debian won't be compatible and you have fixup scripts. If the fixup scripts take an annoying amount of time to run, then we might reconsider. 16:47:18 mbooth: yeh, but it does work 16:47:44 #topic #520 [Guidelines Draft] Per-Product Configuration Defaults v2 16:47:45 .fpc 520 16:47:45 https://fedorahosted.org/fpc/ticket/520 16:47:47 geppetto: #520 ([Guidelines Draft] Per-Product Configuration Defaults v2) – fpc - https://fedorahosted.org/fpc/ticket/520 16:47:55 sgallagh: this be you :) 16:48:20 /me perks up 16:48:33 So tibbs|w and I had a conversation after the meeting last week 16:48:59 We discovered that the macro was the wrong approach (since those are applied at build time and we needed this handled at %post script time) 16:49:16 * geppetto nods 16:49:35 Really it's just that the /etc/os-release is guaranteed to be sourceable. 16:49:36 tibbs|w also noted that we can import /etc/os-release directly, since it's formatted to be sourced by a bourne-compatible shell 16:49:40 Why did you change from the awk to just imprting the file? 16:49:54 Because that's the intended use of the file. 16:49:58 * geppetto nods … that's always going to be safe? 16:50:01 ok 16:50:32 I mean, if someone goes and makes random edits to it, who knows? But that's the case no matter what you do. 16:50:42 And it simplifies things, so why not? 16:50:55 so if I want to move from workstation to server … is that possible? 16:51:21 The scripts just overwrite the existing link, so it should "just work". 16:51:33 on the next upgrade? 16:51:42 If you change the VARIANT in /etc/os-release, of course you'll have to fix things manually or reinstall. 16:51:58 Though there could be a helper script that fixes up all of the links at any point, I guess. 16:51:59 geppetto: Technically or by policy? 16:52:08 But that would be out of the scope of the guideline. 16:52:23 Our official policy is that conversion between editions is unsupported except in one specific case 16:52:25 sgallagh: I wondered if it was a supported feature 16:52:37 sgallagh: and if so, what the packagers/users have to do to make it work 16:52:42 That's the cloud->server "Adopt your cattle" feature. 16:52:44 Actually, is there any way to determine packages which use this? 16:52:51 And that has to be done via a script maintained by the Cloud WG 16:52:59 Ugh … ok 16:53:02 Maybe toss in a Provides? 16:53:18 Maybe require /etc/os-release? 16:53:35 geppetto: That's provided by systemd, so it seems slightly redundant 16:53:52 yeh, I mean it more as documentation … but maybe that's a bad overload 16:53:53 Though... I should probably care about the container case where it may not exist... 16:54:26 Anyway, I'm +1 with this as is. We can always tweak if we want something to identify packages that have these per-product configs. 16:54:30 If the source fails, it should just be treated as "non-product" 16:54:44 Yeah, that does make sense. 16:54:50 /me will add :|| to the end of that line 16:54:52 Should be enough 16:54:56 sgallagh: it doesn't error out the scrtipt? 16:54:59 * geppetto nods 16:55:04 +1 with the ||: 16:55:16 What does the case statement do if VARIANT is empty? I can't remember that much shell. 16:55:38 Fixed 16:55:50 I've tested it. the * catches that 16:56:04 Cool. 16:56:07 Still +1. 16:56:32 * tomspur would have guessted, that you'd need "$VARIANT" instead of just $VARIANT 16:56:35 (Which was necessary for the non-productized case, since VARIANT doesn't exist in the file there) 16:56:40 Yet if it works, +1 16:57:17 do not question the parsing of bourne shell ;) 16:57:39 orionp: mbooth: racor: vote? 16:58:22 Well, ... I am undecided 16:58:35 racor: On what grounds? 16:58:38 racor: You have any questions? 16:59:03 I believe there are quite a few (minor) /bin/sh issues/mistakes lurking 16:59:33 You mean bashisms or something else? 16:59:35 I also do not like the idea of not having these scripts in macros 16:59:59 Not sure how much of it can be macro-ized. 17:00:00 racor: How would you macro-ize them? 17:00:14 The cases will be different depending on the package. 17:00:15 I've tried, but I can't come up with a macro that's any shorter than the scripts 17:00:21 I mean useless quotes, missing quotes and likely useless ||: 17:00:46 Well, yeah, rm -f doesn't need ||:, but it's not really an issue. 17:00:50 e.g. case $variant should be be case "$variant" 17:01:01 sgallagh: I think you definitely need to quote $VARIANT in the case statement 17:01:11 Wouldn't hurt, I guess. 17:01:15 Because e.g. "case in "Server") ;; *) ;; esac " is not valid syntax 17:01:17 while the quotes in "Server") are useless 17:01:36 mbooth: I can do that. It works today with firewalld without it, but I have no problems 17:01:46 (with changing it) 17:01:46 Those seem more like bashisms … but can't hurt 17:01:58 can't hurt to change it, that is 17:02:00 sgallagh: I am surprised it works for non-product case, wierd 17:02:04 no they are useless quotes, not bashims 17:02:30 by bashism, I mean bash would always do the right thing anyway … while dsh or something might not 17:02:37 the difference shows when $variant contains white spaces 17:02:50 case $variant will go up in smoke 17:02:54 ahh 17:02:55 oh, interesting 17:03:05 OK, that's a potential bug then 17:03:11 The format guarantees that there won't be whitespaces. 17:03:22 But, sure, defensive programming is OK. 17:03:26 * geppetto nods 17:03:26 oh true. 17:03:38 It would have to be quoted in /etc/os-release if there was whitespace 17:03:53 But you'd still have to quote the use of the variable in that case. 17:04:00 /me nods 17:04:01 As with PRETTY_NAME. 17:04:11 another presumable bug "if [ \! .... ]" .... 17:04:11 Anyway, nitpicking aside, I am okay to +1 this 17:04:33 ok, that's +4 17:04:36 Yeah, I wasn't sure if the '!' needed to be backwhacked there, but it doesn't hurt. 17:04:36 Isn't it really /usr/lib/os-release? 17:04:43 racor: DId I miss the backwhack somewhere? 17:04:49 I thought I removed all of those 17:04:55 orionp: /etc/os-release has to be canonical. 17:05:10 if [ \! -e %{_sysconfdir}/firewalld/firewalld.conf ]; then 17:05:15 That's the API. /usr/lib/os-release may be implementation-specific 17:05:23 Ah, thanks 17:05:50 racor: what page are you looking at? 17:05:53 if [ \! -e %{_sysconfdir}/foo/foo.conf ]; then 17:06:03 https://fedoraproject.org/wiki/User:Sgallagh/Per-Product_Configuration_Packaging_Draft 17:06:11 racor: Are you looking at an old version? 17:06:12 That's the latest page, and doesn't contain those. 17:06:14 https://fedoraproject.org/w/index.php?title=User:Sgallagh/Per-Product_Configuration_Packaging_Draft&diff=next&oldid=410297 17:06:33 ahh, yeh, the oldid= means you aren't getting the updates 17:07:21 OK ;-) 17:07:41 so quotes belong around $VARIANT but not Server in the case,right? 17:08:01 sgallagh: Yes 17:08:04 sgallagh: yes. 17:08:12 orionp: racor: vote? 17:08:16 OK, and I'll eliminate ||: from the rm -f lines 17:08:32 I'm basically +1, some comments: 17:08:47 * geppetto waits to see some weird error in rm -f to make that fail now ;) 17:09:01 Are the rm -f's necessary? Won't the ln -sf later take care of things? 17:09:11 Can ln -sf fail? 17:09:18 If it can't write to the filesystem.... 17:09:29 Some ln -sf 's don't have || : 17:09:33 orionp: I'm overly-paranoid. I've seen ln -sf not update the symlink from time to time 17:09:39 orionp: I noticed. Refresh 17:10:09 (and just spotted one more) 17:10:44 looks good +1 17:10:50 tibbs|w: Yeah, just today, I've seen filesystems going r/o underneath of dnf 17:11:15 But then, the rm -f calls will fail as well. 17:11:18 Yeah 17:11:40 I can remove that from the example if you want. 17:11:45 I'm afraid I have to run shortly 17:11:48 It's probably unnecessary 17:11:48 +1, but I am still having uneasy feeling on "no macro" 17:11:52 So, it's a question of just how defensive you want to be. Personally I don't think adding four extra characters at the end makes much difference if the script is that long. 17:12:01 mbooth: no problem … we can end after this ticket 17:12:06 But I +1 sgallagh's proposal 17:12:21 If the rm's and ln's are sufficiently identical, they could be macro'ized. 17:12:35 tibbs|w: I just purged the rm's from the example 17:12:43 Cool. 17:12:52 If they're necessary, it's an 'ls' bug 17:12:57 We shouldn't be codifying that :) 17:12:58 ln 17:13:00 BUt, yeah. 17:13:09 ... because right now, AFAIS, we don't have any means to trace src.rpm which utilize this mechanism 17:13:14 oops, yeah. ln 17:14:01 racor: Provides: variant_config(Server) ? 17:14:07 Would that work? 17:14:24 sgallagh: What does the Server bit mean? 17:14:36 Differentiating which Variant it applies to 17:14:47 And how does that work? 17:14:51 So if there were different ones for all three products, it would provide them separately? 17:14:54 sgallagh: Dunno if this would work, but it's something into the directions I was thinking about 17:15:08 Provides: variant_config(Workstation) 17:15:09 Provides: variant_config(Cloud) 17:15:17 For tracking purposes? 17:15:19 Ahh, so in the firewalld example it would provide variant_config(Server) and variant_config(Workstation) ? 17:15:28 sgallagh: that seems great, to me 17:15:34 Yes 17:15:41 In each of the appropriate subpackages 17:16:24 I kind of doubt that this will work with the source os-release trick 17:16:46 sorry, ignore the subpackages comment. 17:16:55 Cobwebs in the brain. That was the old implementation 17:16:59 ok, cool … was trying to find out wtf you meant by that :) 17:17:04 * geppetto nods 17:17:05 tomspur: What won't? 17:17:43 tomspur: It will at least give us a list of any package that *may* be using a variant configuration 17:17:44 sgallagh: Can you source a file and do %if and %elses based on environment variables? 17:17:49 yes 17:18:19 oh sorry 17:18:21 tomspur: By %if do you mean at rpmbuild time? 17:18:22 %if? not sure 17:18:25 Probably not 17:18:37 yes, I mean the rpmbuild %if 17:18:40 How is that relevant? All of this is happening at %posttrigger execution 17:18:50 err %posttrans 17:19:01 sgallagh: I think he's just confused about your subpackage comment 17:19:09 seems so :) 17:19:12 Maybe. I did say to ignore it. 17:19:20 I was misremembering that I eliminated that piece of hackery 17:19:28 ok :) 17:19:37 * geppetto nods … ok, so … latest version … I think we are at +5 or +6 … anyone disagree? 17:20:14 although I don't see the provides yet 17:21:41 geppetto: Updated now 17:21:45 Please refresh 17:21:50 (sorry, was still typing) 17:22:29 ok 17:23:18 racor: You +1? 17:23:59 * tomspur also needs to run in a few minutes 17:24:15 "(01:11:48 PM) racor: +1, but I am still having uneasy feeling on "no macro"" 17:24:19 #action Per-Product Configuration Packaging (+1:6, 0:0, -1:0) 17:24:29 Thanks! 17:24:29 #topic Open Floor 17:24:51 Ok, anything before I close and everyone has to run anyway ;) 17:24:54 Nothing from me. 17:26:17 ok, I'll give it until 13:30 then and close 17:28:22 I assume someone will replace the old guideline with this one? 17:28:29 /me doesn't have privilege. 17:30:15 Yeh, tibbs seems to be doing that stuff atm. 17:30:21 Yeah, I'll write it up. 17:30:25 Thank you 17:30:26 but anyone of us can do it 17:30:31 I have time this evening. 17:30:42 #endmeeting