Re: another input/output question (libinput / pulseaudio / ....)
Hello Bastien, Hello list, >I have no idea how to change the LEDs though, but if they're exposed in sysfs, >you'd probably >change them in gnome-settings-daemon as well. I have :) I will (in the next month) find out using virtualbox/vmware and a packet sniffer see what the win driver is doing while changing the LED's, so patches required: ok, but where would be a proper place in the gnome gui for that? 2015-02-11 0:36 GMT+01:00 Bastien Nocera : > > > - Original Message - >> On Mon, 2015-02-09 at 08:44 +1000, Peter Hutterer wrote: >> >> > However, especially for libinput, it gets hazy and also mostly pointless. >> > aside from some special processing required for touchpads and tablets, we >> > don't care much _what_ a device is, we just pass on the events. If a >> > device >> > has keys, it'll be a keyboard. if it sents KEY_MUTE we pass that on, the >> > compositor/X stack will then handle that however need be. There's no real >> > benefit to us trying to figure out what is a headset and what isn't, we'd >> > still just pass on the keys. >> >> Fair enough. One thing that is important, though, is to preserve enough >> information about the originating device (and the general device >> topology) that higher levels have a chance to do the right thing (e.g. >> mute the headset and not the speakers, if that is where the mute button >> is). > > We already do that, when we can match the audio device with the input device, > in gnome-settings-daemon: > https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/media-keys/gsd-media-keys-manager.c#n1184 > > It did work to make the volume buttons on a USB speaker control the USB > speaker and nothing else. > > I have no idea how to change the LEDs though, but if they're exposed in > sysfs, you'd probably > change them in gnome-settings-daemon as well. > > I'd say "patches welcome" but in this case it will be "patches required". > -- > 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
gloox updated to 1.0.13 with soname bump in f22+rawhide[only]
Hi folks, gloox has been upgraded to 1.0.13 with bumped soname libgloox.so.13 [libgloox.so.12~]. Referring to upstream, this release is *still* source compatible with previous releases, only some ABI were removed. ABI diff details: http://upstream.rosalinux.ru/compat_reports/gloox/1.0.12_to_1.0.13/abi_compat_report.html Meanwhile gloox 1.0.12 will be pushed to all branches still as upstream had disabled SSLv3 to avoid POODLE in that release. Yours sincerely, Christopher Meng http://cicku.me -- 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: another input/output question (libinput / pulseaudio / ....)
- Original Message - > On Mon, 2015-02-09 at 08:44 +1000, Peter Hutterer wrote: > > > However, especially for libinput, it gets hazy and also mostly pointless. > > aside from some special processing required for touchpads and tablets, we > > don't care much _what_ a device is, we just pass on the events. If a > > device > > has keys, it'll be a keyboard. if it sents KEY_MUTE we pass that on, the > > compositor/X stack will then handle that however need be. There's no real > > benefit to us trying to figure out what is a headset and what isn't, we'd > > still just pass on the keys. > > Fair enough. One thing that is important, though, is to preserve enough > information about the originating device (and the general device > topology) that higher levels have a chance to do the right thing (e.g. > mute the headset and not the speakers, if that is where the mute button > is). We already do that, when we can match the audio device with the input device, in gnome-settings-daemon: https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/media-keys/gsd-media-keys-manager.c#n1184 It did work to make the volume buttons on a USB speaker control the USB speaker and nothing else. I have no idea how to change the LEDs though, but if they're exposed in sysfs, you'd probably change them in gnome-settings-daemon as well. I'd say "patches welcome" but in this case it will be "patches required". -- 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: Orphaned Packages in rawhide (2015-02-10)
> audiofileorphan, ajax, alexl, caillon, caolanm, 1 weeks ago > group::gnome-sig, johnp, mbarnes, > rhughes, rstrode, ssp, xiphmont I've added myself there, since there are tons of deps on it down to even audacious-plugins and dozens of packagers are affected either directly or indirectly. Though I'm not familiar with this lib [yet]. There are no open tickets in bugzilla currently. Not much activity in the package %changelog. -- 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: another input/output question (libinput / pulseaudio / ....)
On Tue, Feb 10, 2015 at 02:09:55PM -0500, Matthias Clasen wrote: > On Mon, 2015-02-09 at 08:44 +1000, Peter Hutterer wrote: > > > However, especially for libinput, it gets hazy and also mostly pointless. > > aside from some special processing required for touchpads and tablets, we > > don't care much _what_ a device is, we just pass on the events. If a device > > has keys, it'll be a keyboard. if it sents KEY_MUTE we pass that on, the > > compositor/X stack will then handle that however need be. There's no real > > benefit to us trying to figure out what is a headset and what isn't, we'd > > still just pass on the keys. > > Fair enough. One thing that is important, though, is to preserve enough > information about the originating device (and the general device > topology) that higher levels have a chance to do the right thing (e.g. > mute the headset and not the speakers, if that is where the mute button > is). I _think_ we do that but I'm open to suggestions if we don't do it sufficiently. First, all events in libinput are device-based. There are some seat helpers but all events are still per libinput device, so you definitely know which device the event is coming from. Right now, the only real thing to associate with any topology you get from libinput is the udev_device. What's in the works for 0.11 are device groups (see http://who-t.blogspot.com.au/2015/02/libinput-device-groups.html) which give you a bit more of the topology in some special cases, though that probably won't apply in this particular case. if there is anything more we should do pls let us know. Cheers, Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fedora 22 Mass Branching
Hi All, Fedora 22 has been branched, please be sure to do a git pull --rebase to pick up the new branch, as an additional reminder rawhide/f23 has had inheritance cut off from previous releases, so this means that anything you do for f22 you also have to do in the master branch and do a build there. This is the same as we did for previous Fedora releases Peter ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-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
looking for Jeffrey C. Ollie
Hi, I've filled in https://bugzilla.redhat.com/show_bug.cgi?id=1170578 and I'd like to replace radiusclient-ng-utils with freeradius-client-utils. Does anyone have more recent contact information of Jeffrey C. Ollie (j...@ocjtech.us). regards, Nikos -- 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: another input/output question (libinput / pulseaudio / ....)
On Mon, 2015-02-09 at 08:44 +1000, Peter Hutterer wrote: > However, especially for libinput, it gets hazy and also mostly pointless. > aside from some special processing required for touchpads and tablets, we > don't care much _what_ a device is, we just pass on the events. If a device > has keys, it'll be a keyboard. if it sents KEY_MUTE we pass that on, the > compositor/X stack will then handle that however need be. There's no real > benefit to us trying to figure out what is a headset and what isn't, we'd > still just pass on the keys. Fair enough. One thing that is important, though, is to preserve enough information about the originating device (and the general device topology) that higher levels have a chance to do the right thing (e.g. mute the headset and not the speakers, if that is where the mute button is). -- 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: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22
On 02/10/2015 07:05 AM, Ralf Corsepius wrote: > Well, wouldn't you agree that developers should be able to read warnings > and filter out the serious one? If a project has more than a screen-full of "harmless" warnings, then it's very easy to miss when a serious one slips in. I prefer -Werror so that nothing gets by, all warnings must be considered. It's not that much of a burden after you first get to a warning-free build. I could see the argument that this approach belongs in upstream development, not so much distro packaging. I still think it's useful to know that any patches applied are warning-free too though. -- 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: Schedule for Wednesday's FESCo Meeting (2015-02-11)
FYI, I am going to be moving machines around at a datacenter and likely won't be able to attend. I'll try and vote in tickets later tonight... kevin pgpUiADtoug9J.pgp Description: OpenPGP digital 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: Schedule for Wednesday's FESCo Meeting (2015-02-11)
On Tue, Feb 10, 2015 at 11:08 AM, Miloslav Trmač wrote: > Following is the list of topics that will be discussed in the FESCo > meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net. > > To convert UTC to your local time, take a look at > http://fedoraproject.org/wiki/UTCHowto > > or run: > date -d '2015-02-11 18:00 UTC' > > > Links to all tickets below can be found at: > https://fedorahosted.org/fesco/report/9 Whew... this is a rather large list. I'm somewhat doubtful we're going to get through all of this even in 2 hours. Do we want to prioritize the order a bit? josh -- 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: git - possible rebase on F21
On Tue, 2015-02-10 at 10:03 +, Peter Robinson wrote: > On Tue, Feb 10, 2015 at 9:58 AM, Petr Stodulka > wrote: > > Hi guys, > > I have this request [0] for rebase of git from version 2.1.0 to > > 2.2.2 for > > Fedora 21. Can I do this? Do you know someone about any > > incompatibilities? > > For me there are not so big changes but I have not problem with > > this. We have now version 2.3.0 on rawhide. In the case that yo > > prefer rebase to 2.2.2 or even to 2.3.0? > > What are the pros of moving from 2.1.x to a newer release? 2.3 would somewhat reduce the chance of idiotic monkeys messing up important repositories: https://github.com/git/git/commit/00a6fa0720283b93eb011adcfea850fe21345548 if that's of interest to anyone. :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Schedule for Wednesday's FESCo Meeting (2015-02-11)
Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2015-02-11 18:00 UTC' Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 #topic Welcoming new FESCo members = Followups = #topic #1269 Closing all 'Merge Review' bugs .fesco 1269 https://fedorahosted.org/fesco/ticket/1269 #topic #1326 change to fesco replacement process? .fesco 1326 https://fedorahosted.org/fesco/ticket/1326 #topic #1384 F23 System Wide Change: Harden all packages with position-independent code - https://fedoraproject.org/wiki/Changes/Harden_all_packages_with_position-independent_code .fesco 1384 https://fedorahosted.org/fesco/ticket/1384 #topic #1390 F22 System Wide Change: RpmOstree - Server side composes and atomic upgrades - https://fedoraproject.org/wiki/Changes/RpmOstree .fesco 1390 https://fedorahosted.org/fesco/ticket/1390 #topic #1396 F22 System Wide Change: Atomic Host - https://fedoraproject.org/wiki/Changes/AtomicHost .fesco 1396 https://fedorahosted.org/fesco/ticket/1396 #topic #1397 F22 System Wide Change: Bare Metal Installer for Fedora Atomic Host - https://fedoraproject.org/wiki/Changes/Bare_Metal_Atomic .fesco 1397 https://fedorahosted.org/fesco/ticket/1397 #topic #1392 Review scope of "Python 3 as default" Change for F22 .fesco 1392 https://fedorahosted.org/fesco/ticket/1392 #topic #1413 F22 System Wide Change: Python 3 Migration Improvements - https://fedoraproject.org/wiki/Changes/Python_3_Migration_Improvements .fesco 1413 https://fedorahosted.org/fesco/ticket/1413 #topic #1406 F22 System Wide Change: Systemd Package Split - https://fedoraproject.org/wiki/Changes/SystemdPackageSplit .fesco 1406 https://fedorahosted.org/fesco/ticket/1406 = New business = #topic #1377 enable kdump addon by default .fesco 1377 https://fedorahosted.org/fesco/ticket/1377 #topic #1408 New package/branch request processes (off bugzilla to pkgdb) .fesco 1408 https://fedorahosted.org/fesco/ticket/1408 #topic #1409 provenpackager request: mstuchli .fesco 1409 https://fedorahosted.org/fesco/ticket/1409 #topic #1410 Updates Policy should try harder to prevent updates that break future updates .fesco 1410 https://fedorahosted.org/fesco/ticket/1410 #topic #1411 F21 privacy issue, Geolocation done for every install .fesco 1411 https://fedorahosted.org/fesco/ticket/1411 #topic Meeting time = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- 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: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22
On Tue, Feb 10, 2015 at 04:05:31PM +0100, Ralf Corsepius wrote: > On 02/10/2015 03:56 PM, Adam Jackson wrote: > > >If only there was some way to use different CFLAGS for configure than > >for the project. > > Well, wouldn't you agree that developers should be able to read warnings and > filter out the serious one? But -Werror automates that, at the cost that when compiler changes, grows new warnings etc., you might need to adjust your code, and perhaps work around false positive warnings or individually disable them. Anyway, the problem was that K&R functions with implicit int etc. are not valid in C99 or C11, and it would be desirable if developers from time to time compared e.g. config.h files upon major compiler bumps if something important didn't get turned off. Lots of failed configure tests will show up somewhere during the build or in the testsuites, but some changes might go unnoticed. Jakub -- 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: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22
On Mon, Feb 9, 2015 at 10:22 PM, Marek Polacek wrote: > IIRC bigloo contains various "autoconf" shell scripts with K&R code in > them (that fail with -Werror now) to detect e.g. -fpic. So that's why > the -fpic wasn't used. Oh, I see. Thanks. I have sent an email upstream to inform them of the nature of the problem. 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: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22
On 02/10/2015 03:56 PM, Adam Jackson wrote: If only there was some way to use different CFLAGS for configure than for the project. Well, wouldn't you agree that developers should be able to read warnings and filter out the serious one? Ralf -- 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: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22
On Tue, 2015-02-10 at 07:34 +0100, Ralf Corsepius wrote: > On 02/10/2015 06:22 AM, Marek Polacek wrote: > > On Mon, Feb 09, 2015 at 02:43:25PM -0700, Jerry James wrote: > >> On Sun, Feb 8, 2015 at 10:17 AM, Marek Polacek wrote: > >>> bigloo-4.1a-6.2.fc22.src.rpm > >>> memstomp-0.1.4-15.fc22.src.rpm > >>> build failure due to gnu11 change: -Wimplicit-int is turned on > >>> by default now, > >>> which is the reason these packages didn't compile properly. See > >>> the porting_to > >>> document for more details. > >> > >> The bigloo failure had nothing to do with -Wimplicit-int. One file > >> that should have been compiled with -fPIC wasn't. I don't know why > >> this didn't cause problems before. Fixed in Rawhide. > > > > IIRC bigloo contains various "autoconf" shell scripts with K&R code in > > them (that fail with -Werror now) > > Remove these -Werrors and tell upstream to not use -Werror. > -Werror turns harmless warnings into errors. > > As autoconf scripts are based on compilers issuing errors only on real > errors and not on otherwise harmless warnings, -Werror is not useful > with autoconf scripts and is _guaranteed_ to break autoconf scripts, > because the items GCC warns about are changing with each GCC-release and > also depend on other factors (CFLAGS) in effect. If only there was some way to use different CFLAGS for configure than for the project. - ajax -- 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: Changing default configuration
On Tue, 2015-02-10 at 14:38 +0100, Marek Skalický wrote: > Matthew Miller píše v Út 10. 02. 2015 v 06:19 -0500: > > On Tue, Feb 10, 2015 at 12:12:15PM +0100, Marek Skalický wrote: > > > does someone know what are Fedora Guidelines (or something similar) > > > saying about this bug > > > https://bugzilla.redhat.com/show_bug.cgi?id=1077369 ? > > > Is is possible to change default configuration file depending on > > > available free space? > > > > Generally, making such a decision at install time is bad, because that > > might not reflect _runtime_. For example, in the cloud image, we use a > > / filesystem as small as Anaconda will allow, but that grows to fill > > available storage when the image is booted. > > > > Is there a way to make this decision when mongodb runs? > > > > It should be possible to code this into sysv init script. But I am not > sure if it is possible to do the same in systemd service...? > > My question was also about whether this should be done by mongoDB? Or > there should be default configuration and user can easily change it in > configuration file? It should be done by MongoDB, I would get in touch with the upstream and discuss the problem with them. > Marek > -- Greetings, Alberto Ruiz Engineering Manager - Desktop Applications Team Red Hat, Inc. -- 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: Changing default configuration
Am 10.02.2015 um 14:38 schrieb Marek Skalický: Matthew Miller píše v Út 10. 02. 2015 v 06:19 -0500: On Tue, Feb 10, 2015 at 12:12:15PM +0100, Marek Skalický wrote: does someone know what are Fedora Guidelines (or something similar) saying about this bug https://bugzilla.redhat.com/show_bug.cgi?id=1077369 ? Is is possible to change default configuration file depending on available free space? Generally, making such a decision at install time is bad, because that might not reflect _runtime_. For example, in the cloud image, we use a / filesystem as small as Anaconda will allow, but that grows to fill available storage when the image is booted. Is there a way to make this decision when mongodb runs? It should be possible to code this into sysv init script. But I am not sure if it is possible to do the same in systemd service...? My question was also about whether this should be done by mongoDB? Or there should be default configuration and user can easily change it in configuration file? user configuration as said, you can't make such decisions at install time nor belong they to the service unit signature.asc Description: OpenPGP digital 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: Changing default configuration
Matthew Miller píše v Út 10. 02. 2015 v 06:19 -0500: > On Tue, Feb 10, 2015 at 12:12:15PM +0100, Marek Skalický wrote: > > does someone know what are Fedora Guidelines (or something similar) > > saying about this bug > > https://bugzilla.redhat.com/show_bug.cgi?id=1077369 ? > > Is is possible to change default configuration file depending on > > available free space? > > Generally, making such a decision at install time is bad, because that > might not reflect _runtime_. For example, in the cloud image, we use a > / filesystem as small as Anaconda will allow, but that grows to fill > available storage when the image is booted. > > Is there a way to make this decision when mongodb runs? > It should be possible to code this into sysv init script. But I am not sure if it is possible to do the same in systemd service...? My question was also about whether this should be done by mongoDB? Or there should be default configuration and user can easily change it in configuration file? Marek -- 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: git - possible rebase on F21
Dne 10.2.2015 v 11:03 Peter Robinson napsal(a): On Tue, Feb 10, 2015 at 9:58 AM, Petr Stodulka wrote: Hi guys, I have this request [0] for rebase of git from version 2.1.0 to 2.2.2 for Fedora 21. Can I do this? Do you know someone about any incompatibilities? For me there are not so big changes but I have not problem with this. We have now version 2.3.0 on rawhide. In the case that yo prefer rebase to 2.2.2 or even to 2.3.0? What are the pros of moving from 2.1.x to a newer release? What are the possible issues? Is there a soname bump? API/ABI changes? The bug just asks for it to rebase and doesn't state why it would be useful. In general you should outline things like does it have features that are useful, does it have functionality that is needed to interact with new features of some public tool or infrastructure (say signed pushes for kernel upstream, some new functionality in github etc). Peter Thanks Peter for advice. There are some API changes according to log and I don't see any important issue which is fixed in newer version or some really so good features. #1187874 is closed now. -- 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: Migration to Zanata
- Original Message - > Hi Fedora developers > > I have not heard yet from the maintainers of the following packages. > Fedora Localization Project would like to have them migrated in Zanata > asap for good kickstart of F22. > We all are much appreciated your immediate attention. > system-config-bind Let's consider this as EOL, time to kill it officially... Jaroslav -- 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: Changing default configuration
On Tue, Feb 10, 2015 at 12:12:15PM +0100, Marek Skalický wrote: > does someone know what are Fedora Guidelines (or something similar) > saying about this bug > https://bugzilla.redhat.com/show_bug.cgi?id=1077369 ? > Is is possible to change default configuration file depending on > available free space? Generally, making such a decision at install time is bad, because that might not reflect _runtime_. For example, in the cloud image, we use a / filesystem as small as Anaconda will allow, but that grows to fill available storage when the image is booted. Is there a way to make this decision when mongodb runs? -- Matthew Miller Fedora Project Leader -- 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: Migration to Zanata
On 10.02.2015 04:44, Noriko Mizumoto wrote: > Hi Fedora developers > > I have not heard yet from the maintainers of the following packages. > Fedora Localization Project would like to have them migrated in Zanata > asap for good kickstart of F22. > We all are much appreciated your immediate attention. > > * If you are happy to delegate the migration work to us, please advise > me by mailing to "noriko at redhat.com". The migration timing can be > specified according to your development schedule, let me know. > > * If you like to complete the migration work by yourself, please advise > the date when your package will be available at Zanata. I will inform to > all translators. > > * If your package is Upstream, and your team decide not to migrate to > Zanata. Please let me know, I will inform to all translators. > > "AGAIN, THOSE ARE UNTOUCHED AND NOT MIGRATED" > [Fedora Packages] > readahead dead.package > system-config-boot dead.package -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Changing default configuration
Hi, does someone know what are Fedora Guidelines (or something similar) saying about this bug https://bugzilla.redhat.com/show_bug.cgi?id=1077369 ? Is is possible to change default configuration file depending on available free space? (this change is about adding smallfile=true into mongod.conf file) Thanks, Marek -- 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: git - possible rebase on F21
On Tue, Feb 10, 2015 at 9:58 AM, Petr Stodulka wrote: > Hi guys, > I have this request [0] for rebase of git from version 2.1.0 to 2.2.2 for > Fedora 21. Can I do this? Do you know someone about any incompatibilities? > For me there are not so big changes but I have not problem with this. We > have now version 2.3.0 on rawhide. In the case that yo prefer rebase to > 2.2.2 or even to 2.3.0? What are the pros of moving from 2.1.x to a newer release? What are the possible issues? Is there a soname bump? API/ABI changes? The bug just asks for it to rebase and doesn't state why it would be useful. In general you should outline things like does it have features that are useful, does it have functionality that is needed to interact with new features of some public tool or infrastructure (say signed pushes for kernel upstream, some new functionality in github etc). Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
git - possible rebase on F21
Hi guys, I have this request [0] for rebase of git from version 2.1.0 to 2.2.2 for Fedora 21. Can I do this? Do you know someone about any incompatibilities? For me there are not so big changes but I have not problem with this. We have now version 2.3.0 on rawhide. In the case that yo prefer rebase to 2.2.2 or even to 2.3.0? Thanks for responses :-) Petr [0] https://bugzilla.redhat.com/show_bug.cgi?id=1187874 -- 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: another dnf kernel issue?
- Original Message - > From: "Neal Becker" > To: devel@lists.fedoraproject.org > Sent: Monday, February 9, 2015 3:08:17 PM > Subject: another dnf kernel issue? > > [nbecker@nbecker1 ~]$ sudo dnf remove kernel*3.18.3* > [sudo] password for nbecker: > No match for argument: kernel*3.18.3* > Error: No packages marked for removal. > [nbecker@nbecker1 ~]$ sudo dnf remove kernel*3.18.3-201.fc21 > No match for argument: kernel*3.18.3-201.fc21 > Error: No packages marked for removal. > [nbecker@nbecker1 ~]$ sudo yum remove kernel*3.18.3-201.fc21 > Loaded plugins: fastestmirror, langpacks, merge-conf, versionlock > Repodata is over 2 weeks old. Install yum-cron? Or run: yum makecache fast > Resolving Dependencies > --> Running transaction check > ---> Package kernel-core.x86_64 0:3.18.3-201.fc21 will be erased > ---> Package kernel-modules.x86_64 0:3.18.3-201.fc21 will be erased > ---> Package kernel-modules-extra.x86_64 0:3.18.3-201.fc21 will be erased > --> Finished Dependency Resolution Does "sudo dnf remove kernel*-3.18.3*" work for you? From the DNF's persepective (http://dnf.readthedocs.org/en/latest/command_ref.html#specifying-packages), your specification is in the form "name" (because of the missing dash) and there is no package with a name matching "kernel*3.18.3*". Also in the second query, it is assumed that the name must match "kernel*3.18.3". TBH, I don't know whether we should extend the forms of package specifications to support your case. The current behaviour seems to be safer to me. I mean, if we improve it, user wouldn't be able to query just package names as easily as now. -- Radek Holý Associate Software Engineer Software Management Team Red Hat Czech -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
