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
So what was the decision/end result with the UEFI situation? Where does
OpenSUSE stand with the situation?
Regards
--
Chris Jones @ kernel.devproject(a)gmail.com
and oracle.kerneldev(a)gmail.com
OpenSUSE Linux x86_64 (PC)|Android (Smartphone)|Windows 7 (Laptop)|Windows XP (Gaming)
Linux kernel developer|Solaris kernel developer|Lead Developer of SDL|Lead Developer of Nest Linux
Gamer and Emulator nut|Web Services|Digital Imaging Services
Controllers: Rapier V2 Gaming mouse|Logitech Precision|PS3 controller|XB360 controller|Logitech Attack 3 j/stick
Emulators: Fusion|Gens|ZSNES|Project64|PCSX-R|Stella|WinVICE|WinUAE|DOSBox
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
Здравствуйте!
Скажите, пожалуйста, можно ли продавать, как в http://www.linuxcenter.ru/shop/licence/licences/open_suse_12_1_x86_64_with_… свои произведенные с помощью Suse Studio дистрибутивы (уже два сделал),через ООО или ИП? Если да, то какое соглашение нужно?
Спасибо заранее!
Сергей Шевцов
https://www.facebook.com/sshevts
Hello! I work in I.M. Sechenov First Moscow State Medical university of http://eng.mma.ru/ senior researcher. We want to create your distro opensuse-based Suse Studio. Would it be possible then to distribute on behalf of our university this distribution? Would it be possible to sell your distribution specialists in biology, medicine, psychology and pedagogy?
Thanks in advance!
Sergey
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
Dear friends,
The openSUSE boosters have been going through some changes lately. You
probably noticed some people left - one to play with ARM devices, another
doesn't paint green anymore and a third has his head in the cloud. Others left
for new things internally - all in all, leaving the team quite small. SUSE
responded by starting to hire new people and took this opportunity to see
where the booster team could do better.
So, today, while the team is not at full strength yet, we do have something to
announce. First of all, we've got a new team lead. Some of you might know him
as the Master of Money at KDE: Agustin Benito Bethencourt. He'll bring some
fresh ideas to the team and can help us stay Cool.
Second, to bring all openSUSE efforts in SUSE in one place, I will be joining
the Boosters team. Not much will change and I'll stay in Berlin for now but
I'll be working with them more.
So. No big changes anytime soon, but we'd wanted to let you know there's
something going on and we hope to be back at full strength in a few months,
with fresh ideas, energy and efforts to help openSUSE have fun!
Until then - we'll keep chippin' away at the build issues in 12.2 and the
other thing we've been doing.
love and hugs,
The Boosters
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
Hi,
here's a small summary of the 5th (coding) week. Last week I spent
most of my time with working on the cpio module. Finally I ended
up with a complete rewrite of osc's "old" cpio module. The
cpio implementation details are taken from the cpio 2.11 package.
Currently only the "new ascii" format is supported and we can
only handle regular files (this is sufficient for our needs). Here's
a small example how to use it:
# cpio_open is just a convenience method for CpioArchive(filename=fname)
with cpio_open(fname) as archive:
for archive_file in archive:
# print filename
print archive_file.hdr.name
# print contents
print archive_file.read()
It's also possible to pass a file-like object to a CpioArchive
instance (in this case we do not need to use the with statement).
Also it can be "easily" enhanced to support different cpio formats
(one just have to write the specific ArchiveReader and ArchiveWriter
classes:) ). The code is available at [1] and the testcases at [2].
Todo for this week:
* finish the build module
* start with working on the package fetching code
Marcus
[1] https://github.com/openSUSE/osc2/blob/master/osc/util/cpio.py
[2] https://github.com/openSUSE/osc2/blob/master/test/util/test_cpio.py
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
Hi!
Some more information about what I'm doing at time to make the
Software-Center cross-distro and usable with PackageKit.
At time I am in a pretty intense exam phase, so there are a little
less changes happening - more will be done after my biggest two exams
on 5th July are over.
Of course working hasn't stopped. Here's a short summary (I'll tell
some things again for better understanding)
The key element to get a working Software Center is PackageKit. When I
started the project, SC was incredibly slow. After some modifications,
it is now usable, which means that it will run with acceptable speed.
However, it is still much slower than it's native aptd version.
The current design of PackageKit allows only sequential processing of
transactions, meaning if one transaction (InstallPackages()) is
running, you can't run another one in parallel (GetDetails()). This
results in that odd case that users will not be able to browse the
software catalog while software is installed.
To solve that issue, I introduced the package cache, a SQLite cache of
all installed packages and their details. This worked well, but also
had all issues of a cache and was not very elegant and generally
disliked by many people, including me. So we looked for other
solutions and decided to implement "parallel transactions" after a
longer discussion.
"Parallel transactions" means that you will be able to run some
transactions, e.g. everything which reads the cache, in parallel to
others, for example one which installs packages. This will enable us
to not only show package details while installing stuff, but also to
fire many read transactions at the same time at get them processed
without delay. The final speed of PK will - of course - depend on how
well the backend is written.
Downside of this solution is that all backends have to be threadsafe
(or created processes and do IPC) and that this feature is non-trivial
to implement.
Richard Hughes (PackageKit maintainer) and I drafted the
specifications of parallel transactions, including some test-cases.
Essential for planning the implementation was that a running
transactions may never ever block existing ones. (Avoiding situations
like everything is waiting to release locks)
After planning, implementation started, where we now completely broke
backend API. First idea way to create one PkBackend instance per
PkTransaction, but after we did many parts of the implementation and I
had a working prototype already, Richard stated that initializing one
new backend per transaction is a bad idea and a big overhead. Another
problem which I had discussed with Daniel (aptcc backend maintainer)
before was that with this approach backends can't share cache
resources, as they don't have control over the running threads.
At first, we wanted to do a PkBackendPool, which would've contained a
pool of "activated" backend instances, but once again we avoided the
easy way to do it the right way(tm) (at least that's our impression
:P).
New solution is that there will be only one backend, but multiple
PkBackendJobs, which are submitted to the backend and executed. A
backend job is something like "install X,Y" or "get me the details of
package X".
Implementation is going on right now, and Richard is really amazing
with that, as he already updated some of the most difficult parts (I'm
writing exams, so not much time ^^). Of course this is still not done
yet.
There will be a PackageKit release of the new 0.8.x series we've been
working on the last weeks. This release will already contain many of
the SoC improvements, but I'd like to warn you not to use it in stable
distributions.
As soon as that is done, the PkBackendJob thing will be merged &
tweaked. - A lot of work from backend author will be needed too.
After PK is working properly (and probably even before all pieces are
at place) I'll go into SC again to fix some issues which were
bothering me a long time already. At time, PK is the number-one
priority, because without doing the work on PackageKit, a well-working
Software-Center is impossible.
I haven't seen that coming when I started my SoC, but hey, the changes
are awesome! Many other projects will also benefit from them, as there
are already some other efforts to write a SC on top of PK. (but
they're all in a pretty early state)
Next time, I won't write that much text, I somehow always feel the
need to explain every single step - probably a sideeffect from working
on cross-distro projects :-)
Expect some more news and a blogpost soon after I finished exams :-)
(I wanted have written a blogpost a month ago already, and the text is
nearly done...)
If you have questions, please ask or catch me on IRC (ximion,
Freenode) - I'll be 100% available efter 6th July again :-)
Cheers and thanks for reading!
Matthias
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
Hi,
Last week was spent on rewriting the python code base. The code is now
based on classes and each of the supported methods (httpls, ftpls,
etc) is now a separate class which derives from a common base class.
This supports addition of new methods at a later stage. Checking for
upstream packages upstream (on openSUSE repos for openSUSE packages)
and on sourceforge is not yet implemented. The new scripts were tested
with the upstream-tracker.txt file which was previously used as the
source of records (currently replaced by the Rails framework).
I plan to complete the python code work by adding the Sf and Upstream
classes and integrating it with the rails server this week. I also
plan to start working on implementation of custom regexp in the URL
fields. This would later help with DEHS imports.
--
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
Hello.
I hope to make this question in the right palce.
Sorry if I'm wrong.
Just a question: Must opensuse join to this campaign?
http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement
Debian has joined. And I think that is a way to say that we are the
owner of our hardware. Not other companys that want to "protect" like
a father or like a "big brother"
we are open, and want a open hardware, not a restricted one!
Only my opinion...
I have joined and signed
Thank's all !
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org