[Test-Announce] 2013-08-19 @ 15:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2013-08-19 # Time: 15:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.freenode.net Greetings testers! It's meeting time again on Monday! I'm hoping we can sign off on the changes I proposed for ARM and Cloud testing, and look at where we stand ahead of F20 Alpha TC1. This is a reminder of the upcoming QA meeting. Please add any topic suggestions to the meeting wiki page: https://fedoraproject.org/wiki/QA/Meetings/20130819 The current proposed agenda is included below. == Proposed Agenda Topics == 1. ARM and Visible Cloud validation process change review 2. Fedora 20 Planning 3. Open floor -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
(+libcamel) Re: (+libebackend, libedataserver) Re: evolution-data-server soname version bump for libedata-book/libedata-cal next week (3.9.90 release)
On Fri, 2013-08-16 at 16:47 +0200, Milan Crha wrote: > I've just committed a fix which changes soname version also for > libebackend and libedataserver. Like before, whatever I'll be able to > rebuild I will rebuild. Hi again, I'm sorry, but there was done an API change in libcamel at the very last moment too, thus this one is affected as well. Like before, whatever I'll be able to rebuild I will rebuild. Bye, Milan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Scala package owner unresponsive
On Sun, Aug 18, 2013 at 9:35 PM, Will Benton wrote: > (1) As far as I can tell, the package for Scala 2.9.2 on F19 (2.9.2-2) has > broken dependencies; I can't install it via yum on my new F19 install. Is > this the case for anyone else? If so, wouldn't it be best to have a working > Scala 2.9 package in F19 and introduce 2.10 in a later release? Version 2.9.2-4 was built for F-18, but was never built for F-19 or F-20. The changelog entries for -3 and -4 say: * Wed Jan 23 2013 Jochen Schmitt - 2.9.2-4 - Fix multiuser issues with fsc on /tmp/scala-devel directory (#903160) * Sun Nov 25 2012 Jochen Schmitt 2.9.2-3 - Fix OSGI dependency issue Regards, -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Scala package owner unresponsive
On two related notes, (1) As far as I can tell, the package for Scala 2.9.2 on F19 (2.9.2-2) has broken dependencies; I can't install it via yum on my new F19 install. Is this the case for anyone else? If so, wouldn't it be best to have a working Scala 2.9 package in F19 and introduce 2.10 in a later release? (2) I'm interested in hearing from folks who are using Scala on Fedora (or who have strong opinions about what Fedora should look like with more Scala) because I've recently been trying to package sbt (as a first step to getting more ecosystem projects into Fedora). best, wb - Original Message - > From: "Jochen Schmitt" > To: codebl...@fedoraproject.org, "Development discussions related to Fedora" > > Sent: Wednesday, August 14, 2013 11:33:32 AM > Subject: Re: Scala package owner unresponsive > > On Wed, Aug 14, 2013 at 07:12:32AM -0400, Ricky Elrod wrote: > > > I would like to take over this package and update it to 2.10.x for > > Fedora 21 (or possibly 20, though it wouldn't be an official "Change", > > because we're past the proposal deadline). > > If you have a working package for scala you may send me it, so I may > commit it into the repository and initiate the update for F19. > > As a co-maintainer I have tried to create a package for scala-2.10.x > without success. I was able to built the package locally, but the > build failed on koji. That is the reason, that the current state of > the scala git repository on Fedora is in a accident state. > > Best Regards: > > Jochen Schmitt > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: BlueZ Status in Fedora.
On Sun, Aug 18, 2013 at 02:28:34PM -0700, Ryan Rix wrote: > Basically we ship Fedora 20 in a state where one only of our major desktop > environments supports bluetooth in a stable fashion? That seems kind of like > a > disaster waiting to happen. The current release blocking desktops are Gnome and KDE. If those are broken then F20 doesn't ship - if they're working, it ships. It'd be unfortunate to ship a release that doesn't support the non-blocking desktops, but (right now) it's fundamentally up to them to provide the development effort to ensure that they have a full feature set. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: BlueZ Status in Fedora.
On Sun, Aug 18, 2013 at 11:28 PM, Ryan Rix wrote: > On Sun 18 August 2013 10:00:22 Kevin Fenzi wrote: >> On Wed, 14 Aug 2013 12:40:54 +0200 >> >> Rave it wrote: >> > I don't see that adding a bluetooth-panel-applet package is easy for >> > mate/xfce/lxde. First tests shows me that the removed panel code from >> > gnome-bluetooth isn't independent from the the rest of the code. I >> > quess for this reason the gnome dev didn't >> > remove /usr/lib64/gnome-bluetooth/libgnome-bluetooth-applet.so.0, >> > which is in latest upstream. >> > >> > Ok, i need really help to create such a package. >> > >> > But there is also another simple solution >> > gnome-bluetooth dev should add the removed (fallback) panel applet >> > code back. I'm pretty shure that is more easier for someone who knows >> > the code to do that. >> > >> > If gnome-bluetooth is the only client after the bluez5 switch which >> > is working in fedora, than it should be work for all desktops, imo. >> > >> > So adding the applet back would be a noble gesture from gnome to >> > other desktops ;) >> > >> > PS: i think cinnamon is also affected, because so far i know use >> > cinnamon blueman code in the momment. But i'm not shure in this point. >> >> I've exchanged some emails with the author of >> https://github.com/ncopa/xfce-bluetooth >> >> Unfortunately, the code there is in very early alpha stage. It doesn't >> do a whole lot yet. He's happy to have any help implementing things, >> but makes no promises as to when things will be usable. >> >> This applet depends on vala and the xfce-vala bindings, so I am not >> sure if it would work for other desktops, but its possible that it >> could. >> >> If anyone would be interested in helping out with this applet, please >> contact the maintainer. >> >> For Xfce, we could use this if it becomes usable in time, or we could >> use some other systray producting applet, or we could just not support >> bluetooth from the desktop for this release. ;( > > It sounds like BlueZ5 is not ready for Fedora, betwen the "early alpha" XFCE > code, and shipping git BlueDevil, mate and cinnamon don't appear to work with > it ... > > Basically we ship Fedora 20 in a state where one only of our major desktop > environments supports bluetooth in a stable fashion? That seems kind of like a > disaster waiting to happen. Well the problem is that we have way to many desktops (more desktops then resources). We can't delay changes until every desktop catches up (it basically means we can't move on with stuff at all). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: BlueZ Status in Fedora.
On Sun 18 August 2013 10:00:22 Kevin Fenzi wrote: > On Wed, 14 Aug 2013 12:40:54 +0200 > > Rave it wrote: > > I don't see that adding a bluetooth-panel-applet package is easy for > > mate/xfce/lxde. First tests shows me that the removed panel code from > > gnome-bluetooth isn't independent from the the rest of the code. I > > quess for this reason the gnome dev didn't > > remove /usr/lib64/gnome-bluetooth/libgnome-bluetooth-applet.so.0, > > which is in latest upstream. > > > > Ok, i need really help to create such a package. > > > > But there is also another simple solution > > gnome-bluetooth dev should add the removed (fallback) panel applet > > code back. I'm pretty shure that is more easier for someone who knows > > the code to do that. > > > > If gnome-bluetooth is the only client after the bluez5 switch which > > is working in fedora, than it should be work for all desktops, imo. > > > > So adding the applet back would be a noble gesture from gnome to > > other desktops ;) > > > > PS: i think cinnamon is also affected, because so far i know use > > cinnamon blueman code in the momment. But i'm not shure in this point. > > I've exchanged some emails with the author of > https://github.com/ncopa/xfce-bluetooth > > Unfortunately, the code there is in very early alpha stage. It doesn't > do a whole lot yet. He's happy to have any help implementing things, > but makes no promises as to when things will be usable. > > This applet depends on vala and the xfce-vala bindings, so I am not > sure if it would work for other desktops, but its possible that it > could. > > If anyone would be interested in helping out with this applet, please > contact the maintainer. > > For Xfce, we could use this if it becomes usable in time, or we could > use some other systray producting applet, or we could just not support > bluetooth from the desktop for this release. ;( It sounds like BlueZ5 is not ready for Fedora, betwen the "early alpha" XFCE code, and shipping git BlueDevil, mate and cinnamon don't appear to work with it ... Basically we ship Fedora 20 in a state where one only of our major desktop environments supports bluetooth in a stable fashion? That seems kind of like a disaster waiting to happen. Ryan -- Ryan Rix http://rix.si signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Merging freediams into freemedforms
On Sat, 17 Aug 2013 23:05:48 +1000, Ankur Sinha wrote: > > Hi, > > I maintain two packages for the fedora-medical SIG that fall under the > "freemedforms[1]" project. At the moment, these are packaged separately: > > 1. freemedforms[2]: provides freemedforms-emr and pulls in freediams > 2. freediams[3] > > Now, freemedforms-emr and freediams are both built from the same source, Since Fedora package git has been changed already, I've had a look at the f18 branch: $ cat freediams/sources e014e81b349ef5d41bdb956653fb18ab freemedformsfullsources-0.7.5.tgz $ cat freemedforms/sources e014e81b349ef5d41bdb956653fb18ab freemedformsfullsources-0.7.5.tgz ??? _Why_ has it been done like that? > and use the same internal libraries. Currently, I first build > freemedforms-emr and the common libraries (spec[4]) and then build > freediams (spec[5]), pointing to these libraries. Is it strictly required to build stuff from freemedforms src.rpm _before_ freediams could be built from the same tarball? Would it have been possible to build both from within a single src.rpm? > Recently, with the 0.9.0-beta1 release, upstream sent me a new spec and > suggested I use one spec to build both freedmedforms and freediams, and > provide freediams as a subpackage. > > I've built freemedforms already, and I'm in the process of updating > freediams now. > > I think it's a good idea, since they'll always move hand in hand. The > build process will be simpler, and so will maintaining the package and > updates. > > What do you folks think? Should I go ahead and retire(obsolete) > freediams and provide it as a subpackage in freemedforms? I don't see > any issues with this, but wanted to consult you folks to be sure before > I go ahead and make the changes. Of course! If that hasn't been possible before and now _is_ possible with 0.9.0-beta1, it's the better choice than duplicating the source tarball. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [ACTION REQUIRED] Retiring packages for Fedora 20 v2
2013/8/16 Bill Nottingham > > > $ koji list-tagged --latest f20 | grep fc1[4-8] > > Actually, now that I re-read what we did before, for F-20 we'd block things > that have failed to build since *before* F-18, i.e., those with fc17 or > earlier dist tags. > > Which shortens the list to: > ... This misses packages that don't use %dist, like tiobench, which has not been built in the F18, F19 and F20 mass rebuilds it seems. - Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: BlueZ Status in Fedora.
On Wed, 14 Aug 2013 12:40:54 +0200 Rave it wrote: > I don't see that adding a bluetooth-panel-applet package is easy for > mate/xfce/lxde. First tests shows me that the removed panel code from > gnome-bluetooth isn't independent from the the rest of the code. I > quess for this reason the gnome dev didn't > remove /usr/lib64/gnome-bluetooth/libgnome-bluetooth-applet.so.0, > which is in latest upstream. > > Ok, i need really help to create such a package. > > But there is also another simple solution > gnome-bluetooth dev should add the removed (fallback) panel applet > code back. I'm pretty shure that is more easier for someone who knows > the code to do that. > > If gnome-bluetooth is the only client after the bluez5 switch which > is working in fedora, than it should be work for all desktops, imo. > > So adding the applet back would be a noble gesture from gnome to > other desktops ;) > > PS: i think cinnamon is also affected, because so far i know use > cinnamon blueman code in the momment. But i'm not shure in this point. I've exchanged some emails with the author of https://github.com/ncopa/xfce-bluetooth Unfortunately, the code there is in very early alpha stage. It doesn't do a whole lot yet. He's happy to have any help implementing things, but makes no promises as to when things will be usable. This applet depends on vala and the xfce-vala bindings, so I am not sure if it would work for other desktops, but its possible that it could. If anyone would be interested in helping out with this applet, please contact the maintainer. For Xfce, we could use this if it becomes usable in time, or we could use some other systray producting applet, or we could just not support bluetooth from the desktop for this release. ;( kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Suggestion: bmap files and bmaptool
On 08/16/2013 09:46 AM, Artem Bityutskiy wrote: > Hi Eric, > > thanks for the question. Sorry my answers contain extra information, but > I assume that other people read this, and may benefit from the info. > After all, I am trying to get people interested, this is a good tool > IMO, and I would like to get more users and hopefully contributors. :-) > > On Thu, 2013-08-15 at 12:34 -0500, Eric Sandeen wrote: >> On 8/13/13 8:58 AM, Artem Bityutskiy wrote: >>> # Make the image to be sparse >>> $ cp --sparse=always Fedora-x86_64-19-20130627-sda.raw >> Fedora-x86_64-19-20130627-sda.raw.sparse >>> >>> # Generate the bmap file >>> $ bmaptool create Fedora-x86_64-19-20130627-sda.raw.sparse -o >> Fedora-x86_64-19-20130627-sda.raw.sparse.bmap >> >> So this is the part that interests me . . . > > Before going further, I want to quckly note that the Tizen image > generation software uses the BmapCreate library API directly, instead of > running the bmaptool command-line utility. The library comes with the > bmap-tools project. > > http://git.infradead.org/users/dedekind/bmap-tools.git/blob/refs/heads/devel:/bmaptools/BmapCreate.py > >> There seem to be two issues here; how do we efficiently (compress and) >> transport sparse files while retaining sparseness, and how do we >> efficiently operate on files which are already sparse. > > Yes, it is our assumption is that sparseness gets lost as soon as the > image is compressed or copied to the download server, or anywhere else. > > The idea is that as soon as you generate the raw image on the build > server, you generate the bmap file right away, _before_ the sparseness > gets lost. > > The sparseness information is then saved in the bmap file. Then you can > compress the image, copy it around, and lose the sparseness. The bmap > file preserves it. > > And of course this means that you should not modify the image later on, > otherwise the bmap file becomes incorrect, and the checksums, which are > inside the bmap file, will probably mismatch. > >> For the latter, you're using your bmap tool to map what is hopefully a >> static file (via fibmap or fiemap, I guess?). > > Yes, we use FIEMAP. Here is the python module which does the job: > > http://git.infradead.org/users/dedekind/bmap-tools.git/blob/refs/heads/devel:/bmaptools/Fiemap.py > >> I haven't looked at how you've done it, but you do need to be very >> careful that the file is stable & quiesced on disk. > > Right. We generate the bmap file on the _build server_, inside the tool > which generates the raw image. At this point we do know we fully control > the image, and no one touches it while we generate the bmap. > > But yes, this is a good point, may be I need to put it to the man page. > Which, by the way, as I figure out now, needs to be somewhat updated: > > http://git.infradead.org/users/dedekind/bmap-tools.git/blob/refs/heads/devel:/docs/man1/bmaptool.1 > >> Mapping it this way can be fraught with errors if the file is >> changing, or has delalloc blocks, etc. > > Good point. Tizen image generator fsync()'s the file before creating > bmap, but I guess I have to do this in the BmapCreate library too, to be > safe. > > Thanks! > >> And of course getting the mapping wrong means data corruption. > > Right. But as I said, we are using bmaptool for a year now, and nothing > which looks like a corruption was reported so far. > > But the importance of fsync() is a very good point, I'll improve the > library and make it explicitely fsync, and probably ignore the EROFS > error, in case the file is R/O. > >> If the file is known to be sparse, then going forward, using >> SEEK_HOLE / SEEK_DATA is probably the best approach. > > Why are they better than FIEMAP? > > I did consider them, actually, but they are very new, and build servers > tend to use older kernels, so I chose FIEMAP. I actually first used > FIBMAP, but it is too slow, so I switched to FIEMAP. >> >> But then there's the issue of transporting these sparse files around. >> We have had the same problem in the past with large e2image metadata >> image files, which may be terabytes in length, with only gigabytes or >> megabytes of real data. e2image _itself_ creates a sparse file, but >> bzipping it or rsyncing it still processes terabytes of zeros, and >> loses all notion of sparseness. > > Right, but the scenario I keep in mind is that the bmap file is created > at the _very_ beginning, and carried/published together with the image, > as a stand-alone file with the same basename and ".bmap" extension. > > The zeroes in the image can be very well compressed with xz, so people > download/copy a lot less than Terabytes. And then people just run this > command to re-create the original sparse file: > > $ bmaptool copy --bmap huge.img.bmap huge.img.xz a_sparse_copy.img > > This will decompress huge.img.xz on-the-fly and put it to > a_sparse_copy.img. The a_sparse_copy.img file will be sparse. > > Note, it bmaptool auto-discovers
Re: [Java package] add_to_maven_depmap macro issue
Il 18/08/2013 11:19, punto...@libero.it ha scritto: Il 18/08/2013 07:03, Ankur Sinha ha scritto: Hi, One of my packages: dcm4che-test fails to build for rawhide currently. There's a bug filed here[1]. The build.log seems to fail on the "add_to_maven_depmap" macro. I think it doesn't find it at all[2]. Could someone please tell me if I'm missing a BR or if the macros have changed[3]? [1]https://bugzilla.redhat.com/show_bug.cgi?id=992114 [2]http://ankursinha.fedorapeople.org/dcm4che-build.log [3] http://fedoraproject.org/wiki/Java/JPPMavenReadme#Packages_adding_their_own_depmaps i see now your spec file you should use XMvn take a look here http://mizdebsk.fedorapeople.org/xmvn/cookbook/ regards gil i proceeded to provide a patch https://bugzilla.redhat.com/attachment.cgi?id=787744 - fix rhbz#992114 - switch to XMvn - adapt to current guideline Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=5825895 regards gil <>-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Java package] add_to_maven_depmap macro issue
Il 18/08/2013 07:03, Ankur Sinha ha scritto: Hi, One of my packages: dcm4che-test fails to build for rawhide currently. There's a bug filed here[1]. The build.log seems to fail on the "add_to_maven_depmap" macro. I think it doesn't find it at all[2]. Could someone please tell me if I'm missing a BR or if the macros have changed[3]? [1] https://bugzilla.redhat.com/show_bug.cgi?id=992114 [2] http://ankursinha.fedorapeople.org/dcm4che-build.log [3] http://fedoraproject.org/wiki/Java/JPPMavenReadme#Packages_adding_their_own_depmaps i see now your spec file you should use XMvn take a look here http://mizdebsk.fedorapeople.org/xmvn/cookbook/ regards gil <>-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Java package] add_to_maven_depmap macro issue
Il 18/08/2013 07:03, Ankur Sinha ha scritto: Hi, One of my packages: dcm4che-test fails to build for rawhide currently. There's a bug filed here[1]. The build.log seems to fail on the "add_to_maven_depmap" macro. I think it doesn't find it at all[2]. Could someone please tell me if I'm missing a BR or if the macros have changed[3]? [1] https://bugzilla.redhat.com/show_bug.cgi?id=992114 [2] http://ankursinha.fedorapeople.org/dcm4che-build.log [3] http://fedoraproject.org/wiki/Java/JPPMavenReadme#Packages_adding_their_own_depmaps hi yes is changed you can use %add_maven_depmap https://fedoraproject.org/wiki/User:Akurtakov/JavaPackagingDraftUpdate#Maven_pom.xml_files_and_depmaps regards gil <>-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
