devel August 2013

devel@lists.stg.fedoraproject.org

260 participants
310 discussions

anaconda / initial-setup / gnome-initial-setup: can we do this better?
by Adam Williamson 15 Oct '13

15 Oct '13

So I'm writing a blog post on this topic ATM, and that really kinda brought home how messy this design is at present. Quick refresher for anyone who hasn't looked at it much yet: in F19, anaconda can create user accounts, and 'firstboot' has been replaced with two alternative tools, 'initial-setup' which is used in any graphical install other than a GNOME install and just replicates anaconda's 'root password', 'user creation' and 'date/time' spokes, and gnome-initial-setup, which is used in GNOME installs and is its own whole thing that can also do user creation. I mapped out all the potential paths through this maze, and got this - 16(!!!) paths: anaconda: root pw, no user - g-i-s: admin user i-s: admin user i-s: regular user console: root anaconda: root pw, regular user - g-i-s: user mode i-s: edit root pw or user i-s: leave intact console: regular user + root anaconda: root pw, admin user - g-i-s: user mode i-s: edit root pw or user i-s: leave intact console: admin user + root anaconda: no root pw, admin user - g-i-s: user mode i-s: edit root pw or user i-s: leave intact console: admin user + root Note the paths marked "i-s: edit root pw or user" are pretty messy and open ended in themselves - initial-setup always runs if installed, no matter what you set in anaconda, and at least theoretically lets you change the settings you picked in anaconda. This is...kinda nuts, and a QA nightmare. Can we maybe take a step back and look if there's a more sensible way to design this, ideally with the GNOME and anaconda teams working together? If we imagined initial-setup didn't exist and we only had the anaconda/g-i-s case, the proliferation of trees at least looks rather better, because g-i-s can't set the root password or change what anaconda did; if you create a user account during anaconda, g-i-s runs only after you log in with that user account and just lets you configure various settings for that user account, it doesn't let you create other user accounts (this is what I've labelled as 'g-i-s: user mode' in the tree). So the anaconda/g-i-s paths are broadly sane already. It's the anaconda/i-s paths that are really complicating things. Still, it might help to just take a step back and decide if we really need all this flexibility. We could, for instance, simply force user creation during anaconda, dump initial-setup entirely, and use only gnome-initial-setup's "user mode" (desktops other than GNOME could implement something like this "user mode" if they wanted to, or not). That would be a hell of a lot simpler to code, test, support and explain, with the minor(?) drawback that you couldn't install without a user account and then create it on first boot any more. Xkcd Law tells us that someone will not be happy about this: https://xkcd.com/1172/ but still, it seems to be worth considering. Alternatively, we could make i-s behave a lot more like g-i-s: it could dump its 'root password' and 'date/time' spokes, and only run at all, and only to allow user creation, if you didn't create a user during anaconda. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net

14 37

yum picking kernel-debug instead of kernel for 'BuildRequires: kernel'
by Richard W.M. Jones 13 Oct '13

13 Oct '13

If two packages 'provide' the same dependency, isn't yum supposed to pick the one with the shortest name? Anyway, 'BuildRequires: kernel' in Rawhide (on koji) picks 'kernel-debug' instead of 'kernel'. Is there a way to make it pick 'kernel' instead? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org

2 2

GPG verification in SPECs
by Till Maas 11 Oct '13

11 Oct '13

Hi, upstream of pam_mount pointed me to OpenSUSE's gpg-offline RPM macros at https://build.opensuse.org/package/show/Base:System/gpg-offline They allow to use a keyring and detached signature as additional source in SPECs to get both verified. Since gpg-offline's upstream is willing to create a proper release to allow easy packaging for Fedora, I wonder if I will find any obstacles when I package it. The packaging guidelines allow packaging RPM macros, therefore this should be fine. Also I am interested whether there are better options available. Regards Till

9 13

F19 server install experience
by Samuel Sieb 03 Oct '13

03 Oct '13

I realize it's been a while since F19 was released but I finally got around to do a server install. Since there have been a few negative reviews here of the installation process I thought it might be nice to have a mostly positive one. Here are my observations: VLAN setup for installing! Yay! However, after rebooting, NetworkManager wasn't able to bring it up, something about not knowing the "virtual interface name". Turned out to be the ethernet interface name changed from what it was at install time. Didn't detect my timezone. Not a big deal, but I was hoping it would since there's been some discussion here about it working. I'm reinstalling an existing server, so used the custom partitioning. The only problem I had here was that I clicked on the existing /home partition to add it to the new install but then couldn't figure out what to do. All I saw on the right was lots of disabled form items. Eventually I read the instructions carefully and then looked at the mount point entry again and saw that it wasn't disabled. I wonder if there is some way to make it more obvious... After starting the install, I went to enter the root password. As I was doing so, the interface appeared to freeze. I switched through the consoles and when I got back the interface was working again and the keys that I had typed had shown up. One odd thing I noticed while cycling through the consoles was that console 6 had a login prompt on it. I didn't actually try logging in. The progress bar is strange. All the package installing barely made it past a quarter of the way. Other than the ethernet interface naming issue, just minor cosmetic issues. Thanks to everybody involved in getting the installer in such nice shape.

7 16

bodhi client question
by Joachim Backes 03 Oct '13

03 Oct '13

Dear bodhi/koji specialists, perhaps, this is a dumb question: sometimes after having filed a BZ, I get some email like ----------------------------------------------------------- Package xxxxx-4.1.0.0-4.beta1.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing xxxxx-4.1.0.0-4.beta1.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-9971/xxxxx-4.1.0.0-4.be… ------------------------------------------------------------ *My question:* if xxxxx consists of a lot of packages, and I'm only needing some few of them (libreoffice is a good example), how then can I automatically download only those packages installed on my site? The usage of "bodhi -D xxxxx....." will download *all* and not only the locally installed pkgs. Kind regards Joachim Backes -- Fedora release 19 (Schrödinger’s Cat): Kernel-3.9.4-302.fc19.x86_64 Joachim Backes <joachim.backes(a)rhrk.uni-kl.de> https://www-user.rhrk.uni-kl.de/~backes

8 11

Non-responsive maintainer: Dodji Seketeli
by Darryl L. Pierce 24 Sep '13

24 Sep '13

BZ#848774 This bug is nearly a year old, requesting that package offlineimap be upgraded to what was then the latest release (6.5.4, now it is 6.5.5-rc2). There has been no response from the maintainer. I posted a bug comment on 01 July asking for something from the package maintainer and received no word. I don't want to take over the package, but would like either the primary or else a co-maintainer to upgrade the package as it has bugs that have been fixed since 6.5.2 (the currently packaged release). -- Darryl L. Pierce <mcpierce(a)gmail.com> http://mcpierce.multiply.com/ "What do you care what people think, Mr. Feynman?"

2 6

Suggestion: bmap files and bmaptool
by Artem Bityutskiy 17 Sep '13

17 Sep '13

Hi Fedora developers, I would like suggest you to take a look at bmaptool, which you can use for flashing Fedora ISO images to USB sticks (or other block devices). Let me set the scene. In order to flash a Fedora ISO image, typically first download the image and then use dd to copy it to the USB stick. Bmaptool does this, but a) a lot faster (several times faster if you have the bmap file) b) simpler, because it can flash directly from an URL (decompress on-the fly too) c) simpler, because it verifies data checksum automatically (only if bmap file is present) d) safer, since it won't destroy your mounted partition if you specify wrong block device (say, for example, /dev/sda being the rootfs) So what I am trying to "sell" here is a tool which flashes several times faster than dd, which is safe, and can flash from http/ftp/https/ssh URLs directly, and decompress gz/bz2/xz/gzip/tgz/tar.{gz/bz2/zx} files on-the-fly. We are using this in Tizen IVI, and I'd like to see other distros using/supporting it. Or at least checking it. The key element for bmaptool is the bmap file, which Fedora does not produce for the ISO images. So bmaptool is not so useful, but the community could find the tool useful and start providing the bmap files. Anyway, those who are interested in all the details may read the docs, the links will be at the end. Let me give a couple of examples. I the example I flash a Fedora image to my USB stick, which is /dev/sdd. 1. First of all, I can flash directly from the URL, I use the Finland mirror here: $ bmaptool copy --nobmap ftp://ftp.funet.fi/pub/mirrors/fedora.redhat.com/pub/fedora/linux/releases/… /dev/sdd Note, I use --nobmap because there is no bmap file. With bmap file flashing would be _a lot_ faster. 2. Let's check how fast is dd. I downloaded and decompressed the image prior to running the tests. $ dd if=Fedora-x86_64-19-20130627-sda.raw of=/dev/sdd 4194304+0 records in 4194304+0 records out 2147483648 bytes (2.1 GB) copied, 799.487 s, 2.7 MB/s 13.3 minutes. 3. With bmaptool, no bmap file. $ bmaptool copy --nobmap Fedora-x86_64-19-20130627-sda.raw /dev/sdd bmaptool: info: no bmap given, copy entire image to '/dev/sdd' bmaptool: info: 100% copied bmaptool: info: synchronizing '/dev/sdd' bmaptool: info: copying time: 7m 22.2s, copying speed 4.6 MiB/sec Faster, but not too impressive. The speed is because bmaptool configures the block device for optimal writing of large sequential files. 4. Now I've generated the bmap file myself. Note, the real, correct bmap file can only be generated on the Fedora build server just after the image is created, so this example is artificial, and not correct, do not try to use it. And it will give better numbers than the real bmap file would give, I can explain why if needed, or see the docs. Anyway, I've made a sparse file out of the image, then generated the bmap file for it, and flashed it: # 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 # Now flash with the bmap file $ sudo ./bmaptool copy Fedora-x86_64-19-20130627-sda.raw.sparse /dev/sdd bmaptool: info: discovered bmap file '/home/dedekind/tmp/Fedora-x86_64-19-20130627-sda.raw.sparse.bmap' bmaptool: info: block map format version 1.3 bmaptool: info: 524288 blocks of size 4096 (2.0 GiB), mapped 176288 blocks (688.6 MiB or 33.6%) bmaptool: info: copying image 'Fedora-x86_64-19-20130627-sda.raw.sparse' to block device '/dev/sdd' using bmap file 'Fedora-x86_64-19-20130627-sda.raw.sparse.bmap' bmaptool: info: 100% copied bmaptool: info: synchronizing '/dev/sdd' bmaptool: info: copying time: 2m 36.2s, copying speed 4.4 MiB/sec Several times faster than dd. And yes, bmaptool can flash the .raw.xz file as well, you do not have to decompress. Please, fine the bmaptool documentation here: https://source.tizen.org/documentation/articles/bmaptool It is a bit out-of-date, but not much, will be updated soon. The tool is generic, not tizen-specific. Please, see the information about the project here as well: http://git.infradead.org/users/dedekind/bmap-tools.git/blob/refs/heads/deve… Note, the .xz support is only available in v2.6, which I did not release yet, so you need to take the sources, not the packages. The project is a python project, and it provides APIs so that other python projects could use the functionality. Here is an example of a bmap file can be found here: https://source.tizen.org/documentation/articles/bmaptool And yes, I suggest that Fedora could also generate and publish bmap files, if this is found to be useful. In Tizen IVI people are very happy to use bmaptool versus pain dd. Anyway, please, check the docs, give feed-back, ask questions. Thanks, and sorry for a messy e-mail :-) -- Best Regards, Artem Bityutskiy

9 24

Fwd: Broken dependencies: python-osmgpsmap
by Richard Shaw 16 Sep '13

16 Sep '13

Ok, I've been getting these messages for a while but I'm not the package owner for I didn't worry about it, however, it's been a couple of weeks so I decided to take a look to see how much work it would be. Now I'm really confused... There are two separate packages in Fedora: osm-gps-map python-osmgpsmap Both point to the same upstream URL. The description from upstream of osm-gps-map says it includes python bindings but there is not currently a separate sub-package generated... So what's the deal? Do one of these packages need to be retired? Richard ---------- Forwarded message ---------- From: <buildsys(a)fedoraproject.org> Date: Sun, Aug 11, 2013 at 7:35 AM Subject: Broken dependencies: python-osmgpsmap To: python-osmgpsmap-owner(a)fedoraproject.org python-osmgpsmap has broken dependencies in the rawhide tree: On x86_64: python-osmgpsmap-0.7.3-9.fc20.x86_64 requires libosmgpsmap.so.2()(64bit) On i386: python-osmgpsmap-0.7.3-9.fc20.i686 requires libosmgpsmap.so.2 On armhfp: python-osmgpsmap-0.7.3-9.fc20.armv7hl requires libosmgpsmap.so.2 Please resolve this as soon as possible.

4 18

Mouse focus stealing bug
by Maros Zatko 16 Sep '13

16 Sep '13

Hello dear Fedora comunity, I've hit very weird bug which happen to get very urgent now. Something (very likely GTK{2,3} but not sure at all) is stealing my mouse focus so that I cannot click anymore. Symptoms are in range from being able to click once or several times AFTER switching desktop (tag), to being able to click only with left button (with right being totally unresponsive) to not being able to click at all anymore until I kill Xorg. Killing Xorg was *the fix* -- for you to understand, after reboot I *had* to kill Xorg session three times, with spawning some GTK app in between runs so that I hit the issue and Xorg restart had the right effect. What happens now is that Xorg restart are NOT helping any more, i.e. after that it "works" for about 5 minutes and then it get progressively more and more wrong until I cannot click any more. My nowadays combo is Xmonad with nm-applet and some other basics plus firefox, xchat, pidgin and some gnome-terminals (and couple of other random stuff). To hit the issue is enough to spawn xchat and firefox in a clean session. I've been hitting the very same issue before when I was using Awesome WM, but I thought it was its issue so I've picked xmonad but after some time the same issues returned. So, dear Fedora community, I beg you for help. I have no idea how can I fix this, nor how can I debug it. Any help would be really welcome. Thank you, Maros

3 3

php-gettext
by Michael Schwendt 13 Sep '13

13 Sep '13

What's the full story here? php-gettext php-gettext-0:1.0.11-5.fc20.noarch isn't obsoleted php-gettext-0:1.0.11-4.fc19.noarch isn't obsoleted php-gettext-0:1.0.11-3.fc18.noarch isn't obsoleted php-gettext-0:1.0.9-3.fc15.noarch is oldest php-gettext < 0:1.0.11-3 obsoleted by php-php-gettext-0:1.0.11-8.fc20.noarch Searching a bit, there has been a rename to php-php-gettext and plans to retire php-gettext because it conflicts with the core module, but the package has been kept in the dist and mass-rebuilt several times: http://koji.fedoraproject.org/koji/packageinfo?packageID=9618 So, meanwhile, the Obsoletes tag is insufficient, and the package is available again. Is this intentional? Else, please retire it: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life # repoquery --whatprovides php-gettext php-common-0:5.5.2-1.fc19.x86_64 php-common-0:5.5.2-1.fc19.i686 php-common-0:5.5.0-0.10.RC3.fc19.i686 php-common-0:5.5.1-1.fc19.x86_64 php-gettext-0:1.0.11-4.fc19.noarch php-common-0:5.5.0-0.10.RC3.fc19.x86_64 php-common-0:5.5.1-1.fc19.i686

1 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel August 2013