I am seeing this with an openSUSE 12.1 system at home, and also a
Factory system at work:
% host download.opensuse.orgdownload.opensuse.org has address 195.135.221.134
download.opensuse.org has IPv6 address 2001:67c:2178:8::13
And then, when running zypper patch or zypper up, I see
Retrieving: repomd.xml [error]
Download (curl) error for
'http://download.opensuse.org/update/12.1/repodata/repomd.xml':
Error code: Connection failed
Error message: Failed to connect to 2001:67c:2178:8::13: Network is unreachable
Alas, my provider nor that network at work support IPv6. Still, my
system has IPv6 enabled since roaming around on different networks,
IPv6 may be present, or even necessary there.
(This does not happen all the time, sometimes if I retry a bit later
the system uses IPv4 and everything works.)
Now, is this just a setup problem and I should simply and
unconditionally disable IPv6?
Or are some parts of our update or network stack in need of
some adjustments?
For the time being, unless this is just me running into this,
should we disable IPv6 on download.opensuse.org?
Gerald
--
Dr. Gerald Pfeifer <gp(a)suse.com> || SUSE || Director Product Management
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
Hi guys,
this is my first report about scanny for #1 week:
http://ruby-blog.pl/GSoC/2012/05/28/scanny-week-1/
--
Piotr Niełacny
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
OK, so this is something I'd like to start trying to get my arms around
so we can have a more comprehensive approach to dealing with bug reports
and increase the rate of resolution as well as the follow-up rate when
additional information is needed.
It seems that we have a few areas that we should be looking at:
1. There should be some sort of "screening" that takes place before a
bug is accepted - to ensure that the devs aren't seeing multiple copies
of the same bugs. I think it's fair to say that those who write code
would far rather *write code* than try to sort through duplicate bug
entries. While it's likely there still would be dupes with a screening
process, the incidence should be reduced.
2. There needs to be more of a "human" reply, especially on older bugs,
that are being addressed. Looking at the current Bugzilla stats, I see
that (for example) 12.1 has 183 bugs in a "NEEDINFO" state - there needs
to be some sort of consistent follow-up to ensure that the info needed to
fix the issues is provided, and if it isn't and the information can't be
obtained (because the issue cannot be duped, those looking at it don't
have the necessary hardware, etc), then the bug needs to be closed.
3. For older bugs, (such as on 10.3-11.3, which there are still open
bugs on), a determination needs to be made as to whether the current
supported releases have those issues, and if they do, the bugs need to be
updated. If they don't, then the bugs need to be flagged in an
appropriate way.
4. It would be extremely useful, I think - especially for the non-techie
audience - to put some specific training together on things like (a) how
to submit a bug and include the relevant information, (b) what to expect
with your bug and how to monitor progress, (c) how to provide additional
information when requested (and what to do if you've upgraded/moved to
another version/changed distributions/decided to go back to Windows/MacOS/
whatever) so the bug can continue to be evaluated by those evaluating it.
Ultimately, the goal of this project is to increase resolution rates,
reduce the time to resolution as much as possible, and to visibly improve
the bug resolution process so more people don't perceive (correct or not)
that reporting bugs is useless because they don't get resolved (and
actually, looking at the stats on bug status, I think it's pretty unfair
to say bugs aren't getting resolved. I see, for example, that of the
reported bugs on 11.1, for example, over 3/4 of the bugs are marked as
resolved.)
And overall across all releases of openSUSE, and SUSE Linux Professional/
SUSE Linux from 8.2 on, the bugs marked resolved are 13026/18285, which
is nearly 3/4.
75% isn't bad (the Pareto rule is 80/20, and on 11.1 we're actually
around 78% "resolved"), but I'm sure that if we can guide the process and
streamline it, we can increase that.
Of course those are just rough statistics and the reason bugs are marked
as 'resolved' isn't included in that - and there is a further breakdown
that can be done that might help identify trends that would be useful.
There's clearly more that we should be looking at, but these four areas
are a good place to start. For my own part, I'm willing to do more than
talk and discuss the ideas, but it's going to take more than just one
person working in his spare time to move this along.
I also think something similar to this should be done for FATE, but
that's perhaps a topic for another day. :)
Jim
--
Jim Henderson
Please keep on-topic replies on the list so everyone benefits
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
Hello!
This is my first week work report for the Upstream Tracker Project. I
have chosen to start my work by implementing the web interface first.
This is because, by having a functional web interface, we could start
crowd sourcing the data to proceed further. Also, the base work for
the python scripts are already in place.
Here is the list of things I have managed to do this week.
1. Created a rails application to manipulate records. Each record
consists of data required to obtain the latest version of an
application such as package name, method, URL etc.
2. Added support for XML and JSON Formats.
3. Added a page to view records which are erroneous after being processed.
4. Added color coding on main page to indicate record status. Red for
Error, Green for OK and None for not processed.
5. Added Basic validation for user input.
6. Wrote pycurl scripts to Add, Delete, Update and Show records.
7. Set up a home server to host the rails application for feedback and
testing. This can be found at nbprashanth.no-ip.org.
List of things planned for the upcoming week:
1. Evaluate logging requirements and implement a solution.
2. Update the records model in the rails app to include version
information after processing is complete.
3. Fill in gaps and test the rails app.
the code is hosted at :
1. https://github.com/nbprashanth/Upstream-Tracker-Rails
2. https://github.com/nbprashanth/Upstream-Tracker-Python
The project description can be found at
http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/nbprasha…
--
Regards,
N.B.Prashanth
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
Hi,
This is my first GSoC report for the new One Click Install system. I
had been busy with exams for some time, so, this is an update on the
progress so far. I have started the user interface, and am closely
following the mockup. So far, I have implemented two menus for the
main screen and the settings. I am planning to implement the dynamic
part of the interface as a set of Widgets which I will integrate in
the main UI. On the backend side, I have implemented the parser for
the YMP file, which currently takes a YMP file as input and retrieves
the set of repositories involved and packages to be installed. I have
also managed to add repositories using libzypp. Currently, I am not
checking for any exceptions and errors, but plan to incorporate this
later on.
Right now, I am working on implementing a test case for the Parser,
implement the rest of the UI, and do some prelimnary work on
installing the read packages. I will also work side by side on
packaging the software.
Regards,.
Saurabh
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
Hi,
This is my first report of what we've been doing regarding the fdisk
redesign project.
1) What's been done in previous weeks, before SoC development officially
started:
- Consolidate and agree on internal fdisk API and data structures with
Petr and mainstream util-linux community.
- Isolate DOS specific label logic. This is important since DOS
partition table context was deeply embedded in the heart of fdisk logic,
making it impossible to implement a new API. Now DOS, like all other
supported labels, has its own file and functions.
- Fixed two nasty bugs that are currently present in most distros.
http://git.kernel.org/?p=utils/util-linux/util-linux.git;a=commit;h=50f6100…http://git.kernel.org/?p=utils/util-linux/util-linux.git;a=commit;h=44d2fc8…
- Generic code cleanups.
2) What's been done during week 1:
- Implemented and merged in mainstream the initial functions and data
structures of the new internal API.
http://git.kernel.org/?p=utils/util-linux/util-linux.git;a=commit;h=823f0fd…
- Implement dynamic debug support. By reading environment variables
($FDISK_DEBUG) developers and users can quickly be informed of important
events during that occur during fdisk's entire execution.
http://git.kernel.org/?p=utils/util-linux/util-linux.git;a=commit;h=f7b1f75…
- Generic code cleanups.
3) What's immediately next?
- Add device topology and geometry to the API. We have decided to go
strictly with libblkid for the former, therefore fdisk will probably
depend 100% on it. This enables us not to reinvent the wheel, specially
since this blkid is also part of util-linux.
--
All in all I believe we have had a good, solid start. It really helps
that Petr, I and util-linux maintainer are quite familiar with the code,
thus making quick and important progress. Petr's willingness and
knowledge really make a difference and couldn't be happier working with
him.
Thanks,
Davidlohr
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
General question to those more closely involved in oS project management
- is there a tool we have access to that can help track tasks and
progress on projects within the oS project?
I'm thinking something like a Kablink (or Vibe OnPrem) task list. I've
got Vibe installed at home with a limited number of users, but I'd rather
track the bugzilla/bug process project in a more visible way than on a
private server in my house. :)
If we don't, I can set something on on the Kablink site so those who are
interested can follow along and help document the tasks that need to be
completed and their progress.
Thanks,
Jim
--
Jim Henderson
Please keep on-topic replies on the list so everyone benefits
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
Heya all,
The current status of http://en.opensuse.org/openSUSE:LinuxTag Berlin
- We've got a booth. I'm quite confident it'll be 14m2, have 2 tables and 6
chairs. Nothing else, LT is out of budget for furniture :(
- We will have 40 crates of openSUSE beer to hand out for €1 donation to LT
- We'll do that in collaboration with Fedora, which hands out hotdogs
- I have a few hundred DVD's, some flyers and some posters here. Will
probably walk into a copy shop to create some more.
- don't know yet how many tickets I'll get but anyone who helps at LT will
get a free ticket. Helping =/ hacking at the booth! We won't have place to
sit for anything other than showing ppl something.
-Tuesday evening is booth setup. Pls come to LT location and help out a bit!
Now what is still to do. I like to do the Booth program thing, but that
requires a big screen and presentations. I'll do something every day on
installing ownCloud on openSUSE (demoing Studio and OBS-for-endusers while
at it) and Christian Boltz was willing to do something on AppArmor.
Christian, if you pick a time and add how many times you're willing to do
it, we're only looking for one more :D
Then we need to make sure we get the right things from Nue. I know some
people are going by car so I hope they can bring some stuff. At the least
the box with booth-stuff like tape, pens etcetera.
We need (please tell me if Nue has this):
- some stand(s) to put our merchandise on and hang up posters
- a big screen for the presentations (one of the two big touch-screen-
computers? is transport doable for those?)
- 2-3 power cord extensions (I know Nue has this, don't forget pls)
- I know I forgot things as it's past 1:10 and I need sleep, ideas?
/Jos
Hey all!
As SUSE is gearing up for SLE 12, SUSE is doing more in openSUSE. Features
like systemd and grub2 are examples and more will follow. That is good for
openSUSE, but it can also lead to conflicts. Most of our engineers are
involved in other upstream projects and know the drill of working with
communities, but even then there's a risk that all this 'tramples' a bit
over what we've been doing in openSUSE. That's called the 'Freight Train'
effect, see [1] for a bit more background.
We'd of course like to do what we can to smoothen this out and discussed
this a bit with the openSUSE Boosters and some other people. One result was
that we decided to set up a special mail address with a number of people
where community members who get bitten by the freight train can yell at.
Obviously the goal is to then investigate and do something about it.
We try to have a small number of people on there, preferably including SUSE-
ians from Nuremberg and Prague so they can approach people directly when
needed and talk/hug/beat some sense in them and/or coach/guide.
The team aims to help with TECHNICAL issues. Merge requests being ignored,
patches rejected. It's not about solving bugs, helping users with questions,
or doing something about personal conflics. There are other places for those!
Right now, the team consists of AJ, Henne and myself - we'd like a SUSE
volunteer from Prague. If anyone else is willing to step up, that's good
too. Note that we look for technical people who know many community members
and have some social and coaching skills.
Some people might think there is or will be no problem - the mail address
won't get much issues to solve so we can kill it off soon enough. We're fine
with that! It might also get unrelated or other issues, which we'll try to
relay those to the board, sysadmins or opensuse-project.
[1] http://en.opensuse.org/openSUSE:Freight_Train
Love, hugs and all that,
Jos P