I'm happy to announce that Kubuntu Artful beta 1 milestone released today, having passed all the mandatory testing, thanks to lots of testers! Thanks so much to each of you.
If possible, we'll also be participating in Beta 2 with the next round of KDE bug-fix releases for the last testing milestone before release of Kubuntu 17.10 on 19 October 2017.
Release notes: https://wiki.ubuntu.com/ArtfulAardvark/Beta1/Kubuntu
If you would like to help us seed the torrents, go to http://torrent.ubuntu.com:6969/. To quickly find all the betas: control f and type beta.
Join us in freenode IRC: #kubuntu-devel with praise, help, or bug reports.
Showing posts with label bug reports. Show all posts
Showing posts with label bug reports. Show all posts
Thursday, August 31, 2017
Wednesday, July 26, 2017
Artful Alpha 2 release candidate is ready for testing!
Test if you can, on real hardware if possible, in virtual machines if not.
Kubuntu Desktop amd64 testcases in Artful Daily:
http://iso.qa.ubuntu.com/qatracker/milestones/379/builds/153034/testcases

The label "Daily" will change once the Alpha 2 has been milestoned. Remember to report bugs and link them on the qa site. The easy way to file bugs is in the commandline: ubuntu-bug packagename. Ask us in IRC (#kubuntu-devel) if you need a package name.
Kubuntu Desktop i386 testcases in Artful Daily:
http://iso.qa.ubuntu.com/qatracker/milestones/379/builds/153035/testcases
It is so important to get this preliminary testing done if we want a 32-bit Alpha 2 ISO! We could not do an alpha 1 of Artful for this reason.
Valorie
PS: sorry for the late notice; I'm currently in Spain at KDE Akademy. You can subscribe to get the testing notices directly: http://iso.qa.ubuntu.com/qatracker/subscription
Saturday, November 1, 2014
Filing bug reports for fun and profit
Profit? Well, I didn't make money from filing a bug about redshift, but I did get the lovely little application running on my computer again.
Since jumping to an testing install of Plasma 5 in my upgraded Kubuntu, I've been filing bugs as I find things not working. It took me a few days to notice that redshift no longer worked, because I didn't always use it. But when I had my eyes dilated for my annual eye exam, I needed it! And it crashed.
I love filing bugs using ubuntu-bug from the commandline. I would love to see KDE build this capability as well, because the little application gathers useful information automatically, and uploads it to the bug tracker. Man ubuntu-bug says it reports problems to your distribution's bug tracking system, using Apport to collect a lot of local information about your system to help the developers to fix the problem and avoid unnecessary question/answer turnarounds. Dr. Konqui does this sometimes, but a little cli app would be nice as well.
You can read my bug report here if you like, but to make a long story short: there is still no working Plasma 5 widget, but redshift is a commandline application. The kindly person who answered my bug report sent me to the website, where I found that I could create my own config file, which might be a workaround to the lack of a widget, but it works. The gtk widget did not work, by the way.
Writing a config file sounds daunting, but I just copy/pasted the working config on the website, changed it to fit my system, and saved it as ~/.config/redshift.conf
In the commandline, when I typed redshift & - my screen pinked up a bit. Lovely!
Since jumping to an testing install of Plasma 5 in my upgraded Kubuntu, I've been filing bugs as I find things not working. It took me a few days to notice that redshift no longer worked, because I didn't always use it. But when I had my eyes dilated for my annual eye exam, I needed it! And it crashed.
I love filing bugs using ubuntu-bug from the commandline. I would love to see KDE build this capability as well, because the little application gathers useful information automatically, and uploads it to the bug tracker. Man ubuntu-bug says it reports problems to your distribution's bug tracking system, using Apport to collect a lot of local information about your system to help the developers to fix the problem and avoid unnecessary question/answer turnarounds. Dr. Konqui does this sometimes, but a little cli app would be nice as well.
You can read my bug report here if you like, but to make a long story short: there is still no working Plasma 5 widget, but redshift is a commandline application. The kindly person who answered my bug report sent me to the website, where I found that I could create my own config file, which might be a workaround to the lack of a widget, but it works. The gtk widget did not work, by the way.
Writing a config file sounds daunting, but I just copy/pasted the working config on the website, changed it to fit my system, and saved it as ~/.config/redshift.conf
In the commandline, when I typed redshift & - my screen pinked up a bit. Lovely!
Saturday, April 19, 2014
Weeeee, Kubuntu 14.04 is out! and already looking to the future
The past week has been exhilarating and exhausting for our Kubuntu crew. I'm sure the other *buntu teams were working just as hard. Not just packaging, because that goes on all the time, though not at this intense pace. But the attention to detail, the testing, polishing, patching, discussion with developers to get those patches upstream, coordination with Debian, cleaning up copyright files, man pages and other documentation, making screen shots, our user docs and new website, more testing, more polish.... it was truly an amazing effort.
I used `ubuntu-bug` from the cli more than I ever have before, testing out the betas. It was an amazing experience to file the bug, and then see it fixed within the day! This happened again and again. The entire Ubuntu ecosystem really works well together. My thanks to those developers who read and respond to those bug reports.
What I love about Kubuntu is how everyone pitches in. All of us try to maintain balance in our lives, so that there is time for leisure and enrichment, along with work. Also, the work is fun, because the team enjoys one another, posting fun links, joking around, but continuing to work away on our todo lists. Even those who didn't have time for packaging, often stopped by the devel channel to find out what needed testing. It all helped!
Since I'm not a devel, all this was inspiring rather than exhausting. So I had the time and energy to spend time helping out folks with questions and trouble in #kubuntu and #kde. That felt great! We were able to answer most of the questions, and overcome most of the difficulties.
One issue that came up quite a few times in the last couple of days, was PPAs. On a clean install, of course all old PPAs are blown away. On an upgrade, however, they can linger and cause lots of perplexing problems. Official PPAs like backports are fine, but specialty ones should be removed before upgrading. If you need them, you can always re-add after the upgrade. For the same reason, unpin any packages you have pinned.
It is really fabulous to be able to present the latest KDE software into our Kubuntu LTS. This will give us the freedom to try out the newest stuff from KDE based on the sparkly new Frameworks, Plasma Next and so forth, in our next release. So, our users will be able to use software supported for five years if they want, while also having the option to install 14.10 (if all goes well) and check out the newest.
I used `ubuntu-bug` from the cli more than I ever have before, testing out the betas. It was an amazing experience to file the bug, and then see it fixed within the day! This happened again and again. The entire Ubuntu ecosystem really works well together. My thanks to those developers who read and respond to those bug reports.
What I love about Kubuntu is how everyone pitches in. All of us try to maintain balance in our lives, so that there is time for leisure and enrichment, along with work. Also, the work is fun, because the team enjoys one another, posting fun links, joking around, but continuing to work away on our todo lists. Even those who didn't have time for packaging, often stopped by the devel channel to find out what needed testing. It all helped!
Since I'm not a devel, all this was inspiring rather than exhausting. So I had the time and energy to spend time helping out folks with questions and trouble in #kubuntu and #kde. That felt great! We were able to answer most of the questions, and overcome most of the difficulties.
One issue that came up quite a few times in the last couple of days, was PPAs. On a clean install, of course all old PPAs are blown away. On an upgrade, however, they can linger and cause lots of perplexing problems. Official PPAs like backports are fine, but specialty ones should be removed before upgrading. If you need them, you can always re-add after the upgrade. For the same reason, unpin any packages you have pinned.
It is really fabulous to be able to present the latest KDE software into our Kubuntu LTS. This will give us the freedom to try out the newest stuff from KDE based on the sparkly new Frameworks, Plasma Next and so forth, in our next release. So, our users will be able to use software supported for five years if they want, while also having the option to install 14.10 (if all goes well) and check out the newest.
Wednesday, March 20, 2013
Testing, another way to help your favorite FOSS project
I've done some testing before, but this time I want to document it here, so I can come back later and remind myself of some of the critical steps, and so others new to testing can get the confidence to start contributing in this way as well. I'm mainly using Kubuntu as an example here, but applications and desktops need testing as well. If you are using a non-Debian distribution, the commands I use will not work. Consult your documentation for equivalents.
I'm lucky in that I have some extra computers I can use as testing machines. But when I didn't, I used virtual machines, and those aren't too difficult to set up. However, I'll discuss that another time.
In general, please read the /topic in your development IRC channel, then ask about testing, or join the testing channel if there is one. Often you'll be given bug numbers to test for a specific package -- please be sure to comment completely in the actual bug report, not just give feedback in the channel. Be sure to ask what information is necessary. ISO testing is another place where folks are needed; again, your devel channel /topic should give you some good information. And don't forget to join and read the relevant lists as well; no one can be in IRC all the time.
Right now, some packages need testing in the next Kubuntu distribution release. I prefer using the command line for things like this, because 1. in the console, upgrades happen "under" the desktop, so config files are updated cleanly, and 2. it is much faster. So first, the upgrade. Instructions to do this in the GUI: https://help.ubuntu.com/community/RaringUpgrades/Kubuntu
If your computer is already on, log out of your session. At the login screen, rather than typing in your password, hit Control + Alt + F2. Then log into first your computer with your username and password, then
sudo update-manager -d
This updates all your repositories to the development release. Next, the start the actual upgrade:
sudo do-release-upgrade -d
You'll have to OK a few things, so it's not entirely unattended. After the packages are all downloaded, the upgrade still takes quite awhile. Sometimes I start this at night, and just check on things in the morning.
Next, you'll need to install the package, or build the application from a tarball, or source. Depending on your distro tools, this might vary a bit.
sudo add-apt-repository ppa:
This will download and register the public key, as well as adding the repository. Then you can simply install the package via the command line or using the GUI tools you prefer.
cd ~/kde/src/
wget http://download.kde.org/download.php?url=stable/phonon/4.4.4/src/phonon-4.4.4.tar.bz2
tar xf phonon-4.4.4.tar.bz2
cd phonon-4.4.4 && mkdir build && cd build && cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=debugfull $HOME/kde/src/phonon-4.4.4
sudo make install
I'm not sure that building phonon in my home folder was a good idea, but since I build Amarok locally, I've gotten into the habit of doing that.
So now you have your package or packages, and can do the tests, and report your results. Have fun!
I'm lucky in that I have some extra computers I can use as testing machines. But when I didn't, I used virtual machines, and those aren't too difficult to set up. However, I'll discuss that another time.
In general, please read the /topic in your development IRC channel, then ask about testing, or join the testing channel if there is one. Often you'll be given bug numbers to test for a specific package -- please be sure to comment completely in the actual bug report, not just give feedback in the channel. Be sure to ask what information is necessary. ISO testing is another place where folks are needed; again, your devel channel /topic should give you some good information. And don't forget to join and read the relevant lists as well; no one can be in IRC all the time.
Right now, some packages need testing in the next Kubuntu distribution release. I prefer using the command line for things like this, because 1. in the console, upgrades happen "under" the desktop, so config files are updated cleanly, and 2. it is much faster. So first, the upgrade. Instructions to do this in the GUI: https://help.ubuntu.com/community/RaringUpgrades/Kubuntu
If your computer is already on, log out of your session. At the login screen, rather than typing in your password, hit Control + Alt + F2. Then log into first your computer with your username and password, then
sudo update-manager -d
This updates all your repositories to the development release. Next, the start the actual upgrade:
sudo do-release-upgrade -d
You'll have to OK a few things, so it's not entirely unattended. After the packages are all downloaded, the upgrade still takes quite awhile. Sometimes I start this at night, and just check on things in the morning.
Next, you'll need to install the package, or build the application from a tarball, or source. Depending on your distro tools, this might vary a bit.
Building from source
For Amarok, Myriam has a great blog post about how to build from git: http://blogs.fsfe.org/myriam/2009/09/26/compiling-amarok-from-git-locally-full-summary/, so I won't cover that. If you doing a local build of a different package, the steps will be similar. Consult the documentation for details. This blog post is kept updated, and deals with lots of different distributions.Install from a PPA
To install a package from a PPA, in Debian-based distros, there is an easy way to add it (addrepo in Debian):sudo add-apt-repository ppa:
This will download and register the public key, as well as adding the repository. Then you can simply install the package via the command line or using the GUI tools you prefer.
Build from a tarball
To get the tarball, cd to the directory where you want to unpack it, then wget the file. As as example, here's how I built phonon 4.4.4 from the tarball:cd ~/kde/src/
wget http://download.kde.org/download.php?url=stable/phonon/4.4.4/src/phonon-4.4.4.tar.bz2
tar xf phonon-4.4.4.tar.bz2
cd phonon-4.4.4 && mkdir build && cd build && cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=debugfull $HOME/kde/src/phonon-4.4.4
sudo make install
I'm not sure that building phonon in my home folder was a good idea, but since I build Amarok locally, I've gotten into the habit of doing that.
So now you have your package or packages, and can do the tests, and report your results. Have fun!
Subscribe to:
Posts (Atom)