[02:38] <Alinux> hello, how can I check with wich version of gcc, kernel is compiled?
[02:45] <cprov> Alinux:  it's a litte off topic question, you shoudl try the ubuntulinux channel, but you're lucky
[02:45] <cprov> Alinux: cat /var/log/syslog* | grep gcc
[02:45] <cprov> Sep  2 03:53:10 localhost kernel: 686 (buildd@terranova) (gcc version 3.3.5 (Debian 1:3.3.5-8ubuntu2)) #1 Thu Aug 18 22:39:14 UTC 2005
[02:46] <Alinux> :)
[02:46] <cprov> Alinux: I'm still using hoary
[02:46] <Alinux> cprov, :) thank yuo brother!
[02:46] <Alinux> :)
[02:46] <cprov> Alinux: you're welcome, enjoy Launchpad
[02:46] <Alinux> I'm using hoary
[02:46] <Alinux> but 2.6.10 kernel istn't stabile for me..
[02:47] <Alinux> my sound card crash-s entire system :)
[02:47] <cprov> Alinux: what is broken for you ? mine is 2.6.10 too
[02:47] <cprov> Alinux: uhm
[02:47] <Alinux> my emu10k1 when loaded, turnes of a kompiuter :)
[02:48] <Alinux> i don't know why
[02:48] <Alinux> so I've installed 2.6.12
[02:48] <Alinux> and no problems now.
[02:48] <Alinux> in this moment I'm trying to install NVidia driver.
[02:48] <cprov> Alinux: join #ubuntu, there will be people ready to help you, ask pitti or fabionne (ok, sat night is for hard hacker, but you can try )
[02:49] <Alinux> but something still doesn't work.
[02:49] <Alinux> :)
[02:49] <Alinux> don't wanna register my nickname :)
[02:49] <Alinux> no time at tihe moment
[02:49] <Alinux> :)
[02:49] <cprov> Alinux: I bet you need newer Nvidia driver , if available
[02:50] <Alinux> no :)
[02:50] <Alinux> I have GeForce MX 5200
[02:51] <Alinux> strangee thing is that after compiling and booting of a new kernel, I have black screen and no boot massages... before gdm starts.
[02:51] <cprov> Alinux: so, not much to discuss, I mean, I'm not really aware of the Nvidia drivers for brezzy
[02:51] <Alinux> even if vga=794 form my 1280x1024 is setted up.
[02:52] <Alinux> :)
[02:52] <Alinux> no it's still hoary :)
[02:52] <Alinux> but with vanilla kernel :)
[02:52] <cprov> Alinux: you need breezy stuff for 2.6.12 AFAIK
[02:54] <Alinux> cprov, thank yuo.
[02:54] <cprov> Alinux: the guys are talking about nv drivers/breezy pre releases just now, why don't you join them at #ubuntu ?
[02:54] <Alinux> cprov, ok :)
[02:55] <cprov> Alinux: good luck
[02:55] <Alinux> cprov,  :) thanks
[08:19] <dilys> Merge to<EMAIL_ADDRESS>[r=SteveA,BjornT]  Zope3FormErrorMessages (patch-2343<EMAIL_ADDRESS>[09:32] <zyga> hello
[09:32] <zyga> anyone who knows how rosetta got initiall messages around?
[09:38] <zyga> jordi: ping
[11:20] <SteveA> hi lifeless.  i've resubmitted the request to pqm now.
[11:46] <SteveA> lifeless: merge failed with a different problem this time.  i have forwarded you the message.
[01:38] <sd-tux> hi, i want to download a .po file from rosetta but i can't do it because of this BUG : https://launchpad.net/malone/bugs/1978  doe's anybody know how other way to downsload my translations :) ?
[01:47] <SteveA> sd-tux: the error is simple to fix.   i've updated the bug report with a description of the problem and its solution.  carlos can look into it tomorrow, and we can get a fix into production pretty soon.
[01:48] <SteveA> sd-tux: thanks for mentioning it on this channel.
[02:19] <sd-tux> SteveA: ok.. thank you
[04:52] <cprov> SteveA -> sunday hard worker ;)
[07:38] <cprov> mpt: ping
[07:38] <cprov> mpt: you have email
[07:46] <mpt> thanks cprov
[07:46] <cprov> mpt: did it work ?
[07:47] <mpt> cprov: If you want to restrict it, it's deadsea
[07:47] <mpt> ah, no, still the same error
[07:55] <SteveA> hi cprov
[07:56] <SteveA> hi mpt
[07:56] <cprov> SteveA: hi SteveA
[07:56] <cprov> mpt:  try $ psql -h gwyddion launchpad_sprint
[08:00] <cprov> mpt: and ? can your machine resolve the name gwyddion ? if not replace it by the IP <IP_ADDRESS>
[08:06] <mpt> hi SteveA
[08:06] <mpt> ** server can't find gwyddion: NXDOMAIN
[08:10] <mpt> cprov: I still get the same error, even with psql -h <IP_ADDRESS> launchpad_sprint
[08:13] <cprov> mpt: cprov@deadsea:~$ psql -h gwyddion launchpad_sprint, works
[08:14] <cprov> mpt: use -U cprov or launchpad
[08:15] <mpt> still "could not connect to server: "
[08:21] <cprov> mpt: you're probably being victimated by some silly mistake, try the dump_sprint-20050825.sql in my HOME, the DB is definitely accessible from deadsea, get local help if necessary
[08:22] <cprov> mpt: keep trying with psql until have success
[08:25] <mpt> ok, there's no-one here except jdahlin, I'll get salgado to help tomorrow
[08:25] <cprov> mpt: put johan on it ... he can solve
[08:51] <mpt> cprov: ok, how do I tell whether job/build/title is a product or a package?
[09:03] <cprov> mpt: I didn't get you point, it is always sourcepackagerelease, it may be included in a product (via Packaging) or not
[09:08] <mpt> cprove: So it's only ever distributions that use AutoBuild, not products?
[09:09] <mpt> cprov: For example, http://tinderbox.mozilla.org/showbuilds.cgi?tree=Firefox is for a product rather than for a distribution
[09:09] <cprov> cprov: indeed, atm it's driven by distrorelease
[09:09] <mpt> okay.
[09:10] <cprov> mpt: but good point, we shoudl attempt to this facet of the problem some time in the future
[09:11] <mpt> all right
[09:11] <mpt> so next, I want to link to that package
[09:14] <SteveA> i am going to be doing some very evil stuff with zcml processors tomorrow morning.
[09:15] <mpt> I guess I'll need to create a browser/build.py for that
[09:15] <SteveA> but, the outcome of it will be that we'll have an optional 'facet' attribute for each page or form directive
[09:15] <SteveA> that says what facet that page or form is to belong to.
[09:16] <mpt> cool
[09:16] <cprov> mpt: it's alrady created, isn't it ?
[09:16] <mpt> cprov: There's database/build.py but not browser/build.py
[09:17] <cprov> mpt: ok, we only have browser/builder.py ...
[09:17] <mpt> right
[09:18] <mpt> I'm creating only one function
[09:18] <mpt> so can it go in builder.py, or should I make a new file for it?
[09:19] <cprov> mpt: new file browser/build.py
[09:20] <cprov> mpt: but It won't be easy, we only have srcpkgname/distrorelease/productseries in packaging ...  the join will hurt a bit
[09:39] <mpt> cprov: ping (when you're back)
[09:40] <cprov> mpt: just behind you ...
[09:40] <mpt> no, that's jdahlin who's just behind me :-)
[09:40] <mpt> cprov: Could you teach me how to find what properties are inside some other database property?
[09:41] <mpt> For example, I want to show something if the build is successful
[09:41] <mpt> Judging by dbschema.py, tal:condition="build/buildstate/fullybuilt" should do what I want
[09:42] <mpt> but it returns NotFoundError: (<Item FULLYBUILT (1) from <class 'canonical.lp.dbschema.BuildStatus'>>, 'fullybuilt')
[09:42] <cprov> mpt: you can just say: "if the build was sucessfully"  by retrieving the Builds, at this time buildqueue entry is gone
[09:42] <cprov> mpt: build/buildstate/value or title
[09:43] <cprov> mpt: but yes, compare dbschema is ugly ... we definitely should have a programable formatter for it or extend dbschema to support it
[09:43] <mpt> Yes, I can see how you've used title
[09:44] <cprov> mpt: which is UGLY and can't stay like this
[09:44] <mpt> and I can see class BuildStatus in slave.py
[09:44] <mpt> but the values defined in BuildStatus don't work either
[09:45] <mpt> e.g. tal:condition="build/buildstate/depfail"
[09:45] <cprov> mpt: er, you can't do that
[09:46] <cprov> mpt: buildstate is a dbschema after that only title|value
[09:47] <cprov> mpt: we could embed some graphical representation in the dbschema structure or declare special formatter to do the comparision in code not in tales
[09:58] <mpt> cprov: So it looks like the only way to get at the build state is (a) using the raw number (b) with a python: expression
[09:59] <cprov> mpt: exactly, that's what formatters are for, isn't it ?
[09:59] <mpt> true
[10:00] <mpt> the word you want there is "neither" :-)
[10:01] <mpt> cprov: Could you insert some random gibberish into one of your build packages so it doesn't build? :-)
[10:01] <cprov> mpt:  indeed, watching ferris beeler day off keep concentration hard to do
[10:01] <mpt> otherwise I can't see what failure looks like
[10:02] <cprov> mpt:  it's stopped, you can just modify the fields by hand using psql
[10:03] <mpt> ah, so I get to learn psql as well
[10:05] <Lathiat> just a point, its very confusing on product bug pages, e.g. https://launchpad.net/products/855resolution/+bugs/1779/ how i can comment on the bug i ahve to load the bug in malone)
[10:05] <mpt> cprov: Why is it important to show both the date created and the date started?
[10:06] <cprov> mpt: in few words they still inside the history (limited to 10 items) because the build/builder still pointing to us, the only thing changes is the buildstate
[10:06] <mpt> Lathiat: bradb is fixing that at the moment
[10:06] <Lathiat> mpt: oh cool
[10:06] <Lathiat> took me liek 3 minutes to figure that out :)
[10:06] <cprov> mpt: we can calculate the delay in the buildqueue
[10:07] <mpt> cprov: Sorry, I didn't understand that
[10:07] <mpt> cprov: What do you mean by "pointing to us"?
[10:08] <cprov> mpt: mpt build/builder == builder.id
[10:10] <mpt> cprov: I don't see what that has to do with the date, sorry
[10:12] <cprov> mpt: nothing, it was answering the question about the different possible buildstates
[10:12] <cprov> mpt: datecreated/datebuilt/buildduration are related to the time spent in each build system stage
[10:52] <mindmedic> Is .po file uploading in rosetta currently disabled?
[10:59] <zyga> anyone alive?
[11:02] <mindmedic> zyga, yes.
[11:04] <zyga> mindmedic: maybe you know if
[11:04] <zyga>  is http://l10n-status.gnome.org/gnome-2.12/pl/desktop/index.html automatically imported here https://launchpad.net/distros/ubuntu/breezy/+lang/pl
[11:06] <mindmedic> i dont know.. look, ask in the gnome translations team..


[00:26] <jbicha> jawn-smith: I think I fixed that issue a different way. I am uploading to Debian and it will autosync to Ubuntu
[00:42] <jawn-smith> jbicha: awesome, thanks!
[07:59] <cpaelzer> athos: I updated https://bugs.launchpad.net/ubuntu/+source/amavisd-new/+bug/1895799 as discussed
[08:00] <cpaelzer> athos: I'll try to remind foundations on monday about it if they did not pick it up already by then
[12:04] <athos> thanks, cpaelzer :)
[12:04] <ahasenack> morning
[12:40] <Fantu> hi, memtest86+ 5.31b+dfsg-4 that solves many issues and inlcudes also ubuntu changes of latest years was uploaded to debian unstable 4 days ago but I still not saw it in next ubuntu (Jammy) as proposed, is there something that block autosync from debian? thanks for any reply
[13:06] <xypron> sil2100: for new package cd-boot-images-riscv64 we will need a repository https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/cd-boot-images-riscv64. Could you, please, create a repo for which I can create my merge request.
[13:15] <jbicha> Fantu: packages don't autosync if they have Ubuntu-specific changes (the version number has the word 'ubuntu' in it) so someone will need to manually merge that update https://launchpad.net/ubuntu/+source/memtest86+
[13:17] <ahasenack> xypron: is that a new src package?
[13:17] <Fantu> jbicha thanks for reply, can anyone check and force sync please?
[13:18] <schopin> ginggs: ping regarding the memtest thing?
[13:18] <schopin> (see just above)
[13:18] <xypron> ahasenack: yes LP: #1960216
[13:19] <ahasenack> I can import it into git-ubuntu once there is a publication in LP
[13:20] <xypron> ahasenack: should I push to<EMAIL_ADDRESS>?
[13:21] <ahasenack> whatever you feel more comfortable with, unless your team has a policy and you need it in some specific place. rbasak, I don't think the very first import of a package can account for rich history, can it?
[13:29] <rbasak> ahasenack: I think that might be a currently unsupported edge case. But you're welcome to try if the rich history exists. Worst case: it doesn't get adopted.
[14:37] <rbasak> "This team is responsible for administrative and maintenance tasks for the Ubuntu package archive, including processing of new packages, handling requests for package syncs from external repositories, migration of packages between components, and other administrative matters."
[14:37] <rbasak> "handling requests for package syncs from external repositories"
[14:37] <rbasak> That's not a thing any more, right?
[14:48] <Fantu> rbasak thanks for the message, about handling memtest86+ sync from debian is there something that I should do? (like open a request somewhere) or I only need wait that someone of the team take care of it?
[14:49] <rbasak> Sorry, that wasn't intended for you. I was asking about the description of the ~ubuntu-archive team in Launchpad.
[14:49] <rbasak> There is a process to request a sync
[14:50] <rbasak> But I thought maybe the people discussing it above would be able to just do it, without requiring that process.
[14:50] <rbasak> Maybe hang around to see?
[14:50] <rbasak> If not, and you'd like to submit to the process to make sure it's not forgotten about, that's fine too.
[14:51] <rbasak> https://wiki.ubuntu.com/SyncRequestProcess#For_people_requiring_sponsorship
[14:51] <rbasak> Basically, there should be a bug in Launchpad against the package with the details, and ~ubuntu-sponsors should be subscribed.
[14:52] <rbasak> But please keep poking here either way to make sure it gets done
[15:07] <cjwatson> rbasak: Yeah, I don't think that's been a thing for a loooong time.  I've removed that clause
[15:17] <Fantu> rbasak thanks, done https://bugs.launchpad.net/ubuntu/+source/memtest86+/+bug/1960521
[15:39] <rbasak> schopin, ginggs: ^
[16:07] <ahasenack> mirespace<EMAIL_ADDRESS>and<EMAIL_ADDRESS>need an explanation or fix about why they are failing
[16:08] <ahasenack> the rsync sru bug should also have two comments at the end with links to the excuses page with these failures
[16:28] <mirespace> the skew-clone test for digit in focal stills fails fo '
[16:28] <mirespace> curl: (22) The requested URL returned error: 400 Bad request
[16:28] <mirespace> dgit: failed command: curl --proto-redir '-all,http,https' -L -f -o ./example_1.0-1.debian.tar.xz -- http://<IP_ADDRESS>:43933//pool/main/example_1.0-1.debian.tar.xz
[16:28] <mirespace> local file is not found
[17:13] <ahasenack> that's a localhost url
[17:13] <ahasenack> which the test itself presumably sets up
[17:24] <mirespace> yes
[18:03] <mmikowski> @bdmurray @vorlon @schopin @Juliank I saw some posts on /boot partition discussions.
[18:04] <bdmurray> mmikowski: Starting a discussion on the ubuntu-devel mailing list would be the best way for all of us to be able to discuss this.
[18:05] <juliank> yes, please do not discuss this on irc
[18:06] <mmikowski> yet 4 people just did discuss this on IRC.
[18:06] <mmikowski> over numerous posts.
[18:07] <mmikowski> I'm happy to move to a mailing list post, but just pointing out the obvious I guess.
[18:08] <bdmurray> That was during a regular scheduled meeting of the Foundations team a team which all four of those people are members.
[18:08] <juliank> moving the discussion to mail was the outcome of the discussion
[18:08] <juliank> also you are not on that channel, so how did you see it in the first place?
[18:08] <mmikowski> bdmurray: ok, thank you for the clarification.
[18:09] <mmikowski> The conversation was forwarded to me. I was under the impression that was IRC conversation, not a meeting.
[18:09] <mmikowski> Sorry for the misunderstanding.
[18:09] <juliank> the meeting took place on #ubuntu-meeting
[18:10] <mmikowski> The link was sent to me.  Of course, this is a public transcript.
[18:11] <mmikowski> In any event, I'd be happy to post the responses to the bug which seems more appropriate as it will be proximate to the issue at hand.
[18:15] <bdmurray> mmikowski: Please start a discussion on the mailing list so we can have reply with context. This is much harder to do in a Launchpad bug.
[18:15] <bdmurray> s/reply/replies/
[18:17] <mmikowski> bdmurray: ok, let me review my mailing lists and report. However, I can respond to all these issues on 1959971
[18:18] <mmikowski> bdmurray: thanks
[20:40] <bdmurray> seb128: I see bug 1959362 is assigned to you, are you working on it?
[20:43] <seb128> bdmurray, no yet, comment #5 suggested it might be already fixed though
[21:08] <mwhudson> "test_many_processes (test.test_multiprocessing_forkserver.WithProcessesTestProcess) ... Killed" oh come on
[21:08] <mwhudson> can upstreams write test cases that don't kill the infrastructure please
[21:11] <mwhudson> vorlon: this is python3.9/ppc64el you talked about in the meeting btw
[21:11] <vorlon> mwhudson: I added it to big_packages, did it get retried on larger instance yet?
[21:11] <vorlon> it did
[21:12] <vorlon> it passed
[21:12] <mwhudson> ah yes
[21:12] <mwhudson> hooray latency
[21:12] <mwhudson> now does anyone know what pgloader is
[21:13] <mwhudson> because<EMAIL_ADDRESS>sure looks like an openssl problem and not a glibc problem
[21:13] <vorlon> yeah that was mentioned in backchannel during the meeting
[21:13] <vorlon> this of course means there are no logs so I don't remember who called dibs - possibly schopin but I'm not sure
[21:16] <mwhudson> ok
[22:52] <mwhudson> what is going on here
[22:52] <mwhudson><EMAIL_ADDRESS>[22:52] <mwhudson> Broken libexpat1-dev:i386 Depends on libc6-dev:i386 < 2.35-0ubuntu1 @ii R >
[22:52] <mwhudson> i don't see that constraint anywhere
[22:53] <mwhudson> oh it's cross-toolchain-base fun and games i guess