RE: fedora-rpmdevtools (was RE: spectool-1.0.2)
by Erik LaBianca
> > I'd say we should just make a format that we expect .src.rpm and
md5sum
> > announcements in, and ask people to conform to that. I think quick
and
> > effective QA will be sufficient incentive.
>
> For average size packages, MD5 checksums and GPG signatures are not
> needed at all. The included tarball and maybe 1-2 patches can and must
be
> verified. Signatures get important for large packages, which include
lots
> of patches, for instance.
>
Given all the rhetoric on this list and on the fedora.us website, I see
no reason why rpm signatures on packages and md5sums should not be
required. They're easy to create. If they're not going to be required,
then we need to relax the requirements[1,2,3] for GPG signing everything
that goes into bugzilla too. Who determines when a package is "large
enough" to require a valid signature?
IMO, this kind of ambiguity is killing the project. It's impossible to
streamline a workflow when you allow for every possibility under the sun
at every step.
Personally, I feel that package submissions should be GPG-signed, and we
should eliminate posting the md5sums for the .src.rpm. Clearsigned
md5sums provide some assurance that the author hasn't changed the
package since it was QA'd, and provide a valuable addition to the QA
review, but not the initial package submission.
[1] http://www.fedora.us/wiki/PackageSubmissionQAPolicy
[2] http://www.fedora.us/pipermail/fedora-devel/2003-March/000459.html
[3] http://www.fedora.us/wiki/PUBLISHCriteria
--erik
20 years, 2 months
Fedora Bug Day Tomorrow: March 3rd 2004: Don't Bug Mark Day
by Jef Spaleta
What: Fedora Bug Day: Learn to be a package shepherd
Help us out with Fedora Core triage by picking your favorite
Fedora Core package and acting as its community shepherd, by helping
the package maintainer keep up with bug reports and submitted patches
and so on and so forth.
Alan Cox I think said it best:
"Track the bugs in your favorite package/component:
* try to make a few minutes everyday to look through the new bugs filed
in the last day for the package you want to watch.
* Sign up for the upstream mailing lists and bug tracking system, so you
can more effectively be able to move bugs reported to Fedora upstream
where they are more likely to be fixed."
And to put a finer point on it Warren Togami adds:
"Most projects don't have anything like an effective bug tracker of
their own. Because of that, what we need are volunteers to serve as
liaison to upstream projects. They should be members of those upstream
mailing lists and pay attention to news/patches/security alerts there.
Such helpers if they are diligent would be like assistants to the
package maintainers, and learn things as they go as well as gain trust
in the process"
When: March 3rd, starting at 14:00 UTC (09:00 EST)
Where: #fedora-bugs channel on freenode irc network
How:
Come to the #fedora-bugs channel on the freenode irc network tomorrow
and be a part of the discussion. Instead of writing a very long drawn
out explanation of what you should be doing as a package shepherd. I'll
just point you to an example.
http://www.ottolander.nl/gnome-panel/
I think leonardjo created a very useful shepherding tool with this
simple static table. I think people might be able to do a lot of good
taking this static table summary example and reusing it for other
packages in Fedora Core. Poor Mark, he had to be the guinea pig package
maintainer for leonardjo's proactive shepherding experiment. So instead
of just picking on Mark, maybe its time to pick on..err i mean help...a
few more package maintainers as well. So come on over to the
#fedora-bugs channel tomorrow, pick a fedora core package you would like
to start shepherding and start digging into the steaming pile of bugs
waiting for you in bugzilla.
What else:
And if you can't be a package shepherd just yet, you're you can still be
useful for general Fedora Core Triage, and help clean out
the cobwebs in bugzilla so developers can find the bugreports that need
attention.
Huh: No Clue What I'm talking about when I say the phrase Fedora
Triage?
Take a quick look at the fedora-triage-list archives:
https://lists.dulug.duke.edu/pipermail/fedora-triage-list/
These messages should hopefully tell you what its all about in more
detail:
http://tinyurl.com/ywma3 - Summary of my vision for Fedora Triage
http://tinyurl.com/23alw - My short term goals and long term plan
-jef"black belt cat herder"spaleta
20 years, 2 months
RE: fedora-rpmdevtools (was RE: spectool-1.0.2)
by Erik LaBianca
> >
> > fedora-installkey (install a key from keyserver into the fedora rpm
> > keyring)
>
> This would be a really good idea! Have you manage to be able to
script
> the removal of all signatures from that key though, so you can export
a
> keyfile that wont cause rpm to be b0rked?
I have signature removal scripted. However it isn't working. Removing
all uid's and all signatures doesn't seem to work correctly, and I
haven't been able to strip a key by hand successfully, so I'm stuck. I'd
appreciate some help :)
>
> > fedora-qastart (download srpms+md5sums from bugzilla, verify them,
> > verify sources using spectool, output prelimary qa checklist)
> > fedora-qatemplate (create a qa template to paste fedora-qatest input
> > into, gpg sign it, maybe submit it to bugzilla eventually too)
> >
>
> This would be tough, because there is currently no one standard way of
> putting it into bugzilla. Some people use the URL field, while others
> post a link to it in the comments, while others (unhappily) never
update
> that link with package updates and I have to go fishing for it...
I'm somewhat successfully downloading stuff from bugzilla. I just
download the bugzilla page source, and look for "http://.*\.src\.rpm"
and "http://$1.*md5.*". For the stuff I've tried, it works well. This
way it only catches clickable links. If we want it to catch url field
entries as well, it wouldn't be a difficult change.
I'm sure there are some entries that will confuse it, but they could be
coded around.
I'd say we should just make a format that we expect .src.rpm and md5sum
announcements in, and ask people to conform to that. I think quick and
effective QA will be sufficient incentive.
The stuff I have is available at http://www.ilsw.com/~erik/ if anyone is
interested.
--erik
20 years, 2 months
kernel-2.4.22-1.2174.nptlsmp + kiobuftest fails???
by Davide Rossetti
hi all,
I'm experimenting a bit with kiobuffers in 2.4.22-1.2174.nptlsmp [plain
rpm kernel]
- I took arch/cris/drivers/examples/kiobuftest.c
- compiled and insmod'd it
- mknod /dev/kiobuftest c <major> 0
- run the user-mode test ktest.c (attached)
[note: O_DIRECT in open is just a trie, it doesn't modify the result.
It is there to test whether the O_DIRECT code path does something better...]
problem is that map_user_kiobuf() often puts 0's in maplist[i] for
some/all i.
[root@xeone driver]# ./ktest
buf=0xbf403008 addr=0xbf404000 len=8192
[root@xeone driver]# ./ktest
buf=0xbf4c6008 addr=0xbf4c7000 len=8192
[root@xeone driver]# ./ktest
buf=0xbf48f008 addr=0xbf490000 len=8192
[root@xeone driver]# dmesg
nr_pages == 2
offset == 0
length == 8192
buf == 0xbf404000
page_add(maplist[0]) == 0xff8cd000
page_add(maplist[1]) == 0x00000000
nr_pages == 2
offset == 0
length == 8192
buf == 0xbf4c7000
page_add(maplist[0]) == 0x00000000
page_add(maplist[1]) == 0xff9cb000
nr_pages == 2
offset == 0
length == 8192
buf == 0xbf490000
page_add(maplist[0]) == 0xffa90000
page_add(maplist[1]) == 0x00000000
[root@xeone driver]# dd if=/dev/kiobuftest of=miao bs=8192 count=1
1+0 records in
1+0 records out
[root@xeone driver]# dmesg |tail
nr_pages == 2
offset == 0
length == 8192
buf == 0x09650000
page_add(maplist[0]) == 0xffa91000
page_add(maplist[1]) == 0x00000000
[root@xeone driver]# dd if=/dev/kiobuftest of=miao bs=$[2*8192] count=1
1+0 records in
1+0 records out
[root@xeone driver]# dmesg |tail
nr_pages == 4
offset == 0
length == 16384
buf == 0x08ee8000
page_add(maplist[0]) == 0xffaa9000
page_add(maplist[1]) == 0xff8d9000
page_add(maplist[2]) == 0x00000000
page_add(maplist[3]) == 0x00000000
so it seems that sometimes I get a kernel virtual address = 0...
it is strange as the code in memory.c:get_user_pages(), called by
map_user_kiobuf(), has guards against it happening:
if (pages) {
pages[i] = get_page_map(map);
/* FIXME: call the correct function,
* depending on the type of the found page
*/
if (!pages[i])
goto bad_page;
page_cache_get(pages[i]);
}
seems like there is an error which is not propagated up to the caller of
map_user_kiobuf()
I'm compiling a plain 2.4.25 + dprintk active to double check....
regards
20 years, 2 months
fedora-rpmdevtools (was RE: spectool-1.0.2)
by Erik LaBianca
>
> * version 1.0.2
> * some tidying work
> * replace option -D/--dummy with -n/--dryrun/--dry-run
> * specify what to get/list as options (-s/--source ..., -p/--patch
...,
> -S/--sources, -P/--patches, -A/--all) with '--all' as default
> * list files if no mode options are given
> * work properly on spec files with subpackages
>
Great tool! Thanks!
What are the chances of getting it included with fedora-rpmdevtools,
maybe as fedora-spectool or something?
I've got a several scripts that I'd like to see get ironed out and added
as well...
fedora-installkey (install a key from keyserver into the fedora rpm
keyring)
fedora-qastart (download srpms+md5sums from bugzilla, verify them,
verify sources using spectool, output prelimary qa checklist)
fedora-qatemplate (create a qa template to paste fedora-qatest input
into, gpg sign it, maybe submit it to bugzilla eventually too)
--erik
20 years, 2 months
spectool-1.0.2
by Nils Philippsen
Hi,
spectool-1.0.2 is available at:
http://people.redhat.com/nphilipp/spectool/spectool-1.0.2.tar.bz2
Changelog:
* version 1.0.2
* some tidying work
* replace option -D/--dummy with -n/--dryrun/--dry-run
* specify what to get/list as options (-s/--source ..., -p/--patch ...,
-S/--sources, -P/--patches, -A/--all) with '--all' as default
* list files if no mode options are given
* work properly on spec files with subpackages
Nils
--
Nils Philippsen / Red Hat / nphilipp(a)redhat.com
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
20 years, 2 months
DVD backups - bug or feature?
by Bob Billing
I spent a few frustrating hours yesterday turning DVD+R blanks into
coasters before I realised that there seems to be a deep problem with
the whole DVD mechanism. Since this seems to be a bug in the philosophy
of the system, rather than any specific module, I hope I can raise it
safely here.
My root partition on this system contains about 6.2G of files. This
includes things like the entire Hubble sky survey and the complete
Ordnance Survey map database for the UK. Backing it up as a bzipped tar
file gave me 2165096516 bytes of data. This is just over 2G - in fact it
is hex 810CC044. I then burned this on DVD with growisofs.
When I mounted the resulting DVD the file had shrunk to 835652 bytes.
This is in fact 000CC044. The "cruft" option had cut in and removed the
high byte of the file length.
Now this is the problem: Is mkisofs/growisofs right to allow a file over
2G, and mount is wrong? Or is mount right, the top bit of the file
length should never be set and mkisofs should have rejected it?
Either way it seems that as a DVD is longer than 4G there is no way,
within the standard, of burning a DVD that contains a single 4.7G file.
So should I:
1) Report a bug in mkisofs?
2) Report a bug in mount?
3) Develop a workaround (I already have one)?
4) Use a different filesystem?
--
Robert Billing, Tanglewood,
01344-772849 64, Pinehill Road,
rbilling(a)tnglwood.demon.co.uk Crowthorne,
http://www.tnglwood.demon.co.uk/ Berks, RG45 7JR
20 years, 2 months
tcltk
by Alain
hello,
some old programs do not work or to be recompiled with new tcltk.
is a compatibility package with 8.3.* possible ?
for use this old programs with FC2, I have recompiled some SRPMS (i.e.
python, rythmbox, ...) with tcltk 8.3, but this is not a good solution
for many users.
(sorry for my bad englih)
--
Cordialement
N'envoyez pas de documents au format Word ou PowerPoint.
http://www.fsf.org/philosophy/no-word-attachments.fr.html
20 years, 2 months
Sharp Zaurus cradle and kernel 2.6 : khubd oops
by Matthias Saou
Hi,
I've been trying to use my Sharp Zaurus' (handheld running Linux) cradle
again, as support for usbnet is now in the mainstream kernel, unlike when
I had just purchased it, as it needed to be patched into a vanilla kernel.
It basically works, and quite easily : The Zaurus gets its own IP address
as soon as it's plugged into the cradle, and all I needed to do was create
a configuration file for an usb0 interface on my laptop with the IP
address that the Zaurus has as its default gateway. From there, one
iptables line for masquerading and there goes the Zaurus on the Internet
automatically when "dcocked", cool.
The problem is that the connection is "flaky" and the usb0 interface on
my laptop keeps going up and down until I finally get an oops. Yesterday
I got a lot more of the "waiting for usb0 to become free" than today
before actually getting the oops, but in the end I did too.
This is with kernel 2.6.3-2.1.242. If anyone knows what the problem could
be, or where I can report this problem (and if more info is needed), I'd
appreciate.
Matthias
[...]
hub 2-0:1.0: port 1 disabled by hub (EMI?), re-enabling...<6>usb 2-1: USB disconnect, address 4
usb0: unregister usbnet usb-0000:00:1d.1-1, Sharp Zaurus SL-5x00
divert: freeing divert_blk for usb0
usb 2-1: new full speed USB device using address 5
divert: allocating divert_blk for usb0
usb0: register usbnet at usb-0000:00:1d.1-1, Sharp Zaurus SL-5x00
ip_tables: (C) 2000-2002 Netfilter core team
hub 2-0:1.0: port 1 disabled by hub (EMI?), re-enabling...<6>usb 2-1: USB disconnect, address 5
usb0: unregister usbnet usb-0000:00:1d.1-1, Sharp Zaurus SL-5x00
divert: freeing divert_blk for usb0
unregister_netdevice: waiting for usb0 to become free. Usage count = 4
unregister_netdevice: waiting for usb0 to become free. Usage count = 4
usb 2-1: new full speed USB device using address 6
Unable to handle kernel NULL pointer dereference at virtual address 000000c8
printing eip:
22876146
*pde = 00000000
Oops: 0000 [#1]
CPU: 0
EIP: 0060:[<22876146>] Not tainted
EFLAGS: 00010293 (2.6.3-2.1.242)
EIP is at usb_ifnum_to_if+0x5/0x3d [usbcore]
eax: ffffff1c ebx: 00000001 ecx: 00000000 edx: 00000001
esi: 00000001 edi: ffffff1c ebp: 00000000 esp: 211fbe4c
ds: 007b es: 007b ss: 0068
Process khubd (pid: 78, threadinfo=211fb000 task=211e1980)
Stack: 00000000 00000001 1bb546e0 2287c40c 1bb546cc 00000000 1bb546cc 1bb546e0
ffffff92 1523a8b4 22876266 1523a964 1165ea79 22961a03 00000000 00000000
1bb5429c 1523a8b4 2296668a 1143eed2 1143ee40 22963e36 21aa9134 21aa9218
Call Trace:
[<2287c40c>] usb_set_interface+0x19/0x10a [usbcore]
[<22876266>] usb_driver_release_interface+0x3d/0x4e [usbcore]
[<22961a03>] generic_cdc_bind+0x1a5/0x1d5 [usbnet]
[<22963e36>] usbnet_probe+0x2ad/0x463 [usbnet]
[<2287603f>] usb_probe_interface+0x39/0x48 [usbcore]
[<022247a1>] bus_match+0x27/0x45
[<022247fc>] device_attach+0x3d/0x77
[<02224967>] bus_add_device+0x5b/0x89
[<02223c2e>] device_add+0x71/0xfb
[<2287c748>] usb_set_configuration+0x1a1/0x1d0 [usbcore]
[<22876ebf>] usb_new_device+0x32f/0x3a9 [usbcore]
[<2287895f>] hub_port_connect_change+0x1cb/0x213 [usbcore]
[<22878bd2>] hub_events+0x22b/0x3fd [usbcore]
[<22878dc2>] hub_thread+0x1e/0xd0 [usbcore]
[<02123671>] default_wake_function+0x0/0xc
[<22878da4>] hub_thread+0x0/0xd0 [usbcore]
[<0210b1d9>] kernel_thread_helper+0x5/0xb
Code: 8b 88 ac 01 00 00 31 c0 85 c9 74 28 0f b6 41 04 31 db 84 c0
--
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 1 (Yarrow) - Linux kernel 2.6.3-2.1.242
Load : 0.57 0.51 0.25
20 years, 2 months
